Variante NATIVA del PM/orquestador CCDD que usa sub-agentes de la app de Claude (tool Agent con model override) en vez de GLM/Ollama externo. Claude autora contrato + tests congelados (oráculo), delega la IMPLEMENTACIÓN a un sub-agente barato (Haiku 4.5), y verifica por el gate CCDD determinista. Úsala cuando quieras el flujo PM+CCDD sin la fragilidad de ollama, con aislamiento por worktree para paralelismo y reintentos con contexto vía SendMessage. Hermana de pm-glm-ccdd (misma metodología; cambia SOLO el mecanismo de delegación). Deslinde con pm-sonnet-opus-haiku: mismo gate CCDD/KDD como verificador si el repo lo trae, pero tiering de implementador distinto — esta usa Haiku barato con escalado a Sonnet; pm-sonnet-opus-haiku usa Opus fijo (más caro) más QA/verificación adversarial opcional en capas. Elegí ESTA para el flujo 100% CCDD con implementador barato; usá pm-sonnet-opus-haiku si preferís implementador Opus + QA por capas.
Variante NATIVA del PM/orquestador CCDD que usa sub-agentes de la app de Claude (tool Agent con model override) en vez de GLM/Ollama externo. Claude autora contrato + tests congelados (oráculo), delega la IMPLEMENTACIÓN a un sub-agente barato (Haiku 4.5), y verifica por el gate CCDD determinista. Úsala cuando quieras el flujo PM+CCDD sin la fragilidad de ollama, con aislamiento por worktree para paralelismo y reintentos con contexto vía SendMessage. Hermana de pm-glm-ccdd (misma metodología; cambia SOLO el mecanismo de delegación). Deslinde con pm-sonnet-opus-haiku: mismo gate CCDD/KDD como verificador si el repo lo trae, pero tiering de implementador distinto — esta usa Haiku barato con escalado a Sonnet; pm-sonnet-opus-haiku usa Opus fijo (más caro) más QA/verificación adversarial opcional en capas. Elegí ESTA para el flujo 100% CCDD con implementador barato; usá pm-sonnet-opus-haiku si preferís implementador Opus + QA por capas.
PM nativo · Devs = sub-agentes de la app (Agent + model override) · QA = CCDD gate
Misma metodología CCDD que pm-glm-ccdd — contrato + tests congelados
autorados ANTES de delegar, verify-by-artifact, política de reintentos, red-team del HECHO,
suite 2x. Lo único que cambia es el mecanismo de delegación: en vez de ollama launch
(GLM externo), el implementador es un sub-agente nativo vía la tool Agent.
Tiering (los cuatro tiers, nativos)
Triage → Haiku 4.5 (Agent, model:"haiku"): leer issue, clasificar, limpiar log, mapear
tools MCP, detectar si ya está hecho. Cortá el pipeline aquí si no hay trabajo.
PM/oráculo → Sonnet 5 (model:"sonnet") por defecto; Opus solo para oráculos
adversariales sin tropo conocido. Autora contrato + tests congelados + lint + baseline rojo.
Dev/implementador → Haiku 4.5 (model:"haiku"), escalá a una función
puntual si Haiku falla el gate 2×.
model:"sonnet"
Gate/verify → el orquestador (vos): corrés mcp__ccdd-complexity__* + re-corrés los tests.
El resultado (texto final del agente) vuelve como tool result; el harness reporta
subagent_tokens / tool_uses / duration_ms en la notificación → medición de costo exacta.
run_in_background: true para no bloquear (llega notificación al terminar).
Paralelismo sin colisión — isolation: "worktree":
Cada dev en su propio git worktree → NO necesitás declarar "archivos disjuntos" (lo resuelve
el aislamiento). Auto-limpiado si no cambió. Coste ~200-500ms + disco por agente: úsalo SOLO
cuando varios devs mutan archivos a la vez; para tareas secuenciales, omitilo.
Reintento tras FAIL — SendMessage al MISMO dev (conserva contexto):
SendMessage({ to: "<agentId>", summary: "gate FAIL: cyclomatic 12>10",
... "extraé helpers, no toques los tests, re-corré node --test" })
Más barato que un Agent nuevo: el dev ya tiene el contexto de la tarea; solo le pasás el
feedback del gate. (En pm-glm-ccdd cada retry re-lanzaba GLM re-enviando toda la spec.)
Fan-out determinista — tool Workflow (requiere opt-in explícito del usuario/ultracode):
Encodeá el pipeline como script: pipeline(tareas, stagePM, stageDev, stageVerify) con
agent(prompt, {model:"haiku", isolation:"worktree", effort:"low"}); parallel() para
verificación adversarial (N escépticos por hallazgo). El tiering se expresa por-agente con
model: y effort: (low mecánico, high/max oráculo difícil).
Flujo
Triage (Haiku) → clasifica y decide si hay trabajo.
Delegar impl (Haiku, Agent; worktree si hay paralelo) → el dev implementa contra los tests.
Verificar (orquestador): re-corré los tests + measure_complexity/run_integration_gate.
FAIL → SendMessage al mismo dev con el error (máx 2; a la 3ª subdividí).
Integrar + reportar; suite completa 2×; commit por batch verificado.
Diferencias clave vs pm-glm-ccdd (v1)
v1 (GLM/Ollama)
v2 (nativo)
Dev
GLM externo (ollama launch)
sub-agente Agent (Haiku)
Paralelo sin colisión
declarar archivos disjuntos (manual)
isolation:"worktree" (automático)
Reintento
relanzar GLM (re-envía spec)
SendMessage (conserva contexto)
Costo del dev
pool EXTERNO de GLM (fuera del presupuesto de tu sesión)
tokens Haiku EN tu sesión (medidos exactos)
Fragilidad
< /dev/null, MCP mínimo, ventanas de cuota, arranques escalonados
ninguna de esas (nativo)
Medición de costo
opaca (externa)
exacta (subagent_tokens en la notificación)
Trade-off honesto: v2 gana en robustez, worktree y retries con contexto, y mide el costo con
precisión; pero el costo del dev se paga en el presupuesto de tokens de tu sesión (no un pool
externo). Si el dataset de tareas es enorme y GLM externo sale más barato por token, v1 puede ganar
en costo bruto; v2 gana en fiabilidad y ergonomía. Decidilo por A/B (el gate es el juez).
Todo lo demás (idéntico a pm-glm-ccdd)
Plantilla de spec, red-team del HECHO, RECON, política de reintentos/timeouts, verify-by-artifact,
suite 2x anti-flaky, "el orquestador corre el gate", y memoria compartida cq-git (query en el paso 0
del PLAN; el conocimiento viaja en la spec, nunca como tools del subagente; FAIL→PASS no obvio =
candidato a KU; confirm/flag para cerrar el loop; cq no relaja el gate): ver
pm-glm-ccdd. Esta skill NO los reescribe; solo cambia el mecanismo de delegación.
Lecciones del gate CCDD (verificado, demo en repo TypeScript)
Redactar el contrato formal toma varias vueltas de lint_task_contract: exige, además de
los campos obvios (task/intent/target/signature), los campos budget/tests/
test_command en el frontmatter, y 7 secciones en un ORDEN CANÓNICO específico (## Intent,
## Interface, ## Invariants, ## Examples, ## Do / Don't, ## Tests, ## Constraints —
Tests va DESPUÉS de Do/Don't, no antes). No lo escribas de memoria: mandá un primer intento
mínimo y corregí contra los findings que devuelve; es más rápido que adivinar el formato completo.
check_signature es AST puro y asume Python: a diferencia de lint_task_contract y
measure_complexity, su schema NO tiene parámetro language — devuelve {"mismatch": "parse error"}
en TS/JS/otros lenguajes. En repos no-Python, la verificación de firma dentro del paso 5 (Verificar)
queda limitada a lint_task_contract (que sí valida firma "por aridad genérica" para lenguajes sin
parser nativo) + measure_complexity; no uses check_signature como parte del veredicto fuera de Python.
Gate sin MCP: Nivel 1 de KDD (verificado, demo con el template real)
Si el repo es un KDD instanciado (scripts/validate_contracts.py
knowledge/contracts/ presentes), el paso 3 (contrato + lint) y el paso 5 (verificar) tienen una vía
SIN MCP, más portable que lint_task_contract/measure_complexity:
Contrato en knowledge/contracts/<task>.md con el esquema completo de KDD: frontmatter OKF
(type/title/description/tags) + campos CCDD + tests_sha256 obligatorio (sellado con
python scripts/validate_contracts.py --hash <ruta-tests> — congela el archivo de tests; si alguien
lo edita después, el hash no matchea y el validador lo marca en rojo).
Lint/veredicto: python scripts/validate_contracts.py knowledge/contracts + el test_command del
contrato, ambos en verde. Escrito con el esquema completo desde el principio, pasó en la primera
pasada (sin las vueltas de iteración que sí hacen falta contra lint_task_contract).
Diferencia real: sin el MCP (solo Nivel 1), el budget del frontmatter es DECLARATIVO — el
validador solo chequea que esté presente, no lo hace cumplir. El enforcement real de complejidad
sigue siendo trabajo de measure_complexity/run_integration_gate (Nivel 2, con MCP). Si el MCP
está disponible, seguí usándolo para esa parte — no es sustituible por Nivel 1 solo.
Esto NO reemplaza el paso 4 (Delegar impl): el implementador sigue siendo un dev nativo (Haiku/Opus
vía Agent), no cambia por tener KDD instanciado — el gate solo cambia CÓMO se verifica.
