Checkpoint independiente · Bloque 4 · Unidad 4.1
EX-B4-S01-01
Hacer persistente una factura
Una API distinta evoluciona desde una factura plana hasta operaciones persistentes y una factura con líneas que debe guardarse como una sola unidad.
Cómo abordarla
Conecta modelo, sesión y contrato público
Inténtalo desde el starter nuevo y sin copiar el ensayo anterior. La estructura y el orden del cambio son tuyos; los tests deben demostrar el contrato.
Evidencia objetivo: En el dominio de facturas, haces persistente una creación sin copiar la estructura guiada y pruebas supervivencia entre dos instancias de aplicación.
Abrir práctica extendida: base común y 1 parte
Base común
- Cada starter conserva cinco tests de continuidad verdes y expone criterios de aceptación inicialmente rojos.
- No contiene SQLModel, solución, pistas escalonadas ni una arquitectura de carpetas prescrita.
- Las partes 01–03 avanzan de persistencia plana a operaciones y después a cabecera, líneas e integridad transaccional.
- Cada parte parte de la evidencia anterior, pero llega como paquete independiente para que el estado local no falsee el resultado.
Paquete de trabajo
- Checkpoint de facturasDominio nuevo con estado efímero, contrato probado, aceptación visible y plantilla de evidencia; sin solución ni pistas.
Entorno, evidencia y reinicio
Entorno: Python 3.10+ en un workspace temporal; FastAPI 0.141, SQLModel 0.0.39, pytest y httpx2 instalados por el paquete con uv.
- Predicción independiente de ciclos de vida, contrato y frontera transaccional.
- Resultados del baseline y de los criterios ejecutables de cada parte.
- Pruebas propias de Session, consultas y ausencia de estado parcial.
Revisión: con Codex, utilizando los artefactos y criterios de cada parte; no se publica una solución oficial.
Reinicio: Volver a descomprimir el paquete de la parte activa en otro directorio y eliminar solo los SQLite creados por ese intento.
Parte 1 · Apoyo autónomo
EX-B4-S01-01 · Hacer persistente una factura
Transferir la primera frontera persistente a otro dominio y demostrar contrato, lifecycle y supervivencia sin copiar la secuencia guiada.
Qué debes hacer
- Sin abrir el starter guiado, predice qué debe vivir por app, petición, operación y más allá del proceso.
- Ejecuta y registra la suite de contrato y los criterios de aceptación antes de editar.
- Haz persistente el POST y el GET por id con tres modelos y una Session por petición.
- Añade la evidencia de lifecycle que consideres más directa y prueba una segunda app sobre el mismo archivo.
- Documenta una decisión propia, una alternativa descartada y el punto exacto donde detuviste el alcance.
Entrega esperada
- Repositorio del checkpoint, tests añadidos y ningún archivo SQLite versionado.
- evidence.md completo con comandos, resultados, matriz y decisión.
- Una inspección de tabla/fila y un fingerprint del contrato público final.
Criterios de aceptación
- Los cinco tests suministrados pasan antes y después y el contrato conserva método, path, 201, 404 y body.
- Una factura creada por la primera app se recupera desde otra app que solo comparte la ruta SQLite.
- La base contiene una tabla de dominio y la fila con supplier_reference, subtotal_cents y currency.
- Creación, tabla y salida tienen responsabilidades distintas; storage_note no aparece en respuesta ni OpenAPI.
- Un engine estable sirve a sesiones distintas y cerradas por petición; la escritura confirma y refresca explícitamente.
- No se anticipan importaciones por lotes, unicidad, relaciones, PATCH, repositorios, migraciones o PostgreSQL.
Evidencia para revisión
- Matriz de ciclos de vida y modelos escrita antes del cambio.
- Baseline verde, aceptación roja inicial y todas las pruebas verdes al finalizar.
- Inspección de SQLite y prueba propia de lifecycle de Session.
Reinicio de esta parte: Descomprimir de nuevo el checkpoint y borrar solo la base local del intento; no reutilizar el código del ejercicio de activos.