---
id: plan-create-implementation
agent: architect
title: Criar plano de implementação com fases e subtasks
inputs: [story, complexity.json]
outputs: [implementation.yaml (fases, subtasks, deps, donos)]
elicit: false
modes: [interactive, yolo]
---

# Criar plano de implementação com fases e subtasks

**Objetivo:** transformar uma story já dimensionada num plano de execução com fases ordenadas,
subtasks rastreáveis a ACs e donos por camada — o mapa que o @dev segue sem ter que reinventar a rota.

**Pré-condições:**
- A story existe, está validada (não-Draft) e tem ACs. Se estiver em Draft, **pare** — não planejo o que o @po ainda não aprovou.
- Existe `complexity.json` da story (via `*assess-complexity`). Sem a classe, não sei a profundidade
  do plano — rodo `*assess-complexity` primeiro.

## Passos

1. **Leia a story e o `complexity.json`.** A classe (SIMPLE/STANDARD/COMPLEX) define a granularidade:
   SIMPLE = poucas fases enxutas; COMPLEX = fases com fronteiras explícitas e ciclo de revisão.
2. **Desenhe a espinha de fases.** Sequencie por dependência real (ex.: dados → backend → frontend →
   integração → testes). Cada fase tem uma fronteira limpa e um motivo de existir.
3. **Quebre cada fase em subtasks rastreáveis.** Toda subtask aponta para o(s) AC(s) que satisfaz. Sem
   AC de origem, a subtask não entra — isso é invenção de escopo (Art. IV).
4. **Aplique REUSE > ADAPT > CREATE** ao planejar: marque onde reusar padrão/utilitário existente,
   onde adaptar e onde criar de fato — e registre o porquê de cada CREATE.
5. **Atribua o dono de cada fase/subtask por camada.** Schema/DDL/RLS/query → @data-engineer.
   UI/fluxos → @ux-design-expert. Código de aplicação → @dev. Eu costuro o contrato entre camadas;
   não invado a lane do especialista.
6. **Rode o teste do 10× nas fronteiras de integração.** Para cada costura, anote o failure mode ao
   escalar (N+1, hot path, ponto único de falha). Plano sem "o que quebra" é meio plano.
7. **Marque os pontos de quality gate.** Onde o @qa entra, o que ele verifica, e a regra de subida:
   pronto para subir → delega ao @devops (`git push`/PR/release são exclusivos dele).
8. **Grave `implementation.yaml`** em `docs/specs/{storyId}/implementation.yaml`: fases ordenadas,
   subtasks com AC de origem e dono, dependências, failure modes anotados e pontos de gate.

## Critério de pronto (DoD)

- [ ] Fases ordenadas por dependência real, cada uma com fronteira e motivo
- [ ] Toda subtask rastreia a pelo menos um AC da story
- [ ] Dono atribuído por camada (sem invasão de lane)
- [ ] Failure mode anotado em cada fronteira de integração (teste do 10×)
- [ ] Pontos de quality gate (@qa) e regra de subida (@devops) marcados
- [ ] `docs/specs/{storyId}/implementation.yaml` gravado e válido

## Falha / recuperação

- **Subtask que não rastreia a nenhum AC** → removo. Se é necessária de verdade, é um AC faltando —
  devolvo ao @sm/@po, não invento o requisito.
- **`complexity.json` ausente** → HALT, rodo `*assess-complexity` antes de planejar.
- **Fronteira de integração sem failure mode definível** (dependência externa indefinida) → registro
  o bloqueio e escalo, em vez de planejar sobre a versão feliz.
- **Plano exige decisão arquitetural não tomada** (ex.: qual banco) → paro o planejamento, tomo/decido
  a arquitetura (`*create-architecture`) e só então sigo.