@delorenj/pjangler 1.2.25 → 1.2.33

package/templates/commonproject/_bmad/_config/custom/custom/workflows/ticket-lifecycle/steps-c/step-04-implement.md

@@ -1,147 +0,0 @@
----
-name: 'step-04-implement'
-description: 'Spawn Coding Agent sub-agent to implement ticket requirements and write tests'
-
-nextStepFile: './step-05-review.md'
-blockedStepFile: './step-07-complete.md'
-auditCommentTemplate: '../data/audit-comment-template.md'
----
-
-# Step 4: Implementation via Coding Agent
-
-## STEP GOAL:
-
-To spawn a Coding Agent sub-agent that implements the ticket requirements and writes tests covering each acceptance criteria item.
-
-## 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 implementation to a specialized agent.
-- You provide the Coding Agent with AC items as goals. You do not write code.
-- The Coding Agent is a BMAD agent (Claude Code session-scoped), spawned on-demand.
-
-### Step-Specific Rules:
-
-- Focus ONLY on delegating implementation and handling the result.
-- FORBIDDEN to write code yourself. Delegate to Coding Agent.
-- FORBIDDEN to verify AC. That is QA's job (step 6).
-- If the Coding Agent reports AC ambiguity, route to blocked state.
-
-## EXECUTION PROTOCOLS:
-
-- Spawn Coding Agent with AC items as implementation goals.
-- Coding Agent writes code + tests, commits to repo.
-- On completion, transition to review gate.
-- On AC ambiguity discovery, transition to blocked.
-
-## CONTEXT BOUNDARIES:
-
-- Previous steps provided: ticket context, verified AC items, project context.
-- Focus: implementation delegation.
-- Dependencies: sufficient AC from step 2/3.
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Prepare Coding Agent Context
-
-Assemble the delegation payload:
-- Ticket ID, title, description
-- Enumerated AC items (each item is an implementation goal)
-- Project context (repo path, tech stack if available from project-context.md)
-- Any defect details from prior QA failures (if this is a retry loop)
-
-### 2. Update Ticket Status
-
-Post audit comment using {auditCommentTemplate}:
-```
-[TICKET-LIFECYCLE] State Transition
----
-from: ready
-to: in_progress
-timestamp: {ISO 8601}
-agent: orchestrator
-reason: Implementation starting. Coding agent spawned.
----
-```
-
-Update ticket status to in_progress.
-Broadcast Bloodbank event with `new_state: "in_progress"`.
-
-### 3. Spawn Coding Agent Sub-Agent
-
-Launch a sub-agent with the role of **Coding Agent**:
-
-**Agent Instructions:**
-"You are a Coding Agent implementing ticket {ticket_id}: {ticket_title}.
-
-Your implementation goals are the acceptance criteria items:
-{enumerated_ac_items}
-
-{if_retry: 'IMPORTANT: This is retry #{retry_count}. Previous QA found these defects: {defect_details}. Focus on fixing ONLY the failed AC items.'}
-
-Requirements:
-1. Implement code changes that satisfy each AC item
-2. Write unit tests that verify each AC item (1:1 mapping)
-3. Ensure all existing tests still pass (no regressions)
-4. Commit changes to the repository
-
-If you discover that any AC item is ambiguous or contradictory, STOP and report the ambiguity. Do not guess.
-
-Return: summary of changes, test results, and any AC ambiguity discovered."
-
-### 4. Handle Coding Agent Result
-
-**IF implementation completed successfully:**
-
-**Proceeding to review gate...**
-Immediately load, read entire file, then execute {nextStepFile}.
-
-**IF AC ambiguity discovered:**
-
-Post audit comment:
-```
-[TICKET-LIFECYCLE] State Transition
----
-from: in_progress
-to: blocked
-timestamp: {ISO 8601}
-agent: coding-agent
-reason: AC ambiguity discovered during implementation
-details:
-  ambiguous_items: [{list of ambiguous AC items with explanation}]
----
-```
-
-Update ticket status to blocked.
-Broadcast `ticket.stale` Bloodbank event.
-Load {blockedStepFile} to complete with blocked status.
-
----
-
-## SYSTEM SUCCESS/FAILURE METRICS
-
-### SUCCESS:
-
-- Coding Agent spawned with AC items as goals
-- Implementation delegated, not performed directly
-- On success, transitioned to review gate
-- On AC ambiguity, transitioned to blocked with details
-- Audit comments posted at each transition
-- Bloodbank events broadcast
-
-### FAILURE:
-
-- Writing code directly instead of delegating
-- Not passing defect details on retry loops
-- Ignoring AC ambiguity reports from Coding Agent
-- Not posting audit comment before transition
-
-**Master Rule:** Delegate implementation. Handle both success and ambiguity paths.

package/templates/commonproject/_bmad/_config/custom/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/_config/custom/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/_config/custom/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.