cc-codeconductor 0.5.0 → 1.0.0

package/presets/claude/commands/cc/iterative.md

@@ -0,0 +1,132 @@
+---
+description: >-
+  [cc: alias] 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 role)
+
+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 adopt the **Repo Explorer** role as defined in
+`CLAUDE.md` with that graph output.
+
+Map 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 role)
+
+Adopt the **Task Coach** role as defined in `CLAUDE.md`.
+
+Produce a complete Task Card. 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 (Grilling protocol).
+
+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 (Architect role)
+
+Adopt the **Architect** role as defined in `CLAUDE.md`. Define contracts first,
+then the Technical Plan.
+
+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 proceed to tests until the plan is approved.**
+
+---
+
+## Step 4 — Test coverage (Tester role)
+
+Adopt the **Tester** role as defined in `CLAUDE.md`.
+
+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 role)
+
+Adopt the **Implementer** role as defined in `CLAUDE.md`.
+
+Use the approved Technical Plan, contracts, and the failing tests.
+Create 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 role)
+
+Adopt the **Docs** role as defined in `CLAUDE.md` 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/claude/commands/cc/openspec.md

@@ -12,6 +12,18 @@ Orchestrate FIFO delivery from `BACKLOG.md`. CodeConductor owns planning; agents
 
 ---
 
+## Planning Principles — tracer bullet and blocking edges
+
+A **tracer bullet** is a vertical slice of work: one `BC-NNN` backlog item that goes discover → design → test → implement → review and produces a demoable result, sized to fit inside a single agent's context window without needing an intermediate `/clear`.
+
+**Quantitative heuristic**: a tracer bullet must fit within a maximum of 5 acceptance criteria and the 5 canonical phases (discover, design, test, implement, review) per context window. If an item needs more, split it into multiple `BC-NNN` items linked by `Depends on` instead of growing one tracer bullet past that budget.
+
+**Equivalence**: one `BC-NNN` item equals one tracer bullet equals one or more TaskCards. `cc openspec plan <BC-id>` generates the TaskCards (discover/design/test/implement/review) that implement that item's tracer bullet — each BC-NNN item corresponds to exactly one tracer bullet.
+
+**Blocking edges**: the `Depends on` field between `BC-NNN` items expresses a blocking dependency — an item cannot be selected in Step 2 until every item in its `Depends on` list is `DONE`. `Depends on` is the sole mechanism for sequencing tracer bullets; there is no separate edge syntax.
+
+---
+
 ## Step 0 — Validate (mandatory gate)
 
 Run:
@@ -28,6 +40,19 @@ If validation fails:
 
 ---
 
+## 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:

package/presets/claude/commands/cc/pagespeed.md

@@ -4,6 +4,18 @@ Audit web performance using the PageSpeed Insights API. Applies the 80/20
 principle: identify the 20% of changes that produce 80% of the performance gain.
 Produces a prioritized report in the current working directory.
 
+## 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.
+
+---
+
 ## Usage
 
 ```

package/presets/claude/commands/cc/prototype.md

@@ -0,0 +1,38 @@
+---
+description: >-
+  [cc: alias] 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/claude/commands/cc/refactor.md

@@ -33,6 +33,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 role)
 
 Adopt the **Architect** role as defined in `CLAUDE.md`. Always invoke this step
@@ -56,6 +68,141 @@ proceed without written approval of the plan.**
 
 ---
 
+## Step 1.5 — Blast Radius Assessment (Orchestrator role)
+
+After Architect approval, assess the scope of the refactor using impact analysis.
+Large refactors require staged sequencing to keep the tree green between batches.
+
+### When to apply Blast Radius Assessment
+
+Always run this step. It determines the route for implementation:
+
+- **Narrow refactor** (blast radius within limits) → proceed to Step 2 (normal routing by risk)
+- **Wide refactor** (blast radius exceeds limits) → proceed to expand-migrate-contract sequence
+
+### Measuring blast radius
+
+Run impact analysis on the files listed in the approved Refactor Plan:
+
+```bash
+cc impact --files <file1> <file2> ... <fileN>
+```
+
+The report returns three metrics:
+
+1. **affectedComponents** (array of strings) — distinct components/modules that depend on the refactored files
+2. **brokenContracts** (array of strings) — public interfaces or contracts that change
+3. **affectedFlows** (array of strings) — end-to-end user flows or business processes impacted
+
+### Threshold decision
+
+**Hardcoded heuristic thresholds** (adjust manually for your codebase size):
+
+```
+Wide refactor triggered if ANY condition is true:
+  - affectedComponents.length >= 6
+  - brokenContracts.length >= 3
+  - affectedFlows.length >= 2
+```
+
+If blast radius exceeds these thresholds, the refactor is classified as **wide**
+and requires staged batching. Otherwise, it is **narrow** and proceeds via
+normal risk-based routing.
+
+**Note:** These thresholds are heuristics meant for medium-sized codebases
+(5–20K lines). Adjust based on your repository's complexity and component
+density. A high-level import count alone does not guarantee impact.
+
+### Route: Narrow refactor
+
+If blast radius is within limits:
+
+1. Show the impact report: affectedComponents count, brokenContracts, affectedFlows.
+2. Proceed to Step 2 (Route by risk) using the risk level from the approved Refactor Plan.
+
+### Route: Wide refactor — expand-migrate-contract sequence
+
+If blast radius exceeds limits, the refactor must be delivered in sequenced
+batches to maintain tree-green guarantees between phases.
+
+**Process:**
+
+1. **Expand phase** (batch 1): Introduce the new interface alongside the old one
+   without removing the old interface. This allows consumers to adopt
+   incrementally. Tests for both old and new paths must pass in this batch.
+   
+   Example: If refactoring a component from function-based to class-based:
+   ```typescript
+   // OLD: function-based API (keep during expand)
+   export function transformData(input: Data): Output {
+     return Transform.apply(input);
+   }
+   
+   // NEW: class-based API (add during expand)
+   export class DataTransformer {
+     apply(input: Data): Output {
+       return Transform.apply(input);
+     }
+   }
+   
+   // Both exported; both tested; old not yet removed.
+   ```
+
+2. **Migrate batches** (batches 2–N): Each batch moves a logical subset of
+   consumers from the old interface to the new one, running tests to confirm
+   no regressions. If tests fail in any migrate batch, that batch is BLOCKED
+   (via `Depends on` in BACKLOG.md) and subsequent batches do not start until
+   the regression is fixed.
+   
+   Example: Migrate Service-A consumers in batch 2, Service-B consumers in
+   batch 3, etc. Each batch is a separate `BC-NNN` item in BACKLOG.md.
+
+3. **Contract phase** (final batch): Remove the old interface entirely after all
+   consumers are migrated. This is the point where the contract actually changes.
+
+**Sequencing batches via BACKLOG.md:**
+
+Create multiple `BC-NNN` items, one per batch (expand, then one per migrate, then
+contract). Use the `Depends on` field to enforce ordering:
+
+```
+### BC-001 | Expand Phase
+Status: READY
+Depends on: (none)
+Description: Introduce new interface alongside old...
+
+### BC-002 | Migrate Batch 1 (Service-A consumers)
+Status: READY (but not eligible until BC-001 done)
+Depends on: BC-001
+Description: Move Service-A from old to new interface...
+
+### BC-003 | Migrate Batch 2 (Service-B consumers)
+Status: READY (but not eligible until BC-002 done)
+Depends on: BC-002
+Description: Move Service-B from old to new interface...
+
+### BC-004 | Contract Phase (Remove old interface)
+Status: READY (but not eligible until BC-003 done)
+Depends on: BC-003
+Description: Delete old interface and consolidate tests...
+```
+
+**BLOCKED policy on test failures:**
+
+If any migrate batch's test suite fails after implementation, that batch item
+is marked BLOCKED (and stays BLOCKED in BACKLOG.md until the regression is
+fixed). Subsequent batches in the `Depends on` chain do not start — the
+orchestrator skips them and reports the blocker to the user.
+
+This ensures the tree remains green and no downstream consumer migration builds
+on unstable code.
+
+**STOP here. Show the Blast Radius Assessment report and the recommended route
+(narrow or wide). If wide, show the proposed batch structure and wait for
+user approval before proceeding.**
+
+---
+
 ## Step 2 — Route by risk
 
 Read the risk field from the Refactor Plan and follow the corresponding route.
@@ -140,9 +287,13 @@ findings block completion.
 
 ## Completion
 
-Report: Refactor Plan (approved), Implementation Summary, test results before
+Report: Refactor Plan (approved), Blast Radius Assessment (if applicable), Implementation Summary, test results before
 and after, Review Report (if applicable).
 
 The refactor is complete only when: all pre-existing tests still pass, the
 implementation matches the approved plan exactly, and no CRITICAL review
 findings remain.
+
+If using expand-migrate-contract: completion occurs only after all batches
+(expand, migrate, contract) are DONE and no BLOCKED items remain in the
+sequencing chain.

package/presets/claude/commands/cc/review.md

@@ -17,6 +17,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 adopting the Reviewer role, collect the diff for the specified target.
@@ -45,7 +57,33 @@ Show the diff summary (files changed, lines added/removed) before proceeding.
 
 Adopt the **Reviewer** role as defined in `CLAUDE.md`.
 
-Evaluate the diff against the following checklist:
+Execute two axes in **parallel** without reranking between them, via separate sub-agents:
+
+**Standards Axis** — Code smell detection against Fowler baseline with documented override:
+
+- Long Method
+- Large Class
+- Duplicated Code
+- Feature Envy
+- Shotgun Surgery
+- Primitive Obsession
+- Data Clumps
+- Switch Statements
+- Speculative Generality
+- Temporary Fields
+- Message Chains
+- Middle Man
+- Inappropriate Intimacy
+- Data Class
+- Comments-as-apology
+
+**Spec Axis** — Task Card, acceptance criteria, and scope validation:
+
+- Does the implementation match the stated intent from the Task Card?
+- Are all acceptance criteria addressed?
+- Are there changes outside the stated scope?
+
+**Combined sub-checks** (apply findings from both axes):
 
 **Correctness**
 
@@ -77,31 +115,45 @@ Evaluate the diff against the following checklist:
 - Are public interfaces documented?
 - Is CHANGELOG updated if behavior changed?
 
----
-
 ## Step 3 — Review Report
 
-Produce a structured Review Report with findings in three categories:
+Produce a structured Review Report combining findings from both Standards and Spec axes (executed in parallel without reranking):
 
 ```markdown
 ## Review Report
 
-### CRITICAL
-[Findings that must be fixed before merge — file:line, description, suggested resolution]
+**Task**: [objective from Task Card] **Verdict**: [approved | approved with warnings | blocked]
+
+---
+
+### Standards Axis
+
+Findings from Fowler code smell baseline evaluation (with documented overrides applied).
+
+- [ ] [S1] [file:line] — [code smell type] | Override: [documented or N/A] | Required action: [change needed] (CRITICAL) or Recommended action: [change needed] (WARNING)
+
+_(none)_ if no code smell findings
+
+### Spec Axis
+
+Findings from Task Card, acceptance criteria, and scope alignment.
 
-### WARNING
-[Findings that should be resolved before merge — same format as CRITICAL]
+- [ ] [Sp1] [criterion] — [description] | Evidence: [quote] | Required action: [change needed] (CRITICAL) or Recommended action: [change needed] (WARNING)
 
-### SUGGESTION
-[Optional improvements — style, readability, future-proofing. These do not block merge.]
+_(none)_ if no spec findings
 
-### Summary
-- Files reviewed: N
-- Total findings: N (X critical, Y warnings, Z suggestions)
-- Merge recommendation: APPROVED | BLOCKED
+### Combined Summary
+
+- Standards findings: [count] (X CRITICAL, Y WARNING, Z SUGGESTION)
+- Spec findings: [count] (X CRITICAL, Y WARNING, Z SUGGESTION)
+- **Combined Verdict**: [approved | approved with warnings | blocked]
+- **Verdict justification**: [one sentence explaining the combined decision]
 ```
 
----
+Verdict mapping from parallel axes (no reranking):
+- If either axis has CRITICAL → verdict is `blocked`
+- Else if either axis has WARNING → verdict is `approved with warnings`
+- Else → verdict is `approved`
 
 ## Step 4 — Merge decision
 
@@ -128,10 +180,20 @@ Deliver the complete Review Report. Never summarize or omit findings.
 
 ## Step 5 — Scorecard and outcome
 
+Record the review outcome via scorecard with explicit verdict mapping:
+
 ```bash
 npx cc-codeconductor scorecard create --from-diff --agent reviewer
 npx cc-codeconductor scorecard record --verdict PASS|REVISE|REJECT --score <weighted>
 npx cc-codeconductor scorecard regression
 ```
 
-Map merge recommendation to scorecard verdict. Record outcome for trend tracking.
+**Verdict Mapping** (combined Standards + Spec axes):
+
+- `approved` → `npx cc-codeconductor scorecard record --verdict PASS`
+- `approved with warnings` → `npx cc-codeconductor scorecard record --verdict REVISE`
+- `blocked` → `npx cc-codeconductor scorecard record --verdict REJECT`
+
+Example: if the combined verdict is `blocked` (either axis found CRITICAL), record with `--verdict REJECT`.
+
+Map each review outcome for trend tracking and decision audit.

package/presets/claude/commands/cc/scorecard.md

@@ -10,6 +10,18 @@ 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.
+
+---
+
 ## Step 1 — Identify task
 
 Use `$ARGUMENTS` as task id (e.g. `BC-001`) or read active item from `npx cc-codeconductor openspec status`.

package/presets/claude/commands/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,13 +43,38 @@ 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.
+
+Each cycle covers a single vertical slice of behavior — one cycle, one
+behavior — and follows red-before-green: RED must complete before GREEN
+starts.
+
 ---
 
 ## Phase 1 — RED (Tester role)
 
 Adopt the **Tester** role as defined in `CLAUDE.md`.
 
-### 1a — Scope clarification
+### 1a — Agree on the seam
+
+Before writing any test, identify and state the seam — the point where the
+behavior under test can be exercised and observed in isolation (a function
+boundary, an interface, an injectable dependency). Confirm the seam does not
+require reaching into implementation internals.
+
+If no seam exists yet (the code is not structured to allow isolated testing),
+say so and agree on the minimal seam to introduce before continuing.
+
+### 1b — Scope clarification
 
 Before writing any test, confirm:
 
@@ -47,7 +85,7 @@ Before writing any test, confirm:
 
 If the scope is ambiguous, ask one clarifying question and wait for the answer.
 
-### 1b — Write the failing test
+### 1c — Write the failing test
 
 Write a test that:
 
@@ -61,7 +99,19 @@ Write a test that:
 Do not write the implementation. Do not make the test pass by any means other
 than the implementation that will follow in Phase 2.
 
-### 1c — Run the test suite and confirm RED
+### 1d — Anti-pattern checklist
+
+Before declaring the test ready, verify none of these anti-patterns apply:
+
+- **Implementation-coupled** — asserts internal details instead of observable
+  behavior.
+- **Tautological** — cannot fail given the test's own setup.
+- **Horizontal slicing** — spans multiple unrelated behaviors instead of one
+  vertical slice.
+
+If any anti-pattern applies, rewrite the test before continuing.
+
+### 1e — Run the test suite and confirm RED
 
 Run the test suite. The new test must fail. Existing tests must pass.
 

package/presets/claude/commands/cc/test-plan.md

@@ -20,6 +20,18 @@ proceeding.
 
 ---
 
+## 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 generating the test plan, confirm the scope is well-defined.