@cregis-dev/cckit 0.2.0

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

@@ -0,0 +1,151 @@
+---
+name: 'step-05-generate-output'
+description: 'Generate output documents and validate against checklist'
+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
+
+---
+
+## 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.
+
+## 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`
+
+### Epic-Level Mode (Phase 4)
+
+Generate **one** document:
+
+- `{outputFile}` using `test-design-template.md`
+- If `epic_num` is unclear, ask the user
+
+---
+
+## 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

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

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

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

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

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

@@ -0,0 +1,70 @@
+---
+title: 'TEA Test Design → BMAD Handoff Document'
+version: '1.0'
+workflowType: 'testarch-test-design-handoff'
+inputDocuments: []
+sourceWorkflow: 'testarch-test-design'
+generatedBy: 'TEA Master Test Architect'
+generatedAt: '{timestamp}'
+projectName: '{project_name}'
+---
+
+# TEA → BMAD Integration Handoff
+
+## Purpose
+
+This document bridges TEA's test design outputs with BMAD's epic/story decomposition workflow (`create-epics-and-stories`). It provides structured integration guidance so that quality requirements, risk assessments, and test strategies flow into implementation planning.
+
+## TEA Artifacts Inventory
+
+| Artifact             | Path                      | BMAD Integration Point                               |
+| -------------------- | ------------------------- | ---------------------------------------------------- |
+| Test Design Document | `{test_design_path}`      | Epic quality requirements, story acceptance criteria |
+| Risk Assessment      | (embedded in test design) | Epic risk classification, story priority             |
+| Coverage Strategy    | (embedded in test design) | Story test requirements                              |
+
+## Epic-Level Integration Guidance
+
+### Risk References
+
+<!-- TEA will populate: P0/P1 risks that should appear as epic-level quality gates -->
+
+### Quality Gates
+
+<!-- TEA will populate: recommended quality gates per epic based on risk assessment -->
+
+## Story-Level Integration Guidance
+
+### P0/P1 Test Scenarios → Story Acceptance Criteria
+
+<!-- TEA will populate: critical test scenarios that MUST be acceptance criteria -->
+
+### Data-TestId Requirements
+
+<!-- TEA will populate: recommended data-testid attributes for testability -->
+
+## Risk-to-Story Mapping
+
+| Risk ID | Category | P×I | Recommended Story/Epic | Test Level |
+| ------- | -------- | --- | ---------------------- | ---------- |
+
+<!-- TEA will populate from risk assessment -->
+
+## Recommended BMAD → TEA Workflow Sequence
+
+1. **TEA Test Design** (`TD`) → produces this handoff document
+2. **BMAD Create Epics & Stories** → consumes this handoff, embeds quality requirements
+3. **TEA ATDD** (`AT`) → generates acceptance tests per story
+4. **BMAD Implementation** → developers implement with test-first guidance
+5. **TEA Automate** (`TA`) → generates full test suite
+6. **TEA Trace** (`TR`) → validates coverage completeness
+
+## Phase Transition Quality Gates
+
+| From Phase          | To Phase            | Gate Criteria                                          |
+| ------------------- | ------------------- | ------------------------------------------------------ |
+| Test Design         | Epic/Story Creation | All P0 risks have mitigation strategy                  |
+| Epic/Story Creation | ATDD                | Stories have acceptance criteria from test design      |
+| ATDD                | Implementation      | Failing acceptance tests exist for all P0/P1 scenarios |
+| Implementation      | Test Automation     | All acceptance tests pass                              |
+| Test Automation     | Release             | Trace matrix shows ≥80% coverage of P0/P1 requirements |