[Bugfix #1279] Deliver every protocol template via a {{> }} include, and enforce it

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

@@ -32,6 +32,12 @@ If the baked decisions themselves contain contradictions (e.g., two different la
    - Are acceptance criteria testable?
    - Is terminology consistent?
 
+5. **Structure**
+   - The specify prompt delivers a canonical spec template (`protocols/spir/templates/spec.md`) inline. Does the spec actually follow it?
+   - Required headings, in order: `## Metadata`, `## Clarifying Questions Asked`, `## Problem Statement`, `## Current State`, `## Desired State`, `## Stakeholders`, `## Success Criteria`, `## Constraints`, `## Assumptions`, `## Solution Approaches`, `## Open Questions`, `## Performance Requirements`, `## Security Considerations`, `## Test Scenarios`, `## Dependencies`, `## References`, `## Risks and Mitigation`, `## Expert Consultation`, `## Approval`, `## Notes`.
+   - A free-form spec that reads well but ignores the template is a **defect**, not a style preference — it usually means the builder pattern-matched an older spec in `codev/specs/` instead of the delivered template. `REQUEST_CHANGES` for a wholesale departure (most headings missing or renamed).
+   - A section that genuinely does not apply may be reduced to a one-line "N/A — [reason]", but the heading should remain. Do not `REQUEST_CHANGES` over one such section.
+
 ## Verdict Format
 
 After your review, provide your verdict in exactly this format:

codev-skeleton/protocols/aspir/prompts/review.md

@@ -57,55 +57,9 @@ Compare final implementation to original specification:
 
 ### 3. Create Review Document
 
-Create `codev/reviews/{{artifact_name}}.md`:
+Create `codev/reviews/{{artifact_name}}.md`, following the template below. Use these headings and this order — do not invent your own structure, and do not pattern-match an earlier review in `codev/reviews/` that predates this template. Steps 3b and 4 below expand on the `## Consultation Feedback`, `## Architecture Updates`, and `## Lessons Learned Updates` sections; porch's review checks grep for the last two by exact heading.
 
-```markdown
-# Review: {{title}}
-
-## Summary
-Brief description of what was implemented.
-
-## Spec Compliance
-- [x] Requirement 1: Implemented as specified
-- [x] Requirement 2: Implemented with deviation (see below)
-- [x] Requirement 3: Implemented as specified
-
-## Deviations from Plan
-- **Phase X**: [What changed and why]
-
-## Lessons Learned
-
-### What Went Well
-- [Positive observation 1]
-- [Positive observation 2]
-
-### Challenges Encountered
-- [Challenge 1]: [How it was resolved]
-- [Challenge 2]: [How it was resolved]
-
-### What Would Be Done Differently
-- [Insight 1]
-- [Insight 2]
-
-### Methodology Improvements
-- [Suggested improvement to SPIR protocol]
-- [Suggested improvement to tooling]
-
-## Technical Debt
-- [Any shortcuts taken that should be addressed later]
-
-## Consultation Feedback
-
-[See instructions below]
-
-## Flaky Tests
-- [Any pre-existing tests that were skipped as flaky during this project]
-- [Include test name, file path, and observed failure mode]
-- [If none: "No flaky tests encountered"]
-
-## Follow-up Items
-- [Any items identified for future work]
-```
+{{> protocols/spir/templates/review.md}}
 
 ### 3b. Include Consultation Feedback
 

codev-skeleton/protocols/aspir/prompts/specify.md

@@ -90,6 +90,10 @@ After completing the spec draft, signal completion. Porch will run 3-way consult
 
 Create or update the specification file at `codev/specs/{{artifact_name}}.md`.
 
+Follow the canonical spec template reproduced below. Use these headings, in this order — do not invent your own structure, and do not pattern-match an earlier spec in `codev/specs/` that predates this template. If a section genuinely does not apply, keep the heading and write a one-line "N/A — [reason]" rather than deleting it.
+
+{{> protocols/spir/templates/spec.md}}
+
 **IMPORTANT**: Keep spec/plan/review filenames in sync:
 - Spec: `codev/specs/{{artifact_name}}.md`
 - Plan: `codev/plans/{{artifact_name}}.md`

codev-skeleton/protocols/aspir/protocol.json

@@ -23,6 +23,16 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
+      "checks": {
+        "spec_exists": {
+          "command": "test -f codev/specs/${PROJECT_TITLE}.md",
+          "description": "Spec file must exist before the spec-approval gate"
+        },
+        "spec_has_required_sections": {
+          "command": "grep -qF '## Problem Statement' codev/specs/${PROJECT_TITLE}.md && grep -qF '## Current State' codev/specs/${PROJECT_TITLE}.md && grep -qF '## Desired State' codev/specs/${PROJECT_TITLE}.md && grep -qF '## Success Criteria' codev/specs/${PROJECT_TITLE}.md",
+          "description": "Spec must follow the canonical template delivered by the specify prompt (protocols/spir/templates/spec.md). Required headings: ## Problem Statement, ## Current State, ## Desired State, ## Success Criteria"
+        }
+      },
       "max_iterations": 3,
       "on_complete": {
         "commit": true,

codev-skeleton/protocols/aspir/protocol.md

@@ -21,7 +21,7 @@ This means the builder proceeds automatically from Specify → Plan → Implemen
 | Phases | Specify → Plan → Implement → Review | Same |
 | 3-way consultations | Yes, every phase | Same |
 | Checks (build, tests, PR) | Yes | Same |
-| Prompts / templates | Full set | Same (copied from SPIR) |
+| Prompts / templates | Full set | Same prompts; templates included from SPIR (no copies) |
 
 ### When to Use ASPIR
 
@@ -83,16 +83,18 @@ codev/protocols/aspir/
 │   ├── plan.md            # Plan phase prompt (same as SPIR)
 │   ├── implement.md       # Implement phase prompt (same as SPIR)
 │   └── review.md          # Review phase prompt (same as SPIR)
-├── consult-types/
-│   ├── spec-review.md     # Spec consultation guide (same as SPIR)
-│   ├── plan-review.md     # Plan consultation guide (same as SPIR)
-│   ├── impl-review.md     # Impl consultation guide (same as SPIR)
-│   ├── phase-review.md    # Phase consultation guide (same as SPIR)
-│   └── pr-review.md       # PR consultation guide (same as SPIR)
-└── templates/
-    ├── spec.md            # Spec template (same as SPIR)
-    ├── plan.md            # Plan template (same as SPIR)
-    └── review.md          # Review template (same as SPIR)
+└── consult-types/
+    ├── spec-review.md     # Spec consultation guide (same as SPIR)
+    ├── plan-review.md     # Plan consultation guide (same as SPIR)
+    ├── impl-review.md     # Impl consultation guide (same as SPIR)
+    ├── phase-review.md    # Phase consultation guide (same as SPIR)
+    └── pr-review.md       # PR consultation guide (same as SPIR)
 ```
 
+ASPIR ships **no `templates/` directory**. Its phase prompts deliver SPIR's canonical
+templates directly, via an include directive pointing at `protocols/spir/templates/`, so
+there is exactly one copy of each template and it cannot drift between the two protocols.
+(Written as a path, not as a literal include: an include directive in prose would be
+expanded — and silently emptied — when this file is delivered to a builder.)
+
 All files except `protocol.json` and `protocol.md` are identical to their SPIR counterparts.