🚀 Proyecto final versionado
El módulo de cierre del curso. Consolidas todo en un repo modelo — prompt mínimo, changelog etiquetado por defecto y suite de pruebas — y demuestra la tesis central: el mejor prompt no es el más largo, sino el más consolidado, justificado y por capas. Criterio de calidad: el mismo comportamiento, con menos líneas.
Recreación ilustrativa — no es una captura de pantalla real. La barra de cada versión representa el número de líneas del prompt; v4 se acorta sin romper ninguna prueba.
Contenido detallado
📦 Consolidar el repo del alumno
Todo lo que construiste en las Rutas 1 a 4 converge aquí en un único artefacto versionado: el prompt, el registro de cambios y las pruebas que conviven en el mismo repositorio. No es un archivo suelto: es un sistema con historia. Quien abre el repo entiende no solo lo que el prompt lo hace, pero por qué existe cada línea.
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 ouroTres piezas son obligatorias e inseparables: prompt + registro de cambios + pruebas. Si falta cualquiera de ellos, el repo deja de ser un repo de evolución y se convierte en un archivo de texto. El changelog cuenta la historia; las pruebas dan la garantía; el prompt es el resultado consolidado de ambos.
Por qué versionar en git y no en un documento
Un documento muestra el estado actual. Git muestra la trayectoria — lo que añadiste, lo que quitaste al consolidar y cuándo. Es exactamente lo que hiciste en la Ruta 2 al leer el diff 4.8→Fable 5: la evolución es la lección, no solo el destino.
🏷 Prompt + registro de cambios etiquetado por defecto
Cada entrada del changelog apunta exactamente un patrón del catálogo de la Ruta 1. No basta con decir «agregué una regla»; dices qué patrón ese cambio aplica. Eso transforma el changelog de un diario en un índice de decisiones de ingeniería: se puede auditar todo el prompt leyendo solo el 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 etiquetada
- •Señala un patrón con nombre del catálogo
- •Dice el motivo (qué prueba fallaba)
- •Marca ADD / REMOVE / MERGE
- •Auditable solo leyendo el changelog
✗ Entrada vaga
- •"Mejoré el prompt" — sin criterios
- •"Otra regla suelta" sin justificación
- •Sin motivo ni prueba vinculada
- •Imposible reconstruir la decisión después
✅ La suite de pruebas como contrato de comportamiento
Las pruebas no verifican el texto del prompt: verifican comportamiento que produce. Cada prueba es una promesa: "dada esta entrada, el agente debe responder así". El conjunto de pruebas es el contrato que el prompt debe cumplir. ¿Cambió el prompt? Las pruebas indican si rompiste alguna promesa.
📜 La regla de oro (proveniente de la Trilha 4.3)
Toda regla que se agrega necesita un porqué documentado y una prueba que fallaría sin ella. En el proyecto final, esto se convierte en el criterio de admisión: si una línea del prompt no tiene una prueba que la justifique, puede eliminarse durante la consolidación.
- •Sin prueba → la regla no se incorpora (o se elimina durante la consolidación)
- •Sin el porqué → la regla no se generaliza a casos nuevos
- •La prueba es lo que hace que la eliminación segura: si todavía lo supera, se preservó el comportamiento
# 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📉 Criterio de calidad: menos líneas, mismo comportamiento
El criterio de aprobación del proyecto final es contraintuitivo: el prompt entregado debe tener menos líneas que el borrador intermedio (la v3 inflada) — manteniendo todas las pruebas en verde. Reducir sin retroceder es la prueba de que entendiste la lección central del curso: la robustez viene de la consolidación, no de la acumulación.
La curva: crece, se hincha, se consolida
Identidad + un contrato. El prompt más pequeño que pasa la primera prueba.
Cada regla se incorporó a partir de un fallo real, con un patrón y una prueba. Hasta ahora, todo bien.
Reglas redundantes, rechazos duplicados, formato repetido en 3 lugares. Las pruebas no aumentaron: solo el ruido.
−27 líneas, 0 regresiones. Menos que v3, y aún menos que v2, porque la consolidación fusionó y eliminó sin perder ninguna promesa.
Es exactamente lo que Anthropic hizo de Opus 4.8 → Fable 5
El diff anotado de la Ruta 2 muestra al proveedor eliminando e fusionando instrucciones entre versiones, no solo agregando. Tu v3→v4 es la versión de bolsillo de esa misma dirección: el prompt madura al hacerse más pequeño.
🔁 La ronda final de consolidación (medida por pruebas)
La consolidación final no es una cuestión de gustos: es un procedimiento medido. Ejecutas la suite (línea de base en verde), recortas/fusionas y vuelves a ejecutarla. Si todo sigue en verde, el cambio se queda. Si algo queda en rojo, reviertes o descubriste una prueba que faltaba. La opinión no decide; la prueba decide.
Línea de base verde
Ejecuta toda la suite en v3 antes de tocar nada. ¿Todo en verde? Ese es el comportamiento que te comprometes a preservar.
Elimina una redundancia a la vez
Elimina o fusiona una cosa, ejecuta la suite. ¿Todo en verde? Haz commit con la entrada etiquetada en el changelog. ¿En rojo? Revierte, o escribe la prueba que faltaba.
Detente cuando ya no puedas reducirlo sin causar regresiones
El punto de parada es objetivo: cualquier recorte adicional hace que una prueba falle. Entonces, v4 está listo: mínimo y todavía 100% en verde.
✓ Consolidación medida
- •Un corte, una ejecución de la suite, un commit
- •Verde = mantiene · rojo = revierte
- •Un resultado rojo inesperado revela que falta una prueba
✗ Consolidación por opinión
- •"Creo que esto se puede quitar"
- •Corta diez cosas, ejecuta al final y no sabes qué se rompió
- •Acorta el prompt y también el comportamiento
🌱 Tu «repo de evolución» + próximos pasos
El repo que entregaste no es el final — es el inicio de tu práctica. De aquí en adelante, se convierte en el lugar donde aplicas los rituales de la cultura: con cada nueva versión del modelo, un Diff de la semana; con cada nuevo patrón que descubres, una contribución al glosario vivo. El curso enseñó; los rituales sostienen.
🗓 Diff de la semana
Con cada versión nueva (p. ej., la próxima Fable), un análisis breve: qué se agregó, qué se quitó y qué patrón lo explica. Material listo: la sección "Recently Updated" y los enlaces de diff de README.md del acervo.
📚 Glosario vivo
Los 12 patrones + 5 antipatrones en educacao/glossario.md están abiertos a contribuciones. ¿Encontraste un patrón nuevo en un prompt filtrado? Documéntalo, ponle un nombre y agrega un ejemplo.
🧭 Qué te llevas del curso
Aprendiste a leer prompts por patrones con nombre (Ruta 1), a entender la evolución por diffs reales (Ruta 2), a comparar filosofías y productos (Ruta 3) y a construir mediante laboratorio iterativo (Ruta 4): agrega poco, justifica todo, consolida siempre. Los mejores prompts de sistema de 2026 no son los más largos: son los más consolidados. Ahora el tuyo también lo está.
🎓 ¡Terminaste el curso!
Desde la anatomía de un prompt hasta tu propio repo de evolución versionado: cerraste el ciclo. Entregaste un system prompt de producción pequeño, sólido y justificado, con cada línea respaldada por una prueba y cada cambio etiquetado con un patrón. Ese es el oficio.
➡️ Próximos pasos
- 1.Publica tu repo-modelo y abre el primero Diff de la semana cuando salga la próxima versión del modelo.
- 2.Contribuye con un patrón (o antipatrón) al glosario vivo en
educacao/glossario.md. - 3.Aplica el ciclo MVP → diff → consolidación en tu próximo prompt de producción real.
- 4.Vuelve a revisar la Ruta 1 de vez en cuando — volver a leer el catálogo de patrones con una nueva experiencia aporta ideas diferentes.