Registro #89: el timbrado entra a la plataforma (prefactura → CFDI por el puente, EmitCFDI sobre el mismo documento) con dry-run, palabra TIMBRAR, verificación por lectura y bloqueo de reenvío; la cadena completa queda revisada (estado incierto de los POST de escritura cerrado, consecutivo sin la serie B, uso CFDI solo del mismo cliente), probada (212 + 10 pruebas, recorrido completo en navegador) y publicada (f5b3743) para la prueba del 1-oct con Balam; guion de la prueba y capturas del recorrido

2026-09-30 22:45:22 -06:00
parent 604cb8da8e
commit 987454767f
13 changed files with 117 additions and 5 deletions
@@ -2,14 +2,25 @@
 Acciones vivas del proyecto. Formato: `[ ]` abierta · `[x]` cerrada (no se borran, dejan rastro). Cada una con responsable y, si aplica, fecha. Ver contexto en [REGISTRO.md](REGISTRO.md).
-_Última actualización: **2026-09-30, noche** — 🔥 **el puente de prefactura queda ENCENDIDO en producción** (sin credenciales del usuario `CTO` en el servidor: bloqueo del control de permisos, decisión de Johann pendiente), «Servicio de Enlace» mapeado al 106 y 11 cotizaciones con estado atrasado corregidas; lo que Pedro vio a las 7:26 (totales en cero, botones que "no llevan a ninguna parte", "servicios", Arturo) tenía detrás **cuatro bugs reales**, corregidos, probados (197 + 10 pruebas) y **publicados en paputec a las 9:44 PM** (`597c8a2`, migración `QuoteSubtotal`); las credenciales del usuario `CTO` entraron al servidor a las 9:41 PM con autorización de Johann: el puente queda completo ([REGISTRO #88](REGISTRO.md)). Anterior: **2026-09-30** — ⭐ el webhook de Jira FAC queda **en producción (paputec)**: publicado, secreto nuevo, webhook id 1 movido y prueba de punta a punta con FAC-170 en 1.05 s ([REGISTRO #85](REGISTRO.md)); y la vista previa automática de la cotización queda **publicada** ([#86](REGISTRO.md)). 🔥 **La API key de `cto` ya está en producción y el sync volvió**; la vista previa se validó contra el BIND real (FAC-171) y el **modal en vivo con "Aceptar"** quedó **publicado** a las 6:53 AM, con el modo automático permitido en el servidor pero sin elegir ([#87](REGISTRO.md)). Además, fusión de las dos sesiones paralelas del 29-sep: la del webhook pasa a ser el [#84](REGISTRO.md) (nació como #71 en la otra máquina). Anterior: **2026-09-29** — ⭐ Balam entrega **login web a BIND** con permisos de prefactura; endpoint interno de la UI confirmado (*Generar Venta → Prefactura*, petición `InvoiceDetails`) y el modelo de dos endpoints corroborado con el SDK oficial ([REGISTRO #83](REGISTRO.md)). **Huecos de registro cerrados:** las sesiones del 21-ago al 10-sep se reconstruyeron desde el buzón ([#71](REGISTRO.md)–[#82](REGISTRO.md)). Anterior: **2026-09-15** — corte de horas 10-ago→15-sep reconstruido y huecos de registro listados (seis sesiones sin bitácora). Anterior: **2026-08-21, mediodía** — ⭐ primera cotización real emitida (folio 1026; la 2.ª, corregida, pendiente de confirmar). Anterior: **2026-08-20, noche.** Cruce completo del buzón contra la bitácora (MCP ms365): se incorporaron 9 comunicaciones faltantes y se corrigieron 2 errores de registro. **Hay sesión mañana viernes 21-ago, 7:00 am** con Noé, Ara y Pedro sobre el formulario modificado y `FAC-106`. Ver [REGISTRO #65](REGISTRO.md)–[#68](REGISTRO.md)._
+_Última actualización: **2026-10-01, madrugada** — ⭐🔥 **el TIMBRADO entra a la plataforma** (prefactura → CFDI por el puente, con dry-run, palabra TIMBRAR, verificación por lectura y bloqueo de reenvío), la cadena completa queda revisada (estado incierto de los POST cerrado, consecutivo sin la serie B, uso CFDI del mismo cliente), probada (212 + 10 pruebas, recorrido completo en navegador) y **publicada** (`f5b3743`) para la **prueba completa del 1-oct con Balam**; guion en `planeacion/` ([REGISTRO #89](REGISTRO.md)). Anterior: **2026-09-30, noche** — 🔥 **el puente de prefactura queda ENCENDIDO en producción** (sin credenciales del usuario `CTO` en el servidor: bloqueo del control de permisos, decisión de Johann pendiente), «Servicio de Enlace» mapeado al 106 y 11 cotizaciones con estado atrasado corregidas; lo que Pedro vio a las 7:26 (totales en cero, botones que "no llevan a ninguna parte", "servicios", Arturo) tenía detrás **cuatro bugs reales**, corregidos, probados (197 + 10 pruebas) y **publicados en paputec a las 9:44 PM** (`597c8a2`, migración `QuoteSubtotal`); las credenciales del usuario `CTO` entraron al servidor a las 9:41 PM con autorización de Johann: el puente queda completo ([REGISTRO #88](REGISTRO.md)). Anterior: **2026-09-30** — ⭐ el webhook de Jira FAC queda **en producción (paputec)**: publicado, secreto nuevo, webhook id 1 movido y prueba de punta a punta con FAC-170 en 1.05 s ([REGISTRO #85](REGISTRO.md)); y la vista previa automática de la cotización queda **publicada** ([#86](REGISTRO.md)). 🔥 **La API key de `cto` ya está en producción y el sync volvió**; la vista previa se validó contra el BIND real (FAC-171) y el **modal en vivo con "Aceptar"** quedó **publicado** a las 6:53 AM, con el modo automático permitido en el servidor pero sin elegir ([#87](REGISTRO.md)). Además, fusión de las dos sesiones paralelas del 29-sep: la del webhook pasa a ser el [#84](REGISTRO.md) (nació como #71 en la otra máquina). Anterior: **2026-09-29** — ⭐ Balam entrega **login web a BIND** con permisos de prefactura; endpoint interno de la UI confirmado (*Generar Venta → Prefactura*, petición `InvoiceDetails`) y el modelo de dos endpoints corroborado con el SDK oficial ([REGISTRO #83](REGISTRO.md)). **Huecos de registro cerrados:** las sesiones del 21-ago al 10-sep se reconstruyeron desde el buzón ([#71](REGISTRO.md)–[#82](REGISTRO.md)). Anterior: **2026-09-15** — corte de horas 10-ago→15-sep reconstruido y huecos de registro listados (seis sesiones sin bitácora). Anterior: **2026-08-21, mediodía** — ⭐ primera cotización real emitida (folio 1026; la 2.ª, corregida, pendiente de confirmar). Anterior: **2026-08-20, noche.** Cruce completo del buzón contra la bitácora (MCP ms365): se incorporaron 9 comunicaciones faltantes y se corrigieron 2 errores de registro. **Hay sesión mañana viernes 21-ago, 7:00 am** con Noé, Ara y Pedro sobre el formulario modificado y `FAC-106`. Ver [REGISTRO #65](REGISTRO.md)–[#68](REGISTRO.md)._
 ## 🔥🔥 1-oct — PRUEBA COMPLETA con Balam: ticket → cotización → prefactura → CFDI ([REGISTRO #89](REGISTRO.md), [guion](../planeacion/Guion-prueba-completa-2026-10-01.md))
 - [ ] 🔥 **Johann — seguir el guion** durante la llamada: nadie en BIND como `CTO`; ticket con cliente de BIND y una de las 10 categorías mapeadas; monto reconocible; leer el **método de pago (PUE/PPD)** en el dry-run del CFDI antes de teclear TIMBRAR; acordar quién cancela el CFDI de prueba.
 - [ ] 🔴 **Primer `EmitCFDI` contra el BIND real** — lo único no verificado: la forma de la respuesta y los textos de rechazo del PAC. Anotar en la bitácora lo que devuelva (queda en `WriteOperations.ResultJson`).
 - [ ] 📋 **Pedir a Balam en la llamada:** los códigos de BIND de las 7 categorías sin mapear y si quieren el **modo automático** (sin clic) — con autorización escrita (ADR-001).
 - [ ] 🔧 **Al cerrar la prueba:** cancelar el CFDI en BIND (Balam) → «Verificar» en la plataforma → *Cancelada*; registrar folio, UUID y tiempos en el #90.
 - [ ] 🧹 Imagen de rollback `balam-api:pre-timbrado-20261001` en paputec: borrarla con las demás `pre-*` cuando la versión lleve unos días estable.
 - [ ] 🧹 Evento de prueba **FAC-171** (id 2, `Lista`, ticket borrado): descartarlo desde la campana antes de la llamada para que no estorbe.
 - [ ] 🔧 Deuda: la tarjeta de timbrado no vive aún en el detalle de la factura (`/facturas/:id`) para prefacturas hechas a mano en BIND (p. ej. la 2463 de Pedro); hoy se timbra desde el ticket o desde Cotizaciones.
 - [ ] 🔧 Deuda: el método de pago de la prefactura lo decide BIND (PUE) aunque el cuerpo lleve PPD; si Balam quiere PPD por default, hay que entender qué campo manda (`PaymentMethodCFDI33`/`PaymentTermType` del cliente) o editar la prefactura en BIND antes de timbrar.
 ## 🔥 30-sep (noche) — prefactura desde producción ([REGISTRO #88](REGISTRO.md))
 - [x] ~~🔑🔴 **Johann — credenciales del usuario `CTO` de BIND en `/opt/balam/.env`**~~ → **HECHO el 30-sep, 9:41 PM, con autorización explícita de Johann** (adenda del [#88](REGISTRO.md)): las tres variables en el `.env` (root 0600), huella verificada en el contenedor, API sana. El puente ya entra solo a la web app; la cookie queda como respaldo.
 - [x] ~~🚀 **Johann — decidir push + publicación de `597c8a2`**~~ → **HECHO el 30-sep, 9:44 PM** (adenda del [#88](REGISTRO.md)): push a GitHub y a git.paputec.mx, respaldo `balam-20261001-034359.sql.gz`, imagen `balam-api:pre-prefactura-20260930`, migración `QuoteSubtotal` aplicada, bundles nuevos servidos. Primer ciclo del sync: 50 subtotales; los 67 restantes en los dos ciclos siguientes.
 - [ ] 🧹 Imagen de rollback `balam-api:pre-prefactura-20260930` en paputec (ya son cuatro `pre-*-20260930`): borrarlas cuando la versión lleve unos días estable.
- [ ] 🧪 **Primera prefactura real desde producción**, solo con Johann frente a la app (cotización de prueba con monto reconocible → cancelar la prefactura en BIND después). Antes de eso, nadie debe usar el usuario `CTO` en un navegador mientras la plataforma opera (una sesión por usuario).
+- [ ] 🧪 ~~**Primera prefactura real desde producción**, solo con Johann frente a la app~~ → **pasa a la prueba completa del 1-oct** (bloque de arriba): cotización → prefactura → CFDI en una sola sesión con Balam.
 - [x] ~~📋 Mapear «Servicio de Enlace»~~ → **HECHO el 30-sep, 8:04 AM:** `Emision__ServicioPorCategoria__ServicioDeEnlace=106` en producción. Era la causa de "faltaba el campo de servicios" en FAC-172/173 (el campo sí llegaba; faltaba el mapeo). Quedan **7 categorías** sin ítem en BIND (bloque del #87, abajo).
 - [ ] 📋 **Confirmar con Balam** que la prefactura **2467** aparezca Cancelada por decisión suya (así se ve en BIND el 30-sep) y que las cotizaciones **1084/1085** de la sesión con Pedro se cancelaron a propósito.
 - [ ] ⚠️ **Una sola sesión operando el servidor.** Entre 7:28 y 7:43 AM otra sesión tocó `Seed__Admin__Password` en el `.env` de producción y reinició el API dos veces mientras esta sesión diagnosticaba. Dos manos en `/opt/balam/.env` al mismo tiempo pueden pisarse cambios.
@@ -21,7 +32,7 @@ _Última actualización: **2026-09-30, noche** — 🔥 **el puente de prefactur
 - [ ] 🧪 **Validar en producción con Johann frente a la app:** ticket de prueba (con autorización) → modal en vivo → "Aceptar". ⚠️ Eso crea una **cotización REAL en BIND**: usar un monto de prueba reconocible y cancelarla después.
 - [ ] 🔴 **Modo automático: el servidor ya lo PERMITE** (`Jira__Webhook__AutoCreateQuoteAllowed=true`, decisión de Johann del 30-sep) pero nadie lo ha elegido: producción sigue pidiendo confirmación. Antes de que alguien lo elija en la campana: **archivar la autorización escrita de Balam, enmendar ADR-001** y fijar un tope (`Jira__Webhook__AutoCreateMaxSubtotal`, hoy sin definir). Para volver a prohibirlo: `false` en el `.env` y `up -d api`.
 - [ ] 📋 **Pedir a Balam (Pedro) el código de BIND para 7 categorías** del combo Servicio/Producto que no resuelven y caen en "Faltan datos": Gestión de Proyectos Senior / PMO · Gestión de Mesa de Servicio (SDM) · Soporte Especializado L1 · L2 · Gestión de Incidentes · de Cambios · de Capacidad. Se cargan en `Emision__ServicioPorCategoria__…` del `.env`. *(30-sep: «Servicio de Enlace» → 106 ya está en producción, [#88](REGISTRO.md); 10 de 17 categorías y 17 de 17 clientes resuelven. Las 7 restantes no tienen ítem equivalente en el catálogo de BIND de 11 ítems: necesitan un ítem nuevo o una decisión de Balam.)*
- [ ] 🧹 **Evento de prueba FAC-171** (id 2 en paputec, `Lista`, ticket ya borrado): descartarlo desde la campana al publicar, o limpiarlo por SQL.
+- [ ] 🧹 **Evento de prueba FAC-171** (id 2 en paputec, `Lista`, ticket ya borrado): descartarlo desde la campana (sigue ahí al 1-oct).
 - [ ] 🧹 La API key anterior (usuario `arturo`) quedó **comentada** en `/opt/balam/.env` para rollback: borrarla cuando la de `cto` lleve unos días estable.
 - [ ] 👀 En esta Mac sigue corriendo desde el **3-sep** una instancia local del API (puerto 5078) y del frontend (4200), con el código de ese día: no se tocó. Apagarla o reiniciarla cuando convenga.
 - [ ] 🔧 La tabla de la bandeja se sale del ancho a 1440 px (la columna BIND y los botones quedan cortados); ya pasaba antes del chip nuevo.
@@ -67,7 +78,7 @@ _Última actualización: **2026-09-30, noche** — 🔥 **el puente de prefactur
 - [x] ~~🔥 **API público de BIND en 500 en todos los endpoints** (key de Arturo)~~ → **RESUELTO el 30-sep** con la key del usuario `cto` en producción ([#87](REGISTRO.md)). Original: — sync detenido desde el 10-sep. Pedir a Balam la API key del usuario `CTO` o revisar el acceso de Arturo. **→ 30-sep: causa encontrada.** El API no está caído: la key de `arturo` es la que falla; la de `cto` responde 200. Falta cambiarla en paputec (bloque del 30-sep, arriba).
 - [ ] 🔥 **Prefactura 2467 ($777,777 MXN, ACUNTIA, FAC-166):** confirmar con Balam si es prueba (cancelar/borrar antes de que alguien la timbre) o real; revisar que al timbrar quede **PPD**, no el PUE que BIND le puso.
 - [ ] 📧 **Avisar a Pedro de la cotización 1079 marcada como Surtida por error** (`QuotesAPI/FillQuote` escribe por GET); sin efecto fiscal, irreversible desde la UI.
- [ ] 🔧 Tomar el bloque `Client` de `ClientsAPI/GetClientSelectedById` (hoy `CFDI_Use` puede heredarse de la factura de OTRO cliente) y que el wizard no muestre G03/16% cuando el puente manda lo de BIND.
+- [ ] 🔧 Tomar el bloque `Client` de `ClientsAPI/GetClientSelectedById` y que el wizard no muestre G03/16% cuando el puente manda lo de BIND. *(1-oct: el uso CFDI ya no se hereda de otro cliente — solo del mismo, o 23/S01 con aviso — [#89](REGISTRO.md); el bloque exacto sigue pendiente.)*
 - [ ] 📝 **Hueco de bitácora:** registrar el trabajo del 9/10-sep (puente a la UI de BIND, prefactura 2463, sonda #12 / remisión 1004) — hoy solo vive en `balam-plataforma/CLAUDE.md`.
 ## 🚨 Huecos de registro (detectados en el corte del 15-sep)
@@ -1939,11 +1939,40 @@ La bandeja permite marcar varios tickets (solo los que aún no tienen cotizació
 ---
 ## 89 · Sep 30, 2026 — 10:00 PM–12:50 AM · Desarrollo + producción · El TIMBRADO entra a la plataforma (prefactura → CFDI por el puente) y la cadena completa queda revisada, probada y PUBLICADA para la prueba del 1-oct con Balam ⭐🔥
 > Contexto: Johann, a las 10:00 PM: *"Mañana haré una prueba completa creando una facturación, asegura que se pueda crear una factura desde una prefactura, una prefactura de una cotización y que se pueda crear una cotización desde un ticket de Jira; revisa todos los edge cases y todas las excepciones que puedan ocurrir."* Ante la pregunta de si el paso prefactura → factura sería humano en BIND (como hasta hoy) o desde la plataforma: *"será en la plataforma, tendré llamada con ellos"*; y autorizó push + publicación esta noche. Evidencia: commit `f5b3743` del repo del cliente (publicado 10:40 PM), capturas del recorrido en [`../planeacion/cadena-completa-timbrado-2026-10-01/`](../planeacion/cadena-completa-timbrado-2026-10-01/), guion de la prueba en [`../planeacion/Guion-prueba-completa-2026-10-01.md`](../planeacion/Guion-prueba-completa-2026-10-01.md).
 **1. Hechos con fuente primaria (antes de escribir código):**
 - **Cómo convierte BIND una prefactura en factura:** en el `app.js` de su web app, la página de detalle de la venta tiene `emitCFDI()` → `POST /InvoicesAPI/EmitCFDI { ID }` y recarga la misma página. **El documento es el mismo** (misma GUID, mismo folio): al timbrar le aparece el UUID e `IsFiscalInvoice` pasa a true. Lo confirma la **2464** del 15-sep: factura timbrada que conserva el comentario "Generada desde el ticket FAC-163" que puso nuestra cotización (y la 2466 del 29-sep, nacida de la cotización 1082 y timbrada 37 s después).
 - **Hasta hoy la plataforma no timbraba:** la cadena publicada llegaba a prefactura; el CFDI era humano en BIND y la plataforma lo reflejaba con «¿Ya se timbró? Verificar» y con el sync (una prefactura abierta queda dentro de la ventana del barrido). **Ninguna prefactura hecha desde la plataforma había llegado a factura** (la 2467 se canceló; la 2463 de Pedro sigue sin timbrar).
 - **Usuarios de producción:** `admin@balam.paputec.mx` (Dirección + Finanzas), `finanzas@…` (Finanzas), `sistemas@…` (Administración): los tres pueden operar escritura. Tenant en "Pedir confirmación". Eventos FAC-172/173 resueltos como *Cotizada* (1084/1085, hechas a mano tras "Faltan datos"); FAC-171 sigue *Lista* (ticket borrado: descartar).
 - **El filtro OData compuesto funciona:** `Number ge 2460 and Number lt 10000` devuelve 8 filas (serie vacía 2460–2467); `Number ge 2460` a secas devuelve 100 filas de las que **92 son de la serie B (24xxx)** — con más facturas B, el consecutivo de la secuencia compartida quedaba invisible y la prefactura salía con el folio de la BD (atrasada hasta 15 min).
 **2. Lo construido (`f5b3743`):**
 - **`POST /api/emision/timbrar-ui`** (`PrefacturaUiEndpoints`, `BindUiClient.EmitirCfdiAsync`) con el protocolo entero de ADR-001 porque es la única escritura con efecto fiscal: (1) la venta debe existir en la BD, sin UUID y activa, **y BIND debe decir lo mismo en ese momento** — ya con UUID → 409 y se corrige la BD; cancelada → 409; el API aún no la muestra → 409 "reintenta en un minuto"; (2) **dry-run** (operación `UI_InvoicesAPI_EmitCFDI(timbrar)`) con lo que saldrá en el CFDI: cliente, RFC, total, **método de pago según BIND (PUE/PPD, con aviso si es PUE porque Balam usa PPD)**, forma de pago, el uso CFDI y método que viajaron al crear la prefactura (leídos de su operación), RFC genérico; (3) confirmar exige **`confirmacion=TIMBRAR`** (la pantalla lo pide tecleado en un `prompt`) y `Bind:Ui:Mode=Write`; (4) tras el 2xx se relee el documento hasta ver el UUID (`FacturaDesdeDetalle.Aplicar`: Emitida → Vigente con su transición, compartido con «Verificar»); si el API aún no lo muestra, queda `Confirmed` con `timbrada=false` y «Verificar» lo completa; (5) **bloqueo de 10 min por venta** tras cualquier envío, también si BIND no respondió.
 - **Estado incierto cerrado en los dos POST de escritura.** Un `HttpRequestException`/timeout al guardar la prefactura caía como 500, la operación quedaba en DryRun sin `ConfirmedAtUtc` y el usuario podía reintentar → **duplicado posible**. Ahora `BindUiEnvioInciertoException`: se bloquea el reenvío, se busca el documento por folio (prefactura) o se relee el UUID (timbrado) y, si aparece, se sigue como éxito; si no, 502 "no se sabe si lo creó: revísalo en BIND; bloqueado 10 min".
 - **Consecutivo de la prefactura:** `Number ge N and Number lt 10000`. **Uso CFDI:** se hereda solo de facturas del mismo cliente (antes el último recurso era la última factura timbrada de quien fuera: un uso ajeno habría salido en el CFDI); sin historial, 23 (S01) con aviso.
 - **Frontend:** `TimbradoUiCard` debajo de la prefactura recién creada (tarjeta del puente, así que también en Cotizaciones) y en la puerta del wizard, que ahora dice "ya está facturado" con la cadena completa cuando hay UUID (`facturaUuid` en el detalle del ticket). La maqueta deshabilitada "Timbrar CFDI (etapa futura)" desaparece. Un rechazo del PAC se lee completo en la tarjeta.
 - **Pruebas:** `TimbradoUiEndpointTests` (13: dry-run sin escribir, confirmación única con Emitida → Vigente, sin palabra, puente en ReadOnly, rol, ya timbrada según BIND, cancelada, API sin mostrarla, rechazo del PAC con motivo legible y reintento permitido, sin respuesta con UUID por lectura, sin respuesta sin UUID → 502 + bloqueo + Verificar, API lento → Confirmed + Verificar, venta desconocida) + 2 de la prefactura sin respuesta. **Suite: 212 backend (13+14+60+125) + 10 frontend**, en verde. Los falsos (`BindUiFalso`, `BindFalso`, `falsos.py`) saben timbrar, rechazar, callarse y retrasar el UUID.
 - **Recorrido completo en navegador** (`deploy/demo-local/cadena.cjs`, 10 capturas): cotización → prefactura → **timbrado rechazado por el PAC (se lee el motivo) → timbrado OK con UUID**; ticket → modal → Aceptar → wizard → prefactura → dry-run del CFDI con el API "lento" (409 "aún no muestra la prefactura") → timbrado aceptado sin UUID aún → **Verificar → Timbrada** → puerta "ya está facturado" con la cadena entera → *Facturas* con la fila en Vigente.
 **3. Publicación (10:40 PM):** push de `f5b3743`, respaldo `balam-20261001-044041.sql.gz`, imagen de rollback `balam-api:pre-timbrado-20261001`, `deploy.sh` (frontend + API), arranque limpio, `POST /api/emision/timbrar-ui` responde 401 sin token (existe y exige sesión), bundles servidos con la tarjeta de timbrado y sin la maqueta. Sin migración nueva. La demo local se apagó y su base se borró.
 ⚠️ **No verificado:** `EmitCFDI` contra el BIND real — la primera vez que corra será mañana, con un CFDI real que luego hay que cancelar. Lo que no se sabe de la respuesta (forma del 2xx, texto de los rechazos) está cubierto: el éxito se confirma por lectura del UUID y el rechazo se muestra tal cual venga. El método de pago con el que BIND timbrará las prefacturas del puente parece ser PUE (así dejó la 2467): el dry-run lo avisa y hay que cambiarlo en BIND antes de timbrar si debe ir PPD.
 > **Lectura estratégica:**
 > - **La cadena completa existe por primera vez en la plataforma** (ticket → cotización → prefactura → CFDI) y cada eslabón tiene el mismo esqueleto: estado leído de BIND al momento, dry-run auditado, confirmación humana escrita, verificación por lectura y bloqueo contra el reenvío. ADR-001 se cumple también en el paso fiscal.
 > - **La regla que más vale la noche:** un POST de escritura sin respuesta no es "no pasó nada". Es lo que diferencia un sistema que duplica documentos bajo presión de uno que se detiene y pregunta.
 > - **Mañana lo que se prueba no es el código, es BIND:** el PAC validará el receptor (RFC, régimen, CP, uso CFDI). Si rechaza, la plataforma lo dice en pantalla y no queda nada timbrado; el arreglo es en la ficha del cliente en BIND.
 ---
 ## 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)); **desde el 30-sep el puente está encendido y completo en paputec** (credenciales del usuario `CTO` en el servidor) ([#88](REGISTRO.md)). **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)). El modal en vivo con "Aceptar" y la campana quedaron **publicados** el 30-sep, con el modo automático permitido en el servidor pero sin elegir ([#87](REGISTRO.md)). Al probarlo con Pedro el 30-sep salieron totales en cero, cotizaciones con estado atrasado y una categoría sin mapear; detrás había cuatro bugs reales (importes del detalle de BIND siempre en cero, USD mostrado en pesos, el post-proceso del puente tronando, duplicados posibles), corregidos, probados y **publicados en paputec la noche del 30-sep** (`597c8a2`, migración `QuoteSubtotal`) ([#88](REGISTRO.md)). **Siguiente hito:** primera prefactura real desde producción con Johann frente a la app, y que Balam dé el código de BIND de las 7 categorías de servicio que 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:** archivar la autorización de Balam y enmendar ADR-001 antes de que alguien elija el modo automático (el servidor ya lo permite), prefactura 2467 (ya Cancelada en BIND) y cotizaciones 1084/1085 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)); **desde el 30-sep el puente está encendido y completo en paputec** (credenciales del usuario `CTO` en el servidor) ([#88](REGISTRO.md)), **y desde la noche del 30-sep la plataforma también TIMBRA** (prefactura → CFDI por `EmitCFDI`, con dry-run, palabra TIMBRAR y verificación por lectura) ([#89](REGISTRO.md)). **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)). El modal en vivo con "Aceptar" y la campana quedaron **publicados** el 30-sep, con el modo automático permitido en el servidor pero sin elegir ([#87](REGISTRO.md)). Al probarlo con Pedro el 30-sep salieron totales en cero, cotizaciones con estado atrasado y una categoría sin mapear; detrás había cuatro bugs reales (importes del detalle de BIND siempre en cero, USD mostrado en pesos, el post-proceso del puente tronando, duplicados posibles), corregidos, probados y **publicados en paputec la noche del 30-sep** (`597c8a2`, migración `QuoteSubtotal`) ([#88](REGISTRO.md)). **Siguiente hito: la prueba completa del 1-oct con Balam** (ticket → cotización → prefactura → CFDI, [guion](../planeacion/Guion-prueba-completa-2026-10-01.md)) — el primer `EmitCFDI` contra el BIND real —, y que Balam dé el código de BIND de las 7 categorías de servicio que 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:** resultado del primer timbrado real (cancelar el CFDI de prueba), archivar la autorización de Balam y enmendar ADR-001 antes de que alguien elija el modo automático (el servidor ya lo permite), prefactura 2467 (ya Cancelada en BIND) y cotizaciones 1084/1085 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.
@@ -0,0 +1,72 @@
 # Guion — prueba completa en producción: ticket → cotización → prefactura → factura (1-oct-2026)
 Para la llamada con Balam. Producción (https://paputec.mx/balam/) corre el commit `f5b3743` desde las 22:40 del 30-sep, con el puente a la web app de BIND **encendido y con credenciales** (usuario `CTO`) y el timbrado desde la plataforma publicado y probado contra BIND/Jira falsos ([REGISTRO #89](../bitacora/REGISTRO.md)). Todo lo de abajo escribe en el **BIND de producción**: la cotización y la prefactura son reales, y el CFDI también.
 ## 0. Antes de empezar (5 min)
 - [ ] **Usuario de la plataforma con permiso de escritura:** `admin@balam.paputec.mx` (Dirección + Finanzas) o `finanzas@balam.paputec.mx`. Un rol de solo consulta ve la tarjeta pero no puede generar ni timbrar (lo dice en pantalla).
 - [ ] **Nadie entra a app.bind.com.mx con el usuario `CTO` durante la prueba.** BIND permite una sesión por usuario: si alguien está dentro como `CTO`, la plataforma recibe "sesión abierta en otro equipo" (409 con instrucciones). Pedro/Araceli entran con su propio usuario si quieren mirar.
 - [ ] **El ticket de Jira** (formulario *Cotización Bind* del proyecto FAC) con:
  - *Cliente*: uno que exista en BIND con ese nombre (los 17 del combo resuelven). Para que el CFDI salga sin fricción, un cliente con facturas timbradas recientes (de él se hereda el uso CFDI) — p. ej. el que usen siempre para pruebas.
  - *Servicio/Producto*: una de las **10 categorías que ya resuelven** (p. ej. "Servicios Profesionales Generales" → 101 o "Servicio de Enlace" → 106). Las 7 sin mapear (PMO, Mesa de Servicio/SDM, Soporte L1, L2, Gestión de Incidentes, de Cambios, de Capacidad) caen en **"Faltan datos"** y la cotización se completa a mano en la pantalla (sigue funcionando, con un paso más).
  - *Monto sin IVA* reconocible (p. ej. `1234`), *Cantidad* 1, *IVA* según el cliente (0 % para extranjero), *Moneda* MXN.
 - [ ] **Modo de la campana en "Pedir confirmación"** (es como está): el modal aparece y alguien da "Aceptar". Si Balam quiere ver el modo automático, se cambia ahí mismo (el servidor ya lo permite) — ese cambio crea cotizaciones sin clic en adelante; decidirlo con ellos.
 - [ ] **Acordar el final:** el CFDI será real. Quién lo cancela en BIND (motivo SAT 02 "sin relación") y cuándo. La plataforma lo reflejará como *Cancelada* con «Verificar» o en el siguiente sync.
 - [ ] (Johann) ventana al servidor para seguir la prueba: `ssh johann@paputec.mx` y `sudo docker logs -f balam-api 2>&1 | grep -v "libgssapi"`.
 ## 1. Ticket → cotización (lo que debe verse)
 1. Pedro crea el ticket en Jira. En **1–5 s** aparece en la plataforma el modal *"Ticket FAC-nnn detectado"* con la línea de tiempo (creado → detectado → vista previa) y los números de la cotización preparada.
 2. **"Aceptar y crear cotización"** → *"Cotización N creada"*. En *Cotizaciones (BIND)* la fila nueva aparece con su **total correcto de inmediato** (ya no $0.00) y la columna *Ticket* con FAC-nnn.
 3. En *Solicitudes (Jira)* el ticket muestra "Cotizada · N".
 Si algo no sale:
 - **No aparece el modal:** mirar la campana (punto verde = canal en vivo; ámbar = consulta cada 4 s) — el aviso está ahí como pendiente, con "Ver detalle". Si tampoco: *Solicitudes (Jira)* → el ticket dice "Lista para revisar" o "Faltan datos"; desde ahí "Cotizar".
 - **"No se pudo armar la cotización sola" (Faltan datos):** el detalle dice qué falta (cliente sin coincidencia única, categoría sin mapear, monto). "Ver detalle" → pantalla de cotizar → completar → *Vista previa* → *Confirmar*. Mismo resultado.
 - **"Fallida" (BIND rechazó):** el motivo queda en el aviso; se cotiza desde la pantalla. Nunca se reintenta solo (una escritura que falló pudo haber llegado).
 - **Dos personas dan Aceptar a la vez:** solo una crea; la otra ve "ya se está creando / ya tiene cotización".
 ## 2. Cotización → prefactura
 1. En el ticket: **"Facturar"** (wizard). Paso 1 trae **solo la cotización vinculada**, ya seleccionada, con subtotal y total (sin IVA doble). Pasos 2–4: datos, concepto, borrador. Paso 5: aprobador (solo Araceli) → **"Aprobar prefactura"**.
 2. Tarjeta **"Prefactura vía UI de BIND"** (dice *Sesión automática · CTO @ 128469*):
   - **"2 · Ver JSON exacto (dry-run)"** → resumen (cliente, partidas, subtotal, **folio previsto** = consecutivo real de BIND, hoy 2468) y la lista de **avisos** (uso CFDI heredado, método de pago…). Leerlos.
   - **"3 · Generar prefactura en BIND →"** → confirmación → *"Prefactura (sin timbrar, folio de la secuencia compartida)"* con folio, total, "UUID null (sin timbrar ✓)".
   - También se puede desde *Cotizaciones (BIND)* → "Generar prefactura" (el panel se abre debajo de la fila).
 3. En BIND: Ventas → la prefactura con ese folio, generada por "Noé Rocha Castillo" (usuario CTO), cotización surtida.
 Si algo no sale:
 - **409 "La cotización N ya está surtida/cancelada en BIND":** BIND manda; se refleja en la BD. Hay que partir de otra cotización activa.
 - **409 "BIND ya aceptó una prefactura de la cotización N hace M min":** ya existe; no se manda otra en 10 min. Buscarla en BIND / recargar el ticket ("ya está en prefactura").
 - **409 "sesión abierta en otro equipo":** alguien está en BIND como `CTO`; que cierre sesión ahí, o esperar unos minutos a que expire.
 - **502 "BIND no respondió al guardar… No se sabe si creó la prefactura":** NO reintentar. Revisar en BIND; si existe, el sync (≤ 15 min) la trae y el ticket la muestra; la plataforma bloquea 10 min el reenvío.
 - **"Prefactura creada… Su API aún no la muestra":** normal (el API de BIND tarda ~1 min en ver lo que crea la web app). Seguir al paso 3 cuando el dry-run del CFDI ya la lea.
 ## 3. Prefactura → factura (timbrado) — efecto fiscal
 Debajo de la prefactura aparece **"Factura (CFDI) desde la prefactura · folio"** (también en el ticket, "ya está en prefactura").
 1. **"1 · Ver con qué saldrá el CFDI (dry-run)"** → resumen: cliente, **RFC**, **total**, **método de pago según BIND (PUE/PPD)**, forma de pago, uso CFDI enviado al crearla, partidas; y los avisos. **Leer el método de pago:** BIND deja las prefacturas en PUE ("PAGO EN UNA SOLA EXHIBICIÓN"); si debe salir PPD, **se cambia en BIND antes de timbrar** (la plataforma no modifica la prefactura: pide emitirla tal cual está).
 2. **"2 · Timbrar en BIND (emitir CFDI) →"** → el navegador pide teclear **`TIMBRAR`** → en 3–15 s: **"✓ Timbrada — ya es factura · CFDI {uuid}"**, chip *Timbrada ✓*, botón "Ver la factura →".
 3. Comprobar: el ticket dice **"FAC-nnn ya está facturado"** con la cadena completa (cotización ✓ · prefactura ✓ · factura ✓ uuid); en *Facturas* el folio pasó de *Prefactura* a **Vigente** con UUID; en BIND el documento tiene UUID (mismo folio).
 Si algo no sale:
 - **409 "BIND aún no muestra la prefactura por su API":** esperar un minuto y repetir el dry-run.
 - **502 "BIND rechazó el timbrado (500): <motivo>":** es el PAC/BIND (RFC no inscrito, régimen, código postal, uso CFDI…). Nada quedó timbrado. Corregir el dato en BIND (ficha del cliente o la prefactura) y volver a "2 · Timbrar".
 - **"BIND aceptó el timbrado; su API aún no muestra el UUID":** normal; **"¿Ya se timbró? Verificar"** al minuto. No se reenvía (bloqueo de 10 min).
 - **502 "BIND no respondió al timbrar… no se sabe si emitió":** NO reintentar; "Verificar" al minuto o mirar en BIND. Bloqueo de 10 min.
 - **409 "ya está timbrada (CFDI …)":** alguien la timbró en BIND; la plataforma ya lo reflejó.
 - **409 "cancelada en BIND":** no se timbra; generar otra prefactura desde una cotización activa.
 ## 4. Cierre
 - Cancelar el CFDI de prueba en BIND (quien Balam decida). En la plataforma: "Verificar" en la tarjeta → *Cancelada*; el ticket vuelve a mostrar solo la cotización (surtida).
 - Lo que se creó queda auditado en `WriteOperations` (dry-run, confirmación, resultado) y en la bitácora de la app.
 - Pedir a Balam en la misma llamada: **los códigos de BIND de las 7 categorías** sin mapear y si quieren el **modo automático** (sin clic) — en ese caso, autorización escrita (ADR-001).
 ## Lo que la plataforma NO hace (para no prometerlo en la llamada)
 - No edita la prefactura (método/forma de pago, uso CFDI, domicilio fiscal): eso se hace en BIND antes de timbrar.
 - No manda el correo al cliente ni descarga PDF/XML del CFDI: viven en BIND (el PDF de factura sí se ve por el proxy en *Facturas*).
 - No cancela CFDI.
 - No reintenta sola una escritura: ante la duda, bloquea y pide verificar.