@sandrinio/vbounce 1.9.0 → 2.1.0

package/skills/agent-team/references/mid-sprint-triage.md

@@ -1,4 +1,4 @@
-# Mid-Sprint Change Request Triage
+# Mid-Sprint Triage
 
 > On-demand reference from agent-team/SKILL.md. How the Team Lead handles user interruptions during an active sprint.
 
@@ -15,57 +15,71 @@ Any time the user provides input mid-bounce that is **not** a direct answer to a
 
 The Team Lead MUST classify the request before acting:
 
-| Category | Definition | Example |
-|----------|-----------|---------|
-| **Bug** | Something built (or pre-existing) is broken | "Login crashes when email has a plus sign" |
-| **Spec Clarification** | The spec was ambiguous; user is clarifying intent, not changing scope | "By 'admin' I meant workspace admin, not super admin" |
-| **Scope Change** | User wants to add, remove, or modify requirements for the current story | "Also add a forgot-password flow to the login story" |
-| **Approach Change** | Implementation strategy is wrong; needs a different technical path | "Don't use REST for this — wire it through WebSockets instead" |
+| Category | Definition | Example | Template |
+|----------|-----------|---------|----------|
+| **Bug** | Something built (or pre-existing) is broken | "Login crashes when email has a plus sign" | `templates/bug.md` (or `templates/hotfix.md` if L1) |
+| **Spec Clarification** | The spec was ambiguous; user is clarifying intent, not changing scope | "By 'admin' I meant workspace admin, not super admin" | No template — update story spec inline |
+| **Scope Change** | User wants to add, remove, or modify requirements for the current story | "Also add a forgot-password flow to the login story" | `templates/change_request.md` |
+| **Approach Change** | Implementation strategy is wrong; needs a different technical path | "Don't use REST for this — wire it through WebSockets instead" | `templates/change_request.md` |
 
 ### How to Decide
 
 ```
 Is existing behavior broken?
   YES → Bug
+    Is it L1 (1-2 files, trivial)? → Hotfix Path (templates/hotfix.md)
+    Is it larger? → Bug Report (templates/bug.md) → fix task in current sprint
   NO  → Is the user adding/removing/changing a requirement?
-          YES → Scope Change
+          YES → Scope Change (templates/change_request.md)
           NO  → Is the user correcting an ambiguity in the spec?
-                  YES → Spec Clarification
-                  NO  → Approach Change (technical direction shift)
+                  YES → Spec Clarification (update story inline, no template)
+                  NO  → Approach Change (templates/change_request.md)
 ```
 
 ## Step 2 — Route
 
-| Category | Action | Bounce Impact |
-|----------|--------|---------------|
-| **Bug** | If L1 (1-2 files): Hotfix Path. If larger: add as a bug-fix task within the current story bounce. | Does NOT increment QA/Arch bounce count. |
-| **Spec Clarification** | Update Story spec inline (§1 or §2). Add a note in the Change Log. Continue current bounce. | Does NOT reset or increment bounce count. |
-| **Scope Change** | Pause bounce. Update Story spec. If scope grew significantly, consider splitting into a new story. Reset Dev pass (QA/Arch counts preserved if prior passes are still valid). | Resets Dev pass only. Prior QA/Arch passes invalidated if the change affects tested areas. |
-| **Approach Change** | Update Story §3 Implementation Guide. Re-delegate to Developer with updated context. | Resets Dev pass only. Prior QA/Arch passes invalidated. |
+| Category | Action | Bounce Impact | Document Created |
+|----------|--------|---------------|------------------|
+| **Bug (L1)** | Hotfix Path: Dev fixes, human verifies, merge directly | None — does NOT increment bounce count | `product_plans/hotfixes/HOTFIX-{Date}-{Name}.md` |
+| **Bug (L2+)** | Create bug report, add as fix task within current story bounce | None — does NOT increment bounce count | `product_plans/sprints/sprint-{XX}/BUG-{Date}-{Name}.md` |
+| **Spec Clarification** | Update Story spec inline (§1 or §2). Add a note in the Change Log. Continue current bounce. | None | No separate document |
+| **Scope Change** | **Pause bounce.** Create CR document. Present impact to human. Wait for decision. If approved: update Story spec, reset Dev pass. If rejected: continue as-is. If deferred: add to backlog. | Resets Dev pass. Prior QA/Arch invalidated if change affects tested areas. | `product_plans/sprints/sprint-{XX}/CR-{Date}-{Name}.md` |
+| **Approach Change** | Create CR document. Update Story §3 Implementation Guide. Re-delegate to Developer with updated context. | Resets Dev pass. Prior QA/Arch invalidated. | `product_plans/sprints/sprint-{XX}/CR-{Date}-{Name}.md` |
 
 ## Step 3 — Log
 
-Every change request MUST be logged in the Sprint Plan `sprint-{XX}.md` §4 Execution Log:
+Every triage event MUST be logged in the Sprint Plan `sprint-{XX}.md` §4 Execution Log:
 
 ```
-| {timestamp} | CR | {Category} | {STORY-ID} | {One-line description} |
+| {Story or N/A} | {Category} | 0 | 0 | — | CR: {One-line description} |
 ```
 
-Use `CR` as the event type to distinguish from regular bounce events.
+Use the Notes column with `CR:` prefix to distinguish from regular story completions.
+
+## Step 4 — Present to Human
+
+After categorizing, the Team Lead MUST present the triage decision to the human:
+
+1. State the category: "This is a **{Bug / Scope Change / Approach Change / Spec Clarification}**."
+2. For Bugs: state severity and whether it blocks the current story
+3. For Scope/Approach Changes: present the impact assessment from the CR document and ask for decision (Approve / Reject / Defer)
+4. For Spec Clarifications: state what was clarified and confirm with human before updating
 
 ## Sprint Report Tracking
 
-At sprint consolidation (Step 7), the Team Lead includes a **§2.1 Change Requests** section in the Sprint Report summarizing all mid-sprint CRs. This keeps change-request-driven work separate from agent-driven bounces so metrics aren't skewed.
+At sprint consolidation (Step 7), the Team Lead includes a **§2.1 Change Requests** section in the Sprint Report summarizing all mid-sprint triage events:
 
-| Story | Category | Description | Impact |
-|-------|----------|-------------|--------|
-| STORY-{ID} | Spec Clarification | Clarified admin role scope | No bounce reset |
-| STORY-{ID} | Scope Change | Added forgot-password flow | Dev pass reset, +1 session |
+| Story | Category | Description | Impact | Document |
+|-------|----------|-------------|--------|----------|
+| STORY-{ID} | Bug | Login crash on plus-sign emails | Fixed via hotfix, no bounce reset | HOTFIX-2026-03-22-login-plus |
+| STORY-{ID} | Scope Change | Added forgot-password flow | Dev pass reset, +1 session | CR-2026-03-22-forgot-password |
 
 ## Key Rules
 
-- **Never silently absorb a user change.** Always categorize and log it.
+- **Never silently absorb a user change.** Always categorize, document, and log it.
 - **Bugs don't penalize the bounce count.** They are defects, not process failures.
 - **Spec clarifications are cheap.** Update the spec and move on — no ceremony needed.
-- **Scope changes are expensive.** Always pause, update the spec, and confirm with the user before resuming.
+- **Scope changes require a CR document and human approval.** Always pause, assess impact, and confirm before resuming.
+- **Approach changes require a CR document.** The technical pivot must be recorded for audit trail.
 - **Correction Tax still applies.** Human intervention is tracked, but the category explains *why*.
+- **Everything gets a document or an inline update.** No change goes unrecorded.

package/skills/doc-manager/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: doc-manager
-description: "Use when creating, modifying, or navigating V-Bounce Engine planning documents. Trigger on any request to create a charter, roadmap, epic, story, delivery plan, or risk registry — or when the user asks to update, refine, decompose, or transition documents between phases. Also trigger when an agent needs to know which template to use, where a document fits in the hierarchy, or what upstream/downstream documents to read before writing. This skill manages the full document lifecycle from Charter through Sprint execution."
+description: "Use when creating, modifying, or navigating V-Bounce Engine planning documents. Trigger on any request to create a charter, roadmap, epic, story, delivery plan, sprint plan, or risk registry — or when the user asks to update, refine, decompose, or transition documents between phases. Also trigger when the user asks about work status, backlog, what's next, what's blocked, or wants to plan/start a sprint. This skill manages the full document lifecycle from Charter through Sprint Planning and execution."
 ---
 
 # Document Hierarchy Manager
@@ -49,7 +49,7 @@ Roadmap §5 (Constraints) ──→ Delivery Plan (sprint capacity)
 
 Epic §2 (Scope Boundaries) ──→ Story §1 (The Spec)
 Epic §4 (Technical Context) ──→ Story §3 (Implementation Guide)
-Epic §5 (Decomposition) ──→ Story creation sequence
+Epic §5 (Decomposition) ──→ Codebase research scope + Story creation sequence
 Epic §6 (Risks) ──→ Risk Registry §1 (Active Risks)
 Epic §7 (Acceptance Criteria) ──→ Story §2 (The Truth)
 Epic §9 (Artifact Links) ──→ Delivery Plan §3 (Backlog)
@@ -64,6 +64,12 @@ Sprint Plan §1 (Context Pack Readiness) ──→ Ready to Bounce gate
 Delivery Plan ──→ Updated at sprint boundaries ONLY (never mid-sprint)
 
 Risk Registry ←── ALL levels (cross-cutting input)
+
+Epic §8 (Open Questions) ──→ Spike §1 (Question)
+Epic §4 (Technical Context) ──→ Spike §3 (Approach)
+Spike §4 (Findings) ──→ Epic §4 (Technical Context) [update]
+Spike §5 (Decision) ──→ Roadmap §3 (ADRs) [if architectural]
+Spike §6 (Residual Risk) ──→ Risk Registry §1 (Active Risks)
 ```
 
 ## Template Locations
@@ -77,7 +83,10 @@ Risk Registry ←── ALL levels (cross-cutting input)
 | Sprint Plan | `templates/sprint.md` | `product_plans/sprints/sprint-{XX}/sprint-{XX}.md` |
 | Epic | `templates/epic.md` | `product_plans/backlog/EPIC-{NNN}_{name}/EPIC-{NNN}_{name}.md` |
 | Story | `templates/story.md` | `product_plans/backlog/EPIC-{NNN}_{name}/STORY-{EpicID}-{StoryID}-{StoryName}.md` |
+| Spike | `templates/spike.md` | `product_plans/backlog/EPIC-{NNN}_{name}/SPIKE-{EpicID}-{NNN}-{topic}.md` |
 | Hotfix | `templates/hotfix.md` | `product_plans/hotfixes/HOTFIX-{Date}-{Name}.md` |
+| Bug Report | `templates/bug.md` | `product_plans/sprints/sprint-{XX}/BUG-{Date}-{Name}.md` |
+| Change Request | `templates/change_request.md` | `product_plans/sprints/sprint-{XX}/CR-{Date}-{Name}.md` |
 | Sprint Report | `templates/sprint_report.md` | `product_plans/sprints/sprint-{XX}/sprint-report.md` |
 
 ### Product Plans Folder Structure (State-Based)
@@ -94,7 +103,8 @@ product_plans/
 │   ├── EPIC-001_authentication/
 │   │   ├── EPIC-001_authentication.md
 │   │   ├── STORY-001-01-login_ui.md
-│   │   └── STORY-001-02-auth_api.md
+│   │   ├── STORY-001-02-auth_api.md
+│   │   └── SPIKE-001-001-auth-provider.md
 │
 ├── sprints/                       ← active execution workspace
 │   ├── sprint-01/                 ← active sprint boundary
@@ -152,6 +162,36 @@ Brain files contain the V-Bounce process, critical rules, and skill references.
 
 ## Document Operations
 
+### Ambiguity Assessment Rubric
+
+When creating or reviewing an Epic or Story, assess ambiguity using these signals:
+
+**🔴 High — Discovery Required (any ONE triggers 🔴):**
+- Epic §4 Technical Context has "TBD" or "unknown" in dependencies or affected areas
+- Epic §8 Open Questions has items marked blocking
+- Multiple competing approaches mentioned with no ADR deciding between them
+- Unknown external dependencies or integrations
+- No acceptance criteria defined (Epic §7 empty)
+- Vague scope language in §2 ("various", "possibly", "might", "somehow", "rethink")
+
+**🟡 Medium — Conditional Progress:**
+- Technical Context partially filled (some areas known, others TBD)
+- Open Questions exist but are non-blocking
+- Dependencies listed but unconfirmed
+
+**🟢 Low — Ready to Proceed:**
+- All sections filled with specific, concrete content
+- All Open Questions resolved or non-blocking
+- ADRs exist for every major technical choice
+- Acceptance criteria are concrete Gherkin scenarios
+
+**When 🔴 is detected:**
+1. Set `ambiguity: 🔴 High` in frontmatter
+2. Identify which signals triggered it
+3. For each signal, recommend a spike with a one-sentence question
+4. Create spike documents from `templates/spike.md`
+5. Block downstream transitions until spikes reach Validated or Closed
+
 ### CREATE — Making a New Document
 
 Before creating any document, YOU MUST:
@@ -162,6 +202,24 @@ Before creating any document, YOU MUST:
 4. Fill sections by pulling from upstream sources (see Information Flow above)
 5. Set the Ambiguity Score based on completeness
 6. Verify all cross-references are valid
+7. **Present edge cases and open questions to the human** (see below)
+
+**After creating an Epic — mandatory discussion step:**
+
+After writing the Epic document, you MUST present §6 (Risks & Edge Cases) and §8 (Open Questions) to the human in chat. Do not silently file them — the human needs to see what's uncertain to make good decisions.
+
+Format your presentation like this:
+1. Summarize the epic in 1-2 sentences
+2. List each edge case from §6 with its proposed mitigation — ask the human if the mitigation is adequate or if they see other risks
+3. List each open question from §8 — present the options, explain the impact, and ask the human to decide or delegate
+4. State the current ambiguity score and what must be resolved before decomposition into stories
+
+The epic is NOT ready for decomposition until:
+- All **blocking** questions in §8 are resolved (status = "Decided")
+- All edge cases in §6 have either a decided mitigation or are explicitly accepted as known risk by the human
+- Ambiguity is 🟡 or 🟢
+
+If the human resolves questions during discussion, update the epic document immediately (change §8 status to "Decided", update §6 mitigations, adjust ambiguity score).
 
 **Pre-read requirements by document type:**
 
@@ -169,8 +227,10 @@ Before creating any document, YOU MUST:
 |----------|-----------------|
 | Charter | Nothing — Charter is root. Gather from user input. |
 | Roadmap | Charter (full document) |
-| Epic | Charter §1, §2, §5 + Roadmap §2, §3, §5 |
-| Story | Parent Epic (full document) + Roadmap §3 (ADRs) |
+| Epic | Charter §1, §2, §5 + Roadmap §2, §3, §5 + **Codebase** (explore affected areas for §4) |
+| Story | Parent Epic (full document) + Roadmap §3 (ADRs) + Codebase (affected files) |
+| Spike | Parent Epic (full document) + Roadmap §3 (ADRs) + Risk Registry |
+| Sprint Plan | All candidate stories + Risk Registry + Archive (completed work) + Backlog state |
 | Delivery Plan | Roadmap §2 (Release Plan) + All Stories in scope |
 | Risk Registry | Charter §6 + Roadmap §4, §5 + All Epic §6 sections |
 
@@ -199,20 +259,101 @@ When modifying a document:
 | Epic §4 (Technical Context) | All child Stories §3 (Implementation Guide) |
 | Story status (V-Bounce State) | Delivery Plan §3 (Active Sprint table) |
 | Story — new risk discovered | Risk Registry §1 (new row) |
+| Spike §4/§5 (Findings/Decision) | Epic §4 Technical Context, Epic §8 Open Questions, Risk Registry §1 |
+| Spike §5 (Decision — architectural) | Roadmap §3 ADRs (new row) |
+
+**After any cascade:** Run `vbounce graph` to regenerate the product graph so downstream consumers have current state.
 
 ### DECOMPOSE — Breaking Down Documents
 
 **Epic → Stories:**
 
-1. Read Epic §5 (Decomposition Guidance) for the checklist and suggested sequence
-2. Create one Story per checked category (Schema, API, UI, Integration, etc.)
-3. For each Story:
-   - Pull §1 The Spec from Epic §2 Scope Boundaries (relevant items only)
-   - Pull §2 The Truth from Epic §7 Acceptance Criteria (decomposed per story)
-   - Pull §3 Implementation Guide from Epic §4 Technical Context
-   - Set Complexity Label (L1-L4) based on file count and pattern familiarity
-4. Link all created Stories back in Epic §9 Artifact Links
-5. Update Delivery Plan §3 High-Level Backlog with new stories
+Stories are NOT created by mechanically splitting epic sections by category. The AI must analyze the epic, research the actual codebase, and produce small, focused stories — each delivering a tangible, independently verifiable result.
+
+#### Phase 1: Analyze & Research
+
+1. Read the full Epic document (all sections)
+2. Read Roadmap §3 (ADRs) for architecture constraints
+3. **Research the codebase** — this is mandatory, not optional:
+   - Read every file listed in Epic §4 Affected Areas
+   - Explore the surrounding code to understand current architecture, patterns, and conventions
+   - Identify actual dependencies, imports, and integration points in the code
+   - Note existing tests, utilities, and shared modules that stories will interact with
+4. Build a mental model of what needs to change and in what order
+
+#### Phase 2: Draft Stories by Deliverable, Not by Category
+
+Do NOT create stories by layer (one for schema, one for API, one for UI). Instead, create stories by **tangible outcome** — each story should deliver a small, specific, working result that can be verified.
+
+**Story sizing rules:**
+- Each story has **one clear goal** expressible in a single sentence
+- Each story touches **1-3 files** (if more, it needs splitting)
+- Each story produces a **verifiable result** — something you can see, test, or demonstrate
+- Each story is **independently meaningful** — it delivers value or unlocks the next story, not just "part of a layer"
+- Prefer vertical slices (thin end-to-end) over horizontal slices (full layer)
+
+**If a drafted story exceeds size:**
+- Ask: "Can this be split into two stories that each produce a tangible result?"
+- If yes → split it. Each sub-story must still have its own clear goal.
+- If no (the work is inherently atomic) → keep it as one story, label it L3, and document why it can't be smaller.
+
+#### Phase 3: Write Stories with Codebase-Informed Detail
+
+For each story, use what you learned from codebase research:
+- §1 The Spec: Write requirements informed by actual code state (not just epic abstractions)
+- §2 The Truth: Write Gherkin scenarios that reference real components, routes, and data shapes found in the code
+- §3 Implementation Guide: Reference actual file paths, existing patterns, real function signatures — not placeholders. The developer should be able to start coding immediately.
+- Set Complexity Label (L1-L4) based on actual code complexity discovered during research
+
+#### Phase 4: Link & Update
+
+1. Link all created Stories back in Epic §9 Artifact Links
+2. Update Delivery Plan §3 High-Level Backlog with new stories
+
+### SPRINT PLANNING — Preparing a Sprint
+
+Sprint Planning is a collaborative process between AI and human. No sprint starts without a confirmed Sprint Plan.
+
+**Workflow:**
+
+1. **Read current state:**
+   - Scan `product_plans/backlog/` — read all epic and story frontmatter (status, priority, ambiguity, complexity_label, open questions)
+   - Scan `product_plans/archive/` — understand what's already shipped and what context carries forward
+   - Read `product_plans/strategy/RISK_REGISTRY.md` — identify risks affecting candidate stories
+   - If `vdocs/_manifest.json` exists, read it for documentation context
+
+2. **Propose sprint scope:**
+   - Select stories based on priority, dependencies, and capacity
+   - Identify dependency chains — stories with `Depends On:` must be sequenced
+   - Group parallel-safe stories into phases
+   - Flag stories with 🔴 High ambiguity — these CANNOT enter the sprint without completed spikes
+
+3. **Surface blockers to the human:**
+   - Open questions from epics (§8) and stories that haven't been resolved
+   - Environment prerequisites missing from stories
+   - Risks from Risk Registry that affect planned stories
+   - Edge cases or ambiguity the human may not have considered
+   - Dependencies on incomplete work
+
+4. **Collaborate with the human:**
+   - Present proposed scope, risks, and blockers
+   - Discuss and adjust — add/remove stories, resolve open questions
+   - Agree on execution mode per story (Full Bounce vs Fast Track)
+
+5. **Create Sprint Plan:**
+   - Create `product_plans/sprints/sprint-{XX}/sprint-{XX}.md` from `templates/sprint.md`
+   - Fill §0 Sprint Readiness Gate checklist
+   - Fill §1 Active Scope with confirmed stories + Context Pack Readiness
+   - Fill §2 Execution Strategy (phases, dependencies, risk flags)
+   - Fill §3 Sprint Open Questions (all must be resolved or non-blocking)
+   - Set status: `Planning`
+
+6. **Gate — Human confirms:**
+   - Present finalized plan to human
+   - Explicitly ask for confirmation
+   - On confirmation: set `status: Confirmed`, fill `confirmed_by` and `confirmed_at`
+   - Move story files from `product_plans/backlog/EPIC-{NNN}/` to `product_plans/sprints/sprint-{XX}/`
+   - Sprint is now ready for Phase 3 (Execution)
 
 ### TRANSITION — Moving Documents Between Phases
 
@@ -222,8 +363,13 @@ When modifying a document:
 |------------|------|
 | Charter → Ready for Roadmap | Ambiguity 🟡 or 🟢 (§1 and §5 filled) |
 | Roadmap → Ready for Epics | Charter Ambiguity 🟢 + Roadmap §2 and §3 filled |
-| Epic → Ready for Stories | Ambiguity 🟡 or 🟢 (§2 Scope and §4 Tech Context filled) |
-| Story → Ready to Bounce | Ambiguity 🟢 + ALL Context Pack items checked (Delivery Plan §5) |
+| Epic → Ready for Stories | Ambiguity 🟡 or 🟢 + §2 Scope filled + §4 Tech Context filled + §8 all blocking questions Decided + §6 each edge case has a decided mitigation OR is explicitly accepted as known risk |
+| Story → Ready to Bounce | Ambiguity 🟢 + ALL Context Pack items checked (Sprint Plan §1) |
+| Sprint Plan → Confirmed | §0 Readiness Gate checklist complete + Human explicitly confirms |
+| Sprint Plan → Active | Status is Confirmed (human approval obtained) |
+| Story (Probing/Spiking) → Refinement | All linked spikes are Validated or Closed |
+| Spike → Validated | Architect confirms findings against Safe Zone |
+| Spike → Closed | All items in §7 Affected Documents are checked off |
 | Hotfix → Bouncing | Complexity strictly L1 + Targets 1-2 files |
 
 **Physical Move Rules for State Transitions:**
@@ -232,6 +378,13 @@ When modifying a document:
 - **Sprint Closure Phase**: The Team Lead physically MOVES the entire sprint folder (`sprints/sprint-{XX}/`) to `product_plans/archive/sprints/sprint-{XX}/`. 
 - **Epic Closure**: Once every story attached to an Epic has been archived, the Epic folder itself is moved from `backlog/` to `archive/epics/`.
 
+**Complexity Labels:**
+
+- **L1**: Trivial — Single file, <1hr, known pattern. → Hotfix Path
+- **L2**: Standard — 2-3 files, known pattern, ~2-4hr. *(default)* → Full Bounce
+- **L3**: Complex — Cross-cutting, spike may be needed, ~1-2 days. → Full Bounce
+- **L4**: Uncertain — Requires spikes before Bounce, >2 days. → Discovery first
+
 **V-Bounce State transitions for Stories:**
 
 ```
@@ -257,9 +410,9 @@ Bouncing → Done: Dev implements + Human manually verifies + DevOps runs `hotfi
 | Agent | Documents Owned | Documents Read |
 |-------|----------------|----------------|
 | **Team Lead** | Delivery Plan, Sprint Report, Delivery archive | Charter, Roadmap, ALL Stories (for context packs) |
-| **Developer** | Story §3 updates (during implementation) | Story §1 + §3, LESSONS.md |
+| **Developer** | Story §3 updates (during implementation), Spike §4 Findings (during investigation) | Story §1 + §3, Spike §1 + §2 + §3, LESSONS.md |
 | **QA** | QA Validation Report | Story §2, Dev Implementation Report |
-| **Architect** | Architectural Audit Report, Risk flags (in report — Lead writes to Registry) | Full Story, Roadmap §3 ADRs, Risk Registry |
+| **Architect** | Architectural Audit Report, Risk flags (in report — Lead writes to Registry), Spike validation (Findings Ready → Validated) | Full Story, Spike §4 + §5, Roadmap §3 ADRs, Risk Registry |
 | **DevOps** | DevOps Reports (merge + release) | Delivery Plan, LESSONS.md, gate reports |
 | **Scribe** | Product documentation, _manifest.json | Sprint Report, Dev Reports, codebase |
 | **PM/BA (Human)** | Charter, Roadmap, Epic, Story §1 + §2 | Everything |
@@ -289,4 +442,4 @@ When a sprint is complete:
 
 ## Keywords
 
-charter, roadmap, epic, story, delivery plan, risk registry, document hierarchy, template, create document, update document, decompose epic, story breakdown, ambiguity score, context pack, V-Bounce state, phase transition, cascade update, planning documents
+charter, roadmap, epic, story, delivery plan, risk registry, sprint plan, sprint planning, document hierarchy, template, create document, update document, decompose epic, story breakdown, ambiguity score, context pack, V-Bounce state, phase transition, cascade update, planning documents, backlog, what's next, what's blocked, start sprint