Registro #87: la API key de cto entra a producción (el sync vuelve), la vista previa se valida contra el BIND real con FAC-171 y se construye en local el modal en vivo con "Aceptar", la campana y el modo automático configurable; capturas y video del recorrido

bitacora/REGISTRO.md

@@ -1863,11 +1863,44 @@ La bandeja permite marcar varios tickets (solo los que aún no tienen cotizació
 
 ---
 
+## 87 · Sep 30, 2026 — madrugada (≈1:00–1:45 AM) · Producción + desarrollo · La API key de `cto` entra a producción (el sync vuelve tras 20 días), la vista previa se valida contra el BIND REAL (FAC-171) y se construye el MODAL EN VIVO con "Aceptar", la campana y el modo automático configurable ⭐🔥
+
+> Contexto: misma sesión del [#85](REGISTRO.md)/[#86](REGISTRO.md). Instrucciones de Johann en la sesión (sus palabras, con la ortografía normalizada): *"te autorizo cambiar el token en producción, lo siguiente que quiero hacer es validar el flujo de jira-cotización, que cuando se cree un ticket se cree la cotización automáticamente"*; sobre el alcance: *"por ahora, agrega un modal con un 'aceptar', y que después con una animación fluida se vaya a notificaciones si pasa mucho tiempo, y le puedas dar en ver detalle, quiero que se vea que fue en tiempo real, haz configurable el que se haga en automático o el que pida confirmación a través del modal"*; y para el ticket de prueba: *"Autorizo: cliente ACUNTIA, crear y borrar"*. Evidencia: commit local `aac7447` del repo del cliente (**sin push y sin desplegar**), capturas y video en [`../planeacion/modal-en-vivo-2026-09-30/`](../planeacion/modal-en-vivo-2026-09-30/), fila id 2 de `JiraTicketEvents` y operación #155 en la BD de paputec.
+
+**1. La API key nueva ya está en producción.** Con la autorización de Johann se reemplazó `Bind__ApiKey` en `/opt/balam/.env` por la del usuario `cto` (sin imprimirla; huellas comparadas). La anterior quedó comentada en el mismo archivo para rollback. Al reiniciar: **`[sync] Ciclo OK`** — 17 clientes, 1,202 facturas vistas (2 nuevas, 2 actualizadas, 2 pagos detectados) y 3 cotizaciones nuevas. **El sync estaba detenido desde el 10-sep.**
+
+**2. Radiografía del formulario y del catálogo (solo lecturas).** El formulario "Cotización Bind" (service desk 35, request type 1196) exige diez campos: empresa origen, título, cliente (17 opciones), servicio/producto (17), cantidad, moneda, monto sin IVA, IVA (16 %/0 %), vencimiento y descripción. El catálogo de servicios de BIND ya está depurado: **11 ítems, códigos 100–110**. Con las reglas de prellenado de hoy:
+- **Clientes: 17 de 17** opciones del combo resuelven a un único cliente de BIND.
+- **Categorías: 9 de 17.** Las ocho que NO resuelven y caerían en "Faltan datos": *Gestión de Proyectos Senior / PMO*, *Gestión de Mesa de Servicio (SDM)*, *Soporte Especializado Nivel 1 (L1)* y *Nivel 2 (L2)*, *Gestión de Incidentes*, *de Cambios* y *de Capacidad*, y *Servicio de Enlace* (en BIND se llama "Servicio**s** de Enlace", código 106). Falta que Balam diga a qué código va cada una (`Emision:ServicioPorCategoria`; sobran en BIND el 102 "Proffesional Services" y el 106).
+
+**3. Vista previa validada contra Jira y BIND reales, en producción** (dos escrituras en Jira, autorizadas):
+- **Jira-op 7 (01:07:21):** ticket de prueba **FAC-171** creado por el API de Jira Service Management con el formulario completo (ACUNTIA, Servicios Profesionales Generales, 1 × $1,234.00 MXN, IVA 16 %). → detectado **1.04 s** después (HMAC, verificado) → **vista previa `Lista` a los 4.32 s** (incluye la primera lectura de catálogos a BIND) → **operación #155 en `DryRun`**, firmada por `webhook-jira`, sin confirmar. El body quedó como lo armaría la pantalla: cliente ACUNTIA, ítem de código 101, concepto = título del ticket, `Price` 1234, `Qty` 1, `VAT` 0.16, `Type` 2, `VATRate` 0.16, lista de precios "A", `ExchangeRate` 1. **BIND solo recibió lecturas.**
+- **Jira-op 8 (01:07:42):** FAC-171 **borrado** (204; GET → 404). Vivió 21 segundos.
+- ⚠️ El evento id 2 quedó `Lista` en la BD de paputec (su ticket ya no existe). Aceptarlo no crearía nada — la aceptación verifica antes que el ticket siga en Jira — pero aparecerá como pendiente en la campana cuando se publique el modal: descartarlo ahí o limpiarlo al publicar.
+
+**4. Lo construido: del ticket a la cotización, a un clic** (`aac7447`, local):
+- **Modal en vivo.** Al crearse el ticket, a quien tenga la app abierta le aparece solo un modal con la línea de tiempo y sus tiempos reales (creado en Jira → detectado → vista previa → cotización), los números de la cotización y **"Aceptar y crear cotización"**. Llega por un canal abierto del servidor al navegador (SSE); si el canal no se sostiene, la app consulta cada 4 s. La bandeja de solicitudes también se actualiza sola.
+- **Campana.** Si nadie decide en 30 s, el modal vuela con una animación al ícono de la barra superior y queda resaltado, con **"Ver detalle"** para reabrirlo. El cursor encima pausa la cuenta.
+- **Aceptar es la confirmación humana de ADR-001:** se envía a BIND el body exacto del dry-run guardado, una sola vez, con candado en la base para que dos clics o dos personas no creen dos cotizaciones. Si BIND rechaza o no se sabe si creó, queda "sin confirmar" y **no se reintenta sola**. También se puede "Revisar y editar" (la pantalla de siempre) o descartar.
+- **Modo configurable.** En la campana: "Pedir confirmación" (default) o "Crear en automático". El automático **nace apagado dos veces**: el servidor debe permitirlo (`Jira__Webhook__AutoCreateQuoteAllowed`, hoy `false` en paputec) y además elegirlo un usuario con rol de escritura. Tope de monto opcional.
+- Se agregó `deploy/demo-local/`: Jira y BIND falsos para ver todo esto sin tocar los reales.
+
+**5. Verificación.** Backend **170 pruebas** en verde (eran 147) y frontend 10. Incluyen: dos aceptaciones simultáneas → una sola cotización; rechazo de BIND → una sola escritura y sin reintento; ticket borrado → nada se escribe; roles; el canal en vivo entrega "Detectado" y luego "Lista"; modo automático con y sin permiso del servidor, con tope y con BIND en solo lectura. Se comprobó que tres pruebas fallan si se rompe el candado a propósito. **En un navegador real** (Chromium, contra los falsos): el modal apareció **1.3 s** después de crear el ticket (1.0 s es la entrega simulada del webhook), "Aceptar" disponible a los 2.2 s, guardado solo a los 30.5 s, modo automático en 2.3 s, y por sondeo (sin canal en vivo) en 4.3 s. Sin errores de consola. Capturas y video: [`../planeacion/modal-en-vivo-2026-09-30/`](../planeacion/modal-en-vivo-2026-09-30/).
+
+⚠️ **No verificado:** nada de esto corre todavía en paputec. Falta ver el canal en vivo a través de Apache (si lo retuviera, entra el respaldo de 4 s) y **no se ha creado ninguna cotización real con "Aceptar"**: hacerlo en producción crea una cotización de verdad en BIND.
+
+> **Lectura estratégica:**
+> - **La petición literal era "que se cree la cotización automáticamente"; lo que quedó por default es el clic.** El plan del 29-sep dejó la creación sin confirmación fuera de alcance hasta tener autorización escrita de Balam y enmendar ADR-001. El modo automático existe y está probado, pero encenderlo en producción es una decisión que no se tomó en esta sesión.
+> - **El cuello de botella dejó de ser técnico:** con 8 de 17 categorías sin mapear, casi la mitad de los tickets caería en "Faltan datos" aunque todo funcione. Es una tabla de ocho renglones que tiene que dar Balam.
+> - **Tiempos reales medidos:** Jira entrega el aviso en ~1 s y la vista previa queda en 1–4 s. "En tiempo real" es verdad.
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Estado actual (al 30-sep-2026 — Etapa 2 en producción provisional)
 
-**La plataforma está publicada en https://paputec.mx/balam/** desde el 3-sep (ambiente provisional propio; Azure sigue sin entregarse, [#74](REGISTRO.md)/[#76](REGISTRO.md)) y Balam ya la opera en sesiones acompañadas: cotizaciones reales desde tickets, individuales y en lote ([#77](REGISTRO.md)–[#79](REGISTRO.md)). Producción corre con `Bind__Mode=Write` por decisión de Johann del 30-sep ([#85](REGISTRO.md)). **La cadena ya llegó a la prefactura:** por el API público es imposible — `false` = remisión, `true` = CFDI timbrado; incidente 2386 del 26-ago ([#70](REGISTRO.md)), confirmado con el SDK oficial ([#83](REGISTRO.md)) — pero el puente a la UI de BIND (`BindUiClient`, *Generar Venta → Prefactura*, con el login web que Balam entregó el 29-sep) creó ese mismo día la **primera prefactura real, folio 2467** ([#84](REGISTRO.md)); en paputec el puente sigue apagado. **Y la cadena ya arranca sola:** desde el 30-sep el webhook de Jira avisa a producción cada ticket creado en FAC ([#85](REGISTRO.md)). La vista previa automática de la cotización ("Lista para revisar" en la bandeja) también quedó publicada el 30-sep ([#86](REGISTRO.md)); la confirmación sigue siendo humana (ADR-001). **Siguiente hito:** poner en paputec la API key del usuario `cto` — la de `arturo` es la que responde 500; la de `cto` ya se probó con 200 — para que vuelvan el sync y los catálogos, y entonces validar una vista previa real de punta a punta. **Seguimiento con Pedro** (sesiones "Seguimiento PAF" a las 7:00 am o 1:00 pm; informes de Read AI de Noé). Horas al 16-sep: 94.58 h; Excel de avance en Google Sheets ([#82](REGISTRO.md)). **Abiertos:** cambiar en paputec la API key de BIND por la de `cto` (sync detenido desde el 10-sep), prefactura 2467 por confirmar con Balam, cancelación SAT de la 2386, remisiones 1000/1001, Azure, a quién se reportan horas, y el error al cargar la solicitud al crear cotización visto el 29-sep.
+**La plataforma está publicada en https://paputec.mx/balam/** desde el 3-sep (ambiente provisional propio; Azure sigue sin entregarse, [#74](REGISTRO.md)/[#76](REGISTRO.md)) y Balam ya la opera en sesiones acompañadas: cotizaciones reales desde tickets, individuales y en lote ([#77](REGISTRO.md)–[#79](REGISTRO.md)). Producción corre con `Bind__Mode=Write` por decisión de Johann del 30-sep ([#85](REGISTRO.md)). **La cadena ya llegó a la prefactura:** por el API público es imposible — `false` = remisión, `true` = CFDI timbrado; incidente 2386 del 26-ago ([#70](REGISTRO.md)), confirmado con el SDK oficial ([#83](REGISTRO.md)) — pero el puente a la UI de BIND (`BindUiClient`, *Generar Venta → Prefactura*, con el login web que Balam entregó el 29-sep) creó ese mismo día la **primera prefactura real, folio 2467** ([#84](REGISTRO.md)); en paputec el puente sigue apagado. **Y la cadena ya arranca sola:** desde el 30-sep el webhook de Jira avisa a producción cada ticket creado en FAC ([#85](REGISTRO.md)). La vista previa automática de la cotización ("Lista para revisar" en la bandeja) también quedó publicada el 30-sep ([#86](REGISTRO.md)); la confirmación sigue siendo humana (ADR-001). La API key del usuario `cto` entró a producción el 30-sep y el sync volvió; la vista previa se validó contra Jira y BIND reales con FAC-171 ([#87](REGISTRO.md)). **Siguiente hito:** publicar el modal en vivo con "Aceptar" y la campana (construido y probado en local, [#87](REGISTRO.md)) y validarlo en producción con Johann presente; y que Balam mapee las 8 categorías de servicio que hoy no resuelven. **Seguimiento con Pedro** (sesiones "Seguimiento PAF" a las 7:00 am o 1:00 pm; informes de Read AI de Noé). Horas al 16-sep: 94.58 h; Excel de avance en Google Sheets ([#82](REGISTRO.md)). **Abiertos:** decidir si el modo automático (sin confirmación) se enciende en producción — requiere autorización de Balam y enmendar ADR-001 —, prefactura 2467 por confirmar con Balam, cancelación SAT de la 2386, remisiones 1000/1001, Azure, a quién se reportan horas, y el error al cargar la solicitud al crear cotización visto el 29-sep.
 
 ### Datos duros confirmados por Balam
 - **BIND ERP:** API existe y es viable (confirmado 25-may). Límite 20K req/día. PAC para CFDI integrado en BIND.