convoke-agents 3.2.1 → 3.3.0

package/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/backlog-format-spec.md

@@ -1,219 +1,330 @@
 # 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
+---
+
+## Frontmatter
 
-**Created:** YYYY-MM-DD
-**Method:** RICE (Reach, Impact, Confidence, Effort)
-**Last Updated:** YYYY-MM-DD
+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)
+
+## 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)
+
+## 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)
+
+## Appendix: Initiative Details                        (H2 — full descriptions for §2.4 items)
+### [Item ID] — [Title]                                (H3 — one per initiative when detail is needed)
+
+## Change Log                                          (H2 — operational history)
+```
 
-## RICE Scoring Guide                            (H2 — inline scoring reference)
+**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.
 
-## Backlog                                       (H2 — active items container)
-### [Category Name]                              (H3 — one per category, repeating)
+**Part 2** is the operational surface — Triage adds rows, Review updates rows.
 
-## Exploration Candidates                        (H2 — unscored items needing discovery)
+**Appendix** holds detailed descriptions for Initiative Lane items whose table row is a one-liner.
 
-## Epic Groupings                                (H2 — bundled delivery suggestions)
-### Epic: "[Name]" ([item IDs])                  (H3 — one per grouping)
+---
 
-## Prioritized View (by RICE Score)              (H2 — auto-generated ranked table)
+## Table Formats
 
-## Completed                                     (H2 — finished items, grouped by date)
-### YYYY-MM-DD                                   (H3 — date grouping for milestones)
+### §2.1 Intakes Table
 
-## Change Log                                    (H2 — operational history)
+```markdown
+| ID | Description | Source | Date | Raiser |
+|----|-------------|--------|------|--------|
 ```
 
-### Category Names
+**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.
 
-Categories are user-defined H3 headings under `## Backlog`. The existing backlog uses:
+**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.
 
-- Documentation & Onboarding
-- Update & Migration System
-- Testing & CI
-- Infrastructure
-- Agent Quality & Consistency
-- Platform & Product Vision
+### §2.2 Bug Lane Table
 
-New categories may be added. Category names must be unique within the backlog.
+```markdown
+| ID | Description | R | I | C | E | Score | Portfolio | Status | Dependencies | Linked Follow-up |
+|----|-------------|---|---|---|---|-------|-----------|--------|--------------|------------------|
+```
 
----
+**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.
 
-## Table Formats
+**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.
 
-### Category Table (under each H3 category)
+### §2.3 Fast Lane Table
 
 ```markdown
-| # | Initiative | Source | R | I | C | E | Score | Track | Status |
-|---|-----------|--------|---|---|---|---|-------|-------|--------|
+| ID | Description | R | I | C | E | Score | Portfolio | Status | Dependencies |
+|----|-------------|---|---|---|---|-------|-----------|--------|--------------|
 ```
 
-**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`: 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.
 
-### Prioritized View Table (under `## Prioritized View`)
+**Sort:** Descending by composite Score. Dependencies do not affect sort.
+
+### §2.4 Initiative Lane Table
 
 ```markdown
-| Rank | # | Initiative | Score | Track | Category |
-|------|---|-----------|-------|-------|----------|
+| ID | Description | R | I | C | E | Score | Portfolio | Stage | Artifacts | 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
-
-### Exploration Candidates Table (under `## Exploration Candidates`)
+**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.
+
+**Sort:** Descending by composite Score (same rule as Fast Lane). Dependencies do not affect sort.
+
+### §2.5 Absorbed / Archived Tables
+
+Use H4 sub-headings to group:
+
+**Absorbed into [target]:**
+```markdown
+| ID | Original Description | Absorbed Into | Reference | Date |
+|----|---------------------|---------------|-----------|------|
+```
 
+**Completed (shipped):**
 ```markdown
-| # | Initiative | Source | Next Step |
-|---|-----------|--------|-----------|
+| ID | Description | Shipped | Score | Portfolio |
+|----|-------------|---------|-------|-----------|
 ```
 
-These items are unscored and not included in the prioritized view.
+**Rules:**
+- Nothing disappears without a receipt.
+- Absorbed items must reference the target (epic file, larger initiative).
+- Completed items are append-only.
 
-### Completed Section Tables (under `## Completed`)
+### Appendix Detail Format
 
-Grouped by date using H3 headers:
+For each Initiative Lane item warranting detail:
 
 ```markdown
-### YYYY-MM-DD
+### [ID] — [Title]
 
-| # | Initiative | Score | Category |
-|---|-----------|-------|----------|
-```
+**Stage:** [stage] | **Portfolio:** [portfolio] | **RICE:** [score]
 
-**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.
+**Planning artifacts:** [list with file paths]
 
----
+**Missing (to reach Ready):** [list]
+
+**Blocker:** [if any]
 
-## Change Log Format
+**Scope hint:** [paragraph or bullets]
+```
 
-The Change Log section uses a table:
+### Change Log Table
 
 ```markdown
-## Change Log
-
 | Date | Change |
 |------|--------|
 | YYYY-MM-DD | [Description of what changed] |
 ```
 
-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.
 
 ---
 
 ## RICE Composite Formula
 
-**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
 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
+
+The qualifying gate (Vortex, John, or Winston) assigns each intake to one lane:
+
+**Bug Lane** if:
+- Observed broken behavior, regression, or data loss risk
+- Fix is the scope (deeper rework spawns separate Fast Lane / Initiative item)
+
+**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)
 
-Provenance is recorded in the Initiative cell description or as a separate annotation.
+**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
 
-### Triage Mode — New Items
+**When uncertain:** default to Fast Lane unless a clear architectural or multi-module signal exists. The qualifier can promote later if scope grows.
+
+---
+
+## Insertion Rules
 
-Format: `"Added from [source], [date]"`
+### Triage Mode (steps-t)
 
-Example: `Added from party-mode review transcript, 2026-03-15`
+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.
 
-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.
+### Review Mode (steps-r)
 
-### Review Mode — Rescored Items
+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.
 
-Format: `"Rescored [old]->[new], Review, [date]"`
+### Create Mode (steps-c)
 
-Example: `Rescored 1.8->2.4, Review, 2026-03-15`
+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.
 
-Only recorded when the composite score actually changes. Confirming an existing score or skipping an item generates no provenance entry.
+### Moving Items Between Sections
 
-### Create Mode — New Items
+- **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.
 
-Format: `"Added from Create mode, [date]"`
+Never delete a row outright — every removal becomes a §2.5 entry.
 
 ---
 
 ## Pre-Write Validation
 
-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).
 
 ---
 
 ## Format Consistency
 
-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)

package/_bmad/bme/_enhance/workflows/initiatives-backlog/templates/lifecycle-process-spec.md

@@ -0,0 +1,188 @@
+# 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).