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.