@cregis-dev/cckit 0.4.0 → 0.5.0

package/templates/bmad/tea/workflows/testarch/test-design/steps-c/step-05-generate-output.md

@@ -1,222 +0,0 @@
----
-name: 'step-05-generate-output'
-description: 'Generate output documents with adaptive orchestration (agent-team, subagent, or sequential)'
-outputFile: '{test_artifacts}/test-design-epic-{epic_num}.md'
-progressFile: '{test_artifacts}/test-design-progress.md'
----
-
-# Step 5: Generate Outputs & Validate
-
-## STEP GOAL
-
-Write the final test-design document(s) using the correct template(s), then validate against the checklist.
-
-## MANDATORY EXECUTION RULES
-
-- 📖 Read the entire step file before acting
-- ✅ Speak in `{communication_language}`
-- ✅ Use the provided templates and output paths
-- ✅ Resolve execution mode from explicit user request first, then config
-- ✅ Apply fallback rules deterministically when requested mode is unsupported
-
----
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-- 💾 Record outputs before proceeding
-- 📖 Load the next step only when instructed
-
-## CONTEXT BOUNDARIES:
-
-- Available context: config, loaded artifacts, and knowledge fragments
-- Focus: this step's goal only
-- Limits: do not execute future steps
-- Dependencies: prior steps' outputs (if any)
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-## 0. Resolve Execution Mode (User Override First)
-
-```javascript
-const orchestrationContext = {
-  config: {
-    execution_mode: config.tea_execution_mode || 'auto', // "auto" | "subagent" | "agent-team" | "sequential"
-    capability_probe: config.tea_capability_probe !== false, // true by default
-  },
-  timestamp: new Date().toISOString().replace(/[:.]/g, '-'),
-};
-
-const normalizeUserExecutionMode = (mode) => {
-  if (typeof mode !== 'string') return null;
-  const normalized = mode.trim().toLowerCase().replace(/[-_]/g, ' ').replace(/\s+/g, ' ');
-
-  if (normalized === 'auto') return 'auto';
-  if (normalized === 'sequential') return 'sequential';
-  if (normalized === 'subagent' || normalized === 'sub agent' || normalized === 'subagents' || normalized === 'sub agents') {
-    return 'subagent';
-  }
-  if (normalized === 'agent team' || normalized === 'agent teams' || normalized === 'agentteam') {
-    return 'agent-team';
-  }
-
-  return null;
-};
-
-const normalizeConfigExecutionMode = (mode) => {
-  if (mode === 'subagent') return 'subagent';
-  if (mode === 'auto' || mode === 'sequential' || mode === 'subagent' || mode === 'agent-team') {
-    return mode;
-  }
-  return null;
-};
-
-// Explicit user instruction in the active run takes priority over config.
-const explicitModeFromUser = normalizeUserExecutionMode(runtime.getExplicitExecutionModeHint?.() || null);
-
-const requestedMode = explicitModeFromUser || normalizeConfigExecutionMode(orchestrationContext.config.execution_mode) || 'auto';
-const probeEnabled = orchestrationContext.config.capability_probe;
-
-const supports = { subagent: false, agentTeam: false };
-if (probeEnabled) {
-  supports.subagent = runtime.canLaunchSubagents?.() === true;
-  supports.agentTeam = runtime.canLaunchAgentTeams?.() === true;
-}
-
-let resolvedMode = requestedMode;
-if (requestedMode === 'auto') {
-  if (supports.agentTeam) resolvedMode = 'agent-team';
-  else if (supports.subagent) resolvedMode = 'subagent';
-  else resolvedMode = 'sequential';
-} else if (probeEnabled && requestedMode === 'agent-team' && !supports.agentTeam) {
-  resolvedMode = supports.subagent ? 'subagent' : 'sequential';
-} else if (probeEnabled && requestedMode === 'subagent' && !supports.subagent) {
-  resolvedMode = 'sequential';
-}
-```
-
-Resolution precedence:
-
-1. Explicit user request in this run (`agent team` => `agent-team`; `subagent` => `subagent`; `sequential`; `auto`)
-2. `tea_execution_mode` from config
-3. Runtime capability fallback (when probing enabled)
-
-## 1. Select Output Template(s)
-
-### System-Level Mode (Phase 3)
-
-Generate **two** documents:
-
-- `{test_artifacts}/test-design-architecture.md` using `test-design-architecture-template.md`
-- `{test_artifacts}/test-design-qa.md` using `test-design-qa-template.md`
-
-If `resolvedMode` is `agent-team` or `subagent`, these two documents can be generated in parallel as independent workers, then reconciled for consistency.
-
-### Epic-Level Mode (Phase 4)
-
-Generate **one** document:
-
-- `{outputFile}` using `test-design-template.md`
-- If `epic_num` is unclear, ask the user
-
-Epic-level mode remains single-worker by default (one output artifact).
-
----
-
-## 2. Populate Templates
-
-Ensure the outputs include:
-
-- Risk assessment matrix
-- Coverage matrix and priorities
-- Execution strategy
-- Resource estimates (ranges)
-- Quality gate criteria
-- Any mode-specific sections required by the template
-
----
-
-## 3. Validation
-
-Validate the output(s) against:
-
-- `checklist.md` in this workflow folder
-- [ ] CLI sessions cleaned up (no orphaned browsers)
-- [ ] Temp artifacts stored in `{test_artifacts}/` not random locations
-
-If any checklist criteria are missing, fix before completion.
-
----
-
-## 4. Generate BMAD Handoff Document (System-Level Mode Only)
-
-**If this is a system-level test design** (not component/feature level):
-
-1. Copy `test-design-handoff-template.md` to `{test_artifacts}/test-design/{project_name}-handoff.md`
-2. Populate all sections from the test design output:
-   - Fill TEA Artifacts Inventory with actual paths
-   - Extract P0/P1 risks into Epic-Level guidance
-   - Map critical test scenarios to Story-Level guidance
-   - Build risk-to-story mapping table from risk register
-3. Save alongside the test design document
-
-> **Note**: The handoff document is designed for consumption by BMAD's `create-epics-and-stories` workflow. It is only generated for system-level test designs where epic/story decomposition is relevant.
-
----
-
-## 5. Polish Output
-
-Before finalizing, review the complete output document for quality:
-
-1. **Remove duplication**: Progressive-append workflow may have created repeated sections — consolidate
-2. **Verify consistency**: Ensure terminology, risk scores, and references are consistent throughout
-3. **Check completeness**: All template sections should be populated or explicitly marked N/A
-4. **Format cleanup**: Ensure markdown formatting is clean (tables aligned, headers consistent, no orphaned references)
-
----
-
-## 6. Completion Report
-
-Summarize:
-
-- Mode used
-- Output file paths
-- Key risks and gate thresholds
-- Any open assumptions
-
----
-
-### 7. Save Progress
-
-**Save this step's accumulated work to `{progressFile}`.**
-
-- **If `{progressFile}` does not exist** (first save), create it with YAML frontmatter:
-
-  ```yaml
-  ---
-  stepsCompleted: ['step-05-generate-output']
-  lastStep: 'step-05-generate-output'
-  lastSaved: '{date}'
-  ---
-  ```
-
-  Then write this step's output below the frontmatter.
-
-- **If `{progressFile}` already exists**, update:
-  - Add `'step-05-generate-output'` to `stepsCompleted` array (only if not already present)
-  - Set `lastStep: 'step-05-generate-output'`
-  - Set `lastSaved: '{date}'`
-  - Append this step's output to the appropriate section of the document.
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
-
-### ✅ SUCCESS:
-
-- Step completed in full with required outputs
-
-### ❌ SYSTEM FAILURE:
-
-- Skipped sequence steps or missing outputs
-  **Master Rule:** Skipping steps is FORBIDDEN.

package/templates/bmad/tea/workflows/testarch/test-design/steps-e/step-01-assess.md

@@ -1,65 +0,0 @@
----
-name: 'step-01-assess'
-description: 'Load an existing output for editing'
-nextStepFile: './step-02-apply-edit.md'
----
-
-# Step 1: Assess Edit Target
-
-## STEP GOAL:
-
-Identify which output should be edited and load it.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 📖 Read the complete step file before taking any action
-- ✅ Speak in `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are the Master Test Architect
-
-### Step-Specific Rules:
-
-- 🎯 Ask the user which output file to edit
-- 🚫 Do not edit until target is confirmed
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-
-## CONTEXT BOUNDARIES:
-
-- Available context: existing outputs
-- Focus: select edit target
-- Limits: no edits yet
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly.
-
-### 1. Identify Target
-
-Ask the user to provide the output file path or select from known outputs.
-
-### 2. Load Target
-
-Read the provided output file in full.
-
-### 3. Confirm
-
-Confirm the target and proceed to edit.
-
-Load next step: `{nextStepFile}`
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
-
-### ✅ SUCCESS:
-
-- Target identified and loaded
-
-### ❌ SYSTEM FAILURE:
-
-- Proceeding without a confirmed target

package/templates/bmad/tea/workflows/testarch/test-design/steps-e/step-02-apply-edit.md

@@ -1,60 +0,0 @@
----
-name: 'step-02-apply-edit'
-description: 'Apply edits to the selected output'
----
-
-# Step 2: Apply Edits
-
-## STEP GOAL:
-
-Apply the requested edits to the selected output and confirm changes.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 📖 Read the complete step file before taking any action
-- ✅ Speak in `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are the Master Test Architect
-
-### Step-Specific Rules:
-
-- 🎯 Only apply edits explicitly requested by the user
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-
-## CONTEXT BOUNDARIES:
-
-- Available context: selected output and user changes
-- Focus: apply edits only
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly.
-
-### 1. Confirm Requested Changes
-
-Restate what will be changed and confirm.
-
-### 2. Apply Changes
-
-Update the output file accordingly.
-
-### 3. Report
-
-Summarize the edits applied.
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
-
-### ✅ SUCCESS:
-
-- Changes applied and confirmed
-
-### ❌ SYSTEM FAILURE:
-
-- Unconfirmed edits or missing update

package/templates/bmad/tea/workflows/testarch/test-design/steps-v/step-01-validate.md

@@ -1,67 +0,0 @@
----
-name: 'step-01-validate'
-description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/test-design-validation-report.md'
-validationChecklist: '../checklist.md'
----
-
-# Step 1: Validate Outputs
-
-## STEP GOAL:
-
-Validate outputs using the workflow checklist and record findings.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 📖 Read the complete step file before taking any action
-- ✅ Speak in `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are the Master Test Architect
-
-### Step-Specific Rules:
-
-- 🎯 Validate against `{validationChecklist}`
-- 🚫 Do not skip checks
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-- 💾 Write findings to `{outputFile}`
-
-## CONTEXT BOUNDARIES:
-
-- Available context: workflow outputs and checklist
-- Focus: validation only
-- Limits: do not modify outputs in this step
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly.
-
-### 1. Load Checklist
-
-Read `{validationChecklist}` and list all criteria.
-
-### 2. Validate Outputs
-
-Evaluate outputs against each checklist item.
-
-### 3. Write Report
-
-Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
-
-### ✅ SUCCESS:
-
-- Validation report written
-- All checklist items evaluated
-
-### ❌ SYSTEM FAILURE:
-
-- Skipped checklist items
-- No report produced

package/templates/bmad/tea/workflows/testarch/test-design/test-design-architecture-template.md

@@ -1,230 +0,0 @@
----
-stepsCompleted: []
-lastStep: ''
-lastSaved: ''
-workflowType: 'testarch-test-design'
-inputDocuments: []
----
-
-# Test Design for Architecture: {Feature Name}
-
-**Purpose:** Architectural concerns, testability gaps, and NFR requirements for review by Architecture/Dev teams. Serves as a contract between QA and Engineering on what must be addressed before test development begins.
-
-**Date:** {date}
-**Author:** {author}
-**Status:** Architecture Review Pending
-**Project:** {project_name}
-**PRD Reference:** {prd_link}
-**ADR Reference:** {adr_link}
-
----
-
-## Executive Summary
-
-**Scope:** {Brief description of feature scope}
-
-**Business Context** (from PRD):
-
-- **Revenue/Impact:** {Business metrics if applicable}
-- **Problem:** {Problem being solved}
-- **GA Launch:** {Target date or timeline}
-
-**Architecture** (from ADR {adr_number}):
-
-- **Key Decision 1:** {e.g., OAuth 2.1 authentication}
-- **Key Decision 2:** {e.g., Centralized MCP Server pattern}
-- **Key Decision 3:** {e.g., Stack: TypeScript, SDK v1.x}
-
-**Expected Scale** (from ADR):
-
-- {RPS, volume, users, etc.}
-
-**Risk Summary:**
-
-- **Total risks**: {N}
-- **High-priority (≥6)**: {N} risks requiring immediate mitigation
-- **Test effort**: ~{N} tests (~{X} weeks for 1 QA, ~{Y} weeks for 2 QAs)
-
----
-
-## Quick Guide
-
-### 🚨 BLOCKERS - Team Must Decide (Can't Proceed Without)
-
-**Pre-Implementation Critical Path** - These MUST be completed before QA can write integration tests:
-
-1. **{Blocker ID}: {Blocker Title}** - {What architecture must provide} (recommended owner: {Team/Role})
-2. **{Blocker ID}: {Blocker Title}** - {What architecture must provide} (recommended owner: {Team/Role})
-3. **{Blocker ID}: {Blocker Title}** - {What architecture must provide} (recommended owner: {Team/Role})
-
-**What we need from team:** Complete these {N} items pre-implementation or test development is blocked.
-
----
-
-### ⚠️ HIGH PRIORITY - Team Should Validate (We Provide Recommendation, You Approve)
-
-1. **{Risk ID}: {Title}** - {Recommendation + who should approve} (implementation phase)
-2. **{Risk ID}: {Title}** - {Recommendation + who should approve} (implementation phase)
-3. **{Risk ID}: {Title}** - {Recommendation + who should approve} (implementation phase)
-
-**What we need from team:** Review recommendations and approve (or suggest changes).
-
----
-
-### 📋 INFO ONLY - Solutions Provided (Review, No Decisions Needed)
-
-1. **Test strategy**: {Test level split} ({Rationale})
-2. **Tooling**: {Test frameworks and utilities}
-3. **Tiered CI/CD**: {Execution tiers with timing}
-4. **Coverage**: ~{N} test scenarios prioritized P0-P3 with risk-based classification
-5. **Quality gates**: {Pass criteria}
-
-**What we need from team:** Just review and acknowledge (we already have the solution).
-
----
-
-## For Architects and Devs - Open Topics 👷
-
-### Risk Assessment
-
-**Total risks identified**: {N} ({X} high-priority score ≥6, {Y} medium, {Z} low)
-
-#### High-Priority Risks (Score ≥6) - IMMEDIATE ATTENTION
-
-| Risk ID    | Category  | Description   | Probability | Impact | Score       | Mitigation            | Owner   | Timeline |
-| ---------- | --------- | ------------- | ----------- | ------ | ----------- | --------------------- | ------- | -------- |
-| **{R-ID}** | **{CAT}** | {Description} | {1-3}       | {1-3}  | **{Score}** | {Mitigation strategy} | {Owner} | {Date}   |
-
-#### Medium-Priority Risks (Score 3-5)
-
-| Risk ID | Category | Description   | Probability | Impact | Score   | Mitigation   | Owner   |
-| ------- | -------- | ------------- | ----------- | ------ | ------- | ------------ | ------- |
-| {R-ID}  | {CAT}    | {Description} | {1-3}       | {1-3}  | {Score} | {Mitigation} | {Owner} |
-
-#### Low-Priority Risks (Score 1-2)
-
-| Risk ID | Category | Description   | Probability | Impact | Score   | Action  |
-| ------- | -------- | ------------- | ----------- | ------ | ------- | ------- |
-| {R-ID}  | {CAT}    | {Description} | {1-3}       | {1-3}  | {Score} | Monitor |
-
-#### Risk Category Legend
-
-- **TECH**: Technical/Architecture (flaws, integration, scalability)
-- **SEC**: Security (access controls, auth, data exposure)
-- **PERF**: Performance (SLA violations, degradation, resource limits)
-- **DATA**: Data Integrity (loss, corruption, inconsistency)
-- **BUS**: Business Impact (UX harm, logic errors, revenue)
-- **OPS**: Operations (deployment, config, monitoring)
-
----
-
-### Testability Concerns and Architectural Gaps
-
-**🚨 ACTIONABLE CONCERNS - Architecture Team Must Address**
-
-{If system has critical testability concerns, list them here. If architecture supports testing well, state "No critical testability concerns identified" and skip to Testability Assessment Summary}
-
-#### 1. Blockers to Fast Feedback (WHAT WE NEED FROM ARCHITECTURE)
-
-| Concern            | Impact              | What Architecture Must Provide         | Owner  | Timeline    |
-| ------------------ | ------------------- | -------------------------------------- | ------ | ----------- |
-| **{Concern name}** | {Impact on testing} | {Specific architectural change needed} | {Team} | {Milestone} |
-
-**Example:**
-
-- **No API for test data seeding** → Cannot parallelize tests → Provide POST /test/seed endpoint (Backend, pre-implementation)
-
-#### 2. Architectural Improvements Needed (WHAT SHOULD BE CHANGED)
-
-{List specific improvements that would make the system more testable}
-
-1. **{Improvement name}**
-   - **Current problem**: {What's wrong}
-   - **Required change**: {What architecture must do}
-   - **Impact if not fixed**: {Consequences}
-   - **Owner**: {Team}
-   - **Timeline**: {Milestone}
-
----
-
-### Testability Assessment Summary
-
-**📊 CURRENT STATE - FYI**
-
-{Only include this section if there are passing items worth mentioning. Otherwise omit.}
-
-#### What Works Well
-
-- ✅ {Passing item 1} (e.g., "API-first design supports parallel test execution")
-- ✅ {Passing item 2} (e.g., "Feature flags enable test isolation")
-- ✅ {Passing item 3}
-
-#### Accepted Trade-offs (No Action Required)
-
-For {Feature} Phase 1, the following trade-offs are acceptable:
-
-- **{Trade-off 1}** - {Why acceptable for now}
-- **{Trade-off 2}** - {Why acceptable for now}
-
-{This is technical debt OR acceptable for Phase 1} that {should be revisited post-GA OR maintained as-is}
-
----
-
-### Risk Mitigation Plans (High-Priority Risks ≥6)
-
-**Purpose**: Detailed mitigation strategies for all {N} high-priority risks (score ≥6). These risks MUST be addressed before {GA launch date or milestone}.
-
-#### {R-ID}: {Risk Description} (Score: {Score}) - {CRITICALITY LEVEL}
-
-**Mitigation Strategy:**
-
-1. {Step 1}
-2. {Step 2}
-3. {Step 3}
-
-**Owner:** {Owner}
-**Timeline:** {Milestone or date}
-**Status:** Planned / In Progress / Complete
-**Verification:** {How to verify mitigation is effective}
-
----
-
-{Repeat for all high-priority risks}
-
----
-
-### Assumptions and Dependencies
-
-#### Assumptions
-
-1. {Assumption about architecture or requirements}
-2. {Assumption about team or timeline}
-3. {Assumption about scope or constraints}
-
-#### Dependencies
-
-1. {Dependency} - Required by {date/milestone}
-2. {Dependency} - Required by {date/milestone}
-
-#### Risks to Plan
-
-- **Risk**: {Risk to the test plan itself}
-  - **Impact**: {How it affects testing}
-  - **Contingency**: {Backup plan}
-
----
-
-**End of Architecture Document**
-
-**Next Steps for Architecture Team:**
-
-1. Review Quick Guide (🚨/⚠️/📋) and prioritize blockers
-2. Assign owners and timelines for high-priority risks (≥6)
-3. Validate assumptions and dependencies
-4. Provide feedback to QA on testability gaps
-
-**Next Steps for QA Team:**
-
-1. Wait for pre-implementation blockers to be resolved
-2. Refer to companion QA doc (test-design-qa.md) for test scenarios
-3. Begin test infrastructure setup (factories, fixtures, environments)