balam/bitacora/PENDIENTES.md

PENDIENTES — acciones abiertas

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.

Ú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 y probados en el commit local 597c8a2 (197 + 10 pruebas), sin push ni publicación (REGISTRO #88). 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); y la vista previa automática de la cotización queda publicada (#86). 🔥 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). Además, fusión de las dos sesiones paralelas del 29-sep: la del webhook pasa a ser el #84 (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). Huecos de registro cerrados: las sesiones del 21-ago al 10-sep se reconstruyeron desde el buzón (#71–#82). 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–#68.

🔥 30-sep (noche) — prefactura desde producción (REGISTRO #88)

• 🔑🔴 Johann — credenciales del usuario CTO de BIND en /opt/balam/.env (Bind__Ui__CompanyNumber, Bind__Ui__UserName, Bind__Ui__Password; están en appsettings.Local.json de la máquina de desarrollo). El puente quedó encendido a las 8:02 AM (Bind__Ui__Enabled=true, Bind__Ui__Mode=Write) pero el control de permisos de Claude Code bloqueó escribir el secreto: o Johann lo pega en el servidor, o lo autoriza explícitamente como hizo con la API key. Mientras tanto la tarjeta del wizard pide la cookie de la sesión de BIND.
• 🚀 Johann — decidir push + publicación de 597c8a2 (repo del cliente, local, sin push): panel de prefactura bajo la fila en Cotizaciones, importes correctos (total al crear, USD en su moneda, subtotal nuevo), sync por barrido completo, puente endurecido (estado real de BIND, bloqueo 10 min, post-proceso que ya no truena), aprobadores sin Arturo R. Lleva la migración aditiva QuoteSubtotal; el subtotal de las ≈120 cotizaciones se rellena en 3 ciclos del sync (tope de 50 detalles por ciclo) o con 3 "Sincronizar ahora". Mismo protocolo que los despliegues anteriores: respaldo de BD + imagen etiquetada para rollback.
• 🧪 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).
• 📋 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.
• 🧹 Las 11 cotizaciones que la plataforma tenía "Activas" y BIND no ya quedaron corregidas (cursor en null + relectura, 0 desfasadas a las 8:35 PM); con 597c8a2 publicado el sync barre todo cada ciclo y no vuelve a pasar.

🔥 30-sep — modal en vivo, aceptación y modo automático (REGISTRO #87)

• 🚀 Johann — decidir push + publicación del modal en vivo → HECHO el 30-sep, 6:53 AM (aac7447, migración aplicada). Falta ver el punto de la campana en un navegador: verde = canal en vivo por Apache; ámbar = respaldo cada 4 s.
• 🧪 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; 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.
• 🧹 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.
• 🔧 Deuda del modal: enseña el resumen de la cotización, no el JSON del dry-run (está en WriteOperations); agregar "ver el body" si Balam lo pide. El canal en vivo es en memoria: vale para una sola instancia del API.

⭐ 30-sep — webhook de Jira en producción (REGISTRO #85) y vista previa automática (#86)

• 🔧 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). La confirmación sigue siendo humana (ADR-001).
• 🚀 Johann — decidir push + publicación de la vista previa automática → HECHO el 30-sep por orden de Johann: push de 1c37eaa + 287cb65 y publicación en paputec (migración aplicada, trabajador activo, FAC-170 → NoAplica). Ver adenda del #86.
• 🔥🔑 Poner la API key del usuario cto en Bind__ApiKey de /opt/balam/.env → HECHO el 30-sep con autorización de Johann (#87): [sync] Ciclo OK, el sync volvió tras 20 días.
• 🧪 Con la key nueva en producción: ticket de prueba para ver una vista previa real de punta a punta. → HECHO del lado del servidor con FAC-171 (vista previa Lista en 4.32 s, operación #155, #87). Verla en el navegador pasa al bloque del modal en vivo, arriba.
• 🧹 Imagen de rollback balam-api:pre-vistaprevia-20260930 en paputec (además de la pre-webhook): borrarlas cuando la versión lleve unos días estable.
• 🔧 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 … falta alinear esa documentación con la decisión → Documentación alineada el 30-sep en 597c8a2 (runbook y CLAUDE.md de la plataforma dicen que producción corre en Write y con el puente encendido por decisión de Johann, y cómo apagarlo). Regresar a ReadOnly solo 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 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.
• 🔧 Poller de respaldo del webhook (JQL delta con checkpoint): sigue sin construirse; hoy un aviso perdido no se recupera solo.

🔥 29-sep — login web a BIND y endpoint interno de la UI (REGISTRO #83)

• 🔑 Guardar las credenciales del login web fuera del repo (dotnet user-secrets en desarrollo; /opt/balam/.env en paputec) y destruir el TXT en correo y disco. Misma lección del token de julio (VALIDACION-API.md §8.12).
• 🔴 Johann — revisar el error que impide cargar la solicitud al crear una cotización en BIND (visto en la sesión) y crear la cotización después de corregirlo. Puntos de acción del informe de Read AI.
• ⭐ Especificar el endpoint interno InvoiceDetails con la sesión propia → YA ESTABA HECHO en la otra máquina (se supo al fusionar el 30-sep): el contrato real es POST /InvoicesAPI/AddInvoiceTransaction, capturado el 10-sep y documentado en balam-plataforma/CLAUDE.md (§Puente a la UI de BIND); el login de formulario /Login/Login también. Ver #84, punto 5. ⚠️ El contrato sigue sin escribirse en esta bitácora (hueco del 9/10-sep, abajo). Original: URL, método, Content-Type, shape del payload, respuesta, cookies y __RequestVerificationToken, y el flujo de /Login/Login; capturar con DevTools o Playwright, sanitizar y escribirlo como contrato antes de codificar.
• 🔧 Construir BindUiClient → YA ESTABA HECHO (commit 4d6b3d8 del repo del cliente): dry-run → confirmación humana → verificación por lectura, con el candado ValidarEsPrefactura; primera prefactura real el 29-sep, folio 2467 (#84). No reemplaza el 409 de POST /api/emision/prefactura: ese candado se conservó y el puente vive en POST /api/emision/prefactura-ui. En paputec el puente está apagado (no hay Bind__Ui__* en el .env).
• ⚠️ Acordar con Balam que las prefacturas creadas así llevan CreatedByName = cuenta de Noé (o pedir un usuario de servicio dedicado).
• 📧 Pedir en paralelo a soporte BIND el campo/endpoint oficial de prefactura, con la evidencia del #70 + el swagger del SDK (NewInvoice sin campo de tipo) + la solicitud pública "agregar PREFACTURA" de su foro. Replicar la UI es frágil y posiblemente ajeno a sus términos de servicio.
• 📼 Recuperar los informes completos de Read AI (al menos 9, 10 y 29-sep) desde app.read.ai con sesión — los correos solo traen el extracto — y guardarlos en ../fuentes/.

⭐ 29-sep — webhook Jira FAC → vista previa de cotización (REGISTRO #84, plan)

• 📄 Archivar en fuentes/ la autorización escrita de Pedro para crear el webhook/regla en Jira; anotar su alcance (¿incluye crear un ticket de prueba en FAC?).
• 🔎 Fase 1 (solo GET): myself + mypermissions (ADMINISTER / ADMINISTER_PROJECTS en FAC) + inventario de webhooks → decide Vía A (webhook de sistema) o Vía B (regla de Automation). → HECHO (29-sep): ADMINISTER=true, 0 webhooks de sitio, API de Automation accesible (50+ reglas). Vía A y Vía B disponibles.
• ~🔴 Decidir el evento: creación del ticket, transición a En proceso de facturación (dura 3 min), o ambos. → Creación del ticket (jira:issue_created) para el piloto; la transición a En proceso de facturación queda para después.
• 🔧 Fase 2: POST /api/jira/webhook con secreto, relectura del ticket, idempotencia y solo dry-run; pruebas con FakeHandler. Poller de respaldo. → HECHO (29-sep, d7238da). Falta el poller de respaldo.
• 🌐 Fase 3: ngrok con traffic policy de una sola ruta; API en ReadOnly mientras el túnel esté abierto. → HECHO (29-sep); túnel apagado al cerrar la sesión.
• ✍️ Fase 4: alta del webhook/regla como operación numerada (id, URL, fecha, autorización). → HECHO: webhook de sitio id 1 (19:05:53).
• 🧪 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.
• 🔥 Mover el webhook id 1 a paputec (https://paputec.mx/balam/api/jira/webhook) → HECHO el 30-sep (#85): 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. → Construida el 30-sep (#86); su publicación está en el bloque del 30-sep, arriba.
• ☁️ 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).
• 🔥 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). 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.
• 📝 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)

• 🚨 Seis sesiones con Balam sin entrada en REGISTRO.md → REGISTRADAS el 29-sep (#72, #73, #75, #76, #78, #80, #81; la del 29-sep en #83) — ⚠️ solo con el extracto del correo de Read AI, sin transcript. Detalle original (evidencia: convocatorias de Pedro e informes de Read AI en el buzón): 21-ago 1:00 pm "Seguimiento - PAF (2)" (homologación de estados del flujo; pendiente prueba de escritura en Jira), 24-ago 7:00 am (validación cotización→prefactura MXN/USD, IVA 16 %/0 %; Noé condiciona Azure a que las pruebas funcionen), 26-ago 7:00 am (permisos y flujo remisión/prefactura/factura; el POST se timbró en vivo → #70), 3-sep 7:00 am (datos del tenant de Azure; conceptos de Acuntia por headcount; definición: ítem por código y concepto = título del ticket) y 1:30 pm (tres tickets de Pedro cotizados desde la plataforma publicada), 9-sep 1:00 pm "Seguimiento PAF - Prefactura" (Araceli crea una prefactura en la UI de BIND con "Generar venta" mientras se capturan las peticiones: InvoiceDetails), 10-sep 1:00 pm (con Pedro: cotización 1078 de Acuntia y captura de la petición de red de la prefactura).
• 📝 Registrar la publicación del 3-sep → HECHO (29-sep): #77 y #79. Original: registrar la publicación del 3-sep (https://paputec.mx/balam/, runbook en balam-plataforma/deploy/paputec/README.md) y la cotización en lote del 7-sep — hoy solo constan en el CLAUDE.md del repo del cliente y en los commits 03582af, ed4c819, fbdbd18 (pusheados el 15-sep).
• ⏱️ Validar las 39.25 h reconstruidas del 10-ago al 15-sep en ../planeacion/Seguimiento-horas.csv (todas marcadas reconstruida, con la evidencia en cada fila) y decidir a quién se reporta el corte ahora que el seguimiento es con Pedro. Excel listo: ../planeacion/Avance-Balam-2026-09-15.xlsx.
• 📧 Correos de Noé del 24-ago sin registrar: → REGISTRADOS en #74, evidencia en ../fuentes/. Original: "Re: Seguimiento FAC-106" (explica que la prefactura se genera con Generar venta en Acciones) y "Acceso a Azure Balam y permisos" (pide los requisitos exactos; Johann respondió el 25-ago con suscripción + grupo de recursos + Contributor).

🔥🔴 26-ago — incidente del timbrado y cierre de la investigación (REGISTRO #70)

• 🔥🔴 CANCELAR EL CFDI 2386 EN BIND (motivo SAT 02 "sin relación"). ⚠️ Al 26-ago tarde sigue Activa con UUID — verificado por API. Receptor ACUNTIA (RFC genérico extranjero, $1,160 MXN). Confirmar además que BIND no le haya enviado el correo automático al cliente. Movimiento (26-ago, en la sesión): Pedro tomó la acción de solicitar apoyo para cancelarla (#75); al 29-sep no consta confirmación.
• 📧 Avisar a Noé/Arturo del incidente con transparencia → Noé y Pedro estaban en la sesión donde ocurrió (#75) y Pedro tomó la cancelación. ⚠️ A Arturo no consta que se le haya informado. Original: avisar (qué pasó, por qué, contención aplicada, CFDI cancelado). La plataforma tiene la auditoría completa en WriteOperations #73.
• 🧪 Experimento decisivo: crear UNA prefactura a mano en la UI → RESUELTO sin crear nada: el folio 2384 (Araceli, 19-ago) ES una prefactura — confirmado en UI por Johann. Prefacturas = filas false+UUID null; Status=2 = facturada (parió a la 2385 timbrada). Ver adenda del #70. La detección/vinculación automática de prefacturas ya es construible sin escribir.
• 🧪 Experimento seguro pendiente de go-ahead: POST false apuntando a la secuencia de folios compartida → EJECUTADO la noche del 26-ago (op #79, folio 1002): BIND ignoró el Number — adenda 2 del #70. Original: POST false a la secuencia compartida (Number explícito + espejo de 2384: CFDIUse=23, ShowIEPS=true, plazo) para ver si la UI lo etiqueta Prefactura. Riesgo máximo: documento no fiscal borrable con folio raro. Requiere Bind:Mode=Write en sesión y autorización expresa.
• 📧 Preguntar a Pedro / soporte BIND (sigue vigente como vía paralela al endpoint interno del #83, ahora con la evidencia del SDK oficial): "¿cómo se crea una venta de tipo Prefactura por API? Con IsFiscalInvoice=false cae como Remisión (secuencia 1000) y con true se timbra al crear; el diff contra una prefactura real no muestra ningún campo de tipo". Adjuntar la evidencia del #70.
• 🧹 Borrar las remisiones 1000 y 1001 (siguen Activas). En la UI, o por API (DELETE /api/Invoices/{id}) con autorización expresa.

✅ 21-ago — la cotización ya se emite; lo que deja la sesión (REGISTRO #69)

• 🔥 Cancelar el folio 1026 en BIND (IVA 243,640.96 por el error de escala). Araceli o Johann, desde Ventas → Cotizaciones.
• 🔥 Confirmar la segunda emisión (VAT: 0.16): folio esperado 1027, total 1,431.44 MXN. Verificar por lectura y anotar el folio en #69.
• 📧 Enviar el correo a Pedro (CC Noé, Ara) con la causa → ENVIADO el 21-ago 7:32 am a Noé (CC Pedro), hilo "Seguimiento FAC-106" (#71); Noé respondió el 24-ago con el mecanismo Generar Venta (#74). Original: enviar el correo con la causa — borrador listo en ../planeacion/Correo-error-resuelto-2026-08-21.md; faltan los dos corchetes (folio y estado de la 1026).
• 📝 Capturar la minuta de las definiciones de la sesión: ¿se validaron las 17 categorías? ¿Empresa origen = 3 cuentas o 1? ¿se agrega IVA 0%? ¿Azure? ¿a quién se reportan horas ahora? (29-sep: el extracto de Read AI de esa sesión solo alcanza a decir "Se definió que el IVA nacional…"; sigue sin minuta.)
• 🔧 Resolver el servicio desde el combo, no fijo: → HECHO el 3-sep (definición de Pedro: categoría → código del catálogo /api/Services, mapeo Emision:ServicioPorCategoria, selector de ítem; commit ed4c819, #76). Original: la UI manda el GUID del servicio 027 hardcodeado. Falta el mapeo 17 categorías de Jira → GUID de /api/Services (y BIND tiene 5 "Servicio de Enlace": hay que elegir uno por categoría, idealmente después de que Balam depure su catálogo).
• 🔧 Lista de precios desde el cliente (hecho en la prefactura el 23-ago, commit a07fff6; falta verificar que la cotización haga lo mismo): usar Clients.PriceListID (CEMEX → "A") en vez del GUID fijo; el read model de Quotes reporta ese campo mal.
• Sesión 21-ago → Hecha. Tres intentos en vivo fallaron (protocolo aplicado, nada creado); la causa se encontró después y la emisión funcionó al 5.º intento.
• 🔒 Bind:Mode ReadOnly al cerrar → Hecho en esta máquina (y API/ng apagados). ⚠️ En la otra máquina configurar user-secrets desde cero; Bind:Mode por default es ReadOnly.

🔥🔥 SESIÓN VIERNES 21-AGO, 7:00 AM — Noé, Araceli y Pedro (preparación; ya ocurrió)

• 🔥 Johann — inspeccionar FAC-106 por API → HECHO (20-ago, noche). Informe completo: ../planeacion/Sondeo-FAC-106-y-payload-2026-08-20.md. ⭐ El formulario nuevo resuelve conceptos/partidas: Servicio/Producto (combo, 17 categorías), Cantidad, IVA y Cliente (combo, 17 clientes de BIND) ya son campos estructurados; request type nuevo Cotización Bind. Config corregida: el campo de cliente pasó de customfield_10202 a customfield_11598 — era la causa de que el 12-ago "el cliente no se detectó".
• 🔥🔴 Resolver el ERROR 500 del POST de cotización → DIAGNOSTICADO (20-ago) leyendo 4 cotizaciones reales de BIND. Tres defectos en el payload: (1) VATRate va como fracción (0.16), no como 16; (2) el VAT de partida es monto, no tasa (Price × Qty × 0.16 — verificado en 3 de 4); (3) cada cotización real usa un PriceListID distinto y ninguno coincide con el único que devuelve GET /api/PriceLists → omitirlo. Dry-run corregido ejecutado (operación #18); body listo en el informe. Falta la confirmación real, que es la prueba de mañana.
• 🔴 PREGUNTAR MAÑANA — Empresa origen tiene 3 valores: Balam, RegioTurk y Helmstone. ¿La cotización se emite siempre en la misma cuenta de BIND o hay una por empresa? Hay un solo token. Si son cuentas distintas, el alcance cambia.
• 🔴 PREGUNTAR MAÑANA — el combo IVA de Jira solo ofrece 16%. No hay 0%, y en el combo de clientes hay tres de exportación (ACUNTIA S.A.U., VictTec LLC, IAMCFORWARDER). El Discovery registró 16%/0% y en BIND hay cotizaciones reales con VAT = 0. Falta la opción.
• 🔴 PREGUNTAR MAÑANA — "Servicio de Enlace" existe 5 veces en BIND, con unidad, unidad SAT y ChargeVAT distintos entre sí (una cobra IVA, cuatro no). El combo de Jira manda una sola etiqueta: la correspondencia etiqueta → ítem de BIND no está definida. Se depuró el combo de Jira; falta depurar BIND y fijar el mapeo.
• ⚠️ Fijar por escrito que manda el combo Cliente (11598): sobrevive Nombre del cliente (11596, texto libre) en el mismo formulario.
• 🔒🔴 Regresar Bind:Mode a ReadOnly → HECHO (20-ago, noche); verificado: /api/emision/estado responde ReadOnly. Mañana en la sesión: dotnet user-secrets set "Bind:Mode" "Write" --project src/Balam.Api (y reiniciar el API) SOLO para emitir, y de vuelta a ReadOnly al cerrar.
• 🔧 Cablear los 4 campos nuevos → HECHO (20-ago, noche). El wizard prellena la partida completa desde el ticket (título ← Servicio/Producto, cantidad, tasa de IVA) y manda vatRate como fracción; el endpoint rechaza con 400 cualquier tasa > 1. Verificado e2e contra FAC-106 real: detalle con servicio/cantidad/iva/fechaVencimiento poblados y dry-run (operación #19) con VATRate=0.16, VAT=197.44, sin PriceListID. Tests 74/74. El flujo de mañana es: abrir la solicitud → vista previa automática → encender Write → Confirmar.
• 🔥 Johann — preparar el caso de escritura sobre FAC-106 → LISTO (20-ago, noche). El cliente ya se lee del combo 11598 (CEMEX detectado y con match único en el catálogo sincronizado) y la partida sale de los campos estructurados. Queda solo la Confirmación real en la sesión — el único paso que nadie puede ensayar sin escribir en producción.
• 🔥 Johann — en la sesión: encender Bind:Mode=Write solo para emitir y regresarlo a ReadOnly antes de cerrar.
• ⚠️🔥 Johann — anunciar al abrir la sesión el destino de la cotización real (cancelarla al terminar vs. cliente de prueba) y que la prefactura pertenece a una sesión posterior. Pendiente arrastrado del 12-ago; sigue sin resolverse.
• 🔴 Validar las 17 categorías con Noé y Ara. Pedro redujo el catálogo de servicios de 67 → 17 pero lo condicionó: "tengo que verlas con Noé y Ara antes". Es el momento de cerrar el hueco de conceptos/partidas que bloquea B7 desde el #62.
• ☁️ Azure — insistir; lleva 3 semanas sin avanzar. El 11-ago Noé ofreció explorarlo en la sesión "con una cuenta que estamos creando para este uso"; el 12-ago no se tocó — Noé solo dijo "eso lo resuelvo con Pedro" (REGISTRO #65 §8). Ahora que Pedro es el responsable, es su pendiente directo. Requisitos ya comunicados el 28-jul: grupo de recursos + Contributor (app + BD + Key Vault), sin Global Admin. Sin esto la transición automática no existe y todo queda en disparo manual. Movimientos: 24-ago Noé condiciona Azure a que las pruebas funcionen y pide la app en un VPS (#73); 25-ago Johann manda los requisitos exactos (#74); 3-sep se piden los datos del tenant y Noé debía reenviarlos a Pedro (#76); mientras, la plataforma vive en https://paputec.mx/balam/ desde el 3-sep (#77).
• 👤 Confirmar quién es el responsable del proyecto. → CONFIRMADO: Pedro. Noé lo anunció el 12-ago: "Erika ya no va a ser la PM de este proyecto. El seguimiento del proyecto lo va a traer Pedro." ⚠️ Nunca se comunicó por escrito — el anuncio existe solo en la grabación. Ver REGISTRO #65 §1.

🆕 Abierto por la sesión del 12-ago (REGISTRO #65)

• 🔴 Balam — definir la regla de EDICIÓN de cotizaciones. Araceli las modifica seguido ("siempre hay ajustes") y verificó en vivo que BIND conserva el mismo número al editar. La plataforma no implementa edición. Disyuntiva planteada por Noé y dejada a Balam: historial de cotizaciones (ticket nuevo o regenerar) vs. modificar la misma. Araceli se inclina por conservar historial. Impacta el diseño de B7 — preguntarlo mañana.
• ⚠️ Cancelaciones: la plataforma NO cancela, pero SÍ lleva el récord. Acordado el 12-ago. Antes del timbrado se cancela libremente; después requiere acuerdo con el cliente por correo → cancelación en el ERP → despacho ante el SAT → el cliente acepta en una liga del SAT. Falta modelar el récord ("esta factura se canceló y fue sustituida por esta").
• Balam/Pedro — quitar el SLA a los tickets de cotización para que no impacten métricas (acordado con Araceli en la sesión).
• 📼 Pedro — enviar las grabaciones de BIND (altas de proveedor/clientes, facturación y una tercera). Ofrecidas al cierre del 12-ago; no consta que hayan llegado — no aparecen en el buzón al 20-ago.
• 🗂️ Balam — resolver la herramienta de seguimiento del proyecto. El tablero de Jira para las actividades de Johann "muy próximo iba a necesitar que sea de paga por el tipo de licencia"; se barajaron SharePoint y Google Drive; Noé prefiere Jira pero falta permiso de admin para crear spaces. Mientras tanto sigue vigente lo del #58: el Excel de horas ES el sistema de seguimiento.
• 💰 Definir a quién se le reportan horas, avances y facturación ahora. Todo el circuito administrativo iba por Erika: cortes de horas, Excel de avance, recordatorios de factura (#45, #51, #58, #59). Con el relevo del 12-ago nadie dijo qué pasa con esa vía — y el relevo ni siquiera se comunicó por escrito. Preguntarlo mañana: si el seguimiento es con Pedro, ¿los cortes de horas también, o siguen con Erika/Paola?
• 🔒 Johann — avisar a Pedro antes de cada escritura (cotización o prefactura), ofrecido en la sesión. Noé reafirmó el candado: "no hacer más pruebas de lo que definiéramos, para evitar errores o cosas en producción".

🚨 Huecos de registro abiertos (detectados en el cruce del 20-ago)

• 🚨 Capturar la minuta de la sesión del 12-ago → HECHO (20-ago): transcript localizado y registrado en REGISTRO #65 (../fuentes/2026-08-12 - Transcript - Sesion prueba de escritura Jira-BIND.txt). Las cuatro preguntas quedaron respondidas: no se emitió cotización (error 500); Azure no se tocó y quedó con Pedro; sí, ahí Noé anunció a Pedro como responsable del seguimiento; y el molde de Araceli nunca existió — Pedro construyó un formulario nuevo en vivo.
• 📌 Versionar Cotizacion-BIND-campos-y-catalogos.xlsx — está en la raíz del repo sin trackear y ya es el insumo que Balam usó para rehacer el formulario de Jira (#66).
• 📄 Leer los procedimientos de carga de facturas ya descargados en ../fuentes/ (#46a): 5 portales — Cemex, Acuntia, ATC Consolidados, DYLO y Victec. ⚠️ Dos clientes que el Discovery nunca mencionó y Axie no aparece: el universo de destinos de envío no está cerrado.
• 🗺️ Contrastar el diagrama del flujo de facturación de Jira (../fuentes/2026-07-22 - Correo - Flujo facturacion JIRA BALAM.png, #57a) contra el disparador acordado y lo observado por API.
• 🔎 Identificar qué se firmó en Buk el 30-abr y el 5-may — dos documentos anteriores al contrato de junio que la bitácora nunca registró (REGISTRO #0).
• 📖 Leer el hilo comercial de abril ("Propuesta de servicios por hora - Balam", 23–28 abr) y completar REGISTRO #0: es donde se fijó la tarifa por hora.

🔥 Flujo Jira→BIND — abierto tras la definición del 7-ago

• 🔥 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.
• 🔥 Araceli — levantar el TICKET DE EJEMPLO capturado "como debería ser" (ruteado por Noé el 11-ago; la noche del 11 no existía) → Lo resolvió PEDRO el 20-ago con FAC-106, tras rehacer el formulario de Jira contra el Excel de campos de BIND (#66, #67). ⚠️ No consta que Araceli haya capturado el molde que Noé le pidió: el camino fue otro — Balam modificó el formulario y Pedro levantó el ticket. Los planes B y C (captura en vivo / FAC-100) quedan sin usar.
• 🔥 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.
• 🔴 Conceptos/partidas — la vía quedó definida el 12-ago: DEPURAR EL CATÁLOGO, no agregar un campo. Araceli mostró que el combo de servicios de BIND está sucio (040 y 029 son el mismo servicio; entradas con nombres de personas, "monitor Samsung", periodos en el nombre) y se acordó dejar solo opciones genéricas, volver combo la descripción del ticket y homologar los combos de Jira con los de BIND. Pedro ejecutó la depuración: 67 → 17 categorías, pendientes de validar mañana con Noé y Ara. Dato fiscal: horas de consultoría = unidad SAT E48. Ver REGISTRO #65 §5, #67.
• 🔴 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 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. 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? → RESUELTO en la sesión del 12-ago: la genera la PLATAFORMA. Noé le preguntó a Araceli si le serviría que Jira hiciera la cotización y evitarle el primer paso → "Sí, sí me serviría" → "vamos a hacer ese ejercicio, Johann". El paso comercial de cotizar a mano desaparece para venta nueva; la recurrente sigue fuera de alcance (comercial solo avisa el periodo y administración prefactura). Ver REGISTRO #65 §3.
• 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).
• ⚠️ 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 flujo contra el ticket de ejemplo → CONSTRUIDO (11-ago, noche): contrato Quotes_NewQuote obtenido del portal público, CreateQuoteAsync con guardas, POST /api/emision/cotizacion (dry-run/confirmación auditadas en WriteOperations), pantalla solicitudes/:id/cotizar y vínculo ticket→cotización. 73/73 pruebas. Corre contra cualquier ticket FAC — el molde solo mejora los datos. La escritura real sigue gateada a Bind:Mode=Write, que se enciende SOLO en la sesión. Ver REGISTRO #64.
• 🔥 Johann — enviar a Noé/Pedro el script de la prueba esta noche (../planeacion/Script-cotizacion-sesion-2026-08-12.md) — cumple la condición del 24-jul de compartirlo antes.
• 🔥 Johann — en la sesión: encender Bind:Mode=Write solo para emitir y regresarlo a ReadOnly antes de cerrar. ⚠️ La semántica fina de partidas (Type/SelectedUnit/VAT) se valida contra la primera respuesta real; si BIND rechaza, el error se lee en pantalla y se ajusta en vivo.
• 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.
• 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.
• ⚠️ Johann — implementar la detección por changelog, no por estatus actual. FAC-100 estuvo 2m44s en el estatus disparador; un poller de 15 min que consulte el estado actual se pierde la mayoría de los disparos. Refuerza el caso de pedir un webhook / regla de Automation a Pedro.
• Johann — mover el token de Jira a user-secrets/Key Vault y borrarlo de disco (ya está en .gitignore:9). Mismo pendiente que arrastra bind_token_api.txt.

🔴 Johann (proveedor) — inmediato

• ⚠️🔥 Enviar la propuesta/adenda ajustada por la integración Jira→BIND → Hecho (29-jul): v1.3 enviada por WhatsApp (8:18 am) y por correo (3:56 pm) a Noé, CC Ara/Erika/Pedro. APROBADA por Noé el 30-jul: "De acuerdo con la propuesta actualizada". Alcance: 7–10 h ($4,200–$6,000 MXN + IVA); total primera etapa 119–146 h. Ver REGISTRO #59, #60.

• 📊 Enviar el Excel de horas de las etapas siguientes (2, 3) → Hecho (29-jul, 8:18 am): Avance-Balam-2026-07-28.xlsx por WhatsApp; 👍 de Erika. Ver REGISTRO #59.

• 🔑 Destrabar el acceso a la API de Jira (401 del 29-jul) → Resuelto (30-jul): Pedro confirmó el correo del apikey (pedro.ayala@...), regeneró el token y GET /myself respondió 200. Ver ../planeacion/Investigacion-API-Jira.md (Bloque 0).

• 🌱 Seeder de datos de prueba (B9) → Hecho (1-ago): DevDataSeeder opt-in con datos ficticios (5 estados × MXN/USD × PUE/PPD). El desfase con lo reportado a Erika el 27-jul quedó saldado. Ver REGISTRO #61.

• 🔑 Copiar propuesta/token-jira.txt a esta máquina y correr ../planeacion/pruebas-jira-lectura.sh → Hecho (6-ago): script corrido completo contra FAC (todo 200; auth OK con el token renovado) + sondeo dirigido de customfields. Los IDs quedaron capturados y documentados en ../planeacion/Investigacion-API-Jira.md (sección 6-ago): sí existen "Monto sin IVA"/"Monto con IVA" pero casi nadie los llena (2/69); "Nombre del Cliente" y "Periodo de Incidencias" llegan como ADF. ⚠️ El token estaba suelto en balam-plataforma/token-jira.txt (repo del cliente, sin ignorar): se movió a propuesta/ + user-secrets y se blindó el .gitignore del subrepo.

• 🧪 Crear el sandbox Jira Cloud Free propio (decidido 1-ago) para desarrollar escritura (transiciones/comentarios/creación) sin tocar FAC; la prueba en la instancia real sigue reservada a la sesión acompañada que autorizó Noé.

• ⏱️ Capturar horas 28-jul→1-ago en el CSV (propuesta preparada, validar montos) y regenerar Avance-Balam desde script — la copia en disco del 28-jul está desincronizada (re-guardado manual).

• 📅 Demo del viernes 7-ago: material listo — frontend (login→cartera→facturas→detalle+PDF→clientes), seeder demo como respaldo si BIND falla, scheduler en vivo.

• Asistir al kickoff con Noé (mié 1-jul, 7:00 am) → Hecho (1-jul). Ver REGISTRO #22.

• 📅 Asistir a la sesión "Proceso actual de facturación y cobranza" (lun 6-jul, 7:00 am) → Hecha (6-jul). Proceso mapeado end-to-end; lista blanca eliminada; cotización BIND obligatoria. Ver REGISTRO #27.

• 🎨 Preparar y entregar el prototipo de la Etapa 0 → Entregado por correo (10-jul) a Erika + Noé, CC Pedro, con PDF y versión navegable. Refleja facturación, envío, cobranza y reglas del Discovery. Ver REGISTRO #40.

• 📧 Enviar por correo el prototipo (imágenes) + comentarios → Hecho (10-jul). Balam respondió que lo revisaría internamente.

• 📊 Responder a Erika el % de avance de Fase 0 → Atendido mediante el Excel de avance ajustado y entrega del prototipo. La validación final sigue abierta.

• 📅 Preparar y asistir a la sesión de reglas/dudas de Etapa 1 (mié 22-jul) → Hecha (22-jul, 7 am): alta de cliente/proveedor mapeada (Arturo en pantalla), fee = lo registra el despacho (plataforma solo detecta), Jira confirmado en el proceso (estatus final "resuelto"; validación PDF+XML nacional / PDF internacional). No se tocaron particularidades de envío ni PUE/PPD. Ver REGISTRO #54 y minuta en ../planeacion/Sesion-Etapa1-2026-07-22.md.

• 📅 Preparar y asistir a la validación del prototipo (jue 23-jul, 7:00 pm). Llevar decisiones que requieren visto bueno y separar MVP de Anexo B. Aprovechar para meter la pregunta PUE/PPD que no se alcanzó el 22-jul. Ver REGISTRO #42.

• 📊 Compartir con Erika el corte de avance de la Etapa 1 solicitado el 16-jul → Hecho (16-jul, 8:40 pm): Excel Plan-actividades-avance-2026-07-16.xlsx enviado por WhatsApp; Erika acusó recibo ("Ntp, gracias"). Ver REGISTRO #46.

• 📄 Revisar los procedimientos de carga de facturas por cliente enviados por correo el 16-jul. Conservar correo/adjuntos como evidencia y contrastar destinatarios, adjuntos, asunto, cuerpo y nomenclatura contra el Discovery y el prototipo. Ver REGISTRO #46.

• 🔐 Validar permiso de escritura en el repositorio privado de Balam → Comprobado (16-jul): push exitoso del scaffold inicial (backend .NET 10 + Angular 21, commits 220942a..1f7f098) a pedro-balam-itsm/BALAM. Ver REGISTRO #46.

• ⏱️ Validar el corte reconstruido de 30 h en ../planeacion/Seguimiento-horas.csv: 22 h de Etapa 0 + 8 h de Etapa 1. Solo 3.08 h corresponden a sesiones con duración comprobable; las otras 26.92 h están marcadas como reconstruidas. Ajustarlas si la memoria/evidencia indica otra distribución y después conciliar con Jira. Ver REGISTRO #45.

• 📝 Cerrar el documento de hallazgos + ADRs (../planeacion/Hallazgos-y-decisiones-Etapa0.md) después de las sesiones del 22–23 jul.

• 🔐 Decidir/aplicar el rol local balam_app para que RLS aplique en desarrollo: la política RLS de B6 está aplicada, pero el usuario balam del contenedor es superuser (BYPASSRLS) y la ignora. Falta: CREATE ROLE balam_app LOGIN NOSUPERUSER NOBYPASSRLS + REASSIGN OWNED + apuntar la cadena de conexión de desarrollo (appsettings.Development y DesignTimeDbContextFactory) a ese rol + repetir la verificación psql. En Azure no existe este hueco (el usuario de app no es superuser). Ver REGISTRO #53.

• ⚠️ Preguntar a Arturo: ¿por qué TODO el histórico se factura PUE? 1,374/1,374 facturas con método de pago = PUE, cero PPD, aunque cobran a crédito 30–90 días. Toca la regla "PPD default" de la capa de escritura (B7) y el requerimiento del SAT que ellos mismos sufrieron. No se alcanzó a preguntar en la sesión del 22-jul — reintentar el 23-jul (validación del prototipo) o en la sesión de API Jira con Pedro. Ver REGISTRO #52, #54.

• 📅 Proponer a Erika usar la sesión del martes 7-jul para COBRANZA → Propuesto (6-jul, 3:01 pm) y CONFIRMADO (6-jul, 6:36 pm): convocatoria de Teams enviada para el martes 7-jul, 7:00–8:00 am, con Araceli y Arturo (CC Noé). Ver REGISTRO #34.

• 📅 Asistir a la sesión de cobranza (mar 7-jul, 7:00 am) → Hecha (7-jul). Sin grabación. Ver REGISTRO #35.

• 📝 Documentar el proceso de cobranza de la sesión del 7-jul (sin grabación) → Hecho (7-jul): reconstruido de memoria el mismo día. Notas en ../fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md; entrada REGISTRO #35.

• 📊 Exceles de cobranza (condicional): si Balam valida que el prototipo representa bien su operación, ya no se requieren. Si pide ajustes, solicitar a Arturo estructura con datos ficticios de abiertas/canceladas/días vencidos, pago↔folio y estado de cuenta. No confundir con el Excel de particularidades de envío, que sigue pendiente. Ver REGISTRO #44.

• 🔑 Dar seguimiento a si Pedro crea el usuario de solo lectura de BIND que pidió Noé (mientras tanto Erika opera con el usuario de Arturo, sin bloqueo) — sigue sin resolverse una semana después (7-jul). Ver REGISTRO #37.

• 🔧 Decidir si probar endpoints de escritura (POST/PUT) de BIND → Decidido (7-jul): NO todavía. Contradice la instrucción de Noé de mantener solo-lectura mientras Pedro confirma el alcance del token; sin sandbox, el riesgo fiscal es real. Alternativa segura: catalogar operaciones de escritura desde el portal de desarrolladores de BIND (documentación), no probarlas en vivo. Ver REGISTRO #36.

• 📧 Responder el correo de Pedro → Enviado (6-jul, ~3:28 pm): acuse de recibo + usuario de Arturo documentado + arranque de trabajo con la API, sin comprometer entregas adicionales. Ver REGISTRO #29.

• 📧⚠️ Responder el correo de Noé (importancia alta, 4:33 pm) describiendo las salvaguardas ya operando → ESTABA HECHO DESDE EL 6-JUL, 4:46 PM (13 minutos después del correo de Noé), a Noé y Pedro con Erika en copia. Cubre las cinco salvaguardas: solo-lectura bloqueado en código, consumo acotado, token en gestor de secretos fuera del repo, sin datos reales en la documentación, y escritura diferida. (Corrección del 20-ago: este pendiente llevaba mes y medio abierto por error — el correo apareció al cruzar el buzón.) Ver REGISTRO #31a.

• ⚠️ No atar nada al token actual: Pedro está revisando permisos y puede reemplazarlo por uno de un usuario nuevo de solo lectura — mantener el token como variable de entorno intercambiable (ya es así en el sandbox). Ver REGISTRO #31.

• 🔑 Validar la API de BIND con el token real → ✅ Hecha (6-jul, adelantada un día): 117 peticiones GET-only, Plan A del saldo CONFIRMADO, flujo MVP 100% sostenible en lectura, PDF por API. Hallazgo duro: sin recurso de pagos/REP. Documento: ../bind-api-sandbox/VALIDACION-API.md. Ver REGISTRO #32.

• 📨 Escalar a Pedro las preguntas técnicas de la API (juntas, esta semana): (1) ¿existe endpoint de pagos individuales / complementos de pago (REP) no documentado? — es el hueco más relevante para el flujo PPD, y ganó caso de negocio el 7-jul: el despacho registra los pagos en BIND uno por uno a mano; (2) tabla de mapeo CFDIUse interno → clave SAT; (3) shape del endpoint /{id}/xml; (4) ¿webhooks/eventos o solo polling?; (5) ⚠️ qué token alimenta el Power BI — el 7-jul Arturo mostró su Power BI conectado con su token, pero el kickoff acordó Ara=Power BI / Arturo=desarrollo; BIND emite 1 token por usuario, así que si ambos usos comparten el de Arturo, reemplazarlo por el usuario solo-lectura que planteó Noé rompería uno de los dos. Ver REGISTRO #32 §10, #35.

• 🔐 Higiene del token: moverlo a un gestor de secretos y borrar bind_token_api.txt de la raíz del repo y del correo/descargas (está gitignoreado, pero sigue en disco).

• ⚠️ Aclarar expectativa de recordatorios a clientes: lo que Ara/Arturo describieron el 6-jul son recordatorios automáticos a clientes, que están diferidos al Anexo B (el MVP trae alertas internas). Aclararlo pronto o anticipar que pidan ese módulo al cierre del MVP. Igual con la idea de agentes observando Jira (Nivel 3, fase posterior) y el deseo multi-empresa (Regiotour, Elmstone). Reapareció el 7-jul: quieren correos automáticos al cliente pasados 1–5 días de vencimiento ("ser proactivos"). Ver REGISTRO #27, #35.

• Ajustar la propuesta (30 h explícitas, sin "Etapa 0", términos comerciales en una sección) → Hecho (1-jul): propuesta v1.2 — se agregó el concepto "Facturación inicial: 30 h / $18,000 + IVA" (cubre Etapa 0 + inicio de Etapa 1; Etapa 0 se mantiene en 18–22 h) y se consolidó §3.3 Condiciones comerciales. PDF generado y enviado el 2-jul.

• 📧 Enviar el correo (Noé, CC Pedro, Ara, Erika) con la propuesta v1.2 ajustada, vinculando la facturación inicial de 30 h al acuerdo → Hecho (2-jul, 5:39 PM): enviado con Propuesta-Balam.pdf adjunto, sin esperar el correo de Erika+Paola. Ver REGISTRO #26.

• 💸 NO facturar todavía. Erika confirmó el 13-jul que recibió la propuesta v1.2; la validación para emitir sigue pendiente porque Noé y la CEO están fuera del país. Mantener la factura lista y emitir en cuanto llegue el visto bueno, con pago a 30 días. Ver REGISTRO #41.

• Configurar Jira y aprender el flujo con Pedro — reportar horas ahí (incluye material informativo); Erika hace el corte los lunes. Mientras tanto usar ../planeacion/Seguimiento-horas.csv.

• Usar los tokens de marca en el prototipo → Hecho: prototipo y capturas usan Amarillo #F7BD0C, Café #331F0E y Poppins.

• Preparar el Excel de actividades → Entregado y consolidado: la única versión operativa se conserva en ../planeacion/Plan-actividades-avance-2026-07-10-ajustado.xlsx; contiene el corte reconstruido de 30 h al 15-jul.

• Proponer sesiones de Discovery → Hecho (29-jun): propuestas y aceptadas; Erika coordina las agendas (intermediaria de sesiones).

• Cambiar régimen fiscal (en proceso) para poder facturar (CFDI semanal los viernes, pago a 30 días).

• Confirmar qué permisos exactos de Azure necesita → Definido: acceso Contributor acotado a un grupo de recursos de Balam; no se requiere Global Admin ni una cuenta nueva. Solicitar durante la semana del 21-jul.

• Arrancar el Discovery una vez Balam entregue los accesos → Hecho (6–7 jul): facturación, envío y cobranza mapeados.

• (Opcional) Pedir a Balam copia limpia del contrato: la cláusula de Firma Electrónica de la última página quedó duplicada y aún dice "EL PATRÓN" (residuo de plantilla, bajo riesgo). Ver REGISTRO #19.

• Revisar y firmar el contrato de servicios → Hecho (26-jun): revisado, negociados 2 ajustes (pago de horas al terminar + aceptación a 10 días) y FIRMADO. Ver REGISTRO #18, #19.

• Responder el correo de Noe (8-jun) → Hecho (10-jun): aceptados los 4 ajustes y respondidas las 3 preguntas técnicas. Ver REGISTRO #16.

• Decisión comercial: sin anticipo / pago a 30 días → Aceptado (10-jun), con la condición de firmar el contrato/orden de trabajo antes de arrancar (sustituye al anticipo como mecanismo de compromiso).

• Preparar propuesta v1.1 → Enviada (10-jun) con los 4 ajustes reflejados. Ver REGISTRO #16:

  • Soporte: bolsa de horas a $600/h, vigencia 12 meses (sin caducidad mensual).
  • Garantía: 45 días.
  • Comercial: sin anticipo; factura de Etapa 0 + pago a 30 días; avances a 30 días.
  • Conciliación bancaria: reflejada como primer alcance condicionado a horas liberadas por el Discovery.
  • Dashboard/reporteo: ajustado para no solapar con el tablero Power BI de Pedro (conservar cobranza + alertas).

🟡 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). 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, #63.
• 📅⚠️ 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.
• 🧾 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.
• 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, #19.
• 🔑 Balam: completar accesos de Etapa 1 — token BIND ✅; manual de marca ✅; invitación al repo GitHub recibida y acceso confirmado informalmente (falta validar escritura); Azure programado para semana del 21-jul. Ya no bloquea el desarrollo local, pero Azure sí condiciona despliegue/CI-CD.
• Erika (PM): pedir el plan de actividades → Recibido (30-jun). Erika es la intermediaria de todas las sesiones, agendó el kickoff (1-jul, 7am) y monta el tablero Kanban en Jira. Ver REGISTRO #21.
• Noe: formalizar por correo → Hecho: aclaraciones (8-jun, #15) y luz verde + redacción del documento de firma (16-jun, #17).
• Pedro + Erika: armar el tablero de seguimiento en Jira y revisarlo juntos (instruido formalmente por Noe el 16-jun).
• Pedro: enviar manual de marca → Hecho (1-jul): enviado por correo. Tokens en ../marca/Marca-Balam.md. Ver REGISTRO #23.
• Erika: entregar el token de BIND → ✅ ENTREGADO por correo (6-jul, 12:40 pm), mismo día en que se solicitó. Ver REGISTRO #28.
• Balam: confirmar a qué usuario pertenece el token → ✅ Confirmado (6-jul, 12:38 pm): Pedro lo entregó por correo (bind_token_api.txt) indicando que fue generado con el usuario de Arturo Rosas — conforme al kickoff (Arturo=dev, Ara=Power BI). Ver REGISTRO #29.
• Pedro/Balam: confirmar permisos de escritura para Johann-28 en el repositorio GitHub privado. Pedro envió la invitación el 15-jul y Johann confirmó acceso el 16-jul; falta una prueba efectiva de escritura. Ver REGISTRO #43, #46.
• Pedro: enseñar a Johann el flujo de Jira (reporte de horas como los demás consultores).
• Pedro + Noé: configurar Azure y permisos (Noé otorga donde Pedro tiene limitantes).
• Erika: coordinar la sesión de Discovery con Arturo + Araceli → Hecho: agendada (1-jul) y realizada (6-jul, 7am). Ver REGISTRO #24, #27.
• 📊 Ara + Arturo: enviar el Excel de particularidades de envío por cliente (destinatarios + adjuntos + nomenclatura). Erika confirmó el 13-jul que continúa en preparación y que esperan entregarlo durante la semana. Ver REGISTRO #41.
• Arturo: definir el proceso para cuando el cliente NO esté dado de alta en BIND — el ASIS del alta ya quedó mapeado en la sesión del 22-jul (REGISTRO #54); sigue abierta la decisión de MVP: ¿la plataforma solo detecta que falta el cliente o también lo crea? (cruza con la estimación Jira→BIND de ~10 h). Ver REGISTRO #27, #51.
• 📤 Arturo/Pedro: enviar a Johann el diagrama del flujo Jira de facturación en tamaño legible (comprometido en la sesión del 22-jul; el screenshot era ilegible). Ver REGISTRO #54.
• 📅 Erika: agendar la sesión con Pedro (+Arturo) para explorar la API de Jira (conexión, campos, webhook), la facturación recurrente (~30 facturas/mes) y qué facturas son automáticas vs manuales — acordada en la sesión del 22-jul. Ver REGISTRO #54.
• Erika + Paola / Noé: confirmar la propuesta v1.2 para emitir las 30 h. Erika confirmó recepción; validación pendiente por viaje de Noé y CEO. Ver REGISTRO #41.
• Arturo: dar acceso/contexto de bancos (para conciliación). Las reglas de negocio de facturación ya quedaron mapeadas en la sesión del 6-jul (REGISTRO #27); bancos sigue pendiente.

⚙️ Acordado (referencia, ya cerrado)

• Anticipo de Discovery ($18,000): aprobado (4-jun) → Corregido (8-jun): Balam NO maneja anticipos. Se factura la Etapa 0 (30 h) y se paga a 30 días.
• Propuesta v1.1 enviada (10-jun) y aceptada por Balam (16-jun). Balam redacta el documento de firma.
• Condición de arranque: contrato/orden de trabajo firmado antes de iniciar (planteado por Johann 10-jun; aceptado por Balam 16-jun).
• Contrato de servicios FIRMADO (26-jun-2026) por Johann (firma electrónica). Incluye 2 ajustes finales: pago de horas al terminar + aceptación a 10 días naturales. Facturación semanal (viernes), pago a 30 días.
• Plan de actividades (4 etapas) entregado a Erika (29–30 jun). Kickoff con Noé agendado (1-jul, 7am). Erika = intermediaria de sesiones; tablero Kanban en Jira.
• Pagos: a 30 días post-factura (incluida la Etapa 0); política firme de Balam (8-jun).
• Gestión en Jira (ágil, no Gantt); Erika valida entregables (4-jun).
• Comunicación: canal de WhatsApp + correo para evidencia. Contactos: Erika=principal, Pedro=técnico, Arturo=negocio (4-jun).