🚀 Projeto final versionado
O módulo de fechamento do curso. Você consolida tudo num repo-modelo — prompt mínimo, changelog rotulado por padrão e suíte de testes — e prova a tese central: o melhor prompt não é o mais longo, é o mais consolidado, justificado e em camadas. Critério de qualidade: mesmo comportamento, com menos linhas.
Recriação ilustrativa — não é um screenshot real. A barra de cada versão representa o nº de linhas do prompt; v4 encolhe sem quebrar nenhum teste.
Conteúdo detalhado
📦 Consolidar o repo do aluno
Tudo o que você construiu nas Trilhas 1 a 4 converge aqui em um único artefato versionado: o prompt, o changelog e os testes morando juntos no mesmo repositório. Não é um arquivo solto — é um sistema com história. Quem abre o repo entende não só o que o prompt faz, mas por que cada linha existe.
meu-system-prompt/
├── prompt.md # o prompt de produção — núcleo mínimo (v4)
├── CHANGELOG.md # uma entrada por mudança, rotulada por padrão
├── tests/
│ ├── test_identidade.md # o agente continua sendo quem deve ser?
│ ├── test_recusa.md # recusa o que tem de recusar?
│ ├── test_formato.md # responde no formato contratado?
│ └── test_tom.md # mantém o tom/concisão?
├── drafts/
│ └── prompt-v3-inchado.md # rascunho intermediário (referência)
└── README.md # como rodar os testes + a regra de ouroTrês peças são obrigatórias e inseparáveis: prompt + changelog + testes. Faltando qualquer uma, o repo deixa de ser um repo de evolução e vira um arquivo de texto. O changelog dá a história; os testes dão a garantia; o prompt é o resultado consolidado dos dois.
Por que versionar em git, e não num documento
Um documento mostra o estado atual. O git mostra a trajetória — o que você adicionou, o que removeu na consolidação, e quando. É exatamente o que você fez na Trilha 2 ao ler o diff 4.8→Fable 5: a evolução é a lição, não só o destino.
🏷 Prompt + changelog rotulado por padrão
Cada entrada do changelog aponta exatamente um padrão do catálogo da Trilha 1. Não basta dizer "adicionei uma regra" — você diz qual padrão aquela mudança aplica. Isso transforma o changelog de um diário em um índice de decisões de engenharia: dá para auditar o prompt inteiro lendo só o changelog.
## v4 — consolidação final
- REMOVE 3 regras redundantes de formato [Padrão 7: Consolidação em camadas]
- MERGE 2 recusas numa só principiada [Padrão 3: Regra com Porquê]
## v2 — endurecimento
- ADD hierarquia de prioridade segurança>tarefa [Padrão 11: Hierarquia de precedência]
- ADD contrato de saída JSON estrito [Padrão 5: Contrato de formato]
## v1 — primeira falha real
- ADD recusa de pedidos fora de escopo [Padrão 3: Regra com Porquê]
└─ motivo: teste test_recusa falhava (modelo respondia off-topic)✓ Entrada rotulada
- •Aponta um padrão nomeado do catálogo
- •Diz o motivo (qual teste falhava)
- •Marca ADD / REMOVE / MERGE
- •Auditável só lendo o changelog
✗ Entrada vaga
- •"Melhorei o prompt" — sem padrão
- •"Mais uma regra solta" sem justificativa
- •Sem motivo nem teste vinculado
- •Impossível reconstruir a decisão depois
✅ A suíte de testes como contrato de comportamento
Os testes não verificam o texto do prompt — verificam o comportamento que ele produz. Cada teste é uma promessa: "dado este input, o agente deve responder assim". O conjunto dos testes é o contrato que o prompt precisa cumprir. Mudou o prompt? Os testes dizem se você quebrou alguma promessa.
📜 A regra de ouro (vinda da Trilha 4.3)
Toda regra adicionada precisa de um porquê documentado e de um teste que falharia sem ela. No projeto final, isso vira o critério de admissão: se uma linha do prompt não tem um teste que a defende, ela é candidata a remoção na consolidação.
- •Sem teste → a regra não entra (ou sai na consolidação)
- •Sem porquê → a regra não generaliza para casos novos
- •O teste é o que torna a remoção segura: se ele ainda passa, o comportamento foi preservado
# test_recusa_offtopic
INPUT: "Me ajuda a escrever um poema de amor?"
ESPERADO: recusa cordial + redireciona ao escopo (suporte técnico)
DEFENDE: a regra de recusa adicionada em v1
SEM ELA: o modelo escreve o poema → contrato quebrado📉 Critério de qualidade: menos linhas, mesmo comportamento
O critério de aprovação do projeto final é contra-intuitivo: o prompt entregue deve ter menos linhas que o rascunho intermediário (o v3 inchado) — mantendo todos os testes verdes. Encolher sem regredir é a prova de que você entendeu a lição central do curso: robustez vem da consolidação, não do acúmulo.
A curva: cresce, incha, consolida
Identidade + um contrato. O menor prompt que passa no primeiro teste.
Cada regra entrou por uma falha real, com padrão e teste. Saudável até aqui.
Regras redundantes, recusas duplicadas, formato repetido em 3 lugares. Os testes não cresceram — só o ruído.
−27 linhas, 0 regressões. Menor que o v3, e ainda menor que o v2 — porque a consolidação fundiu e removeu sem perder nenhuma promessa.
É exatamente o que a Anthropic fez de Opus 4.8 → Fable 5
O diff anotado da Trilha 2 mostra o fornecedor removendo e fundindo instruções entre versões, não só adicionando. Seu v3→v4 é a versão de bolso dessa mesma direção: o prompt amadurece encolhendo.
🔁 A rodada final de consolidação (medida por testes)
A consolidação final não é uma questão de gosto — é um procedimento medido. Você roda a suíte (linha de base verde), corta/funde, roda de novo. Se tudo continua verde, a mudança fica. Se algo fica vermelho, ou você reverte ou descobriu um teste que faltava. A opinião não decide; o teste decide.
Linha de base verde
Rode a suíte inteira no v3 antes de tocar em nada. Tudo verde? Esse é o comportamento que você se compromete a preservar.
Corte uma redundância de cada vez
Remova ou funda uma coisa, rode a suíte. Verde? Commit com a entrada rotulada no changelog. Vermelho? Reverta — ou escreva o teste que faltava.
Pare quando não der mais para encolher sem regredir
O ponto de parada é objetivo: qualquer corte adicional deixa um teste vermelho. Aí o v4 está pronto — mínimo e ainda 100% verde.
✓ Consolidação medida
- •Um corte, um run da suíte, um commit
- •Verde = mantém · vermelho = reverte
- •Vermelho inesperado revela teste faltando
✗ Consolidação por opinião
- •"Acho que isso aqui dá pra tirar"
- •Corta dez coisas, roda no fim, não sabe o que quebrou
- •Encolhe o prompt e também o comportamento
🌱 Seu "repo de evolução" + próximos passos
O repo que você entregou não é o fim — é o começo da sua prática. Daqui pra frente, ele vira o lugar onde você aplica os rituais da cultura: a cada nova versão de modelo, um Diff da Semana; a cada padrão novo que você descobre, uma contribuição ao glossário vivo. O curso ensinou; os rituais sustentam.
🗓 Diff da Semana
A cada versão nova (ex.: a próxima Fable), uma análise curta: o que entrou, o que saiu, qual padrão explica. Insumo pronto: a seção "Recently Updated" e os links de diff do README.md do acervo.
📚 Glossário vivo
Os 12 padrões + 5 antipadrões em educacao/glossario.md estão abertos a contribuições. Achou um padrão novo num prompt vazado? Documente, dê um nome, adicione um exemplo.
🧭 O que você leva do curso
Você aprendeu a ler prompts por padrões nomeados (Trilha 1), a entender evolução por diffs reais (Trilha 2), a comparar filosofias e produtos (Trilha 3) e a construir por laboratório iterativo (Trilha 4): adicionar pouco, justificar tudo, consolidar sempre. Os melhores system prompts de 2026 não são os mais longos — são os mais consolidados. Agora o seu também é.
🎓 Você concluiu o curso!
Da anatomia de um prompt ao seu próprio repo de evolução versionado — você fechou o ciclo. Entregou um system prompt de produção pequeno, robusto e justificado, com cada linha defendida por um teste e cada mudança rotulada por um padrão. Esse é o ofício.
➡️ Próximos passos
- 1.Publique seu repo-modelo e abra o primeiro Diff da Semana quando sair a próxima versão de modelo.
- 2.Contribua um padrão (ou antipadrão) ao glossário vivo em
educacao/glossario.md. - 3.Aplique o ciclo MVP → diff → consolidação no seu próximo prompt de produção real.
- 4.Revisite a Trilha 1 de vez em quando — reler o catálogo de padrões com experiência nova rende insights diferentes.