Checkpoint independiente · Bloque 4 · Unidad 4.2
EX-B4-S01-02
Consultar y cambiar facturas
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
Conserva intención al consultar y cambiar
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: Sobre una base persistente de facturas, diseñas list, PATCH y DELETE desde criterios visibles sin copiar los ensayos ni añadir capas prescritas.
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 operaciones sobre facturasBase persistente equivalente a la parte 01, cinco pruebas de continuidad y cuatro criterios rojos; sin rutas objetivo, pistas ni solución.
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 2 · Apoyo autónomo
EX-B4-S01-02 · Consultar y cambiar facturas
Transferir consulta acotada, PATCH con presencia explícita y DELETE 204 al dominio persistente de facturas sin copiar la implementación guiada.
Qué debes hacer
- Predice la página de aceptación y los resultados de PATCH omitido/null antes de editar.
- Ejecuta continuidad y aceptación, y diseña tus modelos de página y update desde el contrato visible.
- Implementa listado por currency con count filtrado, orden estable, offset y limit acotado.
- Implementa PATCH de note distinguiendo ausencia y null, y DELETE con commit y ausencia posterior.
- Añade una prueba o traza propia que haga visible una decisión estructural y documenta dónde detuviste el alcance.
Entrega esperada
- Código y tests añadidos sin archivos SQLite generados.
- evidence.md con predicciones, comandos, resultados y una decisión propia.
- Fingerprint OpenAPI y evidencia de ventana, presencia y borrado.
Criterios de aceptación
- Los cinco tests de continuidad permanecen verdes y los cuatro criterios nuevos terminan verdes.
- GET /invoices filtra por currency, ordena de forma total, limita en SQL y devuelve total del conjunto filtrado.
- PATCH vacío conserva note; null explícito la borra y los campos protegidos no son asignables.
- DELETE confirma la eliminación, responde 204 sin body y el GET posterior devuelve el 404 existente.
- GET y operaciones sobre ids ausentes conservan un contrato de error coherente.
- No se anticipan lotes, unicidad, relaciones, rollback multioperación, migraciones, PostgreSQL o arquitectura obligatoria.
Evidencia para revisión
- Página y matriz de presencia predichas antes de implementar.
- Cinco pruebas de continuidad verdes y cuatro criterios inicialmente rojos que terminan verdes.
- Traza o test propio del orden total, count filtrado y ausencia posterior al DELETE.
Reinicio de esta parte: Descomprimir de nuevo esta parte y borrar solo su base local; no copiar los starters guiados de activos.