Registro #63: Noé confirma la sesión del mié 12-ago 7:00 am, rutea el molde a Araceli y suma Azure a la agenda; sondeo nocturno del 11-ago: el molde aún no existe y FAC-98 lleva 17 días en el estatus disparador

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

bitacora/PENDIENTES.md

@@ -2,22 +2,22 @@
 
 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-08-10 (Balam definió el flujo Jira→BIND en el correo del 7-ago: disparador = `En proceso de facturación`, todos los request types, monto/conceptos como campos de Jira, prueba acompañada sin `FACTEST`. Verificado por API el 10-ago: el campo `Monto sin IVA` ya existe, pero **los conceptos no tienen campo** y **10 de 69 tickets no traen datos estructurados**. Ver [REGISTRO #62](REGISTRO.md))._
+_Última actualización: 2026-08-11, noche (Noé **confirmó la sesión del mié 12-ago, 7:00 am**, ruteó el ticket de ejemplo a **Araceli** y propuso explorar Azure en la misma sesión con una cuenta nueva. **El molde aún no existía la noche del 11** — plan B: captura en vivo al abrir. Ver [REGISTRO #63](REGISTRO.md); contexto de las definiciones en [#62](REGISTRO.md))._
 
 ## 🔥 Flujo Jira→BIND — abierto tras la definición del 7-ago
 
 - [x] ~~🔥 **Johann — responder el correo del hilo de Jira**~~ → **Enviado el 10-ago.** Pide ticket de ejemplo, propone mié 12 / jue 13 a las 7:00 am, fija el alcance en la cotización y recuerda Azure. Texto en [REGISTRO #62](REGISTRO.md).
-- [ ] 🔥 **Balam — levantar el TICKET DE EJEMPLO capturado "como debería ser"** (pedido para hoy/mañana en el correo del 10-ago). Tarea **dejada sin asignar a propósito** para que Balam la ruteé; en la práctica es de Arturo. Es el mecanismo elegido para resolver por evidencia, y no por correo, los huecos de abajo. ⚠️ **Riesgo: el precedente de latencia es de 8 días** (pregunta del 30-jul contestada el 7-ago). Si no hay respuesta para mañana al mediodía, empujar por WhatsApp con Erika, que es el canal que responde el mismo día.
-- [ ] 🔥 **Balam/Noé — confirmar la sesión** (mié 12 o jue 13, 7:00 am). Sin fecha confirmada no hay prueba acompañada.
+- [ ] 🔥 **Araceli — levantar el TICKET DE EJEMPLO capturado "como debería ser"** — Noé lo ruteó a **Araceli** en su respuesta del 11-ago (la apuesta era Arturo; lo captura quien aprueba). ⚠️ **La noche del 11 el molde aún no existe** (verificado por API: el sitio sigue en 69 tickets). **Plan B si no está a las 7:00: que Araceli lo capture EN VIVO al abrir la sesión** (captura → detección → wizard con sus datos); **plan C: `FAC-100`** (único con `Monto sin IVA` poblado — de paso abre ACUNTIA). Sigue siendo el mecanismo para resolver por evidencia los huecos de abajo.
+- [x] ~~🔥 **Balam/Noé — confirmar la sesión** (mié 12 o jue 13, 7:00 am)~~ → **CONFIRMADA por Noé (11-ago, 10:41 am): miércoles 12-ago, 7:00 am.** Además, **Azure se explora en la misma sesión** con una cuenta nueva creada para este uso. Ver [REGISTRO #63](REGISTRO.md).
 - [ ] 🔴 **Conceptos/partidas — se resuelve con el ticket de ejemplo.** El acuerdo del 4-ago resolvió el monto (`customfield_11556`) pero **no existe campo de conceptos en todo el sitio de Jira**. Si en el molde el desglose no cabe en ningún campo, hay que agregar uno; si no, la cotización va de una sola línea. **Sigue siendo el único bloqueo real para cerrar B7.**
 - [ ] 🔴 **ACUNTIA — se resuelve con el segundo ticket de ejemplo.** `FAC-100` trae **un solo** `Monto sin IVA` (7,594.00 USD) para el ticket que históricamente representa 40–48 facturas. ¿Un ticket → una cotización? Ver [REGISTRO #55](REGISTRO.md) punto 6.
 - [ ] ⚠️ **Tickets de `Automation for Jira` — convertido en SUPUESTO, ya no bloquea.** 10 de 69 no tienen request type ni un solo campo (incluido `FAC-91`, vivo en validación nacional). En el correo del 10-ago se asienta que **siguen tramitándose a mano** y que la automatización cubre solo los que entran por el portal. Si Balam objeta, la regla de Automation tendría que propagar los campos (trabajo de ellos). El molde capturado a mano no puede resolver esto.
-- [ ] ⚠️ **Johann — decidir el destino de la cotización de la prueba en BIND.** El ejercicio escribe una **cotización real en BIND producción**. Anunciado en el correo, con dos salidas ofrecidas: cancelarla al terminar o apuntarla a un cliente de prueba. Definir cuál antes de la sesión.
+- [ ] ⚠️🔥 **Johann — decidir el destino de la cotización de la prueba en BIND.** El ejercicio escribe una **cotización real en BIND producción**. Dos salidas: cancelarla al terminar o apuntarla a un cliente de prueba. **Decidir esta noche y anunciarlo al abrir la sesión del 12, antes de ejecutar.**
 - [ ] 🔴 **¿El comercial ya genera la cotización en BIND, o la genera la plataforma?** Contradicción abierta: el 6-jul Ara dijo que **el comercial la genera y la plataforma la convierte** a prefactura ([REGISTRO #27](REGISTRO.md)); el 4-ago Arturo dijo que **la plataforma la genera**; y el formulario de Jira sigue exigiendo **adjuntar la cotización**. Si ambas cosas ocurren, **quedan dos cotizaciones por ticket**. Se resuelve viendo qué adjunto pone Arturo en el ticket de ejemplo: cotización de BIND ya existente (→ convertir) o documento comercial (→ crear).
 - [x] ~~**Alcance del ejercicio en vivo: ¿cotización o prefactura?**~~ → **Decidido (10-ago): termina en la COTIZACIÓN.** Es lo que contestó Arturo el 4-ago; la aprobación de Araceli va entre `En proceso de facturación` y `Facturado`, así que la prefactura pertenece después; Arturo pidió gradualismo explícito; y la cotización se cancela sin efecto fiscal mientras la prefactura es un registro en `Invoices` con `UUID = null`. La prefactura queda para la segunda sesión. Candados acordados: **cotización → prefactura → aprobación humana → timbrado** ([REGISTRO #55](REGISTRO.md)).
 - [ ] ⚠️ **La transición automática depende de Azure.** En la prueba del miércoles el disparo es **manual** (pipeline `Draft→DryRun→Confirmed` de ADR-001 con flags apagados). Para que corra automática hace falta el ambiente publicado y corriendo continuo — otro argumento para insistir en el acceso a Azure.
-- [ ] 🔥 **Johann — preparar el script contra el ticket de ejemplo** en cuanto Arturo lo levante, para llegar a la sesión con el flujo funcionando. Compartirlo con Balam **antes** de la sesión (protocolo del Bloque 6 de `../planeacion/Investigacion-API-Jira.md`).
-- [ ] **Balam/Noé — fecha para la prueba acompañada de escritura.** Aceptado el formato el 7-ago, sin día propuesto por ellos. En el correo del 10-ago se proponen **mié 12 o jue 13-ago, 7:00 am o después de 6:00 pm** (30 min), sobre un ticket que cree Arturo, con el script compartido de antemano. **No habrá `FACTEST`.**
+- [ ] 🔥 **Johann — preparar el flujo contra el ticket de ejemplo** en cuanto Araceli lo levante (la noche del 11 no existe — preparar la sesión con el plan B de captura en vivo). ⚠️ Realidad técnica a las puertas de la sesión: bandeja+detalle leen FAC en vivo, el **wizard es simulación (folio "SIM")** y el `BindClient` **bloquea POST por diseño** — la escritura real de la cotización no está construida ni su shape documentado (portal de developers pendiente con Pedro). El "flujo funcionando" de mañana es: molde → detección → wizard con datos reales → cotización simulada/DryRun; **la escritura real se ejecuta cuando Balam la vea y apruebe en la sesión, no antes** (protocolo del Bloque 6 de `../planeacion/Investigacion-API-Jira.md`).
+- [x] ~~**Balam/Noé — fecha para la prueba acompañada de escritura.**~~ → **Es la sesión confirmada del mié 12-ago, 7:00 am** (Noé, 11-ago). Formato aceptado desde el 7-ago; **no habrá `FACTEST`**. Ver [REGISTRO #63](REGISTRO.md).
 - [ ] **Balam — ¿nacional vs extranjero cambia la cotización** o solo el paquete de salida (PDF+XML vs PDF)? Hay dos estatus de validación y una aprobación por rama.
 - [ ] **Balam/Pedro — migrar a cuenta de servicio** en vez de la cuenta personal de Pedro. Planteado el 29-jul, sin respuesta: hoy todo lo que escriba la plataforma queda firmado como Pedro y una rotación suya mata la integración.
 - [ ] **Johann — levantar el sandbox Jira Cloud propio** (plan Free, proyecto JSM que replique el workflow de FAC). Con `FACTEST` descartado, es el único lugar donde se puede equivocar sin costo.
@@ -85,7 +85,7 @@ _Última actualización: 2026-08-10 (Balam definió el flujo Jira→BIND en el c
 
 ## 🟡 Balam
 
-- [ ] ☁️⚠️ **Noé: otorgar el acceso a Azure** — grupo de recursos con permiso **Contributor** (app + BD + Key Vault); no requiere Global Admin ni cuenta nueva. Requisitos comunicados por Johann el 28-jul 4:53 pm; **Erika lo escaló a Noé** (5:23 pm) porque duda que Pedro pueda otorgarlo. Bloquea ambiente, staging y CI/CD. Ver [REGISTRO #59](REGISTRO.md).
+- [ ] ☁️⚠️ **Noé: otorgar el acceso a Azure** — grupo de recursos con permiso **Contributor** (app + BD + Key Vault); no requiere Global Admin ni cuenta nueva. Requisitos comunicados por Johann el 28-jul 4:53 pm; **Erika lo escaló a Noé** (5:23 pm). Bloquea ambiente, staging y CI/CD. **Movimiento (11-ago): Noé propone explorar/validar los accesos EN la sesión del 12-ago, con una cuenta que están creando para este uso** — llevar los requisitos a la mano. Ver [REGISTRO #59](REGISTRO.md), [#63](REGISTRO.md).
 - [ ] 📅⚠️ **Erika/Arturo: avisar fecha de la sesión del flujo de facturación** tras la revisión interna (Ara de viaje desde el 28-jul). **Desbloquea B7 (capa de escritura).** Ver [REGISTRO #58](REGISTRO.md).
 - [ ] 🧾 **Balam: decisiones de negocio de la integración Jira→BIND** — estatus disparador, request type a observar, fuente de monto y conceptos de la cotización. Sin esto no se escribe código productivo de la integración. Ver `../planeacion/Investigacion-API-Jira.md`.
 - [x] ~~**Balam:** enviar el documento/contrato de firma~~ → **Hecho (25-jun):** contrato enviado vía Paola (RH); ajustado y **firmado el 26-jun**. Ver [REGISTRO #18](REGISTRO.md), [#19](REGISTRO.md).