cleargate 0.14.0 → 0.15.1

package/dist/templates/cleargate-planning/.cleargate/templates/epic.md

@@ -1,166 +0,0 @@
-<instructions>
-FOLLOW THIS EXACT STRUCTURE. Output sections in order.
-YAML Frontmatter: Epic ID, Status, Ambiguity, Context Source, Owner, Target Date.
-§0 Agent Handoff: XML block specifically formulated for AI coding agents to ingest.
-§1 Problem & Value: Why (problem), What (solution), Success Metrics.
-§2 Scope Boundaries: IN-SCOPE checkboxes, OUT-OF-SCOPE list.
-§3 The Reality Check (Context): Constraints table.
-§4 Technical Grounding: Verified files and data changes.
-§5 Acceptance Criteria: Gherkin scenarios (happy path + error cases).
-§6 AI Interrogation Loop: Explicit questions the Planning AI needs the Human to answer.
-Output location: .cleargate/delivery/pending-sync/EPIC-{NNN}_{epic_name}.md
-
-Codebase research is mandatory. Do NOT guess at affected files.
-
-POST-WRITE BRIEF
-After Writing this document, render a Brief in chat with the following sections,
-mechanically extracted from the document's own structure:
-
-  - Prior work       ← cleargate-wiki-query result (cite [[IDs]] or write "none found")
-  - Summary          ← §1 Problem & Value
-  - Open Questions   ← §6 AI Interrogation Loop
-  - Edge Cases       ← §2 OUT-OF-SCOPE list + §5 error scenarios
-  - Risks            ← §3 The Reality Check
-  - Existing Surfaces ← ## Existing Surfaces
-  - Why not simpler? ← ## Why not simpler?
-  - Ambiguity        ← bottom-of-doc ambiguity gate block
-
-Halt for human review. When ambiguity reaches 🟢, proceed to call cleargate_push_item.
-Do NOT ask separately for push confirmation — Brief approval covers it.
-
-Do NOT output these instructions.
-</instructions>
-
----
-epic_id: "EPIC-{ID}"
-parent_cleargate_id: null  # canonical cleargate-id of parent work item; null for top-level
-sprint_cleargate_id: null  # canonical cleargate-id of owning sprint; null for off-sprint items
-carry_over: false  # set true to skip lifecycle reconciliation at sprint close
-status: "Draft"  # lifecycle: Draft → Active → Completed
-ambiguity: "🔴 High"
-context_source: "approved Epic / verified codebase grounding + recorded direct approval"
-owner: "{PM/PO name}"
-target_date: "{YYYY-MM-DD}"
-created_at: "2026-04-17T00:00:00Z"
-updated_at: "2026-04-17T00:00:00Z"
-created_at_version: "strategy-phase-pre-init"
-updated_at_version: "strategy-phase-pre-init"
-server_pushed_at_version: null
-draft_tokens:
-  input: null
-  output: null
-  cache_read: null
-  cache_creation: null
-  model: null
-  sessions: []
-cached_gate_result:
-  pass: null
-  failing_criteria: []
-  last_gate_check: null
-# Sync attribution. Optional; stamped by `cleargate push` / `cleargate pull`.
-pushed_by: null            # set by push: which user pushed
-pushed_at: null            # set by push: ISO-8601 timestamp
-last_pulled_by: null       # set by pull: which user pulled
-last_pulled_at: null       # set by pull: ISO-8601 timestamp
-last_remote_update: null   # set by pull: server's last-modified timestamp
-source: "local-authored"   # flips to "remote-authored" on intake
-last_synced_status: null   # required for conflict-detector; status at last sync
-last_synced_body_sha: null # sha256 of body at last sync
----
-
-# EPIC-{ID}: {Epic Name}
-
-## 0. AI Coding Agent Handoff
-*(This section is strictly for downstream AI execution agents. It contains zero business fluff.)*
-
-```xml
-<agent_context>
-  <objective>{1 sentence strict technical objective}</objective>
-  <architecture_rules>
-    <rule>Must use existing {Component/Pattern}</rule>
-    <rule>No changes to {Protected Area}</rule>
-  </architecture_rules>
-  <target_files>
-    <file path="src/..." action="modify|create" />
-  </target_files>
-</agent_context>
-```
-
-## 1. Problem & Value
-
-**Why are we doing this?**
-{1-2 sentences explaining the user pain or business value.}
-
-**Success Metrics (North Star):**
-- Metric 1: {Quantifiable outcome}
-
-## 2. Scope Boundaries
-
-**✅ IN-SCOPE (Build This)**
-- [ ] {Technical capability 1}
-- [ ] {Technical capability 2}
-
-**❌ OUT-OF-SCOPE (Do NOT Build This)**
-- {Explicitly excluded capability to prevent scope creep / AI hallucination}
-
-## 3. The Reality Check (Context)
-
-| Constraint Type | Limit / Rule |
-|---|---|
-| Performance | {e.g., Must complete in < 200ms} |
-| Security | {e.g., No PII in logs} |
-
-## Existing Surfaces
-
-> L1 reuse audit. List source-tree implementations the epic could extend. Cite file:line.
-
-- **Surface:** `path/to/file.ext:NN` — {what it does}
-- **Coverage of this epic's scope:** {≥80% extension / partial / none — and why}
-
-## Why not simpler?
-
-> L2 / L3 right-size + justify-complexity. Answer both.
-
-- **Smallest existing surface that could carry this epic:** {citation or "none — net-new abstraction required"}
-- **Why isn't extension / parameterization / config sufficient?** {one paragraph}
-
-## 4. Technical Grounding (The "Shadow Spec")
-*(AI Planning Engine: Populate this strictly from the approved Epic and verified codebase grounding.)*
-
-**Affected Files:**
-- `path/to/file.ext` — {Why it changes}
-
-**Data Changes:**
-- Table/Entity: {New column/field}
-
-## 5. Acceptance Criteria
-
-```gherkin
-Feature: {Epic Name}
-  Scenario: {Scenario Name}
-    Given {precondition}
-    When {action}
-    Then {outcome}
-```
-
-## 6. AI Interrogation Loop (Human Input Required)
-*(AI Planning Engine: List edge cases, contradictions, or missing details found while drafting. The Epic stays 🔴 until the Human answers all of these.)*
-
-- **AI Question:** "{e.g., You mentioned we need to send an email, but src/services/email doesn't support templates yet. Should we build the template engine first, or hardcode this one?}"
-- **Human Answer:** {Waiting for user}
-
----
-
-## ClearGate Ambiguity Gate (🟢 / 🟡 / 🔴)
-**Current Status: 🔴 High Ambiguity**
-
-*Evaluate each criterion against its literal text. If you substituted an interpretation, leave the box unchecked and surface the substitution in the Brief.*
-
-Requirements to pass to Green (Ready for Coding Agent):
-- [ ] `approved: true` is set in the YAML frontmatter.
-- [ ] The `<agent_context>` block is complete and validated.
-- [ ] §4 Technical Grounding contains 100% real, verified file paths.
-- [ ] §6 AI Interrogation Loop is empty (all human answers integrated into the spec).
-- [ ] 0 "TBDs" exist in the document.
-- [ ] Existing Surfaces cites at least one source-tree path or explicitly states "none — net-new."
-- [ ] Why not simpler? has both sub-bullets answered.

package/dist/templates/cleargate-planning/.cleargate/templates/hotfix.md

@@ -1,111 +0,0 @@
-<instructions>
-USE THIS TEMPLATE FOR EMERGENCY HOTFIXES ONLY — production anomalies requiring immediate fix outside the sprint cycle. Hotfix discipline: ≤2 files, ≤30 LOC net.
-
-FOLLOW THIS EXACT STRUCTURE. Output sections in order 0.5–4.
-YAML Frontmatter: Hotfix ID, severity, originating signal, lane: "hotfix".
-§0.5 Open Questions: Capture any remaining ambiguity before merge.
-§1 Anomaly: Expected vs. Actual behavior.
-§2 Files Touched: ≤2 files (constraint from EPIC-022 §3).
-§3 Verification Steps: Non-empty before merging (blocks merge if empty).
-§4 Rollback: Git revert instructions.
-Output location: .cleargate/delivery/pending-sync/HOTFIX-{ID}-{Slug}.md
-
-POST-WRITE BRIEF
-After Writing this document, render a Brief in chat with the following sections,
-mechanically extracted from the document's own structure:
-
-  - Prior work    ← cleargate-wiki-query result (cite [[IDs]] or write "none found")
-  - Summary        ← §1 Anomaly (Problem)
-  - Open Questions ← §0.5 Open Questions
-  - Edge Cases     ← §3 Files Affected (risk of adjacent regression)
-  - Risks          ← §4 Verification + risk-of-missing
-  - Ambiguity      ← bottom-of-doc ClearGate Ambiguity Gate block
-
-Halt for human review. When ambiguity reaches 🟢, proceed to call cleargate_push_item.
-Do NOT ask separately for push confirmation — Brief approval covers it.
-
-Do NOT output these instructions.
-</instructions>
-
----
-hotfix_id: "{ID}"
-parent_cleargate_id: null  # canonical cleargate-id of parent work item; null for top-level
-sprint_cleargate_id: null  # canonical cleargate-id of owning sprint; null for off-sprint items
-carry_over: false  # set true to skip lifecycle reconciliation at sprint close
-status: "Draft"  # lifecycle: Draft → In Fix → Completed
-severity: "P2"
-originating_signal: "user-report"
-created_at: "{ISO}"
-created_at_version: "cleargate@0.5.0"
-merged_at: null
-commit_sha: null
-verified_by: null
-lane: "hotfix"
-draft_tokens:
-  input: null
-  output: null
-  cache_read: null
-  cache_creation: null
-  model: null
-  sessions: []
-cached_gate_result:
-  pass: null
-  failing_criteria: []
-  last_gate_check: null
-# Sync attribution. Optional; stamped by `cleargate push` / `cleargate pull`.
-pushed_by: null
-pushed_at: null
-last_pulled_by: null
-last_pulled_at: null
-last_remote_update: null
-source: "local-authored"
-last_synced_status: null
-last_synced_body_sha: null
----
-
-# {ID}: {SLUG}
-
-## 0.5 Open Questions
-
-> Populate during drafting. Resolve every entry before flipping ambiguity to 🟢.
-
-- **Question:** {edge case, contradiction, or missing detail}
-- **Recommended:** {agent's proposed answer}
-- **Human decision:** {populated during Brief review}
-
-## 1. Anomaly
-
-**Expected Behavior:** {What the system should do under normal conditions.}
-
-**Actual Behavior:** {What it is doing now — the observed deviation.}
-
-## 2. Files Touched
-
-Hotfix discipline: ≤2 files, ≤30 LOC net (EPIC-022 §3).
-
-- `{path/to/file.ts}` — {brief description of change}
-
-## 3. Verification Steps
-
-> Rule: §3 must be non-empty before merging. An empty §3 blocks merge at review time.
-
-1. - [ ] {Step 1: describe what to run or observe}
-2. - [ ] {Step 2: confirm the anomaly is resolved}
-3. - [ ] {Step 3: confirm no regression in adjacent behavior}
-
-## 4. Rollback
-
-If the hotfix introduces a regression, revert by running `git revert <commit-sha>` on the sprint or main branch. The original anomaly will reappear; escalate to a sprint story for a permanent fix. No data migrations are involved unless noted in §2 above.
-
----
-
-## ClearGate Ambiguity Gate (🟢 / 🟡 / 🔴)
-**Current Status: 🔴 High Ambiguity**
-
-*Evaluate each criterion against its literal text. If you substituted an interpretation, leave the box unchecked and surface the substitution in the Brief.*
-
-Requirements to pass to Green (Ready for Merge):
-- [ ] Anomaly is deterministically reproducible (§1 filled).
-- [ ] Files Touched list is ≤2 files (§2 filled).
-- [ ] Verification Steps (§3) are non-empty.
-- [ ] `approved: true` is set in the YAML frontmatter.

package/dist/templates/cleargate-planning/.cleargate/templates/initiative.md

@@ -1,122 +0,0 @@
-<instructions>
-USE THIS TEMPLATE TO DOCUMENT WHAT AN INITIATIVE LOOKS LIKE — the BA/PM-authored
-stakeholder-input artifact that captures business intent BEFORE AI decomposition.
-
-WHO AUTHORS THIS: a human BA / PM / sponsor — outside the codebase OR in the upstream
-PM tool (Linear / Jira / GitHub Issues). The AI does NOT author Initiatives from
-scratch in the repo. This template is a cheat sheet for the human author.
-
-HOW IT GETS INTO THE REPO (two paths):
-  1. MCP pull (preferred): `cleargate_pull_initiative` fetches from the upstream PM
-     tool → caches at `.cleargate/delivery/pending-sync/INITIATIVE-NNN_*.md`.
-  2. Manual paste: human drops a markdown file matching this shape into
-     `pending-sync/`. AI stamps `source: manual-paste` then triages.
-
-WHAT THE AI DOES WITH IT:
-  - Reads the cached/pasted Initiative.
-  - Asks open questions in chat.
-  - DECOMPOSES into Epic / Story / CR / Bug — NEVER edits the Initiative body.
-  - On triage completion: moves the Initiative to `archive/INITIATIVE-NNN_*.md`
-    with frontmatter stamps `triaged_at: <ISO-8601>` and
-    `spawned_items: [EPIC-NNN, STORY-NNN-NN, ...]`.
-
-OUTPUT LOCATION: `.cleargate/delivery/pending-sync/INITIATIVE-{NNN}_{short_name}.md`
-
-DO NOT output these instructions in the rendered file.
-</instructions>
-
----
-initiative_id: "INITIATIVE-{NNN}"
-remote_id: null
-source_tool: "linear | jira | github | manual-paste"
-status: "{PM native status — e.g. Discovery, In Triage, Triaged, Completed}"
-synced_at: null
-triaged_at: null
-spawned_items: []
-created_at: "{ISO-8601 timestamp}"
-updated_at: "{ISO-8601 timestamp}"
-created_at_version: "cleargate@{semver}"
-updated_at_version: "cleargate@{semver}"
-server_pushed_at_version: null
-draft_tokens:
-  input: null
-  output: null
-  cache_read: null
-  cache_creation: null
-  model: null
-  sessions: []
-cached_gate_result:
-  pass: null
-  failing_criteria: []
-  last_gate_check: null
-# Sync attribution. Optional; stamped by `cleargate_pull_initiative`.
-pushed_by: null
-pushed_at: null
-last_pulled_by: null
-last_pulled_at: null
-last_remote_update: null
-source: "remote-pulled"        # or "manual-paste"
-last_synced_status: null
-last_synced_body_sha: null
----
-
-# INITIATIVE-{NNN}: {Initiative Name}
-
-## 1. User Flow
-
-{End-to-end walkthrough of what the user does — step-by-step, in plain language.
-Capture the happy path first, then named alternative flows. Diagrams welcome
-(see §2). No technical implementation details — that's the AI's job during
-decomposition.}
-
-## 2. Diagrams
-
-{Embedded mermaid / asciiart / linked image. Optional but encouraged for any
-flow with branching, parallel paths, or multiple actors.
-
-Placeholder:
-```
-[ User ] → [ Action 1 ] → [ Outcome ]
-              ↓
-          [ Branch ]
-```
-}
-
-## 3. End-to-End Verbal Description
-
-{The "tell me what this does" paragraph. 3-8 sentences. Captures the intent,
-the ask, and the boundary of the work. Skim-readable for a stakeholder; rich
-enough that the AI can ground the first round of decomposition questions in it.}
-
-## 4. Business Outcome
-
-{Why this matters. 1-2 sentences linking the work to a business metric, user
-need, or strategic goal. Answers "if this ships, what changes?"}
-
-## 5. Success Criteria
-
-- {Concrete, measurable criterion 1 — what must be true to call this done.}
-- {Concrete, measurable criterion 2}
-- {Concrete, measurable criterion 3 (optional)}
-
-## 6. Open Questions for AI Triage
-
-{Questions the BA/PM knows are unresolved and wants the AI to surface during
-decomposition. The AI MAY answer in chat then propose decomposition; the AI
-does NOT edit this section in the Initiative body.
-
-- Question 1
-- Question 2
-}
-
----
-
-## Stakeholder Authoring Notes (not pushed)
-
-- Initiative is the **stakeholder-input artifact**, not an AI-authored draft.
-  See `.cleargate/knowledge/cleargate-protocol.md` Plan-phase intake (post-CR-025).
-- The AI never invokes `cleargate_push_item` on this file. Push semantics are
-  one-way: Initiative is **pulled**, Epic / Story / CR / Bug / Hotfix are **pushed**.
-- After triage, this file moves to `archive/` with `triaged_at` + `spawned_items`
-  stamped. The PM tool retains source-of-truth for content; the repo retains
-  the audit trail.

package/dist/templates/cleargate-planning/.cleargate/templates/sprint_context.md

@@ -1,50 +0,0 @@
----
-sprint_id: "S-NN"
-created_at: "YYYY-MM-DDTHH:MM:SSZ"
-last_updated: "YYYY-MM-DDTHH:MM:SSZ"
----
-
-# Sprint Context
-
-Per-sprint audit artefact. Populated at sprint init (M1 planning) and re-touched after each story merges. Referenced from every Developer/QA/Architect task brief so all agents start from the same baseline.
-
-## Sprint Goal
-
-_(populated by orchestrator from sprint plan §0 at kickoff)_
-
-## Locked Versions
-
-Frozen dependency versions for this sprint. Orchestrator populates from `package.json` snapshots at sprint init; Developers must not upgrade these mid-sprint without an explicit CR.
-
-| Package | Version |
-|---------|---------|
-| Node    | `>=24.0.0` |
-| TypeScript | `^5.8.0` |
-| (add rows per workspace below) |  |
-
-## Cross-Cutting Rules
-
-Sprint-wide architecture rules and UI/API tokens that every story must honour. Populated from the parent Epic's `<architecture_rules>` block.
-
-1. (rule 1)
-2. (rule 2)
-3. (rule 3)
-
-## Active FLASHCARD Tags
-
-FLASHCARD tags that appear in any story's `<agent_context>` for this sprint. Auto-populated by grepping `.cleargate/FLASHCARD.md` at sprint init. Agents: grep the flashcard file for each tag listed here before starting work.
-
-- `#tag1` — one-line summary of the most recent card
-- `#tag2` — one-line summary
-
-## Adjacent Implementations (Reuse First)
-
-Exported helpers and modules from already-merged stories in this sprint. The Architect updates this section after each story merges. Developers check here before writing new helpers — if the module already exists, import it; duplication is a kick-back criterion.
-
-| Story | Module / Export | Path |
-|-------|----------------|------|
-| (populated as stories merge) | | |
-
-## Mid-Sprint Amendments
-
-_(populated by Architect on CR:scope-change or CR:approach-change; never rewrite, only append. Format: '<ISO-ts> · <ID> · <one-line note>')_

package/dist/templates/cleargate-planning/.cleargate/templates/sprint_report.md

@@ -1,224 +0,0 @@
----
-sprint_id: "SPRINT-NN"
-status: "Draft"
-generated_at: "<ISO-8601>"
-generated_by: "Reporter agent"
-template_version: 2
----
-
-<!-- Sprint Report v2 Template — template_version: 2 -->
-<!-- Event-type vocabulary (STORY-013-05 / protocol §§2–17):
-     User-Review: UR:review-feedback | UR:bug
-     Change-Request: CR:bug | CR:spec-clarification | CR:scope-change | CR:approach-change
-     Circuit-breaker: test-pattern | spec-gap | environment
-     Lane-Demotion: LD
-     These tokens appear verbatim in §2 CR Change Log and §3 Execution Metrics tallies. -->
-
-# SPRINT-<NN> Report: <Sprint Title>
-
-**Status:** Shipped | Partial | Blocked
-**Window:** YYYY-MM-DD to YYYY-MM-DD (N calendar days)
-**Stories:** N planned / M shipped / K carried over
-
----
-
-## §1 What Was Delivered
-
-### User-Facing Capabilities
-<!-- One bullet per user-visible outcome, grouped by business goal. Do NOT list stories here. -->
-- <capability>
-
-### Internal / Framework Improvements
-<!-- Infrastructure, tooling, or agent-contract changes not visible to end users. -->
-- <improvement>
-
-### Carried Over
-<!-- Stories that did not reach Done/Escalated/Parking Lot. If none, state "None." -->
-- None
-
----
-
-## §2 Story Results + CR Change Log
-
-<!-- One block per story. For bounces, list each round-trip as a CR event with the exact token.
-     CR event types: CR:bug | CR:spec-clarification | CR:scope-change | CR:approach-change
-     UR event types: UR:review-feedback | UR:bug
-     Each CR:bug and UR:bug counts toward Bug-Fix Tax (§3). CR:scope-change increments arch_bounces. -->
-
-### STORY-NNN-NN: <Title>
-- **Status:** Completed | Escalated | Parking Lot | Carried Over
-- **Complexity:** L<n>
-- **Commit:** `<sha>`
-- **Bounce count:** qa=N arch=N total=N
-- **CR Change Log:**
-  | # | Event type | Description | Counter delta |
-  |---|---|---|---|
-  | 1 | CR:bug | <description> | qa_bounces +1 |
-- **UR Events:**
-  | # | Event type | Feedback | Tax impact |
-  |---|---|---|---|
-  | 1 | UR:review-feedback | <feedback> | none (enhancement) |
-
----
-
-## §3 Execution Metrics
-
-<!-- Tallies use the locked event-type vocabulary:
-     Bug-Fix Tax = (CR:bug count + UR:bug count) / total story count × 100
-     Enhancement Tax = UR:review-feedback count / total story count × 100
-     First-pass success rate = stories with qa_bounces=0 AND arch_bounces=0 / total stories × 100
-     Token divergence: compare ledger-primary vs task-notification-tertiary; flag if delta >20% -->
-
-| Metric | Value |
-|---|---|
-| Stories planned | N |
-| Stories shipped (Done) | N |
-| Stories escalated | N |
-| Stories carried over | N |
-| Fast-Track Ratio | N% |
-| Fast-Track Demotion Rate | N% |
-| Hotfix Count (sprint window) | N |
-| Hotfix-to-Story Ratio | N |
-| Hotfix Cap Breaches | N |
-| LD events | N |
-| Total QA bounces | N |
-| Total Arch bounces | N |
-| CR:bug events | N |
-| CR:spec-clarification events | N |
-| CR:scope-change events | N |
-| CR:approach-change events | N |
-| UR:bug events | N |
-| UR:review-feedback events | N |
-| Circuit-breaker fires: test-pattern | N |
-| Circuit-breaker fires: spec-gap | N |
-| Circuit-breaker fires: environment | N |
-| **Bug-Fix Tax** | N% |
-| **Enhancement Tax** | N% |
-| **First-pass success rate** | N% |
-| Token source: ledger-primary | N tokens |
-| Token source: story-doc-secondary | N tokens |
-| Token source: task-notification-tertiary | N tokens |
-| Token divergence (ledger vs task-notif) | N% |
-| Token divergence flag (>20%) | YES / NO |
-
----
-
-## §4 Observe Phase Findings
-
-> Populated from sprint plan §4 Execution Log entries dated within the Observe window
-> [last-story-merge-timestamp, sprint-close-timestamp]. Reporter date-filters and groups by event type.
->
-> SKIP THIS SECTION ENTIRELY (no header, no body) if all three subsections are empty.
-> Output a single line in its place: "Observe phase: no findings."
-
-### 4.1 Bugs Found (UR:bug)
-| Date | Description | Resolution | Commit |
-
-### 4.2 Hotfixes Triggered
-| ID | Trigger | Resolution | Commit |
-
-### 4.3 Review Feedback (UR:review-feedback)
-| Date | Description | Status (folded / deferred) | Deferred to / Rationale |
-
----
-
-## §5 Lessons
-
-<!-- Flashcards added during this sprint window, grouped by tag.
-     Preserve the stale-detection pass from reporter.md §5b — stale-candidate symbols
-     from each card are surfaced here for human approval. Do NOT modify FLASHCARD.md. -->
-
-### New Flashcards (Sprint Window)
-
-| Date | Tags | Lesson |
-|---|---|---|
-| YYYY-MM-DD | #tag | <lesson> |
-
-### Flashcard Audit (Stale Candidates)
-<!-- For each active card with no [S]/[R] marker, symbols extracted and grepped.
-     Candidates below have ALL extracted symbols absent from the current repo. -->
-
-| Card (date · lead-tag · lesson head) | Missing symbols | Proposed marker |
-|---|---|---|
-
-If zero candidates: No stale flashcards detected.
-
-### Supersede Candidates
-<!-- Newer cards whose lesson directly contradicts an older card's advice. -->
-
-| Newer card | Older card | Proposed marker for older |
-|---|---|---|
-
----
-
-## §6 Framework Self-Assessment
-
-<!-- Rate each dimension: Green (working well) / Yellow (friction) / Red (blocking).
-     "Tooling" subsection MUST include token-divergence finding if §3 divergence flag = YES. -->
-
-### Templates
-| Item | Rating | Notes |
-|---|---|---|
-| Story template completeness | Green/Yellow/Red | |
-| Sprint Plan Template usability | Green/Yellow/Red | |
-| Sprint Report template (this one) | Green/Yellow/Red | |
-
-### Handoffs
-| Item | Rating | Notes |
-|---|---|---|
-| Architect → Developer brief quality | Green/Yellow/Red | |
-| Developer → QA artifact completeness | Green/Yellow/Red | |
-| QA → Orchestrator kickback clarity | Green/Yellow/Red | |
-
-### Skills
-| Item | Rating | Notes |
-|---|---|---|
-| Flashcard gate adherence | Green/Yellow/Red | |
-| Adjacent-implementation reuse rate | Green/Yellow/Red | |
-
-### Process
-| Item | Rating | Notes |
-|---|---|---|
-| Bounce cap respected | Green/Yellow/Red | |
-| Three-surface landing compliance | Green/Yellow/Red | |
-| Circuit-breaker fires (if any) | Green/Yellow/Red | |
-
-### Lane Audit
-<!-- Filled by Reporter at sprint close. One row per fast-lane story. -->
-
-| Story | Files touched | LOC | Demoted? | In retrospect, was fast correct? (y/n) | Notes |
-|---|---|---|---|---|---|
-| `STORY-NNN-NN` | N | N | y / n | y / n | |
-
-### Hotfix Audit
-<!-- Filled by Reporter at sprint close. One row per hotfix merged during the sprint window. -->
-
-| Hotfix ID | Originating signal | Files touched | LOC | Resolved-by SHA | Could this have been a sprint story? (y/n) | If y — why was it missed at planning? |
-|---|---|---|---|---|---|---|
-| `HOTFIX-NN` | <signal> | N | N | `<sha>` | y / n | |
-
-### Hotfix Trend
-<!-- Filled by Reporter at sprint close. -->
-
-<!-- TBD: Reporter fills at sprint close -->
-
-<Reporter writes a one-paragraph narrative summarising the rolling 4-sprint hotfix count
-and a monotonic-increase flag (yes/no). Empty by default — leave the placeholder text
-intact for sprints with no hotfixes.>
-
-### Tooling
-| Item | Rating | Notes |
-|---|---|---|
-| run_script.sh diagnostic coverage | Green/Yellow/Red | |
-| Token ledger completeness | Green/Yellow/Red | |
-| Token divergence finding | Green/Yellow/Red | If §3 divergence >20%: Red — ledger=N task-notif=N delta=N% |
-
----
-
-## §7 Change Log
-
-<!-- Append one line per material revision to this report after initial generation. -->
-
-| Date | Author | Change |
-|---|---|---|
-| YYYY-MM-DD | Reporter agent | Initial generation |