Cómo se comporta en pruebas el ejemplo de canalización de consultas

¿Qué hizo realmente este ejemplo?

El 8 de octubre de 2026 revisamos cinco rutas definidas en el flujo ficticio de consultas de Northstar Plumbing. Cada ruta se ejecutó con las reglas de consultas del repositorio y, por separado, con el paquete descargable del kit inicial. La tabla registra esos resultados concretos; no es un caso de estudio de clientes ni una cifra de confiabilidad en producción.

Los datos y las expectativas se definieron primero.

El dato de prueba completo es Alex Morgan, alex@example.com, Bristol BS1, que pregunta por una llave de la cocina que lleva una semana goteando. El dato de prueba incompleto es Sam Taylor, sam@example.com, sin área y con el mensaje “Can you help?”. Son contactos ficticios.

El caso de duplicado vuelve a enviar la solicitud de Alex con otro nombre visible, texto en mayúsculas y espacios de más. La aprobación repetida intenta reemplazar una respuesta ya aprobada. El caso de recuperación usa el indicador explícito de falla simulada, intenta saltarse la restauración, restaura el mismo registro y luego lo vuelve a aprobar.

Ejecútalo y compara tu propio resultado.

Descarga el kit inicial 1.0.0, extráelo y sigue su README. Las revisiones incluidas contienen los estados y las comprobaciones esperados. Ejecuta node verify.mjs para generar un informe nuevo con los datos, las expectativas y el historial observado de los cinco casos. Si un caso falla, el comando termina con error.

La ejecución del código fuente del repositorio llamó directamente a las funciones auxiliares actuales en TypeScript. La ejecución del kit inicial cargó el JavaScript empaquetado sin importar archivos del repositorio. Sus definiciones de prueba compartidas hacen que la comparación sea reproducible; las dos ejecuciones no son una prueba independiente de que cada regla posible sea correcta.

El paquete también tiene un ensayo de pausa por separado.

El envoltorio de línea de comandos del paquete agrega almacenamiento en un archivo local y controles de pausa y reanudación. Su ensayo de once comandos inicializó un registro, simuló una falla, pausó, intentó una restauración bloqueada, reanudó, restauró, aprobó dos veces y reinició. La restauración en pausa terminó con error a propósito y dejó el estado sin cambios. Reanudar no volvió a ejecutar ninguna acción.

Es una revisión negativa exitosa, no una prueba fallida sin reportar. node cli-check.mjs ejecuta la secuencia en una carpeta temporal y luego la elimina. Estas funciones de CLI no están en la demo del navegador.

Lo que queda sin demostrar

La memoria de duplicados del navegador desaparece al reiniciar, recargar o cambiar de flujo. El kit inicial guarda un archivo local, pero no tiene bloqueo multiusuario ni un almacén de registros para producción. Un mensaje modificado puede ser una consulta nueva; esta clave no puede decidir si dos solicitudes redactadas de forma distinta describen el mismo trabajo.

Una implementación real necesitaría identificadores duraderos de solicitudes y acciones, una decisión sobre las solicitudes modificadas y revisiones del destino antes de reintentar. Son adiciones necesarias, no soluciones demostradas por estos resultados locales. La falla simulada no envía nada, así que no prueba una conexión que actuó con éxito y luego perdió su confirmación.

De estos cinco casos no se desprende ningún ahorro de mano de obra para clientes, tasa de conversión, integración en vivo, disponibilidad ni entrega exactamente una vez. Por separado, el conjunto de pruebas unitarias existente del repositorio aprobó 21 revisiones de la función auxiliar de consultas. Ese conjunto más amplio es una cobertura útil contra regresiones, no 21 pruebas con clientes ni 21 sesiones de navegador.