cc-codeconductor 1.0.0 → 1.2.0

package/presets/opencode/README.md

@@ -17,30 +17,33 @@ providers)** models.
 | `claude-sonnet-4-6`         | Balanced, general purpose       | Default for most agents         |
 | `claude-haiku-4-5-20251001` | Fast, lightweight               | Task Coach, Docs, Repo Explorer |
 
-### OpenCode Go Models (Chinese Providers)
-
-| Model             | Provider        | Strength                         | Best For                   |
-| ----------------- | --------------- | -------------------------------- | -------------------------- |
-| `deepseek-v4-pro` | DeepSeek        | Reasoning complejo, arquitectura | Architect, orchestrator    |
-| `mimo-v2.5-pro`   | MiniMax         | Razonamiento matemático, código  | Implementer                |
-| `minimax-m2.7`    | MiniMax         | Tareas equilibradas              | Tester, orchestrator       |
-| `qwen3.6-plus`    | Qwen            | Rápido, eficiente                | Reviewer, Task Coach, Docs |
-| `kimi-k2-6`       | Kimi (Moonshot) | Conversación natural             | Task Coach, Docs           |
+### OpenCode Go models
+
+Canonical slugs live in `src/presets/models/*.yml`. Production roles never use
+`muse-spark-1.2-contributor` (trains on prompts). `ox-alpha-free` is an optional
+fallback, not a default.
+
+| Model | Best for |
+| --- | --- |
+| `deepseek-v4-pro` | Architect |
+| `kimi-k3` | Security reviewer |
+| `qwen3.8-max` | Reviewer, contract-builder |
+| `glm-5.3` | Devil, complexity-auditor |
+| `mimo-v2.5` | Implementer |
+| `minimax-m3` | Tester |
+| `qwen3.7-plus` | Orchestrator (TUI default) |
+| `gpt-5.6-luna` | Task coach, planner |
+| `deepseek-v4-flash` | Goal planner |
+| `longcat-2.0` | Repo explorer |
+| `hy3` | Docs |
 
 ---
 
 ## Agent Model Matrix
 
-| Agent             | Claude (Default)            | OpenCode Go (Recommended) | Alternative       |
-| ----------------- | --------------------------- | ------------------------- | ----------------- |
-| **Orchestrator**  | `claude-sonnet-4-6`         | `deepseek-v4-pro`         | `minimax-m2.7`    |
-| **Architect**     | `claude-opus-4-7`           | `deepseek-v4-pro`         | `mimo-v2.5-pro`   |
-| **Implementer**   | `claude-sonnet-4-6`         | `mimo-v2.5-pro`           | `minimax-m2.7`    |
-| **Tester**        | `claude-sonnet-4-6`         | `minimax-m2.7`            | `deepseek-v4-pro` |
-| **Reviewer**      | `claude-sonnet-4-6`         | `qwen3.6-plus`            | `minimax-m2.7`    |
-| **Task Coach**    | `claude-haiku-4-5-20251001` | `qwen3.6-plus`            | `kimi-k2.6`       |
-| **Docs**          | `claude-haiku-4-5-20251001` | `qwen3.6-plus`            | `kimi-k2.6`       |
-| **Repo Explorer** | `claude-haiku-4-5-20251001` | `qwen3.6-plus`            | `kimi-k2.6`       |
+See `skills/cc-update-preset-models/references/role-map.md`. OpenCode column
+examples: architect `deepseek-v4-pro`, implementer `mimo-v2.5`, tester
+`minimax-m3`, reviewer `qwen3.8-max`.
 
 ---
 
@@ -93,7 +96,7 @@ The following paths are denied by default:
 
 ### Medium Tasks (Implementation, testing)
 
-**Recommended:** `mimo-v2.5-pro` or `minimax-m2.7` (OpenCode Go) or
+**Recommended:** `mimo-v2.5` or `minimax-m3` (OpenCode Go) or
 `claude-sonnet-4-6` (Claude)
 
 - Implementer code writing
@@ -165,7 +168,7 @@ export KIMI_API_KEY="your-key"
 | ------------------------------- | -------------------------------------------------- |
 | Complex reasoning, architecture | OpenCode Go (`deepseek-v4-pro`) or Claude (`opus`) |
 | Fast iteration, simple tasks    | OpenCode Go (`qwen3.6-plus`) or Claude (`haiku`)   |
-| Code implementation             | OpenCode Go (`mimo-v2.5-pro`) or Claude (`sonnet`) |
+| Code implementation             | OpenCode Go (`mimo-v2.5`) or Claude (`sonnet`) |
 | Budget constraints              | OpenCode Go (generally lower cost)                 |
 | Availability issues             | Switch to alternative from the matrix              |
 

package/presets/opencode/agents/architect.md

@@ -246,3 +246,9 @@ Rules under CCEP-1:
 - Never approve your own plan — the human approves before implementation starts.
 - If scope expands during design, flag it as a separate task, not an extension
   of the current one.
+
+## Composition
+
+Invoke via `/cc-feature`, `/cc-openspec`, or the orchestrator. Do not invoke
+other agents. If an OpenSpec change folder is active, invoke skill `openspec`
+and run `openspec analyze --output json` before implementation is allowed.

package/presets/opencode/agents/implementer.md

@@ -215,3 +215,10 @@ tests. On **REJECT**, stop and escalate to the orchestrator.
 - Never modify the Technical Plan — if the plan is wrong, escalate to
   `architect` via the orchestrator.
 - Never commit without human confirmation.
+
+## Composition
+
+Invoke via `/cc-feature`, `/cc-fix`, `/cc-tdd-cycle`, or the orchestrator.
+Do not invoke other agents. Invoke skill `testing-tdd`.
+Deliverable is incomplete without a passing suite and runner TDD evidence when
+TDD is required. Scorecard: `bun run dev scorecard create --from-diff`.

package/presets/opencode/agents/reviewer.md

@@ -282,3 +282,9 @@ Invoke skill `evaluation` and run `scorecard record` with agent `reviewer`, mode
 - Never issue vague findings ("this could be better") — every finding must name
   the exact location and the specific required action.
 - Never run `git push` or `git commit`.
+
+## Composition
+
+Invoke via `/cc-review` or the orchestrator. Do not invoke other agents.
+Invoke skill `evaluation`. Deliverable is incomplete without
+`scorecard create --from-diff` and a recorded PASS|REVISE|REJECT.

package/presets/opencode/agents/tester.md

@@ -285,3 +285,9 @@ and confirmed failing; list the failing test paths in `artifacts` so the
 - Never mock real behavior that could be tested with an in-memory alternative.
 - Never declare coverage complete when any acceptance criterion lacks a test.
 - Never run `git push` or `git commit`.
+
+## Composition
+
+Invoke via `/cc-tdd-cycle`, `/cc-feature`, or the orchestrator (test before
+implement). Do not invoke other agents. Invoke skill `testing-tdd`.
+Deliverable is incomplete without `captureTddSuiteEvidence` when TDD is required.

package/presets/opencode/commands/cc-api-contract.md

@@ -20,6 +20,20 @@ Command: `api-contract` (fixed for this workflow — do not infer from user text
 
 ---
 
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc-api-contract`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
 ## Step 1 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the request above.

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

@@ -36,10 +36,11 @@ The catalog is only:
 | `/cc:refactor` | structure, no behavior change |
 | `/cc:review` | inspect a diff/PR |
 | `/cc:tdd-cycle` | red → green → refactor |
+| `/cc:backlog` | create or append BACKLOG.md / objectives |
 | `/cc:openspec` | BACKLOG / BC-xxx delivery |
 
 If the CLI is unavailable, apply the same catalog and the same priority:
-openspec → tdd-cycle → review → refactor → fix → feature (default).
+backlog (author) vs openspec (deliver) → tdd-cycle → review → refactor → fix → feature (default).
 
 ---
 

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

@@ -0,0 +1,68 @@
+---
+description:
+  Author BACKLOG.md — wayfinding, grilling, create or append items, validate
+  with openspec, and plan OpenSpec change folders for /cc-openspec.
+---
+
+# Backlog Authoring Workflow
+
+Objectives: $ARGUMENTS
+
+Create or append valid `BACKLOG.md` items and OpenSpec change docs. Do **not**
+deliver implementation — that is `/cc-openspec`.
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `backlog` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command backlog "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command backlog "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile backlog --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command backlog --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 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke
+`repo-explorer`. Do not write `BACKLOG.md`. Scope must name real files.
+
+---
+
+## Step 2 — Relentless Grilling (task-coach)
+
+Invoke `task-coach`. Measurable acceptance only. One grilling question at a time.
+
+**STOP here.** Unresolved grilling questions populate `questionsForUser`;
+`ccep evaluate --command backlog` halts until a human answers.
+
+---
+
+## Step 3 — Write or append BACKLOG.md
+
+Apply skill `backlog`. Create from template if missing; otherwise append under
+`## Items`. Next `BC-NNN` = max existing + 1. Status `READY`. Do not rewrite
+`## Global` or `## Archive`. Do not `git add` `BACKLOG.md` or `openspec/`.
+
+---
+
+## Step 4 — Validate (mandatory gate)
+
+Run `npx cc-codeconductor openspec validate`. If invalid, show errors and
+canonical structure, fix, re-validate. **STOP** planning until valid.
+
+---
+
+## Step 5 — Plan new items
+
+For each new `BC-id`: `npx cc-codeconductor openspec plan <BC-id>`.
+
+---
+
+## Completion
+
+Report IDs, validate result, change folders. Tell the user to run `/cc-openspec`.
+Apply skill `backlog`.

package/presets/opencode/commands/cc-db-migration.md

@@ -21,6 +21,20 @@ Command: `db-migration` (fixed for this workflow — do not infer from user text
 
 ---
 
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc-db-migration`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
 ## Step 1 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the request above.

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

@@ -26,7 +26,7 @@ If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke `
 
 ## Step 2 — Suggest next command (orchestrator)
 
-Recommend exactly one next slash command (`/cc:feature`, `/cc:fix`, `/cc:refactor`, `/cc:review`, `/cc:triage`, …) with a one-sentence rationale. Do not start that workflow.
+Recommend exactly one next slash command (`/cc:feature`, `/cc:fix`, `/cc:refactor`, `/cc:review`, `/cc:backlog`, `/cc:openspec`, `/cc:triage`, …) with a one-sentence rationale. Do not start that workflow.
 
 ---
 

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

@@ -21,6 +21,24 @@ Command: `feature` (fixed for this workflow — do not infer from user text)
 
 ---
 
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc-feature`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+Skills: `using-cc-skills`, `openspec`, `testing-tdd`, `evaluation`.
+Do not skip `openspec analyze` when a change folder is active.
+"I'll add tests later" is not allowed — tester before implementer.
+
+---
+
+
 ## Step 1 — Wayfinding (repo-explorer)
 
 If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and

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

@@ -31,6 +31,20 @@ Command: `fix` (fixed for this workflow — do not infer from user text)
 
 ---
 
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc-fix`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
 ## Step 1 — Wayfinding (repo-explorer)
 
 If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
@@ -148,3 +162,6 @@ resolved.
 Report: Task Card, Implementation Summary, regression test added, Review Report
 (if applicable). The fix is complete only when: the regression test passes, the
 full suite passes, and no CRITICAL review findings remain.
+
+Skills: `testing-tdd`, `evaluation`. Record `scorecard create --from-diff`.
+A small fix still needs a Task Card and a failing regression test first.

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

@@ -21,6 +21,20 @@ Command: `iterative` (fixed for this workflow — do not infer from user text)
 
 ---
 
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc-iterative`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
 ## Step 1 — Wayfinding (repo-explorer)
 
 If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and

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

@@ -29,6 +29,20 @@ Command: `openspec` (fixed for this workflow — do not infer from user text)
 
 ---
 
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc-openspec`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
 ## Step 1 — Scan
 
 Run `npx cc-codeconductor openspec scan`. Report new, modified, and closed items.
@@ -45,6 +59,8 @@ Use `$ARGUMENTS` BC-id or `npx cc-codeconductor openspec status` for next READY
 
 Run `npx cc-codeconductor openspec plan <BC-id>`. Show TaskCards and `openspec/changes/` path.
 
+Drive status with CLI (do not edit openspec-state.json): `openspec start <cardId>`, `openspec done <cardId>`, `openspec block <cardId> --reason "…"`, `openspec archive <itemId>`.
+
 ---
 
 ## Step 4 — Execute loop
@@ -69,6 +85,6 @@ Reviewer approves or rejects against acceptance criteria. Reject → `IN_PROGRES
 
 ## Step 6 — Update
 
-Mark DONE, move to Archive in BACKLOG.md, run `openspec scan`.
+Mark DONE with `openspec archive <itemId>` (all cards must be done), then run `openspec scan`.
 
 Apply skill `openspec` for format and state rules.

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

@@ -19,6 +19,8 @@ Command: `scorecard` (fixed for this workflow — do not infer from user text)
 
 ---
 
+If a change folder exists, run `npx cc-codeconductor openspec analyze --output json` first. `--from-diff` overlays FR/SC coverage onto `acceptance` and TDD evidence onto `tests`.
+
 1. `scorecard create --task <id> --from-diff`
 2. Complete criteria (reviewer or human)
 3. `scorecard regression` (optional)

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.