@cluesmith/codev 3.0.0 → 3.0.1

package/skeleton/protocols/maintain/templates/maintenance-run.md

@@ -1,64 +1,33 @@
-# Maintenance Run NNN
+# Maintenance Run NNNN
 
-## Metadata
-- **Date**: YYYY-MM-DD
-- **Base Commit**: (commit hash at start)
-- **PR**: #NNN
-- **Scope**: full | code-only | docs-only
+**Date**: YYYY-MM-DD
+**Base Commit**: <hash>
+**PR**: #NNN
 
 ## Changes Since Last Run
 
-<!-- Auto-generated summary of commits since last maintenance -->
+<key commits or summary>
 
-```
-git log --oneline <last-maint-commit>..HEAD
-```
+## What Was Done
 
-## Tasks Completed
+### Dead Code Removed
+- <file>: <item> — <reason>
 
-### Code Hygiene
-- [ ] Dead code removal
-- [ ] Unused dependencies
-- [ ] Dependency updates
-- [ ] Test maintenance
+### Dependencies Cleaned
+- <package> — <reason>
 
-### Documentation
-- [ ] arch.md sync
-- [ ] lessons-learned.md generation
-- [ ] CLAUDE.md / AGENTS.md sync
-- [ ] Documentation pruning (obsolete content, size limits)
+### Documentation Updated
+- arch.md: <what changed>
+- lessons-learned.md: <what changed>
 
-### Framework
-- [ ] codev update
-- [ ] GitHub Issue status updates (close completed, update labels)
-
-## Findings
-
-<!-- Notable discoveries during maintenance -->
-
-## Documentation Changes
-
-<!-- REQUIRED: Log all documentation deletions/moves with justification -->
-
-### arch.md
-| Section | Action | Reason |
-|---------|--------|--------|
-| (example) | KEPT/MOVED/DELETED | (justification) |
-
-### CLAUDE.md
-| Section | Action | Reason |
-|---------|--------|--------|
-| (example) | KEPT/MOVED/DELETED | (justification) |
-
-### README.md
-| Section | Action | Reason |
-|---------|--------|--------|
-| (example) | KEPT/MOVED/DELETED | (justification) |
+### Documentation Changes Log
+| Document | Section | Action | Reason |
+|----------|---------|--------|--------|
 
 ## Deferred
 
-<!-- Items discovered but deferred to next run, with reason -->
+- <items found but not fixed, with reason>
 
 ## Summary
 
-<!-- Brief summary of what was accomplished -->
+<2-3 sentences>

package/skeleton/protocols/protocol-schema.json

@@ -8,7 +8,7 @@
   "properties": {
     "name": {
       "type": "string",
-      "description": "Protocol identifier (e.g., 'spir', 'tick', 'bugfix')"
+      "description": "Protocol identifier (e.g., 'spir', 'bugfix', 'air')"
     },
     "version": {
       "type": "string",

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

@@ -0,0 +1,85 @@
+# {{protocol_name}} Builder ({{mode}} mode)
+
+You are conducting multi-agent research.
+
+{{#if mode_soft}}
+## Mode: SOFT
+You are running in SOFT mode. This means:
+- You follow the RESEARCH protocol yourself (no porch orchestration)
+- The architect monitors your work and verifies you're adhering to the protocol
+- Use `consult` for the 3-way investigation and critique phases
+{{/if}}
+
+{{#if mode_strict}}
+## Mode: STRICT
+You are running in STRICT mode. This means:
+- Porch orchestrates your work
+- Run: `porch next` to get your next tasks
+- Follow porch signals and gate approvals
+
+### ABSOLUTE RESTRICTIONS (STRICT MODE)
+- **NEVER edit `status.yaml` directly** — only porch commands may modify project state
+- **NEVER call `porch approve` without explicit human approval** — only run it after the architect says to
+- **NEVER skip the 3-way consultation** — always follow porch next → porch done cycle
+{{/if}}
+
+## Protocol
+Follow the RESEARCH protocol: `codev/protocols/research/protocol.md`
+
+## RESEARCH Overview
+
+The RESEARCH protocol produces a high-confidence research report through triangulation:
+
+1. **Scope** — Define the precise question, scope, and acceptance criteria. Write a research brief. Gate: architect approval before proceeding.
+2. **Investigate** — Dispatch the brief to 3 models (Gemini, Codex, Claude) in parallel. Each investigates independently. No anchoring — they don't see each other's work.
+3. **Synthesize** — Read all 3 reports. Identify consensus, disagreements, and unique contributions. Write a single synthesis report organized by topic (not by model).
+4. **Critique** — Send the synthesis back to all 3 models for critique. Incorporate valid feedback. Document rejected critique. Finalize the report.
+
+## Output Location
+
+All artifacts go to `codev/research/`:
+- `<topic>-brief.md` — the scoped question (Phase 1)
+- `<topic>-gemini.md`, `<topic>-codex.md`, `<topic>-claude.md` — individual investigations (Phase 2)
+- `<topic>.md` — the final synthesis report (Phase 3+4, this is the deliverable)
+- `<topic>-critique-rebuttals.md` — critique responses (Phase 4)
+
+{{#if task}}
+## Research Topic
+{{task_text}}
+{{/if}}
+
+## Key Principles
+
+- **Triangulate**: consensus across 3 models > any single model's claim
+- **Cite sources**: tell investigators to provide sources where possible
+- **Be candid about uncertainty**: "I don't know" > confabulation
+- **Organize by topic, not by model**: the synthesis is a standalone document
+- **Note surprises**: the most valuable findings are often unexpected
+- **Keep it concise**: the synthesis should be shorter than the sum of the investigations
+
+## Using consult for 3-way Investigation
+
+For the investigate phase, use the `consult` CLI to dispatch to each model:
+
+```bash
+# Phase 2: parallel investigation
+consult -m gemini --prompt-file codev/research/<topic>-brief.md --output codev/research/<topic>-gemini.md &
+consult -m codex --prompt-file codev/research/<topic>-brief.md --output codev/research/<topic>-codex.md &
+consult -m claude --prompt-file codev/research/<topic>-brief.md --output codev/research/<topic>-claude.md &
+wait
+```
+
+For the critique phase:
+```bash
+# Phase 4: parallel critique
+consult -m gemini --prompt "Critique this research synthesis for gaps, errors, and bias:" --prompt-file codev/research/<topic>.md --output codev/research/<topic>-critique-gemini.md &
+consult -m codex --prompt "Critique this research synthesis for gaps, errors, and bias:" --prompt-file codev/research/<topic>.md --output codev/research/<topic>-critique-codex.md &
+consult -m claude --prompt "Critique this research synthesis for gaps, errors, and bias:" --prompt-file codev/research/<topic>.md --output codev/research/<topic>-critique-claude.md &
+wait
+```
+
+## Getting Started
+1. Read the RESEARCH protocol document
+2. Understand the research question from the architect
+3. Write the research brief (Phase 1)
+4. Wait for scope-approval before proceeding to investigation

package/skeleton/protocols/research/protocol.json

@@ -0,0 +1,118 @@
+{
+  "$schema": "../../protocol-schema.json",
+  "name": "research",
+  "version": "1.0.0",
+  "description": "Multi-agent research with 3-way investigation, synthesis, and critique",
+  "input": {
+    "type": "none",
+    "required": false,
+    "default_for": []
+  },
+  "hooks": {
+    "pre-spawn": {}
+  },
+  "phases": [
+    {
+      "id": "scope",
+      "name": "Scope",
+      "description": "Define the research question, scope, and acceptance criteria",
+      "type": "once",
+      "steps": [
+        "clarify_question",
+        "define_scope",
+        "define_acceptance_criteria",
+        "create_research_brief"
+      ],
+      "gate": {
+        "name": "scope-approval",
+        "description": "Architect confirms the research question is correctly scoped",
+        "requires": ["research_brief_exists"],
+        "next": "investigate"
+      }
+    },
+    {
+      "id": "investigate",
+      "name": "Investigate",
+      "description": "3-way parallel investigation — each model researches independently",
+      "type": "once",
+      "steps": [
+        "dispatch_gemini_investigation",
+        "dispatch_codex_investigation",
+        "dispatch_claude_investigation",
+        "collect_all_reports"
+      ],
+      "consultation": {
+        "enabled": true,
+        "models": ["codex"],
+        "parallel": true,
+        "type": "investigation"
+      },
+      "transition": {
+        "on_complete": "synthesize"
+      }
+    },
+    {
+      "id": "synthesize",
+      "name": "Synthesize",
+      "description": "Merge the 3 investigation reports into a single coherent research document",
+      "type": "once",
+      "steps": [
+        "read_all_investigation_reports",
+        "identify_consensus_and_disagreements",
+        "resolve_conflicts",
+        "write_synthesis_report"
+      ],
+      "transition": {
+        "on_complete": "critique"
+      }
+    },
+    {
+      "id": "critique",
+      "name": "Critique",
+      "description": "3-way review of the synthesis — each model critiques for gaps, errors, and bias",
+      "type": "once",
+      "steps": [
+        "dispatch_gemini_critique",
+        "dispatch_codex_critique",
+        "dispatch_claude_critique",
+        "incorporate_feedback",
+        "finalize_report"
+      ],
+      "consultation": {
+        "enabled": true,
+        "models": ["codex"],
+        "parallel": true,
+        "type": "critique"
+      },
+      "gate": {
+        "name": "research-complete",
+        "description": "Research report finalized",
+        "requires": ["report_finalized"],
+        "next": null
+      }
+    }
+  ],
+  "signals": {
+    "PHASE_COMPLETE": {
+      "description": "Signal current phase is complete",
+      "transitions_to": "next_phase"
+    },
+    "BLOCKED": {
+      "description": "Signal research is blocked",
+      "requires": "reason"
+    },
+    "SCOPE_REJECTED": {
+      "description": "Architect rejects the scope — rework needed",
+      "transitions_to": "scope"
+    }
+  },
+  "defaults": {
+    "mode": "strict",
+    "consultation": {
+      "enabled": true,
+      "models": ["codex"],
+      "parallel": true
+    },
+    "checks": {}
+  }
+}

package/skeleton/protocols/research/protocol.md

@@ -0,0 +1,169 @@
+# RESEARCH Protocol
+
+## Overview
+
+Multi-agent research with 3-way investigation, synthesis, and critique. Three AI models independently investigate a question, their findings are synthesized into a single report, and then all three models critique the synthesis for gaps, errors, and bias.
+
+**Core Principle**: Triangulate. No single model's knowledge is authoritative. Consensus across models is more reliable than any individual output.
+
+## When to Use
+
+**Use for**: Competitive analysis, technology evaluation, market research, architectural decision support, "what's the state of X?" questions, exploring unfamiliar domains.
+
+**Skip for**: Implementation work (use SPIR/ASPIR), quick questions (just ask), experiments (use EXPERIMENT), known-answer lookups (just search).
+
+## Output
+
+All research artifacts go to `codev/research/`. The final deliverable is a single synthesis report at `codev/research/<topic>.md`.
+
+## Phases
+
+### Phase 1: Scope
+
+**Purpose**: Make sure we're asking the right question before spending 3 models' worth of compute on answering it.
+
+The builder:
+1. Reads the architect's research request
+2. Clarifies the question — what specifically are we trying to learn?
+3. Defines the scope — what's in, what's out, what depth is needed
+4. Defines acceptance criteria — what does a good answer look like?
+5. Writes a **research brief** (`codev/research/<topic>-brief.md`) with:
+   - The precise question(s)
+   - Scope boundaries
+   - **Required targets** (when applicable — not all research questions have them). When the user names specific projects, products, or systems, those are exemplars of a CLASS, not an exhaustive list. The brief should:
+     - List the named targets as required coverage (each gets a dedicated section)
+     - Identify the CLASS they represent (e.g., "open-source always-on agent frameworks")
+     - Instruct investigators to find OTHER members of that class the user didn't name — discovering what the user SHOULD be thinking about is often the most valuable part of the research
+     - If an investigator cannot find information about a required target, they must say so explicitly — not silently skip it
+   - **Optional context** — additional sources that may be useful but are not required
+   - What a useful answer looks like
+   - Suggested sources or angles for the investigators
+6. Sends the brief to the architect for approval
+
+**Gate**: `scope-approval` — the architect confirms the question is correctly scoped before the 3-way investigation begins. This prevents wasting compute on a badly-framed question.
+
+### Phase 2: Investigate (3-way parallel)
+
+**Purpose**: Get three independent perspectives on the question.
+
+The builder dispatches the research brief to three models (Gemini, Codex, Claude) via `consult`. Each model:
+1. Receives the scoped research brief
+2. Independently investigates using web search, its training knowledge, and reasoning
+3. Produces a standalone investigation report with:
+   - **A dedicated section for each required target** from the brief. Every required target gets its own heading with specific findings — not mentioned in passing, not substituted with an easier target. If a required target yields no findings, the section must say "No information found" rather than being omitted.
+   - Findings (with sources where possible)
+   - Confidence levels on key claims
+   - Gaps it couldn't fill
+   - Surprises or things that contradicted expectations
+
+The investigations run in **parallel** — each model works independently without seeing the others' output. This prevents anchoring bias.
+
+Investigation reports are saved to:
+- `codev/research/<topic>-gemini.md`
+- `codev/research/<topic>-codex.md`
+- `codev/research/<topic>-claude.md`
+
+### Phase 3: Synthesize
+
+**Purpose**: Merge three independent reports into one coherent document.
+
+The builder:
+1. Reads all three investigation reports
+2. Identifies **consensus** — what all three agree on (highest confidence)
+3. Identifies **disagreements** — where models contradict each other
+4. Resolves conflicts — picks the best-supported position, notes the disagreement
+5. Identifies **unique contributions** — things only one model found that the others missed
+6. Writes the **synthesis report** (`codev/research/<topic>.md`) with:
+   - **Scope summary** — a short section (before the executive summary) restating the research question, required targets, and scope boundaries from the brief. A reader should understand what was asked without needing to read the brief separately.
+   - Executive summary
+   - Findings (organized by topic, not by model)
+   - Confidence annotations (consensus vs. single-source)
+   - Gaps and limitations
+   - Recommendations (if the research brief asked for them)
+
+The synthesis is written as a **standalone document** — a reader should never need to reference the individual investigation reports. Those are kept as appendices for traceability.
+
+### Phase 4: Critique (3-way review)
+
+**Purpose**: Pressure-test the synthesis for gaps, errors, and bias.
+
+The builder dispatches the synthesis report back to all three models for critique. Each model:
+1. Reads the synthesis
+2. **Checks coverage against the brief** — does every required target from the research brief have dedicated coverage in the synthesis? Lists any required targets that were named in the brief but have zero or minimal coverage. This is the #1 critique check.
+3. Checks for factual errors or unsupported claims
+4. Identifies gaps — important aspects the synthesis missed
+5. Flags potential bias — did the synthesis over-weight one model's perspective?
+6. Suggests specific improvements
+
+The builder then:
+1. Incorporates valid critique
+2. Documents rejected critique with rationale
+3. Finalizes the report
+4. Commits to `codev/research/<topic>.md`
+
+## File Structure
+
+Only the brief and final report are checked in. Individual investigation reports and full critique outputs are working artifacts — useful during the process but not committed to the repo.
+
+```
+codev/research/
+├── <topic>-brief.md              # Phase 1: scoped research question (checked in)
+└── <topic>.md                    # Phase 3+4: final synthesis (the deliverable, checked in)
+```
+
+The final report includes:
+- A **"Disagreements and resolution"** section documenting where the three investigators disagreed and how the synthesis resolved each disagreement
+- A **"Changes from critique"** section summarizing what the critique phase changed (not the full critique — just what was added, removed, or corrected and why)
+
+Individual investigation reports (`<topic>-gemini.md`, `<topic>-codex.md`, `<topic>-claude.md`) and raw critique outputs are kept locally during the research process but NOT committed. The final report is the deliverable; the process artifacts are disposable.
+
+## Best Practices
+
+### Scoping
+- A good research question is specific enough to answer in 1500-3000 words per model
+- "What's the state of X?" is too broad — "What are the top 5 players in X, their strengths/weaknesses, and the structural gaps?" is better
+- Include the "so what" — why are we researching this? What decision does it inform?
+
+### Investigation
+- Tell each model to cite sources where possible
+- Tell each model to be candid about uncertainty — "I don't know" is better than confabulation
+- Tell each model to note surprises — the most valuable findings are often the unexpected ones
+
+### Synthesis
+- Organize by topic, not by model ("here's what we found about X" not "here's what Gemini said")
+- Weight consensus over single-model claims
+- Don't smooth over disagreements — note them explicitly
+- Keep the synthesis shorter than the sum of the investigations
+
+### Critique
+- Critiquers should focus on gaps and errors, not style
+- A critique that says "add more about X" is useful; "rewrite the intro" is not
+- The builder should reject critique that's outside the original scope
+
+## Integration with Other Protocols
+
+### Research → SPIR
+When research informs a feature decision:
+1. Reference the research report in the spec
+2. Link specific findings as evidence for design choices
+
+### Research → EXPERIMENT
+When research identifies something worth testing:
+1. Create an experiment to validate the research finding
+2. Reference the research report as motivation
+
+## Git Workflow
+
+### Commits
+```
+[Research: topic] Scoped research brief
+[Research: topic] 3-way investigation complete
+[Research: topic] Synthesis report
+[Research: topic] Final report (post-critique)
+```
+
+### What to Commit
+- All investigation reports (for traceability)
+- The final synthesis (the deliverable)
+- The critique rebuttals (for process transparency)
+- Do NOT commit raw web search results or intermediate notes

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

@@ -37,7 +37,7 @@ Follow this 3-step workflow. You can skip or reorder steps as the investigation
 - Write findings to `codev/spikes/<id>-<name>.md` using the template
 - Provide a clear feasibility verdict: Feasible / Not Feasible / Feasible with Caveats
 - Commit the findings document
-- Notify the architect: `af send architect "Spike <id> complete. Verdict: [verdict]"`
+- Notify the architect: `afx send architect "Spike <id> complete. Verdict: [verdict]"`
 
 ## Key Principles
 

package/skeleton/protocols/spike/protocol.md

@@ -10,7 +10,7 @@ Time-boxed technical feasibility exploration. Answer "Can we do X?" and "What wo
 
 **Use for**: Quick technical feasibility investigations, proof-of-concept explorations, "can we do X?" questions, evaluating approaches before committing to SPIR
 
-**Skip for**: Production code (use SPIR), formal hypothesis testing (use EXPERIMENT), bug fixes (use BUGFIX), well-understood implementations (use TICK)
+**Skip for**: Production code (use SPIR), formal hypothesis testing (use EXPERIMENT), bug fixes (use BUGFIX)
 
 ### Spike vs Experiment
 
@@ -25,8 +25,8 @@ Time-boxed technical feasibility exploration. Answer "Can we do X?" and "What wo
 ## Spawning a Spike
 
 ```bash
-af spawn --task "Can we use WebSockets for real-time updates?" --protocol spike
-af spawn --task "What would it take to support SQLite FTS?" --protocol spike
+afx spawn --task "Can we use WebSockets for real-time updates?" --protocol spike
+afx spawn --task "What would it take to support SQLite FTS?" --protocol spike
 ```
 
 Spikes are always soft mode — no porch orchestration, no gates, no consultation.
@@ -83,7 +83,7 @@ POC code from the iterate step is committed to the spike branch alongside the fi
 
 In all cases, notify the architect:
 ```bash
-af send architect "Spike <id> complete. Verdict: [feasible/not feasible/caveats]"
+afx send architect "Spike <id> complete. Verdict: [feasible/not feasible/caveats]"
 ```
 
 ## Git Workflow

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

@@ -53,12 +53,35 @@ Follow the implementation plan at: `{{plan.path}}`
 {{task_text}}
 {{/if}}
 
+## Multi-PR Workflow
+
+Your worktree is persistent — it survives across PR merges. You can produce multiple PRs sequentially:
+
+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
+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.
+
+Record PRs in status.yaml: `porch done {{project_id}} --pr <N> --branch <name>`
+Record merges: `porch done {{project_id}} --merged <N>`
+
+## Verify Phase
+
+After the final PR merges, the project enters the **verify** phase. You stay alive through verify:
+1. Pull main into your worktree
+2. Run `porch done {{project_id}}` to signal verification is ready
+3. The architect approves `verify-approval` when satisfied
+
+If verification is not needed: `porch verify {{project_id}} --skip "reason"`
+
 ## Notifications
-Always use `af send architect "..."` to notify the architect at key moments:
-- **Gate reached**: `af send architect "Project {{project_id}}: <gate-name> ready for approval"`
-- **PR ready**: `af send architect "PR #N ready for review (project {{project_id}})"`
-- **PR merged**: `af send architect "Project {{project_id}} complete. PR merged. Ready for cleanup."`
-- **Blocked**: `af send architect "Blocked on project {{project_id}}: [reason]"`
+Always use `afx send architect "..."` to notify the architect at key moments:
+- **Gate reached**: `afx send architect "Project {{project_id}}: <gate-name> ready for approval"`
+- **PR ready**: `afx send architect "PR #N ready for review (project {{project_id}})"`
+- **PR merged**: `afx send architect "Project {{project_id}} PR merged. Entering verify phase."`
+- **Blocked**: `afx send architect "Blocked on project {{project_id}}: [reason]"`
 
 ## Handling Flaky Tests
 

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

@@ -181,11 +181,22 @@ Before PR:
 porch consultation reviews the actual PR, and the architect can review a real PR
 when the pr gate fires.
 
+**PR body requirements**: The PR body MUST include `Closes #<N>` (for feature issues)
+or `Fixes #<N>` (for bug issues) for the driving GitHub issue. If the PR closes
+multiple issues (e.g. duplicates consolidated), include one keyword per issue.
+Without this, GitHub will not auto-close the issue on merge.
+
+**Exception**: if this PR only partially addresses the issue (e.g. one phase of a
+multi-PR effort), DO NOT use `Closes`/`Fixes` — reference the issue with `Refs #<N>`
+or `Part of #<N>` instead. The issue stays open until the follow-up PR closes it.
+
 ```bash
 gh pr create --title "[Spec {{project_id}}] {{title}}" --body "$(cat <<'EOF'
 ## Summary
 [Brief description of the implementation]
 
+Closes #<N>  <!-- Replace <N> with the driving issue number, or use "Refs #<N>" for partial fixes -->
+
 ## Changes
 - [Change 1]
 - [Change 2]

package/skeleton/protocols/spir/protocol.json

@@ -53,7 +53,7 @@
       },
       "checks": {
         "plan_exists": "test -f codev/plans/${PROJECT_TITLE}.md",
-        "has_phases_json": "grep -q '\"phases\":' codev/plans/${PROJECT_TITLE}.md",
+        "has_phases_json": "grep -qE '\"phases\"\\s*:' codev/plans/${PROJECT_TITLE}.md",
         "min_two_phases": "grep -o '\"id\": *\"[^\"]*\"' codev/plans/${PROJECT_TITLE}.md | wc -l | awk '$1 >= 2 {exit 0} {exit 1}'"
       },
       "gate": "plan-approval",
@@ -135,6 +135,14 @@
         }
       },
       "gate": "pr",
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify",
+      "description": "Post-merge environmental verification (optional — skip with porch verify --skip)",
+      "type": "once",
+      "gate": "verify-approval",
       "next": null
     }
   ],

package/skeleton/protocols/spir/protocol.md

@@ -9,10 +9,10 @@
 ## Prerequisites
 
 **Clean Worktree Before Spawning Builders**:
-- All specs, plans, and local changes **MUST be committed** before `af spawn`
+- All specs, plans, and local changes **MUST be committed** before `afx spawn`
 - Builders work in git worktrees branched from HEAD — uncommitted files are invisible
 - This includes `codev update` results, spec drafts, and plan approvals
-- The `af spawn` command enforces this (use `--force` to override)
+- The `afx spawn` command enforces this (use `--force` to override)
 
 **Required for Multi-Agent Consultation**:
 - The `consult` CLI must be available (installed with `npm install -g @cluesmith/codev`)

package/skeleton/protocols/spir/templates/plan.md

@@ -182,23 +182,3 @@ Phase 1 ──→ Phase 2 ──→ Phase 3
 ## Notes
 [Additional context, assumptions, or considerations]
 
----
-
-## Amendment History
-
-This section tracks all TICK amendments to this plan. TICKs modify both the spec and plan together as an atomic unit.
-
-<!-- When adding a TICK amendment, add a new entry below this line in chronological order -->
-
-<!--
-### TICK-001: [Amendment Title] (YYYY-MM-DD)
-
-**Changes**:
-- [Phase added]: [Description of new phase]
-- [Phase modified]: [What was updated]
-- [Implementation steps]: [New steps added]
-
-**Review**: See `reviews/####-name-tick-001.md`
-
----
--->

package/skeleton/protocols/spir/templates/spec.md

@@ -152,31 +152,3 @@ Note: All consultation feedback has been incorporated directly into the relevant
 ## Notes
 [Any additional context or considerations not covered above]
 
----
-
-## Amendments
-
-This section tracks all TICK amendments to this specification. TICKs are lightweight changes that refine an existing spec rather than creating a new one.
-
-<!-- When adding a TICK amendment, add a new entry below this line in chronological order -->
-
-<!--
-### TICK-001: [Amendment Title] (YYYY-MM-DD)
-
-**Summary**: [One-line description of what changed]
-
-**Problem Addressed**:
-[Why this amendment was needed - what gap or issue in the original spec]
-
-**Spec Changes**:
-- [Section modified]: [What changed and why]
-- [New section added]: [Purpose]
-
-**Plan Changes**:
-- [Phase added/modified]: [Description]
-- [Implementation steps]: [What was updated]
-
-**Review**: See `reviews/####-name-tick-001.md`
-
----
--->