El sistema está construido y verificado; falta el último acto del oficio: entregarlo. Entregar no es enviar un ZIP — es lograr que otra persona pueda instalarlo sin ti, entender qué hace y por qué, y ver en diez minutos que funciona. En esta lección escribirás el README definitivo, prepararás una demostración con guion, redactarás el informe de datos como entregable de negocio (con el pedido de Sant Jordi como modelo), te evaluarás con una rúbrica honesta y harás la retrospectiva que convierte la experiencia en aprendizaje. Y como esta es la última lección del curso, terminaremos donde se debe terminar: mirando el camino completo desde print("Hola, Mundo") hasta aquí, y decidiendo — con criterio — cuál es tu siguiente paso.

1. Documentar para otros: el README completo
2. La demostración: un guion de 10 minutos
3. El informe final de datos como entregable
4. Autoevaluación honesta: la rúbrica
5. Retrospectiva personal: cinco preguntas
6. Extensiones posibles, ordenadas por dificultad
7. El viaje completo: de M1 a M12
8. Próximos pasos con criterio
9. Papyrus era tuyo desde el principio

El README es la puerta del proyecto: se escribe para alguien que no estaba ahí (incluido tu yo de dentro de seis meses, que tampoco estará). La prueba de fuego es literal: otra persona, con solo el README, arranca el proyecto sin hacerte una pregunta. Plantilla real, sección a sección:

Dos detalles que separan un README profesional de uno de adorno: el ejemplo de uso copiable (el curl con su respuesta esperada: quien lo pega y ve el 18.67 ya confía en el proyecto) y la sección de limitaciones conocidas — documentar lo que falta no es debilidad, es criterio; todo software real la lleva, aunque no siempre escrita.

Una demo sin guion enseña pantallas; una demo con guion cuenta una historia. La historia de Papyrus Online es "de la venta al dato", y este orden la cuenta:

Tres consejos de demo: ensáyala una vez entera (la demo que no se ensaya, falla — ley empírica), ten los comandos ya escritos en un fichero para pegarlos (teclear en vivo es tirar minutos), y enseña un fallo controlado a propósito: nada genera más confianza que un sistema rechazando limpiamente una venta imposible. ¿Que no tienes audiencia? Grábate en pantalla siguiendo el guion. La disciplina de contarlo en voz alta delata cada rincón que no entiendes del todo — es autoevaluación disfrazada de teatro.

El informe de RF6 no es un script que imprime números: es un documento de negocio que Ana pueda leer un lunes por la mañana. El entregable (un Markdown o PDF con el PNG incrustado) debe contener exactamente tres cosas:

1. Los números del periodo: total de unidades e importe, top 3 de títulos, mejor día de la semana, evolución mensual. Con ventas_2026.csv: 520 unidades en el semestre, sábado como rey (130 u), abril desbocado (168 u).
2. El gráfico: uno, no seis. El que mejor cuenta la historia del periodo (la barra mensual con abril sobresaliendo, la de M11).
3. Una recomendación accionable — la parte que casi todo el mundo omite y la que da valor a todo lo demás. El modelo es el pedido de Sant Jordi de 11-05:

«La regresión (MAE ±1.1 u/día) proyecta 172 unidades para abril de 2027. Recomendación: pedido de 190 unidades (proyección + margen del ~10 %), repartido en dos cuotas — 120 a inicio de abril, 70 la semana previa a Sant Jordi — para limitar el riesgo de sobrestock. Vigilar Fausto: 210 visitas y 11.9 % de conversión sugieren revisar su precio antes de la campaña.»

Fíjate en la anatomía: dato → recomendación concreta (con número) → gestión del riesgo → decisión que queda en manos de Ana. Los modelos recomiendan; las personas deciden — la regla de oro de M11 también se entrega por escrito.

Sin profesor, la nota te la pones tú — razón de más para que la escala sea explícita. Evalúa cada dimensión y anota el nivel en DECISIONES.md:

Interpretación honesta: "Suficiente" en todo ya es un logro enorme — un sistema completo construido en solitario. "Bueno" es el estándar profesional razonable. "Excelente" es aspiracional: si has marcado todo excelente, o eres muy bueno o has sido poco honesto — y la rúbrica solo sirve con lo segundo descartado.

La experiencia no enseña; la experiencia examinada enseña. Cierra DECISIONES.md respondiendo por escrito, con calma:

1. ¿Qué me costó más de lo esperado? (Señala tu próxima área de estudio.)
2. ¿Qué me costó menos de lo esperado? (Señala una fortaleza que quizá no sabías que tenías.)
3. ¿Qué decisión de diseño repetiría y cuál no? (Revisa tu tabla de decisiones de 12-02 con la verdad del código delante.)
4. ¿Cuál fue el peor bug y qué lo habría evitado? (Un test antes, un contrato más claro, un tipo mejor definido…)
5. ¿Qué haría distinto si empezara mañana? (La respuesta es tu lista personal de lecciones aprendidas — vale más que cualquier resumen nuestro.)

Las ideas aparcadas en 12-01 tienen ahora su sitio. Cada una con lo que tendrías que aprender — porque "querer hacerlo" sin saber qué implica es como estimar sin datos:

Regla para elegir: una extensión, llevada a acabada, enseña más que tres a medias. Ya sabes por qué: lo aprendiste terminando este proyecto.

Mira atrás un momento, porque la distancia recorrida se ve mejor desde el final. En M1 escribiste print("Hola, Mundo") y pelear con el PATH era una aventura. En M2-M4 aprendiste a pensar en control y estructuras, y Papyrus era una lista con cuatro libros. En M5 esos libros se volvieron objetos con comportamiento; en M6 sobrevivieron a un reinicio; en M7 el sistema aprendió a fallar con elegancia y a dejar constancia en un log. M8 te dio las herramientas de adulto — type hints, decoradores, generadores, context managers — y M9 la que lo cambia todo: la capacidad de demostrar que tu código funciona. En M10 Papyrus salió al mundo por HTTP, dos veces y de dos maneras. En M11 sus datos hablaron: sábados de 130 unidades, un Sant Jordi de 168, un Fausto que se mira y no se compra, una regresión que proyectó 172 y una librera que pidió 190. Y en M12 no aprendiste nada nuevo — hiciste algo más difícil: lo ensamblaste todo, solo, y funciona. Esa frase, hace doce módulos, era impensable. Esa frase es el curso.

"¿Y ahora qué?" tiene mejor respuesta si la eliges por interés real, no por moda. Tres itinerarios según lo que más disfrutaste:

Los tres comparten dos peajes: git (ya no hay excusa) e inglés técnico (la documentación de verdad vive ahí). Y un consejo transversal: a partir de aquí se aprende construyendo — elige proyectos algo más grandes que tu comodidad, como lo fue este.

Una confesión final: Papyrus nunca fue el tema del curso. Fue un vehículo — lo bastante pequeño para caber en una lección, lo bastante real para tener stock que cuadrar, socios que validar y un Sant Jordi que planificar. El tema del curso eras tú trabajando sobre tu propia realidad. Así que el último ejercicio es obvio: mira tu trabajo, tu sector, tu día a día. ¿Qué es ahí el "catálogo"? ¿Expedientes, pólizas, reservas, pacientes, inventario? ¿Qué es la "venta con reglas": un cálculo con descuentos, una validación con excepciones, un proceso que hoy alguien hace a mano? ¿Y qué informe le darías a tu "Ana"? Todo lo construido aquí — capas, contratos, errores propios, tests, un CSV que se convierte en decisión — se traslada tal cual. El primer proyecto que hagas sobre tu dominio será más difícil que Papyrus, porque nadie te dará los requisitos numerados. También será el que te cambie el perfil profesional.

• Entregar sin probar la instalación desde cero. Clona/copia tu proyecto a otra carpeta, crea un venv nuevo y sigue tu README al pie de la letra. Fallará en algo (una dependencia no anotada, una ruta) — mejor descubrirlo tú que tu lector.
• Demo sin ensayo. El servidor que no arranca, el JSON con una coma de más… La única vacuna es haberla hecho entera una vez antes.
• Informe de datos sin recomendación. Números sin decisión propuesta es trabajo a medias; la recomendación (con su riesgo gestionado) es lo que Ana no puede pedirle a una hoja de cálculo.
• Autoevaluarse al alza… o al baja. Inflarse impide crecer; machacarse, continuar. La rúbrica existe para sacarte de ambos: nivel por dimensión, con evidencia.
• No cerrar nunca. Siempre habrá un refactor más, una extensión más. Los proyectos se entregan: versión 1.0, README honesto con limitaciones, y lo siguiente ya es la versión 2 — o el siguiente proyecto.

1. Hito final — el paquete de entrega. Completa el README con la plantilla, verifica la instalación desde cero en un venv nuevo, y genera el informe de negocio (números + PNG + recomendación) como INFORME.md. Verificación: una persona de confianza (o tú mismo, en otra máquina u otra carpeta, siguiendo solo el README) arranca el sistema y ejecuta los tests sin ayuda.
2. Hito final — la demo. Prepara el guion de 10 minutos con tus comandos en un fichero demo.md, ensáyala una vez completa y, si puedes, grábala o muéstrasela a alguien. Verificación: la ejecutas entera sin improvisar ni consultar nada fuera del guion.
3. Hito final — cierre y siguiente paso. Rellena la rúbrica y las cinco preguntas de la retrospectiva en DECISIONES.md, elige tu itinerario de la tabla de próximos pasos y escribe la primera acción concreta con fecha ("sábado: curso básico de git"). Verificación: la acción es tan concreta que el sábado sabrás exactamente qué abrir.

1. No hay solución que copiar: hay una señal de éxito — la persona que sigue tu README no te hace ninguna pregunta. Cada pregunta que te haga es una línea que le falta al README; añádela y considera el ejercicio en curso hasta que las preguntas sean cero.
2. Orientativa: los fallos de ensayo más comunes son el servidor arrancado desde la carpeta equivocada (rutas relativas — 12-03 lo avisó) y los datos "sucios" de pruebas anteriores; ten un datos/ de demo limpio y preparado. Si al narrar un paso no sabes explicar por qué funciona, apúntalo: es la última lección del curso diciéndote dónde repasar.
3. Ejemplo de acción bien formulada: «Sábado 10:00: tutorial oficial de git hasta branching; crear repo de Papyrus Online y hacer el primer commit con la versión entregada.» Mal formulada: «aprender git pronto». La diferencia entre ambas es la misma que llevas doce módulos practicando: lo verificable frente a lo vago.

Se acabó — y esta vez no hay "en la próxima lección". Empezaste este curso escribiendo una línea que saludaba al mundo y lo terminas con un sistema completo que gestiona un negocio: dominio con reglas y errores propios, persistencia que no pierde datos, una interfaz que lo sirve, una suite de tests que lo demuestra y un informe que convierte ventas en decisiones. Más importante que cualquier pieza: has demostrado que puedes recibir requisitos, diseñar, construir, verificar y entregar sin que nadie te lleve de la mano. Eso no se olvida como se olvida una sintaxis; es un cambio de categoría. Te llevas un método (contratos antes que código, validar-calcular-mutar, cada bug deja su test, los modelos recomiendan y las personas deciden), un proyecto real que enseñar, y un mapa de siguientes pasos elegido con criterio. La librería de Ana queda en buenas manos — las tuyas fueron las que la construyeron. Ahora ve y hazle a tu propio dominio lo que le has hecho a Papyrus. Ha sido un privilegio acompañarte desde el print("Hola, Mundo"). El resto del camino se recorre igual que este: una línea, un test y un proyecto cada vez. Buen viaje, y buen código.