@cregis-dev/cckit 0.4.0 → 0.5.0

package/templates/bmad/tea/workflows/testarch/ci/steps-c/step-02-generate-pipeline.md

@@ -1,241 +0,0 @@
----
-name: 'step-02-generate-pipeline'
-description: 'Generate CI pipeline configuration with adaptive orchestration (agent-team, subagent, or sequential)'
-nextStepFile: './step-03-configure-quality-gates.md'
-outputFile: '{test_artifacts}/ci-pipeline-progress.md'
----
-
-# Step 2: Generate CI Pipeline
-
-## STEP GOAL
-
-Create platform-specific CI configuration with test execution, sharding, burn-in, and artifacts.
-
-## MANDATORY EXECUTION RULES
-
-- 📖 Read the entire step file before acting
-- ✅ Speak in `{communication_language}`
-- ✅ 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. Resolve Output Path and Select Template
-
-Determine the pipeline output file path based on the detected `ci_platform`:
-
-| CI Platform      | Output Path                                 | Template File                                       |
-| ---------------- | ------------------------------------------- | --------------------------------------------------- |
-| `github-actions` | `{project-root}/.github/workflows/test.yml` | `{installed_path}/github-actions-template.yaml`     |
-| `gitlab-ci`      | `{project-root}/.gitlab-ci.yml`             | `{installed_path}/gitlab-ci-template.yaml`          |
-| `jenkins`        | `{project-root}/Jenkinsfile`                | `{installed_path}/jenkins-pipeline-template.groovy` |
-| `azure-devops`   | `{project-root}/azure-pipelines.yml`        | `{installed_path}/azure-pipelines-template.yaml`    |
-| `harness`        | `{project-root}/.harness/pipeline.yaml`     | `{installed_path}/harness-pipeline-template.yaml`   |
-| `circle-ci`      | `{project-root}/.circleci/config.yml`       | _(no template; generate from first principles)_     |
-
-Use templates from `{installed_path}` when available. Adapt the template to the project's `test_stack_type` and `test_framework`.
-
----
-
-## 2. Pipeline Stages
-
-Include stages:
-
-- lint
-- test (parallel shards)
-- contract-test (if `tea_use_pactjs_utils` enabled)
-- burn-in (flaky detection)
-- report (aggregate + publish)
-
----
-
-## 3. Test Execution
-
-- Parallel sharding enabled
-- CI retries configured
-- Capture artifacts (HTML report, JUnit XML, traces/videos on failure)
-- Cache dependencies (language-appropriate: node_modules, .venv, .m2, go module cache, NuGet, bundler)
-
-Write the selected pipeline configuration to the resolved output path from step 1. Adjust test commands based on `test_stack_type` and `test_framework`:
-
-- **Frontend/Fullstack**: Include browser install, E2E/component test commands, Playwright/Cypress artifacts
-- **Backend (Node.js)**: Use `npm test` or framework-specific commands (`vitest`, `jest`), skip browser install
-- **Backend (Python)**: Use `pytest` with coverage (`pytest --cov`), install via `pip install -r requirements.txt` or `poetry install`
-- **Backend (Java/Kotlin)**: Use `mvn test` or `gradle test`, cache `.m2/repository` or `.gradle/caches`
-- **Backend (Go)**: Use `go test ./...` with coverage (`-coverprofile`), cache Go modules
-- **Backend (C#/.NET)**: Use `dotnet test` with coverage, restore NuGet packages
-- **Backend (Ruby)**: Use `bundle exec rspec` with coverage, cache `vendor/bundle`
-
-### Contract Testing Pipeline (if `tea_use_pactjs_utils` enabled)
-
-When `tea_use_pactjs_utils` is enabled, add a `contract-test` stage after `test`:
-
-**Required env block** (add to the generated pipeline):
-
-```yaml
-env:
-  PACT_BROKER_BASE_URL: ${{ secrets.PACT_BROKER_BASE_URL }}
-  PACT_BROKER_TOKEN: ${{ secrets.PACT_BROKER_TOKEN }}
-  GITHUB_SHA: ${{ github.sha }} # auto-set by GitHub Actions
-  GITHUB_BRANCH: ${{ github.head_ref || github.ref_name }} # NOT auto-set — must be defined explicitly
-```
-
-> **Note:** `GITHUB_SHA` is auto-set by GitHub Actions, but `GITHUB_BRANCH` is **not** — it must be derived from `github.head_ref` (for PRs) or `github.ref_name` (for pushes). The pactjs-utils library reads both from `process.env`.
-
-1. **Consumer test + publish**: Run consumer contract tests, then publish pacts to broker
-   - `npm run test:contract:consumer`
-   - `npx pact-broker publish ./pacts --consumer-app-version=$GITHUB_SHA --branch=$GITHUB_BRANCH`
-   - Only publish on PR and main branch pushes
-
-2. **Provider verification**: Run provider verification against published pacts
-   - `npm run test:contract:provider`
-   - `buildVerifierOptions` auto-reads `PACT_BROKER_BASE_URL`, `PACT_BROKER_TOKEN`, `GITHUB_SHA`, `GITHUB_BRANCH`
-   - Verification results published to broker when `CI=true`
-
-3. **Can-I-Deploy gate**: Block deployment if contracts are incompatible
-   - `npx pact-broker can-i-deploy --pacticipant=<ServiceName> --version=$GITHUB_SHA --to-environment=production`
-   - Add `--retry-while-unknown 6 --retry-interval 10` for async verification
-
-4. **Webhook job**: Add `repository_dispatch` trigger for `pact_changed` event
-   - Provider verification runs when consumers publish new pacts
-   - Ensures compatibility is checked on both consumer and provider changes
-
-5. **Breaking change handling**: When `PACT_BREAKING_CHANGE=true` env var is set:
-   - Provider test passes `includeMainAndDeployed: false` to `buildVerifierOptions` — verifies only matching branch
-   - Coordinate with consumer team before removing the flag
-
-6. **Record deployment**: After successful deployment, record version in broker
-   - `npx pact-broker record-deployment --pacticipant=<ServiceName> --version=$GITHUB_SHA --environment=production`
-
-Required CI secrets: `PACT_BROKER_BASE_URL`, `PACT_BROKER_TOKEN`
-
-**If `tea_pact_mcp` is `"mcp"`:** Reference the SmartBear MCP `Can I Deploy` and `Matrix` tools for pipeline guidance in `pact-mcp.md`.
-
----
-
-### 4. Save Progress
-
-**Save this step's accumulated work to `{outputFile}`.**
-
-- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
-
-  ```yaml
-  ---
-  stepsCompleted: ['step-02-generate-pipeline']
-  lastStep: 'step-02-generate-pipeline'
-  lastSaved: '{date}'
-  ---
-  ```
-
-  Then write this step's output below the frontmatter.
-
-- **If `{outputFile}` already exists**, update:
-  - Add `'step-02-generate-pipeline'` to `stepsCompleted` array (only if not already present)
-  - Set `lastStep: 'step-02-generate-pipeline'`
-  - Set `lastSaved: '{date}'`
-  - Append this step's output to the appropriate section of the document.
-
-### 5. Orchestration Notes for This Step
-
-For this step, treat these work units as parallelizable when `resolvedMode` is `agent-team` or `subagent`:
-
-- Worker A: resolve platform path/template and produce base pipeline skeleton (section 1)
-- Worker B: construct stage definitions and test execution blocks (sections 2-3)
-- Worker C: contract-testing block (only when `tea_use_pactjs_utils` is true)
-
-If `resolvedMode` is `sequential`, execute sections 1→4 in order.
-
-Load next step: `{nextStepFile}`
-
-## 🚨 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/ci/steps-c/step-03-configure-quality-gates.md

@@ -1,112 +0,0 @@
----
-name: 'step-03-configure-quality-gates'
-description: 'Configure burn-in, quality gates, and notifications'
-nextStepFile: './step-04-validate-and-summary.md'
-knowledgeIndex: '{project-root}/_bmad/tea/testarch/tea-index.csv'
-outputFile: '{test_artifacts}/ci-pipeline-progress.md'
----
-
-# Step 3: Quality Gates & Notifications
-
-## STEP GOAL
-
-Configure burn-in loops, quality thresholds, and notification hooks.
-
-## MANDATORY EXECUTION RULES
-
-- 📖 Read the entire step file before acting
-- ✅ Speak in `{communication_language}`
-
----
-
-## 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. Burn-In Configuration
-
-Use `{knowledgeIndex}` to load `ci-burn-in.md` guidance:
-
-- Run N-iteration burn-in for flaky detection
-- Gate promotion based on burn-in stability
-
-**Stack-conditional burn-in:**
-
-- **Frontend or Fullstack** (`test_stack_type` is `frontend` or `fullstack`): Enable burn-in by default. Burn-in targets UI flakiness (race conditions, selector instability, timing issues).
-- **Backend only** (`test_stack_type` is `backend`): Skip burn-in by default. Backend tests (unit, integration, API) are deterministic and rarely exhibit UI-related flakiness. If the user explicitly requests burn-in for backend, honor that override.
-
----
-
-## 2. Quality Gates
-
-Define:
-
-- Minimum pass rates (P0 = 100%, P1 ≥ 95%)
-- Fail CI on critical test failures
-- Optional: require traceability or nfr-assess output before release
-
-**Contract testing gate** (if `tea_use_pactjs_utils` is enabled):
-
-- **can-i-deploy must pass** before any deployment to staging or production
-- Block the deployment pipeline if contract verification fails
-- Treat consumer pact publishing failures as CI failures (contracts must stay up-to-date)
-- Provider verification must pass for all consumer pacts before merge
-
----
-
-## 3. Notifications
-
-Configure:
-
-- Failure notifications (Slack/email)
-- Artifact links
-
----
-
-### 4. Save Progress
-
-**Save this step's accumulated work to `{outputFile}`.**
-
-- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
-
-  ```yaml
-  ---
-  stepsCompleted: ['step-03-configure-quality-gates']
-  lastStep: 'step-03-configure-quality-gates'
-  lastSaved: '{date}'
-  ---
-  ```
-
-  Then write this step's output below the frontmatter.
-
-- **If `{outputFile}` already exists**, update:
-  - Add `'step-03-configure-quality-gates'` to `stepsCompleted` array (only if not already present)
-  - Set `lastStep: 'step-03-configure-quality-gates'`
-  - Set `lastSaved: '{date}'`
-  - Append this step's output to the appropriate section of the document.
-
-Load next step: `{nextStepFile}`
-
-## 🚨 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/ci/steps-c/step-04-validate-and-summary.md

@@ -1,92 +0,0 @@
----
-name: 'step-04-validate-and-summary'
-description: 'Validate pipeline and summarize'
-outputFile: '{test_artifacts}/ci-pipeline-progress.md'
----
-
-# Step 4: Validate & Summarize
-
-## STEP GOAL
-
-Validate CI configuration and report completion details.
-
-## MANDATORY EXECUTION RULES
-
-- 📖 Read the entire step file before acting
-- ✅ Speak in `{communication_language}`
-
----
-
-## 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. Validation
-
-Validate against `checklist.md`:
-
-- Config file created
-- Stages and sharding configured
-- Burn-in and artifacts enabled
-- Secrets/variables documented
-
-Fix gaps before completion.
-
----
-
-## 2. Completion Summary
-
-Report:
-
-- CI platform and config path
-- Key stages enabled
-- Artifacts and notifications
-- Next steps (set secrets, run pipeline)
-
----
-
-### 3. Save Progress
-
-**Save this step's accumulated work to `{outputFile}`.**
-
-- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
-
-  ```yaml
-  ---
-  stepsCompleted: ['step-04-validate-and-summary']
-  lastStep: 'step-04-validate-and-summary'
-  lastSaved: '{date}'
-  ---
-  ```
-
-  Then write this step's output below the frontmatter.
-
-- **If `{outputFile}` already exists**, update:
-  - Add `'step-04-validate-and-summary'` to `stepsCompleted` array (only if not already present)
-  - Set `lastStep: 'step-04-validate-and-summary'`
-  - 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/ci/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/ci/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/ci/steps-v/step-01-validate.md

@@ -1,67 +0,0 @@
----
-name: 'step-01-validate'
-description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/ci-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