cc-codeconductor 0.4.3 → 1.0.0

package/presets/agy/workflows/cc-feature.md

@@ -9,7 +9,29 @@ description:
 
 Feature request: $ARGUMENTS
 
-## Step 1 — Task Card validation (task-coach)
+## Step 0 — CCEP Bootstrap
+
+Command: `feature` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command feature "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command feature "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile feature --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command feature --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the feature description above.
 
@@ -26,7 +48,7 @@ continuing.**
 
 ---
 
-## Step 2 — Technical Plan (architect)
+## Step 3 — Technical Plan (architect)
 
 Invoke `architect` with the validated Task Card from Step 1.
 
@@ -44,7 +66,20 @@ not invoke implementer until the plan is approved.**
 
 ---
 
-## Step 3 — Implementation (implementer)
+## Step 4 — Test coverage (tester)
+
+Invoke `tester` with the Implementation Summary and the Task Card.
+
+tester must:
+
+1. Write or extend failing tests for the new behavior before implementation (RED)
+2. Ensure all acceptance criteria from the Task Card have at least one test
+3. Run the full test suite and confirm it passes
+4. Produce a Coverage Summary: test files added or modified, cases covered
+
+---
+
+## Step 5 — Implementation (implementer)
 
 Invoke `implementer` with the approved Technical Plan and the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
@@ -53,26 +88,13 @@ implementer must:
 
 1. Read the Technical Plan before touching any file
 2. Apply the minimal diff — only what the plan specifies
-3. Run the project test suite after implementation
+3. Run the project test suite and make the previously written failing tests pass
 4. Produce an Implementation Summary: what changed, which files, how to verify
    locally
 
 ---
 
-## Step 4 — Test coverage (tester)
-
-Invoke `tester` with the Implementation Summary and the Task Card.
-
-tester must:
-
-1. Write or extend tests to cover the new behavior
-2. Ensure all acceptance criteria from the Task Card have at least one test
-3. Run the full test suite and confirm it passes
-4. Produce a Coverage Summary: test files added or modified, cases covered
-
----
-
-## Step 5 — Code review (reviewer)
+## Step 6 — Code review (reviewer)
 
 Invoke `reviewer` with the complete diff and the Task Card.
 
@@ -87,7 +109,7 @@ they are resolved and re-reviewed.
 
 ---
 
-## Step 6 — Documentation (docs)
+## Step 7 — Documentation (docs)
 
 Invoke `docs` only if any of the following changed:
 

package/presets/agy/workflows/cc-fix.md

@@ -2,7 +2,7 @@
 name: cc-fix
 description:
   Run the bug fix workflow — risk-based routing through task validation,
-  implementation, testing, and optional review.
+  testing, implementation, and optional review.
 ---
 
 # Bug Fix Workflow
@@ -19,7 +19,29 @@ Provide the following information in $ARGUMENTS:
 
 ---
 
-## Step 1 — Task Card validation (task-coach)
+## Step 0 — CCEP Bootstrap
+
+Command: `fix` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command fix "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command fix "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile fix --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command fix --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the bug description above.
 
@@ -34,11 +56,16 @@ If reproduction steps are missing, task-coach must ask for them before
 classifying risk. A bug without a reproduction path cannot be classified
 reliably.
 
+Capture evidence before tests: reproduction, logs or stack traces, and one
+falsifiable hypothesis of the root cause. Do not patch without that evidence.
+Redact secrets, tokens, and credential dumps from logs before they enter the
+Task Card. Summarize stack traces; do not paste env files.
+
 **STOP here. Show the Task Card and wait for human confirmation.**
 
 ---
 
-## Step 2 — Route by risk
+## Step 3 — Route by risk
 
 Read the risk field from the Task Card and follow the corresponding route.
 
@@ -47,16 +74,16 @@ Read the risk field from the Task Card and follow the corresponding route.
 Applies when: the bug is isolated to a single component, existing tests cover
 the affected code, and no public API or shared state is involved.
 
-Route: `task-coach` → `implementer` → `tester`
+Route: `task-coach` → `tester` → `implementer`
 
-Proceed directly to Step 3a.
+Proceed directly to Step 3 (tests), then Step 4a.
 
 ### Medium or high-risk route
 
 Applies when: the bug touches shared state, a public API, auth or payment paths,
 database writes, or the root cause is not yet understood.
 
-Route: `task-coach` → `architect` → `implementer` → `tester` → `reviewer`
+Route: `task-coach` → `architect` → `tester` → `implementer` → `reviewer`
 
 Invoke `architect` before implementation. architect must:
 
@@ -70,7 +97,20 @@ before continuing.**
 
 ---
 
-## Step 3a — Implementation, low-risk (implementer)
+## Step 4 — Regression tests (tester)
+
+Invoke `tester` for all risk levels.
+
+tester must:
+
+1. Write a regression test that reproduces the original bug and confirm it fails
+   before any fix (RED)
+2. Verify that existing tests still pass
+3. Produce a Coverage Summary: test added, case covered
+
+---
+
+## Step 5a — Implementation, low-risk (implementer)
 
 Invoke `implementer` with the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
@@ -79,12 +119,12 @@ implementer must:
 
 1. Locate the defect using the reproduction steps
 2. Apply the minimal fix — no unrelated changes
-3. Run the test suite
+3. Run the suite and make the RED regression test pass
 4. Produce an Implementation Summary: root cause, fix applied, files changed
 
 ---
 
-## Step 3b — Implementation, medium/high-risk (implementer)
+## Step 5b — Implementation, medium/high-risk (implementer)
 
 Invoke `implementer` with the approved Technical Plan and the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
@@ -94,20 +134,7 @@ Plan approval. After implementation, run the full test suite.
 
 ---
 
-## Step 4 — Regression tests (tester)
-
-Invoke `tester` for all risk levels.
-
-tester must:
-
-1. Write a regression test that reproduces the original bug (fails before the
-   fix, passes after)
-2. Verify that existing tests still pass
-3. Produce a Coverage Summary: test added, case covered
-
----
-
-## Step 5 — Review (reviewer) — medium/high-risk only
+## Step 6 — Review (reviewer) — medium/high-risk only
 
 Invoke `reviewer` with the diff and Task Card.
 

package/presets/agy/workflows/cc-handoff.md

@@ -0,0 +1,42 @@
+---
+name: cc-handoff
+description:
+  Compact the session into gitignored `.codeconductor/sessions/handoff.md` (redact secrets).
+---
+
+# Handoff Workflow
+
+Handoff request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `handoff` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command handoff "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command handoff "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile handoff --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command handoff --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Compact (docs)
+
+Invoke `docs`. Write **only** `.codeconductor/sessions/handoff.md` (gitignored).
+Do not write `.codeconductor/handoff.md` or any tracked path.
+
+Before writing, redact secrets, tokens, API keys, passwords, connection strings,
+`.env` contents, and log/stack-trace lines that embed those values. Summarize
+errors instead of pasting dumps. If unresolved credential material remains, stop
+and wait for a human (CCEP `stopOnHighRisk`).
+
+Include: goal, Task Card status (no secret fields), files touched, test
+pass/fail (not log dumps), open questions, and the next `/cc:` command.
+
+Do not edit source or tests.
+
+---
+
+## Completion
+
+Report the handoff path. Another session should be able to continue from that file alone.

package/presets/agy/workflows/cc-iterative.md

@@ -0,0 +1,128 @@
+---
+name: cc-iterative
+description:
+  Run the advanced iterative workflow — Wayfinding AST discovery, Relentless
+  Grilling, contract and spec design, TDD, council review, and docs.
+---
+
+# Advanced Iterative Workflow
+
+Iterative request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `iterative` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command iterative "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command iterative "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile iterative --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command iterative --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when two modules or one concept need a
+scoped subgraph). Then invoke `repo-explorer` with that graph output.
+
+repo-explorer maps directory trees, conventions, god nodes, and affected
+modules. Do not write code in this step. Write a short phase handoff (scope,
+files, open questions) before the next phase — do not chain agents on unspoken
+context.
+
+---
+
+## Step 2 — Relentless Grilling & Task Card (task-coach)
+
+Invoke `task-coach` using the Grilling protocol to stress-test all assumptions.
+
+The Task Card is ready when it contains: title, type, risk classification,
+scope, context, acceptance criteria, and constraints, and every assumption
+behind it has survived one grilling question.
+
+If any field is missing or ambiguous, ask one clarifying question at a time and
+wait for the answer. Do not proceed with an incomplete Task Card.
+
+**STOP here.** Unresolved grilling questions or missing fields populate
+`questionsForUser` in the CCEP-1 `planner-output`; the `ConfirmationGate`
+(`ccep evaluate`) reads that field and halts the workflow until a human
+answers. Show the completed Task Card and wait for that confirmation before
+continuing.
+
+---
+
+## Step 3 — Contract & Technical Plan (contract-builder & architect)
+
+Invoke `contract-builder` then `architect` with the validated Task Card.
+
+1. Define API contracts, JSON Schemas, or TypeScript interfaces.
+2. Formulate the Technical Plan (chosen approach, affected files, trade-offs).
+3. Apply YAGNI, Simplicity First, and Stdlib-First.
+
+**STOP here. Show the Technical Plan and wait for explicit human approval. Do
+not invoke implementer until the plan is approved.**
+
+---
+
+## Step 4 — Test coverage (tester)
+
+Invoke `tester` with the Task Card and Technical Plan.
+
+1. Write or extend failing tests for the new behavior before implementation (RED).
+2. Ensure all acceptance criteria from the Task Card have at least one test.
+3. Produce a Test Report: test files added or modified, cases covered.
+
+---
+
+## Step 5 — Implementation (implementer)
+
+Invoke `implementer` with the approved Technical Plan, contracts, and failing
+tests. Implementer creates a Git Worktree before touching any file; all edits
+happen inside it.
+
+1. Read the Technical Plan before touching any file.
+2. Apply the minimal diff — only what the plan specifies.
+3. Run the project test suite and make the previously written failing tests pass.
+4. If tests fail, run up to 3 repair cycles (`implementer` → `tester`).
+5. Produce an Implementation Summary: what changed, which files, how to verify
+   locally.
+
+---
+
+## Step 6 — Multi-Perspective Council Review
+
+Invoke the `council` skill on the generated diff (`council-review` phase).
+
+The council evaluates Architecture, Security, Product, Delivery, DataOps, and
+Devil. `security-reviewer` may set `securityVeto: true`; that REJECTED verdict
+overrides majority consensus.
+
+If ANY agent votes CRITICAL:
+- The Review Report status is **BLOCKED**.
+- Return to Step 5 with the feedback.
+
+If APPROVED (no CRITICAL findings), continue.
+
+---
+
+## Step 7 — Documentation (docs)
+
+Invoke `docs` when a public API, public module, or user-visible behavior
+changed.
+
+Update: README (if applicable), OpenAPI spec (if applicable), CHANGELOG
+(always when implementation changed), ADR (if an architectural decision was
+made).
+
+If `graphify-out/` is in use, run `graphify update .` (AST-only).
+
+---
+
+## Completion
+
+The iterative workflow is complete only when: all tests pass, the council
+approves the spec and the diff, no CRITICAL findings remain, and documentation
+and the knowledge graph reflect the implemented behavior.

package/presets/agy/workflows/cc-openspec.md

@@ -0,0 +1,75 @@
+---
+name: cc-openspec
+description:
+  Run OpenSpec backlog delivery — validate BACKLOG.md, plan TaskCards, orchestrate
+  agents by phase, review gate, and update backlog state.
+---
+
+# OpenSpec Backlog Workflow
+
+Scope: $ARGUMENTS
+
+---
+
+## Step 0 — Validate (mandatory gate)
+
+Run `npx cc-codeconductor openspec validate`. If invalid, show errors and recommendations, then **STOP**.
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `openspec` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command openspec "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command openspec "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile openspec --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command openspec --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Scan
+
+Run `npx cc-codeconductor openspec scan`. Report new, modified, and closed items.
+
+---
+
+## Step 2 — Select item
+
+Use `$ARGUMENTS` BC-id or `npx cc-codeconductor openspec status` for next READY item. **STOP** if none.
+
+---
+
+## Step 3 — Plan
+
+Run `npx cc-codeconductor openspec plan <BC-id>`. Show TaskCards and `openspec/changes/` path.
+
+---
+
+## Step 4 — Execute loop
+
+For each pending card: `npx cc-codeconductor openspec next`, then invoke the listed agent:
+
+- discover → `repo-explorer`
+- design → `architect`
+- test → `tester`
+- implement → `implementer`
+- review → `reviewer`
+
+Use isolated context. Implementer uses a git worktree.
+
+---
+
+## Step 5 — Review gate
+
+Reviewer approves or rejects against acceptance criteria. Reject → `IN_PROGRESS`, **STOP**.
+
+---
+
+## Step 6 — Update
+
+Mark DONE, move to Archive in BACKLOG.md, run `openspec scan`.
+
+Apply skill `openspec` for format and state rules.

package/presets/agy/workflows/cc-pagespeed.md

@@ -11,6 +11,18 @@ Audit URL: $ARGUMENTS
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `pagespeed` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command pagespeed "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command pagespeed "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile pagespeed --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command pagespeed --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Pre-flight (pagespeed-perf skill)
 
 Invoke `pagespeed-perf` skill.

package/presets/agy/workflows/cc-prototype.md

@@ -0,0 +1,39 @@
+---
+name: cc-prototype
+description:
+  Disposable spike in an isolated worktree. Not a merge candidate.
+---
+
+# Prototype Workflow
+
+Prototype request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `prototype` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command prototype "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command prototype "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile prototype --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command prototype --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Bounds (architect)
+
+Invoke `architect`. Define what the spike may touch, time-box, and what must not leak into main. Do not treat this as a production Technical Plan.
+
+**STOP here. Wait for approval of the spike bounds.**
+
+---
+
+## Step 2 — Spike (implementer)
+
+Invoke `implementer` in a Git worktree that is not a merge candidate. Label the Implementation Summary as disposable. Do not open a PR against protected branches.
+
+---
+
+## Completion
+
+Report bounds, worktree path, and what was learned. Recommend `/cc:feature` or `/cc:fix` if the spike should become real work.

package/presets/agy/workflows/cc-refactor.md

@@ -34,6 +34,18 @@ If coverage is insufficient:
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `refactor` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command refactor "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command refactor "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile refactor --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command refactor --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Architectural justification (architect)
 
 Always invoke `architect` first, regardless of risk level. A refactor without a

package/presets/agy/workflows/cc-review.md

@@ -18,6 +18,18 @@ Specify what to review. Accepted formats:
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `review` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command review "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command review "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile review --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command review --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Diff collection
 
 Before invoking `reviewer`, collect the diff for the specified target.

package/presets/agy/workflows/cc-scorecard.md

@@ -0,0 +1,29 @@
+---
+name: cc-scorecard
+description:
+  Evaluate deliverable quality — scorecard, outcome tracking, regression checklist.
+---
+
+# Scorecard Evaluation Workflow
+
+Scope: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `scorecard` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command scorecard "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command scorecard "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile scorecard --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command scorecard --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+1. `npx cc-codeconductor scorecard create --task <id> --from-diff`
+2. Complete criteria per docs/agent-scorecard.md
+3. `scorecard regression` if needed
+4. `scorecard record` with verdict and optional cost/tokens
+5. `scorecard aggregate`
+
+Apply skill `evaluation`.

package/presets/agy/workflows/cc-tdd-cycle.md

@@ -18,6 +18,19 @@ Describe what behavior you want to implement. Include:
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `tdd-cycle` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command tdd-cycle "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command tdd-cycle "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile tdd-cycle --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command tdd-cycle --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
 ## Before you begin — mandatory pre-check
 
 This command enforces strict TDD discipline. The three phases are sequential and
@@ -30,6 +43,17 @@ non-negotiable:
 Do not write implementation code during RED. Do not refactor during GREEN.
 Mixing phases invalidates the cycle.
 
+## Verifiable phase gates
+
+RED → GREEN and GREEN → REFACTOR are enforced by `tddCycleStateMachine` in
+`domain/loop`. Evidence must be captured with `captureTddSuiteEvidence` (verification
+runner) — do not hand-edit JSON under `.codeconductor/evidence/`.
+
+- RED→GREEN requires runner evidence that the suite **failed**.
+- GREEN→REFACTOR requires runner evidence that the suite **passed**.
+
+Do not advance phases until that evidence exists.
+
 ---
 
 ## Phase 1 — RED (Tester role)

package/presets/agy/workflows/cc-test-plan.md

@@ -21,6 +21,18 @@ If $ARGUMENTS is empty, describe the scope in your next message before invoking
 
 ---
 
+## Step 0 — CCEP Bootstrap
+
+Command: `test-plan` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command test-plan "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command test-plan "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile test-plan --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command test-plan --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Scope confirmation
 
 Before invoking `tester`, confirm the scope is well-defined.