🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
Sign In

convoke-agents

Package Overview
Dependencies
Maintainers
1
Versions
16
Alerts
File Explorer

Advanced tools

License
Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

convoke-agents - npm Package Compare versions

Comparing version
3.2.1
 to
3.3.0
+176
_bmad/bme/_enhance...es-backlog/steps-c/step-c-03-qualify.md
---
name: 'step-c-03-qualify'
description: 'Qualifying gate for Create mode — walk gathered intakes, assign Lane + Portfolio + RICE per intake (or keep raw)'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-04-generate.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/rice-scoring-guide.md'
processFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/lifecycle-process-spec.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'
---
# Step 3: Qualifying Gate (Create Mode)
## STEP GOAL:
Run the **qualifying gate** on each intake gathered in step-c-02. For each intake, the qualifier (Vortex, John, or Winston) assigns a **Lane** (Bug / Fast / Initiative), a **Portfolio** attachment, and an initial **RICE** score. Intakes the qualifier is not ready to route stay raw (§2.1 only).
This step mirrors step-t-03 (Triage's qualifying gate). The lifecycle rules are identical — only the invocation context differs (Create mode is bootstrapping a new file).
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate lane/portfolio/RICE without user input — the qualifying gate is user-driven
- 📖 CRITICAL: Read this complete step file before taking action
- 🔄 CRITICAL: When loading next step with 'C', read the entire file
- 📋 YOU ARE A QUALIFYING-GATE FACILITATOR supporting the qualifier (Vortex / John / Winston)
### Role Reinforcement:
- ✅ You are a **qualifying gate facilitator** — propose, don't decide; the qualifier decides
- ✅ Only Vortex team, John, or Winston can qualify. Confirm the user's qualifier role.
- ✅ Propose lane/portfolio/RICE based on intake description, but flag uncertainty plainly
- ✅ Every intake ends this step in one of two states: **qualified** (lane + portfolio + RICE) or **raw intake** (logged to §2.1 only)
### Step-Specific Rules:
- 🎯 Focus on lane assignment, portfolio attachment, and RICE scoring
- 🚫 FORBIDDEN to write to the backlog file (step-c-04's job)
- 🚫 FORBIDDEN to re-gather or add new intakes (step-c-02's job)
- 💬 Approach: walk intakes one at a time, propose + decide, track state
## EXECUTION PROTOCOLS:
- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load {templateFile} for RICE factor definitions and calibration examples
- 📖 Load {processFile} for lane definitions and portfolio taxonomy
- 💾 Track each intake's qualification decision for step-c-04
## CONTEXT BOUNDARIES:
- Available context: `gathered_intakes` from step-c-02, RICE scoring guide, lifecycle process spec
- Focus: Qualifying gate per-intake
- Limits: Do NOT write to backlog
- Dependencies: step-c-02-gather.md (gathered intakes)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
### 1. Load References
Load `{templateFile}` (rice-scoring-guide.md):
- **Factor definitions:** Reach (1-10), Impact (0.25-3), Confidence (20-100%), Effort (1-10)
- **Guided questions** for each factor
- **Composite formula:** Score = (R × I × C) / E
Load `{processFile}` (lifecycle-process-spec.md):
- **§1.3 Three Lanes** — Bug / Fast / Initiative triggers
- **§1.4 Portfolio Attachment** — current taxonomy + growth rule
- **§1.6 RICE Scoring** — lane-specific notes
### 2. Confirm Qualifier Role
Display:
> **Qualifying Gate — Confirm Qualifier**
>
> Only three parties can qualify intakes:
> - **[V] Vortex** team (via discovery)
> - **[J] John** (PM shortcut)
> - **[W] Winston** (Architect shortcut)
>
> Who is qualifying in this session?
Record qualifier identity. If user declines, display: "Qualifying requires an authorized qualifier. Type `raw-only` to skip qualification — all intakes will stay in §2.1 without a lane." and accept role letter or `raw-only`.
### 3. Walk Intakes One at a Time
Initialize:
- `qualified_items = []` — intakes with lane + portfolio + RICE
- `raw_intakes = []` — intakes kept as §2.1-only
- `current_index = 1`
For each intake in `gathered_intakes`:
#### 3a. Present Intake & Proposed Qualification
Display:
> **Intake [current_index] of [total]**
>
> **Description:** [description]
> **Source:** [source]
> **Date:** [date]
> **Raiser:** [raiser]
>
> **Proposed qualification:**
> - **Lane:** [proposed with rationale]
> - **Portfolio:** [proposed]
> - **RICE:** R:[r] I:[i] C:[c]% E:[e] = [score]
> *[one-line rationale]*
#### 3b. Present Per-Intake Menu
Display:
> **Review this qualification:**
>
> **Lane override:**
> - `L bug` / `L fast` / `L initiative` — Change lane
> - `L none` — Keep raw (§2.1 only)
>
> **Portfolio override:**
> - `P [item]` — Set portfolio
> - `P new [name] — [rationale]` — Propose new portfolio (logged for John+Winston review)
>
> **RICE adjustments:**
> - `R [value]` / `I [value]` / `CF [value]` / `E [value]` — Component changes
>
> **Decisions:**
> - `K` — Keep/accept
> - `RAW` — Log as raw intake only
> - `S` — Drop (won't reach backlog at all)
> - `X` — Exit qualification (remaining intakes stay raw)
>
> **[A] Advanced Elicitation** / **[P] Party Mode** / **[C] Continue**
#### Menu Handling Logic:
- Same semantics as step-t-03:
- `L bug/fast/initiative/none`, `P [item|new ...]`, `R/I/CF/E [v]`, `K`, `RAW`, `S`, `X`, `A`, `P`, `C`.
- Record adjustments, recalculate composite on RICE changes, redisplay after each action.
- On K/C (with changes): add to `qualified_items`. On RAW/L none: add to `raw_intakes`. On S: drop (logged in Change Log by step-c-04).
- On X: remaining intakes auto-moved to `raw_intakes`, go to step 4.
#### 3c. Advance
Increment `current_index`. If `<= total`, go to 3a. Otherwise step 4.
### 4. Present Qualification Summary
Display:
> **Qualification Complete**
>
> **Qualified (will populate lanes):** [N]
> **Raw intakes (§2.1 only):** [N]
> **Dropped:** [N]
>
> **Qualified breakdown:**
> - Bug Lane: [n]
> - Fast Lane: [n]
> - Initiative Lane: [n]
>
> **Qualifier:** [Vortex / John / Winston / raw-only]
> **New portfolio proposals:** [list, or "none"]
### 5. Present MENU OPTIONS
> **[C] Continue** — Generate backlog file (step-c-04)
> **[R] Revisit** — Walk intakes again
> **[X] Abort** — Return to T/R/C menu without writing
#### Menu Handling Logic:
- IF C: Load, read, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-04-generate.md`, passing `gathered_intakes` (for §2.1 rows), `qualified_items` (for lane rows), `raw_intakes`, `dropped_items`, and qualifier identity.
- IF R: Re-enter step 3.
- IF X: Discard qualifications. Load, read, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md`.
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Every intake qualified or routed to raw/dropped, qualifier recorded, user validated, results passed to step-c-04
### ❌ SYSTEM FAILURE: Qualification without authorized qualifier, lane assigned without RICE, intakes lost between steps, step-c-04 invoked with missing data
**Master Rule:** Skipping steps is FORBIDDEN.
+259
_bmad/bme/_enhance...s-backlog/steps-c/step-c-04-generate.md
---
name: 'step-c-04-generate'
description: 'Generate the complete lifecycle backlog file — frontmatter, Part 1 verbatim from process spec, Part 2 lanes populated from qualified + raw intakes, Appendix, Change Log'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md'
processFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/lifecycle-process-spec.md'
workflowFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md'
---
# Step 4: Backlog Generation & Completion
## STEP GOAL:
Generate the complete lifecycle backlog file from scratch:
- **Frontmatter** with correct artifact governance metadata
- **Part 1: Lifecycle Process** copied verbatim from `lifecycle-process-spec.md`
- **Part 2: Backlog** with §2.1 Intakes populated from all gathered intakes, and §2.2/2.3/2.4 populated from qualified items (if any). §2.5 Absorbed/Archived starts empty.
- **Appendix: Initiative Details** (empty placeholder or populated for Initiative Lane items with detail)
- **Change Log** with the creation entry
Present a completion summary and return to the T/R/C menu.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without completing all mandatory sequence steps
- 📖 CRITICAL: Read this complete step file before taking action
- 🔄 CRITICAL: When returning to menu, read the entire workflow file
- 📋 YOU ARE A BACKLOG OPERATIONS SPECIALIST generating a new file
### Role Reinforcement:
- ✅ You are a **backlog operations specialist** — precise, structured, format-compliant
- ✅ Part 1 is **verbatim** from `{processFile}` — do not paraphrase, summarize, or edit
- ✅ All output must be standard markdown — no HTML, no proprietary syntax
- ✅ Every intake logged, every qualified item in its lane, every decision traceable in the Change Log
### Step-Specific Rules:
- 🎯 Focus on file generation, verbatim Part 1 emission, correct lane population, completion reporting
- 🚫 FORBIDDEN to re-qualify items (step-c-03's job)
- 🚫 FORBIDDEN to paraphrase or modify Part 1 content — emit the `lifecycle-process-spec.md` text verbatim
- 🚫 FORBIDDEN to add items not in the gathered_intakes / qualified_items lists
- 💬 Approach: assemble the complete file, verify structure, write, summarize, return to menu
## EXECUTION PROTOCOLS:
- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load `{templateFile}` (backlog-format-spec.md) for exact structural requirements and table formats
- 📖 Load `{processFile}` (lifecycle-process-spec.md) for the verbatim Part 1 text
- 💾 Write to `{outputFile}` as a complete new file
## CONTEXT BOUNDARIES:
- Available context: `gathered_intakes`, `qualified_items`, `raw_intakes`, `dropped_items`, qualifier identity, templates (format spec + process spec)
- Focus: File generation, completion summary
- Limits: Do NOT re-qualify or re-gather items
- Dependencies: step-c-02 (gathered intakes) and step-c-03 (qualified items). Empty-create path from step-c-01 is valid — both lists may be empty.
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
### 1. Load Templates (If Not Already Loaded)
Ensure `{templateFile}` (backlog-format-spec.md) and `{processFile}` (lifecycle-process-spec.md) are loaded.
Identify in `{processFile}` the **verbatim Part 1 text**: everything after the `---` separator line, starting with `## Part 1: Lifecycle Process` through the end of §1.6.
### 2. Generate Frontmatter
```yaml
---
initiative: convoke
artifact_type: note
qualifier: initiative-lifecycle-backlog
created: 'YYYY-MM-DD'
schema_version: 1
status: draft
origin: 'Create mode ([qualifier identity or raw-only], [date])'
supersedes: convoke-note-initiatives-backlog.md
---
```
`created` = current session date.
### 3. Generate Title
```markdown
# Convoke Initiative Lifecycle & Backlog
**Created:** [current session date]
**Origin:** Create mode ([qualifier identity])
**Status:** Draft (initial creation)
```
### 4. Emit Part 1 Verbatim
Copy the Part 1 text from `{processFile}` verbatim into the new file. This includes:
- `## Part 1: Lifecycle Process` heading
- `### 1.1 Intake`
- `### 1.2 Qualifying Gate`
- `### 1.3 Three Lanes` (with H4 subsections: Bug Lane, Fast Lane, Initiative Lane)
- `### 1.4 Portfolio Attachment`
- `### 1.5 Pipeline Stages (Evolvable)`
- `### 1.6 RICE Scoring`
**Do not paraphrase, summarize, reorder, or edit.** If any edit is desired, it must be made in `lifecycle-process-spec.md` first and migrated downstream.
### 5. Generate Part 2 Structure
Emit `## Part 2: Backlog` with all five H3 sections:
#### §2.1 Intakes (Unqualified)
Emit the 5-column table header:
```markdown
| ID | Description | Source | Date | Raiser |
|----|-------------|--------|------|--------|
```
For each intake in `gathered_intakes` (whether qualified, raw, or dropped):
- `ID`: `IN-{n}` sequential starting at 1.
- `Description`: the intake description. For qualified items, append ` → [laneID]` to cross-reference the lane row. For dropped items, prefix `[DROPPED]`.
- `Source`: from gathered data.
- `Date`: from gathered data.
- `Raiser`: from gathered data.
**Empty-create path:** If no intakes were gathered, emit the table header only (no rows).
#### §2.2 Bug Lane
Emit the 10-column table header:
```markdown
| ID | Description | R | I | C | E | Score | Portfolio | Status | Linked Follow-up |
|----|-------------|---|---|---|---|-------|-----------|--------|------------------|
```
For each qualified item with Lane = Bug:
- `ID`: `BUG-{n}` sequential.
- All columns per format spec.
- `Status`: `Open`.
- Sort table by composite Score descending.
If zero Bug items: emit header only with a line `*(none)*` below.
#### §2.3 Fast Lane (Quick Wins + Spikes)
Emit the 9-column table header:
```markdown
| ID | Description | R | I | C | E | Score | Portfolio | Status |
|----|-------------|---|---|---|---|-------|-----------|--------|
```
For each qualified item with Lane = Fast:
- `ID`: alpha-prefix sequential. Propose `Q-{n}` if uncertain about a domain prefix; user can rename later.
- `Status`: `Backlog`.
- Sort by composite Score descending.
If zero: `*(none)*`.
#### §2.4 Initiative Lane
Emit the 10-column table header:
```markdown
| ID | Description | R | I | C | E | Score | Portfolio | Stage | Artifacts |
|----|-------------|---|---|---|---|-------|-----------|-------|-----------|
```
For each qualified item with Lane = Initiative:
- `ID`: alpha-prefix sequential.
- `Stage`: `Qualified`.
- `Artifacts`: `—` (no planning artifacts yet).
- Sort by composite Score descending.
If zero: `*(none)*`.
#### §2.5 Absorbed / Archived
Emit the section heading and an empty state:
```markdown
### 2.5 Absorbed / Archived
*No absorbed or archived items yet.*
```
### 6. Generate Appendix
```markdown
## Appendix: Initiative Details
*Full descriptions for §2.4 items whose table row is a one-liner. Populated as initiatives enter the pipeline and require detail.*
```
If any Initiative Lane item warrants detail (has substantial scope notes from gathering), emit an H3 subsection per format spec.
### 7. Generate Change Log
```markdown
## Change Log
| Date | Change |
|------|--------|
| [YYYY-MM-DD] | Create: Bootstrapped new lifecycle backlog. Intakes: [N] logged. Qualified: [X] (Bug: a, Fast: b, Initiative: c). Raw intakes: [Y]. Dropped: [Z]. Qualifier: [identity]. [Portfolio proposals: list, if any.] |
```
### 8. Write Complete File
Write the assembled backlog to `{outputFile}`. The file must contain, in order:
1. Frontmatter
2. H1 title + metadata paragraph
3. `## Part 1: Lifecycle Process` (verbatim from process spec)
4. `## Part 2: Backlog` with §2.1 through §2.5
5. `## Appendix: Initiative Details`
6. `## Change Log`
### 9. Post-Write Validation
Re-load the written file and validate:
- All H2 anchors present in correct order
- All H3 Part 2 anchors present (§2.1 through §2.5)
- Table column counts match spec
- Frontmatter parses
If validation fails, display the failure and prompt to retry or abort.
### 10. Completion Summary & Return to Menu
After successful write + validation, display:
> **Create Complete — Lifecycle Backlog Bootstrapped**
>
> **File:** `{outputFile}`
> **Intakes logged:** [N]
> **Qualified into lanes:** [X]
> - Bug Lane: [n]
> - Fast Lane: [n]
> - Initiative Lane: [n]
> **Raw intakes (awaiting later qualification):** [Y]
> **Dropped (logged in §2.1 with [DROPPED] prefix):** [Z]
> **Qualifier:** [identity]
>
> **Next steps:**
> - Use **Triage (T)** to add new intakes from future findings.
> - Use **Review (R)** to rescore lane items as context evolves.
> - Unqualified intakes in §2.1 can be qualified later via a fresh Triage run or manual edit.
Then return to the T/R/C menu:
> Loading `{workflowFile}` to return to mode selection...
Load, read the entire file, and execute `{workflowFile}`.
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Complete file generated with correct frontmatter, verbatim Part 1 from process spec, all five §2.x H3 sections present with correct column counts, intakes logged with cross-references to lanes, qualified items placed in correct lanes and sorted by RICE, Appendix and Change Log present, post-write validation passes, completion summary displayed, menu re-presented
### ❌ SYSTEM FAILURE: Part 1 paraphrased or modified, missing H3 sections, wrong column counts, intakes not cross-referenced to qualified lane items, items placed in wrong lane, file not validated after write, no completion summary, no return to menu
**Master Rule:** Skipping steps is FORBIDDEN.
+192
_bmad/bme/_enhance...es-backlog/steps-t/step-t-03-qualify.md
---
name: 'step-t-03-qualify'
description: 'Qualifying gate — assign Lane, Portfolio, and RICE score for each validated finding. Optional skip keeps the finding as a raw intake.'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-04-update.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/rice-scoring-guide.md'
processFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/lifecycle-process-spec.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'
---
# Step 3: Qualifying Gate (Lane + Portfolio + RICE)
## STEP GOAL:
Run the **qualifying gate** on each validated finding from Gate 1. For each finding, the qualifier (Vortex, John, or Winston) assigns a **Lane** (Bug / Fast / Initiative), a **Portfolio** attachment, and an initial **RICE** score. Findings the qualifier is not ready to route stay logged as raw intakes in §2.1 with no lane.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate lane/portfolio/RICE without user input — the qualifying gate is user-driven
- 📖 CRITICAL: Read this complete step file before taking action
- 🔄 CRITICAL: When loading next step with 'C', read the entire file
- 📋 YOU ARE A QUALIFYING-GATE FACILITATOR supporting the qualifier (Vortex / John / Winston)
### Role Reinforcement:
- ✅ You are a **qualifying gate facilitator** — propose, don't decide; the qualifier decides
- ✅ Only Vortex team, John, or Winston can qualify. Confirm the user is acting in one of those roles.
- ✅ Propose lane/portfolio/RICE based on finding description, but flag uncertainty plainly
- ✅ Every finding ends this step in one of two states: **qualified** (lane + portfolio + RICE) or **raw intake** (logged to §2.1 only)
### Step-Specific Rules:
- 🎯 Focus on lane assignment, portfolio attachment, and RICE scoring
- 🚫 FORBIDDEN to write to the backlog file (that is step-t-04's job)
- 🚫 FORBIDDEN to re-extract or re-classify findings (that was step-t-02's job)
- 🚫 FORBIDDEN to add new findings here (new findings require a fresh Triage run)
- 💬 Approach: walk findings one at a time, propose + decide, track state
## EXECUTION PROTOCOLS:
- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load {templateFile} for RICE factor definitions and calibration examples
- 📖 Load {processFile} for lane definitions and portfolio taxonomy
- 💾 Track each finding's qualification decision for step-t-04
## CONTEXT BOUNDARIES:
- Available context: Validated findings from Gate 1 (step-t-02), RICE scoring guide, lifecycle process spec, existing backlog
- Focus: Qualifying gate per-finding
- Limits: Do NOT write to backlog or modify extraction results
- Dependencies: step-t-02-extract.md (Gate 1 validated findings)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
### 1. Load References
Load `{templateFile}` (rice-scoring-guide.md) and internalize:
- **Factor definitions:** Reach (1-10), Impact (0.25-3), Confidence (20-100%), Effort (1-10)
- **Guided questions** for each factor
- **Calibration examples** (study the reasoning, not just the numbers)
- **Composite formula:** Score = (R × I × C) / E, where C is decimal (e.g., 70% = 0.7)
Load `{processFile}` (lifecycle-process-spec.md) and internalize:
- **§1.3 Three Lanes** — Bug / Fast / Initiative triggers and rules
- **§1.4 Portfolio Attachment** — current taxonomy (convoke, vortex, gyre, forge, bmm, enhance, loom, helm) and growth rule
- **§1.6 RICE Scoring** — lane-specific scoring notes
### 2. Confirm Qualifier Role
Display:
> **Qualifying Gate — Confirm Qualifier**
>
> Only three parties can qualify intakes:
> - **[V] Vortex** team (via discovery)
> - **[J] John** (PM shortcut)
> - **[W] Winston** (Architect shortcut)
>
> Who is qualifying in this session?
Record the qualifier identity. If the user declines to pick one, display: "Qualifying requires an authorized qualifier (Vortex, John, or Winston). You can still log findings as raw intakes — type `raw-only` to skip qualification for this session." and accept either a role letter or `raw-only`.
### 3. Walk Findings One at a Time
Initialize:
- `qualified_items = []` — findings with lane + portfolio + RICE assigned
- `raw_intakes = []` — findings kept as intakes only (no lane)
- `current_index = 1`
For each finding from Gate 1:
#### 3a. Present Finding & Proposed Qualification
Display:
> **Finding [current_index] of [total]**
>
> **Title:** [title]
> **Source:** [source ref]
> **Type:** [Change/Gap/Risk/Break]
>
> **Proposed qualification:**
> - **Lane:** [proposed lane with brief rationale, e.g., "Fast Lane — single-module point fix"]
> - **Portfolio:** [proposed portfolio, e.g., "convoke"]
> - **RICE:** R:[r] I:[i] C:[c]% E:[e] = [score]
> *[one-line RICE rationale]*
>
> *If Type is `Break`, default lane is Bug and RICE impact defaults to 2+ unless narrow scope.*
#### 3b. Present Per-Finding Menu
Display:
> **Review this qualification:**
>
> **Lane override:**
> - `L bug` / `L fast` / `L initiative` — Change lane
> - `L none` — Keep as raw intake (no lane, stays in §2.1 only)
>
> **Portfolio override:**
> - `P [item]` — Set portfolio (convoke, vortex, gyre, forge, bmm, enhance, loom, helm, or a new portfolio)
> - `P new [name] — [rationale]` — Propose a new portfolio item (John+Winston decision per §1.4)
>
> **RICE adjustments:**
> - `R [value]` — Reach (1-10)
> - `I [value]` — Impact (0.25, 0.5, 1, 2, or 3)
> - `CF [value]` — Confidence (20-100%)
> - `E [value]` — Effort (1-10)
>
> **Decisions:**
> - `K` — Keep/accept proposed qualification
> - `RAW` — Log as raw intake only (§2.1); no lane assigned
> - `S` — Skip this finding (not logged, dropped)
> - `X` — Exit qualification early (remaining findings become raw intakes)
>
> **[A] Advanced Elicitation** — Deeper analysis
> **[P] Party Mode** — Multi-perspective discussion
> **[C] Continue** — Apply current qualification and advance to next finding
#### Menu Handling Logic:
- IF `L bug/fast/initiative`: Update lane. If lane is `bug`, note RICE impact may be hardcoded. Redisplay.
- IF `L none`: Mark finding for raw-intake-only routing. Redisplay.
- IF `P [item]`: Update portfolio. If `new`, record the proposal for John+Winston review in Change Log. Redisplay.
- IF `R/I/CF/E [value]`: Validate range. Update, recalculate composite, redisplay.
- IF K: Accept current state. Add to `qualified_items` (or `raw_intakes` if lane is `none`). Advance to next finding.
- IF RAW: Add to `raw_intakes`. Advance to next finding.
- IF S: Drop finding entirely (note in Change Log). Advance to next finding.
- IF X: Remaining findings become raw intakes. Go to step 4.
- IF A: Execute `{advancedElicitationTask}`. When finished, redisplay.
- IF P: Execute `{partyModeWorkflow}`. When finished, redisplay.
- IF C: Same as K if no change was made; otherwise record adjustments, advance.
- IF any other input: Display error, redisplay menu.
#### 3c. Advance
Increment `current_index`. If `<= total`, go to 3a. Otherwise go to step 4.
### 4. Present Qualification Summary
Display:
> **Qualification Complete**
>
> **Qualified items (will be added to lanes):** [N]
> **Raw intakes (logged to §2.1 only):** [N]
> **Dropped:** [N]
> [If early exit: **Auto-converted to raw intakes:** [N]]
>
> **Qualified breakdown:**
> - Bug Lane: [N]
> - Fast Lane: [N]
> - Initiative Lane: [N]
>
> **Qualifier:** [Vortex / John / Winston / raw-only]
### 5. Present MENU OPTIONS
Display:
> **[C] Continue** — Write qualifications to backlog (step-t-04)
> **[R] Revisit** — Walk findings again (re-enter step 3)
> **[X] Abort** — Return to mode selection without writing
#### Menu Handling Logic:
- IF C: Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-04-update.md`, passing `qualified_items`, `raw_intakes`, `dropped_items`, and the qualifier identity.
- IF R: Re-enter step 3 from `current_index = 1`. Preserve existing decisions but allow edits.
- IF X: Discard all qualifications. Load, read, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md`.
- IF any other input: Display error, redisplay menu.
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Every finding either qualified (lane + portfolio + RICE) or routed to raw intakes, qualifier identity recorded, user validated decisions, results passed to step-t-04
### ❌ SYSTEM FAILURE: Qualification performed without authorized qualifier, findings assigned to lane without RICE, findings lost between steps, step-t-04 invoked with missing data
**Master Rule:** Skipping steps is FORBIDDEN.
+188
_bmad/bme/_enhance...log/templates/lifecycle-process-spec.md
# Lifecycle Process Specification
Canonical text for **Part 1: Lifecycle Process** in the Convoke Initiative Lifecycle & Backlog file. Create mode emits this verbatim. Triage/Review modes load it for context but never modify it.
The text below the `---` marker is the verbatim Part 1 content. Do not edit it without coordinating with the lifecycle process governance — the same text appears in active backlog files and changing it requires migration.
---
## Part 1: Lifecycle Process
### 1.1 Intake
Any conversation about a problem, idea, observation, or improvement — regardless of source — enters the lifecycle as an **intake**.
**Intake rules:**
- Anyone can raise an intake: team members, code reviews, retros, party mode sessions, external feedback
- Intakes are logged immediately in Section 2.1 with: ID, description, source, date, raiser
- Intakes remain in the log permanently — they are the audit trail
- An intake has no lane, no priority, and no commitment until it passes the qualifying gate
- Intakes do not block or consume sprint capacity
**Logging format:**
| Field | Required | Description |
|-------|----------|-------------|
| ID | Yes | Sequential: `IN-{number}` |
| Description | Yes | One-line summary (detail in appendix if needed) |
| Source | Yes | Where it came from (code review, retro, party mode, user report, etc.) |
| Date | Yes | Date logged (absolute, not relative) |
| Raiser | Yes | Who raised it (person or agent name) |
### 1.2 Qualifying Gate
The qualifying gate is the single decision point that determines what happens to an intake. It is performed by one of three qualified parties:
1. **Vortex team** — through discovery (full 7-stream or partial)
2. **John (PM)** — product framing shortcut
3. **Winston (Architect)** — technical framing shortcut
**Gate rules:**
- John or Winston may shortcut the Vortex discovery phase when the problem is well-understood
- Vortex team can qualify intakes during discovery and ship spikes directly in a quick process
- The qualifier assigns: lane, portfolio attachment, and initial RICE score
- The qualifying decision is recorded with rationale
- For capability-type intakes (new skill, agent, or team proposals): run the **Capability Evaluation Framework** decision tree (`convoke-note-capability-evaluation-framework.md`) to determine form factor (Skill → Agent → Team) before assigning a lane. Friction log evidence (`convoke-note-friction-log-template.md`) is the required input signal — vision is not demand.
**Gate output:** one of three lanes.
### 1.3 Three Lanes
#### Bug Lane
**Trigger:** Something is broken — observed incorrect behavior, data loss risk, or regression.
**Pipeline:** Reproduce → Fix → Test → Ship
**Rules:**
- Bugs get a fix, not a redesign. The bug lane is for the fix only.
- If the fix reveals a deeper structural issue, spawn a follow-up:
- Refactoring story or light epic → **Fast Lane**
- Larger rework → **Initiative Lane**
- Risk vs. cost triage governs priority
- RICE scored — impact is often hardcoded high, effort is low, so bugs rise organically in the backlog
#### Fast Lane (Quick Wins + Spikes)
**Trigger:** The qualifier judges the full initiative pipeline unnecessary.
**Pipeline:** Story with ACs → Implement → Review → Ship
**What belongs here:**
- Point fixes from code reviews
- Refactoring follow-ups from bug fixes
- Process rules to encode
- Small enhancements (single-module, contained scope)
- Spikes (time-boxed learning with uncertain outcome)
- Documentation improvements
- Test debt items
**Rules:**
- Vortex team can ship spikes directly during discovery
- Each item gets a story with acceptance criteria before implementation
- RICE scored — low effort denominator means good items rise naturally
- Can be bundled into themed groups for sprint planning
#### Initiative Lane
**Trigger:** The work is multi-module, requires architectural decisions, affects user-facing behavior, or has enough scope that skipping planning steps would create risk.
**Pipeline (sequential, non-skippable):**
```
Brief → PRD → Architecture → PRD Validation → IR → Epic Breakdown
```
**Rules:**
- Full pipeline, no way out. No step can be skipped.
- The only shortcut is at intake qualification — John or Winston can qualify without Vortex discovery. Once qualified as an initiative, the pipeline is the pipeline.
- Attaches to a portfolio item (existing taxonomy or new — see 1.4)
- RICE scored
- Pipeline stages track progress (see 1.5)
**v6.3 Adoption standard (reference bar):**
The BMAD v6.3 Adoption initiative established the quality bar: 50 FRs, 33 NFRs, 16 failure modes mitigated, 12-check PRD validation (5/5), full FR→Architecture→Epic traceability, pre-registered experiments, innovation hypotheses with falsification criteria. This is the benchmark.
### 1.4 Portfolio Attachment
Every initiative attaches to a portfolio item. The portfolio item answers: "which part of the product does this serve?"
**Current taxonomy:**
| Portfolio Item | Scope |
|---------------|-------|
| convoke | Core platform, CLI, update system, meta-infrastructure |
| vortex | Discovery team (7 agents, Shiftup Innovation Vortex) |
| gyre | Readiness team (contextual assessment) |
| forge | Knowledge extraction team (brownfield capture) |
| bmm | Build module (upstream BMAD agents, workflows) |
| enhance | Skills module (workflow extensions on existing agents) |
| loom | Orchestration / Team Factory |
| helm | Strategic governance |
**Taxonomy growth rule:**
- New portfolio items are created when an initiative doesn't fit any existing item
- Decision to create a new portfolio item is made by John + Winston
- New items are logged with rationale
**Fast Lane and Bug Lane items** also receive a portfolio attachment where applicable, for traceability. Items that are purely cross-cutting may use `convoke`.
### 1.5 Pipeline Stages (Evolvable)
Initiatives in the Initiative Lane track their progress through pipeline stages.
**Current stages:**
| Stage | Meaning |
|-------|---------|
| **Qualified** | Passed the gate. Lane and portfolio assigned. No planning artifacts yet. |
| **In Pipeline** | Planning work in progress (Brief, PRD, Architecture, etc.) |
| **Ready** | Full pipeline complete — Brief + PRD + Arch + PRD Validation + IR + Epics all exist |
| **In Sprint** | Stories are being executed |
| **Done** | Shipped |
**Artifacts tracking (within "In Pipeline"):**
Each initiative's row includes an artifacts indicator showing what exists:
- `B` = Brief
- `P` = PRD
- `P✓` = PRD validated
- `A` = Architecture
- `IR` = Implementation Readiness report
- `E` = Epic breakdown
- `D` = Discovery (Vortex)
Example: `D, P✓, A, IR, E` = has Discovery, validated PRD, Architecture, IR report, and Epic breakdown.
**Stage evolution rule:**
- These stages are configuration, not dogma
- Stages are adapted when evidence shows the current set is insufficient
- Changes are logged with rationale and date in this section
### 1.6 RICE Scoring
RICE scoring applies to **all three lanes**. It determines priority within each lane.
| Factor | Scale | Description |
|--------|-------|-------------|
| **Reach** | 1–10 | How many users/quarter will this affect? (10 = all users, 1 = edge case) |
| **Impact** | 0.25–3 | Per-user impact (3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal) |
| **Confidence** | 20–100% | How sure are we about reach and impact estimates? |
| **Effort** | 1–10 | Relative effort in story points (1 = trivial, 10 = multi-epic) |
| **Score** | calculated | (Reach x Impact x Confidence) / Effort |
**Lane-specific scoring notes:**
- **Bug Lane:** Impact is often hardcoded high (2–3) when user-facing. Effort is typically low (1–2). Bugs rise organically.
- **Fast Lane:** Effort is typically 1–3. Items above score 3.0 are strong sprint candidates.
- **Initiative Lane:** Full RICE applies. Effort reflects pipeline + execution (not just coding).
+36
_bmad/bme/README.md
# `_bmad/bme/` — Convoke-Owned Modules
This directory is Convoke's owned namespace — everything under `_bmad/bme/` is authored and maintained by the Convoke project, distinct from upstream BMAD Method modules (`_bmad/core/`, `_bmad/bmm/`, `_bmad/bmb/`, etc.).
> **Authoring a new skill, workflow, or agent in `_bmad/bme/`?** Required reading first: [The Convoke Operator Covenant](../../_bmad-output/planning-artifacts/convoke-covenant-operator.md) — one axiom and seven Operator Rights every Convoke skill must honor. The Covenant is what makes a `_bmad/bme/` skill a *Convoke* skill rather than a generic one; authoring without consulting it produces skills that may look structurally correct but violate the operator experience standard the rest of the ecosystem relies on.
## Submodules
| Submodule | Purpose |
|-----------|---------|
| [`_artifacts/`](./_artifacts/) | Artifact governance — migration + portfolio |
| [`_enhance/`](./_enhance/) | Skill extensions — initiatives backlog, RICE scoring |
| [`_gyre/`](./_gyre/) | Gyre team — production readiness agents |
| [`_portability/`](./_portability/) | Skill export + catalog generation |
| [`_team-factory/`](./_team-factory/) | Loom — guided team creation |
| [`_vortex/`](./_vortex/) | Vortex team — 7-stream product discovery |
| `_config/` | Scaffolding (currently empty; reserved) |
## Files at `_bmad/bme/` root
Alongside this README:
- [`config.yaml`](./config.yaml) — BME-level module configuration (operator name, languages, output folder). Each submodule in the table above carries its own `config.yaml` with submodule-specific values; the root file is a **sibling, not a parent** — it is not merged into or inherited by the submodules at runtime (verify: `scripts/convoke-doctor.js` and `scripts/update/lib/refresh-installation.js` only read submodule configs). Generated by the BMAD installer; preserved across `convoke-update`.
## When to add here vs upstream
- **Add to `_bmad/bme/`** when the capability is Convoke-specific (operator-experience patterns, team-of-teams orchestration, Convoke's artifact governance).
- **Contribute upstream to BMAD Method** when the capability is generally useful across BMAD users (a new core agent pattern, a workflow primitive, a framework-level improvement).
Every story that adds or modifies a `_bmad/bme/` skill or workflow must include a **Namespace decision** note explaining why it belongs here rather than upstream (per `project-context.md` rule `namespace-decision-for-new-skills`).
## Adjacent references
- [`../../project-context.md`](../../project-context.md) — project-wide rules AI agents must follow when editing this repo
- [`../../_bmad-output/planning-artifacts/convoke-covenant-operator.md`](../../_bmad-output/planning-artifacts/convoke-covenant-operator.md) — the operator-experience standard all `_bmad/bme/` skills must honor
- [`../../_bmad-output/planning-artifacts/convoke-spec-covenant-compliance-checklist.md`](../../_bmad-output/planning-artifacts/convoke-spec-covenant-compliance-checklist.md) — the auditable form of the Covenant
+90
scripts/update/lib/changelog-reader.js
'use strict';
const fs = require('fs');
const path = require('path');
const { compareVersions } = require('./utils');
const DEFAULT_CHANGELOG_PATH = path.join(__dirname, '..', '..', '..', 'CHANGELOG.md');
// Broad bracket-capture so pre-release headers ([1.0.4-alpha]) don't get skipped —
// a skipped header would leak its body into the preceding entry. Non-semver labels
// (Unreleased, TBD) are dropped later by SEMVER_RE. Date may use ASCII or en/em dash.
const HEADER_RE = /^##\s+\[([^\]]+)\](?:\s*[-–—]\s*(.+?))?\s*$/;
const SEMVER_RE = /^\d+\.\d+\.\d+(?:[-+][\w.-]+)?$/;
const FENCE_RE = /^(?:```|~~~)/;
/**
* Parse a Keep-a-Changelog-formatted file and return entries for versions
* strictly greater than `fromVersion` and less than or equal to `toVersion`.
*
* Returns entries newest-first. Unreleased sections, malformed headers, and
* missing files are skipped silently — this is a decorative surface and must
* never break the update flow.
*
* @param {string|null|undefined} fromVersion - Installed version (exclusive lower bound). Null treats all entries <= toVersion as new.
* @param {string} toVersion - Target version (inclusive upper bound).
* @param {string} [changelogPath] - Absolute path to CHANGELOG.md.
* @returns {Array<{version: string, date: string|null, body: string}>}
*/
function readChangelogEntries(fromVersion, toVersion, changelogPath = DEFAULT_CHANGELOG_PATH) {
if (!toVersion) return [];
let raw;
try {
raw = fs.readFileSync(changelogPath, 'utf8');
} catch {
return [];
}
const entries = [];
const lines = raw.split('\n');
let current = null;
let inFence = false;
const flush = () => {
if (!current) return;
current.body = current.bodyLines.join('\n').replace(/\s+$/, '');
delete current.bodyLines;
entries.push(current);
current = null;
};
for (const line of lines) {
if (FENCE_RE.test(line)) {
inFence = !inFence;
if (current) current.bodyLines.push(line);
continue;
}
if (!inFence) {
const match = HEADER_RE.exec(line);
if (match) {
flush();
current = {
version: match[1].trim(),
date: match[2] ? match[2].trim() : null,
bodyLines: [],
};
continue;
}
}
if (current) {
if (!inFence && /^---\s*$/.test(line)) continue;
current.bodyLines.push(line);
}
}
flush();
return entries
.filter((e) => {
if (!SEMVER_RE.test(e.version)) return false;
const aboveFloor = fromVersion ? compareVersions(e.version, fromVersion) > 0 : true;
const atOrBelowCeiling = compareVersions(e.version, toVersion) <= 0;
return aboveFloor && atOrBelowCeiling;
})
.sort((a, b) => compareVersions(b.version, a.version));
}
module.exports = {
readChangelogEntries,
DEFAULT_CHANGELOG_PATH,
};
+1
-1
_bmad/bme/_enhance/workflows/initiatives-backlog/SKILL.md
---
name: bmad-enhance-initiatives-backlog
description: 'Manage RICE initiatives backlog — triage review findings, rescore existing items, or bootstrap new backlogs. Use when the user says triage findings or manage backlog.'
description: 'Manage lane-aware initiative lifecycle backlog — triage findings into intakes and qualify into Bug/Fast/Initiative lanes, rescore lane items, or bootstrap a new lifecycle backlog. Use when the user says triage findings, qualify intakes, or manage backlog.'
---
IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL {project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md, READ its entire contents and follow its directions exactly!
+55
-32
_bmad/bme/_enhance...tives-backlog/steps-c/step-c-01-init.md
---
name: 'step-c-01-init'
description: 'Check for existing backlog, warn on overwrite, initialize new backlog using format spec'
description: 'Check for existing lifecycle backlog, warn on overwrite, initialize new session using format spec + lifecycle process spec'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-02-gather.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md'
processFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/lifecycle-process-spec.md'
workflowFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md'

@@ -14,3 +15,3 @@ ---

Check whether a backlog file already exists at the output location, warn the user if so, and initialize a new backlog session using the backlog format specification.
Check whether a lifecycle backlog file already exists at the output location, warn the user if so, and initialize a new session by loading the backlog format specification and the canonical lifecycle process spec (Part 1 source).

@@ -23,13 +24,14 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

- 🔄 CRITICAL: When loading next step with 'C', read the entire file
- 📋 YOU ARE AN INITIALIZATION SPECIALIST setting up a new backlog
- 📋 YOU ARE AN INITIALIZATION SPECIALIST setting up a new lifecycle backlog
### Role Reinforcement:
- ✅ You are an **initialization specialist** — your job is to guard against accidental overwrites and prepare the session
- ✅ Do not gather initiatives, score items, or write the backlog file — those are later steps
- ✅ Do not gather intakes, qualify items, or write the backlog file — those are later steps
- ✅ The user must explicitly confirm before any existing file is overwritten
- ✅ Load both the **format spec** (structure) and the **lifecycle process spec** (Part 1 verbatim content)
### Step-Specific Rules:
- 🎯 Focus ONLY on existing file detection, overwrite confirmation, and session setup
- 🚫 FORBIDDEN to gather initiatives (that is step-c-02's job)
- 🚫 FORBIDDEN to score items (that is step-c-03's job)
- 🎯 Focus ONLY on existing file detection, overwrite confirmation, and template loading
- 🚫 FORBIDDEN to gather intakes (that is step-c-02's job)
- 🚫 FORBIDDEN to qualify items (that is step-c-03's job)
- 🚫 FORBIDDEN to write the backlog file (that is step-c-04's job)

@@ -40,8 +42,9 @@ - 💬 Approach: check file, warn if needed, confirm readiness, move on

- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load `{templateFile}` (backlog-format-spec.md) for structural reference — the format spec defines the file structure that step-c-04 will generate
- 📖 Load `{templateFile}` (backlog-format-spec.md) — file structure and table formats
- 📖 Load `{processFile}` (lifecycle-process-spec.md) — canonical Part 1 verbatim text for emission in step-c-04
## CONTEXT BOUNDARIES:
- Available context: Enhance config (loaded by workflow.md), existing backlog file (if present), backlog format spec template
- Available context: Enhance config (loaded by workflow.md), existing backlog file (if present), both template files
- Focus: File existence check and session initialization only
- Limits: Do NOT gather, score, or write anything
- Limits: Do NOT gather, qualify, or write anything
- Dependencies: workflow.md C dispatch (Create mode selected)

@@ -59,7 +62,9 @@

> **⚠️ Existing backlog detected at `{outputFile}`.**
> **⚠️ Existing lifecycle backlog detected at `{outputFile}`.**
>
> Create mode will generate a **new** backlog file, replacing the existing one. All current backlog data will be lost.
> Create mode will generate a **new** backlog file, replacing the existing one. All current data — including Part 2 lanes, Intakes, Absorbed records, and Change Log — will be **lost**.
>
> **[Y] Yes, overwrite and create new backlog**
> Consider using **Triage (T)** or **Review (R)** mode instead if you want to preserve existing data.
>
> **[Y] Yes, overwrite and create new lifecycle backlog**
> **[X] Cancel and return to mode selection**

@@ -75,37 +80,55 @@

### 1. Load Backlog Format Specification
### 1. Load Format Specification
Load `{templateFile}` (backlog-format-spec.md) and internalize:
- **Section hierarchy** — All 7 required H2 sections and their order
- **Table formats** — Category table (10 columns), Prioritized View (6 columns), Exploration Candidates (4 columns)
- **Category names** — Existing convention (Documentation & Onboarding, Update & Migration System, etc.)
- **Item ID format** — Category prefix letter + sequential number
- **Provenance format** — "Added from Create mode, [date]"
- **Changelog format** — Table with Date and Change columns, newest first
- **Frontmatter schema**
- **Section hierarchy** — Part 1 (semi-static), Part 2 (lanes), Appendix, Change Log
- **Table formats** per lane
- **Insertion rules** and **Pre-Write Validation** requirements
### 2. Confirm Session Ready
### 2. Load Lifecycle Process Spec
Load `{processFile}` (lifecycle-process-spec.md) and internalize:
- The **verbatim Part 1 content** (§1.1 through §1.6) — this is the canonical process definition that step-c-04 will emit exactly
- Step-c-04 will copy this text verbatim into `## Part 1: Lifecycle Process` of the new backlog file
### 3. Confirm Session Ready
Display:
> **Create Mode — New Backlog Initialized**
> **Create Mode — New Lifecycle Backlog Initialized**
>
> A new RICE-scored backlog will be created at `{outputFile}`.
> A new lifecycle backlog will be generated at `{outputFile}`.
>
> **Next:** You'll describe your initiatives one at a time — title, description, and category. Then we'll score them using RICE methodology and generate your prioritized backlog.
> **What will be created:**
> - Frontmatter (initiative: convoke, artifact_type: note, ...)
> - Part 1: Lifecycle Process (semi-static, from lifecycle-process-spec.md)
> - Part 2: Backlog (empty lane tables — §2.1 Intakes, §2.2 Bug, §2.3 Fast, §2.4 Initiative, §2.5 Absorbed/Archived)
> - Appendix: Initiative Details (empty)
> - Change Log (initial creation entry)
>
> **Next:** Optionally gather initial intakes and run them through the qualifying gate. You can also create an empty backlog and populate later via Triage mode.
### 3. Present MENU OPTIONS
### 4. Present MENU OPTIONS
Display: "**Select:** [C] Continue to initiative gathering"
Display:
> **Select:**
> - **[C] Continue** — gather initial intakes now
> - **[E] Empty create** — generate empty backlog and skip intake gathering / qualification (go directly to step-c-04)
> - **[X] Cancel** — return to T/R/C menu
#### Menu Handling Logic:
- IF C: Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-02-gather.md`
- IF any other input: Display "Enter **C** to continue to initiative gathering." then redisplay menu
- IF C: Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-02-gather.md`.
- IF E: Skip gathering and qualification. Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-04-generate.md` with empty `gathered_items` and empty `qualified_items`.
- IF X: Display "Cancelling Create mode." then load, read, and execute `{workflowFile}`.
- IF any other input: Display "Unknown option. Use **C**, **E**, or **X**." then redisplay menu.
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting the menu
- ONLY proceed to next step when user selects 'C'
- ONLY proceed to next step when user selects C, E, or X
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Existing file check performed, overwrite warning shown if needed, format spec loaded, session initialized, proceeding to step-c-02
### ❌ SYSTEM FAILURE: Existing file overwritten without warning, format spec not loaded, initiatives gathered prematurely, user not given overwrite choice
### ✅ SUCCESS: Existing file check performed, overwrite warning shown if needed, both templates loaded (format spec + process spec), session initialized, user chose gather/empty/cancel, proceeding appropriately
### ❌ SYSTEM FAILURE: Existing file overwritten without warning, templates not loaded, intakes gathered prematurely, user not given overwrite choice, empty-create path missing
**Master Rule:** Skipping steps is FORBIDDEN.
+62
-59
_bmad/bme/_enhance...ves-backlog/steps-c/step-c-02-gather.md
---
name: 'step-c-02-gather'
description: 'Interactively gather initiatives from the Product Owner with title, description, and category'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-03-score.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
description: 'Interactively gather initial intakes (unqualified findings) for the new lifecycle backlog'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-03-qualify.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md'

@@ -11,7 +11,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'

# Step 2: Interactive Initiative Gathering
# Step 2: Interactive Intake Gathering
## STEP GOAL:
Interactively gather initiatives from the Product Owner — each with a title, description, and category — building a list for RICE scoring in the next step.
Gather initial intakes from the user — each with a description and source — building a list that will pass through the qualifying gate in step-c-03. These items become Intake rows in §2.1 of the new lifecycle backlog; lane assignment happens only if the user runs qualification.

@@ -24,26 +24,25 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

- 🔄 CRITICAL: When loading next step with 'C', read the entire file
- 📋 YOU ARE A GATHERING FACILITATOR collecting initiative descriptions
- 📋 YOU ARE A GATHERING FACILITATOR collecting intake descriptions
### Role Reinforcement:
- ✅ You are a **gathering facilitator** — your job is to collect and organize, not to score or write
- ✅ Accept the user's descriptions faithfully — do not rewrite, editorialize, or merge initiatives
- ✅ Suggest existing category names from the format spec but allow new categories
- ✅ The user decides how many initiatives to add — you prompt until they say done
- ✅ You are a **gathering facilitator** — collect and organize, do not qualify or score
- ✅ Accept the user's descriptions faithfully — do not rewrite, editorialize, or merge intakes
- ✅ Every gathered item becomes an Intake (§2.1) — lane assignment is step-c-03's job
- ✅ The user decides how many intakes to add — you prompt until they say done
### Step-Specific Rules:
- 🎯 Focus ONLY on gathering initiative details (title, description, category)
- 🚫 FORBIDDEN to propose RICE scores (that is step-c-03's job)
- 🚫 FORBIDDEN to write the backlog file (that is step-c-04's job)
- 🚫 FORBIDDEN to reorder, merge, or drop initiatives without user instruction
- 💬 Approach: prompt for one initiative at a time, confirm capture, ask for next or done
- 🎯 Focus ONLY on gathering intake details (description, source)
- 🚫 FORBIDDEN to assign lane, portfolio, or RICE (step-c-03's job)
- 🚫 FORBIDDEN to write the backlog file (step-c-04's job)
- 🚫 FORBIDDEN to reorder, merge, or drop intakes without user instruction
- 💬 Approach: prompt for one intake at a time, confirm capture, ask for next or done
## EXECUTION PROTOCOLS:
- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Reference `{templateFile}` (backlog-format-spec.md) for category name suggestions
- 💾 Track all gathered initiatives in a running list
- 💾 Track all gathered intakes in a running list
## CONTEXT BOUNDARIES:
- Available context: Backlog format spec (for category names), session state from step-c-01
- Focus: Initiative gathering only
- Limits: Do NOT score, write to file, or analyze initiatives
- Available context: Session state from step-c-01, loaded templates
- Focus: Intake gathering only
- Limits: Do NOT qualify, write, or analyze
- Dependencies: step-c-01-init.md (session initialized)

@@ -58,17 +57,16 @@

Set up tracking:
- `gathered_items` = []
- `gathered_intakes` = []
- `item_count` = 0
### 2. Prompt for Initiative
### 2. Prompt for Intake
Display:
> **Initiative #[item_count + 1]**
> **Intake #[item_count + 1]**
>
> Describe your initiative:
> - **Title:** A short name for this initiative
> - **Description:** What it does and why it matters
> - **Category:** Suggested categories: Documentation & Onboarding, Update & Migration System, Testing & CI, Infrastructure, Agent Quality & Consistency, Platform & Product Vision — or name a new one
> Describe this intake:
> - **Description:** A one-line summary of the problem, idea, observation, or improvement
> - **Source:** Where it came from (e.g., "code review 2026-04-15", "retrospective", "user feedback", "party mode session", "audit finding")
>
> *You can provide all three in one message, or just describe the initiative and I'll help structure it.*
> *You can provide both fields in one message, or just describe the intake and I'll ask for the source.*

@@ -80,37 +78,40 @@ **ALWAYS halt and wait for user input.**

Parse the user's input to extract:
- **Title** — short, bold-formatted name
- **Description** — one-line explanation
- **Category** — one of the suggested categories or a new one
- **Description** — one-line summary
- **Source** — origin reference (required for audit trail)
If any field is unclear, ask the user to clarify before confirming.
If Source is missing, prompt: "What's the source of this intake?" and wait.
Display the captured initiative:
Display the captured intake:
> **Captured:**
> - **Title:** [title]
> - **Description:** [description]
> - **Category:** [category]
> - **Source:** [source]
> - **Date:** [current session date YYYY-MM-DD]
> - **Raiser:** [user identity — default to John if invoked via PM agent, otherwise ask]
Add to `gathered_items` with: title, description, category, source = "Create mode".
Increment `item_count`.
Add to `gathered_intakes` with all four fields. Increment `item_count`.
### 4. Present Per-Initiative Menu
### 4. Present Per-Intake Menu
Display:
> **Initiatives gathered so far: [item_count]**
> **Intakes gathered so far: [item_count]**
>
> **[N] Next** — Add another initiative
> **[D] Done** — Finish gathering and proceed to scoring
> **[A] Advanced Elicitation** — Deeper analysis to surface more initiatives
> **[P] Party Mode** — Multi-perspective brainstorming for initiatives
> - **[N] Next** — Add another intake
> - **[D] Done** — Finish gathering and proceed to qualifying gate (step-c-03)
> - **[SKIP] Skip qualification** — Finish gathering and go directly to file generation (step-c-04); all intakes remain raw in §2.1
> - **[A] Advanced Elicitation** — Deeper analysis to surface more intakes
> - **[P] Party Mode** — Multi-perspective brainstorming
#### Menu Handling Logic:
- IF N: Go to step 2 (prompt for next initiative).
- IF N: Go to step 2 (prompt for next intake).
- IF D:
- **If `item_count` >= 1:** Display gathered items summary table, then go to step 5.
- **If `item_count` == 0:** Display "You must add at least one initiative before proceeding." then redisplay this menu.
- IF A: Execute `{advancedElicitationTask}` for deeper initiative discovery. When finished, redisplay this menu.
- IF P: Execute `{partyModeWorkflow}` for multi-perspective brainstorming. When finished, redisplay this menu.
- IF any other input: Display "Unknown command. Use **N**, **D**, **A**, or **P**." then redisplay menu.
- **If `item_count` >= 1:** Display gathered intakes summary table, then advance to step-c-03.
- **If `item_count` == 0:** Display "No intakes gathered. Either add at least one (**N**), skip to empty generation (**SKIP**), or return to the T/R/C menu via [X]." Redisplay this menu.
- IF SKIP:
- **If `item_count` >= 1:** Pass `gathered_intakes` with no qualification (all remain raw) to step-c-04. Display summary, then load, read, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-04-generate.md`.
- **If `item_count` == 0:** Display "No intakes to skip qualification for. Either add at least one or use Empty create from step-c-01." Redisplay this menu.
- IF A: Execute `{advancedElicitationTask}`. When finished, redisplay menu.
- IF P: Execute `{partyModeWorkflow}`. When finished, redisplay menu.
- IF any other input: Display "Unknown command. Use **N**, **D**, **SKIP**, **A**, or **P**." then redisplay menu.

@@ -120,4 +121,4 @@ #### EXECUTION RULES:

- After A or P execution, return to this menu (not to the prompt)
- The user may add as many initiatives as they want — no upper limit
- Do NOT auto-continue — the user must explicitly select D to finish gathering
- The user may add as many intakes as they want — no upper limit
- Do NOT auto-continue — the user must explicitly select D, SKIP, or exit

@@ -128,15 +129,17 @@ ### 5. Gathering Complete — Summary and Advance

> **Gathering Complete — [item_count] initiatives collected**
> **Gathering Complete — [item_count] intakes collected**
>
> | # | Title | Category |
> |---|-------|----------|
> | 1 | [title] | [category] |
> | 2 | [title] | [category] |
> | # | Description | Source |
> |---|-------------|--------|
> | 1 | [description] | [source] |
> | 2 | [description] | [source] |
> | ... | ... | ... |
Then load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-03-score.md`, passing the `gathered_items` list.
Then advance based on the user's choice:
- **D (qualify):** Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-03-qualify.md`, passing `gathered_intakes`.
- **SKIP (no qualify):** Load, read, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-04-generate.md`, passing `gathered_intakes` and empty `qualified_items`.
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Each initiative captured with title, description, and category, user prompted for next or done, at least 1 initiative gathered, complete list passed to step-c-03
### ❌ SYSTEM FAILURE: Initiatives scored prematurely, descriptions rewritten without user approval, zero initiatives accepted, user forced to use specific format, gathered items not passed to next step
### ✅ SUCCESS: Each intake captured with description and source, user offered qualify-now or skip paths, at least 1 intake gathered when D or SKIP chosen, complete list passed to next step
### ❌ SYSTEM FAILURE: Intakes qualified prematurely, descriptions rewritten without approval, source missing, zero intakes accepted for D/SKIP paths, gathered items lost
**Master Rule:** Skipping steps is FORBIDDEN.
+65
-35
_bmad/bme/_enhance...tives-backlog/steps-r/step-r-01-load.md
---
name: 'step-r-01-load'
description: 'Load existing backlog and RICE scoring guide for Review mode walkthrough'
description: 'Load existing lifecycle backlog, let user choose which lane(s) to walk, and prepare item list for rescoring'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-r/step-r-02-rescore.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/rice-scoring-guide.md'

@@ -10,7 +10,7 @@ workflowFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md'

# Step 1: Load Backlog & Walkthrough Setup
# Step 1: Load Backlog & Choose Lanes
## STEP GOAL:
Load the existing backlog file and RICE scoring guide, parse all active items with their current scores and provenance, and prepare for the per-item walkthrough.
Load the existing lifecycle backlog file and RICE scoring guide, parse items from all three lanes (Bug / Fast / Initiative), and let the user choose which lane(s) to walk for rescoring in step-r-02.

@@ -28,10 +28,11 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

- ✅ Parse the backlog faithfully — do not reinterpret, reorder, or filter items
- ✅ The walkthrough starts in step-r-02 — this step only loads and counts
- ✅ The walkthrough starts in step-r-02 — this step only loads, counts, and lets the user choose scope
### Step-Specific Rules:
- 🎯 Focus ONLY on loading, parsing, and counting backlog items
- 🎯 Focus ONLY on loading, parsing, counting, and lane scope selection
- 🚫 FORBIDDEN to rescore, modify, or delete any backlog items (that is step-r-02's job)
- 🚫 FORBIDDEN to write to the backlog file (that is step-r-03's job)
- 🚫 FORBIDDEN to add new items (that is Triage mode's job)
- 💬 Approach: load efficiently, confirm readiness, move on
- 🚫 FORBIDDEN to read or parse items from §2.1 Intakes or §2.5 Absorbed — Review only walks lane items (§2.2/2.3/2.4)
- 💬 Approach: load efficiently, summarize lanes, let user choose scope, move on

@@ -45,3 +46,3 @@ ## EXECUTION PROTOCOLS:

- Available context: Existing backlog file, RICE scoring guide template
- Focus: Data loading and preparation only
- Focus: Data loading, lane summary, scope selection
- Limits: Do NOT modify, score, or write anything

@@ -60,5 +61,5 @@ - Dependencies: workflow.md R dispatch (Review mode selected)

> **No backlog found at `{outputFile}`.**
> **No lifecycle backlog found at `{outputFile}`.**
>
> Review mode requires an existing backlog to walk through. Use **Triage (T)** or **Create (C)** mode first to create one.
> Review mode requires an existing backlog to walk through. Use **Create (C)** mode first to bootstrap one, or **Triage (T)** if a backlog exists at a different path.
>

@@ -81,45 +82,74 @@ > Returning to mode selection...

- **Calibration examples** from the existing backlog
- **Composite formula:** Score = (R x I x C) / E, where C is decimal (e.g., 70% = 0.7)
- **Composite formula:** Score = (R × I × C) / E, where C is decimal (e.g., 70% = 0.7)
- **Score rounding:** One decimal place for display
- **Lane-specific scoring notes:** Bug impact often hardcoded high; Fast Lane effort typically 1-3; Initiative effort reflects pipeline + execution
### 3. Parse Active Backlog Items
### 3. Parse Lane Items
Parse all category tables **under `## Backlog`** to collect items with:
- Item ID (e.g., D2, P4)
- Title and description
- Category (H3 heading name)
- Current RICE component scores (R, I, C, E)
- Current composite score
- Current provenance (from Initiative description cell)
- Current status
Parse tables from lane sections:
**Do NOT include** items from `## Exploration Candidates`, `## Completed`, or other sections outside `## Backlog`.
- **§2.2 Bug Lane** — 10 columns: ID, Description, R, I, C, E, Score, Portfolio, Status, Linked Follow-up.
- **§2.3 Fast Lane** — 9 columns: ID, Description, R, I, C, E, Score, Portfolio, Status.
- **§2.4 Initiative Lane** — 10 columns: ID, Description, R, I, C, E, Score, Portfolio, Stage, Artifacts.
**Do NOT include** items from:
- §2.1 Intakes (unqualified — no RICE)
- §2.5 Absorbed / Archived (removed from active)
- Any section outside `## Part 2: Backlog`
### 4. Count and Summarize
Count the total number of active items collected. Display:
Display a lane summary:
> **Review Mode — Backlog Loaded**
>
> **Items found:** [N] active items across [M] categories
> **Categories:** [list category names]
> **Score range:** [lowest] to [highest]
> | Lane | Items | Score range |
> |------|-------|-------------|
> | §2.2 Bug Lane | [n] | [low]–[high] |
> | §2.3 Fast Lane | [n] | [low]–[high] |
> | §2.4 Initiative Lane | [n] | [low]–[high] |
> | **Total** | **[N]** | |
>
> The walkthrough will present each item one at a time for review. You can rescore, confirm, skip, or exit early at any point.
> *Rescoring applies to these lane items only. Intakes (§2.1) have no RICE and are not included in Review.*
### 5. Present MENU OPTIONS
### 5. Present Lane Selection Menu
Display: "**Select:** [C] Continue to item walkthrough"
Display:
> **Select lane(s) to walk:**
>
> - **[B] Bug Lane only** — [n] items
> - **[F] Fast Lane only** — [n] items
> - **[I] Initiative Lane only** — [n] items
> - **[A] All lanes** — [N] items (walk in order Bug → Fast → Initiative)
> - **[T] Top N by score** — walk top N items across all lanes (prompt for N)
> - **[X] Exit** — return to mode selection
#### Menu Handling Logic:
- IF C: Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-r/step-r-02-rescore.md`
- IF any other input: Display "Enter **C** to continue to the walkthrough." then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting the menu
- ONLY proceed to next step when user selects 'C'
- IF B: Set walk scope to Bug Lane items only.
- IF F: Set walk scope to Fast Lane items only.
- IF I: Set walk scope to Initiative Lane items only.
- IF A: Set walk scope to all lane items in order Bug → Fast → Initiative.
- IF T: Prompt "How many top-ranked items?". Accept integer N ≥ 1. Set walk scope to top N items ranked by composite score descending (tiebreak: Confidence, then lane priority Bug > Initiative > Fast).
- IF X: Display "Exiting Review mode." then load, read, and execute `{workflowFile}`.
- IF any other input: Display "Unknown option. Use B / F / I / A / T / X." then redisplay menu.
### 6. Confirm Scope & Advance
After scope selection, display:
> **Walkthrough scope:** [description, e.g., "Fast Lane — 65 items"]
>
> **[C] Continue to walkthrough**
> **[R] Re-select scope**
> **[X] Exit**
- IF C: Pass `walk_scope` (ordered list of items with full data) to step-r-02. Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-r/step-r-02-rescore.md`.
- IF R: Go back to step 5.
- IF X: Load, read, and execute `{workflowFile}`.
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Backlog file loaded, RICE guide internalized, all active items parsed with scores and provenance, item count displayed, proceeding to step-r-02
### ❌ SYSTEM FAILURE: Backlog not loaded, items from wrong sections included, items modified or filtered, scoring guide not loaded, missing backlog not handled gracefully
### ✅ SUCCESS: Backlog file loaded, RICE guide internalized, lane items parsed from §2.2/2.3/2.4 only, lane summary displayed, user chose scope, scope list passed to step-r-02
### ❌ SYSTEM FAILURE: Backlog not loaded, items from wrong sections included (Intakes / Absorbed), lanes not distinguished, scope selection skipped, missing backlog not handled gracefully
**Master Rule:** Skipping steps is FORBIDDEN.
+60
-30
_bmad/bme/_enhance...es-backlog/steps-r/step-r-02-rescore.md
---
name: 'step-r-02-rescore'
description: 'Walk through backlog items one at a time for rescoring with RICE adjustments'
description: 'Walk lane items one at a time for RICE rescoring, lane-aware (Bug / Fast / Initiative)'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-r/step-r-03-update.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/rice-scoring-guide.md'

@@ -11,7 +11,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'

# Step 2: Item Walkthrough & Rescoring
# Step 2: Lane Walkthrough & Rescoring
## STEP GOAL:
Walk through backlog items one at a time, presenting current scores and provenance, and allow the Product Owner to rescore, confirm, or skip each item. Track all decisions for the update step.
Walk through the selected lane items one at a time, presenting current scores and lane-specific context (Bug status, Fast Lane RICE, Initiative stage + artifacts), and allow the user to rescore, confirm, or skip each item. Track all decisions for the update step.

@@ -28,5 +28,5 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

- ✅ You are a **rescoring analyst** — systematic, evidence-based, calibration-aware
- ✅ Present items faithfully with all current data — do not editorialize or suggest scores unless asked via A
- ✅ Present items faithfully with all current data — do not editorialize unless user invokes A
- ✅ The user decides what changes to make — you calculate, display, and record
- ✅ Compare adjusted scores against calibration examples for consistency
- ✅ Lane-aware: bugs emphasize risk-vs-cost, Fast Lane emphasizes effort, Initiative Lane includes Stage + Artifacts context

@@ -37,5 +37,5 @@ ### Step-Specific Rules:

- 🚫 FORBIDDEN to add new items (that is Triage mode's job)
- 🚫 FORBIDDEN to delete or remove items from the backlog
- 🚫 FORBIDDEN to delete or promote/demote items between lanes (lane changes require separate qualification — noted for future item)
- 🚫 FORBIDDEN to auto-advance without user input — ALWAYS halt and wait
- 💬 Approach: present one item, wait for decision, record result, advance
- 💬 Approach: present one item with its lane context, wait for decision, record result, advance

@@ -48,6 +48,6 @@ ## EXECUTION PROTOCOLS:

## CONTEXT BOUNDARIES:
- Available context: Parsed backlog items from step-r-01, RICE scoring guide
- Available context: `walk_scope` from step-r-01 (ordered list of lane items), RICE scoring guide
- Focus: Per-item walkthrough and rescoring only
- Limits: Do NOT write to backlog or modify the file
- Dependencies: step-r-01-load.md (loaded and parsed items)
- Limits: Do NOT write to backlog, do NOT change item lanes
- Dependencies: step-r-01-load.md (loaded items + scope)

@@ -60,19 +60,42 @@ ## MANDATORY SEQUENCE

Set up tracking for the walkthrough:
Set up tracking:
- `current_index` = 1
- `total_items` = count from step-r-01
- `rescored_items` = [] (items with changed scores)
- `confirmed_items` = [] (items explicitly confirmed or C'd without changes)
- `skipped_items` = [] (items skipped)
- `total_items` = count from `walk_scope`
- `rescored_items` = [] — items with changed composite score
- `confirmed_items` = [] — items explicitly confirmed or C'd without changes
- `skipped_items` = [] — items skipped
### 2. Present Current Item
### 2. Present Current Item (Lane-Aware)
Display the current item with all scoring data:
Display the current item with lane-specific context:
> **Item [current_index] of [total_items] — [Category Name]**
**If Bug Lane item:**
> **Item [current_index] of [total_items] — §2.2 Bug Lane**
>
> **[ID]: [Title]** — Score: [composite]
> **[ID]: [Description]** — Score: [composite]
> R:[reach] I:[impact] C:[confidence]% E:[effort]
> *Provenance: [current provenance text]*
> *Status: [Open/In Fix/In Review/Shipped]*
> *Portfolio: [portfolio]*
> *Linked Follow-up: [fastLaneID or initiativeID, if any]*
**If Fast Lane item:**
> **Item [current_index] of [total_items] — §2.3 Fast Lane**
>
> **[ID]: [Description]** — Score: [composite]
> R:[reach] I:[impact] C:[confidence]% E:[effort]
> *Status: [Backlog/In Story/In Sprint/Shipped]*
> *Portfolio: [portfolio]*
**If Initiative Lane item:**
> **Item [current_index] of [total_items] — §2.4 Initiative Lane**
>
> **[ID]: [Description]** — Score: [composite]
> R:[reach] I:[impact] C:[confidence]% E:[effort]
> *Stage: [Qualified / In Pipeline / Ready / In Sprint / Done]*
> *Portfolio: [portfolio]*
> *Artifacts: [artifacts indicator, e.g., "D, P✓, A, IR, E" or "ADR only" or "—"]*
### 3. Present Per-Item Menu

@@ -98,6 +121,8 @@

> **[C] Continue** — Apply changes and advance to next item
>
> *Note: Changing an item's lane, stage, portfolio, or status is NOT done in Review mode. If this item's lane no longer fits, raise a new intake via Triage mode.*
#### Menu Handling Logic:
- IF `R [value]`: Validate value is integer 1-10. Update Reach for current item. Recalculate composite: Score = (R x I x C) / E. Redisplay updated item scores and menu.
- IF `R [value]`: Validate value is integer 1-10. Update Reach for current item. Recalculate composite: Score = (R × I × C) / E. Redisplay updated item scores and menu.
- IF `I [value]`: Validate value is one of 0.25, 0.5, 1, 2, or 3. Update Impact. Recalculate composite. Redisplay updated item scores and menu.

@@ -109,7 +134,7 @@ - IF `CF [value]`: Validate value is integer 20-100. Update Confidence. Recalculate composite. Redisplay updated item scores and menu.

- IF X: Exit walkthrough early. Go to step 5.
- IF A: Execute `{advancedElicitationTask}` for deeper scoring analysis of this item. When finished, redisplay the current item scores and this menu.
- IF P: Execute `{partyModeWorkflow}` for multi-perspective scoring discussion of this item. When finished, redisplay the current item scores and this menu.
- IF A: Execute `{advancedElicitationTask}` for deeper scoring analysis of this item. When finished, redisplay.
- IF P: Execute `{partyModeWorkflow}` for multi-perspective discussion. When finished, redisplay.
- IF C:
- **If scores were changed:** Record old and new composite scores. Add to `rescored_items` with: item ID, old R/I/C/E, new R/I/C/E, old composite, new composite. Advance to next item (go to step 4).
- **If NO scores were changed:** Treat as confirmed (same as K). Add to `confirmed_items`. Advance to next item (go to step 4).
- **If scores were changed:** Record old and new composite scores. Add to `rescored_items` with lane name, item ID, old R/I/C/E, new R/I/C/E, old composite, new composite. Advance.
- **If NO scores were changed:** Treat as confirmed (same as K). Advance.
- IF any other input: Display "Unknown command. Use `R/I/CF/E [value]`, `K`, `S`, `X`, `A`, `P`, or `C`." then redisplay menu.

@@ -140,10 +165,15 @@

> [If early exit: **Unvisited:** [N] items]
>
> **Rescored breakdown by lane:**
> - §2.2 Bug Lane: [n]
> - §2.3 Fast Lane: [n]
> - §2.4 Initiative Lane: [n]
Then load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-r/step-r-03-update.md`, passing:
- The list of rescored items (with old/new R/I/C/E and composite scores)
- The counts of confirmed, skipped, and unvisited items
- `rescored_items` (each with lane name, ID, old and new R/I/C/E, old and new composites)
- Counts of confirmed, skipped, and unvisited items
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Each item presented with full scoring data and provenance, user given per-item decision, score adjustments recalculated correctly, all decisions tracked (rescored/confirmed/skipped), results passed to step-r-03
### ❌ SYSTEM FAILURE: Items auto-advanced without user input, scores not recalculated after adjustment, decisions not tracked, items modified in backlog file, walkthrough skipped items silently
### ✅ SUCCESS: Each lane item presented with lane-specific context (status / stage / artifacts), user given per-item decision, score adjustments recalculated correctly, all decisions tracked by lane, results passed to step-r-03
### ❌ SYSTEM FAILURE: Items auto-advanced without input, lane context missing, scores not recalculated after adjustment, decisions not tracked, lane changes attempted, items modified in backlog file
**Master Rule:** Skipping steps is FORBIDDEN.
+67
-71
_bmad/bme/_enhance...ves-backlog/steps-r/step-r-03-update.md
---
name: 'step-r-03-update'
description: 'Apply rescores to backlog, regenerate prioritized view, present completion summary'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
description: 'Apply rescores in-place to lane tables, re-sort touched lanes, update Change Log, present completion summary'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md'

@@ -9,7 +9,7 @@ workflowFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md'

# Step 3: Backlog Update, Safety & Completion
# Step 3: Backlog Update — Apply Rescores Lane-Aware
## STEP GOAL:
Validate backlog structure, apply rescored items in-place, regenerate the prioritized view, and present a completion summary before returning to the T/R/C menu.
Validate backlog structure, apply rescored items in-place in their lane tables (§2.2 Bug / §2.3 Fast / §2.4 Initiative), re-sort only the lanes that were touched, update the Change Log, and present a completion summary before returning to the T/R/C menu.

@@ -26,13 +26,14 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

- ✅ You are a **backlog operations specialist** — precise, non-destructive, in-place updates only
- ✅ Preserve all existing content — never delete, overwrite, or reorder existing rows
- ✅ The Prioritized View is the ONLY section regenerated from scratch
- ✅ All output must be standard markdown — no HTML, no proprietary syntax
- ✅ Preserve all existing content outside of the rescored rows and the sort order of their lanes
- ✅ **Part 1 (Lifecycle Process) must not be modified** — it's semi-static documentation
- ✅ **§2.1 Intakes and §2.5 Absorbed must not be modified** — Review does not touch them
- ✅ Re-sort only the touched lanes — untouched lanes keep their current row order
### Step-Specific Rules:
- 🎯 Focus on validation, safe in-place updates, and completion reporting
- 🚫 FORBIDDEN to delete or reorder existing backlog items (FR18, NFR1)
- 🚫 FORBIDDEN to add new items (that is Triage mode's job)
- 🚫 FORBIDDEN to modify items that were confirmed or skipped — only rescored items are updated
- 🚫 FORBIDDEN to modify step-r-01 or step-r-02
- 💬 Approach: validate first, update safely, summarize clearly
- 🎯 Focus on validation, safe in-place updates, lane-specific re-sort, and completion reporting
- 🚫 FORBIDDEN to delete or add rows (add = Triage, remove = Absorb via separate flow)
- 🚫 FORBIDDEN to modify items that were confirmed or skipped
- 🚫 FORBIDDEN to change items' lane / portfolio / stage / status (Review only rescores RICE)
- 🚫 FORBIDDEN to modify Part 1, §2.1, or §2.5
- 💬 Approach: validate first, update rescored rows in-place, re-sort touched lanes, summarize

@@ -45,6 +46,6 @@ ## EXECUTION PROTOCOLS:

## CONTEXT BOUNDARIES:
- Available context: Rescored items from step-r-02, existing backlog file, backlog format spec template
- Focus: Structural validation, safe in-place update, prioritized view regeneration, completion summary
- Limits: Do NOT rescore, re-extract, or add items
- Dependencies: step-r-02-rescore.md (rescored/confirmed/skipped results)
- Available context: `rescored_items` from step-r-02 (with lane, ID, old+new scores), existing backlog, format spec
- Focus: Structural validation, in-place update, per-lane re-sort, Change Log, completion summary
- Limits: Do NOT rescore, re-extract, add items, or change lane metadata
- Dependencies: step-r-02-rescore.md (rescored + confirmed + skipped results)

@@ -57,25 +58,19 @@ ## MANDATORY SEQUENCE

Load `{outputFile}` (existing backlog) and validate structural integrity:
Load `{outputFile}` and validate per format spec:
1. **Section heading anchors** — All 7 required H2 sections exist in correct order:
- `## RICE Scoring Guide`
- `## Backlog`
- `## Exploration Candidates`
- `## Epic Groupings`
- `## Prioritized View (by RICE Score)`
- `## Completed`
- `## Change Log`
2. **Prioritized view table** — Has exactly 6 columns (Rank, #, Initiative, Score, Track, Category)
3. **Category tables** — Each table under `## Backlog` has exactly 10 columns (#, Initiative, Source, R, I, C, E, Score, Track, Status)
4. **Change Log section** — The `## Change Log` H2 section exists with a table
1. **Frontmatter present**
2. **Part 1 anchor exists** (not inspected for content)
3. **Part 2 H3 anchors** — `### 2.1` through `### 2.5` in correct order
4. **Lane table column counts** — Bug (10), Fast (9), Initiative (10)
5. **Change Log section** — `## Change Log` H2 exists
If ALL checks pass, proceed directly to step 3 (Apply Rescores).
If ALL checks pass, proceed to step 3.
### 2. Mismatch Handling
If ANY validation check fails, present the specific mismatch(es):
If ANY validation check fails:
> **Pre-Write Validation — Structural Mismatch Detected**
>
> [List each failed check with details]
> [List each failed check]
>

@@ -85,49 +80,45 @@ > **[Y] Yes, proceed anyway**

**ALWAYS halt and wait for user input.**
**ALWAYS halt and wait.**
- IF Y: Continue to step 3 (Apply Rescores)
- IF X: Display "Aborting backlog update." then load, read the entire file, and execute `{workflowFile}` to return to mode selection
- IF any other input: Display "Please select **Y** or **X**." then redisplay the prompt
- IF Y: Continue to step 3.
- IF X: Display "Aborting backlog update." then load, read, and execute `{workflowFile}`.
- IF any other input: Display "Please select **Y** or **X**." then redisplay.
### 3. Apply Rescores
### 3. Apply Rescores In-Place
For each rescored item from step-r-02:
For each item in `rescored_items`:
1. **Find the item** — Locate the row in its category table under `## Backlog` by matching the item ID
2. **Update RICE scores** — Replace R, I, C, E, and composite Score values in the row
3. **Add rescore provenance** — Append to the Initiative description cell: `Rescored [old]->[new], Review, [date]` where [old] and [new] are the composite scores and [date] is the current session date (FR22)
4. **Preserve everything else** — Do not modify the item's title, source, track, status, or any other content
1. **Find the item** — Locate the row in the correct lane table (§2.2 / 2.3 / 2.4) by matching the item ID.
2. **Update RICE columns** — Replace R, I, C, E, and composite Score values in the row.
3. **Preserve everything else** — Do not modify Description, Portfolio, Status, Stage, Artifacts, Linked Follow-up, or any non-RICE column.
4. **Optional rescore provenance** — If the Description cell has capacity, append a subtle note: ` [rescored YYYY-MM-DD: X.X→Y.Y]`. Skip if the cell would exceed readable length.
**Important:**
- Only update items that were actually rescored (composite score changed)
- Confirmed and skipped items remain completely unchanged — no provenance added
- Do NOT reorder rows within category tables
- Only update items whose composite score actually changed.
- Confirmed and skipped items remain completely unchanged — no modification, no note.
- Do NOT modify rows not in `rescored_items`.
### 4. Regenerate Prioritized View
### 4. Re-Sort Touched Lanes
Rebuild the `## Prioritized View (by RICE Score)` table from scratch:
For each lane that had at least one rescored item:
1. Collect ALL active items from all category tables (existing + rescored)
2. Exclude items with Status "Done" or items in the `## Completed` section
3. Sort by composite RICE score descending
4. Tiebreak: (1) Higher Confidence first, (2) Newer insertion order first
5. Generate sequential rank numbers starting at 1
1. Collect all rows in that lane's table.
2. Sort by composite RICE score **descending**.
3. Tiebreak: (1) Confidence higher first, (2) insertion order newer first.
4. Rewrite the lane's table body with the sorted rows.
Table format (6 columns):
```
| Rank | # | Initiative | Score | Track | Category |
|------|---|-----------|-------|-------|----------|
```
**Do NOT re-sort lanes that were not touched** — preserve their current order. This keeps `git diff` minimal for lanes the session didn't review.
### 5. Add Changelog Entry
### 5. Add Change Log Entry
Prepend a new row to the `## Change Log` table (newest first):
Prepend a new row to `## Change Log`:
```
| YYYY-MM-DD | Review: Rescored [N] items, confirmed [N], skipped [N]. |
| YYYY-MM-DD | Review: Rescored [N] items — Bug: [n], Fast: [n], Initiative: [n]. Confirmed: [N], skipped: [N][, unvisited: N]. Lanes re-sorted: [list]. |
```
### 6. Update Last Updated Date
### 6. Update Frontmatter
Set the metadata header `Last Updated` field to the current date (YYYY-MM-DD format).
- Do NOT modify the `created` date.
- Frontmatter `status` stays as-is (typically `active`).

@@ -141,10 +132,15 @@ ### 7. Completion Summary & Return to Menu

> **Items rescored:** [N]
> **Items confirmed:** [N]
> **Items skipped:** [N]
> [If early exit: **Items unvisited:** [N]]
> - §2.2 Bug Lane: [n]
> - §2.3 Fast Lane: [n]
> - §2.4 Initiative Lane: [n]
> **Confirmed:** [N]
> **Skipped:** [N]
> [If early exit: **Unvisited:** [N]]
>
> **New Top 3 Positions:**
> 1. [#ID] [title] — Score: [X.X]
> 2. [#ID] [title] — Score: [X.X]
> 3. [#ID] [title] — Score: [X.X]
> **Lanes re-sorted:** [list, e.g., "Fast Lane, Initiative Lane"]
>
> **Top 3 across touched lanes (post-sort):**
> 1. [#ID] [title] — Score: [X.X] — Lane: [lane]
> 2. [#ID] [title] — Score: [X.X] — Lane: [lane]
> 3. [#ID] [title] — Score: [X.X] — Lane: [lane]

@@ -158,4 +154,4 @@ Then return to the T/R/C menu:

## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Pre-write validation performed, only rescored items updated in-place with correct provenance, confirmed/skipped items untouched, prioritized view regenerated with all items sorted correctly, changelog updated, completion summary displayed with top 3, T/R/C menu re-presented
### ❌ SYSTEM FAILURE: Existing backlog content deleted/overwritten/reordered, confirmed or skipped items modified, provenance added to non-rescored items, items written without validation, prioritized view not regenerated, no completion summary, no return to menu
### ✅ SUCCESS: Validation performed, only rescored items updated in-place with RICE changes, confirmed/skipped items untouched, only touched lanes re-sorted (untouched lanes preserved), Part 1 / §2.1 / §2.5 untouched, Change Log updated with per-lane counts, completion summary displayed, menu re-presented
### ❌ SYSTEM FAILURE: Rows added or removed, items' lane/stage/status modified, Part 1 or §2.1 or §2.5 altered, untouched lanes re-sorted unnecessarily, Change Log missing lane breakdown, provenance added to confirmed/skipped items
**Master Rule:** Skipping steps is FORBIDDEN.
+12
-12
_bmad/bme/_enhance...ves-backlog/steps-t/step-t-01-ingest.md

@@ -5,3 +5,3 @@ ---

nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-02-extract.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
---

@@ -13,3 +13,3 @@

Accept the Product Owner's text input (review transcript, meeting notes, audit output, or any findings source) and prepare it for extraction in the next step.
Accept the user's text input (review transcript, meeting notes, audit output, party mode output, or any findings source) and prepare it for extraction in the next step.

@@ -31,4 +31,4 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

- 🎯 Focus ONLY on accepting and preserving input text
- 🚫 FORBIDDEN to extract findings, classify, or score in this step — that is step-t-02's job
- 🚫 FORBIDDEN to truncate, summarize, or skip any part of the input regardless of length (FR46)
- 🚫 FORBIDDEN to extract findings, classify, log, or qualify in this step — those are later steps' job
- 🚫 FORBIDDEN to truncate, summarize, or skip any part of the input regardless of length
- 💬 Approach: brief prompts, minimal overhead, get to the content quickly

@@ -38,3 +38,3 @@

- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load existing backlog if present — it will be needed for overlap detection in step-t-02
- 📖 Load existing backlog if present — it will be needed for overlap detection and for appending in later steps

@@ -44,4 +44,4 @@ ## CONTEXT BOUNDARIES:

- Focus: Accepting user input only
- Limits: Do NOT analyze, classify, or score input
- Dependencies: workflow.md T dispatch (completed in Story 1.3)
- Limits: Do NOT analyze, classify, or qualify input
- Dependencies: workflow.md T dispatch

@@ -54,6 +54,6 @@ ## MANDATORY SEQUENCE

Check if an existing backlog file exists at `{planning_artifacts}/initiatives-backlog.md`.
Check if an existing backlog file exists at `{outputFile}`.
- **If found:** Load it silently — it will be used for overlap detection in step-t-02. Briefly note to the user: "Existing backlog loaded — overlap detection will be available during extraction."
- **If not found:** Note silently — step-t-02 will skip overlap detection. Briefly note: "No existing backlog found — a new one will be created."
- **If found:** Load it silently — it will be used for overlap detection in step-t-02 and for writes in step-t-04. Briefly note to the user: "Existing lifecycle backlog loaded — overlap detection against current Intakes and lane items will be available during extraction."
- **If not found:** Note silently — step-t-02 will skip overlap detection. Briefly note: "No existing backlog found. Note: Triage cannot create a new backlog — use Create mode [C] for that. Triage will still extract findings but the final update step will require an existing file."

@@ -64,3 +64,3 @@ ### 2. Prompt for Text Input

> **Triage Mode — Paste your review findings below.**
> **Triage Mode — Paste your findings below.**
>

@@ -75,3 +75,3 @@ > Accepted formats: review transcripts, meeting notes, audit outputs, party-mode outputs, code review findings, retrospective notes, or any text containing actionable observations.

- Preserve it exactly as provided — do not modify, reformat, or summarize
- Process the **entire** input regardless of length (FR46)
- Process the **entire** input regardless of length
- Confirm receipt: "Received [N] lines of input. Ready to extract findings."

@@ -78,0 +78,0 @@ 

+49
-44
_bmad/bme/_enhance...es-backlog/steps-t/step-t-02-extract.md
---
name: 'step-t-02-extract'
description: 'Extract actionable findings from input, classify, detect overlaps, and validate at Gate 1'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-03-score.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
description: 'Extract actionable findings from input, detect overlaps with existing Intakes and lane items, and validate the extraction batch'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-03-qualify.md'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md'

@@ -13,3 +13,3 @@ ---

Extract actionable findings from the ingested text, classify each into a backlog category, detect overlaps with existing backlog items, and present the batch for user validation at Gate 1.
Extract actionable findings from the ingested text, detect overlaps with existing Intakes and lane items, and present the batch for user validation at Gate 1. Each validated finding will become an **Intake** (§2.1) in the backlog — not directly a lane item.

@@ -28,8 +28,10 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

- ✅ The user validates your extraction at Gate 1 — you propose, they decide
- ✅ Every finding becomes an Intake — lane assignment is a separate step (step-t-03 Qualify)
### Step-Specific Rules:
- 🎯 Focus on extraction, classification, and overlap detection
- 🚫 FORBIDDEN to score findings (RICE scoring is step-t-03's job)
- 🎯 Focus on extraction, overlap detection against Intakes and lane items, and Gate 1 validation
- 🚫 FORBIDDEN to assign a lane (Bug/Fast/Initiative) — that is step-t-03's job (the qualifying gate)
- 🚫 FORBIDDEN to score RICE — that is step-t-03's job for qualified items
- 🚫 FORBIDDEN to write to the backlog file (that is step-t-04's job)
- 🚫 FORBIDDEN to truncate or skip any part of the input text (FR46)
- 🚫 FORBIDDEN to truncate or skip any part of the input text
- 💬 Approach: systematic extraction, then collaborative validation at Gate 1

@@ -39,9 +41,9 @@

- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load {templateFile} for category reference
- 📖 Load {templateFile} for file structure reference
- 💾 Track extraction state — redisplay updated batch after every Gate 1 edit
## CONTEXT BOUNDARIES:
- Available context: User's input text (from step-t-01), existing backlog (if loaded), backlog format spec template
- Available context: User's input text (from step-t-01), existing backlog (if loaded), backlog format spec
- Focus: Extraction and Gate 1 validation only
- Limits: Do NOT score or write to backlog
- Limits: Do NOT qualify findings into lanes or write to backlog
- Dependencies: step-t-01-ingest.md (input text accepted)

@@ -53,18 +55,12 @@

### 1. Load Category Reference
### 1. Load Format Reference
Load `{templateFile}` (backlog-format-spec.md) and extract the category names from the "Category Names" section. Current categories:
Load `{templateFile}` (backlog-format-spec.md) and note the structure:
- §2.1 Intakes is the append target for this step's output
- §2.2 Bug Lane, §2.3 Fast Lane, §2.4 Initiative Lane contain already-qualified items
- §2.5 Absorbed / Archived contains removed items
- Documentation & Onboarding
- Update & Migration System
- Testing & CI
- Infrastructure
- Agent Quality & Consistency
- Platform & Product Vision
New categories may be proposed if a finding doesn't fit any existing category.
### 2. Extract Actionable Findings
Process the **complete** input text from step-t-01. Do NOT truncate, summarize, or skip sections (FR46).
Process the **complete** input text from step-t-01. Do NOT truncate, summarize, or skip sections.

@@ -75,2 +71,3 @@ For each passage in the input, determine if it is **actionable**. A finding is actionable if it:

- **Flags a risk** (something could go wrong)
- **Reports a break** (something is observably broken)

@@ -81,6 +78,5 @@ Non-actionable content (general comments, praise, questions without implied action, status updates) should be set aside as **observations** — they are NOT included in the extraction batch but may be escalated at Gate 1.

1. **Finding number** — sequential (1, 2, 3...)
2. **Title** — concise summary (matches backlog Initiative column style)
3. **Category** — one of the categories from step 1 (or propose a new one)
4. **Source reference** — which part of the input it came from (e.g., "paragraph 3", "under 'Performance Issues' heading", "line about caching") (FR4)
5. **Type** — Change / Gap / Risk
2. **Title** — concise summary (matches lane table style)
3. **Source reference** — which part of the input it came from (e.g., "paragraph 3", "under 'Performance Issues' heading", "line about caching")
4. **Type** — Change / Gap / Risk / Break

@@ -91,7 +87,14 @@ ### 3. Detect Overlaps with Existing Backlog

For each extracted finding, compare against existing backlog items by semantic similarity (title + description). Flag potential overlaps when a finding appears to address the same concern as an existing item.
For each extracted finding, compare against **all existing items**:
- §2.1 Intakes (unqualified items)
- §2.2 Bug Lane items
- §2.3 Fast Lane items
- §2.4 Initiative Lane items
- §2.5 Absorbed/Archived items (flag if finding restates something already absorbed)
Compare by semantic similarity (title + description). Flag potential overlaps when a finding appears to address the same concern as an existing item.
For each overlap flag, record:
- The existing item's **ID** (e.g., D2, P4)
- The existing item's **title**
- The existing item's **location** (Intakes, Fast Lane, Initiative Lane, Absorbed, etc.)
- The existing item's **ID** and **title**
- Brief explanation of why it might overlap

@@ -107,3 +110,3 @@

>
> The input contained no content that proposes a change, identifies a gap, or flags a risk.
> The input contained no content that proposes a change, identifies a gap, flags a risk, or reports a break.
>

@@ -129,7 +132,7 @@ > **Options:**

>
> | # | Finding | Category | Source | Type | Overlap |
> |---|---------|----------|--------|------|---------|
> | 1 | [title] | [category] | [source ref] | Change | — |
> | 2 | [title] | [category] | [source ref] | Gap | ⚠️ Overlaps D2: "[existing title]" |
> | 3 | [title] | [category] | [source ref] | Risk | — |
> | # | Finding | Source | Type | Overlap |
> |---|---------|--------|------|---------|
> | 1 | [title] | [source ref] | Change | — |
> | 2 | [title] | [source ref] | Gap | ⚠️ Overlaps §2.3 Fast Lane I15: "[existing title]" |
> | 3 | [title] | [source ref] | Break | — |
>

@@ -139,2 +142,4 @@ > **Observations (not included — escalate with `E` if actionable):**

> - [observation 2]
>
> *Each validated finding will be logged as an Intake (§2.1). Qualification into a lane happens in the next step.*

@@ -148,5 +153,5 @@ ### 6. Present GATE 1 MENU OPTIONS

> **Overlap resolution** (for flagged items only):
> - `merge #N` — Absorb finding into the existing overlapping item
> - `merge #N` — Absorb finding into the existing overlapping item (no new intake created)
> - `skip #N` — Drop finding (existing item is sufficient)
> - `new #N` — Override overlap flag, keep as separate new item
> - `new #N` — Override overlap flag, keep as separate new intake
>

@@ -158,3 +163,3 @@ > **Batch editing:**

>
> **[C] Continue** — Finalize batch and proceed to RICE scoring
> **[C] Continue** — Finalize batch and proceed to qualifying gate

@@ -164,7 +169,7 @@ #### Menu Handling Logic:

- IF `skip #N`: Remove finding #N from batch. Redisplay updated batch and menu.
- IF `new #N`: Clear overlap flag on finding #N (will be added as new item). Redisplay updated batch and menu.
- IF `E #N`: Move observation #N into the findings batch as actionable. Assign a category and source ref. Redisplay updated batch and menu.
- IF `+ [text]`: Add a new finding to the batch. Ask user for category if not obvious. Redisplay updated batch and menu.
- IF `new #N`: Clear overlap flag on finding #N (will be added as new intake). Redisplay updated batch and menu.
- IF `E #N`: Move observation #N into the findings batch as actionable. Assign a source ref. Redisplay updated batch and menu.
- IF `+ [text]`: Add a new finding to the batch. Assign a source ref (likely "user-added"). Redisplay updated batch and menu.
- IF `R #N`: Remove finding #N from the batch. Redisplay updated batch and menu.
- IF C: Finalize the batch. Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-03-score.md`
- IF C: Finalize the batch. Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-03-qualify.md`
- IF any other input: Display "Unknown command. Use `merge/skip/new #N`, `E #N`, `+ [text]`, `R #N`, or **C** to continue." then redisplay menu.

@@ -180,4 +185,4 @@

## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: All actionable findings extracted with categories and source refs, overlaps detected, user validated batch at Gate 1, confirmed findings passed to step-t-03
### ❌ SYSTEM FAILURE: Input truncated, findings invented (not from input), overlaps missed, user not given Gate 1 validation opportunity, findings scored prematurely
### ✅ SUCCESS: All actionable findings extracted with source refs, overlaps detected across all backlog sections, user validated batch at Gate 1, confirmed findings passed to step-t-03 for qualification
### ❌ SYSTEM FAILURE: Input truncated, findings invented (not from input), overlaps missed, user not given Gate 1 validation opportunity, findings qualified or scored prematurely
**Master Rule:** Skipping steps is FORBIDDEN.
+70
-65
_bmad/bme/_enhance...ves-backlog/steps-t/step-t-04-update.md
---
name: 'step-t-04-update'
description: 'Validate backlog structure, append scored items safely, regenerate prioritized view, and present completion summary'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
description: 'Validate backlog structure, log every finding as an Intake in §2.1, append qualified items to their lanes, update Change Log, and present completion summary'
outputFile: '{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md'

@@ -9,7 +9,7 @@ workflowFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md'

# Step 4: Backlog Update, Safety & Completion
# Step 4: Backlog Update — Log Intakes & Append Qualified Items
## STEP GOAL:
Validate backlog structure, safely append scored items from Gate 2, regenerate the prioritized view, and present a completion summary before returning to the T/R/C menu.
Validate backlog structure, log every finding (qualified or raw) as an **Intake** in §2.1 (the audit trail), append qualified items to their assigned lane's table (§2.2 Bug / §2.3 Fast / §2.4 Initiative), update the Change Log, and present a completion summary before returning to the T/R/C menu.

@@ -25,5 +25,6 @@ ## MANDATORY EXECUTION RULES (READ FIRST):

### Role Reinforcement:
- ✅ You are a **backlog operations specialist** — precise, non-destructive, append-only
- ✅ Preserve all existing content — never delete, overwrite, or reorder existing rows
- ✅ The Prioritized View is the ONLY section regenerated from scratch
- ✅ You are a **backlog operations specialist** — precise, non-destructive, append-only for lanes and intakes
- ✅ Preserve all existing content — never delete, overwrite, or reorder existing rows outside the touched lane's sort update
- ✅ **Part 1 (Lifecycle Process) must not be modified** — it's semi-static documentation
- ✅ Every qualified item generates **two** rows: one in §2.1 Intakes (audit trail) AND one in the assigned lane
- ✅ All output must be standard markdown — no HTML, no proprietary syntax

@@ -33,6 +34,6 @@

- 🎯 Focus on validation, safe writes, and completion reporting
- 🚫 FORBIDDEN to delete or reorder existing backlog items (FR18, NFR1)
- 🚫 FORBIDDEN to re-score items (scoring was finalized at Gate 2)
- 🚫 FORBIDDEN to modify step-t-01, step-t-02, or step-t-03
- 💬 Approach: validate first, write safely, summarize clearly
- 🚫 FORBIDDEN to delete or reorder existing §2.1 Intakes (append-only per §1.1)
- 🚫 FORBIDDEN to re-qualify items (qualification was finalized at step-t-03)
- 🚫 FORBIDDEN to modify Part 1 (Lifecycle Process) — load it for context only
- 💬 Approach: validate first, write intakes + lane items safely, summarize clearly

@@ -45,6 +46,6 @@ ## EXECUTION PROTOCOLS:

## CONTEXT BOUNDARIES:
- Available context: Scored findings from Gate 2, existing backlog file, backlog format spec template
- Focus: Structural validation, safe append, prioritized view regeneration, completion summary
- Limits: Do NOT re-score, re-extract, or re-classify items
- Dependencies: step-t-03-score.md (scored findings from Gate 2)
- Available context: Qualified items + raw intakes + dropped items from step-t-03, qualifier identity, existing backlog file, format spec
- Focus: Structural validation, append to §2.1 and lanes, lane sort, Change Log, completion summary
- Limits: Do NOT re-qualify, re-extract, or re-classify items; do NOT modify Part 1
- Dependencies: step-t-03-qualify.md (qualified + raw items + qualifier identity)

@@ -57,17 +58,21 @@ ## MANDATORY SEQUENCE

Load `{outputFile}` (existing backlog) and validate structural integrity:
Load `{outputFile}` (existing backlog) and validate structural integrity per format spec:
1. **Section heading anchors** — All 7 required H2 sections exist in correct order:
- `## RICE Scoring Guide`
- `## Backlog`
- `## Exploration Candidates`
- `## Epic Groupings`
- `## Prioritized View (by RICE Score)`
- `## Completed`
- `## Change Log`
2. **Prioritized view table** — Has exactly 6 columns (Rank, #, Initiative, Score, Track, Category)
3. **Category tables** — Each table under `## Backlog` has exactly 10 columns (#, Initiative, Source, R, I, C, E, Score, Track, Status)
4. **Change Log section** — The `## Change Log` H2 section exists with a table
1. **Frontmatter present** — YAML block at top of file.
2. **Part 1 section anchor** — `## Part 1: Lifecycle Process` exists. (Content is not inspected — only the anchor.)
3. **Part 2 section anchors** — All five H3 sections exist in correct order under `## Part 2: Backlog`:
- `### 2.1 Intakes (Unqualified)`
- `### 2.2 Bug Lane`
- `### 2.3 Fast Lane (Quick Wins + Spikes)`
- `### 2.4 Initiative Lane`
- `### 2.5 Absorbed / Archived`
4. **Table column counts:**
- §2.1 Intakes: 5 columns (ID, Description, Source, Date, Raiser)
- §2.2 Bug Lane: 10 columns
- §2.3 Fast Lane: 9 columns
- §2.4 Initiative Lane: 10 columns
5. **Change Log section** — `## Change Log` H2 exists with a table.
6. **File missing guard** — If the backlog file does not exist, display: "No backlog file found at `{outputFile}`. Triage cannot create a new file — use Create mode [C] first." Then load workflow.md and return.
If ALL checks pass, proceed directly to step 3 (Append Items).
If ALL checks pass, proceed directly to step 3 (Append Intakes).

@@ -87,40 +92,35 @@ ### 2. Mismatch Handling

- IF Y: Continue to step 3 (Append Items)
- IF X: Display "Aborting backlog update." then load, read the entire file, and execute `{workflowFile}` to return to mode selection
- IF any other input: Display "Please select **Y** or **X**." then redisplay the prompt
- IF Y: Continue to step 3.
- IF X: Display "Aborting backlog update." then load, read the entire file, and execute `{workflowFile}` to return to mode selection.
- IF any other input: Display "Please select **Y** or **X**." then redisplay the prompt.
### 3. Append Items
### 3. Append Intakes to §2.1
For each scored item from Gate 2:
For **every** finding that reached this step (qualified + raw intake + dropped), append a row to §2.1 Intakes:
1. **Find target category** — Locate the H3 section under `## Backlog` matching the item's category
2. **Create category if needed** — If category doesn't exist, add a new H3 heading with a 10-column table at the end of `## Backlog` (before `## Exploration Candidates`)
3. **Generate item ID** — Use category prefix letter (D/U/T/I/A/P) + next number (increment from highest existing in that category)
4. **Append row** — Add new row to end of category table. NEVER delete, overwrite, or reorder existing rows
5. **Add provenance** — Include in the Initiative description: `Added from [source], [date]` where source is the input origin from step-t-01 and date is the current session date
1. **Generate Intake ID** — `IN-{n}` where `n` is the next sequential integer after the highest existing IN-ID in §2.1.
2. **Description** — concise one-line summary from the finding.
3. **Source** — session origin (e.g., "party mode 2026-04-15", "code review ag-7-5", "retrospective sp-epic-5").
4. **Date** — current session date (YYYY-MM-DD, absolute).
5. **Raiser** — the qualifier identity from step-t-03 (Vortex / John / Winston / raw-only).
**Column format** (10 columns per backlog-format-spec.md):
```
| [ID] | **[Title]** — [description]. Added from [source], [date] | [source ref] | [R] | [I] | [C]% | [E] | [score] | [track] | Backlog |
```
**Do NOT delete or reorder existing Intake rows.** Append new rows at the end of the table.
**Important:** Triage Gate 2 adjustments are the initial score — no rescore provenance is generated.
**Dropped items are also logged to §2.1** — with a Description prefixed `[DROPPED]` and the reason in the Change Log. This preserves the audit trail even for findings the qualifier chose not to route.
### 4. Regenerate Prioritized View
### 4. Append Qualified Items to Their Lanes
Rebuild the `## Prioritized View (by RICE Score)` table from scratch:
For each item in `qualified_items` (i.e., findings routed to Bug / Fast / Initiative):
1. Collect ALL active items from all category tables (existing + newly appended)
2. Exclude items with Status "Done" or items in the `## Completed` section
3. Sort by composite RICE score descending
4. Tiebreak: (1) Higher Confidence first, (2) Newer insertion order first
5. Generate sequential rank numbers starting at 1
1. **Find target lane table** — §2.2 (Bug), §2.3 (Fast), or §2.4 (Initiative).
2. **Generate lane ID:**
- Bug Lane: `BUG-{n}` sequential.
- Fast Lane + Initiative Lane: single alpha prefix from a simple heuristic (U for Update, I for Infrastructure, T for Testing, A for Agent, D for Doc, P for Platform). If uncertain, use `Q-{n}` (for Qualified-uncategorized).
3. **Append row** with the columns defined in the format spec for the target lane. Include the RICE score rationale as a tail note only if it aids future review (keep rows compact).
4. **Cross-reference** — In the Intake row's Description cell (in §2.1), append ` → [laneID]` so intake→lane linkage is preserved.
5. **Re-sort the touched lane's table by composite RICE score descending.** Tiebreak: Confidence higher first, then insertion order newer first.
Table format (6 columns):
```
| Rank | # | Initiative | Score | Track | Category |
|------|---|-----------|-------|-------|----------|
```
**Never delete, overwrite, or reorder rows in lanes that were not touched this session.**
### 5. Add Changelog Entry
### 5. Add Change Log Entry

@@ -130,8 +130,9 @@ Prepend a new row to the `## Change Log` table (newest first):

```
| YYYY-MM-DD | Triage: Added [N] items ([categories affected]). [Any merge notes if applicable] |
| YYYY-MM-DD | Triage by [Qualifier]: Logged [N] intakes. Qualified [X] ([Bug: a, Fast: b, Initiative: c]). Raw intakes: [Y]. Dropped: [Z]. [Any new portfolio proposals flagged.] |
```
### 6. Update Last Updated Date
### 6. Update Frontmatter
Set the metadata header `Last Updated` field to the current date (YYYY-MM-DD format).
- Set `status: active` if this is the first write to the file (was `draft`).
- Do NOT modify the `created` date.

@@ -144,7 +145,11 @@ ### 7. Completion Summary & Return to Menu

>
> **Items added:** [N]
> **Items merged:** [N] (absorbed into existing items at Gate 1)
> **Categories affected:** [list]
> **Intakes logged:** [N]
> **Qualified into lanes:** [X]
> - Bug Lane: [n]
> - Fast Lane: [n]
> - Initiative Lane: [n]
> **Raw intakes (awaiting qualification):** [Y]
> **Dropped (logged with reason):** [Z]
>
> **New Top 3 Positions:**
> **Top 3 Fast Lane positions (post-sort):**
> 1. [#ID] [title] — Score: [X.X]

@@ -161,4 +166,4 @@ > 2. [#ID] [title] — Score: [X.X]

## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Pre-write validation performed, existing content preserved, items appended with correct IDs and provenance, prioritized view regenerated with all items sorted correctly, changelog updated, completion summary displayed with top 3, T/R/C menu re-presented
### ❌ SYSTEM FAILURE: Existing backlog content deleted/overwritten/reordered, items written without validation, wrong IDs or missing provenance, prioritized view not regenerated, no completion summary, no return to menu
### ✅ SUCCESS: Validation performed, every finding logged as an Intake (audit trail complete), qualified items appended to correct lanes with proper IDs, lanes re-sorted by RICE, Change Log updated with qualifier identity and counts, completion summary displayed, menu re-presented
### ❌ SYSTEM FAILURE: Findings not logged as Intakes, qualified items written without the cross-reference in Intakes, Part 1 modified, existing rows deleted/reordered, Change Log missing the qualifier identity, dropped items lost without audit trail
**Master Rule:** Skipping steps is FORBIDDEN.
+222
-111
_bmad/bme/_enhance...acklog/templates/backlog-format-spec.md
# Backlog Format Specification
Reference document for consistent backlog file formatting across all initiatives backlog operations. Loaded by the workflow during file write operations to ensure output matches the canonical format.
Reference document for the **Convoke Initiative Lifecycle & Backlog** format. Loaded by the workflow during file write operations to ensure output matches the canonical structure defined by the lifecycle process.
All output must be standard markdown — no proprietary extensions, HTML embeds, or tool-specific syntax (NFR6).
All output must be standard markdown — no proprietary extensions, HTML embeds, or tool-specific syntax.
---
## Metadata Header
## File Identity
Every backlog file begins with:
**Canonical filename:** `convoke-note-initiative-lifecycle-backlog.md`
**Canonical location:** `{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md`
**Supersedes:** `convoke-note-initiatives-backlog.md` (archived 2026-04-15 to `_archive/superseded/`)
```markdown
# Convoke Initiatives Backlog
---
**Created:** YYYY-MM-DD
**Method:** RICE (Reach, Impact, Confidence, Effort)
**Last Updated:** YYYY-MM-DD
## Frontmatter
Every backlog file begins with YAML frontmatter:
```yaml
---
initiative: convoke
artifact_type: note
qualifier: initiative-lifecycle-backlog
created: 'YYYY-MM-DD'
schema_version: 1
status: draft | active
origin: '<short origin description>'
supersedes: convoke-note-initiatives-backlog.md
---
```
The `Last Updated` date is refreshed on every write operation.
The `created` date is set on first write and never changed thereafter.
---
## Section Hierarchy
## Document Structure
The backlog file uses this exact heading structure. Sections must appear in this order.
The file uses this exact structure. Sections must appear in this order.
```
# Convoke Initiatives Backlog (H1 — title)
# Convoke Initiative Lifecycle & Backlog (H1 — title)
## RICE Scoring Guide (H2 — inline scoring reference)
## Part 1: Lifecycle Process (H2 — process definition, semi-static)
### 1.1 Intake (H3)
### 1.2 Qualifying Gate (H3)
### 1.3 Three Lanes (H3)
#### Bug Lane / Fast Lane / Initiative Lane (H4)
### 1.4 Portfolio Attachment (H3)
### 1.5 Pipeline Stages (Evolvable) (H3)
### 1.6 RICE Scoring (H3)
## Backlog (H2 — active items container)
### [Category Name] (H3 — one per category, repeating)
## Part 2: Backlog (H2 — operational data, mutates frequently)
### 2.1 Intakes (Unqualified) (H3)
### 2.2 Bug Lane (H3)
### 2.3 Fast Lane (Quick Wins + Spikes) (H3)
### 2.4 Initiative Lane (H3)
### 2.5 Absorbed / Archived (H3)
#### Absorbed into [name] / Completed (shipped) (H4 — optional sub-grouping)
## Exploration Candidates (H2 — unscored items needing discovery)
## Appendix: Initiative Details (H2 — full descriptions for §2.4 items)
### [Item ID] — [Title] (H3 — one per initiative when detail is needed)
## Epic Groupings (H2 — bundled delivery suggestions)
### Epic: "[Name]" ([item IDs]) (H3 — one per grouping)
## Change Log (H2 — operational history)
```
## Prioritized View (by RICE Score) (H2 — auto-generated ranked table)
**Part 1** is semi-static (the lifecycle process definition). The skill **must NOT regenerate or modify Part 1 contents** unless explicitly running Create mode. In Triage and Review modes, Part 1 is loaded for context but never written.
## Completed (H2 — finished items, grouped by date)
### YYYY-MM-DD (H3 — date grouping for milestones)
**Part 2** is the operational surface — Triage adds rows, Review updates rows.
## Change Log (H2 — operational history)
```
**Appendix** holds detailed descriptions for Initiative Lane items whose table row is a one-liner.
### Category Names
---
Categories are user-defined H3 headings under `## Backlog`. The existing backlog uses:
## Table Formats
- Documentation & Onboarding
- Update & Migration System
- Testing & CI
- Infrastructure
- Agent Quality & Consistency
- Platform & Product Vision
### §2.1 Intakes Table
New categories may be added. Category names must be unique within the backlog.
```markdown
| ID | Description | Source | Date | Raiser |
|----|-------------|--------|------|--------|
```
---
**Columns:**
- `ID`: `IN-{n}` sequential integer. Optionally `IN-{n} (was {oldId})` for migrated entries.
- `Description`: One-line summary. Detail goes in Appendix if needed.
- `Source`: Where it came from (party mode, code review, retrospective, user report, etc.).
- `Date`: Absolute date `YYYY-MM-DD`. Never relative.
- `Raiser`: Person or agent name.
## Table Formats
**Rules:**
- Append-only — intakes never disappear, even after qualification (audit trail).
- After qualification, the intake stays here; a corresponding row is added to the assigned lane.
### Category Table (under each H3 category)
### §2.2 Bug Lane Table
```markdown
| # | Initiative | Source | R | I | C | E | Score | Track | Status |
|---|-----------|--------|---|---|---|---|-------|-------|--------|
| ID | Description | R | I | C | E | Score | Portfolio | Status | Dependencies | Linked Follow-up |
|----|-------------|---|---|---|---|-------|-----------|--------|--------------|------------------|
```
**Column rules:**
- `#`: Short alphanumeric ID (e.g., D2, P4, T3). Unique within the backlog.
- `Initiative`: `**[Bold title]** — [description]`. May include markdown links.
- `Source`: Origin of the initiative (e.g., "Vortex review (Liam, Wade)", "Product owner")
- `R`: Reach score (integer 1-10)
- `I`: Impact score (0.25, 0.5, 1, 2, or 3)
- `C`: Confidence as percentage (e.g., 70%, 90%)
- `E`: Effort score (integer 1-10)
- `Score`: Composite RICE score, one decimal place (e.g., 2.8)
- `Track`: "Keep the lights on" or "Move the needle"
- `Status`: One of: Backlog, In Planning, In Progress, Done, Blocked
**Columns:**
- `ID`: Bug-prefixed sequential — `BUG-{n}`.
- `Description`: One-line summary of the broken behavior + intended fix scope.
- `R`, `I`, `C`, `E`: RICE component scores. Impact often hardcoded high (2–3) when user-facing.
- `Score`: Composite, one decimal place.
- `Portfolio`: Portfolio attachment (convoke, vortex, gyre, forge, bmm, enhance, loom, helm, or new).
- `Status`: `Open`, `In Fix`, `In Review`, `Shipped`.
- `Dependencies`: Comma-separated upstream item IDs (any lane). Use `—` when none. See Dependency Notation rules below.
- `Linked Follow-up`: Reference to a Fast Lane or Initiative item if the bug spawned deeper work.
### Prioritized View Table (under `## Prioritized View`)
**Sort:** Descending by composite Score. Dependencies do not affect sort — they are informational. The reader is responsible for noting when a high-RICE item is blocked.
### §2.3 Fast Lane Table
```markdown
| Rank | # | Initiative | Score | Track | Category |
|------|---|-----------|-------|-------|----------|
| ID | Description | R | I | C | E | Score | Portfolio | Status | Dependencies |
|----|-------------|---|---|---|---|-------|-----------|--------|--------------|
```
**Rules:**
- Sorted by composite RICE score, descending
- Tiebreak: Confidence (higher first), then insertion order (newer first)
- Only includes active items (not Done or in Completed section)
- Regenerated from scratch on every write operation — not manually maintained
- Rank is a sequential integer starting at 1
**Columns:**
- `ID`: Original IDs preserved during migration (D2, U7, T6, I43, A7, P10, P11, etc.) or new prefix as needed.
- `Description`: Compact one-liner; full detail can live in Appendix if helpful.
- `R`, `I`, `C`, `E`, `Score`: RICE per scoring guide.
- `Portfolio`: Portfolio attachment.
- `Status`: `Backlog`, `In Story`, `In Sprint`, `Shipped`.
- `Dependencies`: Comma-separated upstream item IDs (any lane). Use `—` when none. See Dependency Notation rules below.
### Exploration Candidates Table (under `## Exploration Candidates`)
**Sort:** Descending by composite Score. Dependencies do not affect sort.
### §2.4 Initiative Lane Table
```markdown
| # | Initiative | Source | Next Step |
|---|-----------|--------|-----------|
| ID | Description | R | I | C | E | Score | Portfolio | Stage | Artifacts | Dependencies |
|----|-------------|---|---|---|---|-------|-----------|-------|-----------|--------------|
```
These items are unscored and not included in the prioritized view.
**Columns:**
- `ID`: Original IDs preserved (P9, P12, S3, P21, etc.). Bundles allowed using `+` (e.g., `U10+P23+A8+A9` for v6.3 Adoption).
- `Description`: Bold title. Full detail in Appendix.
- `R`, `I`, `C`, `E`, `Score`: RICE per scoring guide.
- `Portfolio`: Portfolio attachment (or `*(pending)*` if undecided).
- `Stage`: One of: `Qualified`, `In Pipeline`, `Ready`, `In Sprint`, `Done`. May include parenthetical (e.g., `Qualified (Blocked on P12)`).
- `Artifacts`: Compact indicator of which planning artifacts exist:
- `B` = Brief
- `P` = PRD
- `P✓` = PRD validated
- `A` = Architecture
- `IR` = Implementation Readiness report
- `E` = Epic breakdown
- `D` = Discovery (Vortex)
- Combine with commas. Example: `D, P✓, A, IR, E`.
- `Dependencies`: Comma-separated upstream item IDs (any lane). Use `—` when none. See Dependency Notation rules below.
### Completed Section Tables (under `## Completed`)
**Sort:** Descending by composite Score (same rule as Fast Lane). Dependencies do not affect sort.
Grouped by date using H3 headers:
### §2.5 Absorbed / Archived Tables
Use H4 sub-headings to group:
**Absorbed into [target]:**
```markdown
### YYYY-MM-DD
| ID | Original Description | Absorbed Into | Reference | Date |
|----|---------------------|---------------|-----------|------|
```
| # | Initiative | Score | Category |
|---|-----------|-------|----------|
**Completed (shipped):**
```markdown
| ID | Description | Shipped | Score | Portfolio |
|----|-------------|---------|-------|-----------|
```
**Note:** Legacy completed entries (pre-backlog era) may use non-standard table formats (e.g., `| Item | Fix Applied |`). These should be preserved as-is during write operations — do not attempt to reformat them.
**Rules:**
- Nothing disappears without a receipt.
- Absorbed items must reference the target (epic file, larger initiative).
- Completed items are append-only.
---
### Appendix Detail Format
## Change Log Format
For each Initiative Lane item warranting detail:
The Change Log section uses a table:
```markdown
### [ID] — [Title]
**Stage:** [stage] | **Portfolio:** [portfolio] | **RICE:** [score]
**Planning artifacts:** [list with file paths]
**Missing (to reach Ready):** [list]
**Blocker:** [if any]
**Scope hint:** [paragraph or bullets]
```
### Change Log Table
```markdown
## Change Log
| Date | Change |

@@ -136,3 +205,3 @@ |------|--------|

Entries are prepended (newest first). Each workflow session adds one entry summarizing items added, removed, rescored, or moved.
Entries are prepended (newest first). Each workflow session adds one entry.

@@ -143,9 +212,9 @@ ---

**Formula:** Score = (Reach x Impact x Confidence) / Effort
**Formula:** Score = (Reach × Impact × Confidence) / Effort
Where Confidence is expressed as a decimal (e.g., 70% = 0.7).
**Example:** R:8, I:3, C:70%, E:6 = (8 x 3 x 0.7) / 6 = 2.8
**Example:** R:8, I:3, C:70%, E:6 = (8 × 3 × 0.7) / 6 = 2.8
**Sort order:** Descending by composite score. Ties broken by:
**Sort order (within each lane):** Descending by composite score. Ties broken by:
1. Confidence — higher first

@@ -156,46 +225,82 @@ 2. Insertion order — newer first

## Insertion Rules
## Dependency Notation
### Adding New Items (Triage mode, Create mode)
The `Dependencies` column captures upstream relationships. Notation rules:
1. Identify the target category H3 section under `## Backlog`
2. Append the new row to the end of that category's table
3. If the category doesn't exist, create a new H3 heading at the end of the `## Backlog` section (before `## Exploration Candidates`)
4. Regenerate the `## Prioritized View` table with all active items sorted by composite score
5. Add a Change Log entry
- **Format:** comma-separated item IDs from any lane. Cross-lane references are explicitly allowed (a Fast Lane item can depend on an Initiative Lane item, and vice versa).
- **Empty state:** use `—` (em-dash) when an item has no dependencies.
- **Done dependencies:** if a dependency has shipped, prefix with `✓` (e.g., `✓P1` means "depended on P1, which is now done"). This preserves history without making the item look blocked.
- **Bundle relationships:** for items that travel together (ship as one PR or one epic), use `bundles-with: ID, ID`. Example: `bundles-with: I48`.
- **Absorbed-into shorthand:** items absorbed into another initiative live in §2.5. Their original lane row is removed. The Dependencies column does not need to track absorption.
- **External dependencies:** for blockers outside the backlog (e.g., upstream BMAD release, external user availability), use `external: short-description` (e.g., `external: BMAD v6.3 release`). Keep the description under 30 chars.
- **Multiple types:** when an item has both internal and external dependencies, separate with semicolons. Example: `P12; external: marketplace-PR-merge`.
### Moving Items to Completed
**Dependencies do not change RICE sort order.** Two items with the same RICE score do not get re-ordered by dependency direction. The reader is expected to scan the Dependencies column when planning sequencing.
1. Remove the item row from its category table
2. Add it to the appropriate `### YYYY-MM-DD` group under `## Completed`
3. If no group exists for today's date, create one
4. Regenerate the `## Prioritized View` table
5. Add a Change Log entry
**Stage parenthetical vs. Dependencies column:** if an Initiative is currently blocked, both should reflect it: the Stage cell shows `Qualified (Blocked on X)` for visibility, and the Dependencies cell lists `X` for parseability. Stage parenthetical is human signal; Dependencies cell is the canonical reference.
---
## Provenance Tags
## Lane Assignment Rules
Provenance is recorded in the Initiative cell description or as a separate annotation.
The qualifying gate (Vortex, John, or Winston) assigns each intake to one lane:
### Triage Mode — New Items
**Bug Lane** if:
- Observed broken behavior, regression, or data loss risk
- Fix is the scope (deeper rework spawns separate Fast Lane / Initiative item)
Format: `"Added from [source], [date]"`
**Fast Lane** if:
- Single-module, contained scope
- Point fix from code review, retrospective, audit
- Process rule to encode
- Test debt, doc improvement, small enhancement
- Spike (time-boxed learning with uncertain outcome)
Example: `Added from party-mode review transcript, 2026-03-15`
**Initiative Lane** if:
- Multi-module or architectural impact
- User-facing behavior change
- Requires full pipeline (Brief → PRD → Arch → PRD Validation → IR → Epics)
- Bundle of related work that needs coordinated planning
The score recorded is the **final** score after any Gate 2 user adjustments. The agent's initial proposal is not recorded separately. Triage Gate 2 adjustments are NOT rescores — they are the initial score. No rescore provenance is generated.
**When uncertain:** default to Fast Lane unless a clear architectural or multi-module signal exists. The qualifier can promote later if scope grows.
### Review Mode — Rescored Items
---
Format: `"Rescored [old]->[new], Review, [date]"`
## Insertion Rules
Example: `Rescored 1.8->2.4, Review, 2026-03-15`
### Triage Mode (steps-t)
Only recorded when the composite score actually changes. Confirming an existing score or skipping an item generates no provenance entry.
1. Every extracted finding is logged to **§2.1 Intakes** first, with sequential `IN-{n}` ID.
2. Optional in-session qualification: for each intake, the qualifier assigns lane + portfolio + RICE.
3. Qualified intakes get a corresponding row appended to their lane's table (§2.2/2.3/2.4).
4. The intake row in §2.1 stays — it's the audit trail.
5. A Change Log entry is added.
### Create Mode — New Items
### Review Mode (steps-r)
Format: `"Added from Create mode, [date]"`
1. User chooses which lane(s) to walk: Bug, Fast, Initiative, or All.
2. Walk through items in the chosen lane(s); rescore RICE per the scoring guide.
3. Update only items whose composite score changed; provenance line appended in Description cell.
4. Confirmed and skipped items remain unchanged.
5. A Change Log entry is added.
### Create Mode (steps-c)
1. Detect existing file; warn before overwriting.
2. Generate **Part 1** verbatim from `templates/lifecycle-process-spec.md` (canonical process definition).
3. Initialize empty Part 2 tables.
4. Optionally gather initial intakes (loop).
5. Optionally qualify each intake into a lane.
6. Write the complete file.
### Moving Items Between Sections
- **Intake → Lane:** Append to lane table. Intake row in §2.1 stays.
- **Bug → Fast Lane / Initiative (deeper rework):** Add row to target lane referencing the bug ID in `Linked Follow-up`.
- **Fast Lane → Initiative (scope grew):** Move row, update ID prefix or keep original. Note in Change Log.
- **Any → §2.5 Absorbed:** Move row to §2.5 with reference to absorbing target.
- **Any → §2.5 Completed (shipped):** Move row to Completed sub-table with shipping date.
Never delete a row outright — every removal becomes a §2.5 entry.
---

@@ -205,11 +310,17 @@

Before writing to the backlog file, the workflow must validate:
Before writing, the workflow must validate:
1. **Section heading anchors** — All required H2 sections exist in the correct order
2. **Prioritized view table column count** — Table has exactly 6 columns
3. **Category table column count** — Each category table has exactly 10 columns
4. **Change Log section existence** — The Change Log H2 section exists
5. **No data loss** — Existing category section content is preserved (no deletions, overwrites, or reordering of existing rows). The Prioritized View is excluded from this check since it is regenerated.
1. **Frontmatter present** — Required YAML block at top of file.
2. **Part 1 unchanged** (Triage and Review modes only) — H2 `## Part 1: Lifecycle Process` content matches the loaded snapshot. If modified, warn before proceeding.
3. **Part 2 section anchors** — All five H3 sections (`### 2.1` through `### 2.5`) exist in correct order under `## Part 2: Backlog`.
4. **Table column counts:**
- §2.1 Intakes: 5 columns
- §2.2 Bug Lane: 11 columns (Dependencies column added 2026-04-15)
- §2.3 Fast Lane: 10 columns (Dependencies column added 2026-04-15)
- §2.4 Initiative Lane: 11 columns (Dependencies column added 2026-04-15)
- §2.5 sub-tables: 5 columns each
5. **Change Log present** — `## Change Log` H2 exists.
6. **No data loss** — Existing rows preserved; only the touched rows changed, only the touched lanes reordered.
If validation detects a structural mismatch, the user can proceed or abort.
If validation detects a structural mismatch, the user can proceed (Y) or abort (X).

@@ -220,5 +331,5 @@ ---

The backlog output must match the exact current format of `initiatives-backlog.md`. When in doubt, load the existing file and match its patterns precisely. This ensures:
The backlog output must match the canonical structure of this spec. When in doubt, load the existing file and match its patterns precisely. This ensures:
- Round-trip parseability (the workflow can reload its own output)
- Manual editability (users can edit the file in any text editor between sessions)
- Manual editability (users can edit between sessions)
- `git diff` readability (consistent formatting minimizes noise)
+44
-31
_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md
---
workflow: initiatives-backlog
type: step-file
description: Tri-modal RICE initiatives backlog management — Triage review findings, Review existing items, or Create a new backlog from scratch
description: Lane-aware initiative lifecycle backlog management — Triage intakes through the qualifying gate, review lane items, or bootstrap a new lifecycle backlog
author: John PM (pm.md)
version: 1.0.0
version: 2.0.0
---
# Initiatives Backlog Workflow
# Initiative Lifecycle Backlog Workflow
Manage a RICE-scored initiatives backlog through three complementary modes. This workflow transforms unstructured review findings, audit outputs, and team discussions into prioritized, scored backlog items — and keeps them calibrated over time.
Manage the **Convoke Initiative Lifecycle & Backlog** — a three-lane (Bug / Fast / Initiative) model with a qualifying gate (Vortex, John, or Winston). Transforms unstructured findings into logged intakes, routes them through qualification, and keeps RICE scores calibrated across lanes over time.

@@ -19,25 +19,28 @@ ## Workflow Structure

- State tracking in frontmatter (progress preserved across sessions)
- Two-gate validation in Triage mode (extraction review, then scoring review)
- Qualifying gate sub-flow in Triage + Create modes
## Modes Overview
### [T] Triage — Ingest Review Findings
Accepts text input (review transcripts, meeting notes, audit outputs), extracts actionable findings, proposes RICE scores with two-gate validation, and appends scored items to the existing backlog.
- **Steps:** Ingest > Extract & Gate 1 > Score & Gate 2 > Update backlog
- **When to use:** After a party-mode review, code review, retrospective, or any session that produces findings
### [T] Triage — Ingest → Intake → Qualify
Accepts text input (review transcripts, party mode outputs, audit findings, retro notes), extracts actionable findings, logs every finding as an **Intake** (§2.1), then offers the qualifying gate: for each intake, assign a **Lane** (Bug / Fast / Initiative), **Portfolio**, and **RICE** score.
- **Steps:** Ingest > Extract & log to Intakes > Qualify into lanes > Update backlog
- **When to use:** After any session that produces findings — code review, retrospective, party mode, user report
### [R] Review — Rescore Existing Items
Loads the current backlog and walks through items for rescoring. Prevents score drift by prompting reassessment of Reach, Impact, Confidence, and Effort as project context evolves.
- **Steps:** Load backlog > Walkthrough & rescore > Update backlog
- **When to use:** Periodically (monthly or after major project milestones) to keep priorities calibrated
Loads the current backlog, lets you pick which lane(s) to walk (Bug / Fast / Initiative / All), then walks items one at a time for RICE rescoring. Prevents score drift as project context evolves.
- **Steps:** Load & choose lanes > Walkthrough & rescore > Update backlog
- **When to use:** Periodically (monthly, after major milestones, or when an epic completes and changes adjacent effort)
### [C] Create — Build New Backlog
Bootstraps a new RICE-scored backlog from scratch through guided interactive gathering and scoring.
- **Steps:** Initialize > Gather initiatives > Score > Generate prioritized view
- **When to use:** Starting a new project or creating a fresh backlog for a new domain
### [C] Create — Bootstrap New Lifecycle Backlog
Generates a new lifecycle backlog file from scratch: Part 1 (canonical lifecycle process) verbatim from template + empty Part 2 lanes. Optionally gather initial intakes and run the qualifying gate on them.
- **Steps:** Initialize & guard overwrite > Gather intakes (optional) > Qualify (optional) > Generate file
- **When to use:** Starting a new project or creating a fresh backlog for a new domain. Existing Convoke backlog was bootstrapped on 2026-04-12.
## Output
**Artifact:** `{planning_artifacts}/initiatives-backlog.md`
**Templates:** `templates/rice-scoring-guide.md`, `templates/backlog-format-spec.md`
**Artifact:** `{planning_artifacts}/convoke-note-initiative-lifecycle-backlog.md`
**Templates:**
- `templates/backlog-format-spec.md` — canonical file structure and table formats
- `templates/lifecycle-process-spec.md` — canonical Part 1 content (Create mode only)
- `templates/rice-scoring-guide.md` — RICE factor definitions and calibration examples

@@ -56,7 +59,7 @@ ---

**Initiatives Backlog — Select a Mode:**
**Initiative Lifecycle Backlog — Select a Mode:**
- **[T] Triage** — Ingest review findings into scored backlog items
- **[R] Review** — Rescore existing backlog items to keep priorities calibrated
- **[C] Create** — Bootstrap a new RICE-scored backlog from scratch
- **[T] Triage** — Ingest findings → log as intakes → route through qualifying gate into lanes
- **[R] Review** — Walk a lane and rescore items to keep RICE calibrated
- **[C] Create** — Bootstrap a new lifecycle backlog from scratch
- **[X] Exit** — Return to John PM agent menu

@@ -73,3 +76,3 @@

- **IF C:** Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-01-init.md`
- **IF X:** Display "Exiting Initiatives Backlog workflow." and end the workflow — return control to the John PM agent menu
- **IF X:** Display "Exiting Initiative Lifecycle Backlog workflow." and end the workflow — return control to the John PM agent menu
- **IF any other input:** Display "Unknown option. Please select **T**, **R**, **C**, or **X**." then redisplay the Mode Selection menu above

@@ -80,4 +83,4 @@

- ALWAYS halt and wait for user input after presenting the menu
- Do NOT auto-select a mode — the user must explicitly choose (ADR-3)
- Modes run independently — do NOT switch modes mid-execution (ADR-4)
- Do NOT auto-select a mode — the user must explicitly choose
- Modes run independently — do NOT switch modes mid-execution
- After X, end the workflow completely

@@ -87,7 +90,17 @@

<!-- RETURN-TO-MENU CONVENTION (for step file authors):
When the final step of any mode completes (e.g., step-t-04-update.md for Triage),
it must instruct the LLM to re-load this entire workflow file:
{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md
This re-presents the INITIALIZATION section and Mode Selection menu,
allowing the user to run another mode or exit (FR28). -->
## Qualifying Gate Reference
The **qualifying gate** is the decision point in Triage and Create modes where intakes become lane items. Only three qualifiers can invoke it:
1. **Vortex team** — through discovery (full 7-stream or partial)
2. **John (PM)** — product framing shortcut (this agent)
3. **Winston (Architect)** — technical framing shortcut
The qualifier assigns:
- **Lane:** Bug / Fast / Initiative (per §1.3 of lifecycle-process-spec.md)
- **Portfolio:** convoke, vortex, gyre, forge, bmm, enhance, loom, helm — or new (John+Winston decision)
- **RICE:** Reach × Impact × Confidence / Effort (per rice-scoring-guide.md)
**Default lane when uncertain:** Fast Lane. Can be promoted later if scope grows.
**Intakes stay logged even after qualification.** §2.1 is the audit trail — never deleted.
+3
-0
_bmad/bme/_gyre/config.yaml

@@ -10,2 +10,5 @@ submodule_name: _gyre

- review-coach
# Agents you have deliberately removed — they will NOT be restored on `convoke-update`.
# Add an agent ID here to opt out permanently; remove to re-enable on the next update.
excluded_agents: []
workflows:

@@ -12,0 +15,0 @@ - full-analysis

+4
-1
_bmad/bme/_vortex/config.yaml

@@ -13,2 +13,5 @@ submodule_name: _vortex

- learning-decision-expert
# Agents you have deliberately removed — they will NOT be restored on `convoke-update`.
# Add an agent ID here to opt out permanently; remove to re-enable on the next update.
excluded_agents: []
workflows:

@@ -37,3 +40,3 @@ - lean-persona

- vortex-navigation
version: 3.2.0
version: 3.3.0
user_name: "{user}"

@@ -40,0 +43,0 @@ communication_language: en

+68
-0
CHANGELOG.md

@@ -10,2 +10,70 @@ # Changelog

## [3.3.0] - 2026-04-19
### Added
- **Convoke Operator Covenant** (P21 Epic 1) — New architectural contract governing operator experience across all Convoke skills. Axiom *"the operator is the resolver"* + 7 Operator Rights (default, full universe, rationale, completeness, pause, next action, pacing). Compliance Checklist (OC-R0..OC-R7) with 3-layer audit scope, 6 status values, reproducibility-gate methodology. New `covenant` artifact type in taxonomy. Artifacts: `convoke-covenant-operator.md`, `convoke-spec-covenant-compliance-checklist.md`, Epic 1 story set `oc-1-1`..`oc-1-5` + retro.
- **User agent exclusions** (U8) — `excluded_agents: []` field in `_bmad/bme/_vortex/config.yaml` and `_bmad/bme/_gyre/config.yaml`. `mergeConfig`, `refresh-installation`, `validator`, and `convoke-doctor` all honor exclusions — agent files, user guides, skill wrappers, and manifest rows skip excluded agents. 14 new tests.
- **Update-time changelog display** (U7) — `convoke-update` now surfaces a "What's New" block from `CHANGELOG.md` before confirming refresh/upgrade. New `scripts/update/lib/changelog-reader.js` with Keep-a-Changelog header parsing (incl. pre-release semver). 15 new tests.
- **`convoke-export --quiet`** (I50) — `-q` / `--quiet` flag suppresses per-skill stdout in batch mode; failures (stderr) and single-line summary always emit. Batch dry-run output drops 50 → 1 lines. 6 new integration tests.
- **Capability Evaluation Framework** (P10) + **Friction Log Template** (P11) — Operationalized from archive to `_bmad-output/planning-artifacts/`. Referenced from initiative-lifecycle §1.2 as the qualifying gate for capability-type intakes.
- **Staleness pre-flight rule** (A27, Phase 1) — `staleness-preflight-for-backlog-pickup` rule in `project-context.md` with four checks (existence, dependency, code-anchor validity, semantic-anchor) + GREEN/YELLOW/RED verdict semantics + four exemption classes.
- **Review convergence rule** (A7) — R1 mandatory, R2 only if HIGH, R3 only if structural changes, no R4. Encoded in `project-context.md` and `bmad-code-review` skill's `step-04-present.md`.
- **Mechanical research protocol** (A5) — New `mechanical-research-enumeration` rule: catalog/audit/inventory deliverables must enumerate via `grep`/`glob` with raw output as evidence.
- **Reproducibility gate for multi-skill audits** (A10) — v2+ Covenant audits cover ≥3 cells (expected-PASS + expected-FAIL + borderline) at 100% agreement at N=3-4 / ≥80% at N≥5. Four-path failure-mode handling (revise / DISPUTED-exclude with N-recomputation / methodology-invalid / shrink-scope).
- **OC-R6 external-declared escape hatch** (A15) — 6th Compliance Status value `N/A — external-declared (<tool>)` for skills wrapping external CLIs (git, npm, docker) whose stderr they can't rewrite. Required evidence-note template `Layers: L1 PASS (<ref>), L2 PASS (<ref>), L3 external-declared (<tool>)`.
- **4 new `project-context.md` rules** (I49) — `derive-counts-from-source` (no hardcoded counts), `shared-test-constants` (import from shared files), `catch-all-phase-review` (review fallback matcher output before shipping), `spec-verify-referenced-files` (existence-check file paths in specs).
### Changed
- **`generateGovernanceADR`** (BUG-1) — Platform-initiative and artifact-type counts/lists now derived from `taxonomy.yaml` (was hardcoded `(8)` / `(21)`; taxonomy now carries 23 types and any number of initiatives). Call site `scripts/migrate-artifacts.js` passes the loaded taxonomy through.
- **OC-R7 doc-mapping clarified** (A12) — Compliance Checklist doc rule now uses cumulative vocabulary (concepts introduced in earlier Covenant sections are pre-existing for later sections); example/anti-pattern illustrations don't count as novel when they illustrate an already-introduced concept.
### Fixed
- **`runScript` test helper hardened** (I64) — `tests/helpers.js` timeout handling: `exitCode` is now always a finite integer (was `null` on `execFile` timeout, surfacing as opaque `null !== 0` in any CLI-integration test hitting a timeout). New `timedOut` and `signal` fields surface distinct timeout semantics. Pre-existing helper bug surfaced by T4 code-review warning guard. 4 new tests in `tests/unit/helpers.test.js` lock the contract. First application of A27 staleness pre-flight (all 4 checks GREEN).
### Documentation
- **`_bmad/bme/README.md`** (D8) — New `## Files at _bmad/bme/ root` section listing `config.yaml` with a one-line description. Placed between the Submodules table (directories) and the "When to add here vs upstream" guidance.
- **`docs/README.md`** (D9) — New docs index with Covenant pointer as the featured callout. Contents table enumerates the 6 contributor-facing docs; cross-refs to repo README, bme README, and `project-context.md`.
### Infrastructure / Tests
- **Python CI + linting + PEP 723** (T6, T7, T8) — New `python-test` GitHub Actions job running 116+ Python tests across 5 files; `ruff` linter added with `ruff.toml` (40 auto-fixes + 3 manual); PEP 723 inline metadata standardized with `pyyaml>=6.0` pinning and `>=3.9` version floors (24/24 files covered). Publish gate updated. Resolves Gyre DL-001 blocker.
- **Migration idempotency CLI test** (T4) — New `tests/integration/migrate-artifacts-idempotency.test.js` with hermetic `git()` helper (timeout + inline `-c core.hooksPath=/dev/null` / `commit.gpgsign=false` / `GIT_TERMINAL_PROMPT=0`). 3 tests cover first-run rename + commits, second-run no-op (exit 0 + zero new commits), third-run resume on added ungoverned file.
- **Upgrade CLI end-to-end test** (T3) — New `tests/integration/upgrade-cli-e2e.test.js` exercises real `convoke-update --yes` child-process flow against a v1.7.x fixture (spans 1.7 → 2.0 rename + 2.0 → 3.1 migrations). 4 tests cover fresh-upgrade exit-0, full post-state verification (AGENT_FILES + WORKFLOW_NAMES + skill wrappers + agent-manifest.csv + deprecated-agent cleanup), and second-run refresh-only behavior.
- **Doctor BME skill-wrapper validation** (I43) — `checkAgentSkillWrappers()` validates all 12 bme agent skill wrappers.
- **Test count:** 1,253+ green (≈1,173 unit + 82 integration), up from 1,123 at 3.2.0.
### Governance evidence (for Covenant adopters)
- **oc-1-1 baseline audit** — 8 skills × 7 rights = 56 cells. Overall compliance 82%. Migration and Portfolio calibration cases correctly identify scar-era violations; Portfolio is remediated.
- **A24 Vortex audit expansion** — 3 additional Vortex workflows scored at step-01 (`assumption-mapping`, `empathy-map`, `hypothesis-engineering`). **T1 FIRES for Vortex × Right to pacing** at 25% compliance (1/4 PASS, N=4). A10 reproducibility gate cleared 3/3 = 100% with 2 independent LLM reviewers. Two new Epic 2 Story 2.1 retrofit cells identified (assumption-mapping step-01 + hypothesis-engineering step-01), pending Epic 2 ratification.
### Note
- v3.2.1 (2026-04-12) was a patch bump that was not documented in the changelog at the time. A retroactive entry is included below for audit completeness.
---
## [3.2.1] - 2026-04-12
Patch bump: portability-system hardening + bme agent coverage in catalog manifest + integration-test isolation fixes.
### Added
- **bme agent rows in `_bmad/_config/skill-manifest.csv`** — 12 new rows (7 Vortex agents: Emma, Isla, Mila, Liam, Wade, Noah, Max; 4 Gyre agents; 1 team-factory agent) so `convoke-export` and the decision-tree catalog surface bme agents as portable skills. Required for v3.2.0 Portability System to cover discovery-side personas.
### Changed
- **Portability Export Engine** (`scripts/portability/export-engine.js`) — Minor refinements to discovery-workflow export output.
- **Catalog Generator** (`scripts/portability/catalog-generator.js`) — Minor fix.
### Fixed
- **Integration test isolation** — `tests/integration/cli-entry-points.test.js`, `convoke-doctor.test.js`, `postinstall.test.js`, and `tests/unit/docs-audit.test.js` refactored to use per-test `cliTmpDir` cwd instead of polluting repo root. `tests/helpers.js` supports the refactored pattern.
---
## [3.2.0] - 2026-04-11

@@ -12,0 +80,0 @@ 

+1
-1
package.json
{
"name": "convoke-agents",
"version": "3.2.1",
"version": "3.3.0",
"description": "Agent teams for complex systems, compatible with BMad Method",

@@ -5,0 +5,0 @@ "main": "index.js",

+3
-1
README.md

@@ -20,2 +20,4 @@ <div align="center">

> **Authoring a Convoke skill?** Required reading first: [The Convoke Operator Covenant](_bmad-output/planning-artifacts/convoke-covenant-operator.md) — one axiom and seven Operator Rights every Convoke skill must honor. The Covenant exists because operator-facing UX is an architectural concern in agent systems, not a styling concern; skills that violate it erode operator trust across the skill ecosystem, not just on their own surface.
| Team | Agents | Domain |

@@ -476,3 +478,3 @@ |------|--------|--------|

- [BMAD Method v6.0.0](https://github.com/bmadhub/bmad) — Foundation for agent architecture
- [BMAD Method v6.0.0](https://github.com/bmad-code-org) — Foundation for agent architecture
- [Innovation Vortex](https://unfix.com/innovation-vortex) — Pattern from the [unFIX model](https://unfix.com/) by [Jurgen Appelo](https://jurgenappelo.com/)

@@ -479,0 +481,0 @@ - Claude (Anthropic) — AI reasoning and agent development

+56
-2
scripts/convoke-doctor.js

@@ -8,2 +8,3 @@ #!/usr/bin/env node

const { findProjectRoot, getPackageVersion } = require('./update/lib/utils');
const { AGENTS, GYRE_AGENTS, EXTRA_BME_AGENTS } = require('./update/lib/agent-registry');
// Note: parseCsvRow is loaded LAZILY inside loadSkillManifest() (ag-7-2 review patch).

@@ -86,3 +87,6 @@ // Top-level require would crash the doctor on installs missing _team-factory/ — exactly

// 4. Global checks (module-agnostic)
// 4. Agent skill wrapper check (I43: spans all bme modules)
checks.push(checkAgentSkillWrappers(projectRoot, modules));
// 5. Global checks (module-agnostic)
checks.push(await checkOutputDir(projectRoot));

@@ -201,2 +205,8 @@ checks.push(checkMigrationLock(projectRoot));

const agentIds = mod.config.agents;
// U8: `agents` in config.yaml already has exclusions filtered out (mergeConfig does this
// at upgrade time). We read `excluded_agents` purely to surface the opt-out list in the
// info line — so operators can see what's excluded without cross-referencing files.
const excluded = Array.isArray(mod.config.excluded_agents)
? mod.config.excluded_agents.filter(a => typeof a === 'string')
: [];

@@ -238,3 +248,7 @@ if (!fs.existsSync(agentsDir)) {

return { name: label, passed: true, info: `${agentIds.length} agents present` };
let info = `${agentIds.length} agents present`;
if (excluded.length > 0) {
info += ` (${excluded.length} excluded: ${excluded.join(', ')})`;
}
return { name: label, passed: true, info };
}

@@ -428,2 +442,42 @@

function checkAgentSkillWrappers(projectRoot, modules = []) {
const label = 'BME agent skill wrappers';
// U8: gather excluded agent IDs across all discovered modules so their wrappers
// don't get flagged as missing (they are intentionally absent).
const excludedIds = new Set();
for (const mod of modules) {
if (mod.config && Array.isArray(mod.config.excluded_agents)) {
for (const id of mod.config.excluded_agents) {
if (typeof id === 'string') excludedIds.add(id);
}
}
}
const allAgents = [...AGENTS, ...GYRE_AGENTS, ...EXTRA_BME_AGENTS].filter(
a => !excludedIds.has(a.id)
);
const failures = [];
for (const agent of allAgents) {
const wrapperPath = path.join(projectRoot, '.claude', 'skills', `bmad-agent-bme-${agent.id}`, 'SKILL.md');
if (!fs.existsSync(wrapperPath)) {
failures.push(`Missing: .claude/skills/bmad-agent-bme-${agent.id}/SKILL.md`);
}
}
if (failures.length > 0) {
return {
name: label,
passed: false,
error: failures.join('; '),
fix: 'Run convoke-update to regenerate agent skill wrappers'
};
}
const info = excludedIds.size > 0
? `${allAgents.length} agent skill wrappers verified (${excludedIds.size} excluded)`
: `${allAgents.length} agent skill wrappers verified`;
return { name: label, passed: true, info };
}
async function checkOutputDir(projectRoot) {

@@ -430,0 +484,0 @@ const outputDir = path.join(projectRoot, '_bmad-output');

+3
-2
scripts/migrate-artifacts.js

@@ -138,3 +138,4 @@ #!/usr/bin/env node

'problem-def', 'hypothesis', 'experiment', 'signal', 'decision', 'scope',
'pre-reg', 'sprint', 'brief', 'vision', 'report', 'research', 'story', 'spec'
'pre-reg', 'sprint', 'brief', 'vision', 'report', 'research', 'story', 'spec',
'covenant'
];

@@ -389,3 +390,3 @@

scopeDirs: filteredIncludeDirs
});
}, taxonomy);

@@ -392,0 +393,0 @@ const adrDir = path.join(projectRoot, '_bmad-output', 'planning-artifacts');

+26
-5
scripts/portability/convoke-export.js

@@ -70,5 +70,10 @@ #!/usr/bin/env node

opts.all = true;
} else if (a === '--quiet' || a === '-q') {
opts.quiet = true;
} else if (a === '--output') {
const next = argv[i + 1];
if (!next || next.startsWith('--')) {
// Reject any `-`-prefixed token as a value — covers both long (`--flag`)
// and short (`-q`, `-h`) neighbors. Previously accepted `-q` as a literal
// output path; I50's short-alias introduction made that exploitable.
if (!next || next.startsWith('-')) {
opts.unknown = '--output (missing value)';

@@ -84,3 +89,4 @@ return opts;

const next = argv[i + 1];
if (!next || next.startsWith('--')) {
// See note on `--output` above: reject any `-`-prefixed token as a value.
if (!next || next.startsWith('-')) {
opts.unknown = '--tier (missing value)';

@@ -131,2 +137,5 @@ return opts;

' nothing. Combinable with all other flags.',
' --quiet, -q Suppress per-skill success and skip lines. Failures',
' (stderr) and the final summary line are still emitted.',
' Useful in CI / scripted pipelines.',
' --help, -h Print this message and exit 0.',

@@ -167,3 +176,4 @@ '',

function makeReporter() {
function makeReporter(opts = {}) {
const { quiet = false } = opts;
const results = { success: 0, failed: 0, skipped: 0, warnings: 0 };

@@ -174,2 +184,3 @@ return {

results.warnings += warnings;
if (quiet) return;
const suffix = warnings > 0 ? ` (${warnings} warnings)` : '';

@@ -179,2 +190,3 @@ process.stdout.write(`✅ ${skill} → ${relPath}${suffix}\n`);

failure(skill, error) {
// Failures always emit — `--quiet` suppresses success noise, not errors.
results.failed++;

@@ -186,5 +198,7 @@ const msg = (error && error.message ? error.message : String(error)).split('\n')[0];

results.skipped++;
if (quiet) return;
process.stdout.write(`⏭️ ${skill} — ${reason}\n`);
},
summary(dryRun) {
// Summary always emits — it's a single line that tells CI the batch outcome.
const prefix = dryRun ? '[DRY RUN] ' : '';

@@ -199,2 +213,5 @@ const total = results.success + results.failed + results.skipped;

},
isQuiet() {
return quiet;
},
};

@@ -421,3 +438,7 @@ }

if (matchingSkills.length === 0) {
process.stdout.write('Nothing to export — manifest matches found 0 skills\n');
// Suppress the friendly message in --quiet mode so the caller only sees
// the single-line summary ("Exported 0 skills (0/0/0) — 0 warnings total").
if (!reporter.isQuiet()) {
process.stdout.write('Nothing to export — manifest matches found 0 skills\n');
}
return EXIT_SUCCESS;

@@ -496,3 +517,3 @@ }

const reporter = makeReporter();
const reporter = makeReporter({ quiet: !!opts.quiet });

@@ -499,0 +520,0 @@ let exitCode;

+10
-8
scripts/portability/export-engine.js

@@ -272,3 +272,3 @@ /**

return {
name: agent.displayName,
name: agent.displayName || agent.name,
icon: agent.icon || '',

@@ -1012,9 +1012,4 @@ title: agent.title || '',

// 1. Load skill row + tier check (standalone + light-deps allowed; pipeline rejected)
// 1. Load skill row (all tiers exportable; pipeline skills get a framework-only notice)
const skillRow = loadSkillRow(skillName, projectRoot);
if (skillRow.tier === 'pipeline') {
throw new Error(
`${skillName} is tier "pipeline" — pipeline skills are not exported per the portability schema.`
);
}

@@ -1084,2 +1079,9 @@ // 2. Load source files

'',
];
// Framework-only notice for pipeline skills (not fully portable)
if (skillRow.tier === 'pipeline') {
parts.push('> **⚠️ Framework-only skill.** This skill depends on the full Convoke installation and cannot run standalone. It\'s included in the catalog for discoverability. Install Convoke from [convoke-agents](https://github.com/amalik/convoke-agents) to use it.');
parts.push('');
}
parts.push(
transformedSections.persona,

@@ -1094,3 +1096,3 @@ '',

transformedSections.whatYouProduce,
];
);
if (transformedSections.qualityChecks) {

@@ -1097,0 +1099,0 @@ parts.push('');

+6
-6
scripts/portability/seed-catalog-repo.js

@@ -89,5 +89,6 @@ #!/usr/bin/env node

const nameIdx = header.indexOf('name');
const tierIdx = header.indexOf('tier');
// Get unique exportable skill names (standalone + light-deps)
// Get unique exportable skill names (all tiers — pipeline gets a framework-only notice)
// Exclude meta-platform skills (framework internals, not user-facing)
const intentIdx = header.indexOf('intent');
const seen = new Set();

@@ -99,9 +100,8 @@ const exportableNames = [];

seen.add(name);
if (row[tierIdx] === 'standalone' || row[tierIdx] === 'light-deps') {
exportableNames.push(name);
}
if (row[intentIdx] === 'meta-platform') continue;
exportableNames.push(name);
}
exportableNames.sort();
console.log(`Exporting ${exportableNames.length} skills (standalone + light-deps)...`);
console.log(`Exporting ${exportableNames.length} skills (all tiers)...`);

@@ -108,0 +108,0 @@ // Create output directory

+25
-14
scripts/portability/validate-exports.js

@@ -87,21 +87,32 @@ #!/usr/bin/env node

// Balanced code fences
const fenceCount = (content.match(/^```/gm) || []).length;
if (fenceCount % 2 !== 0) {
issues.push({ skill: skillName, file: 'instructions.md', issue: `unbalanced code fences (${fenceCount} found)` });
// Framework-only (pipeline) skills skip strict structural checks since they
// intentionally reference framework-internal paths and may have unbalanced
// fences after transformations strip framework scaffolding
const isFrameworkOnly = content.includes('⚠️ Framework-only skill.');
// Balanced code fences (skipped for framework-only)
if (!isFrameworkOnly) {
const fenceCount = (content.match(/^```/gm) || []).length;
if (fenceCount % 2 !== 0) {
issues.push({ skill: skillName, file: 'instructions.md', issue: `unbalanced code fences (${fenceCount} found)` });
}
}
// Broken markdown links (links to local files that aren't URLs or anchors)
const localLinks = [...content.matchAll(/\[([^\]]*)\]\((?!https?:\/\/|#|mailto:)([^)]+)\)/g)];
for (const match of localLinks) {
const linkTarget = match[2];
// Skip links containing template placeholders or non-path content
if (linkTarget.includes('[') || linkTarget.includes('{')) continue;
if (linkTarget.includes(' ')) continue; // URLs/paths don't have spaces; this is prose like "(none found)"
const resolved = path.resolve(path.dirname(filePath), linkTarget);
if (!fs.existsSync(resolved)) {
issues.push({ skill: skillName, file: 'instructions.md', issue: `broken link: [${match[1]}](${linkTarget})` });
// Broken markdown links (skipped for framework-only)
if (!isFrameworkOnly) {
// Broken markdown links (links to local files that aren't URLs or anchors)
const localLinks = [...content.matchAll(/\[([^\]]*)\]\((?!https?:\/\/|#|mailto:)([^)]+)\)/g)];
for (const match of localLinks) {
const linkTarget = match[2];
// Skip links containing template placeholders or non-path content
if (linkTarget.includes('[') || linkTarget.includes('{')) continue;
if (linkTarget.includes(' ')) continue; // URLs/paths don't have spaces; this is prose like "(none found)"
const resolved = path.resolve(path.dirname(filePath), linkTarget);
if (!fs.existsSync(resolved)) {
issues.push({ skill: skillName, file: 'instructions.md', issue: `broken link: [${match[1]}](${linkTarget})` });
}
}
}
return issues;

@@ -108,0 +119,0 @@ }

+27
-2
scripts/update/convoke-update.js

@@ -9,2 +9,3 @@ #!/usr/bin/env node

const { findProjectRoot } = require('./lib/utils');
const { readChangelogEntries } = require('./lib/changelog-reader');

@@ -162,2 +163,4 @@ /**

printChangelog(assessment.currentVersion, assessment.targetVersion);
if (dryRun) {

@@ -225,2 +228,4 @@ console.log(chalk.yellow.bold('DRY RUN — no changes will be made'));

printChangelog(assessment.currentVersion, assessment.targetVersion);
// Dry run - preview only

@@ -286,2 +291,22 @@ if (dryRun) {

/**
* Render CHANGELOG sections for versions in (fromVersion, toVersion] to stdout.
* Silently skips if there are no matching entries — this is a decorative surface.
*/
function printChangelog(fromVersion, toVersion) {
const entries = readChangelogEntries(fromVersion, toVersion);
if (entries.length === 0) return;
console.log(chalk.cyan.bold("What's New:"));
console.log('');
for (const entry of entries) {
const header = entry.date
? `${entry.version} — ${entry.date}`
: entry.version;
console.log(chalk.bold.green(header));
console.log(entry.body);
console.log('');
}
}
/**
* Confirm action with user

@@ -305,4 +330,4 @@ * @param {string} message - Confirmation message

// Export assessUpdate for testing
module.exports = { assessUpdate };
// Export for testing
module.exports = { assessUpdate, printChangelog };

@@ -309,0 +334,0 @@ // Run main when executed directly

+52
-1
scripts/update/lib/config-merger.js

@@ -23,2 +23,36 @@ #!/usr/bin/env node

/**
* Read `excluded_agents` from a module's config.yaml without going through the
* full merge path. Used by refresh-installation and validator to skip copying
* / checking agents the operator has opted out of. U8: permanent agent
* exclusions that survive upgrades.
*
* @param {string} configPath - Absolute path to module config.yaml
* @returns {string[]} Array of excluded agent IDs (empty if missing, malformed, or not an array)
*/
function readExcludedAgents(configPath) {
let content;
try {
content = fs.readFileSync(configPath, 'utf8');
} catch (err) {
// ENOENT is expected on fresh installs (config hasn't been written yet).
// Other IO errors (EACCES, EISDIR, EMFILE, ...) indicate a real misconfiguration —
// warn so the operator knows their exclusions won't be applied this run. Never throw:
// this reader must not break the install flow.
if (err && err.code !== 'ENOENT') {
console.warn(`Warning: could not read ${configPath} for excluded_agents (${err.code || err.message}). Proceeding without exclusions.`);
}
return [];
}
try {
const parsed = yaml.load(content);
if (parsed && Array.isArray(parsed.excluded_agents)) {
return parsed.excluded_agents.filter(a => typeof a === 'string');
}
} catch (err) {
console.warn(`Warning: could not parse ${configPath} for excluded_agents (${err.message}). Proceeding without exclusions.`);
}
return [];
}
/**
* Merge current config with new template while preserving user preferences.

@@ -82,3 +116,11 @@ * Agents and workflows use smart-merge: canonical entries in registry order

// Core agents are always restored to canonical order. User-added agents (not in AGENT_IDS)
// are preserved and deduplicated. Deliberately removed core agents are restored on upgrade.
// are preserved and deduplicated.
//
// U8: respect `excluded_agents` — an operator-maintained opt-out list. Agents named in that
// list are filtered out of the active `agents` array so deliberate removals survive upgrades.
// Re-inclusion works by removing the agent from `excluded_agents` — the next merge restores
// it via the canonical spread above.
const excludedAgents = Array.isArray(current.excluded_agents)
? current.excluded_agents.filter(a => typeof a === 'string')
: [];
if (updates.agents) {

@@ -90,2 +132,10 @@ const userAgents = Array.isArray(current.agents)

}
// Apply exclusions to merged.agents regardless of whether `updates.agents` was provided —
// otherwise callers that pass empty updates (e.g., a workflows-only migration delta) would
// leak excluded agents back via the `defaults` spread at line 96.
if (excludedAgents.length > 0 && Array.isArray(merged.agents)) {
merged.agents = merged.agents.filter(a => !excludedAgents.includes(a));
}
// Preserve the exclusion list as a first-class field (empty stays empty — the schema default).
merged.excluded_agents = excludedAgents;

@@ -371,2 +421,3 @@ // Smart-merge workflows: canonical workflows in order, then unique user-added appended

mergeConfig,
readExcludedAgents,
extractUserPreferences,

@@ -373,0 +424,0 @@ validateConfig,

+48
-9
scripts/update/lib/refresh-installation.js

@@ -9,3 +9,3 @@ #!/usr/bin/env node

const configMerger = require('./config-merger');
const { AGENTS, AGENT_FILES, AGENT_IDS, WORKFLOW_NAMES, USER_GUIDES, GYRE_AGENTS, GYRE_AGENT_FILES, GYRE_AGENT_IDS, GYRE_WORKFLOW_NAMES, EXTRA_BME_AGENTS } = require('./agent-registry');
const { AGENTS, AGENT_FILES, AGENT_IDS, WORKFLOW_NAMES, GYRE_AGENTS, GYRE_AGENT_FILES, GYRE_AGENT_IDS, GYRE_WORKFLOW_NAMES, EXTRA_BME_AGENTS } = require('./agent-registry');

@@ -41,2 +41,11 @@ /**

// U8: read per-module `excluded_agents` from target configs BEFORE copy.
// These are opt-out lists the operator maintains; excluded agents don't get
// their agent file copied, don't get a skill wrapper generated, and don't
// fail presence checks downstream.
const vortexExcluded = configMerger.readExcludedAgents(path.join(targetVortex, 'config.yaml'));
const gyreExcluded = configMerger.readExcludedAgents(
path.join(projectRoot, '_bmad', 'bme', '_gyre', 'config.yaml')
);
// 1. Copy agent files

@@ -49,2 +58,8 @@ const agentsSource = path.join(packageVortex, 'agents');

for (const file of AGENT_FILES) {
const agentId = file.replace(/\.md$/, '');
if (vortexExcluded.includes(agentId)) {
changes.push(`Skipped excluded Vortex agent: ${file}`);
if (verbose) console.log(` Skipped excluded Vortex agent: ${file}`);
continue;
}
const src = path.join(agentsSource, file);

@@ -296,2 +311,8 @@ if (fs.existsSync(src)) {

for (const file of GYRE_AGENT_FILES) {
const agentId = file.replace(/\.md$/, '');
if (gyreExcluded.includes(agentId)) {
changes.push(`Skipped excluded Gyre agent: ${file}`);
if (verbose) console.log(` Skipped excluded Gyre agent: ${file}`);
continue;
}
const src = path.join(gyreAgentsSource, file);

@@ -509,7 +530,11 @@ if (fs.existsSync(src)) {

// U8: filter out excluded agents so manifest rows don't point at wrappers the
// stale-cleanup loop (§6) just removed. Left in, rows become dangling pointers.
const activeVortexAgents = AGENTS.filter(a => !vortexExcluded.includes(a.id));
const activeGyreAgents = GYRE_AGENTS.filter(a => !gyreExcluded.includes(a.id));
let bmeRows;
if (isV610) {
bmeRows = [
...AGENTS.map(a => buildAgentRow610(a, '_vortex')),
...GYRE_AGENTS.map(a => buildAgentRow610(a, '_gyre')),
...activeVortexAgents.map(a => buildAgentRow610(a, '_vortex')),
...activeGyreAgents.map(a => buildAgentRow610(a, '_gyre')),
...EXTRA_BME_AGENTS.map(buildExtraBmeAgentRow610),

@@ -519,4 +544,4 @@ ];

bmeRows = [
...AGENTS.map(a => buildAgentRowLegacy(a, '_vortex')),
...GYRE_AGENTS.map(a => buildAgentRowLegacy(a, '_gyre')),
...activeVortexAgents.map(a => buildAgentRowLegacy(a, '_vortex')),
...activeGyreAgents.map(a => buildAgentRowLegacy(a, '_gyre')),
...EXTRA_BME_AGENTS.map(buildExtraBmeAgentRowLegacy),

@@ -537,3 +562,12 @@ ];

if (!isSameRoot) {
for (const guide of USER_GUIDES) {
// U8: user guides are named after each agent (e.g., NOAH-USER-GUIDE.md). Iterate
// AGENTS so we can match guides to agent IDs and skip excluded ones — a guide
// without its agent is dead docs.
for (const agent of AGENTS) {
const guide = `${agent.name.toUpperCase()}-USER-GUIDE.md`;
if (vortexExcluded.includes(agent.id)) {
changes.push(`Skipped excluded guide: ${guide}`);
if (verbose) console.log(` Skipped excluded guide: ${guide}`);
continue;
}
const src = path.join(guidesSource, guide);

@@ -573,6 +607,9 @@ const dest = path.join(guidesTarget, guide);

// Remove stale skill directories (agents no longer in registry)
// Remove stale skill directories (agents no longer in registry OR excluded by operator).
// U8: excluded agents are intentionally omitted from the valid set so the stale-removal
// loop below deletes their wrappers on the next refresh. Re-inclusion (removing from
// excluded_agents) regenerates the wrapper here.
const currentSkillDirs = new Set([
...AGENTS.map(a => `bmad-agent-bme-${a.id}`),
...GYRE_AGENTS.map(a => `bmad-agent-bme-${a.id}`),
...AGENTS.filter(a => !vortexExcluded.includes(a.id)).map(a => `bmad-agent-bme-${a.id}`),
...GYRE_AGENTS.filter(a => !gyreExcluded.includes(a.id)).map(a => `bmad-agent-bme-${a.id}`),
...EXTRA_BME_AGENTS.map(a => `bmad-agent-bme-${a.id}`),

@@ -592,2 +629,3 @@ ]);

for (const agent of AGENTS) {
if (vortexExcluded.includes(agent.id)) continue;
const skillDir = path.join(skillsDir, `bmad-agent-bme-${agent.id}`);

@@ -618,2 +656,3 @@ await fs.ensureDir(skillDir);

for (const agent of GYRE_AGENTS) {
if (gyreExcluded.includes(agent.id)) continue;
const skillDir = path.join(skillsDir, `bmad-agent-bme-${agent.id}`);

@@ -620,0 +659,0 @@ await fs.ensureDir(skillDir);

+2
-1
scripts/update/lib/taxonomy-merger.js

@@ -14,3 +14,4 @@ const fs = require('fs-extra');

'problem-def', 'hypothesis', 'experiment', 'signal', 'decision', 'scope',
'pre-reg', 'sprint', 'brief', 'vision', 'report', 'research', 'story', 'spec'
'pre-reg', 'sprint', 'brief', 'vision', 'report', 'research', 'story', 'spec',
'covenant'
];

@@ -17,0 +18,0 @@ 

+9
-1
scripts/update/lib/validator.js

@@ -114,3 +114,11 @@ #!/usr/bin/env node

const agentsDir = path.join(projectRoot, '_bmad/bme/_vortex/agents');
const requiredAgents = AGENT_FILES;
// U8: honor operator agent exclusions from the target config.yaml, so a
// deliberately-removed agent doesn't fail post-upgrade validation.
const configMerger = require('./config-merger');
const excluded = configMerger.readExcludedAgents(
path.join(projectRoot, '_bmad/bme/_vortex/config.yaml')
);
const requiredAgents = AGENT_FILES.filter(
f => !excluded.includes(f.replace(/\.md$/, ''))
);

@@ -117,0 +125,0 @@ if (!fs.existsSync(agentsDir)) {

-146
_bmad/bme/_enhance...ives-backlog/steps-c/step-c-03-score.md
---
name: 'step-c-03-score'
description: 'Propose RICE scores for gathered initiatives in batch, validate with user, assign track labels'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-04-prioritize.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/rice-scoring-guide.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'
---
# Step 3: Batch RICE Scoring
## STEP GOAL:
Propose RICE scores and Track assignments for all gathered initiatives, present the scored batch for user validation, and finalize scores before backlog generation.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input at the scoring menu
- 📖 CRITICAL: Read this complete step file before taking action
- 🔄 CRITICAL: When loading next step with 'C', read the entire file
- 📋 YOU ARE A SCORING ANALYST proposing calibrated RICE scores
### Role Reinforcement:
- ✅ You are a **RICE scoring analyst** — systematic, calibrated, evidence-based
- ✅ Propose scores grounded in the scoring guide's definitions and calibration examples
- ✅ The user validates and adjusts your proposals — you propose, they decide
- ✅ Assign Track labels based on initiative nature: maintenance/stability = "Keep the lights on", growth/new capability = "Move the needle"
### Step-Specific Rules:
- 🎯 Focus on scoring, rationale, Track assignment, and composite calculation
- 🚫 FORBIDDEN to write to the backlog file (that is step-c-04's job)
- 🚫 FORBIDDEN to re-gather or add new initiatives (that was step-c-02's job)
- 💬 Approach: propose entire batch at once so user sees relative positioning, then collaborative refinement
## EXECUTION PROTOCOLS:
- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load `{templateFile}` for RICE factor definitions, scales, and calibration examples
- 💾 Recalculate and re-sort after every score adjustment
## CONTEXT BOUNDARIES:
- Available context: Gathered initiatives from step-c-02, RICE scoring guide template
- Focus: Scoring and user validation only
- Limits: Do NOT write to backlog or modify gathered initiative descriptions
- Dependencies: step-c-02-gather.md (gathered initiatives list)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
### 1. Load RICE Scoring Guide
Load `{templateFile}` (rice-scoring-guide.md) and internalize:
- **Factor definitions:** Reach (1-10), Impact (0.25-3), Confidence (20-100%), Effort (1-10)
- **Guided questions** for each factor
- **Calibration examples** (study the reasoning, not just the numbers)
- **Composite formula:** Score = (R x I x C) / E, where C is decimal (e.g., 70% = 0.7)
- **Score rounding:** One decimal place for display
### 2. Propose RICE Scores and Track for All Initiatives
For each gathered initiative, propose RICE scores using the guided questions:
- **Reach (1-10):** "How many users per quarter will this affect?"
- **Impact (0.25-3):** "What's the per-user impact?"
- **Confidence (20-100%):** "How confident are we in these estimates?" Default to 50% when no direct evidence exists.
- **Effort (1-10):** "Relative effort in story points?"
- **Track:** "Keep the lights on" (maintenance, stability, bug fixes) or "Move the needle" (growth, new capability, strategic)
For each score, write a **one-line rationale** explaining the scoring basis. Example:
> **#1: Add output examples for Noah agent** — R:5 I:1 C:70% E:2 = 1.8 | Move the needle
> *Reach 5: affects users checking agent outputs. Impact 1: helpful but workarounds exist. Confidence 70%: pattern validated with other agents. Effort 2: single file addition.*
### 3. Calculate Composite Scores and Sort
For each initiative:
1. Calculate composite: Score = (Reach x Impact x Confidence) / Effort
2. Round to one decimal place
3. Verify score falls within expected range (~0.0 to ~30.0)
Sort the batch:
1. **Primary:** Descending by composite score
2. **Tiebreak 1:** Higher Confidence first
3. **Tiebreak 2:** Newer insertion order first
### 4. Present Scoring Batch
Display the scored results:
> **RICE Scoring — Review Proposed Scores**
>
> **Initiatives scored: [N]**
>
> | # | Initiative | R | I | C | E | Score | Track | Rationale |
> |---|-----------|---|---|---|---|-------|-------|-----------|
> | 1 | [title] | 5 | 2 | 80% | 3 | 2.7 | Move the needle | [one-line rationale] |
> | 2 | [title] | 3 | 1 | 60% | 2 | 0.9 | Keep the lights on | [one-line rationale] |
>
> *Sorted by composite score (descending). Formula: (R x I x C) / E*
### 5. Present SCORING MENU OPTIONS
Display:
> **Adjust scores or finalize:**
>
> **Score adjustments** (by item number):
> - `#N R [value]` — Change Reach (1-10)
> - `#N I [value]` — Change Impact (0.25, 0.5, 1, 2, or 3)
> - `#N CF [value]` — Change Confidence (20-100%)
> - `#N E [value]` — Change Effort (1-10)
> - `#N T [value]` — Change Track ("keep" or "move")
>
> **Batch editing:**
> - `D #N` — Drop item #N from the batch (will not be added to backlog)
>
> **[A] Advanced Elicitation** — Deeper analysis of scoring rationale
> **[P] Party Mode** — Multi-perspective scoring discussion
> **[C] Continue** — Finalize scores and proceed to backlog generation
#### Menu Handling Logic:
- IF `#N R [value]`: Update Reach for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `#N I [value]`: Update Impact for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `#N CF [value]`: Update Confidence for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `#N E [value]`: Update Effort for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `#N T [value]`: Update Track for item #N ("keep" = "Keep the lights on", "move" = "Move the needle"). Redisplay table and menu.
- IF `D #N`: Remove item #N from the scoring batch. Redisplay table and menu.
- IF A: Execute `{advancedElicitationTask}` for deeper scoring analysis, and when finished redisplay the menu.
- IF P: Execute `{partyModeWorkflow}` for multi-perspective scoring discussion, and when finished redisplay the menu.
- IF C: Finalize the scored batch. Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-c/step-c-04-prioritize.md`
- IF any other input: Display "Unknown command. Use `#N R/I/CF/E/T [value]`, `D #N`, **A**, **P**, or **C** to continue." then redisplay menu.
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting the menu
- After EVERY score or Track adjustment, recalculate composite, re-sort, and redisplay the full table AND the menu
- The user may make multiple adjustments before pressing C
- ONLY proceed to step-c-04 when user selects 'C'
- After A or P execution, return to this menu
- Do NOT auto-continue — the user must explicitly approve the scores
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: All initiatives scored with calibrated RICE components, rationale, and Track assignment, composites calculated correctly, batch sorted by score, user validated scores, finalized batch passed to step-c-04
### ❌ SYSTEM FAILURE: Scores proposed without rationale, composite formula wrong, Track not assigned, scores outside valid ranges, user not given validation opportunity, items written to backlog prematurely
**Master Rule:** Skipping steps is FORBIDDEN.
-181
_bmad/bme/_enhance...backlog/steps-c/step-c-04-prioritize.md
---
name: 'step-c-04-prioritize'
description: 'Generate complete backlog file with categorized items, prioritized view, and completion summary'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md'
workflowFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/workflow.md'
---
# Step 4: Backlog Generation, Prioritized View & Completion
## STEP GOAL:
Generate the complete backlog file from scratch using the scored initiatives, including all required sections, the prioritized view, provenance tags, and a changelog entry. Present a completion summary and return to the T/R/C menu.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without completing all mandatory sequence steps
- 📖 CRITICAL: Read this complete step file before taking action
- 🔄 CRITICAL: When returning to menu, read the entire workflow file
- 📋 YOU ARE A BACKLOG OPERATIONS SPECIALIST generating a new backlog file
### Role Reinforcement:
- ✅ You are a **backlog operations specialist** — precise, structured, format-compliant
- ✅ Generate the file exactly matching the backlog format specification — no shortcuts
- ✅ All output must be standard markdown — no HTML, no proprietary syntax
- ✅ Every item gets provenance, every section gets created, the prioritized view is sorted
### Step-Specific Rules:
- 🎯 Focus on file generation, provenance, prioritized view, and completion reporting
- 🚫 FORBIDDEN to rescore items (scoring was finalized in step-c-03)
- 🚫 FORBIDDEN to add new items not in the scored batch
- 🚫 FORBIDDEN to modify step-c-01, step-c-02, or step-c-03
- 💬 Approach: generate the complete file, summarize clearly, return to menu
## EXECUTION PROTOCOLS:
- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load `{templateFile}` (backlog-format-spec.md) for exact structural requirements and table formats
- 💾 Write to `{outputFile}` as a complete new file
## CONTEXT BOUNDARIES:
- Available context: Scored initiatives from step-c-03, backlog format spec template
- Focus: File generation, prioritized view, completion summary
- Limits: Do NOT rescore or re-gather items
- Dependencies: step-c-03-score.md (finalized scored initiatives with Track assignments)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
### 1. Load Format Specification
Load `{templateFile}` (backlog-format-spec.md) and reference:
- **Metadata header** format (title, Created, Method, Last Updated)
- **Section hierarchy** — all 7 H2 sections in exact order
- **Table formats** — Category table (10 columns), Prioritized View (6 columns), Exploration Candidates (4 columns)
- **Item ID format** — Category prefix letter + sequential number
- **Provenance format** — "Added from Create mode, [date]"
### 2. Generate Metadata Header
```markdown
# Convoke Initiatives Backlog
**Created:** [current date YYYY-MM-DD]
**Method:** RICE (Reach, Impact, Confidence, Effort)
**Last Updated:** [current date YYYY-MM-DD]
```
### 3. Generate RICE Scoring Guide Section
Create the `## RICE Scoring Guide` section with an inline summary of the methodology:
- Composite formula: Score = (R x I x C) / E
- Factor scales: Reach (1-10), Impact (0.25-3), Confidence (20-100%), Effort (1-10)
- Sort order: Descending by score, tiebreak by Confidence then insertion order
### 4. Generate Backlog Section with Category Tables
Create the `## Backlog` section. For each unique category in the scored items:
1. Create an H3 heading: `### [Category Name]`
2. Create a 10-column table:
```markdown
| # | Initiative | Source | R | I | C | E | Score | Track | Status |
|---|-----------|--------|---|---|---|---|-------|-------|--------|
```
3. For each item in this category:
- **#:** Generate item ID using category prefix letter + sequential number within category (e.g., D1, D2, P1)
- Category prefix mapping: D = Documentation & Onboarding, U = Update & Migration System, T = Testing & CI, I = Infrastructure, A = Agent Quality & Consistency, P = Platform & Product Vision
- New categories: use the first uppercase letter of the category name that is not already in use (D, U, T, I, A, P are reserved)
- **Initiative:** `**[Title]** — [description]. Added from Create mode, [date]`
- **Source:** "Create mode"
- **R, I, C, E:** Individual RICE component scores (C as percentage, e.g., 70%)
- **Score:** Composite score, one decimal place
- **Track:** "Keep the lights on" or "Move the needle"
- **Status:** "Backlog"
### 5. Generate Empty Sections
Create the following sections with empty content:
**Exploration Candidates:**
```markdown
## Exploration Candidates
| # | Initiative | Source | Next Step |
|---|-----------|--------|-----------|
```
**Epic Groupings:**
```markdown
## Epic Groupings
*No epic groupings defined yet.*
```
**Completed:**
```markdown
## Completed
*No completed items yet.*
```
### 6. Generate Prioritized View
Create the `## Prioritized View (by RICE Score)` section:
1. Collect ALL items from all category tables
2. Sort by composite RICE score descending
3. Tiebreak: (1) Higher Confidence first, (2) Newer insertion order first
4. Generate sequential rank numbers starting at 1
```markdown
## Prioritized View (by RICE Score)
| Rank | # | Initiative | Score | Track | Category |
|------|---|-----------|-------|-------|----------|
```
### 7. Generate Change Log
Create the `## Change Log` section with the initial creation entry:
```markdown
## Change Log
| Date | Change |
|------|--------|
| [YYYY-MM-DD] | Create: Bootstrapped new backlog with [N] items ([list categories affected]). |
```
### 8. Write Complete File
Write the complete assembled backlog to `{outputFile}`. The file must contain all 7 H2 sections in the correct order as specified by the format spec.
### 9. Completion Summary & Return to Menu
After successful write, display:
> **Create Complete**
>
> **Items created:** [N]
> **Categories:** [list category names]
>
> **Top 3 Positions:**
> 1. [#ID] [title] — Score: [X.X]
> 2. [#ID] [title] — Score: [X.X]
> 3. [#ID] [title] — Score: [X.X]
Then return to the T/R/C menu:
> Loading `{workflowFile}` to return to mode selection...
Load, read the entire file, and execute `{workflowFile}`.
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: Complete backlog file generated with all 7 H2 sections in correct order, items placed in correct category tables with 10 columns, item IDs generated correctly, provenance tags added, prioritized view sorted and generated with 6 columns, changelog entry added, completion summary displayed with top 3, T/R/C menu re-presented
### ❌ SYSTEM FAILURE: Missing H2 sections, wrong section order, items without provenance, wrong column counts, item IDs not generated, prioritized view not sorted, no changelog entry, no completion summary, no return to menu
**Master Rule:** Skipping steps is FORBIDDEN.
-147
_bmad/bme/_enhance...ives-backlog/steps-t/step-t-03-score.md
---
name: 'step-t-03-score'
description: 'Propose RICE scores for confirmed findings, validate at Gate 2, calculate composite scores'
nextStepFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-04-update.md'
outputFile: '{planning_artifacts}/initiatives-backlog.md'
templateFile: '{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/rice-scoring-guide.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.md'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'
---
# Step 3: RICE Scoring & Gate 2 Validation
## STEP GOAL:
Propose RICE scores for each confirmed finding from Gate 1, present the scored batch for user validation at Gate 2, and calculate composite scores with proper sorting.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input at Gate 2
- 📖 CRITICAL: Read this complete step file before taking action
- 🔄 CRITICAL: When loading next step with 'C', read the entire file
- 📋 YOU ARE A SCORING ANALYST proposing calibrated RICE scores
### Role Reinforcement:
- ✅ You are a **RICE scoring analyst** — systematic, calibrated, evidence-based
- ✅ Propose scores grounded in the scoring guide's definitions and calibration examples
- ✅ The user validates and adjusts your proposals at Gate 2 — you propose, they decide
- ✅ Compare proposed scores against existing backlog items for calibration consistency
### Step-Specific Rules:
- 🎯 Focus on scoring, rationale, and composite calculation
- 🚫 FORBIDDEN to write to the backlog file (that is step-t-04's job)
- 🚫 FORBIDDEN to re-extract or re-classify findings (that was step-t-02's job)
- 🚫 FORBIDDEN to add new findings at Gate 2 (that was Gate 1's job — only drops allowed here)
- 💬 Approach: propose entire batch at once so user sees relative positioning, then collaborative refinement
## EXECUTION PROTOCOLS:
- 🎯 Follow the MANDATORY SEQUENCE exactly
- 📖 Load {templateFile} for RICE factor definitions, scales, and calibration examples
- 💾 Recalculate and re-sort after every Gate 2 adjustment
## CONTEXT BOUNDARIES:
- Available context: Confirmed findings from Gate 1, existing backlog (if loaded), RICE scoring guide template
- Focus: Scoring and Gate 2 validation only
- Limits: Do NOT write to backlog or modify extraction results
- Dependencies: step-t-02-extract.md (confirmed findings from Gate 1)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
### 1. Load RICE Scoring Guide
Load `{templateFile}` (rice-scoring-guide.md) and internalize:
- **Factor definitions:** Reach (1-10), Impact (0.25-3), Confidence (20-100%), Effort (1-10)
- **Guided questions** for each factor
- **Calibration examples** from the existing backlog (study the reasoning, not just the numbers)
- **Composite formula:** Score = (R x I x C) / E, where C is decimal (e.g., 70% = 0.7)
- **Score rounding:** One decimal place for display
### 2. Propose RICE Scores for All Findings
For each confirmed finding from Gate 1, propose RICE scores using the guided questions:
- **Reach (1-10):** "How many users per quarter will this affect?"
- **Impact (0.25-3):** "What's the per-user impact?"
- **Confidence (20-100%):** "How confident are we in these estimates?" Default to 50% when no direct evidence exists.
- **Effort (1-10):** "Relative effort in story points?"
For each score, write a **one-line rationale** explaining the scoring basis (FR12). Example:
> **#1: Add output examples for Noah agent** — R:5 I:1 C:70% E:2 = 1.8
> *Reach 5: affects users checking agent outputs. Impact 1: helpful but workarounds exist. Confidence 70%: pattern validated with other agents. Effort 2: single file addition.*
**Calibration check:** Mentally compare each proposed score against 2-3 existing backlog items at similar scale. If the score would rank the item significantly above or below where it "feels" relative to those items, revisit the component scores.
### 3. Calculate Composite Scores and Sort
For each finding:
1. Calculate composite: Score = (Reach x Impact x Confidence) / Effort
2. Round to one decimal place
3. Verify score falls within expected range (~0.0 to ~30.0; existing backlog ranges ~0.2 to ~10.0)
Sort the batch:
1. **Primary:** Descending by composite score
2. **Tiebreak 1:** Higher Confidence first
3. **Tiebreak 2:** Newer insertion order first
### 4. Present Scoring Batch (Gate 2)
Display the scored results:
> **Gate 2 — Review Proposed RICE Scores**
>
> **Scored findings: [N]**
>
> | # | Finding | R | I | C | E | Score | Rationale |
> |---|---------|---|---|---|---|-------|-----------|
> | 1 | [title] | 5 | 2 | 80% | 3 | 2.7 | [one-line rationale] |
> | 2 | [title] | 3 | 1 | 60% | 2 | 0.9 | [one-line rationale] |
> | 3 | [title] | 7 | 0.5 | 50% | 1 | 1.8 | [one-line rationale] |
>
> *Sorted by composite score (descending). Formula: (R x I x C) / E*
### 5. Present GATE 2 MENU OPTIONS
Display:
> **Gate 2 — Adjust scores or finalize:**
>
> **Score adjustments** (by item number):
> - `#N R [value]` — Change Reach (1-10)
> - `#N I [value]` — Change Impact (0.25, 0.5, 1, 2, or 3)
> - `#N CF [value]` — Change Confidence (20-100%)
> - `#N E [value]` — Change Effort (1-10)
>
> **Batch editing:**
> - `D #N` — Drop item #N from the batch (will not be added to backlog)
>
> **[A] Advanced Elicitation** — Deeper analysis of scoring rationale
> **[P] Party Mode** — Multi-perspective scoring discussion
> **[C] Continue** — Finalize scores and proceed to backlog update
#### Menu Handling Logic:
- IF `#N R [value]`: Update Reach for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `#N I [value]`: Update Impact for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `#N CF [value]`: Update Confidence for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `#N E [value]`: Update Effort for item #N. Recalculate composite. Re-sort batch. Redisplay table and menu.
- IF `D #N`: Remove item #N from the scoring batch. Redisplay table and menu.
- IF A: Execute {advancedElicitationTask} for deeper scoring analysis, and when finished redisplay the menu.
- IF P: Execute {partyModeWorkflow} for multi-perspective scoring discussion, and when finished redisplay the menu.
- IF C: Finalize the scored batch. Load, read the entire file, and execute `{project-root}/_bmad/bme/_enhance/workflows/initiatives-backlog/steps-t/step-t-04-update.md`
- IF any other input: Display "Unknown command. Use `#N R/I/CF/E [value]`, `D #N`, **A**, **P**, or **C** to continue." then redisplay menu.
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting the menu
- After EVERY score adjustment, recalculate composite, re-sort, and redisplay the full table AND the menu
- The user may make multiple adjustments before pressing C
- ONLY proceed to step-t-04 when user selects 'C'
- After A or P execution, return to this menu
- Do NOT auto-continue — the user must explicitly approve the scores
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
### ✅ SUCCESS: All findings scored with calibrated RICE components and rationale, composites calculated correctly, batch sorted by score, user validated at Gate 2, finalized scores passed to step-t-04
### ❌ SYSTEM FAILURE: Scores proposed without rationale, composite formula wrong, scores outside valid ranges, user not given Gate 2 validation, findings written to backlog prematurely
**Master Rule:** Skipping steps is FORBIDDEN.
scripts/lib/artifact-utils.js

Sorry, the diff of this file is too big to display