Caso profesional extenso · Bloque 1
CASE-B1 · Básica · Guiado de moderado a ligero
¿Está lista esta integración?
Una organización quiere intercambiar expedientes con un proveedor, pero requisitos, tráfico y OpenAPI no describen el mismo comportamiento. Debes identificar los bloqueos que impiden empezar y proponer el contrato mínimo que permitiría una prueba de integración.
No se pide una auditoría exhaustiva ni código. La entrega debe caber en una revisión breve: hallazgos prioritarios, propuesta mínima y preguntas que cambian una decisión contractual.
Contexto profesional
El área de operaciones envía expedientes a un proveedor externo. El proveedor ha entregado una propuesta funcional, una captura de pruebas y un documento OpenAPI acotado. El equipo consumidor debe decidir si el contrato está suficientemente definido para iniciar el desarrollo.
Tu destinatario es una revisión conjunta entre producto, el equipo consumidor y el proveedor. Por tanto, cada hallazgo debe distinguir hechos, inferencias, riesgos y preguntas abiertas.
Debes preservar
- Identidad estable de cada expediente.
- Posibilidad de reintentar tras una respuesta perdida.
- Errores que permitan actuar al consumidor.
- Una representación JSON documentada.
No debes asumir
- Qué framework utiliza el proveedor.
- Que una captura aislada define todo el contrato.
- Que 200 implica éxito de negocio.
- Que REST obliga a una única ruta posible.
Paquete de trabajo
- Requisitos recibidosObjetivos, restricciones y afirmaciones contradictorias de las partes.
- Mensajes HTTP de pruebaTres intercambios: creación, repetición tras timeout y consulta de estado.
- Documento OpenAPI propuestoContrato incompleto que debe contrastarse con requisitos y tráfico.
- Plantilla de entregaEstructura vacía para recursos, operaciones, estados, riesgos y preguntas.
Entorno, evidencia y revisión
Prerrequisitos: unidades 1.1, 1.2, 1.3.
Entorno: Paquete documental descargable trabajado en un directorio separado del repositorio del portfolio.
- Hasta cinco hallazgos priorizados con evidencia.
- Propuesta contractual mínima y preguntas que bloquean la integración.
Revisión: con Codex, utilizando la evidencia y los criterios de aceptación; no se publica una solución oficial.
Reinicio: Crear un directorio de trabajo nuevo y volver a descargar los cuatro materiales originales; no se modifica el repositorio del portfolio.
Contradicciones iniciales
Estas observaciones sirven para comenzar la auditoría; no constituyen una lista exhaustiva ni adelantan cómo resolver cada diferencia.
| Área | Requisitos | Tráfico u OpenAPI | Pregunta de auditoría |
|---|---|---|---|
| Operación principal | Se denomina «enviar expediente» y debe ser REST. | Aparecen rutas orientadas a acción y a recurso. | ¿Qué recurso se crea o modifica realmente? |
| Resultado | Se solicita un código HTTP distinto según el resultado. | Una captura devuelve 200 con ok: false. | ¿Qué debe observar un cliente para distinguir éxito y error? |
| Identidad | La referencia externa evita duplicados. | El schema no la marca como requerida. | ¿Quién asigna cada identificador y cuál gobierna el reintento? |
| Documentos | Un expediente admite varios documentos. | Una representación utiliza un string singular. | ¿Cuál es la cardinalidad y forma pública? |
| Procesamiento | La validación puede continuar después de aceptar el envío. | La respuesta de creación declara un estado final. | ¿Qué significa aceptado frente a completado? |
Encargo
- Selecciona como máximo cinco contradicciones que realmente bloqueen la implementación; cita requisito, tráfico u OpenAPI.
- Para cada hallazgo explica el efecto observable sobre un consumidor y qué decisión falta.
- Propón el contrato mínimo para crear un dossier, repetir la creación tras perder la respuesta y consultar su estado.
- Formula como máximo tres preguntas cuya respuesta cambiaría esa propuesta.
Producto esperado
1. Revisión de preparación
Hasta cinco hallazgos ordenados por impacto, cada uno con evidencia y decisión necesaria.
2. Propuesta mínima para decidir
Tres operaciones, comportamiento del reintento y hasta tres preguntas bloqueantes.
Criterios de aceptación
- Cada hallazgo puede rastrearse a una evidencia concreta y explica un impacto observable.
- La entrega prioriza: no intenta clasificar cada frase ni completar documentación decorativa.
- Las tres operaciones propuestas mantienen un vocabulario coherente y métodos con semántica defendible.
- La propuesta define qué ocurre cuando se repite una petición cuya primera respuesta se perdió.
- El contrato mínimo permite formular una creación, un reintento y una consulta de estado.
- Las preguntas abiertas indican exactamente qué parte de la propuesta cambiaría con la respuesta.
- No se introduce implementación, base de datos, autenticación o despliegue para ocultar una decisión contractual.
Pistas graduadas
Pista 1 · Crea una tabla de procedencia
- Usa columnas para requisito, tráfico, OpenAPI e interpretación.
- Cuando dos columnas discrepen, no elijas todavía una ganadora: registra el conflicto.
Pista 2 · Separa recursos de procesos
- Pregunta qué cosas poseen identidad y qué verbos describen cambios sobre ellas.
- Un nombre de operación heredado no obliga a conservarlo como ruta pública.
Pista 3 · Simula una respuesta perdida
- Imagina que el servidor completó la primera petición pero el cliente no recibió la respuesta.
- Recorre tu contrato con una segunda petición idéntica y comprueba el estado observable.
Pista 4 · Prioriza preguntas
- Una buena pregunta desbloquea una decisión concreta de ruta, identidad, representación o estado.
- Coloca primero las respuestas que podrían obligar a rediseñar más partes del contrato.
Fuera de alcance
- Implementar endpoints o escribir código FastAPI.
- Elegir tablas, base de datos o estrategia de persistencia.
- Implementar autenticación, autorización o cifrado.
- Diseñar contenedores, infraestructura o despliegue.
- Completar un documento OpenAPI de producción con todos sus metadatos opcionales.
- Publicar una solución única: la revisión debe aceptar alternativas defendibles.