Registro #86: vista previa automática de la cotización por cada ticket detectado ("Lista para revisar" en la bandeja), construida y probada en local (147 pruebas) y sin publicar; el #85 anota que el sync de producción falla con BIND 500

This commit is contained in:
Johann
2026-09-30 00:46:51 -06:00
parent 7e50c71791
commit daa6a62e86
2 changed files with 34 additions and 8 deletions
+8 -5
View File
@@ -2,13 +2,16 @@
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). 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** — ⭐ 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)). 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-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 **construida en local, sin publicar** ([#86](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)._
## ⭐ 30-sep — webhook de Jira en producción ([REGISTRO #85](REGISTRO.md)) ## ⭐ 30-sep — webhook de Jira en producción ([REGISTRO #85](REGISTRO.md)) y vista previa automática ([#86](REGISTRO.md))
- [ ] 🔧 **Siguiente meta:** con cada `JiraTicketEvent` verificado, armar la **vista previa (dry-run) de la cotización** en BIND y marcar el ticket "lista para revisar" en la bandeja. La confirmación sigue siendo humana (ADR-001). ⚠️ El prellenado resuelve moneda, ubicación, almacén y servicio con los catálogos del API público de BIND (`/api/emision/catalogos`), que hoy responde 500: se puede construir y probar con `FakeHandler`, pero no validar contra BIND hasta que vuelva. - [x] ~~🔧 **Siguiente meta:** con cada `JiraTicketEvent` verificado, armar la vista previa (dry-run) de la cotización y marcar el ticket "lista para revisar" en la bandeja.~~ → **CONSTRUIDA el 30-sep** (commits locales `1c37eaa` y `287cb65`, 147 pruebas en verde, [#86](REGISTRO.md)). La confirmación sigue siendo humana (ADR-001).
- [ ] 🚀 **Johann — decidir push + publicación de la vista previa automática** (`1c37eaa` + `287cb65`: migración aditiva de 5 columnas). ⚠️ Con el API público de BIND en 500, en producción toda vista previa quedará en "Vista previa pendiente" hasta que vuelva; conviene publicarla junto con la API key del usuario `CTO`. Al publicar: abrir la bandeja en el navegador (el chip no se ha visto en pantalla) y, con autorización, un ticket de prueba.
- [ ] 🔧 **Deuda:** las reglas de prellenado viven dos veces (`cotizacion-prefill.ts` y `CotizacionPrefill.cs`). Que las pantallas de cotización (individual y lote) consuman el prellenado y el dry-run ya preparado del servidor.
- [ ] 🔧 Suscribir `jira:issue_updated` (o repetir la vista previa al abrir el ticket) para que "Faltan datos" se actualice cuando alguien completa el ticket en Jira.
- [ ] ⚠️ **Producción corre con `Bind__Mode=Write`** (así estaba en `/opt/balam/.env`; el contenedor anterior llevaba 3 semanas arriba). **Johann decidió dejarlo así el 30-sep.** El runbook y el `CLAUDE.md` de la plataforma siguen diciendo que producción corre en ReadOnly: falta alinear esa documentación con la decisión, o regresarlo a ReadOnly cuando Johann lo indique. - [ ] ⚠️ **Producción corre con `Bind__Mode=Write`** (así estaba en `/opt/balam/.env`; el contenedor anterior llevaba 3 semanas arriba). **Johann decidió dejarlo así el 30-sep.** El runbook y el `CLAUDE.md` de la plataforma siguen diciendo que producción corre en ReadOnly: falta alinear esa documentación con la decisión, o regresarlo a ReadOnly cuando Johann lo indique.
- [ ] 🔑 **El secreto del webhook cambió:** el vigente está en `/opt/balam/.env` (`Jira__Webhook__Secret`) y en `~/jira-webhook-secret.txt` de la MacBook donde se hizo el despliegue. El `~/jira-webhook-secret.txt` de la otra máquina (piloto del 29-sep) **ya no sirve**: reemplazarlo por un canal seguro antes de usar ahí el subcomando `mover`/`registrar`. - [ ] 🔑 **El secreto del webhook cambió:** el vigente está en `/opt/balam/.env` (`Jira__Webhook__Secret`) y en `~/jira-webhook-secret.txt` de la Mac desde la que se hizo el despliegue. El `~/jira-webhook-secret.txt` de la otra máquina (piloto del 29-sep) **ya no sirve**: reemplazarlo por un canal seguro antes de usar ahí el subcomando `mover`/`registrar`.
- [ ] 🧹 Imagen de rollback `balam-api:pre-webhook-20260930` en paputec: borrarla cuando la versión nueva lleve unos días estable. - [ ] 🧹 Imagen de rollback `balam-api:pre-webhook-20260930` en paputec: borrarla cuando la versión nueva lleve unos días estable.
- [ ] 🔧 **Poller de respaldo** del webhook (JQL delta con checkpoint): sigue sin construirse; hoy un aviso perdido no se recupera solo. - [ ] 🔧 **Poller de respaldo** del webhook (JQL delta con checkpoint): sigue sin construirse; hoy un aviso perdido no se recupera solo.
@@ -32,7 +35,7 @@ _Última actualización: **2026-09-30** — ⭐ el webhook de Jira FAC queda **e
- [x] ~~✍️ **Fase 4:** alta del webhook/regla como operación numerada (id, URL, fecha, autorización).~~ → **HECHO: webhook de sitio id 1** (19:05:53). - [x] ~~✍️ **Fase 4:** alta del webhook/regla como operación numerada (id, URL, fecha, autorización).~~ → **HECHO: webhook de sitio id 1** (19:05:53).
- [x] ~~🧪 **Fase 5:** ticket de prueba → "lista para revisar" → verificar que BIND no recibió escritura. Reversa documentada.~~ → **HECHO: FAC-169** creado → detectado en 14.4 s (HMAC, verificado) → borrado. Ver adenda del [#84](REGISTRO.md). - [x] ~~🧪 **Fase 5:** ticket de prueba → "lista para revisar" → verificar que BIND no recibió escritura. Reversa documentada.~~ → **HECHO: FAC-169** creado → detectado en 14.4 s (HMAC, verificado) → borrado. Ver adenda del [#84](REGISTRO.md).
- [x] ~~🔥 **Mover el webhook id 1 a paputec** (`https://paputec.mx/balam/api/jira/webhook`)~~ → **HECHO el 30-sep** ([#85](REGISTRO.md)): plataforma publicada (`5145801`), secreto nuevo en `/opt/balam/.env`, `PUT` del webhook 1 → 200 (solo HMAC, sin token en la URL) y prueba con **FAC-170** detectada en 1.05 s y borrada. - [x] ~~🔥 **Mover el webhook id 1 a paputec** (`https://paputec.mx/balam/api/jira/webhook`)~~ → **HECHO el 30-sep** ([#85](REGISTRO.md)): plataforma publicada (`5145801`), secreto nuevo en `/opt/balam/.env`, `PUT` del webhook 1 → 200 (solo HMAC, sin token en la URL) y prueba con **FAC-170** detectada en 1.05 s y borrada.
- [ ] 🔧 **Siguiente paso de la meta:** vista previa (dry-run) de la cotización por cada detección → pasa al bloque del 30-sep, arriba. - [x] ~~🔧 **Siguiente paso de la meta:** vista previa (dry-run) de la cotización por cada detección.~~ → **Construida el 30-sep** ([#86](REGISTRO.md)); su publicación está en el bloque del 30-sep, arriba.
- [x] ~~☁️ **Destino productivo del webhook:** ngrok con dominio fijo (de pago) vs Azure (sigue bloqueado por el cliente).~~ → **Resuelto por ahora con paputec** (30-sep), el mismo ambiente provisional de la plataforma. Cuando exista Azure, el webhook se mueve con otro `PUT`. - [x] ~~☁️ **Destino productivo del webhook:** ngrok con dominio fijo (de pago) vs Azure (sigue bloqueado por el cliente).~~ → **Resuelto por ahora con paputec** (30-sep), el mismo ambiente provisional de la plataforma. Cuando exista Azure, el webhook se mueve con otro `PUT`.
- [ ] ⚠️ **Una sola sesión de Claude Code dueña de la API** en sesiones de escritura (el 29-sep otra sesión la relanzó en ReadOnly). - [ ] ⚠️ **Una sola sesión de Claude Code dueña de la API** en sesiones de escritura (el 29-sep otra sesión la relanzó en ReadOnly).
- [ ] 🔥 **API público de BIND en 500 en todos los endpoints** (key de Arturo) — sync detenido desde el 10-sep. Pedir a Balam la API key del usuario `CTO` o revisar el acceso de Arturo. - [ ] 🔥 **API público de BIND en 500 en todos los endpoints** (key de Arturo) — sync detenido desde el 10-sep. Pedir a Balam la API key del usuario `CTO` o revisar el acceso de Arturo.
+26 -3
View File
@@ -1803,13 +1803,13 @@ La bandeja permite marcar varios tickets (solo los que aún no tienen cotizació
--- ---
## 85 · Sep 30, 2026 — madrugada (≈12:10–12:45 AM) · Despliegue · 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 ⭐ ## 85 · Sep 30, 2026 — madrugada (≈12:10–12:35 AM) · Despliegue · 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 ⭐
> Contexto: sesión de Johann con Claude Code, continuación del [#84](REGISTRO.md) en la otra máquina (la que tiene la llave SSH de paputec). **Autorizaciones de Johann dadas en la sesión, una por una:** ejecutar el plan (pull, publicación, secreto), el `PUT` del webhook, y crear + borrar el ticket de prueba. Evidencia: commit `9351aa4` del repo del cliente, fila id 1 de `JiraTicketEvents` en la BD de paputec y log del contenedor `balam-api`. > Contexto: sesión de Johann con Claude Code, continuación del [#84](REGISTRO.md) en la otra máquina (la que tiene la llave SSH de paputec). **Autorizaciones de Johann dadas en la sesión, una por una:** ejecutar el plan (pull, publicación, secreto), el `PUT` del webhook, y crear + borrar el ticket de prueba. Evidencia: commit `9351aa4` del repo del cliente, fila id 1 de `JiraTicketEvents` en la BD de paputec y log del contenedor `balam-api`.
**1. Las dos bitácoras del 29-sep chocaban.** Esta máquina tenía sin publicar los registros [#71](REGISTRO.md)–[#83](REGISTRO.md) (commit `3de2739`); la otra publicó la sesión del webhook también como "#71". Al fusionar (commit `e88b5e1`) la del webhook pasó a ser el [#84](REGISTRO.md), con nota de renumeración. Lección: antes de numerar un registro, `git pull`. **1. Las dos bitácoras del 29-sep chocaban.** Esta máquina tenía sin publicar los registros [#71](REGISTRO.md)–[#83](REGISTRO.md) (commit `3de2739`); la otra publicó la sesión del webhook también como "#71". Al fusionar (commit `e88b5e1`) la del webhook pasó a ser el [#84](REGISTRO.md), con nota de renumeración. Lección: antes de numerar un registro, `git pull`.
**2. Publicación en paputec.** Plataforma en `5145801` (cuatro commits nuevos para producción: `4d6b3d8` puente a la UI de BIND, `d7238da` webhook, `8479e96`, `5145801`). Antes de publicar: **116 pruebas en verde** (13 + 14 + 51 + 38), respaldo manual de la BD (`balam-20260930-062117.sql.gz`) y la imagen anterior etiquetada `balam-api:pre-webhook-20260930` para rollback. `deploy/paputec/deploy.sh` completo (frontend + API) → API sana, frontend 200. La migración `20260930005018_JiraTicketEvents` se aplicó al arrancar (la última aplicada era la del 12-ago). Log de arranque: solo los dos mensajes benignos del runbook. **El puente a la UI de BIND queda apagado en producción** (no hay `Bind__Ui__*` en el `.env`; default `Enabled=false`). **2. Publicación en paputec.** Plataforma en `5145801` (cuatro commits nuevos para producción: `4d6b3d8` puente a la UI de BIND, `d7238da` webhook, `8479e96`, `5145801`). Antes de publicar: **116 pruebas en verde** (13 + 14 + 51 + 38), respaldo manual de la BD (`balam-20260930-062117.sql.gz`) y la imagen anterior etiquetada `balam-api:pre-webhook-20260930` para rollback. `deploy/paputec/deploy.sh` completo (frontend + API) → API sana, frontend 200. La migración `20260930005018_JiraTicketEvents` se aplicó al arrancar (la última aplicada era la del 12-ago). Log de arranque: los dos mensajes benignos del runbook y, en cuanto corre el scheduler, **el ciclo de sync falla con `BIND API 500 on /api/Clients`** (tres reintentos y `fail`, a los 15 s del arranque y otra vez a los 15 min): es el bloqueo conocido del API público, ahora confirmado en el log de producción. **El puente a la UI de BIND queda apagado en producción** (no hay `Bind__Ui__*` en el `.env`; default `Enabled=false`).
**3. Secreto nuevo.** `openssl rand -base64 32`, guardado en `~/jira-webhook-secret.txt` (0600) de esta máquina y agregado a `/opt/balam/.env` como **`Jira__Webhook__Secret`** (doble guion bajo: la clave de configuración es `Jira:Webhook:Secret`). Nunca se imprimió; se compararon los sha256 de ambos lados y coinciden. `docker compose up -d api`. El secreto del piloto del 29-sep (el que iba en la URL de ngrok) queda sin uso. **3. Secreto nuevo.** `openssl rand -base64 32`, guardado en `~/jira-webhook-secret.txt` (0600) de esta máquina y agregado a `/opt/balam/.env` como **`Jira__Webhook__Secret`** (doble guion bajo: la clave de configuración es `Jira:Webhook:Secret`). Nunca se imprimió; se compararon los sha256 de ambos lados y coinciden. `docker compose up -d api`. El secreto del piloto del 29-sep (el que iba en la URL de ngrok) queda sin uso.
@@ -1833,11 +1833,34 @@ La bandeja permite marcar varios tickets (solo los que aún no tienen cotizació
--- ---
## 86 · Sep 30, 2026 — madrugada (≈12:35–12:50 AM) · Desarrollo · Vista previa AUTOMÁTICA de la cotización por cada ticket detectado: "Lista para revisar" en la bandeja — construida y probada en local, SIN publicar
> Contexto: misma sesión del [#85](REGISTRO.md); es la "siguiente meta" del plan del webhook ([#84](REGISTRO.md)). Evidencia: commits locales `1c37eaa` y `287cb65` del repo del cliente (**sin push y sin desplegar**: eso espera la orden de Johann). No se tocó Jira, BIND ni producción.
**Qué hace.** Cada `JiraTicketEvent` verificado se encola y un trabajador en segundo plano prepara, fuera de la petición del webhook (Jira no espera a BIND), el **dry-run de la cotización** de ese ticket: relee el ticket, carga los catálogos de BIND, prellena con las mismas reglas de la pantalla y guarda el body en `WriteOperations` como `DryRun` firmado por `webhook-jira`. El resultado queda en el evento y la bandeja lo pinta en la columna BIND:
- **Lista para revisar** — el dry-run está guardado; falta que un humano lo revise y confirme.
- **Faltan datos** — con el detalle: cliente sin coincidencia única en BIND, categoría `Servicio/Producto` sin mapear a un código, o sin monto. No adivina.
- **Vista previa pendiente** — BIND o Jira no respondieron; un barrido la reintenta cada 15 min durante 7 días y se detiene en la primera falla para no quemar cuota.
- Ticket ya cotizado o borrado: no se pinta nada.
**Lo que NO cambia (ADR-001).** El servicio solo hace lecturas (GET a Jira y a los catálogos de BIND) y no tiene ningún camino a la creación de la cotización: confirmar sigue siendo de un humano en la pantalla de cotización. Las pruebas lo afirman contra un BIND y un Jira falsos que registran cada petición. `Bind__Mode` no se tocó.
**Cómo está construido.** `VistaPreviaCola` + `VistaPreviaWorker` + `VistaPreviaCotizacionService`; `CotizacionPrefill.cs` es un **port fiel de `cotizacion-prefill.ts`** (más la carga de `emitir-cotizacion.ts`); `CatalogosEmision` comparte lectura y caché con `GET /api/emision/catalogos`; la validación y el armado del body se extrajeron del endpoint para que la vista previa y la pantalla usen los mismos. Migración aditiva `JiraTicketEventsVistaPrevia` (5 columnas en `JiraTicketEvents`). `POST /api/jira/eventos/{id}/vista-previa` la repite a mano (rol de escritura). Apagable con `Jira__Webhook__AutoPreview=false`.
**Verificación.** Suite completa en verde: **147 pruebas** (antes 116): 24 casos del prellenado y 7 de integración sobre Postgres real (ticket completo → Lista con el body correcto y solo GETs; incompleto → dice qué falta; BIND en 500 → Error y reintento; ya cotizado; repetición a mano con permisos; apagado; y el contrato de `GET /api/emision/catalogos`, que la pantalla sigue leyendo igual). Frontend compila. ⚠️ **No verificado:** el chip no se vio en un navegador, y nada se probó contra el BIND real (API público en 500).
> **Lectura estratégica:**
> - **En producción, hoy, toda vista previa quedaría en "pendiente":** el prellenado necesita los catálogos del API público de BIND, que sigue en 500. La pieza está lista para el día que Balam entregue la API key del usuario `CTO`; el barrido recogería solo lo acumulado de los últimos 7 días.
> - **Deuda consciente:** las reglas de prellenado viven dos veces (TypeScript y C#). Hay pruebas del lado del servidor y avisos en ambos archivos, pero lo correcto es que las pantallas consuman el prellenado del servidor.
> - **Limitación:** el estado es una foto del momento de la creación. Si alguien completa el ticket en Jira después, "Faltan datos" no se entera (el webhook solo escucha `issue_created`); se repite a mano o al abrir la pantalla.
---
## Resumen ejecutivo del hilo (para contexto rápido) ## Resumen ejecutivo del hilo (para contexto rápido)
### Estado actual (al 30-sep-2026 — Etapa 2 en producción provisional) ### 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)). **Siguiente hito:** con cada detección, armar la vista previa (dry-run) de la cotización y marcar el ticket "lista para revisar"; la confirmación sigue siendo humana (ADR-001). **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:** API público de BIND en 500 con la key de Arturo (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)). **Siguiente hito:** publicar la vista previa automática de la cotización ("Lista para revisar" en la bandeja), ya construida en local ([#86](REGISTRO.md)) — depende de que el API público de BIND vuelva; la confirmación sigue siendo humana (ADR-001). **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:** API público de BIND en 500 con la key de Arturo (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.
### Datos duros confirmados por Balam ### 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. - **BIND ERP:** API existe y es viable (confirmado 25-may). Límite 20K req/día. PAC para CFDI integrado en BIND.