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 — ⭐ 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 construida en local, sin publicar (#86). 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 — 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 (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.
🔑 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.

🔑 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) — sync detenido desde el 10-sep. Pedir a Balam la API key del usuario CTO o revisar el acceso de Arturo.
🔥 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).

54 KiB Raw Blame History Unescape Escape