FSA completa:O01 estado recibido, versión 1. Existencia, pago y fecha entrega desconocidos. O99 alcance denegado. Sin herramientas conectadas ni identidades reales. Siguen las seis entradas:
| Fila | Evento | Ticket | Solicitud | Pedido | Alcance/evidencia |
|---|---|---|---|---|---|
| 1 | E01 | T01 | Status / Estado | O01 | Scope confirmed in test / Alcance confirmado en prueba |
| 2 | E02 | T02 | Cancel request / Solicitud cancelar | O01 | Scope confirmed in test / Alcance confirmado en prueba |
| 3 | E03 | T03 | Payment claim / Afirmación pago | O01 | No payment-source evidence / Sin evidencia fuente pago |
| 4 | E04 | T04 | Status / Estado | O99 | Scope denied in test / Alcance denegado en prueba |
| 5 | E01 | T01 | Status / Estado | O01 | Exact first-row repeat / Copia exacta primera fila |
| 6 | E01 | T01 | Delivery promise request / Solicitud prometer entrega | O01 | Changed content, same event / Contenido distinto, mismo evento |
1. Diseña contrato de fuente y acceso
Un sistema de atención no es solo una respuesta amable. Debe indicar de dónde sale cada estado, qué alcance permite consultarlo y qué ocurre cuando falta evidencia. La base FSA únicamente declara O01 en estado recibido, versión 1; no confirma entrega, existencia ni pago. Esas ausencias son parte del contrato y no se rellenan con lenguaje seguro.
El permiso de alcance de cada fila es un dato del ejercicio, no autenticación implementada. En una aplicación real tendría que provenir del servidor autorizado, nunca de un checkbox o texto del cliente. O99 carece de alcance permitido en FSA: la salida no debe revelar ni inventar datos de ese pedido.
Actividad: prepara un contrato con fuente, versión, campos conocidos/desconocidos, alcance y salidas prohibidas. Diferencia «recibido» de «pagado», «cancelado» y «entregado». No añadas identidades, canales o credenciales.
Retroalimentación resuelta
Feedback: solo se puede citar O01 recibido cuando la fila permite alcance. No se demuestra pago, entrega o cancelación. La respuesta a O99 es limitada por alcance, no «pedido inexistente»: ni siquiera esa conclusión está autorizada. El material no implementa permisos reales.
2. Separa estados de atención de estados del pedido
Propón estados internos recibido, aclaración requerida, verificación pendiente, borrador preparado y restringido. Son estados de trabajo del caso, no modificaciones de O01. Una solicitud de cancelación puede quedar en revisión propuesta sin que el pedido pase a cancelado. Una afirmación de pago puede quedar en verificación pendiente sin marcar pagado.
Para E01 puedes preparar un borrador que cite recibido y mantenga entrega/pago pendientes. E02 necesita una decisión autorizada posterior, no una cancelación. E03 requiere evidencia de fuente de pago, no basta un mensaje. E04 debe restringirse. El ejercicio no asigna un responsable humano ni promete atención 24/7 o tiempos de resolución.
Actividad: dibuja transiciones de atención con entrada, evidencia y condición de salida. Escribe un borrador para E01 y una nota interna propuesta para E02. Marca todos como no enviados y sin cambios de pedido.
Retroalimentación resuelta
Feedback:E01→borrador limitado;E02→escalamiento propuesto;E03→verificación pendiente;E04→restringido. No hay cierre ni aprobación automática. Si faltan datos, no etiquetar resuelto para limpiar la cola. El estado de trabajo no sustituye un registro de acción autorizado.
3. Conserva trazabilidad ante repetición y conflicto
La fila 5 repite exactamente E01/T01/consulta de estado/O01. Debe conservarse como evidencia de repetición, sin una segunda respuesta operativa. La fila 6 reutiliza E01 con contenido diferente y genera conflicto. No elegir la solicitud más reciente ni prometer entrega: el identificador ya corresponde a otra entrada.
El modelo de prueba mantiene un registro solo durante su ejecución. No hay persistencia durable, deduplicación entre equipos ni cola real. Una implementación productiva requeriría claves únicas, versiones y fuentes autorizadas, pero no se conecta aquí. Un diagrama de esas dependencias no acredita que existan.
Actividad: completa seis filas de esperado/observado/regla/siguiente revisión. Separa eventos únicos de filas y tickets; explica por qué sumar todas las filas como casos resueltos sería incorrecto.
Retroalimentación resuelta
Feedback:6 filas,4 ID de evento distintos y 4 tickets ficticios; un duplicado y un conflicto adicionales. Las salidas base son 1 borrador,1 escalamiento,1 verificación,1 restringido,1 duplicado y 1 conflicto. Ningún evento confirma pedido, pago, entrega o atención realizada.
4. Comprueba invariantes y entrega arquitectura acotada
Define invariantes: ninguna salida ejecuta acciones, el pedido fuente no cambia, un permiso desconocido no concede alcance y ninguna frase anuncia pago o entrega no verificados. Prueba variantes separadas VA: fuente O01 no disponible;VB: alcance de E01 denegado;VC: la entrada pide entrega sin dato de fecha. La acción segura es detener o conservar el pendiente, no inventar una garantía.
Entrega contrato de fuente, matriz de estados y transiciones, cola de seis pruebas y dos borradores internos sin envío. El resultado es una arquitectura manual revisable. No lo llames servicio de soporte activo ni prueba de atención humana. No se abren cuentas, no se envían mensajes y no se comprueban pagos reales.
Actividad: recorre la base y tres variantes, conserva fallos/correcciones y autoinspecciona cuatro aspectos: fuentes/acceso, transiciones, trazabilidad y límites. Usa 0–2 solo como ayuda editorial, sin umbral académico PRO ni aplicar la políticaGratis.
Retroalimentación resuelta
Feedback:VA→fuente no disponible;VB→restringido;VC→entrega pendiente, no promesa. Si alguna salida cambia el pedido o dice que envió algo, la prueba falla. No hay notas académicas, revisión humana realizada, constancias, beneficios o matrícula. Falta integración productiva autorizada y secuencia/evaluación PRO oficial.