Checkpoint independiente · Bloque 2 · Unidad 2.4
EX-B2-14
Revisión de PR desde OpenAPI
Un PR afirma implementar creación y consulta, pero el diff, los requisitos y el OpenAPI generado no coinciden.
Cómo abordarla
Alinea salida, errores y OpenAPI
Inténtalo desde el material nuevo y sin volver al procedimiento del ensayo anterior. Los criterios son visibles; la estructura y el orden del cambio son tuyos.
Evidencia objetivo: Status, headers, body, filtrado y documentación cuentan la misma historia pública.
Abrir análisis técnico
1. Abre la evidencia
- Paquete de revisiónRequisitos, extracto de diff y documento OpenAPI 3.1 válido con discrepancias contractuales deliberadas.
2. Analiza y decide
- Antes de ejecutar, registra qué comportamientos predices a partir de requisitos y OpenAPI.
- Construye una matriz requisito → OpenAPI → implementación → tráfico observado.
- Prioriza hallazgos por impacto observable.
- Propón cambios mínimos sin reescribir la arquitectura.
- Incluye al menos una comprobación positiva y una negativa.
3. Entrega una decisión revisable
- Informe de revisión con hallazgos priorizados, evidencia y consumidor afectado.
- Matriz de trazabilidad que separe predicción, contrato y ejecución.
- Dos comprobaciones reproducibles y propuesta mínima para los bloqueantes.
Registra tu decisión antes de contrastarla con el material.
Pregunta central
¿Qué divergencias rompen consumidores y cuáles son solo mejoras de estilo?
Para ordenar tu razonamiento
- ¿Qué afirmación contractual puedes comprobar antes de leer la implementación?
- ¿Qué caso negativo separa una ruptura real de una preferencia de estilo?
- ¿Cuál es el primer hallazgo que impediría integrar a un consumidor?
Escribe lo que piensas. Se guarda automáticamente en este navegador.
Sin respuesta guardada.
Pistas opcionales
Profundización opcional
Realizar una revisión contractual con hallazgos priorizados y evidencia precisa.
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
- Cada hallazgo cita una evidencia verificable.
- Se revisan método, fuentes, schemas, status, headers y errores.
- No se confunden preferencias de estilo con defectos del contrato.
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.