@delorenj/pjangler 1.2.25 → 1.2.33

package/templates/commonproject/_bmad/custom/workflows/ticket-lifecycle/steps-c/step-05-review.md

@@ -1,146 +0,0 @@
----
-name: 'step-05-review'
-description: 'Validate tests pass and coverage maps to AC items before QA'
-
-nextStepFile: './step-06-qa.md'
-retryStepFile: './step-04-implement.md'
-auditCommentTemplate: '../data/audit-comment-template.md'
----
-
-# Step 5: Review Gate
-
-## STEP GOAL:
-
-To validate that all tests pass, test coverage maps to AC items, and no regressions exist before handing off to QA.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- Read the complete step file before taking any action.
-- If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread.
-
-### Role Reinforcement:
-
-- You are a workflow orchestrator performing automated review checks.
-- This is a validation gate, not a code review. Check tests and coverage, not code quality.
-
-### Step-Specific Rules:
-
-- Focus ONLY on test validation and AC coverage mapping.
-- FORBIDDEN to modify code or tests. If they fail, route back to implementation.
-- FORBIDDEN to perform QA verification. That is step 6.
-- This is an auto-proceed validation step. No human interaction.
-
-## EXECUTION PROTOCOLS:
-
-- Run the test suite.
-- Verify test coverage maps to AC items.
-- Check for regressions in existing tests.
-- Branch: pass -> QA, fail -> back to implementation.
-
-## CONTEXT BOUNDARIES:
-
-- Step 4 produced: code changes + tests committed to repo.
-- Focus: automated test validation only.
-- Dependencies: committed code and tests from Coding Agent.
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Run Test Suite
-
-Execute the project's test suite. Capture:
-- Total tests run
-- Tests passed
-- Tests failed
-- Test output/errors
-
-### 2. Verify AC Coverage
-
-For each AC item, check that at least one test exists that explicitly verifies it.
-- Map each AC item to its corresponding test(s).
-- Identify any AC items with no test coverage.
-
-### 3. Check for Regressions
-
-Compare current test results against the baseline:
-- Any previously passing tests now failing?
-- Any test suite errors unrelated to the new changes?
-
-### 4. Evaluate Review Gate
-
-**ALL THREE must pass:**
-1. All tests pass (zero failures)
-2. Every AC item has at least one covering test
-3. No regressions in existing test suite
-
-**IF ALL PASS:**
-
-Post audit comment using {auditCommentTemplate}:
-```
-[TICKET-LIFECYCLE] State Transition
----
-from: review
-to: qa
-timestamp: {ISO 8601}
-agent: orchestrator
-reason: Review gate passed. All tests pass, AC coverage complete, no regressions.
-details:
-  tests_run: {count}
-  tests_passed: {count}
-  ac_coverage: {N}/{total} items covered
----
-```
-
-Update ticket status to qa.
-Broadcast Bloodbank event with `new_state: "qa"`.
-
-**Proceeding to QA verification...**
-Immediately load, read entire file, then execute {nextStepFile}.
-
-**IF ANY FAIL:**
-
-Post audit comment:
-```
-[TICKET-LIFECYCLE] State Transition
----
-from: review
-to: in_progress
-timestamp: {ISO 8601}
-agent: orchestrator
-reason: Review gate failed. Routing back to implementation.
-details:
-  test_failures: [{list of failing tests}]
-  uncovered_ac: [{list of AC items without tests}]
-  regressions: [{list of regressed tests}]
----
-```
-
-Update ticket status back to in_progress.
-Broadcast Bloodbank event with `new_state: "in_progress"`.
-
-**Routing back to implementation with review failures...**
-Immediately load, read entire file, then execute {retryStepFile}.
-
----
-
-## SYSTEM SUCCESS/FAILURE METRICS
-
-### SUCCESS:
-
-- Test suite executed completely
-- AC-to-test coverage mapping performed
-- Regression check completed
-- Correct branch taken based on all three checks
-- Audit comment includes test metrics
-
-### FAILURE:
-
-- Not running the full test suite
-- Skipping AC coverage mapping
-- Modifying code or tests in this step
-- Not documenting specific failures when routing back
-
-**Master Rule:** This is an automated gate. Check, record, branch. Never fix.

package/templates/commonproject/_bmad/custom/workflows/ticket-lifecycle/steps-c/step-06-qa.md

@@ -1,199 +0,0 @@
----
-name: 'step-06-qa'
-description: 'Spawn QA Agent for line-item AC verification with retry loop handling'
-
-doneStepFile: './step-07-complete.md'
-retryStepFile: './step-04-implement.md'
-auditCommentTemplate: '../data/audit-comment-template.md'
-workflowConfig: '../workflow.yaml'
----
-
-# Step 6: QA Verification via QA Agent
-
-## STEP GOAL:
-
-To spawn a QA Agent that verifies each acceptance criteria item line-by-line, handling pass/fail/retry/blocked outcomes.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- Read the complete step file before taking any action.
-- If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread.
-
-### Role Reinforcement:
-
-- You are a workflow orchestrator delegating QA verification to a specialized agent.
-- You provide the QA Agent with AC items and code changes. You do not verify AC yourself.
-- The QA Agent is a BMAD agent (Claude Code session-scoped), spawned on-demand.
-
-### Step-Specific Rules:
-
-- Focus ONLY on delegating QA verification and handling the result.
-- FORBIDDEN to verify AC yourself. Delegate to QA Agent.
-- FORBIDDEN to fix code. Route failures back to Coding Agent (step 4).
-- Track retry count. Max retries loaded from {workflowConfig}.
-- On re-entry after a fix, only failed items need re-verification.
-
-## EXECUTION PROTOCOLS:
-
-- Load retry limit from {workflowConfig}.
-- Track which AC items have previously passed (partial pass tracking).
-- Spawn QA Agent for line-item verification.
-- Handle: all pass -> done, partial fail + retries available -> retry, max retries -> blocked.
-
-## CONTEXT BOUNDARIES:
-
-- Step 5 confirmed: tests pass, coverage maps to AC.
-- Focus: functional AC verification (does the implementation actually satisfy each AC item?).
-- Dependencies: passing tests from step 5, AC items, code changes.
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Load Retry Configuration
-
-Read {workflowConfig} to get `qa.max_retries` (default: 3).
-
-Check current retry count from ticket context:
-- If this is the first QA pass: retry_count = 0
-- If returning from a failed QA cycle: increment retry_count
-
-### 2. Determine Items to Verify
-
-**If first QA pass (retry_count == 0):**
-- Verify ALL AC items.
-
-**If retry (retry_count > 0):**
-- Only verify previously failed AC items.
-- Previously passed items retain their pass status.
-
-### 3. Spawn QA Agent Sub-Agent
-
-Launch a sub-agent with the role of **QA Agent**:
-
-**Agent Instructions:**
-"You are a QA Agent verifying acceptance criteria for ticket {ticket_id}: {ticket_title}.
-
-Verify each of the following AC items by testing the actual implementation:
-{ac_items_to_verify}
-
-For EACH item, produce a verdict:
-- PASS: The implementation satisfies this AC item. Include evidence.
-- FAIL: The implementation does NOT satisfy this AC item. Include:
-  - The AC item text
-  - Expected behavior
-  - Observed behavior
-
-Be thorough. Test edge cases where the AC implies them. Do not assume correctness from test results alone. Manually verify the actual behavior.
-
-Return: structured per-item verdicts."
-
-### 4. Aggregate Results
-
-Combine QA Agent results with any previously passed items to produce a complete AC verification report:
-
-For each AC item:
-- Item text
-- Verdict (PASS/FAIL)
-- Evidence or defect details
-
-### 5. Branch Based on Results
-
-**IF ALL AC ITEMS PASS:**
-
-Post audit comment using {auditCommentTemplate}:
-```
-[TICKET-LIFECYCLE] State Transition
----
-from: qa
-to: done
-timestamp: {ISO 8601}
-agent: qa-agent
-reason: All AC items verified (100% pass)
-details:
-  total_items: {count}
-  passed: {count}
-  retries_used: {retry_count}
----
-```
-
-Update ticket status to done.
-Broadcast Bloodbank event with `new_state: "done"`.
-
-**Proceeding to completion...**
-Immediately load, read entire file, then execute {doneStepFile}.
-
-**IF ANY ITEMS FAIL AND retry_count < max_retries:**
-
-Post audit comment:
-```
-[TICKET-LIFECYCLE] State Transition
----
-from: qa
-to: in_progress
-timestamp: {ISO 8601}
-agent: qa-agent
-reason: AC verification failed ({failed_count}/{total_count} items failed)
-retry: {retry_count + 1}/{max_retries}
-details:
-  failed_items:
-    - ac_item: "{item text}"
-      expected: "{expected behavior}"
-      observed: "{observed behavior}"
-  passed_items: [{list of passed item indices}]
----
-```
-
-Update ticket status to in_progress.
-Broadcast Bloodbank event with `new_state: "in_progress"`.
-
-**Routing back to implementation with defect details...**
-Immediately load, read entire file, then execute {retryStepFile}.
-
-**IF ANY ITEMS FAIL AND retry_count >= max_retries:**
-
-Post audit comment:
-```
-[TICKET-LIFECYCLE] State Transition
----
-from: qa
-to: blocked
-timestamp: {ISO 8601}
-agent: orchestrator
-reason: QA max retries exceeded ({max_retries}/{max_retries}). Ticket blocked.
-details:
-  still_failing: [{list of AC items still failing with defect details}]
-  failure_history: [{summary of each retry attempt}]
----
-```
-
-Update ticket status to blocked.
-Broadcast `ticket.stale` Bloodbank event with full failure history.
-
-**Ticket blocked. Exiting to completion...**
-Immediately load, read entire file, then execute {doneStepFile}.
-
----
-
-## SYSTEM SUCCESS/FAILURE METRICS
-
-### SUCCESS:
-
-- QA Agent spawned with correct AC items (all on first pass, only failed on retry)
-- Per-item verdicts collected with evidence/defect details
-- Retry count tracked and max enforced
-- Correct branch taken based on results and retry state
-- Defect payload includes specific expected vs observed details
-- Partial passes preserved across retries
-
-### FAILURE:
-
-- Verifying AC directly instead of delegating to QA Agent
-- Re-verifying already-passed items on retry
-- Not tracking retry count
-- Exceeding max retries without blocking
-- Vague defect descriptions (must include expected vs observed)
-
-**Master Rule:** Line-item verification. Track retries. Provide specific defect details on failure.

package/templates/commonproject/_bmad/custom/workflows/ticket-lifecycle/steps-c/step-07-complete.md

@@ -1,141 +0,0 @@
----
-name: 'step-07-complete'
-description: 'Broadcast completion event, post final audit comment, and exit workflow'
-
-auditCommentTemplate: '../data/audit-comment-template.md'
-eventSchemas: '../data/event-schemas.md'
----
-
-# Step 7: Completion
-
-## STEP GOAL:
-
-To broadcast the final Bloodbank event, post the closing audit comment to Plane, and exit the workflow.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- Read the complete step file before taking any action.
-- If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread.
-
-### Role Reinforcement:
-
-- You are a workflow orchestrator performing final bookkeeping.
-- This is the last step. Clean exit with full audit trail.
-
-### Step-Specific Rules:
-
-- Focus ONLY on completion bookkeeping.
-- FORBIDDEN to modify ticket state beyond what was set in the previous step.
-- Handle both "done" and "blocked" terminal states.
-
-## EXECUTION PROTOCOLS:
-
-- Post final audit comment summarizing the full lifecycle.
-- Broadcast terminal Bloodbank event.
-- Exit cleanly.
-
-## CONTEXT BOUNDARIES:
-
-- Previous step set the terminal state (done or blocked).
-- Focus: audit trail completion and event broadcasting.
-- This is the final step. No next step.
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Determine Terminal State
-
-Check the ticket's current state (set by the previous step):
-- **done**: All AC items verified, ticket complete.
-- **blocked**: Max retries exceeded, AC ambiguity, or refinement failure.
-
-### 2. Post Final Audit Summary
-
-Post a summary audit comment to Plane using {auditCommentTemplate}:
-
-**For "done" state:**
-```
-[TICKET-LIFECYCLE] Workflow Complete
----
-terminal_state: done
-timestamp: {ISO 8601}
-agent: orchestrator
-summary: Ticket processed through full lifecycle. All AC items verified.
-lifecycle:
-  started: {workflow_start_timestamp}
-  completed: {now}
-  states_visited: [{list of all states the ticket passed through}]
-  retries_used: {qa_retry_count}
-  agents_spawned: [{list: plane-captain (if used), coding-agent, qa-agent}]
----
-```
-
-**For "blocked" state:**
-```
-[TICKET-LIFECYCLE] Workflow Complete
----
-terminal_state: blocked
-timestamp: {ISO 8601}
-agent: orchestrator
-summary: Ticket blocked. Requires external intervention.
-reason: {blocked_reason from previous step}
-lifecycle:
-  started: {workflow_start_timestamp}
-  blocked_at: {now}
-  states_visited: [{list of all states}]
-  blocking_details: {details from previous step}
----
-```
-
-### 3. Broadcast Terminal Event
-
-Using {eventSchemas}, broadcast the final Bloodbank event:
-
-```json
-{
-  "event_type": "ticket.state_changed",
-  "version": "v1",
-  "payload": {
-    "project_id": "{project_id}",
-    "ticket_id": "{ticket_id}",
-    "previous_state": "{previous_state}",
-    "new_state": "{terminal_state}",
-    "trigger_source": "ticket-lifecycle-workflow",
-    "terminal": true
-  }
-}
-```
-
-### 4. Exit Workflow
-
-**Workflow complete.** No further steps.
-
-Report final status:
-- Ticket ID and title
-- Terminal state (done or blocked)
-- Total states visited
-- Agents spawned
-- Retries used (if any)
-
----
-
-## SYSTEM SUCCESS/FAILURE METRICS
-
-### SUCCESS:
-
-- Final audit summary posted with full lifecycle details
-- Terminal Bloodbank event broadcast with `terminal: true`
-- Clean exit with status report
-- Both "done" and "blocked" paths handled
-
-### FAILURE:
-
-- Exiting without posting final audit summary
-- Not broadcasting terminal event
-- Attempting further state transitions after completion
-- Missing lifecycle details in summary
-
-**Master Rule:** Clean exit. Full audit trail. No loose ends.

package/templates/commonproject/_bmad/custom/workflows/ticket-lifecycle/steps-e/step-01-assess.md

@@ -1,102 +0,0 @@
----
-name: 'step-e-01-assess'
-description: 'Assess current workflow configuration and present modification options'
-
-nextStepFile: './step-02-apply.md'
-workflowConfig: '../workflow.yaml'
-acRubric: '../data/ac-sufficiency-rubric.md'
-auditCommentTemplate: '../data/audit-comment-template.md'
-eventSchemas: '../data/event-schemas.md'
----
-
-# Step E1: Assess Workflow Configuration
-
-## STEP GOAL:
-
-To load and present the current workflow configuration, identify what can be modified, and gather the user's requested changes.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- Read the complete step file before taking any action.
-- YOU ARE A FACILITATOR. Present current state, gather requested changes.
-
-### Role Reinforcement:
-
-- You are a workflow configuration editor.
-- Present current values clearly. Let the user decide what to change.
-
-### Step-Specific Rules:
-
-- Focus ONLY on assessment and change gathering.
-- FORBIDDEN to apply changes in this step. That is step E2.
-- Present all configurable values from workflow.yaml and data files.
-
-## MANDATORY SEQUENCE
-
-### 1. Load Current Configuration
-
-Read {workflowConfig} and present all configurable values:
-
-**AC Sufficiency Rubric:**
-- Load {acRubric} and summarize criteria
-
-**QA Configuration:**
-- Max retries: {value from config}
-
-**Staleness Durations (minutes):**
-- Triage: {value}
-- Refining: {value}
-- In Progress: {value}
-- Review: {value}
-- QA: {value}
-
-**Plane State Mapping:**
-- Present current state name mappings
-
-**Event Configuration:**
-- Load {eventSchemas} and summarize event types
-
-### 2. Present Modification Options
-
-"**Current workflow configuration loaded. What would you like to modify?**
-
-Configurable areas:
-1. **AC Rubric** - Add/remove/modify sufficiency criteria
-2. **QA Retry Limit** - Change max retry count
-3. **Staleness Durations** - Adjust per-state timeout thresholds
-4. **State Mapping** - Change Plane status names
-5. **Event Schemas** - Modify Bloodbank event payloads
-6. **Audit Comment Format** - Change comment template structure
-
-Tell me which area(s) you want to modify and what changes you need."
-
-### 3. Gather Changes
-
-Collect the user's requested modifications. For each change:
-- Current value
-- Requested new value
-- Confirm understanding
-
-### 4. Present MENU OPTIONS
-
-Display: **Select an Option:** [C] Continue to Apply Changes
-
-#### Menu Handling Logic:
-- IF C: Save gathered changes, then load, read entire file, then execute {nextStepFile}
-- IF Any other: help user, then redisplay menu
-
----
-
-## SYSTEM SUCCESS/FAILURE METRICS
-
-### SUCCESS:
-- All configurable values presented clearly
-- User changes gathered with current vs new values
-- Changes confirmed before proceeding to apply
-
-### FAILURE:
-- Applying changes in this step
-- Not presenting current values before gathering changes
-- Proceeding without user confirmation

package/templates/commonproject/_bmad/custom/workflows/ticket-lifecycle/steps-e/step-02-apply.md

@@ -1,85 +0,0 @@
----
-name: 'step-e-02-apply'
-description: 'Apply requested configuration changes to workflow files'
-
-workflowConfig: '../workflow.yaml'
-acRubric: '../data/ac-sufficiency-rubric.md'
-auditCommentTemplate: '../data/audit-comment-template.md'
-eventSchemas: '../data/event-schemas.md'
----
-
-# Step E2: Apply Configuration Changes
-
-## STEP GOAL:
-
-To apply the gathered configuration changes to the appropriate workflow files.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- Read the complete step file before taking any action.
-- Apply changes precisely as confirmed in step E1.
-
-### Role Reinforcement:
-
-- You are applying confirmed changes. No improvisation.
-- Edit only the files that need modification.
-
-### Step-Specific Rules:
-
-- Focus ONLY on applying confirmed changes.
-- FORBIDDEN to make changes not confirmed in step E1.
-- After applying, verify each change was applied correctly.
-
-## MANDATORY SEQUENCE
-
-### 1. Apply Changes by Target File
-
-For each confirmed change from step E1:
-
-**If modifying workflow.yaml:**
-- Read {workflowConfig}
-- Apply the specific value change
-- Write updated file
-
-**If modifying AC rubric:**
-- Read {acRubric}
-- Apply criteria changes
-- Write updated file
-
-**If modifying audit comment template:**
-- Read {auditCommentTemplate}
-- Apply format changes
-- Write updated file
-
-**If modifying event schemas:**
-- Read {eventSchemas}
-- Apply schema changes
-- Write updated file
-
-### 2. Verify Changes
-
-For each modified file, re-read and confirm the change was applied correctly.
-
-### 3. Summary
-
-Present a summary of all changes applied:
-- File modified
-- What changed (before -> after)
-
-"**All changes applied. Workflow configuration updated.**"
-
----
-
-## SYSTEM SUCCESS/FAILURE METRICS
-
-### SUCCESS:
-- All confirmed changes applied to correct files
-- Each change verified after application
-- Summary presented with before/after values
-
-### FAILURE:
-- Applying unconfirmed changes
-- Modifying wrong files
-- Not verifying changes after application