Checkpoint independiente · Bloque 2 · Unidad 2.3
EX-B2-09
Un modelo no sirve para todo
La API usa `Record` para crear, actualizar y responder: el cliente puede enviar `id` y la salida publica `internal_note`.
Cómo abordarla
Haz explícitas las reglas del modelo
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: El modelo acepta, normaliza o rechaza con reglas localizables y separa entrada, actualización y salida.
Abrir laboratorio de código
1. Descarga y arranca
- API con modelo únicoStarter defectuoso con tres operaciones y una lista en memoria.
2. Escribe y prueba
- Antes de editar, predice qué acepta creación, qué borra PATCH y qué expone la lectura; después captura el comportamiento real.
- Construye una matriz de propiedad de campos por operación y diseña contratos separados con los nombres que puedas defender.
- Conecta las operaciones sin cambiar rutas y demuestra filtrado, presencia en PATCH y rechazo de campos controlados por servidor.
- Compara el OpenAPI público antes y después y explica una abstracción que decidiste no añadir.
3. Demuestra el comportamiento
- Matriz operación → campos aceptados, modificables, públicos e internos.
- Refactor y regresiones para creación, PATCH y lectura.
- Comparación OpenAPI y decisión de diseño con su límite explícito.
La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.
Predicción breve antes de ejecutar
¿Qué campos controla el cliente en cada operación y qué campos son exclusivamente públicos o internos?
Comprueba estas tres cosas
- ¿Qué campos controla realmente el cliente en cada operación?
- ¿Qué petición negativa demuestra que un campo del servidor ya no es asignable?
- ¿Qué cambio observable debe aparecer en OpenAPI y cuál debe permanecer estable?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Profundización opcional
Separar modelos de creación, actualización y respuesta con una base pequeña cuando aporte valor.
Contexto adicional
- Trabaja únicamente dentro del alcance del bloque: una aplicación pequeña y estado en memoria.
- No hay solución oficial publicada; el material contiene huecos y defectos deliberados.
- Justifica las decisiones por el mensaje HTTP y el contrato observable, no solo porque el código arranque.
Cómo revisar tu respuesta
- Creación no acepta campos asignados por el servidor.
- Update solo permite campos modificables.
- Salida no contiene `internal_note`.
Evidencia, revisión y reinicio
- Decisión razonada guardada localmente en la web.
- Código o informe ejecutable en el workspace temporal, más una captura de curl/OpenAPI cuando proceda.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Eliminar el workspace temporal y volver a descargar el material inicial; no hay estado persistente externo.