ma-agents 3.6.2 → 3.9.0

package/_bmad-output/implementation-artifacts/done/12-2-add-to-sprint-workflow.md

@@ -1,137 +0,0 @@
-# Story 12.2: Create Add-to-Sprint Extension Workflow
-
-Status: done
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Scrum Master**,
-I want an extension workflow to assign backlog items to a sprint using multi-criteria prioritization,
-So that highest-value items are selected within capacity.
-
-## Acceptance Criteria
-
-1. **Given** add-to-sprint workflow exists in lib/bmad-extension/workflows/add-to-sprint/workflow.md,
-   **When** invoked (NFR19),
-   **Then** it presents flat backlog (stories + bugs) for selection (FR65),
-   **And** items can be assigned to a sprint
-
-2. **Given** items being prioritized (FR67),
-   **When** workflow guides prioritization,
-   **Then** agent presents a structured ranking table with explicit per-item rationale: business value (H/M/L), dependency status (blocked/blocking/independent), severity (critical/high/medium/low — bugs only, N/A for stories), effort (S/M/L),
-   **And** ranking table is displayed to the user before any assignment is made,
-   **And** user must explicitly confirm or modify the ranking before items are assigned,
-   **And** the confirmed ranking is included in the workflow output for auditability
-
-3. **Given** sprint at capacity,
-   **When** attempt to add another item,
-   **Then** workflow warns capacity exceeded,
-   **And** suggests removing item or increasing capacity
-
-## Tasks / Subtasks
-
-- [x] Task 1: Create add-to-sprint workflow (AC: #1, #2, #3)
-  - [x] 1.1: Create directory `lib/bmad-extension/workflows/add-to-sprint/`
-  - [x] 1.2: Create `lib/bmad-extension/workflows/add-to-sprint/workflow.md` with guided flow
-
-- [x] Task 2: Implement backlog discovery step (AC: #1)
-  - [x] 2.1: Workflow step 1a: Read sprint-status.yaml to discover all user story backlog items (sprint-status.yaml is authoritative for story execution status)
-  - [x] 2.2: Workflow step 1b: Glob `_bmad-output/implementation-artifacts/bug-*.md` to discover all bug stories. Parse YAML frontmatter from each file to extract: `type`, `severity`, `title`. Bug stories discovered this way are peers to user stories.
-  - [x] 2.3: Workflow step 2: Present flat backlog combining both sources — listing all items with type (story/bug), title, and current status
-  - [x] 2.4: Backlog must be flat — no epic grouping — stories and bugs are peers (FR65)
-
-- [x] Task 3: Implement sprint selection and capacity check (AC: #1, #3)
-  - [x] 3.1: Workflow step 3: List available sprints by reading sprint artifact files from `_bmad-output/implementation-artifacts/sprint-plan-*.yaml`
-  - [x] 3.2: Workflow step 4: User selects target sprint
-  - [x] 3.3: Workflow step 5: Display current sprint capacity usage (assigned items count vs capacity limit)
-
-- [x] Task 4: Implement multi-criteria prioritization guidance (AC: #2)
-  - [x] 4.1: Workflow step 6: For each candidate item, guide agent to evaluate: business value (high/medium/low), technical dependencies (blocked/blocking/independent), bug severity (critical/high/medium/low — bugs only), effort estimation (small/medium/large)
-  - [x] 4.2: Workflow step 7: Agent suggests a ranked ordering based on multi-criteria evaluation
-  - [x] 4.3: Workflow step 8: User confirms or adjusts ranking
-
-- [x] Task 5: Implement assignment with capacity enforcement (AC: #1, #3)
-  - [x] 5.1: Workflow step 9: Assign selected items to sprint by updating the sprint-plan-{number}.yaml artifact (add to assigned_items list). The sprint plan artifact is the **sole authoritative source** for sprint membership.
-  - [x] 5.2: Workflow step 10: After each assignment, check if sprint is at capacity — if at or over capacity, warn user and suggest removing an item or increasing capacity via modify-sprint workflow
-  - **Data authority note:** Do NOT update sprint-status.yaml to track sprint assignments. sprint-status.yaml is authoritative for item execution status (not-started/in-progress/done). Sprint assignments live exclusively in sprint-plan-{number}.yaml. These are separate concerns and must not be conflated.
-
-- [x] Task 6: Register workflow in module-help.csv (AC: #1)
-  - [x] 6.1: Add entry to `lib/bmad-extension/module-help.csv` for add-to-sprint workflow
-  - [x] 6.2: Entry must include: workflow name, slash command `/add-to-sprint`, description, phase association
-
-## Dev Notes
-
-### Architecture Compliance
-
-- **Extension module pattern:** Workflow lives in lib/bmad-extension/workflows/add-to-sprint/
-- **Flat backlog (FR65):** Stories and bugs are peers in a flat list — no epic hierarchy in backlog presentation
-- **Multi-criteria prioritization (FR67):** Agent assists with ranking using business value, dependencies, severity, and effort — but user makes final decisions. Ranking must be presented as a structured table with explicit rationale per item.
-- **Capacity enforcement:** Count-based (item count, not points) — matches sprint artifact format from 12-1
-- **Sprint artifact integration:** Reads and updates sprint-plan-{n}.yaml files created by add-sprint workflow (12-1)
-- **Data authority split:** sprint-plan-{n}.yaml owns sprint membership (assigned_items). sprint-status.yaml owns item execution status. Never write sprint assignments to sprint-status.yaml.
-- **Bug story discovery:** Bug stories are discovered via glob `_bmad-output/implementation-artifacts/bug-*.md` with YAML frontmatter parsing. They are NOT tracked in sprint-status.yaml. Sprint workflows must use both sources to build the complete backlog.
-
-### Shared Guardrails
-
-See `_bmad-output/implementation-artifacts/epic-11-12-shared-guardrails.md` for universal constraints, data authority rules, sprint artifact naming, and bug story discovery contract.
-
-### Critical Guardrails (story-specific)
-
-- Do NOT place workflow in `_bmad/bmm/workflows/` — use `lib/bmad-extension/workflows/`
-- Do NOT modify any existing BMAD base module files
-- Do NOT add npm dependencies
-- Do NOT group items by epic — present flat backlog (FR65)
-- Do NOT auto-assign items without user confirmation
-- Do NOT silently exceed capacity — always warn and offer alternatives
-- Do NOT modify lib/installer.js, lib/agents.js, or bin/cli.js
-
-### Project Structure Notes
-
-- **Files to create:**
-  - `lib/bmad-extension/workflows/add-to-sprint/workflow.md`
-- **Files to update:**
-  - `lib/bmad-extension/module-help.csv` — add workflow registration entry
-- **Files to read (at runtime):**
-  - `_bmad-output/implementation-artifacts/sprint-status.yaml` — backlog item discovery
-  - `_bmad-output/implementation-artifacts/sprint-plan-*.yaml` — sprint artifact files
-
-### References
-
-- [Source: _bmad-output/implementation-artifacts/sprint-status.yaml] — Backlog items source
-- [Source: lib/bmad-extension/workflows/add-sprint/workflow.md] — Sprint artifact format (created in 12-1)
-- [Source: lib/bmad-extension/workflows/modify-sprint/workflow.md] — Cross-reference for capacity adjustment (created in 12-3)
-
-## Dev Agent Record
-
-### Agent Model Used
-claude-sonnet-4-6
-
-### Debug Log References
-None — clean implementation following 12-1 sprint artifact format.
-
-### Completion Notes List
-- Created `lib/bmad-extension/workflows/add-to-sprint/workflow.md` with 9-step guided flow
-- Step 1a: Reads sprint-status.yaml, filters out epic-* and *-retrospective keys to get user stories
-- Step 1b: Globs bug-*.md, parses YAML frontmatter for type/severity/title
-- Step 2: Flat backlog table — stories and bugs as peers, no epic grouping (FR65)
-- Steps 3–4: Sprint discovery via sprint-plan-*.yaml glob; capacity display
-- Step 5: Candidate item selection
-- Step 6: Multi-criteria ranking table — business value, dependency status, severity (bugs), effort
-- Step 7: User confirms/modifies/re-ranks before any assignment
-- Step 8: Per-item capacity check with warn + options (add anyway/skip/modify sprint)
-- Step 9: Updates sprint-plan-{n}.yaml assigned_items + last_modified; confirmed ranking in output for audit
-- sprint-status.yaml is read-only — sprint assignments never written there
-- Registered in module-help.csv with `/add-to-sprint` command
-- Post-review fixes: Step 1c added to filter items already assigned to any sprint (H1); {{sprint_number}} → {{target_sprint.sprint_number}} in step 8 (H2); "all" expansion logic added to step 5 (M3); re-rank option 'r' now specifies unlisted items are excluded (M4); `<goto next-item />` replaced with valid continue action (L2)
-
-### File List
-- `lib/bmad-extension/workflows/add-to-sprint/workflow.md` (created)
-- `lib/bmad-extension/module-help.csv` (updated — added add-to-sprint entry)
-- `_bmad-output/implementation-artifacts/12-2-add-to-sprint-workflow.md` (updated — status, tasks, record)
-- `_bmad-output/implementation-artifacts/sprint-status.yaml` (updated — 12-2 in-progress→review)
-
-## Change Log
-
-- 2026-03-18: Story 12.2 implemented — add-to-sprint extension workflow created and registered
-- 2026-03-18: Addressed code review findings — H1 (cross-sprint duplicate filter), H2 (sprint_number variable fix), M3 (all expansion), M4 (re-rank exclusion spec), L2 (valid continue action)

package/_bmad-output/implementation-artifacts/done/12-3-modify-sprint-workflow.md

@@ -1,127 +0,0 @@
-# Story 12.3: Create Modify Sprint Extension Workflow
-
-Status: done
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Scrum Master**,
-I want an extension workflow to modify existing sprints,
-So that scope can be adjusted when priorities change mid-sprint.
-
-## Acceptance Criteria
-
-1. **Given** modify-sprint workflow exists in lib/bmad-extension/workflows/modify-sprint/workflow.md,
-   **When** invoked (NFR19),
-   **Then** it allows: adding items, removing items, changing capacity, updating metadata
-
-2. **Given** sprint modification requested,
-   **When** items added or removed,
-   **Then** sprint status reflects updated item list and remaining capacity (FR71)
-
-## Tasks / Subtasks
-
-- [x] Task 1: Create modify-sprint workflow (AC: #1, #2)
-  - [x] 1.1: Create directory `lib/bmad-extension/workflows/modify-sprint/`
-  - [x] 1.2: Create `lib/bmad-extension/workflows/modify-sprint/workflow.md` with guided flow
-
-- [x] Task 2: Implement sprint selection step (AC: #1)
-  - [x] 2.1: Workflow step 1: List available sprints by reading `_bmad-output/implementation-artifacts/sprint-plan-*.yaml`
-  - [x] 2.2: Workflow step 2: User selects sprint to modify
-  - [x] 2.3: Workflow step 3: Display current sprint state — name, capacity, assigned items with status, remaining capacity
-
-- [x] Task 3: Implement modification operations (AC: #1, #2)
-  - [x] 3.1: Workflow step 4: Present modification menu — add item, remove item, change capacity, update metadata
-  - [x] 3.2: **Add item:** Present unassigned backlog items (from sprint-status.yaml), user selects item, add to sprint assigned_items list, check capacity
-  - [x] 3.3: **Remove item:** List currently assigned items, user selects item to remove, remove from assigned_items list, item returns to unassigned backlog
-  - [x] 3.4: **Change capacity:** Prompt for new capacity (positive integer), validate, update sprint artifact
-  - [x] 3.5: **Update metadata:** Allow updating sprint name, start/end context, status (planning/active/completed)
-
-- [x] Task 4: Implement capacity feedback after each modification (AC: #2)
-  - [x] 4.1: After every modification, display updated remaining capacity (capacity - assigned_items count)
-  - [x] 4.2: If adding an item exceeds capacity, warn user and require confirmation or capacity increase
-  - [x] 4.3: Allow multiple modifications in sequence before finalizing
-
-- [x] Task 5: Persist changes to sprint artifact with concurrency guard (AC: #2)
-  - [x] 5.1: Before writing, re-read the sprint artifact file and compare its `last_modified` timestamp to the value read at the start of the workflow session. If the timestamp differs, the file was modified externally — halt and display: *"Sprint artifact was modified since this session started. Re-read the current state below and confirm your changes before proceeding."* Then redisplay the current state and await user confirmation.
-  - [x] 5.2: Write updated sprint data back to the sprint YAML artifact file, updating `last_modified` to the current ISO timestamp.
-  - **Data authority note:** Do NOT write sprint assignments to sprint-status.yaml. Sprint membership is owned exclusively by sprint-plan-{n}.yaml. sprint-status.yaml is read-only from the perspective of sprint management workflows.
-
-- [x] Task 6: Register workflow in module-help.csv (AC: #1)
-  - [x] 6.1: Add entry to `lib/bmad-extension/module-help.csv` for modify-sprint workflow
-  - [x] 6.2: Entry must include: workflow name, slash command `/modify-sprint`, description, phase association
-
-## Dev Notes
-
-### Architecture Compliance
-
-- **Extension module pattern:** Workflow lives in lib/bmad-extension/workflows/modify-sprint/
-- **Sprint artifact format:** Reads and writes the same YAML format defined in 12-1 (sprint-plan-{number}.yaml), including the `last_modified` timestamp field
-- **Capacity as item count:** Consistent with FR66 — capacity is always an integer item count
-- **Remaining capacity display (FR71):** After every modification, show remaining capacity
-- **Concurrency guard:** Re-read artifact before write and compare `last_modified`. Abort write if file changed externally.
-- **Data authority:** sprint-plan-{n}.yaml is authoritative for sprint membership. Do not modify sprint-status.yaml from this workflow.
-
-### Shared Guardrails
-
-See `_bmad-output/implementation-artifacts/epic-11-12-shared-guardrails.md` for universal constraints, data authority rules, sprint artifact naming, and concurrency guard requirements.
-
-### Critical Guardrails (story-specific)
-
-- Do NOT place workflow in `_bmad/bmm/workflows/` — use `lib/bmad-extension/workflows/`
-- Do NOT modify any existing BMAD base module files
-- Do NOT add npm dependencies
-- Do NOT allow capacity to be set to zero or negative values
-- Do NOT silently exceed capacity when adding items — always warn
-- Do NOT modify lib/installer.js, lib/agents.js, or bin/cli.js
-- Do NOT delete sprint artifact files — only modify their contents
-
-### Project Structure Notes
-
-- **Files to create:**
-  - `lib/bmad-extension/workflows/modify-sprint/workflow.md`
-- **Files to update:**
-  - `lib/bmad-extension/module-help.csv` — add workflow registration entry
-- **Files to read/write (at runtime):**
-  - `_bmad-output/implementation-artifacts/sprint-plan-*.yaml` — sprint artifact files
-  - `_bmad-output/implementation-artifacts/sprint-status.yaml` — backlog item status
-
-### References
-
-- [Source: lib/bmad-extension/workflows/add-sprint/workflow.md] — Sprint artifact format (created in 12-1)
-- [Source: lib/bmad-extension/workflows/add-to-sprint/workflow.md] — Item assignment pattern (created in 12-2)
-- [Source: _bmad-output/implementation-artifacts/sprint-status.yaml] — Backlog status file
-
-## Dev Agent Record
-
-### Agent Model Used
-claude-sonnet-4-6
-
-### Debug Log References
-None — clean implementation.
-
-### Completion Notes List
-- Created `lib/bmad-extension/workflows/modify-sprint/workflow.md` with looping multi-step menu workflow
-- Step 1: Sprint discovery via sprint-plan-*.yaml glob; stores session_last_modified for concurrency guard
-- Step 2: Displays current sprint state with capacity/remaining
-- Step 3: Modification menu loops — supports multiple modifications before save
-- Step 3a (Add item): reads sprint-status.yaml + bug-*.md glob for unassigned items; capacity over-limit warning with options (add anyway/skip/change capacity)
-- Step 3b (Remove item): lists assigned items, removes from working state
-- Step 3c (Change capacity): validates positive integer; updates working state
-- Step 3d (Update metadata): name, start/end context, status (planning/active/completed)
-- Step 4 (Concurrency guard): re-reads file before write, compares last_modified; on conflict offers overwrite/merge/cancel
-- Step 5: Writes updated YAML preserving sprint_number and created_date; updates last_modified to current ISO timestamp; sprint-status.yaml not modified
-- Registered in module-help.csv with `/modify-sprint` command
-- Post-review fixes: {{working_assigned_items}} explicitly initialized from {{target_sprint.assigned_items}} in step 2 (M1); step 3b adds identifier resolution to titles/types before displaying Remove table (M2); step 3a cross-references ALL sprint plans to filter already-assigned items (H1); step 3d choice 5 now has explicit check block (L5)
-
-### File List
-- `lib/bmad-extension/workflows/modify-sprint/workflow.md` (created)
-- `lib/bmad-extension/module-help.csv` (updated — added modify-sprint entry)
-- `_bmad-output/implementation-artifacts/12-3-modify-sprint-workflow.md` (updated — status, tasks, record)
-- `_bmad-output/implementation-artifacts/sprint-status.yaml` (updated — 12-3 in-progress→review)
-
-## Change Log
-
-- 2026-03-18: Story 12.3 implemented — modify-sprint extension workflow created and registered
-- 2026-03-18: Addressed code review findings — H1 (cross-sprint filter in 3a), M1 (working_assigned_items init), M2 (identifier resolution in 3b), L5 (explicit choice 5 handler in 3d)

package/_bmad-output/implementation-artifacts/done/12-4-sprint-status-assigned-items.md

@@ -1,129 +0,0 @@
-# Story 12.4: Update Sprint Status with Assigned Items
-
-Status: done
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a **Scrum Master**,
-I want sprint status workflow to show assigned items per sprint,
-So that sprint progress is visible with all stories and bugs listed.
-
-## Acceptance Criteria
-
-0. **Architecture mandate:**
-   Implementation MUST create a new extension workflow at `lib/bmad-extension/workflows/sprint-status-view/workflow.md`. Do NOT modify any files under `_bmad/bmm/workflows/`. This is not a decision left to the implementing developer — the extension approach is required.
-
-1. **Given** existing sprint status workflow,
-   **When** it displays sprint information,
-   **Then** it shows all assigned items (stories + bugs) with their current status (FR71),
-   **And** remaining capacity visible,
-   **And** bugs and stories distinguishable in listing
-
-## Tasks / Subtasks
-
-- [x] Task 1: Prepare extension workflow — **architecture is pre-decided: create extension only** (AC: #0)
-  - [x] 1.1: Read existing sprint-status workflow in `_bmad/bmm/workflows/` to understand current format for reference only — do NOT modify it
-  - [x] 1.2: Read existing `_bmad-output/implementation-artifacts/sprint-status.yaml` to understand current data structure
-  - [x] 1.3: Create `lib/bmad-extension/workflows/sprint-status-view/workflow.md` — this is the mandated approach. Do not modify base module files.
-
-- [x] Task 2: Create sprint-status-view extension workflow (AC: #1)
-  - [x] 2.1: Create `lib/bmad-extension/workflows/sprint-status-view/workflow.md`
-  - [x] 2.2: Workflow step 1: Read all sprint artifact files from `_bmad-output/implementation-artifacts/sprint-plan-*.yaml`
-  - [x] 2.3: Workflow step 2: For each sprint, display: sprint name/number, capacity, status (planning/active/completed)
-  - [x] 2.4: Workflow step 3: For each sprint, list assigned items with: item identifier, title, type (story or bug), current status
-  - [x] 2.5: Workflow step 4: Display remaining capacity per sprint (capacity - assigned items count)
-
-- [x] Task 3: Implement type distinction for stories vs bugs (AC: #1)
-  - [x] 3.1: Stories and bugs must be visually distinguishable in the listing — use type labels or markers
-  - [x] 3.2: Bug items should show severity alongside status
-  - [x] 3.3: Story items should show standard status (not-started/in-progress/done)
-
-- [x] Task 4: Integrate with sprint-status.yaml data (AC: #1)
-  - [x] 4.1: Cross-reference sprint assigned_items (from sprint-plan-*.yaml) with sprint-status.yaml to get current item execution statuses. Data authority: sprint-plan-{n}.yaml owns membership; sprint-status.yaml owns execution status.
-  - [x] 4.2: For bug items (discovered via `bug-*.md` glob): execution status comes from the bug file's YAML frontmatter (or shows as "not-started" if no status field present — bugs start unstarted).
-  - [x] 4.3: Handle items that exist in a sprint plan but have no entry in sprint-status.yaml (user stories only): display a **data integrity warning** — *"Item {id} has no status entry in sprint-status.yaml — run /sprint-planning to initialize status tracking for this item."* Do NOT silently show "status unknown."
-  - [x] 4.4: Handle items in sprint-status.yaml not assigned to any sprint: show in an "Unassigned Backlog" summary section.
-
-- [x] Task 5: Register workflow in module-help.csv (AC: #1)
-  - [x] 5.1: Add entry to `lib/bmad-extension/module-help.csv` for sprint-status-view workflow
-  - [x] 5.2: Entry must include: workflow name, slash command `/sprint-status-view`, description, phase association
-
-## Dev Notes
-
-### Architecture Compliance
-
-- **Extension workflow mandatory:** Implementation MUST be a new extension workflow at `lib/bmad-extension/workflows/sprint-status-view/workflow.md`. This is not a preference — it is required. The base `_bmad/bmm/workflows/` must not be modified.
-- **Sprint artifact integration:** Reads sprint-plan-{n}.yaml files created by add-sprint (12-1) and modified by add-to-sprint (12-2) and modify-sprint (12-3)
-- **Flat listing (FR65):** Items displayed in a flat list within each sprint — no epic grouping
-- **Remaining capacity (FR71):** Must be prominently displayed per sprint
-- **Item type distinction:** Stories and bugs are clearly labeled — bugs show severity, stories show status
-- **Data authority split:** sprint-plan-{n}.yaml owns sprint membership. sprint-status.yaml owns user story execution status. Bug execution status comes from bug file frontmatter. Never conflate these sources.
-- **Bug story discovery:** Bug stories are discovered via glob `_bmad-output/implementation-artifacts/bug-*.md` with YAML frontmatter parsing. They are NOT in sprint-status.yaml.
-- **Data integrity warnings:** Items in sprint plan but missing from sprint-status.yaml must surface as an actionable warning (run /sprint-planning), not silently as "status unknown."
-
-### Shared Guardrails
-
-See `_bmad-output/implementation-artifacts/epic-11-12-shared-guardrails.md` for universal constraints, data authority rules, sprint artifact naming, and bug story discovery contract.
-
-### Critical Guardrails (story-specific)
-
-- Do NOT modify `_bmad/bmm/workflows/` base module files — extension workflow is mandatory (see AC #0)
-- Do NOT add npm dependencies
-- Do NOT modify lib/installer.js, lib/agents.js, or bin/cli.js
-- Do NOT group items by epic — maintain flat backlog view within sprints
-- Do NOT hide unassigned items — surface them in a summary section
-
-### Project Structure Notes
-
-- **Files to create (likely):**
-  - `lib/bmad-extension/workflows/sprint-status-view/workflow.md` (or similar name)
-- **Files to update:**
-  - `lib/bmad-extension/module-help.csv` — add workflow registration entry (if new workflow)
-- **Files to read (at runtime):**
-  - `_bmad-output/implementation-artifacts/sprint-plan-*.yaml` — sprint artifact files
-  - `_bmad-output/implementation-artifacts/sprint-status.yaml` — item statuses
-- **Existing files to review (not modify):**
-  - `_bmad/bmm/workflows/` — existing sprint-status workflow for reference
-
-### References
-
-- [Source: _bmad-output/implementation-artifacts/sprint-status.yaml] — Current sprint status data
-- [Source: _bmad/bmm/workflows/] — Existing sprint-status workflow for pattern reference
-- [Source: lib/bmad-extension/workflows/add-sprint/workflow.md] — Sprint artifact format (created in 12-1)
-- [Source: lib/bmad-extension/workflows/add-to-sprint/workflow.md] — Item assignment format (created in 12-2)
-
-## Dev Agent Record
-
-### Agent Model Used
-claude-sonnet-4-6
-
-### Debug Log References
-None — clean implementation. Extension workflow approach confirmed mandated by AC #0.
-
-### Completion Notes List
-- Read existing sprint-status workflow at `_bmad/bmm/workflows/4-implementation/sprint-status/instructions.md` for reference only (not modified)
-- Created `lib/bmad-extension/workflows/sprint-status-view/workflow.md` as new extension (not modifying base module)
-- Step 1: Globs sprint-plan-*.yaml sorted by sprint_number
-- Step 2: Loads sprint-status.yaml into story_status_map (story key → status); excludes epic-* and *-retrospective keys
-- Step 3: Globs bug-*.md into bug_metadata_map (basename → severity/title)
-- Step 4: Per sprint — displays capacity/remaining; resolves each assigned_items entry:
-  - Stories (regex `^\d+-\d+-.+`): status from story_status_map; DATA INTEGRITY WARNING if missing (not silent "unknown")
-  - Bugs (regex `^bug-.+`): severity from bug_metadata_map frontmatter; execution status from bug frontmatter or "not-started"
-  - Type distinction: 📋 Story vs 🐛 Bug markers in table
-- Step 5: Unassigned Backlog — stories grouped by status count + full unassigned bug table (id/title/severity)
-- Step 6: Interactive next-action menu — option 1 now shows full unassigned item list (stories + bugs) with details
-- Registered in module-help.csv with `/sprint-status-view` command; output_type: display (read-only workflow)
-- Post-review fixes: story/bug patterns use explicit regex (L3); unassigned bugs show full table not count (M6); step 6 option 1 replaced with genuinely additive full backlog detail view (L4); output_type corrected to display (M7)
-
-### File List
-- `lib/bmad-extension/workflows/sprint-status-view/workflow.md` (created)
-- `lib/bmad-extension/module-help.csv` (updated — added sprint-status-view entry)
-- `_bmad-output/implementation-artifacts/12-4-sprint-status-assigned-items.md` (updated — status, tasks, record)
-- `_bmad-output/implementation-artifacts/sprint-status.yaml` (updated — 12-4 in-progress→review, epic-12 in-progress)
-
-## Change Log
-
-- 2026-03-18: Story 12.4 implemented — sprint-status-view extension workflow created and registered
-- 2026-03-18: Addressed code review findings — M6 (full unassigned bug table), M7 (output_type: display), L3 (explicit regex patterns), L4 (step 6 option 1 replaced)

package/_bmad-output/implementation-artifacts/done/13-1-project-context-template-and-generator.md

@@ -1,179 +0,0 @@
-# Story 13.1: Create Project-Context Template and Generator Function
-
-Status: done
-
-## Story
-
-As a **Chief Architect**,
-I want a standalone project-context template and a `generateProjectContext()` function in the installer,
-So that a constitutional document can be generated with correct platform-specific content at install time.
-
-## Acceptance Criteria
-
-1. `lib/templates/project-context.template.md` exists as a standalone file (not an inline string in code) containing all mandatory rule sections (NFR24)
-2. The template contains a `## AI Agent Mandatory Rules` section with:
-   - Pre-task rules: read MANIFEST.yaml (`{{MANIFEST_PATHS_LIST}}` placeholder), load all `always_load: true` skills, select task-relevant skills (FR80)
-   - Git workflow rules: create fresh worktree per mission (not just a branch), all work in worktree, conventional commits, PR to main, worktree cleanup post-merge (FR80)
-   - Full 8-step mission lifecycle documented in sequence (FR83)
-3. The template contains `{{MANIFEST_PATHS_LIST}}` exactly once — no hardcoded platform paths anywhere in the template source (NFR22)
-4. The template contains the machine-readable version comment `<!-- ma-agents-template-version: 1.0 -->` on line 2 (NFR25)
-5. The template contains inline expansion comments referencing `bmad-generate-project-context`, `bmad-retrospective`, and manual additions (FR85)
-6. The template contains empty `## Technology Stack` and `## Project-Specific Rules` placeholder sections with TODO comments
-7. `generateProjectContext(projectRoot, installedAgents)` is implemented in `installer.js` — `installedAgents` receives ALL agents from the project manifest, not just those installed in the current run
-8. The function reads the template from `TEMPLATE_PATH` constant (resolved via `path.join(__dirname, 'templates', 'project-context.template.md')`, not hardcoded inline)
-9. The function resolves relative MANIFEST.yaml paths for each agent: `agent.skillsDir + '/MANIFEST.yaml'` — relative to project root, no `path.resolve()` or absolute prefixes (NFR22 for generated output)
-10. The function replaces `{{MANIFEST_PATHS_LIST}}` with a markdown bullet list: one `  - \`<path>\`` line per agent (FR81, FR82)
-11. The function returns the stamped content string — it does NOT write any file (writing is Story 13.2's responsibility)
-12. When `installedAgents` is empty, `{{MANIFEST_PATHS_LIST}}` is replaced with `  - (no agents installed — run ma-agents to install skills)`
-13. When the template file cannot be read (missing, permission error), the function throws an `Error` with message including the template path and the underlying cause — it never swallows errors silently
-14. With one installed platform, the returned content contains exactly one MANIFEST path entry (FR81)
-15. With multiple installed platforms, the returned content contains one entry per platform in the order they appear in the manifest (FR82)
-
-## Tasks / Subtasks
-
-- [x] Task 1: Create `lib/templates/` directory and template file (AC: #1-#4)
-  - [x] 1.1 Create `lib/templates/` directory in the project
-  - [x] 1.2 Create `lib/templates/project-context.template.md` with the full template structure (see Dev Notes for exact content)
-  - [x] 1.3 Verify template contains `{{MANIFEST_PATHS_LIST}}` placeholder
-  - [x] 1.4 Verify template contains all three mandatory rule sections: pre-task, git workflow, mission lifecycle
-  - [x] 1.5 Verify template contains expansion guidance comments
-  - [x] 1.6 Verify template contains empty Technology Stack and Project-Specific Rules sections
-
-- [x] Task 2: Implement `generateProjectContext()` in `installer.js` (AC: #5-#9)
-  - [x] 2.1 Add `TEMPLATE_PATH` constant near top of `installer.js`: `const TEMPLATE_PATH = path.join(__dirname, 'templates', 'project-context.template.md')`
-  - [x] 2.2 Implement `async function generateProjectContext(projectRoot, installedAgents)`:
-    - [x] 2.2.1 Read template file with `await fs.readFile(TEMPLATE_PATH, 'utf8')`
-    - [x] 2.2.2 Map `installedAgents` to manifest paths: `agent.skillsDir + '/MANIFEST.yaml'` (relative paths — no `path.join(projectRoot, ...)`)
-    - [x] 2.2.3 Format paths as markdown list: `  - \`${path}\``
-    - [x] 2.2.4 Replace `{{MANIFEST_PATHS_LIST}}` in template with formatted list
-    - [x] 2.2.5 Return stamped content string
-  - [x] 2.3 Wrap `fs.readFile` in try/catch — if template file missing, throw clear error: `"project-context template not found at ${TEMPLATE_PATH} — ma-agents installation may be corrupted"`
-
-- [x] Task 3: Unit tests (AC: all)
-  - [x] 3.1 Test: single platform → one MANIFEST path in output (AC: #14)
-  - [x] 3.2 Test: multiple platforms → correct count of paths in manifest order (AC: #15)
-  - [x] 3.3 Test: all relative paths — no absolute path segments in output (AC: #9)
-  - [x] 3.4 Test: `{{MANIFEST_PATHS_LIST}}` placeholder fully replaced — not present in output (AC: #10)
-  - [x] 3.5 Test: empty agents array → fallback message appears, no error thrown (AC: #12)
-  - [x] 3.6 Test: missing template file → Error thrown with path in message (AC: #13)
-  - [x] 3.7 Test: template version comment present in output (AC: #4, NFR25)
-  - [x] 3.8 Test: function does NOT call fs.writeFile or fs.pathExists (AC: #11 — pure content generator)
-
-## Dev Notes
-
-### Template File Content
-
-`lib/templates/project-context.template.md` should contain:
-
-```markdown
-# Project Context
-<!-- Generated by ma-agents at install time — this is a living document -->
-<!--
-  EXPAND THIS FILE over time:
-  - After architecture phase: run /bmad-generate-project-context
-  - After each sprint:        run /bmad-retrospective (includes context update step)
-  - Manually:                 add conventions you notice agents getting wrong
--->
-
-## AI Agent Mandatory Rules
-
-### Pre-Task (EVERY task, no exceptions)
-
-1. Read the MANIFEST.yaml for your platform:
-{{MANIFEST_PATHS_LIST}}
-2. Load ALL skills marked `always_load: true` completely before doing anything
-3. Select additional skills relevant to the specific task type
-
-### Git Workflow (ALL file-changing tasks)
-
-1. Create a fresh worktree: `git worktree add ../<project>-<branch> -b <branch>`
-2. ALL work happens inside that worktree — never in the main working tree
-3. Use conventional commits: `feat/fix/chore/docs/refactor`
-4. Open a PR to main — never commit directly to main, never auto-merge
-5. After human approval and merge: `git worktree remove ../<project>-<branch>`
-
-### Agent Mission Lifecycle
-
-1. **Pre-flight:** Read MANIFEST.yaml, load always_load skills, select task skills
-2. **Worktree:** `git worktree add` creates fresh, isolated working surface
-3. **Implementation:** Execute task within the worktree
-4. **Self-review:** Run `code-review` skill on own output before opening PR
-5. **PR:** Conventional commit + PR opened — clear title and description
-6. **Human review gate:** Await approval — do NOT auto-merge under any circumstance
-7. **Merge + cleanup:** After approval: merge, `git worktree remove`, delete branch
-8. **Post-mission:** Update story status to done, append session to AiAudit.md
-
-## Technology Stack
-<!-- TODO: Populated after architecture phase via /bmad-generate-project-context -->
-<!-- Run: /bmad-generate-project-context to auto-detect your stack -->
-
-## Project-Specific Rules
-<!-- TODO: Grows through retrospectives and manual additions -->
-<!-- Run: /bmad-retrospective after each sprint to surface new conventions -->
-```
-
-### Architecture Compliance
-
-- **Decision P2-7** (Project Context Auto-Generation): This story implements the template creation and generator function. Story 13.2 handles pipeline integration (writing the file).
-- **NFR22** (Relative paths only): `agent.skillsDir` values in the agent registry are already relative project paths (e.g., `.claude/skills`). Appending `/MANIFEST.yaml` keeps them relative. Do NOT resolve to absolute paths.
-- **NFR24** (Template as separate file): The template MUST be a file in `lib/templates/`, not a template literal in installer.js code.
-
-### Source Tree Components to Touch
-
-| File | Change |
-|------|--------|
-| `lib/templates/project-context.template.md` | CREATE — new template file |
-| `lib/installer.js` | ADD — `TEMPLATE_PATH` constant + `generateProjectContext()` function |
-
-### Agent Registry `skillsDir` Values
-
-From `lib/agents.js`, the relevant `skillsDir` values for path resolution:
-- Claude Code: `.claude/skills`
-- Cursor: `.cursor/skills`
-- Cline: `.cline/skills`
-- Copilot: `.github/copilot/skills`
-- Gemini: `.gemini/skills`
-- Kilocode: `.kilocode/skills`
-- OpenCode: `.opencode/skills`
-- Antigravity: `.antigravity/skills`
-
-Verify actual values by reading `lib/agents.js` before implementation.
-
-### Testing Standards
-
-Epic 7 test suite is not yet complete. Manual verification is acceptable. If tests/installer.test.js exists, add unit tests there. Otherwise document manual test steps.
-
-### Epic 13 Cross-Story Context
-
-**Story 13.1** (this): Create template file and generator function — returns stamped content string
-**Story 13.2**: Call `generateProjectContext()` in install pipeline, handle file write + idempotency
-**Story 13.3**: Update all 11 BMAD agent `critical_actions` to load project-context.md
-**Story 13.4**: Add expansion trigger to retrospective workflow
-
-## Dev Agent Record
-
-### Agent Model Used
-claude-sonnet-4-6
-
-### Debug Log References
-- Test 3.1/3.2 initially failed: template itself contains "MANIFEST.yaml" in header text. Fixed test helper to count only backtick-wrapped path entries (`/MANIFEST.yaml`) not all occurrences of "MANIFEST.yaml".
-- Tests 3.6 and 3.8 raced when Promise.all ran them in parallel (3.6 temporarily renames template file). Fixed by running tests sequentially with async/await instead of Promise.all over parallel promises.
-- `skillsDir` property added to all agent definitions in `lib/agents.js` (not in original source tree spec) — required for `agent.skillsDir + '/MANIFEST.yaml'` pattern. All relative paths derived from agent definitions match the Dev Notes table.
-
-### Completion Notes List
-- `lib/templates/project-context.template.md` created with all mandatory rule sections, version comment on line 2, `{{MANIFEST_PATHS_LIST}}` placeholder (exactly once), expansion guidance comments, and empty Technology Stack / Project-Specific Rules sections.
-- `TEMPLATE_PATH` constant added near top of `lib/installer.js`.
-- `generateProjectContext(projectRoot, installedAgents)` implemented: reads template, maps agents to relative MANIFEST paths via `agent.skillsDir`, replaces placeholder, returns content string. Throws descriptive Error on missing template.
-- `skillsDir` property added to all 12 agent definitions in `lib/agents.js` for clean relative-path access.
-- `generateProjectContext` and `_TEMPLATE_PATH` exported from `lib/installer.js`.
-- 9 unit tests written in `test/generate-project-context.test.js` covering all 8 ACs. All pass. Full regression suite (84 tests) passes with no regressions.
-
-### File List
-- `lib/templates/project-context.template.md` — CREATED
-- `lib/installer.js` — MODIFIED (TEMPLATE_PATH constant, generateProjectContext function, exports)
-- `lib/agents.js` — MODIFIED (skillsDir property added to all 12 agent definitions)
-- `test/generate-project-context.test.js` — CREATED
-
-## Change Log
-- 2026-03-19: Story created (Epic 13, Story 13.1)
-- 2026-03-20: Story implemented — template file created, generateProjectContext() implemented, 9 unit tests passing, no regressions