@delorenj/pjangler 1.2.21 → 1.2.33

package/templates/commonproject/_bmad/_config/custom/custom/workflows/ticket-lifecycle/data/event-schemas.md

@@ -1,58 +0,0 @@
-# Bloodbank Event Schemas
-
-Reference for events broadcast during ticket lifecycle execution.
-Source schemas: ~/code/33GOD/holyfields/schemas/agent/
-
-## ticket.state_changed
-
-Broadcast at every state transition. Primary event for this workflow.
-
-```json
-{
-  "event_type": "ticket.state_changed",
-  "version": "v1",
-  "payload": {
-    "project_id": "{from ticket_provider.board_id in .project.json}",
-    "ticket_id": "{plane ticket ID}",
-    "previous_state": "{state before transition}",
-    "new_state": "{state after transition}",
-    "trigger_source": "ticket-lifecycle-workflow",
-    "timestamp": "{ISO 8601}"
-  }
-}
-```
-
-## ticket.stale
-
-Broadcast when a ticket exceeds max duration in any state.
-
-```json
-{
-  "event_type": "ticket.stale",
-  "version": "v1",
-  "payload": {
-    "project_id": "{from ticket_provider.board_id in .project.json}",
-    "ticket_id": "{plane ticket ID}",
-    "stuck_state": "{state ticket is stuck in}",
-    "duration_minutes": "{how long it has been in this state}",
-    "max_duration_minutes": "{configured max from workflow.yaml}",
-    "timestamp": "{ISO 8601}"
-  }
-}
-```
-
-## Existing Holyfields Schemas Used
-
-These are published via Bloodbank CLI at ~/code/33GOD/bloodbank/
-
-- `agent.task.assigned` - When sub-agent receives work
-- `agent.task.completed` - When sub-agent finishes work
-- `agent.message.sent` - For audit trail notifications
-
-## Publishing
-
-```bash
-# Example: publish state change event
-cd ~/code/33GOD/bloodbank
-./publish.sh ticket.state_changed '{payload_json}'
-```

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

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

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

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

@@ -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.