cc-codeconductor 0.4.3 → 1.0.0

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

@@ -0,0 +1,250 @@
+---
+description: >-
+  [cc: alias] Run a structured Red-Green-Refactor TDD cycle — write a failing
+  test first, implement the minimum code to pass it, then refactor with the
+  suite green.
+---
+
+# TDD Cycle — Red → Green → Refactor
+
+Scope: $ARGUMENTS
+
+Describe what behavior you want to implement. Include:
+
+- The function, method, or feature to implement
+- The expected behavior (inputs and outputs, or acceptance criteria)
+- Any known constraints or edge cases
+- Relevant files or modules (if known)
+
+---
+
+## 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
+non-negotiable:
+
+1. **RED** — a failing test exists before any implementation code is written
+2. **GREEN** — the minimum implementation to make the test pass (no more)
+3. **REFACTOR** — clean up the code while keeping all tests green
+
+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)
+
+Invoke the `tester` subagent via the Task tool.
+
+### 1a — Scope clarification
+
+Before writing any test, confirm:
+
+- What is the unit of behavior being tested? (function, method, endpoint, domain
+  rule)
+- What are the inputs and expected outputs?
+- What are the failure cases?
+
+If the scope is ambiguous, ask one clarifying question and wait for the answer.
+
+### 1b — Write the failing test
+
+Write a test that:
+
+- Targets exactly the behavior described in the scope
+- Fails for the right reason (not a compile error, not a missing dependency —
+  the logic does not exist yet)
+- Has a name that describes the behavior: `given_X_when_Y_then_Z` or equivalent
+  in the project's test naming convention
+- Covers at minimum: one happy path, one edge case, one failure case
+
+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
+
+Run the test suite. The new test must fail. Existing tests must pass.
+
+If the new test passes without implementation, the test is wrong. Fix the test
+before continuing.
+
+**RED Phase Report:**
+
+```
+## RED Phase Report
+
+**Test file**: [path/to/test/file]
+**Tests written**:
+- [test name] — [what it verifies]
+
+**Suite result**: [X passing, Y failing]
+**New test status**: FAIL ✓
+**Failure reason**: [quoted error or assertion message]
+**Existing tests**: [all passing | N failing — list]
+```
+
+**STOP. Show the RED Phase Report. Do not proceed to GREEN without
+confirmation.**
+
+---
+
+## Phase 2 — GREEN (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool.
+
+### 2a — Read the failing test before writing any code
+
+Understand exactly what the test asserts. Write only the code that satisfies
+that assertion. Nothing more.
+
+### 2b — Implement the minimum
+
+Rules for GREEN phase:
+
+- Write the smallest amount of code that makes the failing test pass
+- Do not add features not tested
+- Do not clean up or restructure existing code — that is Refactor's job
+- Do not add new tests — that is another RED cycle
+- Hardcoding a return value is acceptable if it makes the test pass (the
+  Refactor phase will generalize it)
+
+### 2c — Run the test suite and confirm GREEN
+
+Run the test suite. The new test must pass. All previously passing tests must
+still pass.
+
+If any previously passing test now fails, you introduced a regression. Fix it
+before continuing.
+
+**GREEN Phase Report:**
+
+```
+## GREEN Phase Report
+
+**Files changed**:
+- [path/to/file] — [what was added, one sentence]
+
+**Implementation approach**: [one sentence — what the code does]
+**Suite result**: [X passing, Y failing]
+**New test status**: PASS ✓
+**Regressions**: [none | list failing tests]
+```
+
+**STOP. Show the GREEN Phase Report. Do not proceed to REFACTOR without
+confirmation.**
+
+---
+
+## Phase 3 — REFACTOR (Implementer role, then Reviewer role)
+
+Invoke the `implementer` subagent via the Task tool.
+
+### 3a — Assess what needs cleaning
+
+Before touching any code, identify:
+
+- Duplication introduced during GREEN
+- Names that do not clearly express intent
+- Abstractions that belong in a separate function or module
+- Logic that is hardcoded and should be generalized
+
+Do not invent improvements. Only address what is directly in the implementation
+written in Phase 2.
+
+### 3b — Refactor
+
+Rules for REFACTOR phase:
+
+- All tests must remain GREEN throughout — run the suite after each change
+- Do not add new behavior
+- Do not add new tests (if you discover untested behavior, note it for a new RED
+  cycle)
+- Do not change function signatures unless the original was clearly wrong
+
+### 3c — Run the test suite and confirm GREEN after refactor
+
+The full suite must pass. If any test fails during refactor, undo the last
+change and investigate.
+
+### 3d — Review (Reviewer role)
+
+Invoke the `reviewer` subagent via the Task tool.
+
+Review only the refactored code against these axes:
+
+| Axis          | What to check                                                   |
+| ------------- | --------------------------------------------------------------- |
+| Scope         | Did the refactor change any behavior?                           |
+| Correctness   | Does the logic still satisfy the original test intent?          |
+| Architecture  | Does the code follow existing project patterns?                 |
+| Test coverage | Are all written tests still meaningful (not trivially passing)? |
+
+Produce a Review Report. CRITICAL findings block completion.
+
+**REFACTOR Phase Report:**
+
+```
+## REFACTOR Phase Report
+
+**Changes made**:
+- [path/to/file] — [what was cleaned up]
+
+**Suite result**: [X passing, Y failing]
+**Behavioral changes**: none (refactor only)
+
+### Review findings
+**CRITICAL**: (none) | [list]
+**WARNING**: (none) | [list]
+**SUGGESTION**: (none) | [list]
+
+**Verdict**: approved | approved with warnings | blocked
+```
+
+---
+
+## Completion
+
+The TDD cycle is complete when:
+
+- RED: at least one failing test was written and confirmed failing
+- GREEN: the minimum implementation makes the test pass
+- REFACTOR: the code is clean, all tests pass, no CRITICAL review findings
+
+**Final Summary:**
+
+```
+## TDD Cycle Summary
+
+**Behavior implemented**: [one sentence]
+**Tests written**: [count] — [list test names]
+**Files changed**: [list]
+**Suite result**: [X passing, Y failing]
+**Cycle status**: complete | blocked (reason)
+```
+
+If the behavior requires additional test cases, start a new `/tdd-cycle` with
+the next scenario. One cycle = one behavior.

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

@@ -0,0 +1,150 @@
+---
+description: >-
+  [cc: alias] Generate a structured test plan for a feature or module — covers
+  unit, integration, contract, and edge cases without writing implementation code.
+---
+
+# Test Plan Workflow
+
+Scope: $ARGUMENTS
+
+Specify what to plan tests for. Examples:
+
+- A feature name: `user authentication`
+- A module or file path: `src/orders/OrderService.kt`
+- A Task Card title: `Add paginated product listing endpoint`
+- A PR or branch: `feature/payment-retry`
+
+If $ARGUMENTS is empty, describe the scope in your next message before
+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.
+
+A valid scope includes:
+
+- The behavior or module under test
+- The acceptance criteria or expected behavior (from the Task Card if available)
+- Known edge cases or failure modes
+
+If the scope is vague (e.g., "test the whole service"), ask one clarifying
+question and wait for the answer.
+
+---
+
+## Step 2 — Test plan generation (Tester role, planning mode)
+
+Invoke the `tester` subagent via the Task tool.
+
+Produce a test plan document — not test code. The plan will be used as input
+when tests are actually written.
+
+Cover the following layers:
+
+**Unit tests**
+
+- Individual functions or methods in isolation
+- One test per behavior, not per method
+- Input/output contracts, null handling, type coercion
+
+**Integration tests**
+
+- Interactions between two or more components
+- Database read/write cycles (if applicable)
+- External service boundaries (mocked or stubbed)
+
+**Contract tests**
+
+- API endpoint contracts: request shape, response shape, status codes
+- Event schema contracts (if event-driven components are in scope)
+
+**Edge cases**
+
+- Empty inputs, boundary values, max/min limits
+- Concurrent access (if shared state is involved)
+- Failure paths: what happens when a dependency is unavailable
+
+**Regression cases**
+
+- Known past bugs that must not recur (include reference if available)
+
+---
+
+## Step 3 — Test Plan format
+
+Produce the plan in this format:
+
+```markdown
+## Test Plan — [Scope Name]
+
+### Scope
+[What is being tested and why]
+
+### Unit Tests
+| Test ID | Target | Scenario | Expected Result |
+| ------- | ------ | -------- | --------------- |
+| U-001   | ...    | ...      | ...             |
+
+### Integration Tests
+| Test ID | Components | Scenario | Expected Result |
+| ------- | ---------- | -------- | --------------- |
+| I-001   | ...        | ...      | ...             |
+
+### Contract Tests
+| Test ID | Endpoint/Event | Property | Expected Value |
+| ------- | -------------- | -------- | -------------- |
+| C-001   | ...            | ...      | ...            |
+
+### Edge Cases
+| Test ID | Input/Condition | Expected Behavior |
+| ------- | --------------- | ----------------- |
+| E-001   | ...             | ...               |
+
+### Regression Cases
+| Test ID | Reference | Scenario | Must Not Happen |
+| ------- | --------- | -------- | --------------- |
+| R-001   | ...       | ...      | ...             |
+
+### Coverage Targets
+- Minimum unit coverage: [% or "all acceptance criteria covered"]
+- Integration scenarios: [count]
+- Contract validations: [count]
+
+### Out of Scope
+[What this test plan explicitly does not cover and why]
+```
+
+---
+
+## Step 4 — Human review
+
+Show the Test Plan before any tests are written. The Test Plan is an artifact
+for review and approval.
+
+Writing test code is a separate action — run `/feature` or add a test task to
+implement from this plan.
+
+---
+
+## Completion
+
+Deliver the complete Test Plan document. Save it as
+`docs/test-plans/[scope-slug].md` if requested.
+
+This command produces a plan, not test files. No production code and no test
+code is written during this command.

package/presets/cursor/commands/cc/triage.md

@@ -0,0 +1,34 @@
+---
+description: >-
+  [cc: alias] 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/cursor/gates/pre-commit/GATE.md

@@ -0,0 +1,136 @@
+# Pre-commit Gate: Typecheck and Test
+
+Este gate instala un hook `pre-commit` que ejecuta `bun run typecheck` 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 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` 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` 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/cursor/rules/behavioral-discipline.mdc

@@ -0,0 +1,14 @@
+---
+description: Behavioral discipline for all code changes — think before coding, simplicity first, surgical changes, goal-driven execution.
+globs: "**/*"
+alwaysApply: false
+---
+
+# Behavioral Discipline
+
+1. **Think Before Coding** — State assumptions explicitly. If uncertain, ask.
+2. **Simplicity First** — Minimum code that solves the problem. No speculative abstractions.
+3. **Surgical Changes** — Touch only what you must. Match existing style.
+4. **Goal-Driven Execution** — Define verifiable success criteria. Loop until verified.
+
+See @AGENTS.md for full routing policy and agent contracts.

package/presets/cursor/rules/context-budget.mdc

@@ -0,0 +1,12 @@
+---
+description: Context budget and token optimization — use when conversation is long or switching tasks.
+alwaysApply: false
+---
+
+# Context Budget
+
+- Execute `/clear` when switching to an unrelated task type.
+- Use `/summarize` or `/compress` before re-delegating with large context.
+- Delegate verbose exploration to background subagents (`repo-explorer`).
+- Prefer `@filename` references over pasting full file contents.
+- Respect `.cursorignore` — do not read excluded paths unless explicitly required.

package/presets/cursor/rules/orchestration.mdc

@@ -0,0 +1,12 @@
+---
+description: Cursor subagent orchestration patterns — multitask, parallel delegation, model tiers.
+alwaysApply: false
+---
+
+# Orchestration Patterns
+
+- Use `/multitask` for independent parallel steps (review + docs).
+- Invoke subagents via Task tool: `orchestrator`, `architect`, `implementer`, `tester`, `reviewer`, `security-reviewer`, `complexity-auditor`, `docs`, `task-coach`, `repo-explorer`.
+- High-risk routes: `architect` → `tester` → `implementer` → `security-reviewer` → `reviewer`.
+- Run `repo-explorer` as background subagent for codebase mapping.
+- See `.cursor/agents/orchestrator.md` for full routing table.

package/presets/cursor/rules/yagni-stdlib.mdc

@@ -0,0 +1,11 @@
+---
+description: YAGNI and stdlib-first constraints for source code changes.
+globs: "src/**"
+alwaysApply: false
+---
+
+# YAGNI and Stdlib-First
+
+- Do not build features or abstractions not explicitly requested.
+- Prefer the language standard library over third-party packages.
+- Every line must solve a problem that exists now.