amend

name	Amend
description	Formally amend the constitution, with mandatory impact analysis before any change lands. The constitution is supreme law; amendments are versioned and their downstream effects scanned first.
argument-hint	[section] [--impact] [--force]

Amend — Change the Constitution

The formal process for changing the constitution, with mandatory impact analysis before any change lands. The constitution is supreme law; amendments are versioned and their downstream effects are scanned first.

Process

1. Identify the amendment. Take the section number as an argument, or show the constitution's table of contents and ask. Amendment types: tech stack, quality gates, conventions, architecture decisions.

2. Impact analysis (always first). Before applying anything, scan for downstream impact:

   • Approval records — scan active features' approvals/master.json and group-N.json for records referencing the affected section or the constraints being changed.
   • Implementation dependencies — search feature directories for specs referencing the section, micro specs constrained by the changing rule, and completed implementations that may need review.

   Present a summary with a risk level:

   Impact Analysis for Amendment:
   AFFECTED FEATURES:        {list with approval status}
   APPROVAL RECORDS:         {count} reference affected constraints
   IMPLEMENTATIONS AT RISK:  {count} completed implementations
   RISK LEVEL: {Low | Medium | High | Critical}
   

   --impact stops here (analysis only). If risk is High/Critical and --force is not set, refuse: "This amendment affects {N} active features. Use --force to proceed, or resolve in-progress work first."

3. Apply the amendment. On approval:

   1. Draft the amendment text with its rationale.

   2. Write the change to the constitution.

   3. Append to the constitution's changelog (the versioning record):

      | #{NNN} | {date} | S{section} | {summary} | {rationale} |
      

      The sequential #NNN is the amendment's version identifier; the changelog is the durable history.

   4. Update the project-state.md session log.

   5. Downstream cleanup checklist — after applying, verify every reference still holds:

      • other specs referencing the amended section — still accurate?
      • design-doc sections describing the amended area — updated?
      • skill/doc examples referencing the amended behavior — updated?
      • coverage maps (FR/AC) — do they still add up?
      • shared file paths — do other specs that touch them know?

      Fix any failing check before committing. Amendments that don't propagate leave stale references that the final audits catch.

4. Commit. A single scoped commit, e.g. amend: constitution section {N} — {summary}.

Natural language triggers

- "amend the constitution"
- "change a project rule"
- "what would this amendment affect"