@cluesmith/codev 3.0.2 → 3.0.5

package/skeleton/protocols/air/protocol.md

@@ -37,6 +37,10 @@ AIR is a minimal protocol for implementing small features (< 300 LOC) where the
 - Architectural changes → use **SPIR**
 - Complex features with multiple phases → use **SPIR** or **ASPIR**
 
+## Baked Decisions (Optional)
+
+When filing an issue for AIR, you can pin architectural decisions you don't want the builder or CMAP reviewers to re-litigate. Include a `## Baked Decisions` section (any heading level is fine) anywhere in the issue body. Useful categories: language, framework, deployment shape, key dependencies, decisions deferred to a later spec. The builder will treat each listed item as fixed during implementation; CMAP reviewers will not propose alternatives unless the implementation itself fails to honor a stated decision. Leave the section out for issues where you want the builder to explore freely — absence is the no-op default. You can amend or rescind a baked decision at any time by updating the issue and respawning, or by sending the builder a direct instruction via `afx send`.
+
 ## Protocol Phases
 
 ### I - Implement

package/skeleton/protocols/aspir/builder-prompt.md

@@ -30,6 +30,12 @@ You are running in STRICT mode. This means:
 Follow the ASPIR protocol: `codev/protocols/aspir/protocol.md`
 Read and internalize the protocol before starting any work.
 
+## Baked Decisions
+
+If the issue body contains a section named "Baked Decisions" (any heading level, case-insensitive), treat its contents as fixed architectural decisions baked in by the architect. Do not autonomously override them in your spec, plan, or implementation. If you discover a serious reason to question a baked decision, surface that concern to the architect via `afx send` rather than relitigating it inside the spec/plan/review.
+
+If the architect's baked-decisions section contains internal contradictions (e.g., two different language choices), do not pick one — pause, flag the contradiction to the architect via `afx send`, and wait for resolution before proceeding.
+
 {{#if spec}}
 ## Spec
 Read the specification at: `{{spec.path}}`
@@ -53,13 +59,23 @@ Follow the implementation plan at: `{{plan.path}}`
 {{task_text}}
 {{/if}}
 
-## Multi-PR Workflow
+## PR Strategy
+
+**Do not autonomously open a PR per implementation phase.** Plan phases ship as git commits within a single PR, not as separate PRs. The plan's instruction that "each phase commits independently" refers to git commits, not PRs.
+
+By default, the PR is opened during/after the final implement phase, with all phase-commits already on the branch.
+
+### Architect-requested PRs
+
+The architect MAY request a PR at any point — for spec review, mid-implementation feedback, slicing a large spec into shippable PRs, etc. When the architect explicitly asks for a PR earlier (or for additional PRs), follow that direction. The prohibition is specifically on the *builder* autonomously deciding to open per-phase PRs without architect request.
+
+### Multi-PR Mechanics (when the architect requests sequential PRs)
 
-Your worktree is persistent — it survives across PR merges. You can produce multiple PRs sequentially:
+Your worktree is persistent — it survives across PR merges. When the architect asks for sequential PRs (e.g., to slice a large spec into shippable pieces), use this loop:
 
 1. Cut a branch, open a PR, wait for merge
 2. After merge: `git fetch origin main && git checkout -b <next-branch> origin/main`
-3. Continue to the next phase, open another PR
+3. Continue to the next slice, open another PR
 
 **Important**: Do NOT run `git checkout main` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/main` via fetch.
 

package/skeleton/protocols/aspir/consult-types/plan-review.md

@@ -3,6 +3,12 @@
 ## Context
 You are reviewing an implementation plan during the Plan phase. The spec has been approved - now you must evaluate whether the plan adequately describes HOW to implement it.
 
+## Baked Decisions
+
+If the issue body or the approved spec's Constraints section includes content under a "Baked Decisions" heading, the architect has marked those choices as fixed (this extends the existing "don't re-litigate spec decisions" rule with explicit baked-decision language). Do not autonomously challenge them: do not propose alternative languages, frameworks, deployment shapes, or dependencies that contradict a baked decision. You may `COMMENT` with concerns; reserve `REQUEST_CHANGES` for the case where the plan **fails to honor** a stated baked decision — that is a real defect.
+
+If the baked decisions themselves contain contradictions, do not pick one — `REQUEST_CHANGES` and ask the architect to clarify before proceeding.
+
 ## Focus Areas
 
 1. **Spec Coverage**

package/skeleton/protocols/aspir/consult-types/spec-review.md

@@ -3,6 +3,12 @@
 ## Context
 You are reviewing a feature specification during the Specify phase. Your role is to ensure the spec is complete, correct, and feasible before it moves to human approval.
 
+## Baked Decisions
+
+If the issue body or the spec's Constraints section includes content under a "Baked Decisions" heading, the architect has marked those choices as fixed. Do not autonomously challenge them: do not propose alternative languages, frameworks, deployment shapes, or dependencies that contradict a baked decision. You may `COMMENT` with concerns about a baked decision (the architect decides whether to rescind it); reserve `REQUEST_CHANGES` for the case where the spec **fails to honor** a stated baked decision — that is a real defect.
+
+If the baked decisions themselves contain contradictions (e.g., two different language choices), do not pick one — `REQUEST_CHANGES` and ask the architect to clarify before proceeding.
+
 ## Focus Areas
 
 1. **Completeness**

package/skeleton/protocols/aspir/prompts/specify.md

@@ -31,6 +31,12 @@ ls codev/specs/{{project_id}}-*.md
 
 **If no spec exists:** Proceed to Step 1 below.
 
+### 0.5 Baked Decisions
+
+Before exploring solution approaches, check the issue body for a section named "Baked Decisions" (any heading level, case-insensitive). If present, copy its content verbatim into the spec's Constraints section and treat each item as fixed. Do not autonomously relitigate the architect's choices in your Solution Exploration. If you discover a serious problem with a baked decision, raise it via `afx send architect` rather than overriding it in the spec.
+
+If two baked decisions contradict each other (e.g., two different language choices), do not pick one — pause, flag the contradiction via `afx send`, and wait for resolution before drafting.
+
 ### 1. Clarifying Questions (ONLY IF NO SPEC EXISTS)
 
 Before writing anything, ask clarifying questions to understand:

package/skeleton/protocols/aspir/protocol.md

@@ -41,6 +41,10 @@ Use SPIR instead when:
 - The work is **high-risk** — security-sensitive, user-facing, or broadly impactful
 - You want to **review and adjust** the plan before implementation starts
 
+## Baked Decisions (Optional)
+
+When filing an issue for ASPIR, you can pin architectural decisions you don't want the builder or CMAP reviewers to re-litigate. Include a `## Baked Decisions` section (any heading level is fine) anywhere in the issue body. Useful categories: language, framework, deployment shape, key dependencies, decisions deferred to a later spec. The builder will copy the section verbatim into the spec's Constraints and treat each item as fixed; CMAP reviewers will not propose alternatives unless the spec itself fails to honor a stated decision. Leave the section out for issues where you want the builder to explore freely — absence is the no-op default. You can amend or rescind a baked decision at any time by updating the issue and respawning, or by sending the builder a direct instruction via `afx send`.
+
 ## Protocol Phases
 
 ASPIR follows the same four phases as SPIR. For full phase documentation, see the [SPIR protocol](../spir/protocol.md).

package/skeleton/protocols/bugfix/consult-types/impl-review.md

@@ -1,38 +1,54 @@
-# Implementation Review Prompt
+# Implementation Review Prompt (BUGFIX)
 
 ## Context
-You are reviewing implementation work during the Implement phase. A builder has completed a plan phase and needs feedback before proceeding. Your job is to verify the implementation matches the spec and plan.
+You are reviewing in-progress fix work for a **BUGFIX protocol** project. A builder has investigated a GitHub Issue, identified a root cause, and is implementing the fix + regression test. Your job is to verify the fix matches the issue's symptom and meets BUGFIX standards.
+
+**BUGFIX is not SPIR.** There is **no spec, no plan, and no review document**. The GitHub Issue is the spec. The PR body will be the review. Do **not** request changes for missing `codev/specs/`, `codev/plans/`, or `codev/reviews/` artifacts.
 
 ## CRITICAL: Verify Before Flagging
 
 Before requesting changes for missing configuration, incorrect patterns, or framework issues:
-1. **Check `package.json`** for actual dependency versions — framework conventions change between major versions
-2. **Read the actual config files** (or confirm their deliberate absence) before flagging missing configs
-3. **Do not assume** your training data reflects the version in use — verify against project files
-4. If "Previous Iteration Context" is provided, read it carefully before re-raising concerns that were already disputed
+1. **Check `package.json`** for actual dependency versions — framework conventions change between major versions.
+2. **Read the actual config files** (or confirm their deliberate absence) before flagging missing configs.
+3. **Do not assume** your training data reflects the version in use — verify against project files.
+4. If "Previous Iteration Context" is provided, read it carefully before re-raising concerns that were already disputed.
 
 ## Focus Areas
 
-1. **Spec Adherence**
-   - Does the implementation fulfill the spec requirements for this phase?
-   - Are acceptance criteria met?
+1. **Issue Adherence**
+   - Does the implementation actually resolve the symptom described in the GitHub Issue?
+   - Is the root cause fix targeted, or is it a workaround that masks the symptom?
+
+2. **Regression Test**
+   - Is there a regression test that exercises the exact scenario from the issue?
+   - Without the fix applied, would this test fail? (The whole point.)
+   - Is the test deterministic?
+   - If no test was added, has the builder justified why (e.g., docs-only change with no testable behavior)?
+
+3. **Scope Discipline**
+   - Is the change focused on the root cause only — no unrelated refactors, no drive-by fixes?
+   - Is the net diff staying under ~300 LOC? If it has grown larger, should this escalate to SPIR/TICK?
 
-2. **Code Quality**
+4. **Code Quality**
    - Is the code readable and maintainable?
-   - Are there obvious bugs or issues?
-   - Are error cases handled appropriately?
+   - Are there obvious bugs or issues introduced by the fix?
+   - Are error cases handled appropriately for the path that was changed?
+   - No debug code, stray `console.log`, or commented-out code.
 
-3. **Test Coverage**
-   - Are the tests adequate for this phase?
-   - Do tests cover the main paths AND edge cases?
+5. **Test Status**
+   - Existing tests still pass.
+   - Build still passes.
+   - No new flaky tests introduced.
 
-4. **Plan Alignment**
-   - Does the implementation follow the plan?
-   - Are there plan items skipped or partially completed?
+## Out of Scope (Do NOT request changes for)
 
-5. **UX Verification** (if spec has UX requirements)
-   - Does the actual user experience match what the spec describes?
-   - If spec says "async" or "non-blocking", is it actually async?
+The following are **not** part of the BUGFIX protocol and must **not** be cited as REQUEST_CHANGES reasons:
+
+- Missing `codev/specs/<N>-*.md`, `codev/plans/<N>-*.md`, or `codev/reviews/<N>-*.md` — BUGFIX produces none of these. The GitHub Issue is the spec; the PR body is the review.
+- Commit format `[Spec NNNN][Phase]` — BUGFIX uses `Fix #N: ...` or `[Bugfix #N] ...`. This is the protocol-mandated format, **not** a bug.
+- `status.yaml` fields such as `build_complete: false` — porch manages `status.yaml`; the builder is **forbidden** from editing it manually. Treat porch state as informational, not a fixable issue.
+- "Plan Alignment" or "Spec Adherence" — there is no plan and no spec to align with.
+- Phase-scoping concerns — BUGFIX is single-phase by design. There are no plan phases to scope against.
 
 ## Verdict Format
 
@@ -51,22 +67,13 @@ KEY_ISSUES:
 ```
 
 **Verdict meanings:**
-- `APPROVE`: Phase is complete, builder can proceed
-- `REQUEST_CHANGES`: Issues that must be fixed before proceeding
-- `COMMENT`: Minor suggestions, can proceed but note feedback
-
-## Scoping (Multi-Phase Plans)
-
-When the implementation plan has multiple phases (e.g., scaffolding, landing, media_rtl):
-- **ONLY review work belonging to the current plan phase**
-- The query will specify which phase you are reviewing
-- Do NOT request changes for functionality scheduled in later phases
-- Do NOT flag missing features that are out of scope for this phase
-- If unsure whether something belongs to this phase, check the plan file
+- `APPROVE`: Fix and regression test are in good shape; builder can proceed to PR creation.
+- `REQUEST_CHANGES`: Real BUGFIX-relevant issues (fix doesn't resolve the symptom, missing regression test without justification, scope creep, broken existing tests, etc.).
+- `COMMENT`: Minor suggestions; builder can proceed but should consider the feedback.
 
 ## Notes
 
-- This is a phase-level review, not the final PR review
-- Focus on "does this phase work" not "is the whole feature done"
-- If referencing line numbers, use `file:line` format
-- The builder needs actionable feedback to continue
+- This is an implementation-level review, not the final PR review.
+- Focus on "does this fix actually resolve the issue, and is it protected by a regression test" — not on artifacts from other protocols.
+- If referencing line numbers, use `file:line` format.
+- The builder needs actionable, protocol-correct feedback to continue.

package/skeleton/protocols/bugfix/consult-types/pr-review.md

@@ -1,36 +1,59 @@
-# PR Ready Review Prompt
+# PR Ready Review Prompt (BUGFIX)
 
 ## Context
-You are performing a final self-check during the Review phase. The builder has completed all implementation phases and is about to create a PR. This is the last check before the work goes to the architect for integration review.
+You are performing a final self-check during the PR phase of the **BUGFIX protocol**. The builder has investigated a GitHub Issue, implemented a focused fix, and added a regression test. They are about to create — or have just created — a PR for the architect's integration review.
+
+**BUGFIX is not SPIR.** Do **not** review against the SPIR three-document trinity. The artifacts of a BUGFIX project are:
+- The originating **GitHub Issue** (serves as the spec)
+- The **code fix** (minimal, focused on root cause)
+- A **regression test** that fails without the fix and passes with it
+- The **PR body** (Summary, Root Cause, Fix, Test Plan)
+
+There is **no `codev/specs/`, `codev/plans/`, or `codev/reviews/` file** for a BUGFIX, and there should not be one. The commit format is `Fix #NNNN: <description>` (or `[Bugfix #NNNN] ...`), **not** `[Spec NNNN][Phase]`.
 
 ## Focus Areas
 
-1. **Completeness**
-   - Are all spec requirements implemented?
-   - Are all plan phases complete?
-   - Is the review document written (`codev/reviews/XXXX-name.md`)?
-   - Are all commits properly formatted (`[Spec XXXX][Phase]`)?
-
-2. **Test Status**
-   - Do all tests pass?
-   - Is test coverage adequate for the changes?
-   - Are there any skipped or flaky tests?
-
-3. **Code Cleanliness**
-   - Is there any debug code left in?
-   - Are there any TODO comments that should be resolved?
-   - Are there any `// REVIEW:` comments that weren't addressed?
-   - Is the code properly formatted?
-
-4. **Documentation**
-   - Are inline comments clear where needed?
-   - Is the review document comprehensive?
-   - Are any new APIs documented?
-
-5. **PR Readiness**
-   - Is the branch up to date with main?
-   - Are commits atomic and well-described?
-   - Is the change diff reasonable in size?
+1. **Issue Resolution**
+   - Does the fix actually resolve the symptom described in the issue?
+   - Does the PR body include `Fixes #<N>` so the issue auto-closes on merge?
+   - Does the PR description cover: Summary, Root Cause, Fix, Test Plan?
+
+2. **Regression Test**
+   - Is there a regression test that targets the exact scenario from the issue?
+   - Would the test fail without the fix? (If reviewers can't tell, ask the builder to demonstrate.)
+   - Is the test deterministic (not flaky)?
+   - If the fix is documentation-only or otherwise truly untestable, has the builder explicitly justified the absence of a test?
+
+3. **Scope Discipline**
+   - Is the change focused on the root cause? No unrelated refactors, no drive-by fixes for other bugs.
+   - Is the net diff under ~300 LOC (additions + deletions, excluding generated/lockfiles)?
+   - If the scope grew beyond a bugfix, should the builder have escalated to SPIR/TICK instead?
+
+4. **Code Cleanliness**
+   - No debug code, `console.log`, or commented-out blocks left behind.
+   - No stray TODOs introduced by this fix.
+   - Code follows existing project conventions.
+
+5. **Test Status**
+   - All existing tests pass.
+   - Build passes.
+   - No new flaky tests introduced.
+
+6. **PR Hygiene**
+   - Commits use the BUGFIX format: `Fix #<N>: ...` or `[Bugfix #<N>] ...` (**not** `[Spec NNNN][Phase]`).
+   - Branch is up to date with main (or close enough for clean merge).
+   - PR is linked to the issue.
+
+## Out of Scope (Do NOT request changes for)
+
+The following are **not** part of the BUGFIX protocol and must **not** be cited as REQUEST_CHANGES reasons:
+
+- Missing `codev/specs/<N>-*.md` — BUGFIX has no spec; the GitHub Issue is the spec.
+- Missing `codev/plans/<N>-*.md` — BUGFIX has no plan.
+- Missing `codev/reviews/<N>-*.md` — BUGFIX has no review document; review lives in the PR body.
+- Commit format `[Spec NNNN][Phase]` — BUGFIX intentionally uses `Fix #N:` / `[Bugfix #N]`.
+- `status.yaml` fields like `build_complete: false` — porch manages `status.yaml`; the builder is **forbidden** from editing it directly. Treat porch state as informational, not a fixable issue.
+- Phase-scoping concerns — BUGFIX is a single-phase protocol; there are no plan phases to scope against.
 
 ## Verdict Format
 
@@ -49,24 +72,26 @@ KEY_ISSUES:
 
 PR_SUMMARY: |
   ## Summary
-  [2-3 sentences describing what this PR does]
+  Fixes #<N>. [1-2 sentences on what was fixed.]
+
+  ## Root Cause
+  [Brief explanation of what caused the bug]
 
-  ## Key Changes
-  - [Change 1]
-  - [Change 2]
+  ## Fix
+  [Brief explanation of the fix]
 
   ## Test Plan
-  - [How to test]
+  - [Regression test description]
+  - [Manual verification, if applicable]
 ```
 
 **Verdict meanings:**
-- `APPROVE`: Ready to create PR
-- `REQUEST_CHANGES`: Issues to fix before PR creation
-- `COMMENT`: Minor items, can create PR but note feedback
+- `APPROVE`: Bug is resolved, regression test is in place, PR is ready for architect review.
+- `REQUEST_CHANGES`: Real BUGFIX-relevant issues to fix (missing regression test, fix doesn't resolve the symptom, scope creep, etc.).
+- `COMMENT`: Minor items, can proceed but note feedback.
 
 ## Notes
 
-- This is the builder's final self-review before hand-off
-- The PR_SUMMARY in your output can be used as the PR description
-- Focus on "is this ready for someone else to review" not "is this perfect"
-- Any issues found here are cheaper to fix than during integration review
+- This is the builder's final self-review before hand-off to the architect.
+- The `PR_SUMMARY` block can be used directly as the PR description.
+- Focus on "is this bug actually fixed and protected by a test" — not on artifacts from other protocols.

package/skeleton/protocols/spir/builder-prompt.md

@@ -30,6 +30,12 @@ You are running in STRICT mode. This means:
 Follow the SPIR protocol: `codev/protocols/spir/protocol.md`
 Read and internalize the protocol before starting any work.
 
+## Baked Decisions
+
+If the issue body contains a section named "Baked Decisions" (any heading level, case-insensitive), treat its contents as fixed architectural decisions baked in by the architect. Do not autonomously override them in your spec, plan, or implementation. If you discover a serious reason to question a baked decision, surface that concern to the architect via `afx send` rather than relitigating it inside the spec/plan/review.
+
+If the architect's baked-decisions section contains internal contradictions (e.g., two different language choices), do not pick one — pause, flag the contradiction to the architect via `afx send`, and wait for resolution before proceeding.
+
 {{#if spec}}
 ## Spec
 Read the specification at: `{{spec.path}}`
@@ -53,13 +59,23 @@ Follow the implementation plan at: `{{plan.path}}`
 {{task_text}}
 {{/if}}
 
-## Multi-PR Workflow
+## PR Strategy
+
+**Do not autonomously open a PR per implementation phase.** Plan phases ship as git commits within a single PR, not as separate PRs. The plan's instruction that "each phase commits independently" refers to git commits, not PRs.
+
+By default, the PR is opened during/after the final implement phase, with all phase-commits already on the branch.
+
+### Architect-requested PRs
+
+The architect MAY request a PR at any point — for spec review, mid-implementation feedback, slicing a large spec into shippable PRs, etc. When the architect explicitly asks for a PR earlier (or for additional PRs), follow that direction. The prohibition is specifically on the *builder* autonomously deciding to open per-phase PRs without architect request.
+
+### Multi-PR Mechanics (when the architect requests sequential PRs)
 
-Your worktree is persistent — it survives across PR merges. You can produce multiple PRs sequentially:
+Your worktree is persistent — it survives across PR merges. When the architect asks for sequential PRs (e.g., to slice a large spec into shippable pieces), use this loop:
 
 1. Cut a branch, open a PR, wait for merge
 2. After merge: `git fetch origin main && git checkout -b <next-branch> origin/main`
-3. Continue to the next phase, open another PR
+3. Continue to the next slice, open another PR
 4. Repeat
 
 **Important**: Do NOT run `git checkout main` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/main` via fetch.

package/skeleton/protocols/spir/consult-types/plan-review.md

@@ -3,6 +3,12 @@
 ## Context
 You are reviewing an implementation plan during the Plan phase. The spec has been approved - now you must evaluate whether the plan adequately describes HOW to implement it.
 
+## Baked Decisions
+
+If the issue body or the approved spec's Constraints section includes content under a "Baked Decisions" heading, the architect has marked those choices as fixed (this extends the existing "don't re-litigate spec decisions" rule with explicit baked-decision language). Do not autonomously challenge them: do not propose alternative languages, frameworks, deployment shapes, or dependencies that contradict a baked decision. You may `COMMENT` with concerns; reserve `REQUEST_CHANGES` for the case where the plan **fails to honor** a stated baked decision — that is a real defect.
+
+If the baked decisions themselves contain contradictions, do not pick one — `REQUEST_CHANGES` and ask the architect to clarify before proceeding.
+
 ## Focus Areas
 
 1. **Spec Coverage**

package/skeleton/protocols/spir/consult-types/spec-review.md

@@ -3,6 +3,12 @@
 ## Context
 You are reviewing a feature specification during the Specify phase. Your role is to ensure the spec is complete, correct, and feasible before it moves to human approval.
 
+## Baked Decisions
+
+If the issue body or the spec's Constraints section includes content under a "Baked Decisions" heading, the architect has marked those choices as fixed. Do not autonomously challenge them: do not propose alternative languages, frameworks, deployment shapes, or dependencies that contradict a baked decision. You may `COMMENT` with concerns about a baked decision (the architect decides whether to rescind it); reserve `REQUEST_CHANGES` for the case where the spec **fails to honor** a stated baked decision — that is a real defect.
+
+If the baked decisions themselves contain contradictions (e.g., two different language choices), do not pick one — `REQUEST_CHANGES` and ask the architect to clarify before proceeding.
+
 ## Focus Areas
 
 1. **Completeness**

package/skeleton/protocols/spir/prompts/specify.md

@@ -31,6 +31,12 @@ ls codev/specs/{{project_id}}-*.md
 
 **If no spec exists:** Proceed to Step 1 below.
 
+### 0.5 Baked Decisions
+
+Before exploring solution approaches, check the issue body for a section named "Baked Decisions" (any heading level, case-insensitive). If present, copy its content verbatim into the spec's Constraints section and treat each item as fixed. Do not autonomously relitigate the architect's choices in your Solution Exploration. If you discover a serious problem with a baked decision, raise it via `afx send architect` rather than overriding it in the spec.
+
+If two baked decisions contradict each other (e.g., two different language choices), do not pick one — pause, flag the contradiction via `afx send`, and wait for resolution before drafting.
+
 ### 1. Clarifying Questions (ONLY IF NO SPEC EXISTS)
 
 Before writing anything, ask clarifying questions to understand:

package/skeleton/protocols/spir/protocol.md

@@ -79,6 +79,10 @@ Each phase follows a build-verify loop: build the artifact, then verify with 3-w
 - Dependency updates
 - Emergency hotfixes (but do a lightweight retrospective after)
 
+## Baked Decisions (Optional)
+
+When filing an issue for SPIR, you can pin architectural decisions you don't want the builder or CMAP reviewers to re-litigate. Include a `## Baked Decisions` section (any heading level is fine) anywhere in the issue body. Useful categories: language, framework, deployment shape, key dependencies, decisions deferred to a later spec. The builder will copy the section verbatim into the spec's Constraints and treat each item as fixed; CMAP reviewers will not propose alternatives unless the spec itself fails to honor a stated decision. Leave the section out for issues where you want the builder to explore freely — absence is the no-op default. You can amend or rescind a baked decision at any time by updating the issue and respawning, or by sending the builder a direct instruction via `afx send`.
+
 ## Protocol Phases
 
 ### S - Specify (Collaborative Design Exploration)