cc-codeconductor 0.5.0 → 1.1.0

package/presets/opencode/commands/cc-security.md

@@ -0,0 +1,179 @@
+---
+description: >
+  Run the authorized defensive security workflow — domain security-* skills,
+  authorization gate, risk-based routing, hardening, and review.
+---
+
+# Defensive Security Workflow
+
+Security objective: $ARGUMENTS
+
+Provide the following information in $ARGUMENTS:
+
+- What must be reviewed or hardened, and why
+- Domain: a `security-*` skill id (recon, vuln-assessment, web, cloud, IR,
+  hunting, GRC, …) or `web-app` / `api` / `cloud-config` /
+  `dependency-supply-chain` / `secrets`
+- Authorization: who authorized this work on this target, and the scope boundary
+- Risk classification (`low`, `medium`, or `high`), if known
+- Scope: which files, modules, repos, or environments are in and out of bounds
+
+---
+
+## Scope and authorization
+
+This workflow performs **authorized defensive security work only**: threat
+modeling, hardening, secure configuration, dependency and supply-chain review,
+secret hygiene, and detection coverage.
+
+Refuse outright and offer the defensive equivalent instead (threat model,
+hardening, detection coverage, dependency audit):
+
+- Exploit or proof-of-concept development
+- Malware authoring, or malware analysis intended for reuse
+- Reverse engineering aimed at bypassing a control
+- Red-team playbooks
+- Any unauthorized-access procedure
+
+Scope is limited to the repository under analysis. Do not scan, probe, or
+perform reconnaissance against third-party hosts.
+
+Do not proceed without an authorization statement. Do not produce exploit
+payloads, malware, or attack procedures.
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `security` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command security "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command security "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile security --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command security --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. Load the matching `security-*` skill
+for the named domain (see `.claude/skills/security-*/SKILL.md`). Keep the OWASP
+`security` skill for application-security reviews.
+
+---
+
+## Step 2 — Task Card validation (task-coach)
+
+Invoke `task-coach` with the security objective above.
+
+task-coach must produce a Task Card that includes:
+
+- Objective: what must be reviewed or hardened, in one sentence
+- Domain: which `security-*` skill applies, or `web-app` / `api` /
+  `cloud-config` / `dependency-supply-chain` / `secrets`
+- Authorization: who authorized this work on this target, and the scope boundary
+- Risk classification: `low`, `medium`, or `high`
+- Scope: which files or modules are likely affected
+
+If authorization is absent, unclear, or names a system the requester does not
+own or operate, **STOP and refuse. Do not route the task.**
+
+Redact secrets, tokens, and credentials from any evidence before it enters the
+Task Card. Summarize logs; do not paste env files.
+
+**STOP here. Show the Task Card and wait for human confirmation.**
+
+---
+
+## Step 3 — Route by risk
+
+Read the risk field from the Task Card and follow the corresponding route.
+
+### Low-risk route
+
+Applies when: the weakness is isolated, not exploitable in the current
+configuration, and no authentication, secret, or dependency boundary is
+involved.
+
+Route: `task-coach` → `tester` → `implementer`
+
+Proceed directly to Step 4 (tests), then Step 5a.
+
+### Medium or high-risk route
+
+Applies when: the work touches authentication, authorization, secrets,
+cryptography, trust-boundary input validation, or a dependency upgrade.
+
+Route: `task-coach` → `architect` → `tester` → `implementer` → `reviewer`
+
+Invoke `architect` before implementation. architect must:
+
+- Identify the weakness and the affected trust boundary
+- Define the hardening approach and affected files
+- Flag any regression risk to adjacent components
+- Produce a Technical Plan
+
+On **high** risk, also invoke `security-reviewer` before Reviewer.
+
+**STOP here if high-risk. Show the Technical Plan and wait for human approval
+before continuing.**
+
+---
+
+## Step 4 — Tests (tester)
+
+Invoke `tester` for all risk levels.
+
+tester must:
+
+1. Write a regression test that proves the weakness exists and confirm it fails
+   before any change (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.
+
+implementer must:
+
+1. Apply the minimal hardening change — no unrelated changes
+2. Run the suite and make the RED regression test pass
+3. Produce an Implementation Summary: weakness, change applied, files changed
+
+---
+
+## 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.
+
+implementer must follow the plan exactly. Any deviation requires a new Technical
+Plan approval. After implementation, run the full test suite. No exploit code.
+
+---
+
+## Step 6 — Review (Reviewer role) — medium/high-risk only
+
+Invoke `reviewer` with the diff and Task Card. The Reviewer must apply the OWASP
+rules in the `security` skill.
+
+reviewer produces a Review Report with CRITICAL / WARNING / SUGGESTION findings.
+If any CRITICAL findings exist, **STOP**. Do not close the task until they are
+resolved.
+
+---
+
+## Completion
+
+Report: Task Card, Implementation Summary, regression test added, Review Report
+(if applicable). The task is complete only when: the regression test passes, the
+full suite passes, and no CRITICAL review findings remain.

package/presets/opencode/commands/cc-tdd-cycle.md

@@ -17,6 +17,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
@@ -29,6 +42,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/opencode/commands/cc-test-plan.md

@@ -20,6 +20,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.

package/presets/opencode/commands/cc-triage.md

@@ -0,0 +1,33 @@
+---
+description: Classify a request into type, risk, and the destination CodeConductor command.
+---
+
+# Triage Workflow
+
+Triage request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `triage` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command triage "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command triage "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile triage --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command triage --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 — Classify (task-coach)
+
+Invoke `task-coach`. Produce: title, type (`feature` | `fix` | `refactor` | `review` | `docs` | `test`), risk, named scope, and the destination command (`feature`, `fix`, `refactor`, `review`, `explore`, …).
+
+Ask one question per unresolved branch. If the human is unavailable, emit a Markdown questionnaire and stop at ConfirmationGate.
+
+**STOP here. Show the classification and wait for confirmation before running the destination workflow.**
+
+---
+
+## Completion
+
+Do not implement. Hand the human a destination slash command and a partial Task Card.

package/presets/opencode/gates/pre-commit/GATE.md

@@ -0,0 +1,137 @@
+# Pre-commit Gate: Typecheck, Lint, and Test
+
+Este gate instala un hook `pre-commit` que ejecuta `bun run typecheck`, `bun run lint` y `bun run test` antes de permitir commits en el repositorio. Si cualquiera de estos comandos falla, el commit es bloqueado.
+
+## Cuándo usar
+
+**Para agentes**: Integra este gate en flujos de desarrollo local cuando quieras garantizar que los cambios typecheck correctamente y pasan los tests antes de ser cometidos.
+
+**Para equipos**: Utiliza este gate como barrera de calidad local (sin dependencias externas) para prevenir commits con errores de tipado o tests fallidos.
+
+## Instalación
+
+### Paso 1: Descarga el script
+
+El script está embebido abajo (sección "Script Installer").
+
+### Paso 2: Ejecuta en la raíz de tu proyecto
+
+Desde la raíz del repositorio (o cualquier subdirectorio), extrae el bloque ```bash de este archivo y ejecuta:
+
+    bash << 'SCRIPT_EOF'
+    #!/bin/bash
+    set -e
+    # [contenido del bloque bash de abajo]
+    SCRIPT_EOF
+
+O, más simplemente, guarda el script en un archivo temporal y ejecútalo:
+
+    curl -s https://raw.githubusercontent.com/.../ | bash
+
+### Paso 3: Verifica
+
+Después de la instalación, debería verse:
+
+    Pre-commit hook installed successfully.
+
+## Script Installer
+
+```bash
+#!/bin/bash
+set -e
+
+# Resolver git directory dinámicamente (worktree-safe)
+GIT_DIR=$(git rev-parse --git-dir)
+HOOK_PATH="$GIT_DIR/hooks/pre-commit"
+
+# Detectar Husky o lint-staged en package.json
+if grep -q '"husky"' package.json 2>/dev/null || grep -q '"lint-staged"' package.json 2>/dev/null; then
+  echo "Warning: Husky or lint-staged detected in package.json. Installation skipped."
+  exit 0
+fi
+
+# Verificar si un pre-commit hook ya existe
+if [ -f "$HOOK_PATH" ]; then
+  echo "Warning: Pre-commit hook already exists at $HOOK_PATH. Not overwriting."
+  exit 0
+fi
+
+# Crear directorio hooks si no existe
+mkdir -p "$GIT_DIR/hooks"
+
+# Escribir el hook pre-commit
+cat > "$HOOK_PATH" << 'HOOK_EOF'
+#!/bin/bash
+bun run typecheck || exit 1
+bun run lint || exit 1
+bun run test || exit 1
+HOOK_EOF
+
+# Hacer el hook ejecutable
+chmod +x "$HOOK_PATH"
+
+echo "Pre-commit hook installed successfully."
+```
+
+## Notas de implementación
+
+- **Sin dependencias externas**: El script no instala Husky, lint-staged, ni ninguna otra herramienta. Solo escribe un archivo shell y configura permisos.
+- **Resolución dinámica de git dir**: Usa `git rev-parse --git-dir` para localizar el directorio correcto, incluso en worktrees.
+- **Detección de conflictos**: Si Husky o lint-staged ya está en `package.json`, el script avisa y no instala para evitar conflictos.
+- **Protección de hooks existentes**: Si ya existe un `.git/hooks/pre-commit`, el script no lo sobrescribe.
+- **Solo Bun**: El hook ejecuta `bun run typecheck`, `bun run lint` y `bun run test`. Asegúrate de que estos scripts están definidos en `package.json`.
+
+## Verificación
+
+Después de instalar, verifica que el hook está en su lugar.
+
+Para verificar, ejecuta:
+
+    ls -la .git/hooks/pre-commit
+
+Debe mostrar algo como:
+
+    -rwxr-xr-x  user  group  ... .git/hooks/pre-commit
+
+Luego, intenta hacer un commit. Si hay errores de tipo o tests fallidos, el commit será bloqueado:
+
+    git add .
+    git commit -m "test"
+    # Si typecheck o test falla, verás el error y el commit será abortado.
+
+## Troubleshooting
+
+### "Warning: Pre-commit hook already exists"
+
+Ya hay un hook pre-commit. Revisa su contenido:
+
+    cat .git/hooks/pre-commit
+
+Si quieres reemplazarlo, bórralo y ejecuta el script nuevamente:
+
+    rm .git/hooks/pre-commit
+    bash /path/to/installer
+
+### "Warning: Husky or lint-staged detected"
+
+Tu proyecto usa Husky o lint-staged. Este gate no se instala para evitar conflictos. Si quieres usar este gate, remove Husky/lint-staged de `package.json` y ejecuta de nuevo.
+
+### Hook no se ejecuta al hacer commit
+
+Verifica que el hook es ejecutable:
+
+    chmod +x .git/hooks/pre-commit
+
+Verifica que `bun run typecheck`, `bun run lint` y `bun run test` existen en `package.json`:
+
+    cat package.json | grep -A 5 '"scripts"'
+
+### "command not found: bun"
+
+Bun no está instalado o no está en PATH. Instala Bun desde https://bun.sh o configura PATH adecuadamente.
+
+## Adicional: Desinstalación
+
+Para remover el hook, simplemente bórralo:
+
+    rm .git/hooks/pre-commit

package/presets/opencode/prompts/v0.1.0/DEPRECATED.md

@@ -0,0 +1,11 @@
+# DEPRECATED — v0.1.0
+
+**Status:** deprecated. Superseded by `v1.0.0`.
+
+These Agent Contracts are kept for reproducibility only. Projects that pinned
+`contract_version: 0.1.0` can still reinstall from this directory, but new work
+must not adopt this version.
+
+- Do not edit these files — contracts are append-only.
+- Use `prompts/v1.0.0/` for all new installs.
+- See `docs/prompt-versioning.md` for the full version table.

package/presets/opencode/prompts/v0.2.0/DEPRECATED.md

@@ -0,0 +1,11 @@
+# DEPRECATED — v0.2.0
+
+**Status:** deprecated. Superseded by `v1.0.0`.
+
+These Agent Contracts are kept for reproducibility only. Projects that pinned
+`contract_version: 0.2.0` can still reinstall from this directory, but new work
+must not adopt this version.
+
+- Do not edit these files — contracts are append-only.
+- Use `prompts/v1.0.0/` for all new installs.
+- See `docs/prompt-versioning.md` for the full version table.

package/presets/opencode/prompts/v0.3.0/DEPRECATED.md

@@ -0,0 +1,11 @@
+# DEPRECATED — v0.3.0
+
+**Status:** deprecated. Superseded by `v1.0.0`.
+
+These Agent Contracts are kept for reproducibility only. Projects that pinned
+`contract_version: 0.3.0` can still reinstall from this directory, but new work
+must not adopt this version.
+
+- Do not edit these files — contracts are append-only.
+- Use `prompts/v1.0.0/` for all new installs.
+- See `docs/prompt-versioning.md` for the full version table.

package/presets/opencode/prompts/v0.4.0/DEPRECATED.md

@@ -0,0 +1,11 @@
+# DEPRECATED — v0.4.0
+
+**Status:** deprecated. Superseded by `v1.0.0`.
+
+These Agent Contracts are kept for reproducibility only. Projects that pinned
+`contract_version: 0.4.0` can still reinstall from this directory, but new work
+must not adopt this version.
+
+- Do not edit these files — contracts are append-only.
+- Use `prompts/v1.0.0/` for all new installs.
+- See `docs/prompt-versioning.md` for the full version table.

package/presets/opencode/prompts/v0.5.0/goal-planner.md

@@ -45,7 +45,7 @@ Match objective keywords against built-in templates (in order):
 | migration, schema, database | migration |
 | (no match) | generic 4-task chain |
 
-**Generic fallback chain:** `task-coach` → `architect` → `implementer` → `tester`
+**Generic fallback chain:** `task-coach` → `architect` → `tester` → `implementer`
 
 Each task must include: `id`, `title`, `type`, `risk`, `status: pending`,
 `context_scope`, `depends_on`, `acceptance_criteria` (≥ 1 each).

package/presets/opencode/prompts/v0.5.0/orchestrator.md

@@ -106,22 +106,22 @@ regression.
 
 | Task type          | Risk        | Route                                                              |
 | ------------------ | ----------- | ------------------------------------------------------------------ |
-| New feature        | high        | `architect` → `implementer` → `tester` → `security-reviewer` → `reviewer` |
-| New feature        | low-medium  | `architect` → `implementer` → `tester` → `reviewer`                |
+| New feature        | high        | `architect` → `tester` → `implementer` → `security-reviewer` → `reviewer` |
+| New feature        | low-medium  | `architect` → `tester` → `implementer` → `reviewer`                |
 | Performance Opt    | medium      | `task-coach` → `implementer` → `reviewer`                           |
-| Bug fix            | low         | `implementer` → `tester`                                           |
-| Bug fix            | medium–high | `task-coach` → `architect` → `implementer` → `tester` → `reviewer` |
+| Bug fix            | low         | `tester` → `implementer`                                           |
+| Bug fix            | medium–high | `task-coach` → `architect` → `tester` → `implementer` → `reviewer` |
 | Refactor           | low         | `architect` → `implementer`                                        |
 | Refactor           | medium–high | `architect` → `implementer` → `reviewer`                           |
 | API change         | any         | `architect` → `implementer` → `reviewer`                           |
-| Database migration | any         | `architect` → `implementer` → `tester` → `reviewer`                |
+| Database migration | any         | `architect` → `tester` → `implementer` → `reviewer`                |
 | Test coverage      | any         | `tester`                                                           |
 | Documentation      | any         | `docs`                                                             |
 | Codebase question  | any         | `repo-explorer`                                                    |
 | Code review        | any         | `reviewer`                                                         |
 | Task unclear       | any         | `task-coach`                                                       |
 | Multi-step goal    | any         | `goal-planner` → [dependency-ordered agents]                       |
-| DDD→SDD→TDD        | any         | `contract-builder` → `architect` → `implementer` → `tester`        |
+| DDD→SDD→TDD        | any         | `contract-builder` → `architect` → `tester` → `implementer`        |
 
 ---
 

package/presets/opencode/prompts/v0.6.0/implementer.md

@@ -0,0 +1,35 @@
+---
+name: Implementer
+description: Executes an approved Technical Plan with minimal diff. CCEP-1 structured output.
+---
+
+# Agent Contract — implementer v0.6.0
+
+## Role
+
+You are the Implementer for CodeConductor (CCEP-1). Execute the approved Technical
+Plan and Task Card. Write the minimal diff. Do not invent architecture.
+
+## Output contract (mandatory JSON)
+
+Respond with **valid JSON only** matching `ImplementerOutputSchema`:
+
+```json
+{
+  "status": "success",
+  "confidence": 0.0,
+  "warnings": [],
+  "artifacts": [{ "type": "diff", "path": "src/example.ts" }],
+  "next_actions": [],
+  "filesChanged": [{ "path": "src/example.ts", "summary": "Added validation" }],
+  "tests": { "runner": "bun test", "result": "passed" }
+}
+```
+
+## Rules
+
+- Read the Technical Plan before editing any file.
+- Touch only files listed in the plan.
+- Run tests before returning output.
+- If blocked, set `status` to `blocked` and list `next_actions`.
+- Never return free-form prose as the final answer.

package/presets/opencode/prompts/v0.6.0/planner.md

@@ -0,0 +1,36 @@
+---
+name: Planner
+description: Converts product intent into structured CCEP planner output. No code.
+---
+
+# Agent Contract — planner v0.6.0
+
+## Role
+
+You are the Planner for CodeConductor (CCEP-1). Convert execution context into a
+structured plan. Do not write code.
+
+## Output contract (mandatory JSON)
+
+Respond with **valid JSON only** matching `PlannerOutputSchema`:
+
+```json
+{
+  "status": "success",
+  "confidence": 0.0,
+  "goal": "",
+  "assumptions": [],
+  "risks": [],
+  "tasks": [],
+  "questionsForUser": [],
+  "needsConfirmation": true
+}
+```
+
+## Rules
+
+- Use only information from the compiled CCEP context.
+- If critical data is missing, set `status` to `needs_clarification` and populate
+  `questionsForUser`.
+- Never invent repository context.
+- Separate assumptions, risks, tasks, and confirmation requirements.

package/presets/opencode/prompts/v0.6.0/reviewer.md

@@ -0,0 +1,40 @@
+---
+name: Reviewer
+description: Reviews diffs against Task Card and plan. CCEP-1 structured output.
+---
+
+# Agent Contract — reviewer v0.6.0
+
+## Role
+
+You are the Reviewer for CodeConductor (CCEP-1). Verify the implementation against
+the Task Card and Technical Plan. Do not edit code.
+
+## Output contract (mandatory JSON)
+
+Respond with **valid JSON only** matching `ReviewerOutputSchema`:
+
+```json
+{
+  "status": "pass",
+  "confidence": 0.0,
+  "verdict": "approved",
+  "warnings": [],
+  "findings": [
+    {
+      "severity": "WARNING",
+      "message": "Missing edge-case test",
+      "axis": "test_coverage"
+    }
+  ],
+  "artifacts": [],
+  "next_actions": []
+}
+```
+
+## Rules
+
+- Any CRITICAL finding → `verdict: "blocked"` and `status: "fail"`.
+- Every finding must include `severity`, `message`, and `axis`.
+- Base review on diff evidence — no speculation.
+- Never return free-form prose as the final answer.

package/presets/opencode/prompts/v1.0.0/README.md

@@ -0,0 +1,47 @@
+# Agent Contracts v1.0.0
+
+First stable, distributable contract set. Copied from `v0.5.0` and aligned with
+the CodeConductor Execution Protocol (CCEP-1) and the current workflow profiles.
+
+## Contracts
+
+| Contract | Role in the workflow |
+| -------- | -------------------- |
+| `orchestrator.md` | Validates Task Cards, selects the route, monitors completion. |
+| `task-coach.md` | Turns vague requests into complete, routable Task Cards (intake). |
+| `planner.md` | CCEP-1 intake role — serializes intent into `planner-output`. |
+| `goal-planner.md` | Turns an objective string into a YAML task graph. |
+| `repo-explorer.md` | Read-only repo map, conventions, impact radius. |
+| `architect.md` | Technical Plan, ADRs, module boundaries. |
+| `contract-builder.md` | API contracts / data shapes before implementation (DDD→SDD→TDD). |
+| `tester.md` | Failing-first tests that verify acceptance criteria. |
+| `implementer.md` | Minimal-diff implementation of the approved plan. |
+| `complexity-auditor.md` | Bloat / dependency / cyclomatic audit (feeds `cc-gain`). |
+| `reviewer.md` | Correctness, scope, security, and architecture review. |
+| `security-reviewer.md` | Dedicated high-risk security review with veto authority. |
+| `docs.md` | README / OpenAPI / ADR / CHANGELOG sync. |
+| `devil.md` | Devil's advocate for the `council` (adversarial) workflow. |
+
+## What changed from v0.5.0
+
+- **CCEP-1 alignment** — every contract now carries a "CCEP-1 structured output"
+  section mapping its Markdown Deliverable to the runtime JSON schema
+  (`planner-output`, `technical-plan`, `implementer-output`, `review-report`,
+  `council-verdict`, `agent-output`).
+- **New `devil.md`** — the devil's advocate role required by the `council`
+  workflow profile (previously referenced without a contract).
+- **New `planner.md`** — the CCEP-1 intake role carried forward from the v0.6.0
+  draft and finalized.
+- **Orchestrator** — added the `council` workflow, the `devil` routing row, a
+  workflow-commands table, and a CCEP-1 confirmation-gate section.
+- Intake/design/test/review contracts stop on unresolved branches, wayfinding
+  names the next `/cc:` command, TDD forbids green-by-weakening, and `docs` may
+  write session handoffs only to `.codeconductor/sessions/handoff.md` (gitignored,
+  secrets redacted).
+- Version markers and scorecard `contract_version` bumped to `v1.0.0`.
+
+## Versioning
+
+Contracts are append-only. Versions `v0.1.0`–`v0.4.0` are deprecated (see each
+directory's `DEPRECATED.md` and `docs/prompt-versioning.md`). Pin the version via
+`contract_version` in `codeconductor.config.jsonc`.