Checkpoint independiente · Bloque 3 · Unidad 3.2
EX-B3-S01-02
Proporcionar contexto, settings y auditoría
Recibes una API distinta a la del ejemplo: registra solicitudes de cumplimiento, permite consultarlas y tomar una decisión. Funciona y está probada, pero vive en un único módulo.
Cómo abordarla
Haz visible el árbol y el ciclo de vida
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 la API modular de cumplimiento, sustituyes repetición y globals por proveedores explícitos y pruebas sus límites sin un árbol prescrito.
Abrir práctica extendida: base común y 1 parte
Base común
- El starter arranca y sus tests deben estar verdes antes de editar.
- El contrato público y los datos sintéticos son distintos al ejercicio guiado.
- Cada parte declara qué mecanismo puede añadirse; persistencia, autenticación, servicios y auto-registro siguen fuera.
- Los criterios dicen qué conservar, no qué carpetas debes crear.
Paquete de trabajo
- Checkpoint de proveedores y configuraciónAplicación modular con repetición y lifecycle manual, tests verdes y contrato estable; sin solución con Depends o Settings.
Entorno, evidencia y reinicio
Entorno: Python 3.10+ en un workspace temporal; FastAPI, Pydantic 2, pytest y httpx2 instalados por el paquete con uv.
- Commit o diff del refactor sin cambios funcionales.
- Salida completa de pytest antes y después.
- Fingerprint OpenAPI y diagrama de imports final.
Revisión: con Codex, utilizando los artefactos y criterios de cada parte; no se publica una solución oficial.
Reinicio: Descomprimir de nuevo el starter en otro directorio temporal; cada intento empieza con el monolito y sus tests verdes.
Parte 2 · Apoyo autónomo
EX-B3-S01-02 · Proporcionar contexto, settings y auditoría
Reemplazar repetición de frontera, constantes de entorno y cleanup manual por proveedores explícitos, conservando el contrato y demostrando cada alcance.
Qué debes hacer
- Documenta el árbol deseado y clasifica cada nodo como petición, proceso o recurso antes de editar.
- Conserva el contrato de headers, query, respuestas y OpenAPI mientras eliminas la repetición de contexto.
- Recibe configuración tipada desde fuentes externas y permite sustituir su proveedor en tests.
- Gestiona el audit sink mediante un ciclo con yield y prueba cierre en éxito y error.
- Entrega una matriz que conecte cada decisión con una prueba o traza observable.
Entrega esperada
- Repositorio refactorizado sin persistencia, seguridad ni funcionalidad nueva.
- Tests propios de caché por petición, settings/override y lifecycle.
- before-after.md con árbol, comandos, resultados, decisiones y límite de parada.
Criterios de aceptación
- Los ocho tests suministrados pasan antes y después y el fingerprint de operaciones y parámetros OpenAPI no cambia.
- La subdependencia común se ejecuta una vez por petición y vuelve a ejecutarse en otra petición.
- Settings usa pydantic-settings, prefijo explícito y un campo obligatorio que falla al faltar; ningún valor sensible se publica.
- El test sustituye el proveedor de settings y restaura overrides y cachés controladas.
- El audit sink se abre y cierra una vez en éxito y error mediante una dependencia con yield, sin ocultar la excepción.
- No hay recurso global mutable, service locator, use_cache=False sin necesidad ni imports de vuelta hacia main.py.
- La entrega explica por qué cada alcance es suficiente y dónde se detuvo la composición.
Evidencia para revisión
- Árbol y clasificación petición/proceso/recurso antes del cambio.
- Diff, tests añadidos y misma regresión HTTP/OpenAPI después del refactor.
- Trazas de caché y cleanup junto con un override de settings restaurado.
Reinicio de esta parte: Volver a descomprimir el checkpoint; eliminar el .env local del intento y no reutilizar código de los ensayos guiados.