Project Constitution

Project Constitution

The constitution is the set of non-negotiable rules that govern every plan, task, and review in this repository. It is the highest authority in the Spec-Driven Development loop: a feature that conflicts with the constitution must either be rejected or the constitution must be amended first, with rationale.

The full text lives at .specify/memory/constitution.md. This page summarizes it and explains the reasoning.

Core principles

I. Static Output First

The site must build to static files hostable without a custom server, database, queue, or runtime API. Any feature requiring server-side execution is rejected unless the constitution is amended.

Why: it keeps hosting, operations, and recovery simple, and it is the defining constraint that shapes the whole architecture.

II. Content Is Source-Controlled

All page content, configuration, and build inputs live in the repository. External media or embeds must have stable references and local fallbacks when they affect the primary experience.

Why: every change becomes reviewable and reproducible from source alone.

III. Accessible By Default

Every user-facing change preserves semantic HTML, keyboard navigation, readable contrast, meaningful link text, and useful alt text. Accessibility checks are part of review for any changed page.

Why: a static site still has real users and real assistive-technology needs.

IV. Fast, Stable Delivery

Every change keeps the production build deterministic and lightweight. Plans must identify the build command, static output directory, and verification path before implementation.

Why: it prevents deployment surprises and keeps the site cheap to serve.

V. Minimal Surface Area

New dependencies, scripts, and build tools must be justified by visible user value or clear maintenance savings. Prefer platform features, static assets, and small focused components over custom frameworks or services.

Why: it keeps the project understandable as it grows.

Additional constraints

• Static Web Constraints — no secrets in client code, no private data persistence in the browser unless explicitly required, and no runtime dependencies that cannot be served as static assets. Public pages should remain usable when optional third-party embeds fail.
• Delivery Workflow — each plan documents the hosting target, output directory, preview command, and verification steps. Each implementation runs the documented build or explains why it could not. Reviews check changed pages for accessibility, broken links or assets, and avoidable dependency growth.

How the constitution is enforced

The constitution is not a passive document. It is wired into the workflow:

flowchart LR
    CON[Constitution] --> GATE{Constitution Check\ngate in plan.md}
    GATE -->|PASS| DESIGN[Proceed to design + tasks]
    GATE -->|FAIL| AMEND[Reject feature or amend constitution]
    DESIGN --> RECHECK{Re-check after design}
    RECHECK -->|PASS| IMPL[Implement]
    RECHECK -->|FAIL| AMEND

Loading

Every plan.md contains an explicit Constitution Check section that must pass before Phase 0 research and is re-checked after the design is complete. For this feature the gate passed because the planned architecture is a static Next.js export with embedded data, no database or runtime API, explicit accessibility checks, documented build and preview commands, and a small dependency set limited to the framework and verification tooling.

Governance and versioning

Amendments require a rationale, an expected-impact statement, and any required template updates. Versions follow semantic versioning:

• MAJOR — backward-incompatible governance changes
• MINOR — new or materially expanded principles
• PATCH — clarifications that do not change obligations

Compliance is reviewed during planning and before merge. A feature that violates the constitution must document the violation and receive explicit approval before implementation continues.

Current version: 1.0.0 — Ratified 2026-06-18.

Why a constitution at all

In an AI-assisted workflow, the agent will optimize for whatever the spec asks. The constitution gives it a fixed frame of values it must respect regardless of any individual spec — the guardrails that stop a locally reasonable request from violating a global principle. It is the difference between "build what I said" and "build what I said, within the rules we agreed on."

See Why Spec-Driven Development for the broader motivation, and Methodology Comparison for how this compares to acceptance criteria in classic DevOps planning.