Una demo que funciona no es un flujo de cliente completado: mantenga un registro de aceptación en tres capas

El problema: una marca verde, tres afirmaciones

Una demo puede estar en verde sin que el flujo del cliente se haya ejecutado nunca. Según el estado publicado por GridZen, en la ruta de identidad alojada están evidenciados la creación real de sesiones, los callbacks firmados y la lectura autoritativa, pero una persona nueva que complete todo el recorrido alojado y una acción de negocio del cliente siguen sin verificar. Las pruebas del operador no son demanda de clientes. Si su registro tiene una sola fila llamada "onboarding de identidad", no puede saber qué ha probado. Su decisión: ¿qué capa está realmente listo para aprobar y qué bloquea la siguiente?

Diseño propuesto: registro de aceptación en tres capas

Esto es un diseño de aplicación propuesto, no comportamiento implementado por GridZen. Mantenga un registro por piloto con tres capas. Capa 1, fixture local: evidencia de que su handler trata correctamente aprobación, duplicados, correcciones y expiración con datos sintéticos. Capa 2, ruta aprobada: evidencia de que una cuenta de comerciante verificada presentó una solicitud de piloto, de que el responsable revisó propósito, acuerdos posteriores, derechos del proveedor, capacidades, cupo gratuito y expiración, y de que la ruta está confirmada como activa. Las solicitudes nunca habilitan producción automáticamente. Capa 3, acción real posterior: evidencia de que un usuario real, con un propósito permitido, completó una sesión, su servicio volvió a leer la decisión autoritativa, aplicó su propia política y ejecutó una acción de negocio acotada. Cada capa tiene su responsable, fecha y referencia de evidencia, y ninguna capa puede marcarse completa con evidencia de una capa inferior.

Ejemplo hipotético: rellenar la Capa 1

Hipótesis: un pequeño equipo de marketplace ejecuta la tarea identity del ejemplo descargable. La creación devuelve mode synthetic_fixture, state simulated, session fixture-session, hosted_link hacia una dirección example.invalid, link_executable false y next send_real_provider_link_only_after_authorization. Un evento sintético Approved con política explícita produce status approved, deadline 60, permission_granted true, grant_count 1, live_permission_changed false, policy_version 1, allow_action true. Repetir el mismo evento devuelve el registro idéntico, con grant_count aún 1. Una corrección posterior Declined produce status declined, permission_granted false, grant_count 1. Para una sesión pendiente más allá de su plazo, recover devuelve status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh y provider_polled false. El equipo anota estos valores literalmente en la Capa 1. Observe live_permission_changed false en cada fila: ese campo indica que la Capa 3 no ha ocurrido.

Manejo de fallos que el registro debe cubrir

Los fallos también pertenecen a la Capa 1. Un evento para una sesión desconocida genera BINDING_MISMATCH; leer una sesión desconocida genera SESSION_NOT_FOUND. Los eventos deben usar identificadores sintéticos que empiecen por fixture-; cualquier otro modo u origen genera PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED, porque el fixture no tiene verificador real de firmas. Cambiar la política con una versión esperada incorrecta genera STALE_POLICY_VERSION, y una decisión explícita sin evidencia aprobada vigente genera CURRENT_EVIDENCE_AND_EXPLICIT_APPROVAL_REQUIRED. Recover expira el estado localmente; nunca consulta a un proveedor. Su registro debe indicar qué comportamiento propio maneja cada error, por ejemplo enviar a revisión manual en lugar de reintentar a ciegas.

Lo que el fixture no demuestra

El permiso del fixture es un registro local en SQLite, no un permiso real de vendedor o usuario. Superar todas las filas de la Capa 1 no dice nada sobre la elegibilidad de la Capa 2, los cupos del proveedor ni los derechos posteriores, que deben comprobarse antes de activar. Distinga además este ejemplo de la prueba HTTP anónima sin registro: esa prueba devuelve respuestas sintéticas en tres escenarios y es un artefacto distinto del ejemplo descargable con sus cuatro ramas de teléfono y su máquina de estados de identidad. Indique cuál ejecutó.

Lista práctica de aceptación

Capa 1: todas las salidas anteriores registradas con sus valores; el duplicado no cambia grant_count; la corrección anula permission_granted; la expiración informa provider_polled false; ambos códigos de error manejados. Capa 2: solicitud de piloto enviada desde una cuenta de comerciante verificada; resultado de la revisión registrado; disponibilidad de la ruta confirmada por separado; un UUID de idempotencia por solicitud y lectura del registro existente tras interrupciones. Capa 3: sesión real completada por un usuario permitido; decisión autoritativa releída; versión de política y decisión explícita registradas; una acción posterior ejecutada y reversible. Deje la Capa 3 abierta hasta que todo exista.

Siguiente paso

Ejecute el tutorial sintético correspondiente de la guía customer-pilot, rellene la Capa 1 e inspeccione cómo su código maneja cada fallo. Cree una cuenta sandbox solo cuando necesite registros guardados. Después decida si una integración sandbox encaja con su tarea antes de solicitar una ruta de piloto real.

Ejecutar el ejemplo sintético comprobado

Descargue y extraiga https://gridzen.ai/downloads/verification-delivery.zip, entre en verification_delivery y ejecute con Python 3.10+. El ejemplo local no hace llamadas de red. Use una base nueva para otra prueba de identidad.

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

Fuentes y alcance

https://gridzen.ai/guides/customer-pilot/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.