<Project> build constitution

<Describe the product, stack and client relationship in one sentence.> Read this file, STATE.md and RULES.md on startup, resume and handoff. Read the nearest package instructions and existing scripts before editing. Inspect Git status and protect unrelated work.

Rule zero: recover the answer before asking again

Before a client question or a needs-client label, search decisions, the message ledger, the mailbox and the docs archive. Start with bash scripts/brief.sh <topic> or the brief skill. Read the matching bodies, comments, full mail threads and attachments. Check sender and date. An acknowledgement is not approval; a prior answer can apply only to one platform or release. An unavailable source means search incomplete. Preserve existing decisions and authorization. See docs/agent-workflow.md and .claude/skills/client-feedback/SKILL.md.

Verification standard

Green suites prove nothing about a boundary they never exercised. Run the thing. A task is done when the relevant behavior was observed: a route called, a screen loaded or a row read back. Tests support that evidence. An agent's completion reply remains a claim. Check git status --short, git diff --stat and git log -1 after delegated work.

For a logic defect, reproduce it and show the fix at its real entry point. Run the most targeted existing check. For a screen, inspect the relevant desktop/mobile view or both native platforms when affected. Attach safe evidence. State skipped checks and missing environments plainly. Read exit status and output; never turn a failed command into the word clean.

When corrected: add what happened, root cause and prevention to archive/MISTAKES.md; bump the matching RULES.md count. At the second occurrence, consider a scoped rule or executable check. Name exactly what it catches and what remains judgment. See review.md for acceptance cases.

Rules of engagement

1. One file, one owner. Independent writers use separate worktrees and explicit path fences.
2. Use the existing package manager, helper APIs and architecture. Ask before new production dependencies.
3. Preserve a meaningful failing assertion while making the implementation pass. Do not weaken tests to hide a defect.
4. Keep commands and credentials separate. Never print, commit or paste credential values into records.
5. Inspect access and environment before calling them unavailable. See the dev-reference skill.
6. Stage explicit paths. Do not revert unrelated changes or rewrite shared history.
7. Never add AI attribution or Co-Authored-By trailers to commits. Check the final message yourself.
8. Observe the user's release and communication authorization. A merge is not delivery.
9. Stop only the dev servers you started. Record the ports and cleanup.
10. Cross-package or product-rule gaps become a contract request, not an invented endpoint or changed requirement.

Repository map to adapt

Run <typecheck command>, <lint command> and <targeted test command> as the change requires, then observe behavior. Those commands belong to your application; this reference has no app suite.

Spec stack

Governance

Do not change LOGIC.md or a decision to make code pass. A changed requirement needs an owner decision with evidence and a new decision record. Builders request contract changes; the named owner applies them. Read specs/SESSIONS.md before splitting work and docs/agent-harness.md before relying on hooks. The lane scripts are an adaptation of a one-night experiment, not a requirement to delegate or authorization to run unattended jobs.