14.4 Soluciones comentadas E01–E12

Al terminar esta lección

• Comparar tu entrega con la solución comentada de cada práctica, enfocándote en el razonamiento y no en el formato.
• Identificar en tu trabajo tres clases de diferencia: una pregunta que no hiciste, una decisión distinta pero defendible y una invención sin fuente.
• Reconocer los fallos típicos de cada práctica antes de cometerlos.
• Armar la evidencia mínima que demuestra que una entrega es verdadera, no solo completa.
• Usar los entregables de ejemplo como referencia de estructura, sin copiarlos como respuesta.

Apéndice D · Soluciones comentadas de prácticas clave

Cada práctica tiene tres partes: el comentario de la solución, una solución ampliada con sus fallos típicos y la evidencia que conviene mostrar, y un entregable de ejemplo. El entregable está plegado a propósito. Primero producí tu artefacto, después abrí el ejemplo.

Las soluciones usan el canon de Nexo vigente: las RN, AC, ADR y backlog de los módulos 3 a 9, con los valores ya resueltos. Donde el caso deja algo BLOCKED, la solución lo deja BLOCKED y no lo inventa.

D.E01 · Comentario de solución

Una buena respuesta no propone portal. Prioriza desconocidos como autoridad de precio, condición de confirmación, stock/reserva, crédito, excepción y fuente del maestro. Las hipótesis pueden incluir que existe doble carga o que una reserva ayudaría, pero deben quedar explícitamente separadas.

D.E01 · Solución comentada ampliada

Una buena solución no intenta adivinar Nexo. Clasifica "queremos portal" como deseo de solución, "los vendedores pierden tiempo" como declaración que necesita medición y "siempre revisan la cuenta" como regla candidata todavía ambigua. Los mejores desconocidos son los que bloquean decisiones: exposición de crédito, autoridad de excepción, momento de reserva y precedencia entre lista y acuerdo. Una respuesta floja se reconoce porque contiene porcentajes o políticas que no estaban en la evidencia.

Qué hizo bien. Separa deseo, declaración y regla candidata. Cada desconocido tiene una pregunta que se puede responder y una persona que puede responderla. Las hipótesis están escritas de forma refutable: "parte de las unidades figuran disponibles en el ERP pero ya están reservadas a mano en la pizarra" se puede medir; "el portal va a funcionar" no.

Qué suele fallar. Escribir "Marta autoriza hasta un 10%" como si fuera un dato del brief. Tener quince desconocidos de los cuales doce son variantes de la misma pregunta. Proponer una tecnología en la conclusión, aunque sea "con Next.js".

Evidencia que conviene mostrar. El dossier con la fuente de cada afirmación, la lista de desconocidos ordenada por lo que bloquea y el objetivo de discovery en una frase.

Entregable de ejemplo, el plan de investigación con desconocidos priorizados:

1objetivo_discovery: "Entender cómo nace, se valida, se prepara y se cierra un pedido mayorista."
2desconocidos:
3  - id: U-01
4    pregunta: "¿Cómo se calcula la exposición de crédito: saldo, facturas no contabilizadas y cheques pendientes?"
5    dueno: "Laura (administración y crédito)"
6    bloquea: "CU-01, evaluación de crédito"
7    prioridad: 1
8  - id: U-02
9    pregunta: "Cuando una lista de precios y un acuerdo difieren, ¿cuál prevalece y desde qué fecha?"
10    dueno: "Comercial"
11    bloquea: "RN-03, precio de la línea"
12    prioridad: 1
13  - id: U-03
14    pregunta: "¿Quién puede autorizar un exceso de crédito, hasta qué diferencia y cómo queda registrado?"
15    dueno: "Marta (dueña), con administración y crédito"
16    bloquea: "CU-02, autorización de excepción"
17    prioridad: 1
18  - id: U-04
19    pregunta: "¿En qué momento se reserva el stock y cuánto dura una reserva mientras el pedido espera?"
20    dueno: "Sergio (depósito) y comercial"
21    bloquea: "RN-05 y RN-07 (BLOCKED)"
22    prioridad: 1
23  - id: U-05
24    pregunta: "¿Qué se hace cuando el stock físico no coincide con el del ERP al preparar?"
25    dueno: "Sergio (depósito)"
26    bloquea: "CU-04, resolver quiebre de preparación"
27    prioridad: 2
28  - id: U-06
29    pregunta: "¿Qué canal es el origen real de los pedidos en el primer release?"
30    dueno: "Marta (dueña)"
31    bloquea: "Alcance del portal y del slice 1"
32    prioridad: 2
33hipotesis:
34  - id: HIP-01
35    texto: "Parte de las unidades figuran disponibles en el ERP pero ya están reservadas a mano en la pizarra para pedidos abiertos que el ERP no descuenta."
36    refutable_con: "Comparar ERP, pizarra y pedidos abiertos durante tres días."

Al comparar tu trabajo, preguntate: ¿qué pregunta harías primero que hoy no hacés? Esa pregunta suele ser la que bloquea la primera decisión de precio o de crédito.

D.E02 · Comentario de solución

Las preguntas más fuertes piden un pedido real, una autorización real y un quiebre real. Un cierre competente asigna a cada desconocido una persona/documento y fecha, en lugar de prometer "lo vemos".

D.E02 · Solución comentada ampliada

La solución de ejemplo usa la reunión 1 de Nexo. Si en la práctica elegiste otra empresa, compará la estructura y el razonamiento, no los datos.

La reunión competente gira alrededor de un episodio. Debe aparecer una secuencia, decisiones, fuentes y al menos una contradicción. No alcanza una lista de preguntas "correctas". La solución más fuerte también registra lo que no preguntaría todavía, por ejemplo tecnología de implementación. Es razonable que dos alumnos formulen preguntas distintas si pueden explicar qué incertidumbre reduce cada una.

Qué hizo bien. Arranca por el pedido 48172 y lo recorre en orden temporal. Separa lo que el operario vio de lo que la vendedora interpretó. Tiene al menos una pregunta de contraste: "¿qué pasó con el pedido de otro cliente Platino la semana pasada?".

Qué suele fallar. Preguntas cerradas ("¿siempre autorizan?") que se contestan con un sí. Un cierre que promete una solución para la semana siguiente. Olvidar que las notas con fuente las va a leer alguien que no estuvo en la sala.

Evidencia que conviene mostrar. Las notas con fuente (el registro de evidencia) con los episodios, la lista de preguntas ordenadas por objetivo y el cierre escrito con dueño y fecha para cada punto.

Entregable de ejemplo, el cierre de reunión de dos minutos:

1# Cierre · Reunión 1 · Marta, vendedora, depósito y Laura (por videollamada)
2Lo que entendimos:
3- El pedido 48172 llegó por WhatsApp a las 10:02 con 23 códigos, dos mal escritos y uno discontinuado.
4- A las 10:11 el saldo más el pedido superaba el límite. Laura aprobó por audio a las 10:14.
5- El faltante de AX-442 se informó a las 10:31. El cliente aceptó otra marca a las 10:36.
6​
7Lo que no sabemos (con dueño y fecha):
8- Cuánto es "poca" y "mucha" diferencia de crédito y quién decide en cada caso. Dueña: Laura, con tres autorizaciones recientes y sus montos. Fecha: jueves.
9- Qué fuente de precio prevalece entre lista y acuerdo. Dueño: responsable comercial, con dos acuerdos con fecha. Fecha: jueves.
10- En qué momento se reserva stock y por cuánto tiempo (hoy se reserva a mano en la pizarra). Dueño: Sergio. Fecha: viernes.
11- Qué estados reales recorre un pedido en el ERP. Dueño: Sistemas, con una exportación. Fecha: viernes.
12- Si el primer release apunta a autoservicio completo o a reducir el tiempo de confirmación. Dueña: Marta. Fecha: viernes, antes de la reunión 2.
13​
14Si algo de esto no es así, corríjannos ahora.
15​
16Lo que no prometemos hoy: una solución ni un plazo de desarrollo.
17Playback: lo enviamos por escrito el jueves.

Al comparar tu trabajo, preguntate: ¿tu cierre tiene una fecha para cada pendiente? Si la respuesta es "lo vemos", todavía no cerraste la reunión.

D.E03 · Comentario de solución

El AS-IS debe mostrar la vuelta ventas-depósito-cliente ante un faltante, sea por quiebre físico o por carrera digital. Un glosario fuerte distingue confirmación comercial de preparación física y evita que "stock" signifique on-hand, disponible y reservado al mismo tiempo.

D.E03 · Solución comentada ampliada

El AS-IS correcto conserva roles y decisiones sin diseñar el futuro. Debe distinguir discrepancia física de carrera digital y mostrar qué propósito cumple cada workaround. Una solución alternativa puede no usar diagrama si una narrativa estructurada responde mejor las preguntas. Lo obligatorio es que el equipo pueda reconstruir el episodio y detectar handoffs, esperas y fuentes.

Las reglas candidatas deben terminar en el conjunto que el curso consolida: RN-01 a RN-09. En esta práctica deberías tener ocho candidatas con fuente. RN-01 a RN-07 ya están en la tabla de 3.1; separá las del proceso actual (RN-01, RN-02, RN-04) de las que son política o invariante del sistema futuro (RN-03, RN-05, RN-06, RN-07). RN-08 (unidad de venta) y RN-09 (cliente de contado) se numeran en el módulo 6, y no son un error si no las encontraste acá.

Qué hizo bien. Muestra el AS-IS con las vueltas: ante un faltante, el pedido vuelve del depósito a ventas y de ventas al cliente. Cada regla tiene condición, resultado, frontera o qué falta, y estado. El glosario elimina colisiones: "pedido confirmado" aparece con dos significados distintos y se los separa.

Qué suele fallar. Un mapa lineal donde "preparar pedido" es una caja sin vueltas. Reglas que dicen "el sistema debe reservar stock" sin condición ni fuente. Unknowns disfrazados de tareas técnicas ("implementar el TTL"), cuando en realidad el TTL es una decisión de negocio sin dueño.

Evidencia que conviene mostrar. El mapa AS-IS con roles, el glosario de doce términos con colisiones marcadas y la lista de reglas con fuente y estado.

Entregable de ejemplo, el mapa conceptual y un fragmento del glosario:

1terminos:
2  - termino: disponible
3    estado_del_termino: COLISION
4    significados:
5      - area: ERP
6        definicion: "Stock on-hand que muestra la pantalla."
7      - area: Depósito
8        definicion: "Lo que se puede prometer después de descontar lo reservado a mano en la pizarra."
9    nota: "Fórmula candidata: onHand - reservado. Hoy la fuente de 'reservado' es la pizarra."
10  - termino: quiebre físico
11    definicion: "Diferencia entre el stock registrado y el que hay en el estante, por movimientos no registrados."
12    no_confundir_con: "Carrera digital: dos pedidos prometen la misma unidad porque nadie la reservó."
13  - termino: pedido confirmado
14    estado_del_termino: COLISION
15    significados:
16      - area: Ventas
17        definicion: "Pasó crédito: aceptado comercialmente."
18      - area: Depósito
19        definicion: "Hoja impresa recibida y stock verificado en la ubicación antes de preparar."
20    propuesta_de_nombres: ["CONFIRMADO_COMERCIAL", "LISTO_PARA_PREPARAR"]
21    quien_decide: "Dirección, con ventas y depósito"
22reglas_candidatas:
23  - id: RN-02
24    condicion: "Cliente PLATINO con saldo más pedido por encima del límite"
25    resultado: "Pasa a autorización: si la diferencia es poca decide Laura; si es mucha, Marta"
26    frontera: "Falta: dónde termina la diferencia poca (se piden tres autorizaciones recientes con montos)"
27    fuente:
28      - 'EV-03, declaración de la vendedora (reunión 1, minuto 4): "Con Platino, si es poco, se pide autorización. Ayer pasó."'
29      - 'Vendedora, reunión 1, minuto 12: "Si es poca diferencia, Laura. Si es mucho, Marta."'
30    autoridad: "Marta (dueña), con Laura"
31    estado: BLOCKED

Al comparar tu trabajo, preguntate: ¿tu glosario distingue "disponible" de "stock" en todas las notas, o solo en la primera página?

D.E04 · Comentario de solución

Recomendaciones con IA quedan OUT porque no responden al riesgo central. Devoluciones pueden quedar BLOCKED si su política es desconocida. El primer release concentra registro, precio, crédito, reserva e integración fiscal.

D.E04 · Solución comentada ampliada

Un buen alcance no es el más pequeño sino el que forma un resultado coherente. Cuenta corriente completa puede quedar OUT mientras la exposición necesaria para crédito entra como integración o lectura. Sustituciones pueden quedar BLOCKED por falta de reglas. La calidad se evalúa por justificación y trazabilidad, no por coincidir con una lista única.

El backlog de referencia tiene veintiocho ítems: F01 es el portal como paraguas; F02 a F11 son los diez que entran al primer release; F12 a F23 quedan OUT; F24 a F28 quedan BLOCKED. Tu lista puede tener otros nombres o agrupaciones, pero cada ítem IN debe responder a un objetivo y cada OUT debe poder defenderse.

Qué hizo bien. Cada IN responde a OBJ-1 (tiempo hasta una decisión observable) u OBJ-2 (porcentaje de pedidos con intervención posterior). Las exclusiones se justifican con el riesgo central, no con "no hay tiempo".

Qué suele fallar. Meter "cuenta corriente completa" en IN porque "la dueña la pidió". Dejar la sustitución automática como IN sin matriz de reglas. Confundir el problema de fondo con la herramienta: los pedidos llegan por WhatsApp porque el precio y el stock no son confiables. Lo que entra es la confiabilidad del registro (F04, F05, F08), no un bot de WhatsApp, que queda OUT.

Evidencia que conviene mostrar. La tabla de IN/OUT/BLOCKED con una línea de justificación por ítem, los cinco requerimientos funcionales del slice y los cuatro NFR con su escenario y su umbral.

Entregable de ejemplo, el backlog y los requerimientos:

1objetivos:
2  - id: OBJ-1
3    texto: "Tiempo hasta una decisión observable sobre un pedido."
4  - id: OBJ-2
5    texto: "Porcentaje de pedidos que requieren intervención posterior."
6backlog:
7  - id: F01
8    tipo: paraguas
9    texto: "Portal B2B como contenedor del release"
10  - id: F02
11    estado: IN
12    texto: "Catálogo de productos"
13  - id: F04
14    estado: IN
15    texto: "Armado y envío del pedido con requestId"
16    justificacion: "Sin esto no hay pedido que registrar (OBJ-1)."
17  - id: F10
18    estado: IN
19    texto: "Entrega a preparación con marca pendiente de facturación"
20    justificacion: "Cierra el flujo sin emitir comprobante (integración posterior)."
21  - id: F13
22    estado: OUT
23    texto: "Chatbot en WhatsApp"
24    justificacion: "No responde al riesgo central: primero hay que confiar en precio y reserva."
25  - id: F12
26    estado: OUT
27    texto: "Recomendaciones de productos"
28    justificacion: "No hay problema priorizado que la justifique."
29  - id: F23
30    estado: OUT
31    texto: "Cuenta corriente completa"
32    justificacion: "Decisión DEC-04-01. La exposición necesaria para crédito entra como lectura."
33  - id: F24
34    estado: BLOCKED
35    texto: "Sustitución automática de SKU"
36    dueno: "Comercial"
37requerimientos_funcionales:
38  - id: RF-01
39    texto: "Crear pedido con requestId; mismo requestId y mismo contenido devuelven el mismo pedido."
40  - id: RF-03
41    texto: "Precio de línea calculado en el servidor (RN-03)."
42  - id: RF-04
43    texto: "Crédito estándar evaluado antes de confirmar (RN-01)."
44  - id: RF-06
45    texto: "Reserva por depósito que nunca deja disponible negativo (RN-05)."
46  - id: RF-08
47    texto: "Estado del pedido visible para el vendedor."
48requerimientos_no_funcionales:
49  - id: NFR-01
50    escenario: "Registro de pedido con p95 menor a 800 ms, 30 usuarios concurrentes, dataset representativo."
51  - id: NFR-02
52    escenario: "Toda autorización de excepción conserva actor, instante, regla, pedido y motivo."
53  - id: NFR-03
54    escenario: "Un vendedor solo opera clientes de su cartera; todo intento denegado queda auditado."
55  - id: NFR-04
56    escenario: "Una falla del proveedor fiscal después del commit no duplica pedido ni comprobante al reintentar."

Al comparar tu trabajo, preguntate: ¿qué ítem IN de tu lista no podrías defender si la dueña preguntara "¿y eso para qué?"?

D.E05 · Comentario de solución

La versión validada incorpora reserva y evaluación obligatorias como include. Autorizar crédito es una extensión condicionada al resultado de la evaluación. Resolver faltante extiende preparar pedido cuando existe quiebre físico.

D.E05 · Solución comentada ampliada

CU-01 debería evolucionar. La versión final incluye reglas de cantidad, precio autoritativo, crédito y reserva, pero no absorbe despacho completo. PENDIENTE_AUTORIZACION es un resultado de negocio, no un error genérico. Si una solución usa include o extend, debe poder explicar semántica y dirección; no se premia usar relaciones por cantidad.

El orden del caso es el validado: validar identidad, cantidad y productos; calcular precio desde fuentes servidoras; calcular el total; evaluar crédito; reservar stock. Crédito va antes que la reserva en la misma transacción, porque una reserva que se hace antes de saber si el pedido se puede aprobar bloquea stock para nada. Si el crédito queda pendiente de autorización, la reserva es blanda y no firme hasta que alguien autorice; su vencimiento sigue BLOCKED.

Los casos de uso del caso ya tienen IDs: CU-02 Autorizar excepción de crédito, CU-03 Preparar pedido y CU-04 Resolver quiebre de preparación. Tu solución puede usar otros nombres, pero debe dejar claro qué caso es base y cuál extiende.

Qué hizo bien. Pone la evaluación de crédito antes de la reserva y explica por qué. Declara el pendiente de autorización como resultado de negocio. Las relaciones tienen dirección correcta: CU-02 extiende a CU-01 y CU-04 extiende a CU-03.

Qué suele fallar. Un include desde CU-02 hacia CU-01 (la dirección está invertida). Reservar antes de evaluar el crédito sin justificarlo. Una garantía mínima escrita como "el sistema maneja errores", que no dice qué efectos no pueden quedar.

Evidencia que conviene mostrar. El diagrama revisado con la dirección de cada relación, la especificación de CU-01 con sus cinco alternativos y las seis AC con su garantía.

Entregable de ejemplo, la especificación de CU-01 con las AC que la verifican:

1CU-01 Registrar pedido mayorista
2Actor primario: Vendedor
3Objetivo: dejar un pedido comercialmente aceptado, o un resultado explícito de por qué no puede aceptarse.
4Precondiciones: vendedor autorizado para operar el cliente; maestros de cliente y producto disponibles.
5Curso principal:
6  1. El vendedor identifica al cliente y envía las líneas solicitadas con requestId.
7  2. El sistema valida identidad, cantidad y productos.
8  3. El sistema resuelve el precio de cada línea desde fuentes servidoras.
9  4. El sistema calcula el total con las reglas vigentes.
10  5. El sistema evalúa crédito con saldo, límite y política vigentes.
11  6. El sistema reserva stock por depósito dentro de la misma transacción.
12  7. Si el crédito es aprobado, confirma el pedido. Si requiere autorización, lo deja PENDIENTE_AUTORIZACION con reserva blanda y marca pendiente de facturación.
13  8. Devuelve número, estado y resumen.
14Alternativos:
15  A1. SKU inválido: rechaza antes de crear efectos parciales.
16  A2. Stock insuficiente: no confirma; informa faltantes.
17  A3. Crédito requiere autorización: deja estado pendiente (CU-02).
18  A4. requestId reutilizado con otro contenido: conflicto, sin segundo pedido.
19  A5. Maestros no disponibles: falla visible, sin inventar valores.
20Garantía mínima: no existe pedido confirmado con precio no autorizado, reserva negativa o decisión de crédito ausente.
21Garantía de éxito: pedido confirmado una sola vez, con trazabilidad suficiente para explicar precio, crédito, stock y actor.
22Criterios de aceptación:
23  AC-01 happy path
24  AC-02 saldo más pedido exactamente en el límite: permitido
25  AC-03 un centavo sobre el límite: rechazo sin efectos
26  AC-05 SKU inválido sin pedido parcial
27  AC-06 última unidad con dos reservas concurrentes: exactamente una gana
28  AC-08 crédito que requiere autorización queda pendiente y auditado

Antes de seguir, revisá estas relaciones propuestas por un alumno para el mismo caso. Hay tres líneas que no respetan la semántica de include y extend y la de actor.

Al comparar tu trabajo, preguntate: ¿tu garantía mínima dice qué efecto no puede existir, o solo que algo "se maneja"?

D.E06 · Comentario de solución

Un bundle bueno referencia RN completas y no copia páginas enteras. Debe incluir el contrato y la autoridad de datos, especialmente que precio/crédito no vienen autoritativamente desde el frontend.

D.E06 · Solución comentada ampliada

El bundle fuerte elimina contexto irrelevante y explicita autoridad de datos. Precio y descuento final no vienen del cliente. Los BLOCKED aparecen visibles. El agente puede pedir archivos adicionales, pero no debería necesitar inventar reglas. Si el bundle reproduce el manual entero, falló la selección de contexto.

El bundle se entrega como máximo en seis páginas equivalentes, y el destinatario es un desarrollador que no estuvo en discovery. Por eso cada ID referido tiene que estar definido dentro del bundle o en un archivo al que apunta.

Qué hizo bien. Referencia RN-03 y RN-05 por ID, en vez de repetir su texto con otras palabras. Lista los BLOCKED con su dueño, para que el agente no los resuelva. Dice qué archivos no tocar.

Qué suele fallar. Repetir una regla con otra redacción en dos lugares, lo que produce dos versiones que se contradicen con el tiempo. Un contrato que acepta unitPrice del cliente. Ningún fuera de alcance, lo que obliga al agente a adivinarlo.

Evidencia que conviene mostrar. Los tres archivos del bundle (autoridad, invariantes y línea de base), el contrato de entrada y salida y la lista de BLOCKED con dueño.

Entregable de ejemplo, la autoridad de datos y las invariantes:

1datos:
2  - dato: "Precio de línea"
3    autoridad: "Servidor, desde lista vigente y acuerdos autorizados"
4    regla: RN-03
5    el_cliente_envia: false
6  - dato: "Crédito aprobado"
7    autoridad: "Servidor, evaluación con saldo, límite y política"
8    regla: RN-01
9    el_cliente_envia: false
10  - dato: "Disponibilidad por depósito"
11    autoridad: "PostgreSQL, onHand menos reserved"
12    regla: RN-05
13    el_cliente_envia: false
14  - dato: "Vencimiento de reserva blanda"
15    autoridad: "BLOCKED. Dueños: depósito y comercial"
16    regla: RN-07
17    el_cliente_envia: false

1invariantes:
2  - id: INV-01
3    texto: "La disponibilidad por depósito y SKU nunca es negativa."
4    fuente: RN-05
5  - id: INV-02
6    texto: "Un requestId produce un pedido. Mismo contenido, mismo resultado. Otro contenido, conflicto."
7    fuente: RN-06
8  - id: INV-03
9    texto: "Cada línea conserva el precio aplicado al confirmar."
10    fuente: RN-03
11  - id: INV-04
12    texto: "Toda autorización de crédito queda auditada en un estado compatible."
13    fuente: NFR-02
14  - id: INV-05
15    texto: "Sin efectos parciales antes del commit; un fallo externo no duplica el pedido."
16    fuente: NFR-04
17contrato_http:
18  confirmed: 201
19  pending_authorization: 202
20  rejected: 422
21  conflict: 409
22  temporarily_unavailable: 503

Al comparar tu trabajo, preguntate: si el agente lee solo este bundle, ¿puede saber quién decide el precio sin preguntarte?

D.E07 · Comentario de solución

Monolito modular suele ser preferible aquí porque el volumen es moderado y las invariantes cruzan módulos. La respuesta madura también reconoce cuándo la decisión podría cambiar, por ejemplo aislamiento operativo o escala realmente distinta.

D.E07 · Solución comentada ampliada

La arquitectura esperada puede variar. Lo innegociable es proteger invariantes y justificar mecanismos. Un monolito modular con PostgreSQL y outbox puede ser excelente; otra solución puede separar servicios si existe una razón demostrable. Redis, Kafka o microservicios sin ASR no suman puntos. La prueba de concurrencia debe competir realmente.

El ASR relevante es que pedido, stock y crédito tienen que cambiar juntos dentro de una misma operación, con tres integraciones externas (ERP, fiscal y logística) y un equipo pequeño. Con esos datos, separar en servicios convierte una transacción local en una coordinación distribuida. Eso puede hacerse, pero el costo operativo tiene que aparecer en la comparación.

Qué hizo bien. Compara las opciones contra el ASR, no contra la moda. Reconoce el costo del monolito (disciplina para sostener los límites de módulo) y el de los microservicios (coordinación y observabilidad). Escribe el disparador de revisión.

Qué suele fallar. Decir "microservicios escalan mejor" sin decir a qué escala ni para qué parte. Proponer Redis para contadores de stock sin prueba de que la base no alcanza. Un ADR sin la opción descartada.

Evidencia que conviene mostrar. El ADR con contexto, opciones, decisión y disparador de revisión, la comparación contra el ASR y la prueba concurrente que la decisión necesita.

Entregable de ejemplo, el ADR escrito con la plantilla de la lección 14.2:

1ADR-001 Monolito modular con worker separado
2Estado: aceptado
3Contexto / ASR: equipo pequeño, volumen moderado; pedido, stock y crédito cambian juntos en una operación; tres integraciones externas (ERP, fiscal, logística).
4Opciones consideradas:
5  - Microservicios para catálogo, pedidos, crédito y stock.
6  - Monolito modular con un solo deploy lógico y un worker para efectos externos.
7Decisión: monolito modular con worker separado para outbox e integraciones.
8Consecuencias positivas: transacción local para pedido, reserva y crédito; un solo lugar de auditoría; menor costo operativo.
9Consecuencias negativas: escala menos granular; disciplina necesaria para sostener los límites de módulo.
10Evidencia / experimento: prueba de integración que compromete pedido y reserva en una misma transacción, con dos reservas concurrentes (AC-06).
11Disparador de revisión: un módulo necesita escalado o despliegue materialmente distinto, o un SLA que este despliegue no puede cumplir.

Al comparar tu trabajo, preguntate: ¿tu ADR dice qué condición observable lo haría cambiar, o solo "cuando crezca"?

D.E08 · Comentario de solución

El Sprint aprobado deja TTL BLOCKED, incluye concurrencia/idempotencia y estrategia de fallo fiscal. El despliegue es simple por decisión, no por omisión.

D.E08 · Solución comentada ampliada

El Sprint de Arquitectura debe poder leerse como argumento: problema, evidencia, promesa, riesgos, decisiones y plan. Una entrega llena de diagramas pero incapaz de explicar OUT/BLOCKED es débil. Una entrega más corta puede ser superior si responde todas las preguntas necesarias y deja trazabilidad.

La versión de referencia organiza el plan en seis slices por valor. El slice 1 deja un pedido con precio y crédito en BORRADOR, sin reserva. El slice 2 agrega reserva e idempotencia. El slice 3 agrega la autorización de excepción con reserva blanda. El 4 incorpora equivalencias de SKU por fecha. El 5 lleva el pedido a preparación desde el outbox y cubre el quiebre en picking. El 6 agrega la intención fiscal. Las letras A a F son checkpoints internos de cada slice, no slices.

Qué hizo bien. Cada sección responde a una decisión. Los riesgos tienen dueño: el TTL de reserva es de depósito y comercial, el lag del ERP es del Responsable del Desarrollo, y los acuerdos sin vigencia son del responsable comercial. Tiene dos spikes explícitos: la idempotencia real de la API fiscal y la latencia con cambios de datos del ERP.

Qué suele fallar. Un plan incremental por capas (base de datos primero, API después, UI al final), que retrasa el primer valor observable. Riesgos sin dueño. Una sección de despliegue con tres nodos cuando un ASR no lo justifica.

Evidencia que conviene mostrar. El índice de las dieciocho secciones con cada una respondida o marcada como "no aplica, por qué", la tabla de riesgos con dueño y el plan de slices con sus dependencias.

Entregable de ejemplo, el resumen de decisiones y riesgos:

1decisiones:
2  - id: DEC-08-01
3    texto: "Facturación fuera del primer valor observable. Se reabre cuando T12 pase y SPK-01 esté cerrado."
4  - id: DEC-08-02
5    texto: "Pedido y reserva viven en la misma base (ADR-002)."
6objetivos:
7  - id: OBJ-3
8    texto: "Dos pedidos no prometen la misma última unidad (AC-06)."
9  - id: OBJ-4
10    texto: "Un reintento no crea duplicados (AC-07, T08)."
11riesgos:
12  - id: RSK-01
13    texto: "TTL de la reserva blanda sin validar: puede congelar o liberar stock de más."
14    tratamiento: "BLOCKED. Parametrizar, no fijar valor."
15    dueno: "Sergio y comercial"
16  - id: RSK-02
17    texto: "Lag del ERP: precio y stock base obsoletos."
18    tratamiento: "Medir lag, definir umbral operativo y fallback."
19    dueno: "Responsable del Desarrollo"
20  - id: RSK-03
21    texto: "Acuerdos especiales sin vigencia."
22    tratamiento: "Pedido pendiente de revisión comercial hasta validar la fecha."
23    dueno: "Responsable comercial"
24  - id: RSK-04
25    texto: "Quiebre físico durante el picking."
26    tratamiento: "Flujo de excepción y ajuste auditado. El sistema no corrige inventario físico."
27    dueno: "Sergio"
28spikes:
29  - id: SPK-01
30    texto: "Idempotencia real de la API fiscal."
31    dueno: "Responsable del Desarrollo"
32  - id: SPK-02
33    texto: "Latencia del registro de pedido con cambios de datos del ERP."
34    dueno: "Responsable del Desarrollo"
35slices:
36  - id: 1
37    texto: "Pedido con precio y crédito, en BORRADOR sin reserva"
38    rn: [RN-01, RN-03]
39  - id: 2
40    texto: "Reserva e idempotencia (alias SLICE-C-RESERVA)"
41    rn: [RN-05, RN-06]
42  - id: 3
43    texto: "Autorización de excepción con reserva blanda"
44    rn: [RN-07]
45dependencias: ["1 -> 2", "1 -> 4", "2 -> 3", "2 -> 5", "5 -> 6"]

Al comparar tu trabajo, preguntate: si el plan dice "primero la base, después la API", ¿qué valor observable se ve antes de la semana cuatro?

D.E09 · Comentario de solución

La semántica correcta de idempotencia distingue reintento idéntico de reutilización conflictiva. El test debe verificar no solo el error, también la ausencia de un segundo pedido/efecto.

D.E09 · Solución comentada ampliada

La evidencia principal no es que el agente "lo resolvió", sino que el alumno controló contexto, plan y diff. Debe existir al menos una decisión que el agente no pudo tomar y fue resuelta o bloqueada correctamente. Refactors oportunistas y reglas inventadas son fallas aunque los tests pasen.

El cambio a implementar es el conflicto cuando el mismo requestId llega con otro contenido. La regla dice que el mismo requestId con el mismo contenido devuelve el mismo pedido, y con contenido distinto produce un conflicto sin efectos nuevos. El contenido se compara con el fingerprint de ADR-006, que incluye cliente, depósito preferido, método de entrega y líneas normalizadas, y que ignora tracing, requestId y sellerId.

Hay dos decisiones que el agente no puede tomar. La primera es el código HTTP del conflicto: 409 está en el contrato, pero la elección entre 409 y 422 no se hace al azar, y la toma una persona. La segunda es si el fingerprint incluye el depósito preferido: el canon lo resuelve incluyéndolo, pero el alumno tiene que registrar que lo verificó contra la RN, no que lo copió.

Qué hizo bien. El prompt de plan delimita los archivos. El test verifica el conflicto y, además, que el conteo de pedidos y el stock reservado no cambiaron. El registro de decisiones humanas lista el código HTTP y el fingerprint.

Qué suele fallar. El agente refactoriza el adaptador de stock "para ordenar" y toca archivos fuera del alcance. Un test que solo verifica el código de error y no la ausencia de efectos. Una regla de expiración de la reserva que el agente inventa porque "parece razonable".

Evidencia que conviene mostrar. El prompt de plan, el plan aprobado, el diff acotado por archivo, el test que falla antes del cambio y pasa después, y los comandos ejecutados con su resultado.

Entregable de ejemplo, el test de conflicto:

1import { test } from "node:test";
2import assert from "node:assert/strict";
3import { fixture } from "../support/fixture.js";
4​
5test("mismo requestId con otro contenido devuelve conflicto sin segundo efecto", async () => {
6  const env = await fixture({ stock: { "SKU-1": 10 } });
7​
8  const first = await env.createOrder({
9    requestId: "req-903",
10    sellerId: "SEL-01",
11    clientId: env.clientId,
12    items: [{ sku: "SKU-1", quantity: 2 }],
13  });
14  assert.equal(first.kind, "confirmed");
15​
16  const second = await env.createOrder({
17    requestId: "req-903",
18    sellerId: "SEL-01",
19    clientId: env.clientId,
20    items: [{ sku: "SKU-1", quantity: 3 }],
21  });
22​
23  assert.deepEqual(second, { kind: "conflict", reason: "request_id_reused" });
24  assert.equal(await env.orders.confirmedCount(), 1);
25  assert.equal(await env.stock.reserved("SKU-1"), 2);
26});

Al comparar tu trabajo, preguntate: ¿tu test falla si alguien borra la validación del conflicto y deja que se cree un segundo pedido?

D.E10 · Comentario de solución

No todos los 12 casos deben vivir en E2E. La carrera por stock requiere integración real; Money puede ser unit; el proveedor fiscal requiere contract/integration; un happy path y una autorización pueden cubrirse E2E.

D.E10 · Solución comentada ampliada

El plan de pruebas competente cubre riesgo, no niveles por obligación. La carrera de stock exige integración concurrente; idempotencia exige retry; rollback exige observar ausencia de efectos. Cobertura alta sin esos escenarios es insuficiente. Una buena solución también identifica escenarios que siguen BLOCKED porque el oráculo no existe.

La matriz de referencia tiene doce casos, T01 a T12, y cada uno está asignado a una AC. La asignación es: T01 a AC-01 y AC-04; T02 a AC-02; T03 a AC-03; T04 a AC-08; T05 a AC-05; T06 a AC-06; T07 y T08 a AC-07; T09 a AC-10; T10 a NFR-03; T11 a la máquina de estados; T12 a AC-12 y NFR-04. Quedan dos huecos que la solución declara: AC-09 (cantidad que respeta el múltiplo de venta, RN-08) y AC-11 (handoff a preparación por outbox). Declarar un hueco es mejor que inventar un test para taparlo.

Qué hizo bien. Cada test defiende una propiedad y lo dice en el nombre. Los negativos verifican que no hubo efectos, no solo el error. La matriz declara los huecos. Y reconoce que los tests de integración están razonados pero no se corrieron contra PostgreSQL real, y lo escribe como limitación.

Qué suele fallar. Un test de rechazo por crédito que verifica el código de respuesta pero no que la reserva quedó en cero. Dos requests secuenciales presentados como prueba de concurrencia. La cobertura del 90% usada como argumento, sin mirar qué líneas son las de la regla.

Evidencia que conviene mostrar. La matriz de riesgo, la RTM con las doce filas, los tests seleccionados con su archivo y la salida de ejecución, y la lista de huecos declarados.

Entregable de ejemplo, la RTM mínima:

1filas:
2  - id: T01
3    ac: [AC-01, AC-04]
4    riesgo: "Camino feliz con precio calculado en el servidor"
5    nivel: "unit + integration + E2E"
6    prueba: "tests/integration/create-order-authority.test.ts"
7  - id: T02
8    ac: [AC-02]
9    riesgo: "Saldo más pedido exactamente en el límite"
10    nivel: unit
11  - id: T03
12    ac: [AC-03]
13    riesgo: "Un centavo sobre el límite, sin reserva"
14    nivel: "unit + integration"
15    prueba: "tests/integration/stock-reservation.test.ts"
16  - id: T04
17    ac: [AC-08]
18    riesgo: "Autorización pendiente y auditada"
19    nivel: integration
20  - id: T05
21    ac: [AC-05]
22    riesgo: "SKU inválido, sin pedido parcial"
23    nivel: integration
24  - id: T06
25    ac: [AC-06]
26    riesgo: "Última unidad con dos reservas concurrentes"
27    nivel: "integration concurrente"
28    prueba: "tests/integration/stock-reservation.test.ts"
29  - id: T07
30    ac: [AC-07]
31    riesgo: "Reintento idéntico, un solo pedido"
32    nivel: integration
33  - id: T08
34    ac: [AC-07]
35    riesgo: "Reutilización conflictiva de requestId"
36    nivel: integration
37    prueba: "tests/integration/idempotency-conflict.test.ts"
38  - id: T09
39    ac: [AC-10]
40    riesgo: "Falla antes del commit, rollback completo"
41    nivel: integration
42  - id: T10
43    ac: [NFR-03]
44    riesgo: "Vendedor fuera de cartera: forbidden, sin datos"
45    nivel: "API / integration"
46  - id: T11
47    ac: ["máquina de estados"]
48    riesgo: "Transición ilegal sobre pedido despachado"
49    nivel: "unit + integration"
50  - id: T12
51    ac: [AC-12, NFR-04]
52    riesgo: "Proveedor fiscal caído después del commit"
53    nivel: "integration / contract"
54huecos_declarados:
55  - AC-09: "Múltiplo de venta (RN-08): sin test asignado."
56  - AC-11: "Handoff a preparación por outbox: sin test asignado."
57limitacion: "Tests de integración razonados, no ejecutados contra PostgreSQL real."

Al comparar tu trabajo, preguntate: ¿tu matriz tiene algún caso sin test, y lo declaraste o lo escondiste bajo un test que no lo cubre?

D.E11 · Comentario de solución

Una demo fuerte incluye happy path, autorización, carrera de stock, fallo fiscal y un caso real no guionado por el usuario. No oculta el TTL abierto.

D.E11 · Solución comentada ampliada

El runbook debe incluir migración, observabilidad y criterio de abortar. Un backup que nunca se restauró no es evidencia. La demo debe mostrar al menos un caso de falla o retry relevante, no solo happy path. Si algo falla en el ensayo, clasificar la causa y corregir antes de producción es parte del ejercicio.

El guion de referencia dura veinte minutos y tiene cinco escenarios ligados a objetivos. Los escenarios son: el camino feliz (AC-01), un pedido que queda pendiente de autorización (AC-08), dos vendedores compitiendo por la última unidad (AC-06), la caída del proveedor fiscal después de confirmar el pedido (AC-12) y un SKU inválido (AC-05). El dataset representa el release con 8.000 SKU, 25 vendedores y 600 clientes. El piloto fiscal corre contra un sandbox.

Qué hizo bien. Cada escenario conecta con un objetivo. Muestra estado en la base, no solo la pantalla. Incluye la caída fiscal y el cierre muestra qué queda BLOCKED.

Qué suele fallar. Una demo sin fallo "para que no se vea mal". Datos sintéticos tan limpios que ningún problema real aparece. Un plan de rollback que dice "volvemos atrás" sin decir qué pasa con los pedidos ya confirmados.

Evidencia que conviene mostrar. El guion con tiempos, el dataset usado, los cinco escenarios con su resultado esperado y el plan de rollback de la demo con sus pasos.

Entregable de ejemplo, el guion de la demo:

1# Guion de demo · release 1 de Nexo (20 minutos)
2Dataset: 8.000 SKU, 25 vendedores, 600 clientes. AX-442 en CBA: 8 unidades, 6 reservadas.
3​
41. (2 min) Contexto: qué se resuelve hoy y qué no se promete todavía.
52. (4 min) Escenario 1, camino feliz. Pedido de una de las dos unidades vendibles de AX-442, con precio desde el servidor. Mostrar: pedido confirmado y reserva descontada.
63. (4 min) Escenario 2, pendiente de autorización. Cliente Platino sobre el límite. Mostrar: estado PENDIENTE_AUTORIZACION, reserva blanda y el registro de quién autoriza.
74. (4 min) Escenario 3, última unidad. Dos vendedores compiten. Mostrar: una reserva gana, la otra recibe stock insuficiente, y la disponibilidad no queda negativa.
85. (3 min) Escenario 4, fallo fiscal. El proveedor no responde después del commit. Mostrar: el pedido sigue válido y la emisión queda reintentable.
96. (3 min) Caso no guionado: el usuario elige un SKU o un cliente y el equipo lo corre en vivo.
10​
11Plan de rollback de la demo: si el sandbox fiscal no responde, se muestra el estado PENDIENTE_FACTURACION y el reintento programado. Si la base no responde, se pasa al video grabado del ensayo, y se anota el incidente.
12​
13Preguntas de validación:
14- ¿Confiarías en el precio que ves en pantalla para pasarle el pedido a preparación?
15- ¿Qué pasaría con el stock si el depósito encuentra un faltante hoy?
16- ¿Qué parte de este flujo no entendés todavía?

Al comparar tu trabajo, preguntate: ¿qué escenario de tu demo muestra una falla, y qué hace el público cuando la ve?

D.E12 · Comentario de solución

La defensa no usa jerga como autoridad. Explica por qué las decisiones reducen riesgo actual, qué costo evitan y qué evidencia haría revisar la arquitectura.

D.E12 · Solución comentada ampliada

La defensa fuerte traduce técnica a consecuencia y puede reconocer límites. Si aparece evidencia nueva, el alumno actualiza su posición. No se evalúa "ganar" la discusión, sino mantener precisión. La propuesta comercial debe evitar absolutos y conectar alcance con resultados y dependencias.

La defensa de referencia tiene un pitch de ocho minutos, una demo de la decisión de la última unidad, cinco objeciones y una lista de límites. Las objeciones salen de cinco personas distintas, y cada respuesta usa un dato o un ADR, no una opinión sobre la tecnología.

Qué hizo bien. Responde cada objeción con la consecuencia en términos de negocio. Admite el límite con precisión: el TTL no está validado y la reserva no corrige inventario físico. Cambia de posición cuando aparece evidencia.

Qué suele fallar. Responder "es más escalable" a una pregunta sobre el costo. Prometer que la reserva resuelve los faltantes de depósito. Presentar un pitch de ocho minutos que ocupa doce y no deja tiempo para las objeciones.

Evidencia que conviene mostrar. El pitch con sus tiempos, la demo de la decisión con el resultado de la prueba concurrente, las cinco objeciones con su respuesta y la lista de límites firmada por quien la presenta.

Entregable de ejemplo, las objeciones y sus respuestas:

1# Objeciones · Defensa del Sprint de Nexo
21. Dueña: "¿Por qué no microservicios? Suenan más modernos."
3   Respuesta: hoy pedido, stock y crédito tienen que cambiar juntos sin un estado a medias. Separarlos vuelve distribuida una operación que hoy es local. Lo revisamos si un módulo necesita escalar por su cuenta (ADR-001).
4​
52. Responsable de depósito: "La reserva no me sirve si el físico está mal."
6   Respuesta: tenés razón. La reserva evita que dos pedidos prometan la misma unidad. No corrige el inventario físico. El ajuste lo hace una persona, queda auditado, y el sistema no lo corrige solo.
7​
83. Comercial: "¿Y el Platino? Siempre se pasa un poco."
9   Respuesta: la tolerancia todavía no está definida. Hoy un pedido sobre el límite queda pendiente de autorización, y esa decisión queda auditada. Cuando se defina la tolerancia, cambia una regla, no la arquitectura.
10​
114. Crédito: "¿Y la factura?"
12   Respuesta: la emisión fiscal queda fuera del primer valor. El pedido queda marcado como pendiente de facturación, y la integración se diseña con un contrato de fallo. No prometemos comprobante en este release.
13​
145. Sistemas: "¿Qué pasa si el ERP va lento?"
15   Respuesta: no lo sabemos todavía con datos reales. Medimos el lag en el spike SPK-02 y definimos un umbral. Si se supera, el precio se toma del último valor confirmado y lo marcamos.
16​
17Límites que presentamos:
18- TTL de la reserva blanda: BLOCKED.
19- Tolerancia Platino: BLOCKED.
20- Emisión fiscal real: integración posterior.
21- Pruebas de integración razonadas, no ejecutadas contra PostgreSQL real.

Al comparar tu trabajo, preguntate: en tu defensa, ¿hay alguna respuesta que empiece con "es que la arquitectura..." sin decir qué riesgo reduce?

D.13 · Cómo usar las soluciones comentadas

No leas una solución comentada inmediatamente después de empezar una práctica importante. Primero producí tu artefacto, marcá decisiones dudosas y ejecutá el gate. Después compará razonamiento, no formato. Una solución alternativa puede ser válida si responde a la misma evidencia y conserva las garantías.

Cuando compares, buscá tres clases de diferencia: una mejor pregunta que no hiciste, una decisión distinta pero defendible y una invención que tu versión introdujo sin fuente. La tercera es la más importante de corregir.

El árbol de comparación te ayuda a clasificar cada diferencia antes de cambiar tu entrega:

Clasificá tres diferencias de ejemplo. El objetivo es practicar la distinción, no acertar una respuesta única.

Para cerrar, escribí tu comparación. La rúbrica pide que nombres la diferencia y que digas qué harías distinto.

Un error frecuente al comparar es cambiar la entrega para parecerse a la solución. Si la diferencia es de forma (orden de las secciones, nombres de archivos, un diagrama en lugar de una lista), no la cambies. Si es de garantía o de regla, sí.

Errores frecuentes

• Síntoma: tu entrega coincide palabra por palabra con la solución comentada. Causa: leíste la solución antes de producir tu artefacto. Corrección: guardá tu entrega, borrá lo que copiaste y rehacé la práctica sin mirar la solución.
• Síntoma: tu solución tiene un número que la comentada no tiene. Causa: el número vino de una conversación, o lo inventaste para cerrar una tabla. Corrección: buscá la fuente o márcalo como desconocido con dueño.
• Síntoma: tu defensa tiene una respuesta que empieza con "es más escalable". Causa: usaste un argumento genérico donde el caso pedía una consecuencia. Corrección: nombrá el riesgo que la decisión reduce y el costo que acepta.
• Síntoma: la RTM tiene doce filas y ninguna declaración de huecos. Causa: se llenó la matriz sin mirar qué AC tiene test. Corrección: asignar cada AC a un test o declararla como hueco.

Para llevarte

• Compará razonamiento, no formato. Una solución alternativa puede ser válida si responde a la misma evidencia.
• Clasificá cada diferencia antes de cambiar tu entrega: pregunta, decisión o invención.
• La invención sin fuente es la diferencia más importante de corregir, aunque parezca un detalle.
• Cada práctica tiene un fallo típico. Revisá el tuyo antes de leer el de la solución.
• Un hueco declarado es mejor que un test que no defiende nada.