Pipeline del Orquestador (motor compartido)

¿Qué hace Pipeline del Orquestador (motor compartido)?

Las habilidades orch-* son envoltorios ligeros. No reimplementan ningún trabajo — clasifican la solicitud, eligen qué fases de este pipeline se ejecutan y delegan cada fase a un agente o comando ECC existente. Este archivo es ese pipeline.

Invoca una habilidad de operación (orch-add-feature, orch-fix-defect, …) en lugar de este motor directamente. Este archivo es la referencia a la que apuntan.

Cuándo usarlo

• Se carga indirectamente siempre que se ejecuta una habilidad de operación orch-*.
• Se lee directamente solo al agregar una nueva operación a la familia o ajustar las fases, compuertas o mapa de agentes compartidos.

La familia de operaciones

Habilidad	Operación	Disparador	Primer movimiento
orch-add-feature	característica	la capacidad aún no existe	investigar + planificar un nuevo segmento
orch-change-feature	ajuste	funciona, pero el comportamiento deseado difiere	modificar el comportamiento existente y sus pruebas
orch-fix-defect	corrección	roto; el comportamiento es incorrecto	reproducir como una prueba fallida, luego corregir
orch-refine-code	refactorización	el comportamiento se mantiene, la estructura mejora	reestructurar manteniendo las pruebas verdes
orch-build-mvp	mvp	arrancar desde un documento de diseño/especificación	ingerir documento → segmentos verticales

Estos envoltorios componen comandos ECC existentes en lugar de reemplazarlos: /feature-dev, /plan, /code-review, /build-fix, /refactor-clean, y /gan-build, además de la habilidad tdd-workflow. La familia orch-* agrega el clasificador de tamaño compartido y las dos compuertas sobre ellos, de modo que un paraguas cubre las cinco operaciones de manera consistente.

Paso 0 — Clasificar tamaño (dimensionamiento correcto)

La ceremonia se escala según el radio de explosión. Puntúa la solicitud en tres señales, toma el nivel más alto que alcance cualquier señal y expresa el resultado en una línea para que el usuario pueda anularlo:

Nivel	Archivos tocados	Nueva dependencia / contrato	Ambigüedad de diseño	Fases que se ejecutan
trivial	1, unas pocas líneas	ninguna	ninguna — el cambio es obvio	4 → 5 → 6
pequeño	1 archivo / 1 función	ninguna	claro una vez que lees el código	(1 ligera) → 4 → 5 → 6
estándar	2–5 archivos	tal vez un nuevo módulo interno	una decisión real que tomar	1 → 2 → 4 → 5 → 6
grande	muchos / transversales	nueva dependencia externa, API pública o un documento de especificación	múltiples preguntas abiertas	1 → 2 → (3) → 4 → 5 → 6

La fase 0 (Admisión) siempre se ejecuta y se omite de la columna de máscara anterior. El desempate: cualquier cosa que toque un disparador de seguridad (a continuación) o una API / contrato público es al menos estándar, independientemente del número de archivos.

Las fases

Cada fase delega — no realiza el trabajo en línea.

• 0. Admisión — reformular la solicitud. Para orch-build-mvp, leer el documento de especificación/diseño y extraer el alcance, las decisiones cerradas y una lista de características.
• 1. Investigación y Reutilización — según rules/common/development-workflow.md: gh search repos / gh search code, luego Context7 / documentos del proveedor, luego registros de paquetes, luego Exa. Preferir adoptar una implementación probada en lugar de código completamente nuevo.
• 2. Planificar — delegar al agente planner (o architect / code-architect para decisiones estructurales). Generar una task_list ordenada como segmentos verticales delgados. → COMPUERTA 1.
• 3. Andamiaje — solo orch-build-mvp: levantar el primer segmento completo.
• 4. Implementar (TDD) — impulsar cada tarea a través del agente tdd-guide (o la habilidad tdd-workflow): rojo → verde → refactorizar. Respetar la regla de primer movimiento de la operación.
• 5. Revisar — agente code-reviewer / /code-review. Agregar security-reviewer cuando el diff toque un disparador de seguridad (a continuación).
• 6. Confirmar — confirmaciones convencionales (feat: / fix: / refactor: / …), una por fragmento lógico. → COMPUERTA 2.

Las dos compuertas

Esta familia es con compuertas, no autónoma:

1. COMPUERTA 1 — después de Planificar. Presentar la task_list; no escribir código de implementación hasta que el usuario lo apruebe.
2. COMPUERTA 2 — antes de Confirmar. Presentar el resumen del diff y los mensajes propuestos; no confirmar hasta que el usuario lo confirme.

Todo entre las compuertas fluye sin detenerse.

Mapa de agente / comando

Fase	Principal	Alternativa / escalada
Admisión / comprender	code-explorer	rastrear rutas existentes antes de un ajuste, corrección o refactorización
Planificar	planner	architect, code-architect para decisiones estructurales
Implementar	tdd-guide (o habilidad tdd-workflow)	build-error-resolver / /build-fix en fallos de compilación
Revisar	code-reviewer / /code-review	revisor de lenguaje (python-reviewer, typescript-reviewer, …)
Seguridad	security-reviewer	—
Bucle interno MVP	/gan-build "<breve>" --skip-planner	impulsa gan-generator → gan-evaluator; ajustar --max-iterations / --pass-threshold

Emparejar el revisor de lenguaje con el repositorio (consultar el CLAUDE.md propio del repositorio).

Disparador de revisión de seguridad

Incluir security-reviewer cuando el diff toque cualquiera de: autenticación o autorización, manejo de entrada del usuario, consultas de base de datos, rutas del sistema de archivos, llamadas a API externa, criptografía o secretos / credenciales. (Según rules/common/security.md).

Artefactos de traspaso

El pipeline no transporta estado oculto — los documentos de planificación son el traspaso:

• task_list (de Planificar) impulsa el bucle de Implementar.
• El trabajo más grande también puede generar PRD / arquitectura / diseño_del_sistema bajo el docs/ del repositorio según rules/common/development-workflow.md.
• Los hallazgos de la revisión (CRÍTICO / ALTO) deben resolverse antes de la Compuerta 2.

Verificación

• se indicó el nivel de tamaño y coincidió con el trabajo
• se respetaron tanto la Compuerta 1 (plan) como la Compuerta 2 (confirmación)
• security-reviewer se ejecutó si y solo si se tocó un disparador de seguridad
• las confirmaciones son convencionales y están limitadas a un cambio lógico
• el comportamiento nuevo / modificado tiene pruebas; cobertura ≥ 80% según rules/common/testing.md