Motor de canalización de orquestación (compartido)
Las habilidades orch-* son envoltorios ligeros. No reimplementan ningún trabajo —
clasifican la solicitud, eligen qué fases de esta ejecución de canalización se ejecutan
y delegan cada fase a un agente o comando ECC existente. Este archivo es esa canalización.
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 cuando se ejecuta una habilidad de operación
orch-*. - Se lee directamente solo al añadir una nueva operación a la familia o ajustar las fases, puertas o mapa de agentes compartidos.
La familia de operaciones
| Habilidad | Operación | Desencadenante | Primera acción |
|---|---|---|---|
orch-add-feature | feature | la capacidad no existe aún | investigar + planificar un nuevo fragmento |
orch-change-feature | ajuste | funciona, pero el comportamiento deseado difiere | modificar el comportamiento existente y sus pruebas |
orch-fix-defect | arreglo | roto; el comportamiento es incorrecto | reproducir como una prueba fallida, luego arreglar |
orch-refine-code | refactorización | el comportamiento permanece, la estructura mejora | reestructurar mientras se mantienen las pruebas en verde |
orch-build-mvp | mvp | arrancar desde un documento de diseño/especificación | ingerir doc → fragmentos 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 habilidadtdd-workflow. La familia orch-* añade el clasificador de tamaño compartido y las dos puertas sobre ellos, por lo 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 | clara una vez que lees el código | (1 ligera) → 4 → 5 → 6 |
| estándar | 2–5 archivos | quizás un nuevo módulo interno | una elección real que hacer | 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 (Recepción) siempre se ejecuta y se omite en la columna de máscara anterior. El factor de desempate: cualquier cosa que toque un desencadenante de seguridad (abajo) o una API pública / contrato es al menos estándar, independientemente del recuento de archivos.
Las fases
Cada fase delega — no realiza el trabajo en línea.
- 0. Recepción — reformula la solicitud. Para
orch-build-mvp, lee el documento de especificación/diseño y extrae el alcance, las decisiones fijas 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 documentos de Context7 / proveedor, luego registros de paquetes, luego Exa. Prefiere adoptar una implementación probada sobre código nuevo. - 2. Planificar — delegar al agente
planner(oarchitect/code-architectpara decisiones estructurales). Produce unatask_listordenada como fragmentos verticales delgados. → PUERTA 1. - 3. Andamiaje — solo
orch-build-mvp: construir el primer fragmento de extremo a extremo. - 4. Implementar (TDD) — impulsar cada tarea a través del agente
tdd-guide(o la habilidadtdd-workflow): rojo → verde → refactorizar. Respetar la regla de primera acción de la operación. - 5. Revisar — agente
code-reviewer//code-review. Añadirsecurity-reviewersiempre que la diferencia toque un desencadenante de seguridad (abajo). - 6. Confirmar — confirmaciones convencionales (
feat:/fix:/refactor:/ …), una por fragmento lógico. → PUERTA 2.
Las dos puertas
Esta familia está controlada, no es autónoma:
- PUERTA 1 — después de Planificar. Presentar la
task_list; no escribir código de implementación hasta que el usuario lo apruebe. - PUERTA 2 — antes de Confirmar. Presentar el resumen de la diferencia y los mensajes propuestos; no confirmar hasta que el usuario lo confirme.
Todo lo que hay entre las puertas fluye sin detenerse.
Mapa de agentes / comandos
| Fase | Principal | Alternativo / escalada |
|---|---|---|
| Recepción / comprensión | code-explorer | rastrear rutas existentes antes de un ajuste, arreglo o refactorización |
| Planificar | planner | architect, code-architect para llamadas estructurales |
| Implementar | tdd-guide (o habilidad tdd-workflow) | build-error-resolver / /build-fix en errores de compilación |
| Revisar | code-reviewer / /code-review | revisor de lenguaje (python-reviewer, typescript-reviewer, …) |
| Seguridad | security-reviewer | — |
| Bucle interno de MVP | /gan-build "<breve>" --skip-planner | impulsa gan-generator → gan-evaluator; ajustar --max-iterations / --pass-threshold |
Emparejar el revisor de lenguaje con el repositorio (ver el CLAUDE.md del propio repositorio).
Desencadenante de revisión de seguridad
Incluir security-reviewer cuando la diferencia toque cualquiera de: autenticación o
autorización, manejo de entrada de usuario, consultas a bases de datos, rutas del sistema de archivos,
llamadas a API externas, criptografía o secretos/credenciales. (Según rules/common/security.md.)
Artefactos de entrega
La canalización no transporta estado oculto — los documentos de planificación son la entrega:
- La
task_list(de Planificar) impulsa el bucle de Implementar. - El trabajo más grande también puede emitir PRD / arquitectura / diseño_del_sistema en el
docs/del repositorio segúnrules/common/development-workflow.md. - Los hallazgos de la revisión (CRÍTICO / ALTO) deben resolverse antes de la Puerta 2.
Verificación
- el nivel de tamaño fue declarado y coincidió con el trabajo
- la Puerta 1 (plan) y la Puerta 2 (confirmación) fueron respetadas
security-reviewerse ejecutó si y solo si se tocó un desencadenante de seguridad- las confirmaciones son convencionales y están limitadas a un cambio lógico
- el comportamiento nuevo/cambiado tiene pruebas; cobertura ≥ 80% según
rules/common/testing.md