Lição 5 de 8: Escrever o plano da fatia 1

O plano que virou diário

Antes de qualquer regra, olhe um plano real. Este é o começo do plans/feat-tcu-guide-tab.md do CEAP, com 306 linhas, escrito antes de a página /guia-tcu existir (vista na L01):

# feat: Add TCU Guide Tab ("Guia TCU")

> New dashboard tab designed as a presentation-ready walkthrough
> for TCU auditors, doubling as a permanent reference.

## Overview

The TCU's coLAB-i team is meeting with us to see the "Onde Foi
Parar a Cota" dashboard. This tab serves three purposes:

1. Presentation guide — Walk TCU folks through the tool
2. Permanent reference — After the meeting, entry point
3. Bridge to collaboration — Soft path to structured support

The tone is straightforward and friendly — we're sharing
something useful, not selling.

## Problem Statement / Motivation

The meeting feedback says:
- Explain how the tool was created
- Explain the data sources (Dados Abertos da Câmara)
- Give an overview of what the tool generates
- Open for questions

Cinco seções fazem esse plano funcionar como input pro /work no M3. Você vai aprender quais são. O trecho acima já mostra três delas em ação: Context, Goal implícito, e Acceptance vindo de feedback explícito.

As 5 seções de um plano de feature: Context, Goal, Out of scope, Acceptance criteria, Task listLayout vertical de plano feat-*.md mostrando 5 seções empilhadas: Context (arquivos e decisões que importam), Goal (o que a fatia entrega em 1 frase), Out of scope (o que NÃO entra nesta fatia), Acceptance criteria (asserções sim/não verificáveis), Task list (tarefas em ordem de execução).

As 5 seções

A forma do plano é a mesma dos planos do próprio Builder OS (feat-builder-os-foundation.md, feat-builder-os-phase-3-landing-and-hook.md) e do CEAP acima.

Passo 1: Claude propõe o draft

Claude já tem o nome do arquivo (commit da L04), o brief (docs/product.md) e o roadmap (docs/roadmap.md). Junte tudo.

Leia estes 3 arquivos do projeto, nessa ordem:

1. `docs/product.md`: o brief do produto
2. `docs/roadmap.md`: as 3 fatias verticais (foco na fatia 1)
3. `plans/[NOME_DO_PLANO].md`: o nome decidido na L04

Com base nos três, escreva o conteúdo do `plans/[NOME_DO_PLANO].md` com 5 seções, exatamente nessa ordem:

## Context

2 a 4 frases descrevendo o que existe hoje no projeto que importa para esta fatia. Aponte arquivos relevantes (`CLAUDE.md`, `docs/product.md`), decisões já tomadas, dependências.

## Goal

Uma única frase descrevendo o que esta fatia entrega ao usuário, derivada da entrega da fatia 1 do roadmap.

## Out of scope

3 a 5 bullets do que parece óbvio que entra mas explicitamente não entra nesta fatia. Inclua pelo menos 1 item que vem dos Não-objetivos do `docs/product.md` e pelo menos 1 que é uma feature da fatia 2 ou 3.

## Acceptance criteria

4 a 6 bullets verificáveis (que dão para testar sim/não). Cada um derivado do nome do arquivo e do que está no escopo. Inclua pelo menos 1 critério de performance com número (ex: "PDF em menos de 2 segundos").

## Task list

5 a 12 tarefas em ordem de execução. Cada tarefa equivale a aproximadamente 1 PR ou 1 commit. Granularidade clara: não "construir backend" mas "schema da tabela X com campos Y/Z." Marque dependência quando importante (ex: "depende de #2").

**Mostre o diff antes de aplicar.** Não escreva outros arquivos, apenas preencha o `[NOME_DO_PLANO].md`.

Claude responde com o conteúdo das 5 seções. Não aprove o diff ainda; vá pro Passo 2.

Passo 2: revise o draft

Antes de aprovar, leia com olhar crítico. Os 3 erros mais comuns:

Aprove o diff só quando os 3 erros estiverem resolvidos.

Passo 3: stress-test do Out of scope

Out of scope é a seção que mais economiza tempo durante a implementação. Aplique pra cada item:

"Se eu mostrasse essa fatia pra um usuário real e ele pedisse essa coisa, eu adicionaria ou recusaria?"

• Adicionaria na hora: item mal classificado. Ou já está na fatia 1 (mova pra Acceptance criteria) ou está na fatia 2 (mantenha, mas anote o pedido).
• Recusaria explicando que vem na fatia 2 ou 3: bem classificado.
• Não sei: decida agora, antes de começar.

Pegue cada item da seção Out of scope do meu plano e me ajude a classificar:

- **MANTER:** se um usuário pedir, eu recuso explicando que vem na fatia 2 ou 3 (bem classificado).
- **MOVER PARA ACCEPTANCE:** se um usuário pedir, eu já tenho que entregar nessa fatia (mal classificado).
- **DECIDIR AGORA:** não sei se entrego ou recuso (precisa de decisão antes de começar).

Para cada item, saída: 1 das 3 classificações + 1 frase de motivo.

Se algum item ficou em MOVER PARA ACCEPTANCE, refaça Acceptance criteria. Se algum ficou em DECIDIR AGORA, decida. Quando todos forem MANTER, siga.

Passo 4: aplique o diff e faça o commit

Faça commit do plano preenchido. Stage só `plans/[NOME_DO_PLANO].md`, com mensagem `docs(plans): write [NOME_DO_PLANO] for slice 1`.

Aprove git add e git commit. Confira no GitHub.

Verificação: Claude consegue executar /work em cima do plano?

Você não vai rodar /work agora (isso é o Módulo 3). Apenas peça pra Claude simular o primeiro passo, pra validar que o plano está pronto.

Leia `plans/[NOME_DO_PLANO].md`. Sem executar nada, descreva em até 5 frases:

1. Qual a primeira tarefa que você executaria.
2. Qual arquivo ou diretório seria criado/modificado primeiro.
3. Quais decisões ainda estão ambíguas no plano e que você precisaria me perguntar antes de começar. **Exemplos de ambiguidade real que conta:** "número sequencial é por contador ou global?", "se a API da Receita cair, retry exponencial ou fail-fast?", "validação de CPF entra como middleware ou só na rota?", "PDF é gerado server-side ou client-side?". Se você não encontrar nada nesse nível, responda "nenhuma, o plano está claro" e não force ambiguidade pra parecer crítico.

Se sua resposta na 3 for "nenhuma," ótimo. Se você listar 2 ou mais ambiguidades reais, o plano ainda tem lacunas; me diga quais.

Se Claude responder com a primeira tarefa clara e zero ambiguidades, o plano está pronto. Se listar ambiguidades reais, volte ao Passo 2 e refine antes de fechar a lição.

Build Diary: quando o plano do CEAP "vazou" forma

Voltando ao feat-tcu-guide-tab.md do começo. O plano funcionou: a página foi entregue, a reunião com o coLAB-i aconteceu. Mas a correspondência com as 5 seções desta lição é imperfeita:

Out of scope ficou implícito. Funcionou nesse caso porque o autor tinha o tom claro na cabeça. Mas se outro contribuidor pegasse o plano em 3 meses, teria reinventado escopo. Pra você, que está aprendendo o formato, mantenha as 5 seções separadas e explícitas: fica mais legível pro Claude e pra você revisar daqui a 2 semanas.

Takeaways

• 5 seções (Context, Goal, Out of scope, Acceptance criteria, Task list) são o mínimo pra /work funcionar e cabem numa página revisável.
• Out of scope é a seção que mais economiza tempo durante a implementação: sem ela, Claude expande escopo sozinho.
• Acceptance criteria são asserções sim/não com número quando dá. "Funciona corretamente" não conta.
• Plano que vira diário (TCU plan, 306 linhas) começou com 5 seções e cresceu recebendo o que aconteceu. Você instala isso no M5.

Você terminou quando

O feat-<nome>.md da fatia 1 está commitado com as 5 seções preenchidas, Out of scope tem 3 ou mais itens, e os Acceptance criteria são todos verificáveis.