@delorenj/pjangler 1.1.3

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

@@ -0,0 +1,173 @@
+---
+name: 'step-01-init'
+description: 'Resolve project context, validate preconditions, and acquire ticket'
+
+nextStepFile: './step-02-triage.md'
+workflowConfig: '../workflow.yaml'
+planeSkill: '~/.claude/skills/managing-tickets-and-tasks-in-plane/'
+---
+
+# Step 1: Initialize and Acquire Ticket
+
+## STEP GOAL:
+
+To resolve the project's Plane workspace context, validate all preconditions for autonomous execution, and acquire a ticket to process.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- **NEVER** proceed if preconditions fail. Exit with a clear error message.
+- Read the complete step file before taking any action.
+- When loading next step, ensure entire file is read.
+- 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. You read state, evaluate conditions, and route execution.
+- You do not write code. You do not interact with humans.
+- You bring systematic precondition validation and context resolution.
+
+### Step-Specific Rules:
+
+- Focus ONLY on context resolution and ticket acquisition.
+- FORBIDDEN to evaluate AC or spawn agents in this step.
+- Exit immediately with a clear error if any precondition fails.
+
+## EXECUTION PROTOCOLS:
+
+- Resolve project context from the `ticket_provider` block in `.project.json` + workspace config.
+- Load Plane skill for API patterns.
+- Load workflow config for state mapping and staleness durations.
+- Acquire ticket (by ID if provided, or via scoring algorithm).
+
+## CONTEXT BOUNDARIES:
+
+- This is step 1. No prior context exists.
+- Focus: project identification, workspace resolution, ticket selection.
+- Dependencies: `.project.json` must exist and contain a `ticket_provider` block with a non-empty `board_id`, Plane API must be accessible.
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Resolve Project Context
+
+Search for `.project.json` in the current project root.
+
+**If found:**
+- Read and parse `.project.json` and extract the `ticket_provider` block, reading `ticket_provider.workspace` and `ticket_provider.board_id`.
+- Load `~/.claude/plane-workspaces.json` to resolve API endpoint and credentials for this workspace.
+
+**If NOT found (or no `ticket_provider` block / empty `board_id`):**
+- EXIT with error: "PRECONDITION FAILED: No .project.json with a ticket_provider block found in project root. This workflow requires a Plane-integrated project. Ensure .project.json contains a ticket_provider block with workspace and a non-empty board_id."
+
+### 2. Validate Workspace Registration
+
+Using `ticket_provider.workspace` from `.project.json`, verify it exists in `~/.claude/plane-workspaces.json`.
+
+**If registered:**
+- Extract API base URL, API key reference, and workspace ID.
+- Confirm API connectivity with a lightweight health check (list projects).
+
+**If NOT registered:**
+- EXIT with error: "PRECONDITION FAILED: Workspace '{workspace_slug}' not found in ~/.claude/plane-workspaces.json. Register the workspace first."
+
+### 3. Validate External Dependencies
+
+Verify availability of:
+
+1. **Bloodbank CLI:** Check that `~/code/33GOD/bloodbank/` exists and the publish script is accessible.
+2. **Holyfields schemas:** Check that `~/code/33GOD/holyfields/schemas/agent/` contains expected event schema files.
+
+**If any dependency is missing:**
+- EXIT with error listing which dependencies are unavailable and how to resolve them.
+
+### 4. Load Workflow Configuration
+
+Read {workflowConfig} to load:
+- AC sufficiency rubric criteria
+- QA retry limits
+- Staleness durations per state
+- Plane state name mapping
+
+Store these values for use in subsequent steps.
+
+### 5. Acquire Ticket
+
+**If a ticket ID was provided as input:**
+- Fetch the ticket from Plane API using the project context.
+- Verify the ticket exists and is in a processable state (backlog or ready).
+
+**If NO ticket ID was provided:**
+- Load {planeSkill} to access the ticket scoring algorithm.
+- Query the Plane board for tickets in backlog or ready state.
+- Score and select the highest-priority ticket.
+- If no eligible tickets exist, EXIT with message: "No eligible tickets found in backlog or ready state."
+
+### 6. Capture Ticket Context
+
+Extract from the selected ticket:
+- Ticket ID, title, description
+- Current state/status
+- Acceptance criteria field (raw, for evaluation in next step)
+- Any linked functional requirements or labels
+- Assignee and priority metadata
+
+### 7. Transition to Triage
+
+Post an audit comment to the Plane ticket:
+```
+[TICKET-LIFECYCLE] State Transition
+---
+from: {current_state}
+to: triage
+timestamp: {ISO 8601}
+agent: orchestrator
+reason: Ticket acquired for lifecycle processing
+---
+```
+
+Update the ticket status to the triage state (per {workflowConfig} state mapping).
+
+Broadcast Bloodbank event:
+```json
+{
+  "event_type": "ticket.state_changed",
+  "version": "v1",
+  "payload": {
+    "project_id": "{project_id}",
+    "ticket_id": "{ticket_id}",
+    "previous_state": "{current_state}",
+    "new_state": "triage",
+    "trigger_source": "ticket-lifecycle-workflow"
+  }
+}
+```
+
+**Proceeding to triage...**
+
+Immediately load, read entire file, then execute {nextStepFile}.
+
+---
+
+## SYSTEM SUCCESS/FAILURE METRICS
+
+### SUCCESS:
+
+- Project context resolved from the `ticket_provider` block in `.project.json` + workspace config
+- All preconditions validated (Plane API, Bloodbank, Holyfields)
+- Ticket acquired (by ID or scoring algorithm)
+- Ticket context captured (ID, title, AC, status, metadata)
+- Ticket transitioned to triage state with audit comment
+- Bloodbank event broadcast
+
+### FAILURE:
+
+- Proceeding without validating preconditions
+- Silently failing on missing `.project.json` / `ticket_provider` block or workspace
+- Not posting audit comment at state transition
+- Not broadcasting Bloodbank event
+- Attempting to evaluate AC in this step (that's step 2)
+
+**Master Rule:** Exit immediately on precondition failure. Never proceed with incomplete context.

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

@@ -0,0 +1,159 @@
+---
+name: 'step-02-triage'
+description: 'Evaluate ticket AC against sufficiency rubric and branch accordingly'
+
+nextStepFile: './step-04-implement.md'
+refineStepFile: './step-03-refine.md'
+acRubric: '../data/ac-sufficiency-rubric.md'
+auditCommentTemplate: '../data/audit-comment-template.md'
+---
+
+# Step 2: Triage - AC Sufficiency Evaluation
+
+## STEP GOAL:
+
+To evaluate the ticket's acceptance criteria against the sufficiency rubric and branch to either AC refinement (step 3) or implementation (step 4).
+
+## 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 evaluating AC quality against a deterministic rubric.
+- You do not subjectively judge AC quality. You apply the 4 binary criteria.
+- The rubric is the authority, not your opinion.
+
+### Step-Specific Rules:
+
+- Focus ONLY on AC evaluation against the rubric.
+- FORBIDDEN to spawn agents or begin implementation in this step.
+- FORBIDDEN to modify AC. If insufficient, route to Plane Captain (step 3).
+- Apply all 4 rubric criteria. Do not short-circuit on the first failure.
+
+## EXECUTION PROTOCOLS:
+
+- Load the AC sufficiency rubric from {acRubric}.
+- Evaluate each criterion independently.
+- Document which criteria passed/failed.
+- Branch based on result.
+
+## CONTEXT BOUNDARIES:
+
+- Step 1 provided: ticket ID, title, description, AC field, metadata, project context.
+- Focus: AC quality evaluation only.
+- Dependencies: ticket context from step 1.
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Load AC Sufficiency Rubric
+
+Read {acRubric} to load the 4 evaluation criteria:
+1. Non-empty
+2. Testable assertions
+3. Enumerated items
+4. Functional requirement coverage
+
+### 2. Extract Acceptance Criteria
+
+From the ticket context acquired in step 1, extract the raw AC field content.
+
+### 3. Evaluate Each Criterion
+
+Apply each of the 4 rubric criteria to the AC content. For each criterion, record:
+- Criterion name
+- Pass/Fail
+- Evidence (what was found or missing)
+
+**Evaluate ALL 4 criteria even if early ones fail.** The complete evaluation is needed for the Plane Captain if refinement is required.
+
+### 4. Determine Sufficiency
+
+```
+SUFFICIENT = non_empty AND testable AND enumerated AND fr_coverage
+```
+
+### 5. Branch Based on Result
+
+**IF SUFFICIENT (all 4 criteria pass):**
+
+Post audit comment to Plane using {auditCommentTemplate}:
+```
+[TICKET-LIFECYCLE] State Transition
+---
+from: triage
+to: ready
+timestamp: {ISO 8601}
+agent: orchestrator
+reason: AC passed sufficiency rubric (4/4 criteria met)
+---
+```
+
+Update ticket status to ready state.
+
+Broadcast Bloodbank event:
+```json
+{
+  "event_type": "ticket.state_changed",
+  "payload": {
+    "project_id": "{project_id}",
+    "ticket_id": "{ticket_id}",
+    "previous_state": "triage",
+    "new_state": "ready"
+  }
+}
+```
+
+**Proceeding to implementation...**
+Immediately load, read entire file, then execute {nextStepFile}.
+
+**IF INSUFFICIENT (any criterion fails):**
+
+Post audit comment to Plane:
+```
+[TICKET-LIFECYCLE] State Transition
+---
+from: triage
+to: refining
+timestamp: {ISO 8601}
+agent: orchestrator
+reason: AC failed sufficiency rubric ({N}/4 criteria met)
+details:
+  failed_criteria: [{list of failed criterion names}]
+  evidence: [{evidence for each failure}]
+---
+```
+
+Update ticket status to refining state.
+
+Broadcast Bloodbank event with `new_state: "refining"`.
+
+**Proceeding to AC refinement...**
+Immediately load, read entire file, then execute {refineStepFile}.
+
+---
+
+## SYSTEM SUCCESS/FAILURE METRICS
+
+### SUCCESS:
+
+- All 4 rubric criteria evaluated independently
+- Complete evidence recorded for each criterion
+- Correct branch taken based on evaluation result
+- Audit comment posted with full evaluation details
+- Bloodbank event broadcast
+
+### FAILURE:
+
+- Short-circuiting evaluation on first failure
+- Subjectively judging AC instead of applying rubric
+- Not recording evidence for each criterion
+- Modifying AC content in this step
+- Not posting audit comment before branching
+
+**Master Rule:** The rubric is deterministic. Apply all 4 criteria, record evidence, branch accordingly.

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

@@ -0,0 +1,149 @@
+---
+name: 'step-03-refine'
+description: 'Spawn Plane Captain sub-agent to define or improve acceptance criteria'
+
+nextStepFile: './step-04-implement.md'
+acRubric: '../data/ac-sufficiency-rubric.md'
+auditCommentTemplate: '../data/audit-comment-template.md'
+planeSkill: '~/.claude/skills/managing-tickets-and-tasks-in-plane/'
+---
+
+# Step 3: AC Refinement via Plane Captain
+
+## STEP GOAL:
+
+To spawn a Plane Captain sub-agent that will define or improve the ticket's acceptance criteria until they pass the sufficiency rubric, then transition the ticket to ready state.
+
+## 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 AC refinement to a specialized agent.
+- You provide the Plane Captain with context and rubric failures. You do not refine AC yourself.
+- The Plane Captain is a BMAD agent (Claude Code session-scoped), spawned on-demand.
+
+### Step-Specific Rules:
+
+- Focus ONLY on delegating AC refinement and verifying the result.
+- FORBIDDEN to write AC yourself. Delegate to Plane Captain.
+- FORBIDDEN to begin implementation. That is step 4.
+- After refinement, re-evaluate AC against rubric before proceeding.
+
+## EXECUTION PROTOCOLS:
+
+- Spawn Plane Captain sub-agent with ticket context and failed criteria.
+- Plane Captain reads ticket, collaborates with PM context, writes AC back to Plane.
+- Re-evaluate refined AC against rubric.
+- If still insufficient after refinement, mark ticket as blocked.
+
+## CONTEXT BOUNDARIES:
+
+- Step 2 provided: rubric evaluation results, failed criteria with evidence.
+- Focus: AC refinement delegation and verification.
+- Dependencies: ticket context, rubric failures from step 2.
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Prepare Plane Captain Context
+
+Assemble the delegation payload for the Plane Captain sub-agent:
+- Ticket ID, title, description
+- Current AC content (raw)
+- Failed rubric criteria with evidence from step 2
+- The full rubric from {acRubric} so the Plane Captain knows the target
+- Plane API access patterns from {planeSkill}
+
+### 2. Spawn Plane Captain Sub-Agent
+
+Launch a sub-agent with the role of **Plane Captain**:
+
+**Agent Instructions:**
+"You are a Plane Captain responsible for defining clear, testable acceptance criteria for ticket {ticket_id}.
+
+Review the ticket description and context. The current AC failed these rubric criteria: {failed_criteria_with_evidence}.
+
+Write new acceptance criteria that satisfy ALL 4 rubric criteria:
+1. Non-empty
+2. Each item is a testable assertion
+3. Items are enumerated (numbered list)
+4. At least one item per functional requirement
+
+Update the ticket's AC field in Plane via the API. Return the updated AC content when complete."
+
+### 3. Receive Refined AC
+
+When the Plane Captain sub-agent completes:
+- Read the updated AC from Plane (re-fetch ticket to get latest).
+- Do NOT trust the sub-agent's return value alone. Verify against Plane.
+
+### 4. Re-Evaluate Against Rubric
+
+Apply the same 4-criteria rubric from {acRubric} to the refined AC.
+
+**IF SUFFICIENT (all 4 criteria pass):**
+
+Post audit comment using {auditCommentTemplate}:
+```
+[TICKET-LIFECYCLE] State Transition
+---
+from: refining
+to: ready
+timestamp: {ISO 8601}
+agent: plane-captain
+reason: AC refined and passed sufficiency rubric (4/4 criteria met)
+---
+```
+
+Update ticket status to ready state.
+Broadcast Bloodbank event with `new_state: "ready"`.
+
+**Proceeding to implementation...**
+Immediately load, read entire file, then execute {nextStepFile}.
+
+**IF STILL INSUFFICIENT:**
+
+Post audit comment:
+```
+[TICKET-LIFECYCLE] State Transition
+---
+from: refining
+to: blocked
+timestamp: {ISO 8601}
+agent: orchestrator
+reason: AC refinement failed. Plane Captain could not produce sufficient AC.
+details:
+  still_failing: [{list of criteria still failing}]
+---
+```
+
+Update ticket status to blocked state.
+Broadcast `ticket.stale` Bloodbank event.
+EXIT workflow. This ticket needs human intervention.
+
+---
+
+## SYSTEM SUCCESS/FAILURE METRICS
+
+### SUCCESS:
+
+- Plane Captain spawned with complete context and rubric
+- AC refined and re-verified against rubric
+- Ticket transitioned to ready (or blocked if refinement failed)
+- Audit comment posted with transition details
+- Bloodbank event broadcast
+
+### FAILURE:
+
+- Writing AC directly instead of delegating to Plane Captain
+- Not re-evaluating refined AC against rubric
+- Trusting sub-agent return without verifying Plane state
+- Proceeding to implementation without rubric passing
+
+**Master Rule:** Delegate, verify, then proceed. Never skip verification.

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

@@ -0,0 +1,147 @@
+---
+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.