Pipeline do Orquestrador (motor compartilhado)

As skills orch-* são invólucros simples. Elas não reimplementam nenhum trabalho — elas classificam a solicitação, escolhem quais fases deste pipeline executar e delegam cada fase a um agente ou comando ECC existente. Este arquivo é esse pipeline.

Invoque uma skill de operação (orch-add-feature, orch-fix-defect, …) em vez deste motor diretamente. Este arquivo é a referência para onde elas apontam.

Quando Usar

• Carregado indiretamente sempre que uma skill de operação orch-* é executada.
• Lido diretamente apenas ao adicionar uma nova operação à família ou ao ajustar as fases, portões ou mapeamento de agentes compartilhados.

A família de operações

Esses invólucros compõem comandos ECC existentes em vez de substituí-los: /feature-dev, /plan, /code-review, /build-fix, /refactor-clean e /gan-build, mais a skill tdd-workflow. A família orch-* adiciona o classificador de tamanho compartilhado e os dois portões sobre eles, de modo que um guarda-chuva cubra as cinco operações de forma consistente.

Etapa 0 — Classificar tamanho (dimensionamento correto)

A cerimônia escala para o raio de explosão. Pontue a solicitação em três sinais, pegue o nível mais alto que qualquer sinal atingir e declare o resultado em uma linha para que o usuário possa substituir:

A Fase 0 (Entrada) sempre é executada e é omitida na coluna de máscara acima. O desempate: qualquer coisa que toque um gatilho de segurança (abaixo) ou uma API pública / contrato é pelo menos padrão, independentemente da contagem de arquivos.

As fases

Cada fase delega — ela não faz o trabalho em linha.

• 0. Entrada — reafirme a solicitação. Para orch-build-mvp, leia o documento de especificação/design e extraia o escopo, as decisões travadas e uma lista de recursos.
• 1. Pesquisa e Reutilização — por rules/common/development-workflow.md: gh search repos / gh search code, depois Context7 / documentação do fornecedor, depois registros de pacotes, depois Exa. Prefira adotar uma implementação comprovada em vez de código totalmente novo.
• 2. Planejar — delegar ao agente planner (ou architect / code-architect para decisões estruturais). Produzir um task_list ordenado como fatias verticais finas. → PORTÃO 1.
• 3. Estruturar — orch-build-mvp apenas: configurar a primeira fatia ponta a ponta.
• 4. Implementar (TDD) — conduzir cada tarefa através do agente tdd-guide (ou da skill tdd-workflow): vermelho → verde → refatorar. Honrar a regra de primeiro movimento da operação.
• 5. Revisar — agente code-reviewer / /code-review. Adicionar security-reviewer sempre que a diferença tocar um gatilho de segurança (abaixo).
• 6. Confirmar — commits convencionais (feat: / fix: / refactor: / …), um por bloco lógico. → PORTÃO 2.

Os dois portões

Esta família é controlada por portões, não autônoma:

1. PORTÃO 1 — após Planejar. Apresentar o task_list; não escrever código de implementação até que o usuário aprove.
2. PORTÃO 2 — antes de Confirmar. Apresentar o resumo da diferença e as mensagens propostas; não confirmar até que o usuário confirme.

Tudo entre os portões flui sem parar.

Mapeamento de Agente / Comando

…