Fluxo, medição e entrega final

Projeto final: uma entrega com rastreabilidade

Projeto 8 min de leitura 2h de prática Você leva: Dossiê da feature (plano, diff, testes, review, retrospectiva)

Executar uma feature pequena aplicando tudo — plano, ciclos curtos, revisão, documentação e retrospectiva — avaliada por uma rubrica objetiva.

O projeto não mede se você escreveu muito código com IA. Mede se cada decisão da sua entrega tem motivo e prova.

Ao final desta aula você consegue

Aplicar o fluxo completo do curso em uma entrega real.
Produzir um dossiê que outra pessoa consiga auditar.
Escrever o seu playbook pessoal a partir do que funcionou.

Escopo

Escolha uma feature que você concluiria em até duas horas sem IA: um endpoint simples, uma validação, um relatório pequeno, um componente isolado. Escopo grande arruína o exercício, porque o registro vira resumo e o valor está no detalhe.

Precisa ser código real, num repositório real. Projeto inventado não produz as fricções que o curso trata.

As seis etapas

Mapa de decisões (módulo 2): requisito original, ambiguidades, o que você decidiu, o que perguntou, o que ficou como risco.
Critérios de aceite observáveis, com números, em Dado/Quando/Então.
Ciclos curtos (módulo 3): pelo menos três, cada um com teste que falhou antes, diff e prova de detecção por sabotagem.
Revisão por categorias (módulo 4): as oito categorias, com a classificação dos achados em verdadeiro/falso positivo.
Documentação (módulo 5): o que a próxima pessoa precisa saber, com fontes fechadas.
Retrospectiva: tempo estimado × real, o que a IA acelerou, o que atrapalhou, e ao menos uma sugestão que você recusou com o motivo.

Você leva daquiDossiê da feature

Um documento único que reúne as seis etapas. É o artefato que prova o processo — e o modelo que você reutiliza nas próximas entregas.

# Dossiê — [nome da feature]
Autor: [nome] · Período: [datas] · Repositório: [link]

## 1. Mapa de decisões
[requisito original sem edição]
[decisões técnicas · decisões de produto respondidas · riscos assumidos]

## 2. Critérios de aceite
- Dado [...], quando [...], então [...] (número concreto)

## 3. Ciclos
### Ciclo 1 — [regra]
- Teste antes · mensagem de falha esperada × obtida
- Diff: [n] linhas em [arquivos]
- Sabotagem aplicada · teste ficou vermelho? [sim/não]
- O que recusei da sugestão e por quê
(repetir para os ciclos 2 e 3)

## 4. Revisão
| Categoria | Achados | VP | FP | Ação |
|-----------|---------|----|----|------|
| Correção | | | | |
| Autorização | | | | |
| Exposição de dados | | | | |
| Injeção | | | | |
| Concorrência | | | | |
| Performance | | | | |
| Observabilidade | | | | |
| Testes | | | | |

## 5. Documentação
[o que escrevi · fontes usadas · lacunas marcadas]

## 6. Retrospectiva
- Estimado: [x]h · Real: [y]h
- Acelerou: [onde, concretamente]
- Atrapalhou: [onde, concretamente]
- Sugestão que recusei: [qual e por quê]
- Vai para o meu CONTEXT.md: [o que aprendi sobre onde o assistente erra aqui]

## 7. Playbook pessoal
[3 a 5 regras que eu passo a seguir por padrão]

Onde guardar: docs/dossies/[feature].md no repositório, ou anexado ao pull request.

Rubrica de avaliação

Critério	Insuficiente	Adequado	Forte
Decisões	Não registradas	Registradas	Com alternativa descartada e reversibilidade
Critérios	Subjetivos	Observáveis	Com números e fronteiras
Ciclos	Um bloco só	Três ciclos	Cada um com prova de detecção
Revisão	Aceita tudo	Classifica achados	Rejeita falso positivo com evidência
Documentação	Ausente	Existe	Fontes fechadas, lacunas marcadas
Retrospectiva	Só elogio	Ganhos e perdas	Inclui recusa fundamentada e virou regra

A coluna "Forte" tem um padrão: em todas as linhas, ela exige que você mostre o que não fez e por quê. É isso que separa quem usa a ferramenta de quem é usado por ela.

Mão na massa120 min

Entregar a feature e o dossiê completo.

Escolha a feature e registre a estimativa antes de começar.
Execute as seis etapas na ordem, preenchendo o dossiê conforme avança — não no final, de memória.
Abra o pull request usando o template do módulo 5.
Peça revisão humana e registre o que ela pegou que a revisão assistida não pegou.
Feche a retrospectiva com números reais.
Escreva o playbook: 3 a 5 regras suas, não do curso.

Deu certo quando

A feature está mergeada ou pronta para merge.
Os três ciclos têm prova de detecção registrada.
Existe ao menos uma sugestão recusada com motivo escrito.
A retrospectiva compara estimativa registrada antes com o tempo real.
O playbook tem regras suas, específicas do seu contexto.

Se travar: Se você não encontrou nenhuma sugestão para recusar, provavelmente a revisão foi superficial ou o escopo foi trivial demais. Volte ao diff e pergunte, de cada trecho: eu escreveria assim? Se a resposta for "não sei", esse trecho não foi revisado.

O que fica depois do certificado

O certificado prova que você passou na avaliação. O que muda o seu trabalho são os cinco artefatos: o CONTEXT.md, a regra pessoal de uso, o mapa de decisões, o checklist de review calibrado e o template de PR.

Todos eles têm a mesma natureza — decisões tomadas uma vez, escritas, e reutilizadas. É esse o processo repetível que o curso queria construir.

Em uma frase

Uma entrega madura mostra o que foi recusado e por quê — não só o que foi aceito.

← Aula anterior Voltar ao curso →

Comentários e dúvidas

Inscreva-se grátis para comentar, tirar dúvidas, marcar seu progresso e emitir o certificado ao fim do curso.

Inscrever-se grátis com Google

Ainda não há comentários nesta aula.