Constitution

constitution — the project's non-negotiable principles

The first rsc-sdd phase. Run once per project, then amend. It writes down the rules every later phase obeys: stack canon, quality bars, conventions. Everything downstream — specify, plan, analyze, implement, verify, review — reads this file as guardrails.

A constitution is small, durable, and enforceable. It is not a wiki of everything you know about the project (that is what 02-DOCS/wiki/ already is, run by the harness). It is the short list of principles that, if violated, mean the work is wrong regardless of whether it runs. If a rule here cannot be checked or pointed at later, it does not belong here — move it to the stack wiki and link it.

Not this phase: what to build → ../specify/SKILL.md; the technical approach for one feature → ../plan/SKILL.md; setting up 01-TOOLS/ + 02-DOCS/ or capturing general project knowledge → harness; concrete stack mechanics (how to configure Ruff, pytest, Tailwind tokens) → the relevant stack skill (../fastapi/SKILL.md, ../nextjs/SKILL.md, ../go/SKILL.md, ../postgresdb/SKILL.md, ../flutter/SKILL.md, ../design/SKILL.md, ../secure-coding/SKILL.md). The constitution names the bar; the stack skill enforces it.

Model tier — heavy (opt-in routing)

This phase's default model tier is heavy — it sets the project's non-negotiables, the highest-leverage decisions in the repo. Routing is off unless models.enabled: true in 02-DOCS/wiki/sdd/config.yaml. When on: resolve this phase's tier (models.overrides wins over models.phases), map it to a model via models.tiers, and apply per ../sdd/references/model-routing.md — announce the switch in one line when it differs from the session model, and dispatch any Task/parallel subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.

Honor the register first

Before asking anything, read 02-DOCS/wiki/harness/user-profile.md and use its technical_level: technical terms, or plain words with analogies. No profile yet → use analogies and ask once "technical or with analogies?", or point the user at init; never assume fluency. The interview is the same for every reader:

• Infer almost everything from the codebase and stack wiki. Ask only the few questions that genuinely change a principle.
• Give one line of why per principle proposed, and the trade-off where a rule constrains the team — in the orient voice.
• For a non-technical reader, say in one sentence what a constitution is (the house rules every later step obeys) before drafting.

Reconcile before you write (do not duplicate the stack wiki)

The harness may already hold real conventions under 02-DOCS/wiki/stack/* (e.g. nextjs.md, fastapi.md, postgresdb.md). The constitution does not copy them — it ratifies the principle and links the detail. Run this reconciliation pass first:

1. Read the Knowledge map — the full index lives in 02-DOCS/wiki/index.md (root CLAUDE.md keeps only a short pointer to it). List every 02-DOCS/wiki/stack/* article that exists.
2. Read each stack article. Pull out anything already phrased as a rule (a version pin, a lint config, a test threshold, a naming convention).
3. For each existing rule, decide: is it a project-wide non-negotiable (→ ratify it as a principle, linking the stack article for detail) or a local mechanic (→ leave it in the stack wiki, do not lift it into the constitution)?
4. Contradictions are findings, not fixes. If two stack articles disagree, or a stack article contradicts what the user states now, surface it and let the user resolve — never silently pick a winner.

The rule of thumb: the constitution says "every endpoint is typed and tested to ≥80% line coverage — see wiki/stack/fastapi.md for the pytest setup". It does not paste the pytest config.

What a principle must have

Every principle in the constitution is one numbered, testable statement. A vague aspiration is not a principle.

• Imperative and specific. "Code is formatted with the repo's formatter on every commit" — not "we value clean code".
• Checkable. There must be a way for ../analyze/SKILL.md and verify to tell whether it held. Prefer a number, a command, or a named artifact.
• Owned. If enforcement lives in a stack skill or a script, link it.
• Falsifiable in review. A reviewer can point at a diff and say "this violates principle 4".

Weak   — "We care about security."
Strong — "4. No secret is ever committed; secrets load from 01-TOOLS/<provider>/.env
          (gitignored). Enforced by secure-coding + a pre-commit secret scan."

The interview (requirements-first, batched)

Gather what you cannot infer, then draft. Ask in one short batch — only the questions that matter. Cover these dimensions — skip any the stack wiki already answers, and confirm rather than re-ask:

1. Stack canon — languages, frameworks, runtime/versions, package manager. What is fixed vs. open?
2. Quality bar — formatter/linter (must pass clean?), type checking (strict?), test discipline (TDD? coverage floor? what kind of tests gate a merge?).
3. Conventions — naming, directory structure, module boundaries, API/error shapes, commit message format.
4. Branching & shipping — branch naming, PR required?, who/what gates a merge, release cadence. (Authorship rule is fixed — see below.)
5. Security & privacy floor — secret handling, authn/z baseline, data residency, dependency policy.
6. Accessibility & UX floor (if there's a UI) — the minimum bar (e.g. WCAG AA, keyboard-navigable).
7. Performance budgets (where they matter) — a named budget, not "should be fast".
8. Documentation & knowledge — what must be written down (decisions log, the wiki) and when.

For any significant either/or (e.g. "strict types or gradual?", "squash or merge commits?"), use the harness "siempre 3 opciones" shape where it applies: gather the constraint, present up to 3 honest options with a recommendation matched to the team's level, then ratify the choice and log it.

Fixed principles (always present)

Two principles are inherited from the rsc ecosystem and appear in every constitution unless the user explicitly overrides them:

• Git authorship is the human's. Commits and PRs are authored by the human (Eric, or whoever owns the repo). No Co-Authored-By an AI, no "generated with" footer. Enforced at the ship phase.
• Decisions are logged. Every significant decision is appended to 02-DOCS/wiki/sdd/decisions.md (or the harness decisions.md) with date, options considered, and the why. The constitution itself is the highest-order decision record.