[Spec 746] Baked architectural decisions in SPIR issue body

codev-skeleton/protocols/air/builder-prompt.md

@@ -26,6 +26,12 @@ You are running in STRICT mode. This means:
 ## Protocol
 Follow the AIR protocol: `codev/protocols/air/protocol.md`
 
+## 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 issue}}
 ## Issue #{{issue.number}}
 **Title**: {{issue.title}}

codev-skeleton/protocols/air/consult-types/impl-review.md

@@ -10,6 +10,12 @@ Before requesting changes for missing configuration, incorrect patterns, or fram
 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
 
+## Baked Decisions
+
+If the issue body 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 implementation **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. **Issue Adherence**

codev-skeleton/protocols/air/consult-types/pr-review.md

@@ -3,6 +3,12 @@
 ## Context
 You are performing a review of a pull request created under the AIR protocol. The builder implemented a small feature directly from a GitHub issue — there are no spec, plan, or review files. The review is embedded in the PR body.
 
+## Baked Decisions
+
+If the issue body 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 code **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. **Completeness**

codev-skeleton/protocols/air/prompts/implement.md

@@ -6,6 +6,12 @@ You are executing the **IMPLEMENT** phase of the AIR protocol.
 
 Read the GitHub issue, implement the feature, and add tests. Keep it focused and under 300 LOC.
 
+## Baked Decisions
+
+Check the issue body for a section named "Baked Decisions" (any heading level, case-insensitive). If present, treat each listed decision as fixed during implementation. Do not autonomously substitute alternate languages, frameworks, or dependencies. If you discover a serious problem with a baked decision, raise it via `afx send architect` rather than working around it.
+
+If two baked decisions contradict each other, do not pick one — pause, flag the contradiction via `afx send`, and wait for resolution before implementing.
+
 ## Context
 
 - **Issue**: #{{issue.number}} — {{issue.title}}

codev-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

codev-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}}`

codev-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**

codev-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**

codev-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:

codev-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).

codev-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}}`

codev-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**

codev-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**

codev-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:

codev-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)