Files

T

Johann 63af3d634d Registro #88 : el puente de prefactura queda encendido en producción (sin credenciales CTO: bloqueo del control de permisos), «Servicio de Enlace» → 106 y 11 cotizaciones con estado atrasado corregidas; lo que Pedro vio a las 7:26 (totales en cero, botones sin destino, "servicios", Arturo) tenía detrás cuatro bugs reales, corregidos y probados en 597c8a2 del repo del cliente (197 + 10 pruebas, sin push ni publicación); capturas del recorrido local

Pendientes nuevos: credenciales del usuario CTO en /opt/balam/.env (decisión de Johann), push + publicación de 597c8a2, primera prefactura real desde producción con Johann, código de BIND de las 7 categorías restantes, confirmar 2467/1084/1085 con Balam, una sola sesión operando el servidor.

2026-09-30 21:29:22 -06:00

257 KiB

Raw Blame History

REGISTRO · Bitácora de comunicaciones — Proyecto Balam

Log cronológico de toda comunicación del proyecto (correos, llamadas, mensajes). Es la fuente de la verdad del "qué se dijo y cuándo". Convención y plantillas para registrar en README.md. Material crudo (transcripciones, .eml, PRD) en ../fuentes/.

Hilo de correo principal: "Re: Solicitud de cotización – PRD" Participantes:

Johann (proveedor) — johann_antonio85@hotmail.com
Noe Rocha — CTO, Balam — noe.rocha@balamtalentoestrategico.com
Araceli Sanchez Jimenez ("Ara") — Balam — araceli.sanchez@balamtalentoestrategico.com
Erika Chavez — Project Manager, Balam — erika.chavez@balamtalentoestrategico.com · WhatsApp +52 1 81 2353 5803 · ⚠️ PM del proyecto hasta el 12-ago-2026, cuando Noé anunció su relevo (#65)
Pedro Alberto Ayala Elizondo — Desarrollador / contacto técnico, Balam — pedro.ayala@balamtalentoestrategico.com · ⭐ responsable del seguimiento del proyecto desde el 12-ago-2026 (#65)
Arturo Rosas Hernandez — Gerencia administrativa / operación, Balam — arturo.rosas@balamtalentoestrategico.com
Paola de los Angeles Castro Martínez — Recursos Humanos, Balam — hr@balamtalentoestrategico.com · coordinó la firma del contrato (WhatsApp)

Periodo: 8 abr 2026 → 29 sep 2026 (última actualización: 29-sep — ⭐ Balam entrega login web a BIND con permisos de prefactura y queda confirmado el modelo de dos endpoints: externo = API (remisión o CFDI timbrado), interno = UI (Generar Venta → Prefactura, petición InvoiceDetails) (#83). Se reconstruyen desde el buzón las sesiones sin registro del 21-ago al 10-sep (#71–#82): homologación de estados, false = remisión, la sesión del incidente, publicación en paputec.mx, cotización en lote y la primera prefactura observada por DevTools. Anterior: 21-ago — ⭐ primera cotización real emitida en BIND desde un ticket (folio 1026, #69); Type=2 y VAT como tasa, indocumentados. Anterior: 20-ago — cruce completo del buzón de Outlook vía MCP ms365 + recuperación del transcript del 12-ago. Se incorporan 10 comunicaciones que faltaban y se corrigen 2 errores. ⭐ Cambio de gobernanza: Pedro Ayala releva a Erika en el seguimiento del proyecto desde el 12-ago. Próxima sesión: viernes 21-ago, 7:00 am con Noé, Ara y Pedro sobre FAC-106) Orden: cronológico (más antiguo arriba)

0 · Abr 8–28, 2026 · Correo · Prehistoria comercial — cómo se fijó la tarifa por hora

⚠️ Entrada de inventario (añadida el 20-ago-2026). El registro arrancaba el 30-abr con la solicitud de cotización; el buzón muestra que la relación comercial se abrió cinco semanas antes. Los cuerpos de estos correos aún no se han leído — se listan aquí para que dejen de estar fuera del registro. Es el hilo donde se pactó la tarifa por hora que sostiene todo lo demás.

Fecha	Movimiento
8-abr	Paola (RH) → Johann · "Johann Velazquez - Proyecto Balam"
23-abr 10:18 am	Noé abre el hilo "Propuesta de servicios por hora - Balam" 📎 — "En seguimiento a la llamada de días previos para colaborar con nosotros como proveedor de servicios y sobre tu interés en participar en procesos de consultoría en desarrollo, automatización e IA (agentes, automatización, SLM's)…"
23-abr	Araceli · "Sesión Balam" + dos respuestas al hilo 📎 · Johann responde dos veces
24-abr	Paola 📎 · Johann responde 📎
27–28-abr	Paola cierra el hilo

Además, dos firmas en Buk sin explicar: "Tu documento está listo" + código de firma el 30-abr y otra vez el 5-may — anteriores al contrato de servicios de junio (#18, #19). Son dos documentos firmados que este registro nunca mencionó. Acción: identificar qué se firmó (¿NDA, convenio marco?) y si condiciona algo del contrato posterior.

1 · Apr 30, 2026 — 4:38 PM · Erika Chavez → Johann

Asunto: Solicitud de cotización – PRD CC: Noe Rocha, Araceli Sanchez

Buenas tardes,

Espero que se encuentren muy bien. Mi nombre es Erika Chávez, Project Manager en Balam. Es un gusto saludarte, Johann.

Por medio de este medio, te comparto el PRD con la finalidad de solicitar tu apoyo en la elaboración de la cotización correspondiente.

Quedo atenta a cualquier duda o comentario.

Saludos.

2 · May 4, 2026 — 3:30 PM · Johann → Erika (CC Noe, Ara)

Buenos días Araceli,

Gracias por compartir el PRD, ya lo revisé a detalle durante el fin de semana. El alcance está muy claro y bien estructurado.

Para preparar la propuesta técnica con una estimación precisa por fase, me surgen las siguientes preguntas:

Integraciones

¿BIND ERP tiene API habilitada o se trabaja con exportación de archivos?
¿BUK expone API para consultar nómina procesada?
¿Los 3 bancos entregan estados de cuenta por API, archivos (CSV/OFX) o PDFs?
¿Cuál es el banco americano que manejan?
¿Pueden dar acceso a ambientes sandbox de BIND y BUK para desarrollo, o solo cuentan con producción?

Facturación

¿Ya cuentan con un PAC contratado para timbrado CFDI? ¿Cuál?
La facturación a clientes en Texas, ¿es invoice estándar o requiere tax compliance específico?
El PRD menciona soporte para EUR en RF-02, pero la regla de facturación internacional refiere solo a USD. ¿Confirman que el MVP debe incluir EUR, o lo dejamos preparado para una fase posterior?

Cobranza

El PRD indica que ACUNTIA y los "top 3 clientes" no deben recibir recordatorios automáticos. ¿Quiénes son esos top 3? ¿Es una lista fija o configurable?
Se menciona el uso de tickets físicos en pagos con tarjeta como problema actual. ¿Esto se refiere a pagos con terminal donde el registro es manual?

Datos y sistemas

¿"Book" es un sistema interno? ¿Cuenta con API o base de datos accesible?
¿Jira se usa únicamente para gestión de proyectos o también como fuente de datos de clientes/colaboradores?

Operación

¿Aproximadamente cuántos colaboradores tienen en nómina y cuántas facturas emiten al mes?
¿Quién sería el contacto operativo para validar reglas de negocio durante el desarrollo?

Infraestructura y diseño

¿Tienen servidor o nube preferida para hospedar la plataforma, o propongo opciones?
¿Cuentan con guía de marca / assets (logo, colores, tipografía) para la plataforma, o se diseña desde cero?

Con estas respuestas puedo tener la propuesta lista en 24–48 horas. Si prefieren, podemos agendar una sesión corta de 20–30 minutos para revisarlas en conjunto.

3 · May 4, 2026 — 7:59 PM · Noe Rocha → Johann (respuestas inline)

Hola Johan, te paso los comentarios más abajo de lo que sé; algunos los tengo que investigar y otros los puede responder o aclarar Ara (TBD Ara).

Pregunta	Respuesta de Noe
¿BIND ERP tiene API habilitada?	Exportación de archivos
¿BUK expone API?	No hasta donde sabemos
¿Estados de cuenta de los 3 bancos?	PDFs
¿Cuál es el banco americano?	TBD Ara
¿Sandbox de BIND y BUK?	Solo producción
¿PAC contratado para CFDI?	Integrado en el mismo sistema de BIND (hasta donde sabe)
¿Facturación a Texas, tax compliance?	TBD Ara
¿EUR en MVP?	Dejarlo preparado para fase posterior. Por el momento solo USD con empresas europeas
¿Quiénes son ACUNTIA + top 3, lista fija o configurable?	Lista configurable de acuerdo al objetivo de negocio
¿Tickets físicos en pagos con tarjeta?	TBD Ara
¿"Book" es interno?, ¿API?	Es un SaaS
¿Jira para qué se usa?	Gestión de proyectos y servicios solamente con clientes
¿Cuántos colaboradores y facturas/mes?	45 colaboradores + 5 proveedores tipo freelancer
¿Contacto operativo durante desarrollo?	Un servidor (Noe) y el gerente administrativo
¿Nube preferida?	Preferentemente Azure; si hay mejor costo-beneficio, abiertos a evaluar
¿Guía de marca / assets?	TBD Ara

3a · May 6, 2026 — Araceli Sánchez → Johann · respuestas "en verde"

Asunto: RE: Solicitud de cotización – PRD · 3:42 PM · Para Noé, CC Johann ✅ Evidencia recuperada el 20-ago-2026 del buzón (MCP ms365): ../fuentes/2026-05-06 - Correo - Araceli respuestas al cuestionario (hilo PRD).md

"Te respondo en verde. Gracias, Saludos." Araceli responde los puntos que Noe dejó marcados TBD Ara el 4-may: (1) banco americano, (2) tax compliance para clientes en Texas, (3) tickets físicos en pagos con tarjeta, (4) guía de marca / assets.

✅ RESUELTO (20-ago-2026). El correo apareció íntegro en el buzón y las respuestas quedaron transcritas en ../fuentes/2026-05-06 - Correo - Araceli respuestas al cuestionario (hilo PRD).md. Lo que confirma:

⭐ Banco americano = "IBC BANK, es un banco Texano e ingresamos vía web." — deja de ser inferencia de la llamada del 19-may: está por escrito desde el 6-may.
⭐ Tax = "Por el momento TAX estándard" — ídem.
PAC: "Integrado hasta donde se en el mismo sistema de Bind, confirmo está contenido dentro del precio del ERP."
Pagos con tarjeta: no tienen terminal; lo que buscan es mandar un link de pago y/o domiciliación ("pólizas, etc"). Matiza el punto 3 de arriba: no era un problema de registro manual.
Manual de marca: sí existe y lo pueden compartir (se entregó el 1-jul, #23).

⚠️ Único residuo: el cuerpo se recuperó como texto plano, así que el resaltado verde no es recuperable y no puede distinguirse tipográficamente qué contestó Araceli y qué Noé. El contenido, que era lo que faltaba, sí está completo.

3b · May 6, 2026 — Johann → Balam · acuse

Asunto: Re: Solicitud de cotización – PRD (Fuente: lista del hilo de Outlook.)

"Muchas gracias por sus comentarios. Los incorporo a la propuesta y se las comparto a la brevedad." Johann acusa recibo de las respuestas (Noe inline + Araceli en verde) y anuncia que las incorpora a la propuesta.

4 · May 8, 2026 — 5:06 PM · Johann → Noe

Hola Noe,

Antes de compartirles la propuesta técnica final, me gustaría agendar una sesión contigo para revisar algunos puntos que impactan directamente el alcance:

Dashboards: ¿Qué campos e indicadores necesitan visualizar por módulo (facturación, cobranza, conciliación)? Quiero asegurarme de que el diseño refleje exactamente lo que el equipo de finanzas y dirección necesita ver.
Mapa técnico de datos: Sería muy útil que en la llamada me pudieras mostrar los sistemas desde donde sacaremos la información — qué sale de BUK, qué está en BIND, qué está en Book y cómo interactúan hoy. Esto me ayudará a dimensionar mejor la parte de integración y asegurar que no haya sorpresas durante el desarrollo.
Acceso a bancos: Si en algún punto se busca integración vía API bancaria, conviene definirlo desde ahora para contemplarlo en el alcance desde el inicio.

¿Tienes disponibilidad para una sesión de 30–45 minutos?

5 · May 11, 2026 — 5:47 PM · Noe → Johann

Hola Johan,

Te paso opciones para una reunión:

Miércoles de 7am a 8am, 6pm a 7pm
Jueves de 7am a 8am

Te doy opciones muy temprano o muy tarde para que se te acomode en tu horario. Si hay tiempo para ti de verlo en horarios intermedios nos podemos adecuar.

6 · May 12, 2026 — 10:27 PM · Johann → Noe

Hola Noe,

Jueves de 7-8am me parece bien.

Saludos.

7 · May 16, 2026 — 10:32 AM · Noe → Johann

Buenos días Johan,

¿Podemos tener la sesión este martes? O bien, si es algo de una llamada, ¿a qué número te podría marcar?

(Implícita: la llamada se sostuvo el martes 19 de mayo de 2026 — transcripción en ../fuentes/2026-05-19 - Transcript - Solicitud de cotizacion.txt.)

7a · May 16, 2026 — Johann → Noe · confirma sesión + comparte teléfono

Asunto: Re: Solicitud de cotización – PRD (Fuente: lista del hilo de Outlook.)

"Buen día Noe, claro, este martes podemos tener sesión. Cualquier cosa te comparto mi número: 8131610998. Saludos." (La sesión se sostuvo el martes 19-may; ver #7.)

8 · May 25, 2026 — 10:41 PM · Noe → Johann

Hola Johann,

En el caso de Bind tiene una API que veo factible que podamos usar para nuestra necesidad:

Como dato tiene un límite de 20 mil solicitudes diarias, no sé si es poco o mucho para nuestra necesidad, pero hay que tomarlo en cuenta.

Como nuestro primer interés es el tema de facturación, considero que la propuesta sería primero solo considerando el sistema ERP Bind.

Saludos.

9 · May 27, 2026 — AM · Pedro (desarrollador, Balam) → Johann ⭐ (último mensaje)

Buenos días Johan,

Espero te encuentres bien. Quiero compartirte una actualización respecto a nuestra plataforma BUK: confirmamos que sí cuenta con soporte API para integraciones con herramientas externas. Puedes consultar la documentación disponible en el siguiente enlace.

(Nota: el link al API no se incluyó en el mensaje recibido; pendiente solicitarlo en la respuesta.)

Aunque esta integración no es prioridad en este momento, queremos que cuentes con esta información para que puedas preparar una propuesta cuando sea oportuno avanzar con el tema.

En cuanto tengamos mayor claridad sobre los tiempos, te los haremos saber.

¡Saludos!

Lectura estratégica:

Pedro está ejecutando lo que Noe le pidió en la llamada del 19-may (acelerar con BUK / Book / proveedores).

No cambia el alcance del MVP — BUK sigue siendo Fase 2 post-MVP.

Sí confirma viabilidad técnica del ciclo end-to-end Jira → BUK → Plataforma → BIND para Fase 2.

Pedro perfila como contacto técnico día a día durante el proyecto (responde la pregunta abierta del checklist).

10 · May 29, 2026 — 2:44 PM · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta

Asunto: Re: Solicitud de cotización – PRD Evidencia: hilo ../fuentes/RE_ Solicitud de cotización – PRD (1).eml (en este punto Pedro ya aparece en CC). Adjunta la propuesta v1.0 en PDF. El cuerpo del correo ("Adjunto la propuesta para la plataforma de automatización financiera que conversamos…") consta dentro del .eml.

Envío de la propuesta v1.0 en PDF (Propuesta-Balam.pdf). MVP BIND-first enfocado en facturación: consulta + emisión asistida de facturas MXN/USD vía API de BIND (con dry-run + confirmación humana; timbra el PAC de BIND), cobranza operativa (aging, alertas internas, lista blanca ACUNTIA + Top 3), dashboard, reportes y bitácora. Inversión $67,200 – $81,600 MXN + IVA, 6–7 semanas, anticipo de 30 h ($18,000 + IVA) para Discovery. Módulos diferidos (conciliación, Stripe, recordatorios a clientes, asientos, BUK) cotizados de forma indicativa en el Anexo B.

11 · Jun 2, 2026 — 5:33 PM · Pedro → Johann, Noe (CC Ara, Erika)

Asunto: RE: Solicitud de cotización – PRD

"Buenas tardes, Johan. Gracias por compartir la propuesta. @Noe Rocha y yo la hemos revisado y tenemos varios comentarios que nos gustaría compartir contigo directamente en una sesión conjunta. ¿Nos podrías compartir tu disponibilidad para mañana por la tarde, o tu horario de preferencia para el jueves 4 de junio?"

12 · Jun 2, 2026 — 9:39 PM · Johann → Pedro, Noe (CC Ara, Erika)

"Buen día, Pedro: Claro que sí, con gusto. Me funcionaría mejor el jueves 4 de junio a las 7:00 am para revisar los comentarios juntos. Si a esa hora no l[es funciona]…" (vista previa)

13 · Jun 3, 2026 · Pedro → Johann, Noe (confirmación + liga Teams)

"Buenos días, Johan. Te agendo para el día de mañana a las 7 am. Te comparto el link de la sesión. Reunión de Microsoft Teams — Unirse: https://teams.microsoft.com/meet/22…" (vista previa)

Queda confirmada la sesión: jueves 4-jun, 7:00 am, por Microsoft Teams.

14 · Jun 4, 2026 — 7:00 AM · Llamada de revisión de propuesta ⭐

Participan: Noe, Pedro, Erika y Johann. Transcripción completa en ../fuentes/2026-06-04 - Transcript - Revision de propuesta.txt.

Veredicto general: "En términos generales, la propuesta está bien." El proyecto avanza; hay puntos a negociar/ajustar antes de formalizar.

Acuerdos y decisiones:

Anticipo $18,000 (Discovery): APROBADO. Arrancan con eso; el monto final del MVP se aclara tras Discovery (Noe entiende que el rango $67.2K–$81.6K depende de lo que se encuentre).
Conciliación: Noe la quiere incluir (hoy es 100% manual y ya es un problema real). Vio que está cotizada en el Anexo B (~$48–63K). Condicional al flujo: si facturación queda en ~$67K pediría conciliación de inmediato; si sube a $81.6K, evaluará tiempos/flujo en las próximas semanas. Enfoque platicado: estados de cuenta PDF → extracción (librerías/OCR/IA) → matching por algoritmo (~98%) usando la API de BIND para las facturas. Involucrar a Arturo (bancos).
Dashboard/reporteo: posible recorte. Balam ya tiene un tablero Power BI (hecho por Pedro) que resuelve antigüedad de cartera; Noe no quiere pagar por lo que ya tienen. Sí quiere el módulo de cobranza + alertas internas (que el tablero no ejecuta). Validar con Pedro qué del dashboard es redundante.
Lista blanca: confirmado que es configurable, no limitada a 3.
Soporte/mantenimiento: a Noe no le gusta la caducidad de horas a 30 días ("úsalo o lo pierdes"); pide negociar mayor vigencia. Johann: negociable.
API BIND: Pedro hoy usa la llave de Araceli para el Power BI; para desarrollo se usará otra (de Arturo, mismos permisos). BIND parece permitir 1 API key por usuario (Pedro confirmará); generarlas desde la cuenta maestra (ARA) y documentar cuál es para qué.
Azure: se gestiona con Guajardo / Erika. Johann requiere permisos para crear App Service + PostgreSQL (no Global Admin).
Manual de marca: existe (paleta, tipografía, logos); Pedro lo envía.
Reglas de negocio: se definen con Arturo + Pedro.
Metodología IA: aclarado = no se entrenan modelos con datos de Balam. Noe OK.
Pagos: anticipo a 7 días OK; avances a 30 días (Balam cobra a sus clientes a 60–120 días; 30 es el mínimo negociado). Johann aceptó.
Gestión del proyecto: en Jira (estilo ágil/Yael, no Gantt). Pedro crea el espacio (plan free); Erika valida entregables para el pago.
Comunicación: canal de WhatsApp + correo para evidencia formal. Erika = contacto principal · Pedro = técnico · Arturo = negocio.
Fiscal (Johann): en proceso de cambiar régimen (24 h); confirma que sí puede facturar.
Inicio: Johann puede empezar cuanto antes, de preferencia inicio de semana para coordinar con Arturo.

Próximos pasos definidos en la llamada:

Noe formaliza por correo a partir del 5-jun: solicita factura de anticipo, envía info/accesos y los ajustes a la propuesta para arrancar.
Johann: cambiar régimen fiscal (24 h), emitir factura de anticipo, preparar Discovery.
Pedro: enviar manual de marca; revisar llaves API (cuántas por usuario, generar desde ARA); crear proyecto en Jira.
Pendiente con Arturo: reglas de negocio + acceso a bancos (conciliación).
Azure: gestionar con Guajardo/Erika.

15 · Jun 8, 2026 — 6:15 PM · Correo · Noe → Johann (CC Ara, Erika, Pedro) · aclaraciones y preguntas

Evidencia: ../fuentes/2026-06-08 - Correo - Noe aclaraciones y preguntas.md. Re-adjunta Propuesta-Balam.pdf.

Noe formaliza por escrito 4 aclaraciones/ajustes y 3 preguntas, antes de avanzar:

Ajustes solicitados:

La inversión final del módulo de facturación queda supeditada al Discovery (112 vs 136 h, 6–7 sem). — De acuerdo, así estaba planteado.
Soporte: el límite de consumo mensual es limitante; piden bolsa de horas vigente 12 meses (paquetes por hora, no mensualidad con caducidad).
Garantía: piden 45 días (no 30) — el ciclo financiero es mensual y los defectos no se ven hasta pasado el cierre.
Sin anticipos (política Balam) y pago estricto a 30 días post-factura. Proponen: Johann factura las 30 h de la Etapa 0 y se programa el pago a 30 días.

Preguntas:

¿Qué pasa si el Discovery revela que la API de BIND no soporta la escritura/emisión esperada?
Si el Discovery reduce horas, ¿se puede adelantar algo de conciliación?
Sin sandbox, ¿qué garantías concretas contra una emisión errónea con efecto fiscal? ¿Hay reversa/cancelación contemplada?

Acción Johann: responder el correo (respuestas + postura comercial) y reflejar los cambios en la propuesta v1.1. Decisión clave: aceptar el esquema sin anticipo / pago a 30 días (impacto en flujo). Ver PENDIENTES.md.

16 · Jun 10, 2026 — 6:11 PM · Johann → Noe (CC Ara, Erika, Pedro) · respuesta + propuesta v1.1

Asunto: RE: Solicitud de cotización – PRD CC: Araceli Sánchez, Erika Chávez, Pedro Ayala Evidencia: ../fuentes/2026-06-10 - Correo - Johann respuesta v1.1.md. Adjunta Propuesta-Balam.pdf (v1.1).

Johann responde el correo del 8-jun, acepta los 4 ajustes y contesta las 3 preguntas técnicas; reenvía la propuesta v1.1.

Respuesta a los ajustes:

Inversión del módulo de facturación: de acuerdo, se confirma con el Discovery (112–136 h, 6–7 semanas).
Soporte: de acuerdo. Replanteado como bolsa de horas a $600/h + IVA, vigencia 12 meses desde su contratación, sin caducidad mensual.
Garantía: de acuerdo, 45 días (cubre el primer cierre mensual).
Sin anticipo / pago a 30 días: de acuerdo. Factura las 30 h de la Etapa 0 al inicio y el pago corre a 30 días, igual que los avances. Única condición: dejar firmado el contrato/orden de trabajo antes de iniciar (la firma formaliza el compromiso y le permite arrancar de inmediato).

Respuesta a las preguntas:

Si BIND no soporta escritura/emisión: es lo que el Discovery valida antes de construir. Si no es viable o implica riesgo, la facturación se entrega en modo asistido (la plataforma prepara y valida; la emisión final se confirma en BIND) y se reajusta el alcance del módulo. No se invierte en construir algo que no funcione.
Si el Discovery reduce horas: sí, la capacidad liberada puede arrancar un primer alcance de conciliación, con mini-scope y estimación al cierre del Discovery.
Garantías sin sandbox / reversa: la emisión tiene cinco candados — lectura primero, validación en Discovery, dry-run antes de cada emisión, confirmación humana obligatoria por factura y feature flag apagado por defecto. La plataforma no auto-emite; el timbrado lo hace el PAC de BIND. La cancelación de un CFDI corre por el proceso fiscal BIND/SAT (con su ventana de aceptación); la plataforma puede disparar/registrar esa solicitud vía API de BIND si la soporta — a confirmar en Discovery.

Lectura estratégica:

Johann cede en lo comercial (sin anticipo, 30 días, 45 días garantía, soporte 12 meses) pero fija un candado propio: firma del contrato antes de arrancar, que sustituye al anticipo como mecanismo de compromiso. Es el punto a vigilar.

Las 3 respuestas técnicas desactivan los riesgos que Noe planteó sin ampliar alcance: el Discovery sigue siendo la red de seguridad.

La conciliación queda explícitamente condicionada a horas liberadas por el Discovery — coherente con lo que Noe pidió el 4-jun.

17 · Jun 16, 2026 — 3:35 PM · Noe → Johann, Pedro (CC Ara, Erika) · luz verde ⭐

Asunto: Solicitud de cotización – PRD CC: Araceli Sánchez, Erika Chávez Evidencia: ../fuentes/2026-06-16 - Correo - Noe luz verde y documento de firma.md. Adjunto: Outlook-p2vlyjhm (50 KB). (Hora 3:35 PM tomada de la captura del correo.)

Balam da luz verde a los términos de la v1.1. Noe confirma:

"Estamos de acuerdo con lo que se definió." Balam ya está redactando el documento para firmar estos acuerdos.
Pide a Johann esperar a que le envíen todo para los siguientes pasos (queda en hold del lado del proveedor).
Instruye a Pedro a armar el tablero de seguimiento en JIRA y revisarlo con Erika para el seguimiento del proyecto de desarrollo, "para ir preparando el camino".

Lectura estratégica:

Hito comercial: el cliente acepta formalmente la propuesta v1.1. El proyecto pasa de "negociación" a "preparación de firma".

La pelota está del lado de Balam: redactar el documento de firma. Johann debe revisarlo cuando llegue (verificar que recoja: sin anticipo + firma previa, 30 días de pago, 45 días de garantía, soporte bolsa 12 meses, alcance MVP BIND-first y el condicionante de Discovery) antes de firmar.

Se activa el tablero Jira (Pedro + Erika), tal como se acordó el 4-jun — primer paso operativo real.

No hay accesos ni fecha de arranque todavía: el Discovery no inicia hasta que llegue el documento firmado + los accesos.

18 · Jun 25, 2026 — Balam (vía Paola, RH) → Johann · contrato de servicios para firma

Evidencia: ../fuentes/2026-06-26 - WhatsApp - Paola (RH) ajustes y firma de contrato.md. Contrato: ../propuesta/2026_06-25_12-13__Contrato_de_servicios_profesionales__Johann_Joseph_Velazquez_Antonio.pdf.

Balam envía el Contrato de Prestación de Servicios Profesionales (PDF) para firma, coordinado por Paola (Recursos Humanos) vía WhatsApp. Es el "documento de firma" que Noe anunció el 16-jun (#17). Recoge los términos v1.1: sin anticipo, pago a 30 días, garantía 45 días, alcance MVP BIND-first, firma como condición de arranque, propiedad intelectual de Balam, y facturación semanal (viernes) por horas trabajadas. Johann pide corregir su segundo nombre ("Josep" → "Joseph"); Paola corrige.

19 · Jun 26, 2026 — WhatsApp Johann ↔ Paola (RH) · ajustes finales y FIRMA del contrato ⭐

Evidencia: ../fuentes/2026-06-26 - WhatsApp - Paola (RH) ajustes y firma de contrato.md. Contrato firmado: ../propuesta/2026_06-26_14-19__Contrato_de_servicios_profesionales__Johann_Joseph_Velazquez_Antonio.pdf.

Johann revisa el contrato a detalle y plantea observaciones por WhatsApp. Balam acepta 2 ajustes y los agrega (nueva cláusula "Terminación anticipada, pago de servicios y aceptación de entregables"):

Pago al terminar: en terminación anticipada se pagan las horas efectivamente trabajadas hasta la fecha.
Aceptación de entregables: se dan por aceptados si no hay comentarios por escrito en 10 días naturales; correcciones limitadas al alcance pactado.

Correcciones aplicadas: firmas → "EL CLIENTE / EL PRESTADOR DE SERVICIOS" (se quitó "TRABAJADOR"); se eliminó el párrafo "Para constancia" duplicado.

Johann FIRMA el contrato (firma electrónica, 26-jun 14:48, RFC VEAJ031228MD6).

Lectura estratégica:

Cierre formal del cierre comercial. El proyecto queda contratado; falta que Balam entregue los accesos para arrancar.

Residuo (bajo riesgo): la cláusula "Firma Electrónica" de la última página quedó duplicada y aún dice "EL PATRÓN" (residuo de plantilla). Opcional pedir copia limpia; el resto del contrato define bien a las partes y declara que no hay relación laboral.

Términos NO incluidos (Johann decidió no insistir): tope/límite de responsabilidad, rescisión recíproca, metodología IA, "lugar de servicios", bolsa de horas 12 meses.

Facturación semanal (viernes) por horas + 30 días — distinto del "por etapa" de la propuesta; es lo vinculante.

20 · Jun 29, 2026 — WhatsApp Erika → Johann · arranque del plan de actividades ⭐

Evidencia: ../fuentes/2026-06-29 - WhatsApp - Erika arranque del plan de actividades.md.

Erika (PM, contacto principal) confirma que ya pasaron los temas administrativos internos de Balam y arranca la coordinación de ejecución. Pide a Johann un listado de actividades con fechas (Excel) por etapas (como en la propuesta), empezando por Etapa 0 y 1: actividad · fecha inicio–fin · responsable, alineado a los entregables, indicando dónde requiere apoyo de Balam. Ofrece llamada de 5 min.

Lectura estratégica:

El proyecto entra en fase de ejecución / kickoff.

Acción de Johann: preparar el Excel de actividades (Etapa 0 y 1) y proponer sesiones de Discovery (conocer el proceso actual + encaminar el prototipo) — parte de la Etapa 0; el contrato ya obliga a Balam a dar disponibilidad de interlocutores.

Sigue pendiente que Balam entregue los accesos (API BIND, Azure, manual de marca, reglas con Arturo).

21 · Jun 29–30, 2026 — WhatsApp Johann ↔ Erika · plan de actividades entregado + kickoff agendado ⭐

Evidencia: ../fuentes/2026-06-29 - WhatsApp - Erika arranque del plan de actividades.md. Plan vigente consolidado: ../planeacion/Plan-actividades-avance-2026-07-10-ajustado.xlsx (+ .md).

Johann entrega el plan de actividades (Excel sencillo: actividad · fecha inicio–fin · responsable · apoyo de Balam): primero Etapa 0 y 1 (29-jun) y luego enviado completo, las 4 etapas (0–3) con fechas tentativas (30-jun, 12:34). Las sesiones quedan ubicadas por etapa; la Etapa 0–1 se mantiene idéntica a lo enviado el 29-jun.
Erika confirma que será la intermediaria de todas las sesiones ("lo que necesites me lo pides y yo coordino agendas").
Kickoff con el Ing. Noé CONFIRMADO: miércoles 1-jul, 7:00 am.
Erika está montando el tablero Kanban en Jira para el seguimiento (mide avance por %).

Lectura estratégica:

Arranca la operación: el 1-jul es el kickoff. Etapa 0 (ejecución) planeada para la semana del 6-jul, condicionada a accesos.

Erika como punto único de coordinación de sesiones simplifica la logística (Johann define qué necesita; ella agenda con la persona correcta).

Bloqueador vivo: accesos de Balam (API BIND, Azure, manual de marca, reglas con Arturo).

22 · Jul 1, 2026 — 7:00 AM · Llamada · Kickoff del proyecto ⭐

Participan: Noe Rocha, Pedro Ayala, Erika Chávez y Johann. Canal: Microsoft Teams. Evidencia: ../fuentes/2026-07-01 - Transcript - Kick off-Proyecto integración Balam.txt.

Resumen: Arranque formal del MVP. Noé fija la expectativa (plataforma robusta en menos de 6 meses, con posible integración futura de CRM — "vámonos por partes"). Revisan el GANTT por etapas, el detalle de accesos, la mecánica de horas en Jira y —el punto más largo— cómo vincular la factura de la Etapa 0 con el documento contractual.

Acuerdos / decisiones:

API BIND (token): solo Ara y Arturo tienen usuario en BIND; se acordó que los tokens salgan de la cuenta mayor (todos los permisos habilitados). Para desarrollo se usará el token de Arturo (aún sin usar), dejando el de Ara para los tableros Power BI. BIND = 1 token por usuario, no caducable ni múltiple. Se probará primero el token de Arturo para confirmar que expone todo lo necesario. Entendimiento: es de pura consulta (invoices, facturas, pagos); esta etapa es solo visualización, sin edición.
Manual de marca: Pedro lo envía hoy por correo (paquete de branding). → cumplido, ver #23.
Repositorio: lo crea Balam / Pedro (GitHub privado) para montar backend/frontend en Fase 1–2. (Antes se preveía que lo montara Johann; ahora lo provee Balam.)
Azure: lo gestionan Pedro + Noé (Noé otorga permisos donde Pedro tiene limitantes).
Discovery / proceso actual: sesión sí o sí con Arturo y Araceli (Araceli conoce mejor el proceso; Arturo lleva 3 meses y aún no define todo). Erika la coordina (pedirá horas disponibles del equipo).
Horas / Jira: Johann reportará sus horas en Jira igual que los demás consultores, subiendo incluso material informativo para transparencia. Pedro le enseñará el flujo. Erika hace el corte los lunes y reporta a dirección al cierre de semana.
Facturación Etapa 0 = 30 h (tema abierto): se confirma el monto (30 h), pero la propuesta dice Etapa 0 = 18–22 h, lo que el área de pagos/compras cuestionará. Noé necesita que la factura sea muy vinculante con un documento. Acción (Erika + Paola): revisar si el contrato ya ata las 30 h; si no, pedirán por correo a Johann ajustar la propuesta para que indique explícitamente las 30 h — sin etiquetarlo "Etapa 0" (para no contraponerse con las 18–22 h que figuran arriba; "primer pago por 30 h" abarcaría Etapa 0 + un poco más). Johann aún no factura: espera la aclaración/correo para emitir con redacción clara. Balam quiere que ya corra el plazo de pago (30 días).
Conciliación: sigue de interés; se evaluará integrarla en esta primera fase según lo que arroje el Discovery (que definirá 112 vs 136 h del módulo de facturación). Hoy la hacen 100% manual.

Pendientes que surgieron:

Balam/Pedro — generar y entregar el token de Arturo (BIND) y probar cobertura de endpoints — arranque Discovery.
Balam/Pedro — crear el repositorio GitHub privado.
Pedro + Noé — configurar Azure y permisos.
Pedro — enseñar a Johann el flujo de Jira (reporte de horas).
Erika — coordinar la sesión de Discovery con Arturo + Araceli (pedir horas disponibles).
Erika + Paola — revisar si el contrato vincula las 30 h; de no ser así, solicitar a Johann por correo el ajuste de la propuesta.
Johann — no facturar aún; al recibir el correo, ajustar la propuesta (30 h explícitas, sin llamarlo "Etapa 0", términos comerciales en una sola sección) y emitir la factura.

Citas relevantes: "Vámonos por partes, como dice Chuck el destripador." · "Necesito que sea muy vinculante al tema del pago con lo que dice el documento… me van a decir ¿dónde dice que son 30 horas?" · "Como recomendación, cuando hables de términos comerciales, déjalo en una sola sección."

Lectura estratégica:

El bloqueador ya no es solo "accesos": la emisión de la primera factura queda condicionada a que Balam aclare internamente (contrato vs propuesta) y lo pida por correo. Johann hizo bien en no facturar todavía; conviene tener lista la versión ajustada de la propuesta para responder rápido cuando llegue el correo.

Balam asume más de la infraestructura de lo previsto (crea el repo, gestiona Azure con Pedro/Noé), lo que reduce fricción de accesos para Johann.

Token de Arturo, solo consulta: coherente con la estrategia de "lectura primero"; la escritura/emisión se valida en Discovery. Un solo token por usuario refuerza el pendiente de documentar cuál llave es para qué.

Erika = punto único para agendar la sesión Arturo+Araceli, clave del Discovery. Jira pasa a ser obligatorio para el reporte de horas (corte lunes).

23 · Jul 1, 2026 — 7:33 AM · Correo · Pedro → Johann · manual de imagen corporativa

CC: Noe Rocha, Erika Chávez, Araceli Sánchez. Dirección: recibido. Evidencia (adjunto): ../fuentes/manual de imagen corporativa - Balam.pdf.

Resumen: Pedro comparte el manual de imagen corporativa de Balam "para su uso en la herramienta que se desarrollará". Sobre el API de BIND, indica que buscará a Johann "en otro momento para ver este tema" (queda para coordinar por separado). Es el "paquete de branding" que Pedro ofreció en la llamada de hoy (#22).

Acción derivada: cierra el pendiente del manual de marca. Los tokens (color, tipografía, uso de logo) quedan destilados en ../marca/Marca-Balam.md para el prototipo de la Etapa 0.

Adjuntos: manual de imagen corporativa - Balam.pdf.

Nota de marca: colores oficiales Amarillo #F7BD0C + Café #331F0E + Blanco; tipografía Poppins. El ámbar #C0892F de la propuesta PDF es acento editorial de Johann, distinto del amarillo de marca — para la plataforma se usan los oficiales.

24 · Jul 1, 2026 — WhatsApp Erika ↔ Johann · agenda la sesión "Proceso actual de facturación y cobranza" (lunes 6-jul)

Evidencia: ../fuentes/2026-07-01 - WhatsApp - Erika coordinacion sesion facturacion-cobranza.md.

7:01 AM: Erika confirma con Johann que ya están en la sesión de kickoff y que se pueda conectar (ver #22).

1:45–1:46 PM: Erika pregunta si puede pedir agenda a las personas involucradas en el proceso de facturación y cobranza para verlo el lunes 06 y martes 07 de julio a las 7 am. Johann da el visto bueno; Erika queda en confirmar por correo.

6:09–6:39 PM: Erika confirma que le aceptaron la reunión del lunes 06 a las 7 am y envía la liga de Teams. Convocatoria: "Proceso actual de facturación y cobranza- Balam", lunes 6-jul 7:00–8:00 AM, organiza Erika, invitados Johann, Araceli Sánchez Jiménez y Arturo Rosas Hernández (CC Noe Rocha).

Lectura estratégica:

Esta sesión es la reunión de Discovery con Arturo + Araceli que Erika se comprometió a coordinar en el kickoff (#22) — cierra ese pendiente.

Solo quedó confirmado el lunes 6-jul; no hay evidencia de que se haya agendado también el martes 7-jul mencionado por Erika. A confirmar si hace falta una segunda sesión.

25 · Jul 2, 2026 — 4:18–4:41 PM · WhatsApp Erika ↔ Johann · agenda/materiales para la sesión del 6-jul

Evidencia: ../fuentes/2026-07-01 - WhatsApp - Erika coordinacion sesion facturacion-cobranza.md.

Erika pregunta si Johann necesita algún documento o ejercicio de parte de Balam para la sesión del lunes, para poder anticiparlo a los asistentes. Johann responde con los puntos que propone cubrir:

Proceso de facturación en BIND (PDF/XML), con ejemplos en USD y MXN.
Revisión de cobranza y reglas de crédito.
Confirmación de la "lista blanca" de clientes (sin recordatorios).
Cualquier otro tema operativo que tengan en el radar.
Pregunta si ya tienen el token de BIND disponible, para poder arrancar con lo técnico.

Lectura estratégica:

Johann fija la agenda de la sesión de Discovery (#24) antes de que ocurra — mismos temas que venía preguntando desde el 4-may (facturación BIND, cobranza, lista blanca).

Aprovecha el mensaje para dar seguimiento al token de BIND (de Arturo), pendiente desde el kickoff (#22) — sin respuesta todavía a este punto.

26 · Jul 2, 2026 — 5:39 PM · Correo · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta v1.2

Asunto: RE: Solicitud de cotización – PRD Para: Noe Rocha · CC: Araceli Sánchez Jiménez, Erika Chávez, Pedro Alberto Ayala Elizondo Adjunto: Propuesta-Balam.pdf (v1.2, 2 MB).

"Buenas tardes a todos, como comentamos en la sesión, les comparto la propuesta actualizada (v1.2, adjunta), donde queda explícita la facturación inicial de 30 horas al arranque del proyecto, con pago a 30 días naturales. Quedo atento a su confirmación para proceder con la emisión de la factura correspondiente. Cualquier comentario o ajuste, con gusto lo revisamos antes."

Johann envía la propuesta v1.2 (30 h de facturación inicial explícitas, condiciones comerciales consolidadas en §3.3) y queda a la espera de que Balam confirme para poder emitir la factura.

Lectura estratégica:

Johann toma la iniciativa: en el kickoff (#22) el plan era que Erika+Paola revisaran primero el contrato y, de ser necesario, pidieran por correo el ajuste; en vez de esperar ese correo, Johann ya envió la propuesta ajustada directamente, lo que puede acelerar el ciclo de la factura.

Sigue vigente el candado: no facturar hasta recibir la confirmación de Balam sobre este correo. Ver PENDIENTES.md.

Nota menor: el documento adjunto conserva la frase "arranque condicionado a contrato u orden de trabajo firmado" (§3.3 y Próximos pasos), redactada como si la firma estuviera pendiente — cuando el contrato ya se firmó el 26-jun (#19). No debería generar confusión (Balam ya sabe que está firmado), pero queda anotado por si alguien lo señala.

27 · Jul 6, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de facturación y cobranza ⭐

Participan: Araceli Sánchez (comercial/dirección), Arturo Rosas Hernández (administración/facturación), Erika Chávez y Johann. Noé era opcional y no asistió. Canal: Microsoft Teams (~1 h 5 min). Evidencia: ../fuentes/2026-07-06 Proceso actual de facturación y cobranz_ Transcript.txt.

Resumen: Primera sesión de Discovery (Etapa 0). Araceli y Arturo muestran en vivo el proceso completo de facturación: entrada por Jira ITSM (obligatoria desde hace ~1 mes) → validación de administración → prefactura en BIND → emisión de CFDI → envío por correo con particularidades por cliente. Se demostró el flujo real en BIND (crearon y cancelaron una prefactura en vivo). Dos reglas de negocio cambiaron en la propia sesión. La parte de cobranza NO se cubrió — solo se tocaron la lista blanca y la idea de recordatorios; el proceso de seguimiento de pagos queda pendiente de mapear (cuando Johann preguntó si después seguía cobranza, Ara redirigió al proceso de envío de factura).

El proceso actual, paso a paso

1. Entrada — Jira ITSM (portal de servicios interno):

Desde hace ~2 quincenas es mandatorio: "si no hay algo que se levante a través de Jira en un ticket, no se factura". Antes se controlaba con un Excel manual → facturas olvidadas (descubrían en marzo que enero no se facturó) y errores de moneda.
Módulo Administración General → Facturación, con dos tipos: "Facturación adicional" (suma) y "Bajas" (resta).
El portal sirve a varias empresas (Balam, Regiotour, Elmstone); el campo "empresa origen" las distingue. A futuro quieren que la plataforma facture también para las demás — por ahora el foco es Balam.
Campos del formulario: empresa origen · summary · proyecto · cliente nuevo (sí/no — si es nuevo se adjunta cédula de identificación fiscal + cotización; si es recurrente solo cotización) · moneda (MXN/USD) · días de crédito (default 30; a veces 45; CEMEX 90 innegociable) · periodo de incidencias (horas extra, periodos de servicio, comentarios) · facturación recurrente (sí/no) + periodo de recurrencia en meses (el equipo de tecnología trabaja en que las recurrencias se detonen solas cierto día).
Quién lo llena: siempre la parte comercial = Araceli (excepcionalmente Pau la apoya). "El deber ser es que la parte comercial siempre levante el ticket."
Tres vías generan factura: (a) ticket directo de facturación adicional; (b) Headhunting — el ticket de RH detona automáticamente una factura de anticipo y, al colocar a la persona, el 50% o 100% restante; (c) Staff augmentation — al arrancar la persona en el cliente se genera el ticket de factura.
Ruteo: todos los tickets se asignan por regla a una sola persona: Arturo. Administración hace doble check (datos, cédula fiscal, estado de cuenta) sobre la lista.
Flujo interno del ticket con SLAs: solicitud abierta → proceso de facturación → (espera del colaborador / cancelado) → se adjunta PDF + XML obligatorios como evidencia → botón de validación/autorización → estatus "facturado". Flujo alterno de facturación extranjera: sin XML, solo la invoice en PDF ("validación extranjera").

2. BIND ERP (lo opera Arturo):

Consulta: Finanzas → Cuentas por cobrar (facturas en proceso, vencidas, pagadas — ahí dan seguimiento a cobranza).
Creación: Ventas → generar documento. Siempre hacen prefactura primero (no se timbra ante el SAT; cancelar una factura timbrada es retrabajo administrativo y contable) → doble check → Emitir CFDI.
Prerequisitos que asumen cargados: cliente dado de alta, cuentas, moneda. Pregunta abierta que dejó Arturo: definir qué hará la automatización cuando el cliente NO esté dado de alta (proceso aparte).
Campos relevantes: sucursal (hoy solo matriz; serviría para facturar por unidad de negocio a futuro) · días de crédito (manual, editable, default del cliente) · orden de compra (deber ser: OC autorizada como prerequisito) · uso CFDI: "gastos en general" (nacional) y "sin efectos fiscales" (extranjera — se timbra igual pero con IVA 0%) · método de pago PPD/PUE · conceptos precargados editables (ej. 029 "consultoría y servicios"; sugieren incluir el nombre del recurso) · dirección fiscal precargada · comentarios (ponen el ticket de Jira para cruzar reportes).
⚠️ PPD vs PUE es delicadísimo: siempre dan crédito → casi todo es PPD. Hace ~2 años administración seleccionó PUE por error y les cayó un requerimiento del SAT. PUE exige complemento de pago timbrado el mismo día. (Regla de validación clara para la plataforma.)
⚠️ IVA no es automático en BIND: "sin efectos fiscales"/extranjero debería ir con 0% y pesos con 16%, pero BIND no lo pone solo — Arturo lo capturó manualmente (y en el ejemplo puso 16% en una sin efectos fiscales; Ara lo señaló). Otra validación clara para la plataforma. Además, por ser reclutadora a veces llevan retenciones adicionales.
Tras la prefactura se habilitan: emitir CFDI, registrar pago, nota de crédito, editar, copiar (así manejan las recurrencias), cancelar, exportar partidas a Excel, enviar por email (a los correos configurados del cliente), descargar PDF, póliza contable.

3. Envío al cliente (el paso que les falta sistematizar):

La facturación "termina" hasta que la factura se envía por correo, y cada cliente tiene particularidades: Axie (extranjero): facturas + estado de cuenta de todas las facturas · CEMEX: factura a un hub + Excel de horas del colaborador con visto bueno del jefe + nomenclatura específica del asunto (número de proveedor, mes, número de factura en posiciones exactas) y redacción específica del correo · Dilo (proyectos): factura + cotización del proyecto · Acuntia: .zip + estado de cuenta.
Tienen un Excel con cliente → destinatarios; les falta la columna de adjuntos/particularidades. Ara + Arturo se comprometieron a completarlo y enviarlo HOY (6-jul).
Volumen real: ~55 facturas/mes de solo 4–6 clientes — el cliente mayor exige una factura por colaborador (~40 colaboradores); agrupadas serían 5–6 facturas.

Dolores (en palabras de Ara, dirección general)

El caos de control ya lo mitigó Jira; el dolor vivo es que el proceso en BIND sigue siendo manual → errores en montos, descripciones, moneda, IVA, PPD/PUE.
No quiere "engrosar la nómina" con capturistas: quiere que la automatización absorba la carga y enfocar a la gente en actividades de más valor. El volumen es bajo (~55/mes); el problema es la incidencia de errores, y están en franco crecimiento.
Reporteo ya lo cubren con Power BI; lo que piden de la plataforma es que administración solo valide prefacturas antes del envío.
Dónde quieren la automatización: después de Jira (confirmado explícitamente por Ara y Arturo cuando Johann lo preguntó). Idea de Arturo: que los agentes observen Jira (botones/aprobaciones del flujo) para saber cuándo accionar en BIND.

🔄 Cambios de reglas de negocio (decididos en la sesión)

Lista blanca ELIMINADA. Solo tenían a Acuntia (nunca hubo "top 3" reales). Y en la propia llamada Ara revirtió la decisión: los recordatorios de morosidad deben ir a TODOS los clientes, sin excepciones — hoy arrastran una factura de febrero y otra de abril justamente del cliente "muy pagador" por no recordarle a tiempo. Arturo coincidió: con recordatorios automáticos no habrían llegado a julio con una factura de febrero.
Cotización en BIND = punto de partida OBLIGATORIO. Ara lo fijó como requisito formal: "sí puedes tomar, Johann, como un requisito de que vamos a partir de una cotización del sistema". El deber ser: comercial genera la cotización en BIND → se adjunta al ticket de Jira → administración (o el agente) la convierte a prefactura con un clic → validación humana → CFDI. Para cliente nuevo: comercial levanta ticket → administración (que tiene el privilegio) da de alta al cliente en BIND → avisa → comercial ya puede cotizar. No quiere "desarrollo con parchecitos". (Excepción discutida y descartada: aun en headhunting con rango salarial abierto, la cotización puede esperar al cierre — siempre habrá cotización.)

Acuerdos / próximos pasos de la sesión:

Ara + Arturo — enviar hoy (6-jul) el Excel de particularidades de envío por cliente (destinatarios + adjuntos + nomenclatura).
Johann — trabajar el prototipo reflejando el flujo real (lo dijo al cierre: "ya me da una idea más clara de cómo trabajar el prototipo que les mostraré"). Dudas de seguimiento vía Erika.

Lectura estratégica:

El flujo real valida el diseño de la propuesta: cotización → factura vía API era exactamente el mecanismo cotizado en la Etapa 2, y ahora además es política interna de Balam. El pipeline objetivo queda nítido: Jira (disparador) → cotización BIND → prefactura → validación humana → CFDI → envío por correo.

La eliminación de la lista blanca simplifica el MVP (el catálogo/lista configurable puede quedar como capacidad, hoy vacía). PERO ojo: lo que Ara y Arturo describen son recordatorios automáticos a clientes, que están diferidos al Anexo B (el MVP trae alertas internas). Su expectativa apunta a ese módulo — conviene aclararlo pronto o anticipar que lo pidan al cierre del MVP.

Jira como disparador del flujo (agentes observando tickets/botones) se parece al "Nivel 3" (generación desde eventos) que estaba en fase posterior. La integración con la API de Jira no está cotizada en el MVP — vigilar ese límite de alcance cuando se diseñe el prototipo.

Se levantaron reglas de validación de oro para la plataforma: PPD por default (PUE solo consciente — ya les costó un requerimiento del SAT) · IVA 16% MXN / 0% extranjero-sin efectos fiscales (BIND no lo automatiza) · prefactura SIEMPRE antes de timbrar · OC/cotización como prerequisito · alta de cliente como flujo aparte.

El token de BIND NO se tocó en la sesión — sigue abierto desde el kickoff y el WhatsApp del 2-jul (#25).

La cobranza quedó sin mapear — la sesión del martes 7-jul (que Erika mencionó desde el 1-jul) sería el espacio natural para cubrirla: cómo dan seguimiento hoy a los pagos, quién persigue morosos, cómo concilian cuentas por cobrar, y de dónde saldría el aging. Proponérselo a Erika.

Multi-empresa (Regiotour, Elmstone) aparece como deseo de futuro de Ara — anotarlo para el roadmap, no para el MVP.

28 · Jul 6, 2026 — 9:01 AM–12:40 PM · WhatsApp Erika ↔ Johann · token de BIND ENTREGADO ⭐

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md.

Tras la sesión de Discovery (7–8 am, #27), Erika revisa el plan de actividades línea por línea:

9:01 — Sobre "Entrega y validación de accesos (BIND, Azure, manual de marca) · lun 06 → mar 07 jul": "¿solo necesitas el token tal cual?" Johann (9:53–9:54): "Sí, para BIND solo necesito el token tal cual. Lo de Azure no me urge hoy y el manual de marca ya lo tengo."
10:26 — Erika: "okey deja lo solicito" → el token queda formalmente solicitado dentro de Balam.
10:28–10:37 — Sobre "Validación técnica de la API de BIND con la cuenta real · mar 07 → mié 08 jul": "¿se necesita una sesión?" Johann (10:37): "No, esa validación la hago yo por mi cuenta ya teniendo el token."
12:10–12:19 — Token GENERADO dentro de Balam: "ya solicitaran el token ahorita te lo comparto". Erika desconoce si tiene vencimiento (según el kickoff: no caduca), comenta que lo tienen en un .txt y pregunta si sirve por correo. Johann (12:25): sí, por correo y .txt está bien; (12:27) pide que le confirmen a qué usuario pertenece el token para documentarlo.
12:40 — Erika: "ya se compartió por correo" → ✅ TOKEN DE BIND ENTREGADO.

Lectura estratégica:

El bloqueador del token se resolvió el mismo día: Johann lo empujó a las 9:01 vía el plan de actividades, Erika lo solicitó a las 10:26 y estaba entregado a las 12:40 — un día antes de la fecha del plan (mar 7-jul). Cierra el seguimiento que venía desde el 2-jul (#25).

Que Erika trabaje sobre el plan de actividades confirma que el Excel de Johann es el instrumento real de seguimiento — mantenerlo al día paga.

Quedan dos higienes: (1) Balam debe confirmar de qué usuario salió el token (Johann lo pidió 12:27, Erika "okey" — el acuerdo del kickoff fue el de Arturo para dev); (2) tratarlo como llave de producción (sin sandbox): guardarlo en gestor de secretos, no dejarlo en el correo/.txt.

Desbloquea la validación técnica de la API (mar 7 – mié 8 del plan) — puede incluso adelantarse hoy.

29 · Jul 6, 2026 — 12:38 PM · Correo · Pedro → Johann (CC Noe, Erika) · entrega formal del token de BIND ✅

Adjunto: bind_token_api.txt. Evidencia: ../fuentes/2026-07-06 - Correo - Pedro entrega token BIND (usuario Arturo Rosas).md.

Pedro entrega el token de la API de BIND por correo (es el envío que Erika anunció por WhatsApp a las 12:40, #28) y confirma que fue generado con el usuario de Arturo Rosas — conforme al acuerdo del kickoff (llave de Arturo para desarrollo; la de Ara para Power BI). Se ofrece para validar dudas directamente. Erika agradece en el hilo (12:39). Johann acusa recibo (~3:28 pm): toma nota del usuario de Arturo para documentarlo, confirma que ya puede comenzar a trabajar con la API y que cualquier duda la validará con Pedro — deliberadamente sin comprometer entregas adicionales (los hallazgos se integran al documento de cierre de la Etapa 0 ya planeado).

Lectura estratégica:

Cierra las dos puntas del pendiente de accesos BIND: token entregado y usuario documentado. La entrega por correo (no WhatsApp) además deja la evidencia formal en el canal correcto.

Higiene inmediata: pasar el token del .txt a un gestor de secretos y no conservarlo en el buzón.

Dato colateral: la firma de Pedro lo identifica como ITSM Analyst / Consultor de Gestión de Servicios TI — coherente con que él montó el portal Jira ITSM del Discovery.

30 · Jul 6, 2026 — 3:01 PM · WhatsApp Johann → Erika · propone sesión de cobranza (martes 7-jul)

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md (bloque 7).

Johann plantea a Erika que la sesión de hoy solo alcanzó para facturación y envío, y que falta mapear cobranza (seguimiento de pagos y cuentas por cobrar). Propone el martes 7-jul, 7am — retomando la fecha que Erika misma había mencionado el 1-jul — o cuando se acomode en la semana. Erika queda en revisar la agenda con las personas involucradas y confirmar.

Lectura estratégica:

Completa el Discovery pendiente de #27 reutilizando la propia propuesta de Erika (bajo costo de coordinación). Interlocutor clave: Arturo (lleva CxC en BIND); Ara deseable por el contexto comercial.

Idealmente se confirma antes del viernes 10 (validación del prototipo), para que la pantalla de Cobranza llegue respaldada por el proceso real y no como hipótesis.

31 · Jul 6, 2026 — 4:33 PM · Correo · Noé → Johann, Pedro (CC Erika) · salvaguardas sobre el token ⚠️

Importancia alta. Evidencia: ../fuentes/2026-07-06 - Correo - Pedro entrega token BIND (usuario Arturo Rosas).md (respuesta de Noé en el hilo).

Noé responde al hilo de la entrega del token con dos instrucciones:

A Johann: mientras Pedro revisa si el acceso es de lectura o también de escritura, aplicar "las salvaguardas necesarias para evitar alguna afectación operativa".
A Pedro: si es necesario, crear un usuario específico de solo lectura en BIND para esta etapa de exploración — "la cuenta de Arturo tiene algunos privilegios elevados que creo que no serían necesarios en este momento".

Implicación: el token de Arturo podría ser reemplazado por uno de un usuario nuevo de solo lectura.

Lectura estratégica:

La preocupación de Noé es exactamente el diseño ya construido: el sandbox opera en modo solo-lectura por defecto con bloqueo de escrituras en código, dry-run, cuota vigilada y token fuera del repo (.gitignore ya cubre bind_token_api.txt y *.env). Responder describiendo esas salvaguardas convierte un correo de riesgo en una oportunidad de confianza con el CTO.

Ojo operativo: si Pedro crea un usuario nuevo, el token cambiará — no invertir esfuerzo en atar nada al token actual; el cliente ya está parametrizado por variable de entorno, el cambio es trivial.

Coherente con la estrategia "lectura primero" de la propuesta: nadie está pidiendo frenar la validación, solo asegurar el perímetro.

31a · Jul 6, 2026 — 4:46 PM · Correo · Johann → Noé, Pedro (CC Erika) · respuesta formal con las salvaguardas ✅

Evidencia: ../fuentes/2026-07-06 - Correo - Johann respuesta salvaguardas token.md. Recuperado del buzón el 20-ago-2026.

🔧 Corrección de registro. Este correo faltaba. #33 y PENDIENTES.md daban la respuesta formal a Noé por no enviada ("borrador listo… falta la respuesta formal por correo"), y así llevaba mes y medio. Se envió el mismo 6-jul, 13 minutos después del correo de Noé de las 4:33 pm (#31).

Johann contesta punto por punto las salvaguardas que ya estaban operando:

Solo lectura, bloqueado en código: "el cliente que uso bloquea desde el código cualquier operación de escritura, así que no hay forma de modificar datos".
Consumo acotado: pocas consultas, resultados pequeños, "muy por debajo del límite diario de BIND".
Token fuera del repo: "no queda en el repositorio ni en registros, lo guardo en un gestor de secretos".
Sin datos reales en documentación: solo estructura de la API (nombres de campos y tipos), "sin información real de clientes o facturas".
Escritura diferida y disposición inmediata a cambiar de token: "si Pedro lo crea, de mi lado cambiar el token es inmediato y no afecta el avance".

Lectura estratégica:

El pendiente 📧⚠️ más viejo del proyecto nunca existió: estaba cumplido desde el día uno. Lo que sí sigue abierto es la contraparte de Balam — que Pedro decida si crea el usuario de solo lectura (#37).

Confirma el patrón de canal: la instrucción de riesgo de Noé se respondió por correo (evidencia formal) y por WhatsApp vía Erika (#33).

32 · Jul 6, 2026 — tarde · Validación técnica de la API de BIND con la cuenta real ⭐ ✅

Actividad del plan "Validación técnica de la API de BIND" (mar 7 – mié 8) — ejecutada un día antes, el mismo día en que llegó el token. Evidencia completa: ../bind-api-sandbox/VALIDACION-API.md (117 peticiones, exclusivamente GET, solo estructura — cero datos reales persistidos).

Veredictos clave:

✅ Plan A del saldo CONFIRMADO — el riesgo central de la propuesta quedó resuelto a favor: cada fila de Invoices trae Total, Payments (acumulado) y CreditNotes; el saldo por factura es una resta local, verificada aritméticamente. No se activa el Plan C (+6–8 h) — la inversión apunta a la parte baja del rango.
✅ El flujo del MVP es 100% sostenible en lectura: cotizaciones legibles (con partidas y comercial), prefacturas distinguibles (UUID null / IsFiscalInvoice false), PPD/PUE y días de crédito auditables (en el detalle), IVA por partida (habilita la validación 16%/0%), PDF del CFDI descargable por API (insumo del módulo de envío), aging viable con ExpirationDate + saldo.
❌ No existe recurso de pagos individuales ni de complementos de pago (REP) — 20 nombres probados, todos 404. La cobranza operativa del MVP funciona igual (detecta pago por transición de estatus/residual), pero la fecha valor del pago y los REP del flujo PPD no son visibles. Escalar a Pedro.
⚠️ Sin vínculo cotización→factura en la API — la trazabilidad la llevará la plataforma (registrar el par al orquestar la conversión).
⚠️ Rarezas a cablear con cuidado: token inválido responde 500 (no 401); $select y conteos no funcionan (paginación manual con $top=100); nomenclatura CFDI invertida vs SAT (CFDIPaymentTerm = PPD/PUE); CFDIUse es código interno (falta tabla de mapeo); typo real del API (Loctaion); campos clave solo en el detalle → sync incremental obligatorio.
✅ Token acotado a una sola empresa (la de Arturo → Balam) — multi-empresa confirmado fuera del alcance por API.
Presupuesto de sync: ~1,000 req/día con polling cada 15 min ≈ 5% del límite de 20K. Holgado.

Preguntas que quedan para Pedro/doc (§10 del documento): endpoint de pagos/REP no descubierto · tabla CFDIUse interno→clave SAT · shape del endpoint /xml · códigos de Status >2 · webhooks/eventos.

Lectura estratégica:

El Discovery técnico ya pagó: el Plan A confirmado elimina la mayor incertidumbre de horas de la propuesta, y todo lo que el MVP necesita en lectura existe. La actividad del plan se cerró anticipada — buen dato para el corte de Erika del lunes.

El hueco de REP/pagos es real pero no bloquea el MVP (cobranza operativa funciona por transición de estatus); importa para el flujo PPD completo y para conciliación (Anexo B). Escalarlo con Pedro esta semana, idealmente junto con la tabla de CFDIUse.

Las salvaguardas prometidas a Noé (#31) se cumplieron al pie: GET-only por construcción, presupuesto de peticiones, reporte sanitizado, token fuera de git.

33 · Jul 6, 2026 — 4:34–5:03 PM · WhatsApp Erika → Johann · confirma operar solo-lectura (eco del correo de Noé)

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md (bloque 8).

Resumen: Erika transmite por WhatsApp, en versión breve, la instrucción de Noé sobre salvaguardas del token (#31): "referente a lo del token que se te compartió, para evitar complicaciones operativas." Johann confirma: "por el momento estaré haciendo operaciones solo de lectura." Erika agradece el entendimiento.

Acción derivada: confirmación informal, no sustituye la respuesta formal por correo a Noé. ✅ La respuesta formal SÍ se envió, el mismo 6-jul a las 4:46 pm — ver #31a. (Corrección del 20-ago: este registro y PENDIENTES la daban por pendiente con "borrador listo" desde hace mes y medio.)

Lectura estratégica:

Erika actúa como puente entre la instrucción formal de Noé (correo, 4:33 pm) y Johann — coherente con su rol de intermediaria única.

El contenido no agrega nada nuevo a lo ya resuelto por diseño (sandbox solo-lectura); es una confirmación de bajo costo que sostiene la confianza mientras se prepara la respuesta formal.

34 · Jul 6, 2026 — 6:36–6:40 PM · WhatsApp + convocatoria Outlook/Teams · confirma sesión de cobranza (martes 7-jul) ⭐

Evidencia: ../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md (bloque 9).

Resumen: Erika envía la convocatoria "Proceso actual de cobranza- Balam", martes 07/07/2026, 7:00–8:00 AM, por Microsoft Teams. Organiza Erika Chávez; invitados Johann, Araceli Sánchez Jiménez y Arturo Rosas Hernández (CC: Noé Rocha) — cierra la propuesta que Johann hizo el mismo día a las 3:01 pm (#30). Johann confirma recepción por WhatsApp (6:40 pm).

Acción derivada: asistir a la sesión el martes 7-jul, 7:00 am (agenda: cómo dan seguimiento hoy a pagos y cuentas por cobrar, quién persigue morosos, cómo concilian, de dónde saldría el aging — temas listados en la lectura estratégica de #27).

Lectura estratégica:

Cierra el hueco de Discovery que quedó abierto el 6-jul: facturación y envío ya están mapeados (#27); cobranza se mapea el 7-jul, antes del viernes 10 (fecha objetivo para la validación del prototipo) — como Johann buscaba al proponerlo.

Interlocutores correctos confirmados: Arturo (lleva CxC en BIND) y Araceli (contexto comercial), igual que en la sesión anterior — buena señal de continuidad.

Convocatoria aún sin respuestas registradas ("4 sin respuesta") al momento de reenviarla — no es un riesgo en sí, Balam ya confirmó la sesión por WhatsApp.

35 · Jul 7, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de cobranza (sin grabación) ⭐

Participan: Arturo Rosas (administración/CxC — mostró el proceso) y Johann; la convocatoria incluía también a Araceli y Erika (CC Noé). Canal: Microsoft Teams, 7:00–8:00 AM. ⚠️ Sin grabación — evidencia: ../fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md (notas de memoria de Johann, mismo día).

Resumen: Segunda sesión de Discovery — cierra el mapeo de cobranza que quedó pendiente el 6-jul (#27). Arturo mostró sus Exceles de control (facturas abiertas, canceladas, días de morosidad — el aging de facto) y el flujo real de un pago: el cliente avisa por correo/mensaje con su estado de cuenta → se comparte con el despacho contable, que registra los pagos en BIND uno por uno → un Power BI (conectado, según Arturo, con su token) muestra la cartera pero no está al día.

El detalle que complica conciliar:

Un mismo pago puede cubrir decenas de facturas ("10 pesos divididos en 40 facturas" — consistente con el cliente que exige factura por colaborador, ~40).
Los comprobantes llegan todos con el mismo patrón de referencia (tipo num_referencia.pdf) → la referencia no distingue facturas, se concilia por folio.
Al recibir el dinero hay un fee/comisión → los montos no cuadran exactos contra el total facturado.
Caso mostrado: Arturo pidió a Acuntia su relación de pagos; respondieron con un Excel pago ↔ folio — control de ambos lados, pero totales distintos por el fee.
Casos límite: clientes que pagan facturas viejas arrastradas (aplicación fuera de orden) y facturas pagadas cuyo registro va atrás de la realidad.

Lo que buscan: ser proactivos — recordatorios configurables (pasados 1–5 días de vencimiento, correo al cliente) o al menos visibilidad inmediata del atraso. Su evolución: eran reactivos ("ya hace rato que no me paga"), hoy son activos, quieren ser proactivos.

Pendientes que surgieron:

Johann — pedir a Arturo los Exceles: control de cobranza (abiertas/canceladas/morosidad), el Excel tipo Acuntia (pago↔folio) y un estado de cuenta ejemplo.
Johann — preguntar cómo registran en BIND la diferencia por fee (¿pago parcial con residual? ¿nota de crédito?).
Johann/Pedro — verificar qué token alimenta el Power BI (ver lectura estratégica).

Lectura estratégica:

El diseño de cobranza del MVP queda respaldado por el proceso real: el aging por factura con residual (Plan A: Total − Payments − CreditNotes, confirmado en #32) cubre exactamente los casos que Arturo describió — pagos fuera de orden y facturas arrastradas se leen por factura, no por cliente.

Regla de diseño nueva — tolerancia a fees: "pagada" no puede exigir residual = 0 exacto; hace falta un umbral configurable para no mostrar como morosas facturas saldadas con comisión. Aplica también a la conciliación futura (Anexo B).

El hueco de pagos/REP del API (#32) ahora tiene caso de negocio: el despacho registra pagos a mano, uno por uno — automatizar ese registro requeriría justo el endpoint que no apareció. Refuerza la escalación a Pedro.

⚠️ Discrepancia de tokens a verificar: Arturo mostró el Power BI conectado con su token, pero el kickoff (#22) acordó Ara = Power BI / Arturo = desarrollo. BIND emite 1 token por usuario: si Power BI y el desarrollo comparten el de Arturo, el reemplazo por un usuario solo-lectura que planteó Noé (#31) rompería uno de los dos. Verificar con Pedro antes de cualquier cambio.

Los recordatorios proactivos a clientes reaparecen (tercera vez: propuesta original, sesión del 6-jul, hoy) — siguen siendo módulo del Anexo B (el MVP trae alertas internas + visibilidad). La aclaración de expectativas ya no puede esperar mucho.

Actor nuevo en el mapa: el despacho contable — no había aparecido en el Discovery de facturación; es quien toca BIND para los pagos.

Los Exceles de Arturo son la especificación de facto de la pantalla de Cobranza (columnas, buckets de morosidad que ya usan) — pedirlos con las salvaguardas de siempre: datos reales fuera del repo y de los documentos, solo estructura.

36 · Jul 7, 2026 — 12:27 PM · WhatsApp Erika → Johann · seguimiento del pendiente de BIND (¿probar escritura?)

Evidencia: ../fuentes/2026-07-07 - WhatsApp - Erika seguimiento BIND.md.

Resumen: Erika revisa de nuevo el plan de actividades y pregunta por la línea "Validación técnica de la API de BIND con la cuenta real" (vigente hoy 7-jul y mañana 8-jul según el plan): "johan respecto a este punto, es para hoy y mañana, todo bien, necesitas algo?" — la misma actividad que Johann ya adelantó y cerró el 6-jul (#32).

⚠️ A las 9:28 am Erika había respondido "no" a un mensaje previo que no está incluido en la evidencia disponible — contexto pendiente de aclarar.

Acción derivada: Johann evalúa si hace falta sondear los endpoints de escritura (POST/PUT) de BIND, ya que la validación de lectura cerró en #32. Decisión: no probarlos en vivo contra producción todavía — sigue vigente la instrucción de Noé de mantener el modo solo-lectura mientras Pedro confirma el alcance real del token (#31), y no hay sandbox donde ensayar sin riesgo fiscal. Camino seguro en su lugar: revisar el catálogo de operaciones del portal de desarrolladores de BIND (ya referenciado por Noé el 25-may — incluye al menos Activities_AddActivity) para documentar qué escrituras existen, sin ejecutarlas. Respuesta a Erika: nada adicional urgente para las pruebas; lo único abierto es escalar con Pedro las preguntas técnicas ya listadas en PENDIENTES.md (endpoint de pagos/REP, tabla CFDIUse, shape de /xml, webhooks).

Lectura estratégica:

Buena disciplina: la tentación de "ya que tenemos el token, probemos escritura" se descarta porque contradice justo lo que Noé pidió resguardar — probarlo ahora sería el peor momento (token de Arturo con privilegios elevados, posible reemplazo en curso).

El BindClient ya está diseñado para este escenario: modo read-only bloquea cualquier método mutante en código (BindReadOnlyViolation), y addActivity() queda estructuralmente listo pero inerte hasta que se active dry-run/write con autorización — los candados de la propuesta (dry-run + confirmación humana) siguen intactos.

37 · Jul 7, 2026 — 3:56–5:49 PM · WhatsApp Erika ↔ Johann · seguimiento al usuario de lectura de BIND

Evidencia: ../fuentes/2026-07-07 - WhatsApp - Erika seguimiento BIND.md (bloque 3).

Erika confirma que, mientras se resuelve si Pedro crea el usuario de solo lectura que pidió Noé por correo (#31), ella sigue operando en BIND con el usuario de Arturo a modo de lectura, sin que esto la bloquee. Pregunta si ese usuario de lectura se lo iban a crear. Johann aclara que Noe le pidió a Pedro revisar si era necesario crearlo — la decisión no depende de Erika. Erika, reconociendo que no está familiarizada con el tema, queda en revisarlo con el equipo técnico.

Lectura estratégica:

Confirma que el reemplazo de token propuesto por Noé el 6-jul (#31) sigue sin resolverse una semana después — Pedro no ha confirmado si crea el usuario nuevo. No es bloqueante hoy (Erika opera con el de Arturo sin problema), pero sigue abierto el riesgo señalado en #35: si el Power BI de Arturo comparte el mismo token que el de desarrollo, reemplazarlo rompería uno de los dos usos.

38 · Jul 8, 2026 — 10:09 AM–10:55 AM · WhatsApp Erika ↔ Johann · datos ficticios para los Exceles de cobranza

Evidencia: ../fuentes/2026-07-08 - WhatsApp - Erika datos ficticios cobranza y avance fase 0.md (bloques 1–2).

Erika avisa que Balam está validando internamente si puede compartir la información de cobranza que Johann solicitó (#35, pendiente en PENDIENTES.md), por tratarse de información delicada. Johann ofrece una salida de bajo fricción: acepta que sean datos ficticios, ya que lo que necesita es la estructura que siguen, no los datos reales. Erika traslada la propuesta al equipo (10:50) y queda en avisar cuando tenga respuesta.

Lectura estratégica:

Resuelve por adelantado la fricción de confidencialidad de los Exceles de cobranza pedidos en #35: en vez de esperar una validación legal/interna que podría demorar, Johann baja el estándar a "estructura, no datos reales" — coherente con la salvaguarda ya prometida a Noé de mantener datos reales fuera del repo y de los documentos.

Sin fecha comprometida para la respuesta de Balam; sigue siendo no bloqueante para el avance del prototipo.

39 · Jul 9–10, 2026 · WhatsApp Erika ↔ Johann · avance de Fase 0 + prototipo sin sesión de validación agendada

Evidencia: ../fuentes/2026-07-08 - WhatsApp - Erika datos ficticios cobranza y avance fase 0.md (bloques 3–4).

9-jul, 7:20 PM: Erika pide a Johann un corte de avance de las actividades de Etapa 0 ("cómo vamos"). Johann responde hasta las 9:10 PM preguntando por qué medio compartirlo, sin resolverlo esa noche.

10-jul, 8:41–9:39 AM: Erika insiste ("nomás dime qué actividades y % de avance"). Johann reconoce que no confirmó la sesión de validación del prototipo que él mismo se había puesto como meta para el viernes 10-jul (ver PENDIENTES.md): el día anterior no dio seguimiento y no quedó agendada la reunión. Ofrece, en su lugar, compartir el prototipo por correo con sus propios comentarios. Erika acepta y da instrucciones de destinatarios, corrigiéndose dos veces en minutos: primero pide copiar a Pedro, al Ing. Noé y a Araceli (9:00); a los 21 minutos corrige — sin Araceli (9:21–9:22); y pocos minutos después acota aún más — solo a ella y al Ing. Noé, con Pedro en copia, "nosotros se los pasamos internamente" (9:28). Johann confirma y, al cierre, retoma la pregunta pendiente del 9-jul sobre si el % de avance de Fase 0 se reporta por el mismo canal de WhatsApp — sin respuesta aún al cierre de este tramo.

Lectura estratégica:

Dos pendientes de Johann quedan expuestos por la falta de seguimiento propio: (1) el reporte de avance/% de Fase 0 que Erika pidió desde el 9-jul, y (2) la sesión de validación del prototipo del viernes 10-jul (comprometida en PENDIENTES.md) que no se agendó a tiempo. Ambos se resuelven convergiendo en un solo entregable: correo con el prototipo (imágenes) + avance de Fase 0, en vez de una reunión.

Lista de destinatarios del correo del prototipo, final: Erika + Ing. Noé, CC Pedro únicamente — Araceli queda excluida (Balam decide compartirlo con ella internamente). Difiere del patrón habitual del hilo de correo principal, donde Araceli sí solía ir en copia — respetar esta instrucción explícita para este envío.

Sigue sin resolverse el % de avance de Fase 0 que se debe reportar — acción abierta de Johann.

40 · Jul 10, 2026 · Correo · Johann → Erika, Noé (CC Pedro) · entrega del prototipo Etapa 0 ⭐

Evidencia documental: ../prototipo/Correo-prototipo-Etapa0.md. Adjunto: ../prototipo/Prototipo-Balam-Etapa0.pdf.

Johann entrega por correo el prototipo navegable de facturación y cobranza, con PDF y acceso temporal a la versión web. El material usa datos ficticios y refleja el flujo levantado en Discovery: Jira → cotización BIND → prefactura → validación humana → CFDI → envío, además de cobranza por factura.

Balam responde que lo revisará internamente y compartirá comentarios. La retroalimentación queda pendiente; no se realizó la sesión en vivo prevista originalmente para ese día.

Acción derivada: mantener el entregable en validación y continuar únicamente con trabajo de Etapa 1 que no dependa de cambios visuales.

40a · Jul 10, 2026 · Correo · Reacción de Balam al prototipo: acuse de Erika y Noé fuera de oficina

Añadido el 20-ago-2026 desde el buzón. Complementa #40, que registraba el envío pero no la respuesta.

2:13 pm — Erika → Johann, Noé (CC Pedro): "Buenas tardes Johan. Confirmo de recibido. Saludos!" — acuse seco, sin comentarios de fondo.
12:14 pm — Noé: respuesta automática de ausencia.

Lectura estratégica:

Explica el silencio sobre el entregable. El prototipo se envió a Erika y Noé; Noé estaba fuera de oficina ese día, y la validación real no ocurrió hasta el 24-jul (#55) — dos semanas después. El entregable de la Etapa 0 estuvo dos semanas sin lectura del CTO, y el registro no lo hacía visible.

41 · Jul 13, 2026 · WhatsApp Erika ↔ Johann · continuidad de Etapa 1, sesión con Arturo y factura de 30 h

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Johann comunica que, mientras Balam revisa el prototipo, avanzará localmente con base de datos, autenticación/roles y cliente de consulta de BIND. Erika explica que la CEO se encuentra fuera del país y que la diferencia de horario dificulta la validación inmediata.

Johann pide coordinar una sesión con Arturo para cerrar alta de clientes nuevos, tratamiento del fee en BIND y Excel de particularidades de envío. Erika contactará a Arturo y confirma que el Excel continúa en preparación.

Sobre la propuesta v1.2 y la factura inicial de 30 h, Erika confirma que recibió el documento. La validación administrativa sigue pendiente porque la CEO y Noé están fuera del país por trabajo; Erika revisará cómo obtener el visto bueno.

Lectura estratégica: no hay rechazo comercial ni bloqueo técnico total. Johann mantiene momentum en local, pero la factura aún no debe emitirse sin confirmación y las definiciones de negocio se recorren.

42 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · dos sesiones confirmadas para 22–23 jul

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Erika confirma dos espacios distintos:

Miércoles 22-jul: sesión de dudas y definiciones de la Etapa 1 con Arturo y participación solicitada de la CEO.
Jueves 23-jul, 7:00 pm: sesión de validación del prototipo de la Etapa 0. Erika envía la convocatoria.

Temas para el 22-jul: alta de cliente nuevo, registro de diferencias por fee, particularidades de envío y definición de alcance de la posible automatización Jira → cotización BIND.

43 · Jul 14–15, 2026 · WhatsApp Erika ↔ Johann · ajuste de accesos y repositorio GitHub autorizado

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Johann aclara que para la Etapa 1 requiere un repositorio privado de GitHub de Balam y, posteriormente, acceso acotado a Azure. Se mantiene la reprogramación: repositorio primero; Azure durante la semana del 21-jul; CI/CD y secretos el 24-jul.

El 15-jul Erika confirma que Noé autorizó la creación del repositorio y solicita el usuario de GitHub. Johann comparte Johann-28 (https://github.com/Johann-28).

Estado: repositorio autorizado; falta recibir la invitación y verificar permisos de escritura. Azure aún no bloquea el desarrollo local.

44 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · Excel de días vencidos condicionado a validación

Evidencia: ../fuentes/2026-07-13 a 2026-07-15 - WhatsApp - Seguimiento prototipo sesiones accesos.md.

Erika pregunta si todavía se requiere el Excel de control de cobranza con días vencidos. Johann aclara que, si Balam considera que la estructura del prototipo refleja correctamente su operación, ya no será necesario prepararlo; si detectan ajustes, seguirá siendo útil como referencia y puede contener datos ficticios.

Impacto: deja de ser un pendiente obligatorio y permanece condicionado a la retroalimentación del prototipo. Esto no sustituye el Excel de particularidades de envío por cliente, que Balam continúa preparando.

45 · Jul 15, 2026 · Gestión interna · se inicia control local de horas

Mientras Pedro habilita el flujo de reporte en Jira, Johann crea un control local en ../planeacion/Seguimiento-horas.csv y su guía en ../planeacion/Seguimiento-horas.md.

Se cargan 3.08 h de sesiones con duración comprobable y se reconstruye retrospectivamente el resto del esfuerzo por actividad hasta un corte de 30 h: 22 h de Etapa 0 y 8 h de Etapa 1. Las 26.92 h reconstruidas quedan etiquetadas como estimadas y deben validarse contra memoria/evidencia y Jira antes de facturar; no se derivan del porcentaje de avance.

Acción: Johann debe validar el desglose reconstruido, capturar diariamente en adelante y conciliar con Jira cuando Balam otorgue acceso al flujo.

46 · Jul 16, 2026 · WhatsApp · Erika ↔ Johann · invitación Git, procedimientos y solicitud de avance

Evidencia: ../fuentes/2026-07-16 - WhatsApp - Erika invitacion Git procedimientos y avance Etapa1.md.

Erika informa que Pedro envió el 15-jul la invitación al repositorio privado y pide validar el acceso. Johann confirma por WhatsApp que ya puede entrar; queda pendiente comprobar que también tenga permisos de escritura. Erika envía por correo los procedimientos de carga de facturas por cliente y Johann confirma recepción.

Erika solicita un corte del avance de la Etapa 1. Johann se compromete a prepararlo y compartirlo por WhatsApp. Esa misma noche (8:40 pm) Johann envía por WhatsApp el Excel Plan-actividades-avance-2026-07-16.xlsx; Erika acusa recibo a las 8:44 pm ("Ntp, gracias").

Acciones derivadas:

~~Johann — validar permisos de escritura en el repositorio de Balam~~ → Comprobado (16-jul): push exitoso del scaffold inicial (backend .NET 10 + frontend Angular 21) al repo de Balam.
Johann — revisar el correo y los procedimientos de carga de facturas; documentar reglas o diferencias frente al Discovery.
~~Johann — enviar a Erika el corte de avance de Etapa 1~~ → Hecho (16-jul, 8:40 pm): Excel enviado por WhatsApp con acuse de Erika.

Estado técnico comprobado al preparar el corte: repositorio local limpio; solución .NET 10 y cliente BIND compilando; 13/13 pruebas del cliente BIND aprobadas; endpoints base /health y /api/bind/status. La base de datos, autenticación/roles, sincronización y endpoints de cartera siguen en construcción.

46a · Jul 16, 2026 — 1:01 PM · Correo · Erika → Johann · procedimientos de carga de facturas (5 portales) 📎

Adjunto recuperado y guardado el 20-ago-2026: ../fuentes/2026-07-16 - Correo - Procedimientos de cargas de facturas-clientes.zip (1.7 MB). Cierra el pendiente "conservar correo/adjuntos como evidencia" de #46.

Asunto: Procedimiento de cargas de facturas-Proyecto integración Balam

El ZIP trae 16 archivos en 5 carpetas, un procedimiento por portal de cliente, cada uno en .docx + .pptx (guía con capturas):

#	Cliente	Archivos
1	Cemex	docx + pptx (912 KB — el más extenso)
2	Acuntia	docx + pptx
3	ATC Consolidados	docx + pptx
4	DYLO	docx + pptx
5	Victec	docx + pptx

Lectura estratégica:

⭐ Dos clientes que el Discovery nunca mencionó: ATC Consolidados y Victec. Las particularidades de envío levantadas el 6-jul (#27) hablaban de Axie, CEMEX, Dilo y Acuntia. Aquí Axie no aparece, "Dilo" se escribe DYLO, y salen dos portales nuevos. El universo de destinos no está cerrado.

No son "correos con particularidades", son portales de carga. El Discovery los trató como variantes del envío por correo; el material muestra procedimientos de subida a portal del cliente, que es otro tipo de trabajo — y otro alcance si algún día se automatiza.

Sigue pendiente leerlos y contrastarlos contra el prototipo y el MVP.

47 · Jul 19, 2026 · Gestión interna · demo del 18-jul no realizada; entorno local montado en la Mac

La demo semanal planeada para el viernes 18-jul no ocurrió (confirmado por Johann el 19-jul). Causa señalada: la validación del prototipo de la Etapa 0 sigue pendiente (quedó para el jue 23-jul) y eso ha retrasado el avance de la etapa. Los días 17–18 jul no registran trabajo en ../planeacion/Seguimiento-horas.csv. La próxima demo queda apuntada al viernes 24-jul (cierre de Etapa 1), donde también conviene comunicar que la capa de escritura se entrega en dry-run (ver nota en ../planeacion/Agenda-semana-2026-07-20.md).

El mismo 19-jul se montó el entorno local en la Mac: repo del cliente clonado en balam-plataforma/ (convención de ../planeacion/Plan-Etapa1.md), SDK .NET 10 instalado en usuario, token cargado en user-secrets, API corriendo (/health y /api/bind/status verificados, modo ReadOnly, 13/13 pruebas verdes) y frontend Angular servido. Se creó la agenda por día de la semana 20–24 jul (../planeacion/Agenda-semana-2026-07-20.md) y se actualizó el CSV de horas con los cortes del 16 y 19 jul.

48 · Jul 19, 2026 — noche · Desarrollo · B0+B1 completados (adelantados del lunes) + Scalar UI

Trabajo adelantado la noche del domingo siguiendo ../planeacion/Plan-Etapa1.md al pie, con asistencia de IA (Claude Code). Tiempo real registrado en ../planeacion/Seguimiento-horas.csv (~1.25 h de sesión — el plan estimaba 4–5.5 h manuales; el registro es de horas efectivamente trabajadas, conforme al contrato).

B0 — Preparación local: docker-compose.yml con Postgres 17 en puerto 5438 (5433–5437 ocupados por otros proyectos locales — difiere del 5433 que asume el plan en la otra máquina); cadena de conexión en appsettings.Development.json; DesignTimeDbContextFactory; referencia Infrastructure → Integrations.Bind; dotnet-ef 10.0.10.

B1 — Fundación de datos: entidades Tenant, Client, Invoice (modelo central: Uuid null ⇒ prefactura, OpenBalance, CfdiPaymentTermRaw, PaidDetectedAtUtc), Quote, QuoteInvoiceLink (ADR-003, con JiraTicketKey ADR-006), InvoiceStatusChange (ADR-004, fecha de detección), WriteOperation (pipeline Draft→DryRun→Confirmed, ADR-001); TenantId en SyncCheckpoint/AuditLogEntry; BalamDbContext → IdentityDbContext con llaves Guid; convenciones fechas BIND sin zona vs *Utc timestamptz y decimal(18,2)/ExchangeRate(18,6); migración Inicial aplicada (16 tablas); DbSeeder idempotente verificado: tenant Balam (GUID fijo), 4 roles, 5 usuarios ficticios *@balam.dev (password en user-secrets Seed:DefaultPassword).

Extra: UI del OpenAPI con Scalar en /scalar/v1 (solo Development). Estado verificado: API arriba con BD, 13/13 pruebas verdes, seed comprobado por consulta directa a Postgres. Cambios sin commitear en el repo del cliente — commit pendiente de Johann.

Efecto en la agenda: el lunes 20 queda libre para gestión + arrancar B2 (auth JWT + roles + bitácora) directamente.

49 · Jul 19, 2026 — noche · Desarrollo · B2 completado (adelantado del lunes): auth JWT + policies + bitácora

Continuación de la sesión nocturna asistida por IA (~0.5 h reales registradas en el CSV). Con esto el trabajo técnico planeado para el lunes 20 queda hecho; el lunes queda solo la gestión + arrancar B3 (sync de clientes).

B2 conforme al plan: POST /api/auth/login (Identity + JWT propio, sin MapIdentityApi, sin refresh en E1) y GET /api/auth/me; Jwt:SigningKey en user-secrets con fail-fast; policies nombradas (PuedeVerCartera, PuedeDispararSync, PuedeVerBitacora, PuedeOperarEscritura) con matriz provisional hasta la sesión del 22-jul; roles como constantes (BalamRoles); bitácora en dos piezas — AuditMiddleware (mutantes + 401/403) e IAuditLogger explícito — y GET /api/audit (Direccion/Administracion). Decisión aplicada del plan: BD obligatoria con fail-fast.

Verificado end-to-end contra el API corriendo: login fallido 401 (auditado una sola vez), login Finanzas 200 con token, /me 200, /me sin token 401, /api/audit con Finanzas 403 (auditado), con Dirección 200 mostrando toda la secuencia. 13/13 pruebas verdes.

Repo del cliente: 3 commits locales (5631f55 Scalar, 6264ea3 B0+B1, 4617070 B2) — push pendiente por decisión de Johann (no se hace push sin su orden explícita).

50 · Jul 19, 2026 — noche · Desarrollo · B3 completado: sync de clientes CONTRA PRODUCCIÓN + hallazgo de datos

Cierre de la sesión nocturna (~0.5 h reales más). Primer dato real de BIND viviendo en la plataforma: 16 clientes sincronizados con detalle (días de crédito 0/30/45/60/90), checkpoint registrado y ciclo auditado en bitácora.

Hallazgo de producción: hay clientes con LocationID/LoctaionID null — caso que la validación del 6-jul no encontró. Se hicieron nullable todos los GUIDs de referencia de los modelos BIND (commit fb0f066); los IDs propios siguen no-nulos. Vale mencionarlo a Pedro junto con las 5 preguntas técnicas.

B3 conforme al plan: full-scan de lista + SourceHash, detalle solo nuevos/cambiados con tope por ciclo, normalización RFC/nombre, dedup por RFC exacto excluyendo genéricos — verificado en real: el único RFC repetido es XEXX010101000 (2 clientes extranjeros) y quedó correctamente FUERA del dedup. Idempotencia comprobada: segundo run = 16 sin cambio, 1 sola petición. Consumo total del día: ~42 peticiones de 20,000.

POST /api/sync/run (Finanzas/Administración; Operaciones→403 verificado) y GET /api/sync/status. 13/13 pruebas verdes. Repo: 5 commits locales, push pendiente por decisión de Johann.

Estado de bloques al cierre del domingo: B0 ✅ · B1 ✅ · B2 ✅ · B3 ✅ — el lunes queda gestión + B4 (sync de facturas/cotizaciones + cartera, el bloque más grande) con margen de un día completo vs. el plan.

51 · Jul 21, 2026 · WhatsApp Erika ↔ Johann · estimación Jira→BIND comunicada (10 h) y alcance confirmado por Erika ⭐

Erika pidió en la mañana la estimación del cambio nuevo "para tenerla a la mano" antes de su sesión con directores. Secuencia clave:

Johann comunicó: ~10 h de desarrollo, a confirmar el miércoles 22 en la sesión con Arturo (primero cerrar reglas del flujo y validar la escritura de BIND). Quedó por escrito que "no estaba contemplado al inicio; es una mejora que surgió en el Discovery".
Erika retó con la §1.4 de la propuesta ("¿no es esto lo de las cotizaciones?"). Aclaración que quedó asentada: crear cotizaciones manualmente desde la plataforma SÍ está en el MVP (capa de escritura); lo nuevo es que los tickets de Jira las generen automáticamente. Erika encontró ella misma la §1.3 donde Jira dice "Fuera de alcance" y lo confirmó con 👍. Erika lo valida internamente con los directores.
Erika preguntó por 2 actividades vencidas en fechas del Excel (backend base y multi-tenant); Johann respondió "esas ya quedaron". Backend base ✅ real (B2); multi-tenant al ~80% — hacer B6 (RLS real) de inmediato para que la afirmación quede cubierta.
Nuevo compromiso: compartir las horas semanalmente por Excel mientras Pedro habilita Jira, con entregable + actividad + horas de cada etapa (formato pedido por Erika, lunes de corte).

52 · Jul 21, 2026 — noche · Desarrollo · B4 completado: sync de facturas/cotizaciones + cartera por moneda + SYNC HISTÓRICO ⭐

Sesión nocturna asistida por IA (~1 h real registrada en el CSV). La plataforma ya tiene la cartera completa de producción viviendo en Postgres.

B4 conforme al plan: InvoiceStatusMapper como función pura en Domain con 13 pruebas xUnit (precedencia Cancelada→Pagada→Emitida→Vencida→Vigente; "hoy" en hora MX vía MexicoTime; la frontera Emitida/Vigente se ajusta en minutos si la sesión del 22 la cambia). InvoiceSyncService con ventana única (delta por Date + re-barrido de abiertas viejas, solape 1 día, cursor que solo avanza al completar la pasada) y QuoteSyncService con sonda del filtro CreationDate + fallback a full-scan. Detección de pagos ADR-004: transición → InvoiceStatusChanges con fecha de DETECCIÓN; facturas nuevas NO generan transición (el histórico fotografía, no detecta). Campo nuevo DetailSyncedAtUtc (migración DetalleSyncPendiente) para tope de detalle 50/ciclo + backfill B5. Endpoints: GET /api/cartera (por moneda, jamás suma monedas; primer uso de PuedeVerCartera), GET /api/invoices|clients|quotes. Normalización PPD/PUE desde la etiqueta larga de BIND.

Sync histórico corrido y verificado esta noche (jamás en demo): 1,494 facturas y 43 cotizaciones, detalle 1,494/1,494 (0 pendientes), idempotencia comprobada (2ª pasada = 100% sinCambio), InvoiceStatusChanges = 0 (cero pagos falsos), 24.5 min, ~1,700 peticiones (~8.5% de cuota; cierre del día ~1,750 de 20,000). Cartera verificada BD ↔ endpoint exacto: MXN 17 abiertas $1,568,772.32 · USD 92 abiertas $320,379.06.

Hallazgos de producción: (1) el filtro CreationDate de Quotes SÍ funciona (pendiente §10 de VALIDACION-API resuelto de facto); (2) ⚠️ las 1,374 facturas con método de pago traen PUE — ninguna PPD (120 con el campo vacío). Todo el histórico se factura "pago en una sola exhibición" aunque cobran a crédito 30–90 días — preguntar a Arturo en la sesión del 22 (toca la regla PPD-default de la capa de escritura y el riesgo SAT que ellos mismos reportaron).

Commit 2e1ae82. 26/26 pruebas verdes. 7 commits locales, push pendiente por decisión de Johann.

53 · Jul 21, 2026 — noche · Desarrollo · B6: RLS real de Postgres (contractual) — código completo; verificación local pendiente de rol de app

Cierre de la sesión (~0.5 h real). B6 conforme al plan: ITenantOwned en las 8 entidades de negocio; ICurrentTenantProvider + FixedTenantProvider (ADR-005: tenant único); TenantConnectionInterceptor (set_config('app.tenant_id',…) en cada conexión, vías sync y async); filtros globales EF por entidad como segunda capa; migración RlsPorTenant a mano con ENABLE/FORCE ROW LEVEL SECURITY + política tenant_isolation (USING + WITH CHECK, fail-closed sin GUC) en las 8 tablas. Migración aplicada (catálogo confirma relrowsecurity=t, relforcerowsecurity=t en las 8); app end-to-end igual que antes (login, cartera, sync). Commit fedb376.

⚠️ Verificación de aislamiento local INCOMPLETA: la prueba psql devolvió filas sin GUC y con tenant ajeno porque balam (usuario bootstrap del contenedor) es superuser con BYPASSRLS — FORCE somete al owner, pero ningún candado somete a un superuser. El fix (pendiente de decisión de Johann, quedó en PENDIENTES): crear rol local balam_app (LOGIN, NOSUPERUSER, NOBYPASSRLS), transferirle la propiedad y apuntar la cadena de conexión de desarrollo a ese rol — replica cómo será Azure, donde el usuario de la app tampoco es superuser. Las políticas en sí son correctas; el hueco es del entorno local, no del código.

54 · Jul 22, 2026 — 7:00 AM · Llamada · Sesión de reglas Etapa 1: alta de clientes, fee bancario y flujo Jira ⭐

Participan: Noe Rocha (sala de juntas), Arturo Rosas, Araceli (se suma ~min 21 para el tema del fee) y Johann. Erika no participó. Duración ~48 min. Transcripción: ../fuentes/2026-07-22 - Flujo para dar de alta clientes nuevos,_ Transcript.txt. Agenda preparada en ../planeacion/Sesion-Etapa1-2026-07-22.md.

Resumen: Se resolvieron 3 de los temas de la agenda: alta de cliente/proveedor en BIND (demostrada en pantalla por Arturo), tratamiento del fee bancario (lo registra el despacho, no Balam) y flujo Jira de facturación (estatus, validaciones y confirmación de que Jira ya es parte del proceso). Quedaron fuera: particularidades de envío, la pregunta PUE/PPD y el cierre técnico (repo/Azure/Jira horas).

1 · Alta de cliente/proveedor en BIND (ASIS, demostrado por Arturo):

Mismo procedimiento para clientes (módulo Ventas→Clientes) y proveedores (Compras→Proveedores). Botón Agregar → 2 pestañas: Detalle y Direcciones.
Detalle: razón social, RFC, nombre comercial y categoría se toman de la constancia de situación fiscal; banco y CLABE del estado de cuenta del cliente. Días y monto de crédito vienen de la negociación comercial (no de un documento). Además: correo de comunicación, sucursal (solo existe matriz), teléfono, uso CFDI (mayoría "gastos en general", según constancia), régimen fiscal e idioma de documentos (p. ej. BICTEX → inglés). Clientes agregan: ventas esperadas, lista de precios, descuento pactado.
Direcciones: país/estado/municipio/calle/CP, también de la constancia. Al guardar, BIND asigna un ID interno consecutivo (ej. 1016), exclusivo de la instancia de Balam.
En editar se pueden adjuntar archivos: constancia, carátula bancaria, NDA, contrato marco — todo en un solo lugar.
El alta nace del área comercial: cuando una propuesta pasa a firme, administración da de alta al cliente. Caso reciente: Frisa.
Extranjeros (ej. Acuntia): documento legal/fiscal del país en lugar de constancia; BIND propone un RFC genérico; uso CFDI = "sin efectos fiscales"; la factura al extranjero genera solo PDF, sin XML ni timbrado SAT (se registra como gasto/ingreso extranjero sin obligaciones fiscales).
No se hizo alta en vivo (producción, sin datos de prueba). Arturo se comprometió a grabar y documentar los procesos nuevos conforme ocurran (Frisa está por facturarse; hará manuales Word/PowerPoint).

2 · Fee/comisión bancaria (con Araceli):

El fee NO lo registra Balam: lo registra y deduce contablemente el despacho, para que la factura quede saldada al 100% sin residual de deuda del cliente. Balam solo concilia estado de cuenta ↔ facturas pagadas.
El fee solo aplica a pagos internacionales que mueven dinero hacia México (ej. Europa→Banorte; varía según banco emisor). Los pagos nacionales cuadran a centavos, sin fee. BigTech paga de banco americano a banco americano de Balam → sin fee.
El monto del fee no es predecible (no hay reglas conocidas), pero siempre viene marcado en el estado de cuenta ("comisión", "IVA sobre comisión"). Por eso es crítico pedir el estado de cuenta al cliente — además Accent/Axios tiene muchas facturas por el mismo monto y sin estado de cuenta no se sabe cuál pagaron.
Regla para la plataforma: el agente de conciliación solo debe identificar la diferencia como fee bancario; quién autoriza saldar la factura con diferencia es el despacho, a nivel contable. Hoy el caso vivo es Acuntia.

3 · Jira (flujo de facturación) — confirmado que SÍ entra en la fórmula:

Noe reconoció explícitamente que el alcance inicial decía "sin Jira" pero el proceso interno evolucionó y hoy todo pasa por Jira; la integración se pone sobre la mesa como ajuste.
Space "Facturación" separado (hay otros: administración general, GEDEX, RH), con un solo request type hoy (facturación adicional/recurrente) — el universo de tickets de facturación está cerrado y filtrable.
Flujo de estatus del ticket: inicia → abierto → proceso de facturación (confirmar monto, cliente dado de alta, constancia vigente, cuenta bancaria) → validación (nacional: adjuntar PDF + XML obligatorios; internacional: solo PDF) → facturado → resuelto. El estatus que confirma facturación válida es "resuelto" (el anterior solo es validación en curso). Las validaciones nacieron de desaciertos operativos reales ("ya facturé" sin evidencia).
Facturación recurrente: ~30 facturas/mes salen de un flujo recurrente por contratos establecidos — es proceso de Balam ejecutado en BIND, no capacidad nativa de BIND, y siempre con intervención humana (los montos pueden variar mes a mes). Pedirá sesión aparte con Pedro para entenderlo.
Forecast contractual a largo plazo: BIND solo proyecta sobre lo ya facturado (por plazo de pago); Noe quisiera a futuro proyección por contrato — explícitamente NO es para ahora.

4 · Escritura en BIND / prueba Jira→cotización: Johann planteó probar el flujo ticket Jira → cotización BIND (cotización→prefactura→factura). Noe accedió a explorarlo pero con advertencia fuerte: no hay ambiente de pruebas, es producción directa — "muy, muy medida la prueba… para no hacernos harakiri". La escritura será acordada y controlada llegado el momento.

Acuerdos / próximos pasos que anotó Noe:

Balam (Arturo/Pedro) — enviar a Johann el diagrama del flujo Jira en tamaño legible (el screenshot se veía ilegible en la llamada).
Balam (Erika coordina) — sesión con Pedro (+Arturo) para: API de Jira (explorar conexión), facturación recurrente y facturas automáticas vs manuales.
Confirmado: mañana jueves 23-jul, sesión de validación del prototipo.

Lectura estratégica:

Jira→BIND avanza: Noe aceptó en voz alta que Jira ya es parte del proceso y encaminó API + sesión con Pedro — coherente con la estimación de ~10 h comunicada a Erika el 21-jul (#51). El disparador de facturación es el estatus "resuelto"; para crear cotizaciones el candidato natural es un estatus previo (a confirmar con Pedro en la sesión de API).

El fee simplifica el MVP de conciliación: la plataforma NO registra ajustes contables — solo detecta y etiqueta la diferencia como fee bancario en pagos internacionales. El asiento es del despacho. Esto acota el alcance justo donde la agenda temía ambigüedad.

Alta de clientes: quedó mapeado el ASIS completo, pero no se decidió si la plataforma solo detecta clientes faltantes o también los crea — la pregunta del MVP sigue abierta y toca la estimación Jira→BIND (#51): un ticket de un cliente inexistente en BIND cruza ambas piezas.

No se tocaron: la pregunta PUE vs PPD (1,374 facturas históricas todas PUE, #52) — reintentarla el 23-jul o con Pedro—, las particularidades de envío (Excel sigue pendiente de Ara/Arturo) y el cierre técnico (Azure/Jira horas).

Factura extranjera sin XML confirma el diseño del prototipo (PDF-only para internacionales) y explica por qué la validación de Jira solo exige PDF en ese ramal.

55 · Jul 24, 2026 — 11:00 AM · Llamada · Validación del prototipo Etapa 0 — APROBADO (queda 1 definición de proceso) ⭐

Participan: Erika Chávez (abre), Johann (presenta), Noe Rocha, Araceli Sánchez, Arturo Rosas. Duración ~1 h 4 min. La sesión estaba agendada para el jueves 23-jul 7 am pero se corrió al viernes 24-jul 7 am porque Araceli (dueña del proceso) tuvo un tema personal (reagenda documentada en #57). Transcripción: ../fuentes/2026 - 07 - 24 - Validación de prototipo etapa 0- proyec_ Transcript.txt. Guion usado: ../planeacion/Guion-validacion-prototipo-2026-07-23.md.

Veredicto: Etapa 0 validada. Johann recorrió el PDF y luego el prototipo navegable (URL). Ara: "Johann nos captó absolutamente todo lo indispensable y más… de momento no le pondría nada", "Me encantó", "Sí a todo". Arturo: "yo no le pondría nada más… esto es lo mínimo que necesitamos". Ambos aprobaron el MVP tal cual. Queda pendiente UNA sola cosa del lado de Balam: redefinir el flujo de facturación en Jira (ver abajo) antes de volver con Johann para hacer el MVP productivo. Erika confirmó que esto no bloquea a Johann, que ya está en Etapa 1.

El único bloqueo real — definición de proceso (no de sistema): hoy el CIS de Jira exige que la factura se haga antes de cerrar el ticket, es decir el proceso de facturación ya no arrancaría desde el sistema. Hay que decidir si la ejecución (prefactura) se dispara desde la plataforma (lo deseable, para que el sistema optimice) o se sigue haciendo antes y solo se presenta al sistema. Arturo pidió explícitamente que sea PREFACTURA, no timbrado automático: validación previa (nacional vs extranjera, montos, datos fiscales) para evitar cancelaciones que el SAT observa; "para ir monitoreando la eficiencia de la IA. Tal vez en algún futuro daremos independencia completa". Ara sale de viaje mié/jue/vie; propuso el martes 28-jul para esa sesión; Erika coordina. Es prerrequisito para que Johann conecte el frontend a la escritura.

Decisiones y aclaraciones que quedaron asentadas:

Cotización SIEMPRE, sin excepciones (Ara). Incluso las recurrentes (contrato AXIANS 3–4 años) deben nacer de una cotización → prefactura/factura. Es un punto de control para cazar cambios (sueldos, viáticos, ajustes) y errores. "El esfuerzo es el mismo": la cotización vive en BIND y se convierte a prefactura/factura con un clic. Noe lo cerró como 3 candados: cotización → prefactura → aprobación humana → timbrado.
Nada de agente de IA en este MVP (Noe, muy vocal, lo repitió 3 veces): esto es reglas de negocio + procesos + integración de sistemas para homologar pantallas, no LLM. La IA llega después; el candidato claro para agente es conciliación (hoy 100% manual). Primero la base de proceso, "si le metemos IA de inicio va a ser una fiesta". Johann alineado: el MVP asienta el proceso para montar los modelos encima.
Roles: la plataforma ya los soporta; por ahora Ara y Arturo ven todo, se acotan cuando entre un analista.
Dashboard: las 4 tarjetas son propuesta, todo customizable. "Qué necesita atención" se alimentaría de Jira + estatus de facturación. Posible acople con el Power BI de aging de Pedro (no duplicar reporteo).
Fuente única = BIND (Vine) o Jira. No hay fuente alterna. Cartera vencida sale de BIND; lo que no esté en BIND requeriría carga/capa manual.
Un ticket = una factura (hoy). Caso ACUNTIA/Accions: un solo ticket con un Excel de 40–48 facturas. Queda abierto si se maneja como ticket-por-factura o un ticket con múltiples hijos (definición de proceso, va con el punto del bloqueo).
Todo nace en Jira — política de empresa: "Lo que no está en JIRA no se procesa." Ni correo ni mensaje; incluso los correos se reenvían a una dirección que auto-crea el ticket.
Envío con particularidades por cliente: validado y les gustó (CEMEX bloqueado por faltar Excel de horas; ACUNTIA = zip con PDF+XML+estado de cuenta). El módulo de configuración de reglas de envío queda cerrado/hardcodeado al inicio; si cambian reglas, se cobra como horas de servicio. No se desarrolla ahora.
NAFINSA / cadenas productivas (solo CEMEX): facturas ya programadas para pago (p. ej. cae 24-sep, 120 días) que no existen como estatus en BIND. Quieren una capa/pantalla extra "programado para pago" para planeación financiera (Arturo: "la cerecita del pastel"). Idea de Ara: ticket Jira automático cada 15 días para revisar el portal Nafinsa, adjuntar Excel/pantallazos y alimentar cuentas por cobrar, haciendo match por folio. A evaluar con Johann.
Fee: tolerancia configurable por cliente (% o fijo); se muestra como "pagada pero con tolerancia". (Consistente con #54: el asiento contable es del despacho, la plataforma solo detecta/etiqueta.)
Recordatorios internos en el MVP: D+1 → Arturo, D+15 → Araceli. Los correos al cliente (D+5, D+30) NO son alcance ("no está definida la regla"). Excepciones de seguimiento por cliente contempladas.
Bitácora/auditoría: "Me encanta, sí a todo."

Observaciones que anotó Noe sobre el prototipo: (a) un ticket rotulado "facturación nacional" era extranjera → pedía XML+PDF cuando extranjera es solo PDF (ajuste menor); (b) los estatus del prototipo son placeholders previos a explorar Jira ("listo para facturar" ≈ "facturado" en Jira real) y se adaptarán al flujo que Balam defina.

Cierre y próximos pasos:

Balam hace teamback para separar must vs nice-to-have y define el flujo de facturación/prefacturación (sesión martes 28-jul, Erika coordina).
Antes del go-live habrá una prueba muy observada de prefacturación (primera escritura real sobre BIND), paso a paso y validada.
Sesión con Pedro para el API de Jira queda encaminada (se materializó el 27-jul, #56).
Johann: montar el frontend, conectarlo al backend ya construido (cliente BIND, auth, multi-tenant, BD) y hacer las pruebas.

Lectura estratégica:

Etapa 0 cerrada en la práctica con validación entusiasta de los dueños del proceso (Ara y Arturo) y respaldo de Noe. El entregable de Etapa 0 quedó aprobado; el único hilo suelto es una definición de proceso de Balam, no una carencia del prototipo.

"Cotización siempre" es una decisión firme que simplifica la capa de escritura (B7): un solo camino cotización→prefactura→aprobación→timbre, sin ramas de excepción para recurrentes. Elimina ambigüedad que la agenda temía.

PUE/PPD no se retomó en esta sesión — sigue abierta desde #52 (1,374 facturas históricas todas PUE). Reintentarla con Arturo en la sesión del 28-jul o con el flujo Jira.

Dos capacidades nuevas asomaron fuera del MVP core: "programado para pago"/planeación financiera (Nafinsa) y el espacio "comercial" en Jira para generar cotizaciones. Ambas son candidatas a ampliación (horas extra), útiles para el pipeline comercial, pero no deben inflar el MVP — es justo lo que Noe pidió filtrar con el teamback.

La prueba observada de prefacturación es el hito de riesgo antes del go-live: es la primera escritura real sobre producción. Los candados acordados (dry-run, confirmación humana por factura, feature flag) son el seguro.

56 · Jul 27, 2026 — mañana · Llamada · Sesión API de Jira con Pedro: token comprometido y bandeja "Facturación" (FAC) identificada ⭐

Participan: Noe Rocha, Erika Chávez, Pedro Ayala (TI, dueño de Jira), Johann. Duración ~12 min. Transcripción: ../fuentes/2026-07-27 - API de conexión con JIRA Transcript.txt. Es el Discovery de API que quedó encaminado el 22-jul (#54) y ratificado el 24-jul (#55).

Objetivo (Noe): el Discovery mostró que buena parte del proceso de facturación llega por Jira, conectividad que originalmente no se contempló y que ahora sí será necesaria. Pedro explica cómo se conecta hoy vía API.

Lo que confirmó Pedro:

Usa el API de Jira para varios tableros de TI (limpieza de usuarios, aprobadores, conectores, SLAs). Funciones: crear y consultar actividades/tickets, aprobaciones, documentos adjuntos, cambio de estatus. Es de lectura Y escritura — todo accionable ("cualquier creación que se haría manual se puede hacer por API"). Cubre el CRUD que Johann necesita.
Token comprometido: Pedro genera una API key llamada "PAF" (Plataforma de Automatización Financiera), expiración a 1 año — 27-jul-2027. La envía por correo en TXT junto con la documentación de desarrolladores de Atlassian (informativa). Ya la tenía lista al cierre de la llamada.
Límites de consumo: a diferencia de BIND (20K/día), Pedro cree que Jira no tiene tope por día; lo investigará en Atlassian y lo revisa con Johann. Noe quiere saber el límite de transacciones por escritura/consulta para planear la operación.
Los tokens se generan desde la cuenta de Pedro, diferenciados por nombre; buena práctica rotarlos.

Identificación de dónde consultar (aclaración importante): no es "tablero" (eso es Power BI) sino el Space de Jira. Los tickets de facturación viven en la bandeja/space "Facturación", con llave FAC- + número. Otras bandejas: Administración General (AG), ITS (DITCM), Recursos Humanos (RH), Facturación (FAC), HD. El API es global (extrae de todas), pero la que importa es Facturación, que funciona como bandeja "padre": procesos que se cierran en RH o Administración General caen en Facturación. Este es el insumo que Johann pidió el 24-jul para saber de dónde extraer los tickets.

Próximos pasos acordados:

Pedro → enviar por correo: token TXT (PAF) + documentación Atlassian; investigar límites de consumo. → CUMPLIDO el mismo día (ver seguimiento).
Johann → revisar la documentación de Jira/Atlassian; con la key, integrar la consulta al prototipo. Construir un script de consulta y también scripts de creación/edición/eliminación sobre un registro de prueba. Noe: no existe un CRUD previo por API; cuando llegue el momento se hace una prueba en vivo de creación. Johann es el checkpoint — avisa cuando necesite prueba o tenga dudas.

Seguimiento — correo de Pedro del mismo día (27-jul, 7:40 am; CC Noe y Erika): ../fuentes/2026-07-27 - Correo - Pedro medicion de consumo API Jira y token.md. Johann acusó recibo ("Enterado, muchas gracias Pedro! Saludos").

No hay límite de volumen ("X llamadas al mes") ni costo extra de licencia por usar la API. Hay 3 límites de velocidad en paralelo, cualquiera devuelve HTTP 429 (RateLimit-Reason indica cuál):
1. Cuota por puntos/hora: 1 punto base + 1 por objeto de dominio (issues, proyectos) o 2 por objeto de identidad (usuarios, grupos, roles); las escrituras solo cobran el punto base. Bolsa por defecto 65,000 puntos/hora.
2. Burst por segundo: 100 req/s GET y POST, 50 PUT y DELETE, bucket por endpoint y por tenant. Consulta de clientes de service desk topada a 5/s.
3. Por issue en escrituras: 20 ops/2 s y 100/30 s sobre un mismo ticket.
No existe dashboard de consumo (limitante de Atlassian): consola de desarrolladores solo muestra el tier de apps propias; el detalle por token exige Atlassian Guard Premium (licencia aparte); las apps de Marketplace estiman por muestreo. Única fuente confiable = headers de respuesta: X-RateLimit-Limit/Remaining/NearLimit (NearLimit se activa con <20% de capacidad) y en 429 además X-RateLimit-Reset, Retry-After, RateLimit-Reason.
Token entregado vía enlace de Google Drive (carpeta compartida). ⚠️ Tratar como credencial: mover a user-secrets/Key Vault, no dejar en texto plano.

Lectura estratégica:

Desbloqueo clave para B7/Jira→BIND: con token de escritura a 1 año y la bandeja FAC identificada, se habilita tanto la lectura de tickets como la automatización Jira→cotización BIND estimada en ~10 h (#51). El API confirmado como read+write despeja el mayor riesgo de la integración.

"Facturación como bandeja padre" es un dato de arquitectura relevante: consultar solo FAC puede no bastar si el disparador nace en RH/AG y cae en FAC — validar en las pruebas si conviene escuchar la bandeja padre o rastrear los procesos origen.

Límite de consumo resuelto (correo 27-jul): no hay tope mensual; 3 límites de velocidad (puntos 65k/h, burst/s, por-issue en escrituras) sin dashboard nativo → el sync debe autorregularse leyendo los headers X-RateLimit-* (pausar en NearLimit, respetar Retry-After en 429). Las escrituras son baratas en puntos (solo el base), lo que favorece la capa de escritura frente a las consultas de identidad (2 puntos c/u).

Pendiente de proceso aún abierto: qué estatus de Jira dispara qué (facturación vs cotización) sigue amarrado a la definición del martes 28-jul (#55) — la conectividad ya está, la regla de negocio no.

57 · Jul 21–27, 2026 · WhatsApp Erika ↔ Johann · coordinación de sesiones, envío del flujo de facturación y reagenda 23→24 jul

Hilo de coordinación que complementa la parte de fondo del 21-jul (#51) y enlaza la sesión de reglas del 22-jul (#54), la validación del 24-jul (#55) y la sesión de API de Jira del 27-jul (#56). Transcripción completa (con imágenes inferidas): ../fuentes/2026-07-21 a 2026-07-27 - WhatsApp - Erika coordinacion sesiones validacion y API Jira.md.

21-jul (tarde): Johann propuso compartir las horas por Excel mientras se habilita Jira; Erika pidió el formato entregable + actividad + horas por etapa. Erika cuestionó si lo de las cotizaciones ya estaba (📷 captura) → Johann aclaró que crear cotizaciones sí está en el MVP y que lo nuevo (Jira genere la cotización en BIND automáticamente) requeriría acceso técnico a Jira + escritura controlada en BIND. Erika confirmó por su cuenta que Jira dice "fuera de alcance".

22-jul: Erika se disculpó por no asistir a la sesión de reglas de esa mañana ([#54]; avisó a los ingenieros para que la tomaran igual). Preguntó dos veces si se ajustará la propuesta por el cambio de la integración Jira → compromiso de Johann: enviar el conteo de horas + la propuesta ajustada "entre hoy y mañana" (para el 23-jul). Erika propuso la sesión de API de Jira con Noe y Pedro y confirmó que ya envió por correo el flujo de facturación de Jira (2:26 pm).

23-jul (reagenda): por un tema personal de Araceli (dueña del proceso), la validación del prototipo se movió de jueves 23-jul 7 am a viernes 24-jul 7 am. La sesión de API de Jira se movió de viernes 24-jul 7 am → 7 pm → finalmente lunes 27-jul 7 am por disponibilidad de Pedro. Erika preguntó si "esta actividad se acabó ayer" (📷 captura del plan) → Johann: sí, falta la prueba de escritura en BIND pero ya está.

24-jul: intercambio de arranque; se conectan a la sesión de validación ([#55]).

27-jul (mañana): Erika pidió los avances de la Etapa 1; Johann preguntó si ya existe el Jira del proyecto — justo antes de la sesión de API donde Pedro compromete el token PAF ([#56]).

Pendientes que deja el hilo:

Johann — enviar conteo de horas (Excel: entregable + actividad + horas por etapa) + propuesta ajustada por la integración Jira→BIND. ⚠️ Comprometido para el 23-jul — verificar si ya se envió.
Johann — entregar avances de Etapa 1 solicitados el 27-jul.
Conservar el correo del flujo de facturación de Jira (Erika, 22-jul) como evidencia/insumo.

Nota de imágenes: las capturas no vienen en el volcado; se infieren tres adjuntos por los deícticos ("esto", "esta actividad") — cotizaciones (21-jul 12:58), "fuera de alcance" (21-jul 1:03, confianza media) y actividad del plan (23-jul 11:29). Detalle en el archivo de fuentes.

57a · Jul 22, 2026 — 2:24 PM · Correo · Erika → Johann · flujo de facturación de Jira (diagrama) 📎

Adjunto recuperado y guardado el 20-ago-2026: ../fuentes/2026-07-22 - Correo - Flujo facturacion JIRA BALAM.png. Cierra el pendiente "conservar el correo del flujo de facturación de Jira como evidencia/insumo" de #57.

Asunto: Flujo de facturación JIRA — es el envío que Erika anunció por WhatsApp ese mismo día (#57, 2:26 pm: "ya envié por correo el flujo de facturación de Jira").

Diagrama del flujo tal como Balam lo tenía documentado antes de las definiciones del 30-jul–7-ago (#62). Acción: contrastarlo contra el disparador acordado (En proceso de facturación) y contra lo observado por API, para detectar dónde el diagrama oficial y la instancia real difieren.

58 · Jul 27–28, 2026 · WhatsApp Erika ↔ Johann · avance de Etapa 1 entregado, Excel de horas para FACTURACIÓN y Jira aún sin licencia ⭐

Continuación de #57. Registrado a partir de capturas de pantalla del hilo (4 imágenes). Cubre el envío del avance del 27-jul y los pedidos de Erika del 27 (tarde) y 28 (mañana).

27-jul, mañana — avance de Etapa 1 entregado por mensaje: Erika pidió los avances de Etapa 1 (📷 captura del plan, 7:11 am). Johann preguntó si ya existe un Jira para el seguimiento de este proyecto —es decir, dónde llevar sus actividades y horas, no la instancia a integrar— (7:14 am) → respuesta de Erika (7:54 am): "aún estamos viendo lo de alguna licencia... pero estamos viendo una segunda opción y no Jira precisamente". Johann ofreció trabajar en un Excel compartido; Erika contestó que le comentó a Pedro que pudiera ser un Drive para subir la documentación, pero están en espera de la validación (8:57 am).

⚠️ Precisión importante: este intercambio es sobre la herramienta de gestión del proyecto (dónde se registran actividades y horas de Johann), NO sobre la integración técnica. El Jira a integrar es la instancia productiva de TI que administra Pedro —bandeja FAC, token PAF a 1 año, API read+write confirmada (#56)— y ese no está en duda. Consecuencia práctica: mientras no haya herramienta de gestión, el Excel de horas de Johann ES el sistema de seguimiento del proyecto, lo que explica la insistencia de Erika en el desglose por etapa.

Johann envió el avance por actividad en texto (8:12 am), con 👍 de Erika y "gracias" (8:58 am):

✅ Sincronización de clientes — hecho y verificado · ✅ Sincronización de facturas/cotizaciones — hecho, 1,494 facturas cuadran · ✅ Modelo + migraciones + datos de prueba — hecho · ⏸️ Capa de escritura — en la junta del viernes comentaron que iban a definir el flujo de facturación; en cuanto quede, la implemento (Balam) · ⏳ Config. Azure (+ staging) — espera el acceso a Azure de Pedro/Noé (Balam) · ⏳ CI/CD + secretos — depende de Azure (Balam)

27-jul, tarde — la fila de escritura y la sesión del proceso: Erika preguntó (3:35 pm) si la capa de escritura "es la que está pendiente de lo que se mencionó el viernes de que validarían el flujo" → Johann confirmó. Erika: "es que lo tengo al 100%" (3:40 pm) → Johann corrigió: "lo volví a marcar como pendiente porque se iba a validar el proceso" y preguntó cuándo podrían tener la junta revisando el proceso validado (3:44–3:45 pm). Erika: le comentó a Arturo, y como Ara sale de viaje, mañana en la oficina ve cuándo revisarlo internamente y después pasarlo con Johann; queda en avisar (3:49 pm). ⚠️ La sesión del 28-jul no quedó confirmada — se movió a revisión interna de Balam primero.

27-jul, 4:59 pm — pedido formal de horas: "johan un favor, me puedes pasar en un excel tus horas que llevas de cada etapa por favor" → Johann envió Avance-Balam-2026-07-27.xlsx a las 6:45 pm (versión simplificada). Johann ofreció además pasar un Excel para las siguientes etapas; Erika (7:57 pm): "Y las ya completas más que nada para ver cuántas son".

28-jul, mañana — el propósito del Excel y dos pendientes:

(8:36 am) ⭐ "es para llevar el conteo de horas de cada etapa sobre todo para la FACTURACIÓN correspondiente de la misma." → El Excel de horas es el insumo de facturación, no solo seguimiento.
(9:12 am) "johann adicional, ¿pasaste la propuesta con lo adicional de JIRA que no estaba contemplado?" → Johann (10:58 am): "Aún no la comparto, te la paso a la brevedad." ⚠️ Es el compromiso que viene arrastrándose desde el 22-jul (#57).
(9:27 am) Sobre Azure: Johann preguntó si el acceso lo iba a entregar Noé o Pedro → Erika: "Sip" + "deja pregunto" (11:01 am). Erika pidió a Johann contexto de qué se requiere específicamente de Azure (11:19 am) — respondido esa tarde, ver #59. (Corregido con la captura del hilo: la pregunta la hizo Erika, no Johann.)

Lecturas clave:

El Excel de horas es documento de facturación (dicho por Erika, 28-jul 8:36 am). Cambia su naturaleza: ya no es reporte de avance, es sustento de cobro. Refuerza que las 41.58 h estén validadas y trazables.

Erika creía la capa de escritura al 100% y Johann la corrigió a pendiente. Buena decisión: si se hubiera dejado al 100%, la definición del proceso habría reabierto una actividad cerrada. Valida el criterio de reportar 40% y no más.

Sin herramienta de gestión para el proyecto (licencia en revisión; Erika evalúa una alternativa a Jira para ese fin). No afecta la integración técnica —esa va contra la instancia de TI de Pedro, ya disponible—, pero sí significa que el Excel de horas de Johann es el registro oficial de seguimiento y el insumo de facturación. Mantenerlo trazable y al día no es opcional.

La propuesta ajustada por Jira sigue sin enviarse (comprometida el 22-jul, re-preguntada el 28-jul). Es el pendiente comercial más viejo del hilo y ahora Erika lo pide por segunda vez.

La sesión del flujo de facturación no está agendada: Balam la revisa internamente primero (Ara de viaje). El desbloqueo de B7 se corre de fecha.

Pendientes que deja el hilo:

⚠️🔥 Johann — enviar la propuesta/adenda ajustada por la integración Jira→BIND (comprometida 22-jul, re-preguntada 28-jul 9:12 am). Estimación ya comunicada: ~10 h (#51).
Johann — enviar el Excel de horas de las etapas siguientes (2, 3) que Erika pidió el 27-jul 6:46 pm ("las ya completas más que nada para ver cuántas son").
Balam/Erika — avisar fecha de la sesión del flujo de facturación tras su revisión interna. Desbloquea B7.
Balam/Erika — definir la herramienta de gestión del proyecto (licencia en revisión). Mientras no exista, el Excel de Johann es el registro oficial.
Balam/Pedro/Noé — entregar el acceso a Azure; Erika iba a preguntar (28-jul 11:01 am). Johann pidió el contexto de lo que se requiere.

59 · Jul 28–29, 2026 · WhatsApp Erika ↔ Johann · requisitos Azure escalados a Noé, propuesta v1.3 + Excel de etapas entregados, seguimiento API Jira ⭐

Continuación de #58. Registrado a partir de capturas de pantalla del hilo (3 imágenes). Cierra los dos pendientes 🔥 de Johann que dejó #58.

28-jul, tarde — requisitos de Azure definidos y escalados: Erika había pedido contexto de qué se requiere específicamente de Azure (11:19 am, ver #58). Johann respondió (4:53 pm): "un grupo de recursos con permiso de Contributor para desplegar la aplicación, la base de datos y el Key Vault de secretos. No requiere Global Admin ni cuenta nueva. Con eso puedo montar el ambiente y el CI/CD." → Erika (5:23 pm): "okey de acuerdo, deja lo solicito con el inge porque desconozco si pedro puede apoyarme con ese permiso que se requiere de azure" — es decir, el acceso a Azure quedó escalado a Noé, no a Pedro.

28-jul, 5:38 pm — status check de Erika: "y ahorita estas detenido por algo o en que estas trabajando?" → Johann (5:41 pm): "Mientras tenemos la junta para ver el flujo de facturación, estoy trabajando en la integración con Jira, hoy en la noche podré compartirte el Excel de las actividades que llevamos más las de las siguientes etapas." Erika: "De acuerdo" (5:42 pm). Buen manejo: la espera de B7 no se lee como bloqueo total porque el tiempo se redirige a la integración Jira.

29-jul, 8:18–8:19 am — entrega doble (cierra los dos pendientes 🔥 de #58): Johann envió por WhatsApp Propuesta-Balam.pdf (v1.3, 21 págs) y Avance-Balam-2026-07-28.xlsx con el mensaje "Te comparto el excel y la propuesta con lo de Jira, cualquier cosa lo revisamos". Ambos archivos con 👍 de Erika; "Buen día johan / Lo reviso gracias" (9:35 am).

29-jul, 11:09 am — Erika pide formalizar por correo: "puedes compartirla en la cadena de correo donde adjuntaste la ultima version con los cambios que te dijo el inge noé pls para que la tengan todos" (adjuntó captura del correo de la v1.2) → Johann: "Sin problema" (11:18 am) → correo enviado a las 3:56 pm (ver #60).

29-jul, tarde — seguimiento a la API de Jira: Erika (1:27 pm): "Johan mande un correo para ver si nos puedes apoyar con tu retroalimentacion al respecto de la API de jira, si pudiste ingresar o se necesita algo adicional va" → Johann (4:59 pm): "Listo, también ya lo respondí, estaba haciendo unas pruebas extra para asegurarme de que no estuviese probando mal el token" (era la etapa del 401, ver ../planeacion/Investigacion-API-Jira.md). Erika: "Lo valido con Pedro para ajustar" (5:00 pm). Johann pidió saber el correo desde el cual se generó el apikey (5:00 pm) → Erika: "Sí claro" (5:18 pm). (Resuelto el 30-jul: Pedro confirmó pedro.ayala@balamtalentoestrategico.com, regeneró el token y el GET /myself respondió 200 — Bloque 0 de la investigación.)

Lecturas clave:

Los dos pendientes 🔥 de Johann quedaron cerrados el 29-jul por la mañana: propuesta ajustada por Jira (arrastrada desde el 22-jul) y Excel de horas de etapas siguientes. El hilo comercial más viejo se destrabó.

Azure ya no depende de Pedro: Erika lo escaló a Noé porque duda que Pedro pueda otorgar el permiso Contributor. Los requisitos exactos ya están comunicados y por escrito (grupo de recursos + Contributor + Key Vault, sin Global Admin).

Erika opera como PM activa: status check directo ("¿estás detenido?"), pide formalizar por correo lo que llega por WhatsApp, y da seguimiento al bloqueo del token Jira con Pedro. El patrón WhatsApp→correo confirma que el correo es el canal de evidencia para todo lo comercial.

59a · Jul 29, 2026 · Correo · Erika ↔ Johann · seguimiento a la API de Jira en el hilo de Pedro

Añadido el 20-ago-2026 desde el buzón. #59 registró este intercambio como WhatsApp; los correos existen y son el canal donde realmente se documentó.

1:25 pm — Erika → Johann (hilo "Seguimiento: medición de consumo API de Jira y accesos"): pide retroalimentación sobre el acceso a la API de Jira.
4:58 pm — Johann → Erika: responde en el hilo. Es el "Listo, también ya lo respondí" que Erika acusa por WhatsApp a las 4:59 pm (#59).

Lectura estratégica:

Refuerza el patrón ya asentado: WhatsApp coordina, el correo documenta. Al registrar solo el lado de WhatsApp, el registro perdía el rastro del canal formal — justo el que Balam pide usar.

60 · Jul 29–30, 2026 · Correo · Johann → Noé (CC Ara, Erika, Pedro) · propuesta v1.3 (Jira→BIND) enviada y APROBADA por el CTO ⭐

Cadena de correo sobre el mismo hilo donde se envió la v1.2 (2-jul). Registrado a partir de captura de Outlook.

29-jul, 3:56 pm — envío de la v1.3: Johann → Noé, CC Araceli, Erika y Pedro, con Propuesta-Balam.pdf (3 MB) adjunto. Puntos del cuerpo:

Incorpora al alcance la integración Jira → BIND: los tickets de la bandeja de Facturación generan automáticamente su cotización en BIND, con trazabilidad ticket → cotización → factura.
Ajuste: 7 a 10 h ($4,200 – $6,000 MXN + IVA), en línea con la estimación de ~10 h comunicada el 21-jul (#51).
Total primera etapa: 119 a 146 h ($71,400 – $87,600 MXN + IVA), 6 a 8 semanas a media dedicación.
El control fiscal no cambia: la integración crea cotizaciones, nunca facturas. Se conserva la cadena cotización → prefactura → aprobación humana → timbrado por el PAC de BIND. Tarifa, facturación semanal y garantía siguen igual.

30-jul, 4:51 pm — ✅ APROBACIÓN de Noé (CTO): "De acuerdo con la propuesta actualizada para seguir avanzando con la integración de JIRA."

Lecturas clave:

La integración Jira→BIND queda formalmente dentro del alcance, aprobada por el CTO y por correo — el canal de evidencia correcto. Las 7–10 h del ajuste son ahora horas contratadas.

Con esto, el alcance de la primera etapa queda cerrado en 119–146 h. La aprobación llega un día después del envío: sin fricción comercial.

La aprobación habilita continuar la parte técnica de la integración (../planeacion/Investigacion-API-Jira.md), aunque el código productivo sigue bloqueado por decisiones de negocio (estatus disparador, request type, fuente de monto/conceptos) y por la aprobación explícita de cada prueba de escritura.

Pendientes que dejan #59–#60:

~~Johann — enviar la propuesta/adenda ajustada por Jira→BIND~~ → Hecho (29-jul) y APROBADA por Noé (30-jul).
~~Johann — enviar el Excel de horas de las etapas siguientes~~ → Hecho (29-jul): Avance-Balam-2026-07-28.xlsx.
~~Johann/Pedro — destrabar el acceso a la API de Jira (401)~~ → Resuelto (30-jul): correo del apikey confirmado, token regenerado, GET /myself → 200.
Balam/Noé — otorgar el acceso a Azure (grupo de recursos con Contributor; escalado por Erika el 28-jul 5:23 pm). Bloquea ambiente, staging y CI/CD.
Balam/Erika — avisar fecha de la sesión del flujo de facturación tras su revisión interna. Desbloquea B7.
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.

61 · Ago 1, 2026 · Desarrollo · Recuperación del plan: E1 técnica cerrada (B5/B6/B8/B9), frontend de lectura de E2 completo y cliente Jira ⭐

Sesión de trabajo del sábado 1-ago para poner el proyecto donde el plan del 28-jul dice que debería estar, y adelantar todo lo que no depende de Balam. 9 commits nuevos en pedro-balam-itsm/BALAM (pusheados junto con los 7 que faltaban de B0–B6 — el repo del cliente ya refleja todo el trabajo).

Entorno (bloqueos propios resueltos): el backend no compilaba en esta máquina (faltaba apuntar al SDK .NET 10 de ~/.dotnet); Docker apagado. Resuelto y documentado en el CLAUDE.md del repo. bind_token_api.txt borrado del disco (el token vive solo en user-secrets).

Etapa 1 — deuda técnica cerrada (lo no bloqueado):

B9 · DevDataSeeder ✅ — datos demo 100% ficticios opt-in (Seed:DevData=true): 5 clientes (con caso de dedup), 11 facturas cubriendo los 5 estados × MXN/USD × PUE/PPD, 3 cotizaciones y 2 vínculos con ticket ficticio. Idempotente, fechas relativas a "hoy" MX. Cierra el entregable 8 y el pendiente "se reportó como hecho el 27-jul". Runbook en CLAUDE.md.
B6 · verificación RLS real ✅ — rol balam_app (NOSUPERUSER/NOBYPASSRLS) creado y con ownership de las tablas; la connection string de desarrollo ya lo usa. Verificado fail-closed por psql: sin GUC 0 filas, INSERT rechazado. Script de init para volúmenes nuevos en backend/db/init/.
B5 · scheduler ✅ — BackgroundService + PeriodicTimer cada 15 min (configurable; ≤0 lo apaga) con guardas de solape y de cuota (<10% restante salta el ciclo). Primer ciclo real contra BIND detectó el movimiento desde el 27-jul: 3 facturas nuevas, 46 pagos, 2 cotizaciones nuevas.
B8 · Balam.Api.Tests ✅ — 25 pruebas de integración con el API completo contra Postgres real (balam_test, recreada por corrida): matriz rol→policy (401/403/200), login sin filtración de correos, cartera multimoneda contra la fixture demo, paginación/filtros, PDF demo sin tocar BIND. Total de la solución: 61/61 pruebas verdes.

Etapa 2 — recuperadas las filas vencidas (29-31 jul) y adelantadas las de la semana próxima (solo lectura, nada bloqueado): andamiaje Angular (sesión JWT en señales, interceptor, guards por rol espejo de las policies, login) · shell con identidad de marca y estado del sync · cartera por moneda sin total combinado · listado de facturas con búsqueda/filtros/paginación/orden del lado del servidor (el API se extendió para ello) · detalle con desglose y descarga de PDF vía proxy (el token de BIND nunca llega al navegador) · catálogo de clientes con dedup visible y export CSV (facturas y clientes). Verificado end-to-end con login real por el proxy de desarrollo. Fuera de alcance por bloqueo: creación de cotizaciones y conversión (flujo sin validar por Balam), XML (shape sin confirmar con Pedro), tipo de cambio DOF (diferido: la captura al facturar depende de B7).

Integración Jira — todo lo posible sin Balam: proyecto Balam.Integrations.Jira espejo del cliente BIND (Basic auth email:token, search/jql con nextPageToken — el clásico da 410—, changelog, transiciones con expand=transitions.fields, servicedeskapi, rate limit leído de headers X-RateLimit-*), con los tres modos ReadOnly/DryRun/Write y read-only por default (FAC es producción); 10 pruebas con FakeHandler. Los modelos persisten el id numérico inmutable (la llave FAC-nnn cambia con un move — Bloque 5). Registro condicional en el API (+/api/jira/status). ⚠️ Las pruebas de lectura contra FAC real quedaron bloqueadas EN ESTA MÁQUINA: propuesta/token-jira.txt no existe aquí (quedó en la otra computadora, gitignoreado). Script listo para correrlas en un comando: planeacion/pruebas-jira-lectura.sh.

Pendientes que deja la sesión:

Johann — copiar propuesta/token-jira.txt a esta máquina y correr planeacion/pruebas-jira-lectura.sh (bloques 2/3/4/5 de la investigación, solo lectura).
Johann — crear el sandbox Jira Cloud Free propio (decidido 1-ago) para desarrollar transiciones/comentarios/creación sin tocar FAC.
Johann — capturar las horas del 28-jul→1-ago en el CSV (propuesta preparada, pendiente de validación) y regenerar el Excel de avance desde el script (la copia en disco está desincronizada — re-guardado manual del 28-jul).
Johann — demo del viernes 7-ago: ya hay material (frontend + seeder demo + scheduler).

62 · Jul 30 – Ago 10, 2026 · Correo · Balam define el flujo Jira→BIND: disparador, campos y prueba acompañada ⭐🔥

⚠️ Nota de merge (11-ago): esta entrada se escribió en la otra máquina como "#59" sin conocer las #59–#61 locales; se renumeró a #62 al integrar ambas líneas de trabajo.

Hilo RV: Seguimiento: medición de consumo API de Jira y accesos (fuente original conservada localmente; no versionada porque contiene cabeceras y adjuntos completos del correo). Continúa #56. Es la definición del flujo de facturación que estaba bloqueando B7 desde el 24-jul (#55, #58).

Cronología (8 días de latencia):

Fecha	Movimiento
30-jul 10:28–11:44 am	Pedro confirma su correo, regenera el token y comparte la URL `https://balam-jsm-temp.atlassian.net`. Cierra el 401 del 29-jul.
30-jul 1:07 pm	Johann pregunta las 4 definiciones (disparador, alcance de request types, fuente de monto/conceptos, y FACTEST vs prueba acompañada) + reporta el hallazgo de que el monto no está en campos estructurados.
3-ago 4:58 pm	Noé escala internamente a Araceli y Arturo (CC Pedro), reconociendo el cambio de propósito: "el flujo de JIRA tenía un propósito claro, validar la actividad y la evidencia, ahora cambiar a ejecutar y automatizar actividades con el desarrollo". Entra Araceli Sánchez al hilo.
3-ago 4:59 pm	Noé a Johann: "Estamos definiendo para darte respuesta mañana mismo".
4-ago 12:15 pm	Arturo responde en verde sobre los tres puntos + adjunta captura del formulario y del filtro de request types.
7-ago 11:34 am	Noé reenvía a Johann y contesta la cuarta: prueba acompañada. (Corregido el 20-ago: el registro decía 5:34 pm — se leyó como local la hora UTC 17:34.)

Las 4 definiciones, cerradas:

⭐ La cotización BIND se genera al entrar a En proceso de facturación. Y: "por el momento todo se tramitará como facturación normal, hasta el explorar el módulo de proyectos en BIND" → el caso de facturación recurrente queda fuera de alcance por ahora.
⭐ Se observan TODOS los request types de la bandeja de facturación, no solo Facturación adicional.
⭐ Monto y conceptos van como campos de Jira, no del adjunto. Noé: "resta rapidez, pero garantiza consistencia de datos". Arturo: "de acuerdo, deben ser los campos de JIRA (omitir el campo recurrencia)".
⭐ No habrá proyecto FACTEST: "Preferimos una prueba acompañada sobre un ticket" (Noé).

Verificación por API el 10-ago (solo lectura; detalle en ../planeacion/Investigacion-API-Jira.md):

✅ El acuerdo ya está implementado en Jira: Monto sin IVA existe como customfield_11556 (number/float, obligatorio) en el request type 83. Desapareció Periodo de Incidencias.
🔴 Pero solo 2 de 69 tickets lo tienen poblado — FAC-100 y FAC-101, ambos creados el 4-ago, el mismo día de la respuesta de Arturo. Sin histórico contra el cual validar el mapeo.
🔴 conceptos/partidas NO existe como campo en todo el sitio. El catálogo completo solo tiene Monto sin IVA (11556), Monto con IVA (11522, sin usar en el formulario) y Total forms (de JSM). El acuerdo resolvió el monto pero no los conceptos.
🔴 "Todos los request types" incluye tickets sin request type: el filtro de la bandeja muestra 6 opciones (las 4 del portal + Empty + Emailed request). 10 de 69 tickets no tienen request type ni un solo campo estructurado; nacen de Automation for Jira desde HH/SA/IN/RH, con los datos codificados en el summary. No son ruido: FAC-91 es uno de ellos y está vivo en En validación nacional ([FACTURA COMPLETA - Staff Augmentation] Axians — RH-36).
🔴 El estatus disparador dura minutos. FAC-100 estuvo 2m44s en En proceso de facturación (11:51:25 → 11:54:09 del 5-ago) y 25 min de punta a punta. Solo 1 de 69 tickets está parado ahí hoy. Un poller que consulte el estatus actual se pierde la mayoría de los disparos → la detección por changelog pasa de preferencia a requisito.
⭐ Hallazgo nuevo: el workflow tiene aprobaciones de JSM, con Araceli Sánchez como aprobadora en las ramas de validación nacional/extranjera (customfield_10003/10025). El paso a Facturado es una aprobación formal, no una transición simple. La plataforma no debe aprobar nunca.
✅ FAC-100 cierra con status = Facturado y resolution = Done consistentes (resuelve la trampa documentada el 30-jul).
✅ Headers de rate limit confirmados: X-RateLimit-Limit: 350, X-RateLimit-Remaining: 348, más los estándar RateLimit-Policy/RateLimit. El límite observado es 350, no los 100/s que mencionó Pedro → leer el header, no hardcodear.
✅ El origen es creación por Automation, no move entre proyectos: sin cambios de project/key en los changelogs, con issuelinks al ticket origen. Escuchar FAC basta.
⚠️ Facturación recurrente sigue siendo obligatorio y se está llenando (FAC-100: Si, periodo 12) pese al acuerdo de omitirlo.
⚠️ Nombre del Cliente es ADF, no string, y no trae RFC — la llave de match contra BIND queda en el nombre escrito a mano.
⚠️ ACUNTIA ya tiene caso real: FAC-100 es Julio/CONSULTORIA Y SERVICIOS (Eduardo Fiallo CEMEXUSA)/ACUNTIA, Helmstone, USD, 45 días, un solo Monto sin IVA de 7,594.00 — para el ticket que históricamente representa 40–48 facturas (#55 punto 6).

Lectura estratégica:

B7 queda desbloqueado en su mayor parte. El disparador está definido y el campo de monto ya existe: se puede implementar lectura, detección por changelog, parser de ADF y mapeo. Lo único que sigue bloqueado es el armado final de la cotización, por la definición de conceptos.

El acuerdo del 4-ago resolvió el monto y olvidó los conceptos. Es el hueco más caro del hilo: sin partidas, la cotización BIND sale de una sola línea. Puede ser aceptable, pero tiene que ser una decisión explícita de Balam, no un default silencioso.

"Todos los request types" no es implementable literalmente. ~14% de los tickets no tiene datos con los que armar nada. Hay que acotar el alcance por escrito o pedir que la regla de Automation propague los campos — y eso es trabajo de Balam.

Sin FACTEST, el sandbox propio deja de ser opcional. Se escribirá en producción una sola vez, acompañado; todo el desarrollo previo tiene que ocurrir en un sitio Jira Cloud gratuito propio.

8 días de latencia en la definición, con el agravante de que la pregunta se hizo el 30-jul y el escalamiento interno no arrancó hasta el 3-ago. Suma al patrón ya documentado: la definición del flujo lleva bloqueando desde el 24-jul.

Araceli entra al hilo como aprobadora, tanto en el correo como en el workflow de Jira. Es un interlocutor nuevo para las definiciones que faltan.

PUE/PPD gana evidencia: hay tickets Seguimiento del Ticket con pago anticipado:, lo que sugiere casos PUE reales y refuerza la pregunta que lleva cuatro sesiones sin hacerse (#52).

Respuesta de Johann — ENVIADA el 10-ago, tarde. Texto completo y borradores previos en ../planeacion/Correo-respuesta-Noe-2026-08-10.md:

Buenas tardes, espero se encuentren bien. Gracias por las definiciones, quedan claras y ya retomé el desarrollo, ya validé que el campo "Monto sin IVA" está creado y funcionando. Para aterrizar los detalles que faltan sería de ayuda que hoy o mañana se cree un ticket de ejemplo capturado "como debería ser", con todos los campos llenos tal como quieren que se capture de aquí en adelante. Contra ese molde llego a la sesión con el flujo ya funcionando. Para la sesión, ¿les funciona el miércoles 12 o el jueves 13, a las 7:00 am? El ejercicio termina en la cotización en BIND. Sigo pendiente del acceso a Azure para publicar el ambiente. Quedo atento. Saludos.

Decisión de enfoque: en lugar de resolver los tres huecos con otra ronda de correos, se pide un ticket de ejemplo capturado "como debería ser". Balam ya está adoptando el llenado completo de campos, así que el molde resuelve por evidencia lo que la prosa tardaría dos semanas en definir, y permite preparar el script contra datos reales para llegar a la sesión con el flujo funcionando.

La tarea se dejó deliberadamente sin asignar ("sería de ayuda que se cree"), para que Balam la ruteé internamente: Arturo no estaba en el CC del correo de Noé, y Noé ya venía haciendo ese papel de router desde el escalamiento del 3-ago. Nombrar a un ausente habría sido peor que dejarlo abierto.

Alcance del ejercicio fijado: termina en la COTIZACIÓN, no en la prefactura. Razones: 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 el 24-jul; y una cotización se cancela sin efecto fiscal, mientras que en BIND la prefactura es un registro en Invoices con UUID = null y los shapes de los POST nunca se han probado. Respeta los tres candados de Noé: cotización → prefactura → aprobación humana → timbrado (#55).

Lo que el correo final dejó fuera y ahora se resuelve verbalmente en la sesión (sin constancia escrita previa):

Que el ejercicio genera una cotización real en BIND producción y que se cancela al terminar. Anunciarlo al abrir la sesión, antes de ejecutar.
El compromiso de compartir el script antes (condición de Noé del 24-jul). Mandarlo por separado cuando esté listo.
Que el disparo es manual en esta prueba (pipeline Draft→DryRun→Confirmed de ADR-001 con flags apagados) y que la versión automática depende de Azure.
ACUNTIA y el supuesto de los tickets de Automation for Jira.

Pendientes que deja el hilo:

🔥 Johann — responder el correo → Enviado el 10-ago (texto arriba).
🔴 Balam/Arturo — definir de dónde salen los conceptos/partidas de la cotización.
🔴 Balam/Arturo — decidir qué pasa con los tickets creados por Automation (10 de 69, sin campos).
🔴 Balam/Arturo — confirmar si ACUNTIA es un ticket → una cotización o sigue siendo 40–48 facturas.
Balam/Noé — fecha para la prueba acompañada de escritura.
Balam — ¿nacional vs extranjero cambia la cotización o solo el paquete de salida?
Balam/Pedro — cuenta de servicio en vez de la cuenta personal de Pedro (planteado el 29-jul, sin respuesta).
Johann — levantar el sandbox Jira Cloud propio (plan Free) para desarrollar sin tocar producción.
Johann — mover el token de Jira a user-secrets/Key Vault y borrarlo de disco (ya está gitignoreado).

63 · Ago 11, 2026 · Correo · Noé confirma la sesión (mié 12-ago, 7:00 am) y rutea el ticket de ejemplo a ARACELI; Azure entra a la agenda 🔥

Respuesta de Noé (11-ago, 10:41 am) al correo del 10-ago (#62). Registrado desde captura de Outlook. Para: Johann y Araceli; CC Pedro. Arturo y Erika siguen fuera del hilo (la nota del borrador de agregarlos al CC no se aplicó en el envío).

Lo que confirma:

✅ Sesión: miércoles 12-ago, 7:00 am (tomó la primera de las dos fechas propuestas).
🔀 El ticket de ejemplo queda asignado a ARACELI ("@Araceli Sanchez Jimenez por favor puedes generar el ticket en JIRA") — no a Arturo, como preveía la apuesta de PENDIENTES. Consistente con [#62]: Araceli es la aprobadora del workflow; el molde lo captura quien aprueba.
☁️ Azure entra a la agenda de la sesión: "De los permisos de Azure mañana lo podemos explorar para validarte los accesos con una cuenta que estamos creando para este uso". Primer movimiento desde el escalamiento del 28-jul (#59) — y llega como cuenta nueva creada para este uso, no como permiso sobre una cuenta de Johann.

Verificación por API, noche del 11-ago (script de lectura, todo 200): el molde aún NO existe — el sitio sigue en 69 tickets, 0 actualizados en la ventana. Y FAC-98 ("Baja Jorge Herrera L2", nacido de Automation, sin un solo campo estructurado) lleva desde el 24-jul parado en En proceso de facturación — 17 días en el estatus "que dura minutos": los tickets de Automation también rompen la premisa de duración, y es el exhibit vivo del supuesto asentado el 10-ago.

Lecturas clave:

La latencia fue de un día, no de ocho. La táctica del molde + fechas cerradas funcionó: Noé contestó en <1 día hábil confirmando todo.

Riesgo operativo para las 7:00 am: el molde no existe la noche anterior. Plan B: que Araceli lo capture en vivo al abrir la sesión — convierte el riesgo en el mejor momento de la demo (captura → detección → wizard con sus datos, y siendo ella quien captura, el molde queda con la autoridad de la aprobadora). Plan C: correr sobre FAC-100 (único con Monto sin IVA poblado; de paso pone ACUNTIA en la mesa).

La sesión ganó una segunda agenda (Azure). Llevar a la mano los requisitos ya comunicados el 28-jul: grupo de recursos + Contributor (app + BD + Key Vault), sin Global Admin — para validar en vivo que la cuenta nueva alcanza.

Pendientes que deja el correo:

~~Balam/Noé — confirmar la sesión~~ → CONFIRMADA: mié 12-ago, 7:00 am.
🔥 Araceli — crear el ticket de ejemplo (pedido por Noé el 11-ago; no existe la noche del 11).
🔥 Johann — decidir y anunciar al abrir la sesión el destino de la cotización real (cancelar al terminar vs. cliente de prueba) y que la prefactura pertenece a la 2.ª sesión.
☁️ Johann — llevar los requisitos de Azure para validar la cuenta nueva en la sesión.

64 · Ago 11, 2026 — noche · Desarrollo · Capa de escritura mínima: ticket FAC → cotización BIND real, con dry-run y candados (lista para la sesión del 12) ⭐

Sesión nocturna previa a la prueba acompañada. Objetivo pedido: llegar con un ejemplo real de "leer de Jira y escribir en BIND", no con simulación. 2 commits en balam-plataforma (locales, sin push).

El hueco que había: el wizard de emisión (6-ago) simula la mitad cotización → prefactura y arranca desde una cotización BIND EXISTENTE; el ejercicio del 12 es la otra mitad, ticket → cotización nueva. Además el BindClient bloqueaba POST por diseño y el shape de creación nunca se había documentado (la doc "detallada tras login" seguía pendiente con Pedro).

El contrato se consiguió sin login: el data-plane del portal de developers (APIM) responde anónimo. Operación Quotes_NewQuote = POST /api/Quotes, body con ClientProspect{isNew, Client{ClientId, ClientName}}, Items[{Title, Unit, Price, Qty, VAT, IEPS, …}], CurrencyID/LocationID/VATRate/Comments; responde el GUID de la cotización creada. También existen Quotes_UpdateQuote y Quotes_DeleteQuote (la reversa por API existe, aunque la cancelación de la prueba se hará desde la pantalla de BIND). ⚠️ El SDK oficial de GitHub (2018) es ANTERIOR al recurso Quotes — no sirve de referencia. ⚠️ Semántica fina de partidas (Type, SelectedUnit, VAT ¿monto o tasa?) sin documentar: se valida contra la primera respuesta real, en la sesión.

Lo construido (73/73 pruebas verdes + smoke test de arranque):

BindClient.CreateQuoteAsync — hereda las guardas del núcleo: en ReadOnly lanza, en DryRun loguea sin enviar, solo Bind:Mode=Write envía. 3 pruebas nuevas con FakeHandler (una por modo, la de Write valida el body PascalCase con isNew en minúsculas, sic del portal).
POST /api/emision/cotizacion (modo DryRun/Confirmed) — valida contra el catálogo sincronizado (el cliente DEBE existir en BIND), persiste cada intento en WriteOperations (ADR-001), y en Confirmed: crea, verifica por lectura (folio/total), refleja la Quote en nuestra BD y guarda el vínculo ticket → cotización en QuoteInvoiceLink (migración: InvoiceId ahora opcional — el vínculo nace en la emisión y se completa al facturar, ADR-003). Policy PuedeOperarEscritura (Finanzas/Administración). El 409 cuando el modo no es Write es el candado visible.
Pantalla solicitudes/:id/cotizar ("Generar cotización en BIND", botón nuevo en el detalle) — prellena cliente/moneda/monto/concepto desde el ticket, exige confirmar el cliente a mano (Jira no trae RFC), y aplica ADR-001 en la UI: dry-run con el body exacto del wire antes de habilitar Emitir; cualquier edición lo invalida; Emitir pide confirmación explícita con cliente y total.
Doc para Balam: ../planeacion/Script-cotizacion-sesion-2026-08-12.md — el "script compartido antes" que pidió Noé el 24-jul (operación única, body de ejemplo, candados, reversa, qué NO hace). Enviarlo esta noche.

Guion de la sesión (7:00 am), afinado en la madrugada del 12 para la coreografía de pantalla compartida (ellos capturan → Johann recarga y se ve llegar → un clic → confirmación → cotización): (1) anunciar que el ejercicio crea UNA cotización real y su destino; (2) molde de Araceli — si no existe, que lo capture EN VIVO compartiendo su pantalla; (3) Johann comparte la suya: ⟳ Actualizar en la bandeja (nuevo: salta el caché de 60 s — sin esto el ticket recién capturado no aparecía) → el ticket se ve llegar; (4) abrir el ticket, repasar los campos que llenaron; (5) "Crear cotización en BIND →" (ahora CTA primario; también hay botón Cotizar por fila) → la vista previa del body se genera SOLA; (6) encender Bind:Mode=Write + reiniciar API → confirmar el diálogo → folio en pantalla → verlo en su BIND; (7) apagar el modo Write ahí mismo; (8) temas verbales (conceptos con el molde, ACUNTIA, Automation con FAC-98 de exhibit, PUE/PPD, cuenta de servicio, prefactura=2.ª sesión); (9) Azure con la cuenta nueva.

Lecturas clave:

El compromiso del correo ("llego a la sesión con el flujo ya funcionando") queda cumplible sin el molde: el flujo corre contra cualquier ticket de FAC; el molde solo mejora los datos.

La primera escritura real ocurre EN la sesión, nunca antes — es literalmente el formato de prueba acompañada que autorizó Noé. Si BIND rechaza el primer intento (semántica de partidas), el error se lee en pantalla y se ajusta en vivo: para eso es la sesión.

El default ReadOnly y la pantalla con candado convierten la salvaguarda de ADR-001 en algo que Balam puede VER — vale más que explicarla.

Pendientes que deja la sesión:

🔥 Johann — enviar el script a Noé/Pedro esta noche (doc listo en planeacion/).
🔥 Johann — en la sesión: encender Bind:Mode=Write solo para emitir y regresarlo a ReadOnly antes de cerrar.
Johann — capturar las horas de esta sesión nocturna en el corte siguiente.
Johann — si BIND ajusta el shape en vivo (Type/SelectedUnit/VAT), documentar la semántica confirmada en ../planeacion/Investigacion-API-Jira.md y en el CLAUDE.md del repo de la plataforma.

65 · Ago 12, 2026 — 7:00 AM · Llamada · Prueba de escritura Jira→BIND: Pedro releva a Erika, se decide que la plataforma genera la cotización y el primer POST falla con 500 ⭐🔥

Evidencia: ../fuentes/2026-08-12 - Transcript - Sesion prueba de escritura Jira-BIND.txt (52 min). Asistentes: Noé, Araceli, Pedro y Johann. (La diarización del transcript es poco fiable en varios tramos — atribuye a Noé frases que claramente son de Pedro; el contenido sí es legible.)

1 · ⭐ Cambio de PM — anuncio de Noé (2:26 y 4:12)

"Nada más creo que no te había avisado, no sé si te lo mandé por correo o no. Erika ya no va a ser la PM de este proyecto. El seguimiento del proyecto lo va a traer Pedro." — y lo repite al cerrar el bloque: "Bueno, este es un anuncio, Johann. El tema del seguimiento es con Pedro."

Explica el vuelco de interlocución que se ve desde el 18-ago (#67) y por qué Erika desaparece del hilo después del 29-jul. Nunca llegó por correo — el anuncio es exclusivamente verbal y vivía solo en esta grabación.

2 · La lógica comercial de la cotización, explicada por Araceli (9:38–13:22)

La explicación más completa que se ha obtenido de por qué existe la cotización:

Día 1 / venta nueva: comercial cotiza directamente en BIND para que el cliente acepte el monto. Requisito previo: el cliente ya debe estar dado de alta, o la cotización no sale con nombre ni RFC. Cerrada la venta, comercial solicita facturación adjuntando esa cotización; administración busca el número (p. ej. 01) y desde el menú de la cotización en BIND da prefactura o factura.
Recurrente: comercial no vuelve a cotizar; solo avisa a administración el periodo (3, 6, 12 meses) y administración genera prefacturas y facturas. "el área comercial no se entera cuando es recurrencia".
Por qué existe la prefactura: "antes nos íbamos directamente a facturación, pero luego había muchos errores y ya estaban timbradas… era todo un rollo la cancelación con el SAT" — hay clientes que deben aceptar la cancelación y "CEMEX se tarda años".

3 · ⭐ DECISIÓN: la cotización la genera la plataforma (13:23–14:15)

Noé pregunta a Araceli si le serviría que Jira generara la cotización y le ahorrara el primer paso → "Sí, sí me serviría". Noé: "vamos a hacer ese ejercicio, Johann… eso va a quitar tal H que hoy por hoy se está haciendo desde el área comercial."

✅ Cierra la contradicción 🔴 que llevaba abierta desde el 6-jul: Ara había dicho que el comercial genera la cotización y la plataforma la convierte; Arturo dijo lo contrario el 4-ago. Resolución: para venta nueva la genera la plataforma, y el paso comercial desaparece. La recurrente sigue fuera de alcance.

4 · ⚠️ El molde nunca existió — Pedro construye el formulario EN VIVO (14:43–29:52)

Araceli confirma que no hay tipo de ticket para cotización: "Jira no, fíjate que no lo tenemos, pero lo tendremos que definir". El molde que Noé le encargó el 11-ago nunca se creó. En su lugar, Pedro lo improvisa en la sesión: "lo que puedo hacer es construir un nuevo formulario muy rápido aquí en Jira con campos muy muy especiales para la cotización y hacemos esa prueba en vivo" — y se apoya en el Excel que Johann había mandado esa misma mañana (#66): "ya habíamos mapeado campos en un correo con Johann".

Campos acordados en vivo: Empresa origen · Summary (título del ticket) · Descripción (hoy texto libre; debe ser combo) · Nombre del cliente (debe ser combo, solo clientes dados de alta en BIND) · Tipo de moneda · Monto sin IVA · Fecha de vencimiento (= vigencia de la cotización). Además, quitarle el SLA a estos tickets para que no impacten métricas.

5 · ⭐ El catálogo de BIND está sucio — y de ahí salen las 17 categorías (22:54–27:22)

Araceli abre el combo de productos y servicios de BIND en pantalla y señala el desorden: "consultoría y horas de servicio, este es 040 y 029, esto es absolutamente lo mismo"; hay entradas con números de personas, "monitor Samsung", "servicios profesionales 16 horas", periodos metidos en el nombre. Su conclusión: debería haber solo opciones genéricas y editarse el detalle en la cotización.

Acuerdo (Noé, 27:04): "Actividad pendiente: depurar los campos que se van a usar en la cotización, para que sean los mismos que van a estar en el combo desplegable y coincidan con los campos que se van a estar planchando en [BIND]."

⭐ Éste es el origen de las "17 categorías" de Pedro (#67): de los 67 servicios que Johann catalogó en el Excel a 17 depuradas. Es la vía por la que se está resolviendo el hueco de conceptos/partidas — no agregando un campo de partidas a Jira, sino limpiando el catálogo y volviendo combo la descripción.

Dato fiscal capturado: horas de consultoría = unidad SAT E48.

6 · 🔴 La primera escritura real a BIND — ERROR 500, no se creó cotización (30:08–49:59)

✅ El ticket creado en vivo se reflejó en la plataforma de inmediato: "ya se vio reflejado el ticket que hicimos aquí de prueba".
⚠️ El cliente no se detectó: el mapeo venía del summary/description, no de campos estructurados. Johann lo resolvió en vivo con el endpoint de clientes de BIND y seleccionó CEMEX.
🔴 Al ejecutar el POST: error 500. Diagnóstico en vivo: faltaban campos que el portal envía en ceros, y sobre todo la lista de precios.
Araceli: "nosotros realmente no tenemos una lista de precios… ese lo podríamos agarrar del monto, del [Jira]. Ya ves que te pusieron monto sin IVA. Ese sería nuestra lista de precios." Noé imagina que BIND multiplica cantidad × precio del servicio, pero Araceli confirma que ellos capturan el número directo — Pedro: "como campo abierto".
Johann reintentó con un ítem existente; la sesión cerró sin cotización creada, con el compromiso de validar y avisar.

🚨 Corrige la lectura del #64. La capa llegó probada en dry-run con 73/73, pero el primer POST real contra BIND falló. La semántica de partidas (Type/SelectedUnit/lista de precios) no está resuelta, y es exactamente lo que hay que llevar cerrado a la sesión del 21-ago.

7 · Reglas de negocio que quedaron abiertas

Edición de cotizaciones (32:49–39:05): Araceli necesita modificar cotizaciones ("siempre hay ajustes"). Verificó en vivo que BIND conserva el mismo número al editar (cotización 10.19) y solo registra la modificación. La plataforma no tiene edición implementada. Noé plantea la disyuntiva —historial de cotizaciones (nuevo ticket o regenerar) vs. modificar la misma— y la deja como definición de Balam: "creo que como regla tenemos que definirlo nosotros, para no andar trayendo a Johann arriba y abajo". Araceli se inclina por conservar historial.
Cancelaciones (41:53–45:06): mientras no se timbre se puede cancelar libremente — "mientras no las [timbremos] en CFDI, podemos cancelar y hacer las prefacturas que queramos". Ya timbrada: acuerdo con el cliente por correo → cancelación en el ERP → el despacho la cancela ante el SAT → el cliente debe aceptarla en una liga del SAT. Decisión: el desarrollo NO ejecuta cancelaciones, pero sí debe llevar el récord ("esta factura se canceló y fue sustituida por esta").

8 · Otros acuerdos

☁️ Azure sigue del lado de Balam. Noé: "Pendientes de nuestro lado hacia ti es el tema del ambiente de Azure… para que puedas irlo generando" → "eso lo resuelvo con Pedro". No se exploró en la sesión, pese a que el 11-ago se anunció que se vería aquí (#63).
📼 Grabaciones de BIND: Pedro tiene videos de altas de proveedor/clientes y facturación y quedó de enviarlos al terminar. No consta que hayan llegado.
🗂️ Herramienta de seguimiento del proyecto sin resolver: 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 barajan SharePoint y Google Drive. Noé prefiere Jira pero falta el permiso de admin para crear spaces. Sigue vigente lo asentado en #58: el Excel de horas es, de facto, el sistema de seguimiento.
🔒 Candado reafirmado (Noé, 50:28): "esta es la primera prueba de escritura… habíamos acordado ser muy puntuales, de no hacer más pruebas de lo que definiéramos, para evitar errores o cosas en producción que puedan afectar". Johann ofrece avisar a Pedro cada vez que vaya a escribir una cotización o prefactura.
🔁 Pedro quiere jalar los catálogos de BIND por API para no capturar a mano (50:59). Johann ofrece dárselos en JSON o Excel — de hecho ya se los había mandado esa mañana (#66).

Lectura estratégica:

La sesión cambió la gobernanza del proyecto y no quedó registro escrito. Un cambio de PM anunciado solo de viva voz, en una grabación que estuvo ocho días fuera de la bitácora, es exactamente el riesgo que la regla de oro busca evitar.

El Excel del #66 llegó una hora antes y se volvió el insumo de la sesión. Sin él, Pedro no habría podido armar el formulario en vivo. La táctica de mandar "qué necesita el destino" se validó en tiempo real.

El molde de Araceli nunca existió y ya no hará falta: el camino real fue formulario nuevo + catálogo depurado, no un ticket de ejemplo. Los planes B y C del #63 quedaron sin usar.

🔴 El 500 es el pendiente técnico más caro que dejó la sesión y sigue abierto ocho días después. La sesión del 21-ago es la segunda oportunidad de emitir la primera cotización real; conviene llegar con el shape del POST ya resuelto contra el nuevo formulario.

66 · Ago 12, 2026 · Correo · Johann → Pedro (CC Ara, Noé) · campos y catálogos de la cotización BIND ⭐

Evidencia: ../fuentes/2026-08-12 - Correo - Campos cotizacion BIND.md. Adjunto: ../Cotizacion-BIND-campos-y-catalogos.xlsx.

8:09 am — Johann entrega la estructura completa de la cotización en BIND, en dos partes:

Campos del formulario: cada campo de la cotización, cuáles son obligatorios, y el origen de las opciones de cada combo.
Catálogos con datos reales de BIND hoy: 67 servicios, 3 productos, 17 clientes, monedas, sucursales y listas de precios.

10:30 am — Pedro acusa: "Confirmo de recibido. Estaré trabajando en conjunto con el equipo para regresar con comentarios."

Lectura estratégica:

⭐ Es la jugada que destraba el hueco de conceptos/partidas. Desde el #62 el único bloqueo real de B7 era que Jira no tiene campo de conceptos. En vez de pedirlo en prosa, Johann invierte la dirección: manda qué necesita BIND para recibir y deja que Balam ajuste el formulario de origen. Es la misma táctica del "molde" del 10-ago, pero al revés.

Funcionó. El 18-ago Pedro reporta que redujo el catálogo a 17 categorías y que el formulario se armó "con lo que marcaste en 'Sí' en el excel compartido" (#67). El Excel de Johann se volvió la especificación del formulario de Jira.

⚠️ Los comentarios formales nunca llegaron por correo. Pedro los prometió el 12-ago; se materializaron 6 días después y por WhatsApp. El canal de evidencia volvió a quedar vacío.

📌 El Excel sigue sin versionar en git (está en la raíz del repo, sin trackear).

67 · Ago 18–20, 2026 · WhatsApp Johann ↔ Pedro · Pedro toma el timón: 17 categorías, formulario modificado y sesión del viernes 21-ago ⭐🔥

Evidencia: ../fuentes/2026-08-18 a 2026-08-20 - WhatsApp - Pedro formulario 17 categorias y sesion 21-ago.md.

18-ago — comentarios al Excel, por fin:

⭐ Pedro: "logré reducirlo a 17 categorías pero tengo que verlas con Noé y Ara antes" (catálogo de servicios: de 67 → 17).
⭐ Pedro: "del formulario son lo que marcaste en 'Si' en el excel compartido" — el formulario de Jira se rehace contra los campos obligatorios de BIND.
Johann pide lo que necesita: un ticket de prueba con el nuevo formulario, para pasarlo a cotización.

19-ago — Balam mueve el formulario y convoca: Pedro anuncia "ya hemos realizado algunas modificaciones en nuestros formularios y campos" y pide sesión con Noé y Ara, el viernes a las 7. Johann ofrece preparar el caso de escritura para esa misma sesión; Pedro acepta ("si me parece bien el caso").

20-ago — el ticket llega el día antes, al filo:

9:48 am Johann pide el ticket para el ejercicio → 10:47 am "dame un momento".
3:43 pm ⚠️ "de momento no pude crear el ticket debido a que surgieron varios comentarios internos, dejame tocar base con Noé".
4:23 pm ✅ "ya me confirmaron Johan, mañana a las 7 am" + FAC-106.
4:24 pm ⚠️ "no te dejará entrar debido a la licencia", ofrece pantallazo de la estructura.

Lectura estratégica:

👤 ⭐ Cambió el interlocutor del proyecto. Desde el 18-ago todo se coordina con Pedro: comentarios, formulario, agenda, ticket y convocatoria. Erika (PM, contacto único durante toda la Etapa 0) no aparece en el hilo desde el 29-jul, y Noé pasó de definir a validar. Concuerda con lo que Johann recuerda de una junta donde se anunció a Pedro como nuevo responsable del proyecto — sin registrar (#65).

⭐ Balam cambió Jira para acomodar a BIND. Es la primera vez en el proyecto que el sistema origen se ajusta al destino en lugar de pedirle al desarrollo que absorba la diferencia. El Excel del #66 fue el instrumento.

⚠️ Las 17 categorías NO están validadas. Pedro lo dice explícito: "tengo que verlas con Noé y Ara antes". La sesión del viernes es donde eso se aprueba — y de ahí sale (o no) el mapeo de conceptos.

🔁 Se repite el patrón del 11-ago: el insumo de la sesión llega la víspera por la tarde y no se puede inspeccionar (entonces el molde no existía; hoy FAC-106 existe pero la licencia bloquea la UI). Mitigación disponible esta noche: leerlo por API — el token PAF corre sobre la cuenta de Pedro, que sí tiene licencia, y es como se sondeó el sitio el 6-ago y el 11-ago. No hace falta el pantallazo para conocer la estructura.

El alcance sigue siendo la cotización, no la prefactura (#62); y la escritura real sigue gateada a Bind:Mode=Write, que se enciende solo durante la sesión (#64).

68 · Ago 20, 2026 — 4:25 PM · Correo · Pedro → Noé, Johann · "Seguimiento - PAF" (convocatoria + FAC-106)

Evidencia: ../fuentes/2026-08-20 - Correo - Pedro Seguimiento PAF.md. PAF = Plataforma de Automatización Financiera, el nombre con el que Pedro bautizó el token del proyecto el 27-jul (#56).

Correo escueto: la liga de FAC-106 y la reunión de Microsoft Teams (Id. 280 788 665 449 275). Es el formalizado por correo de lo acordado por WhatsApp minutos antes (#67).

⚠️ El correo no dice fecha ni hora. La convocatoria real —viernes 21-ago, 7:00 am— consta solo en WhatsApp. Si alguien reconstruye el proyecto desde el correo, la sesión aparece sin fecha.

Lectura estratégica:

Noé va en el "Para", no en copia: la sesión tiene al CTO como asistente, no como observador. Coincide con que se validan las 17 categorías, que Pedro no puede aprobar solo.

Es el primer correo del proyecto que no cuelga de un hilo previo — asunto nuevo, con el nombre del proyecto. Encaja con el relevo de interlocución del #67.

69 · Ago 21, 2026 — 7:00 AM · Llamada + trabajo posterior · PRIMERA COTIZACIÓN REAL EN BIND desde un ticket (folio 1026) — tras 5 intentos y dos semánticas indocumentadas ⭐🔥

Asistentes: Noé, Araceli, Pedro, Johann. Preparación: ../planeacion/Guion-sesion-2026-08-21.md y ../planeacion/Sondeo-FAC-106-y-payload-2026-08-20.md. ⚠️ Minuta de la parte de definiciones (17 categorías, Empresa origen, IVA 0%, Azure) pendiente de capturar por Johann — esta entrada cubre la parte técnica, que quedó auditada en WriteOperations.

En la sesión (7:04–7:11 am) — tres intentos, cero cotizaciones creadas:

#	Op	Body	Respuesta de BIND
1	23	sin `ID`/`Type` de partida, sin `PriceListID`	500 explícito: "Required property 'ID'… 'Type' not found… El ID de la lista de precio es requerido" → se corrigió en vivo (lista "A" dada por Araceli)
2	28	+ `ID` servicio 027, `Type: 1`, `PriceListID` A, `Unit: "Servicio"`, sin `ExchangeRate`	500 genérico `174068216` ("comunicarte con soporte técnico")
3	34	ídem con el servicio `ChargeVAT:true`	500 genérico `174068255`

Se aplicó el protocolo del guion §6: parar, anunciar el diagnóstico, pivotear a las definiciones. Verificado por lectura después de cada intento: 52 cotizaciones en BIND, ninguna nueva. Al salir de la sesión, Balam autorizó seguir sobre FAC-106 por ser ticket de prueba.

Investigación posterior (solo lectura):

Schema tipado del portal (APIM, anónimo): Items son NewFullProducts, requeridos solo ID y Type, sin enums ni descripciones. Permiso descartado: el token trae 5|11|AgregarCotizacion. GET /api/Series?docType=n devuelve [] para todo n (sin series → DocNumberID no aplica). El read model de Quotes reporta PriceListID = su propio ID (bug de BIND); la lista real de CEMEX es "A" 03e4bb2d (Clients.PriceListID).
Intento 4 (op 44): + ExchangeRate 1.0, Unit E48 + SelectedUnit, Type: 1 → 500 genérico 174068365.
⭐ Intento 5 (op 45): Type: 2 → HTTP 200, folio 1026. Type es el catálogo donde BIND busca el ID: 2 = servicio, 1 = producto. Indocumentado; solo descubrible por ensayo.

Pero el folio 1026 salió mal: VAT = 243,640.96 sobre base 1,234 = 1,234 × 197.44. ⭐ En el write model Items[].VAT es TASA (0.16), no monto — BIND lo multiplica por precio × cantidad. El read model sí devuelve montos, lo que indujo el error. Corregido en UI y con guard de 400 (misma regla que VATRate). El folio 1026 debe cancelarse (IVA absurdo) y la segunda emisión, ya con VAT: 0.16, debe dar 1,234 + 197.44 = 1,431.44 MXN — folio y confirmación pendientes de Johann.

Lectura estratégica:

Se cumplió lo que la prueba acompañada existe para hacer: dos semánticas que ningún documento de BIND contiene (Type y la escala de VAT) quedaron resueltas contra producción y escritas en el modelo. El costo fue un folio de prueba que se cancela sin efecto.

El primer error de BIND fue útil y los tres siguientes no: cuando falla la validación del JSON, BIND dice qué falta; cuando falla por dentro, solo da un código. El diagnóstico salió de comparar con cotizaciones reales y del schema del portal, no del mensaje.

La plataforma se portó como se diseñó: cada intento auditado en WriteOperations con body y respuesta, verificación por lectura entre intentos, y el candado de Bind:Mode encendido solo para emitir. Es el argumento de confianza ante Noé, y va en el correo.

⚠️ Deuda que deja: el GUID del servicio (027) y la lista de precios ("A") van fijos en la UI. Lo correcto es resolver el servicio desde el combo Servicio/Producto (17 categorías → GUID de BIND, que además hoy tiene 5 "Servicio de Enlace" distintos) y la lista desde Clients.PriceListID.

Borrador del correo a Balam: ../planeacion/Correo-error-resuelto-2026-08-21.md.

70 · Ago 26, 2026 · Incidente + investigación de cierre · IsFiscalInvoice=true TIMBRA al crear (folio 2386) — y el API de BIND ni crea ni VE prefacturas 🔥⚠️

Contexto: entre el 23 y el 25-ago se construyó el camino cotización→prefactura (POST /api/emision/prefactura, mismo protocolo ADR-001). Los intentos con IsFiscalInvoice=false produjeron los folios 1000 y 1001 como remisiones (confirmado por Noé por correo), así que se cambió a true bajo la hipótesis "true = factura sin timbrar = la prefactura del flujo" — el API no tiene operación de timbrado (130 operaciones revisadas), y de ahí se infirió que crear no podía timbrar.

El incidente: el 26-ago, al confirmar desde el wizard (op #73, cotización 1028 / ticket FAC-108), BIND creó la venta 2386 como Factura Electrónica (CFDI) y la timbró en el acto — UUID aa70001d-…, $1,160 MXN, receptor ACUNTIA. El timbrado vive DENTRO de la creación, no en una operación aparte; la ausencia de operación de timbrado significaba lo contrario de lo inferido. El tripwire de la plataforma (verificación por lectura post-creación, "⚠️ TIMBRADA" si UUID ≠ null) lo detectó al instante. Contención el mismo día: confirmación de prefactura bloqueada con 409 en el endpoint (commit c5143cf, pusheado), API reiniciado en ReadOnly, instrucciones de cancelación SAT (motivo 02) comunicadas.

Investigación de cierre (misma fecha, SOLO GETs contra producción):

El body de Invoices_AddInvoice no tiene campo de tipo de documento. Verificado contra dos fuentes primarias: el portal APIM (27 campos) y el swagger oficial del SDK de Python de BIND — coinciden campo por campo. El UseStock que sugieren los resúmenes de IA de Google no existe (respuesta fabricada; también da UseCFDI:"G03" como string cuando CFDIUse es un int interno).
false = remisión, comprobado con la verdad impresa: los PDFs por API (GET /api/Invoices/{id}/pdf) de 1000, 1001 y 2384 titulan "Remision"; el de 2386 titula "Factura Electrónica (CFDI)".
No existe el estado intermedio: 0 filas con IsFiscalInvoice=true and UUID=null en TODA la cuenta. BIND timbra al crear, siempre.
Censo completo de no fiscales: 58 documentos, todos remisiones. Únicos activos: nuestros 1000 y 1001; los otros 56, cancelados. Ni una prefactura visible en /api/Invoices — la afirmación de VALIDACION-API.md (6-jul) "false = prefactura" era una inferencia errada sobre filas que en realidad son remisiones.
Orders tampoco: 1 pedido (2024, cancelado). El detalle de venta no expone claves ocultas que discriminen tipo.
⚠️ Efecto colateral del API detectado: la lista reporta Status=2 en filas cuyo detalle dice Activa (1000/1001), y Number no es único entre series — la búsqueda por número es ambigua. Confiar solo en detalle por GUID.

Conclusión (revisada el mismo día — ver adenda): la "Prefactura" del combo de la UI de BIND no es expresable por su API pública con lo documentado. Queda una incógnita: dónde queda almacenada una prefactura creada por la UI (en esta cuenta nunca ha existido una, así que no hay espécimen que leer).

ADENDA (26-ago, tarde) — apareció el espécimen y reescribe medio registro. El folio 2384 (VictTec, $1,650 USD, 19-ago, creado por Araceli) SÍ es una Prefactura — confirmado por Johann en la UI. Con eso:

Las prefacturas SÍ son visibles por API (VALIDACION-API.md tenía razón a medias): son filas IsFiscalInvoice=false+UUID=null. Lo errado era leer Status=2 como "cancelada": en el precursor significa consumida/facturada — la 2384 parió a la 2385 (misma fecha, mismo total, timbrada) y quedó en 2. Las 56 "canceladas" del censo son los precursores históricos del flujo real de Balam (el PDF por API las titula "Remision" aunque sean prefacturas: la plantilla no distingue).
Diff campo por campo prefactura 2384 vs remisión 1000: NO existe campo de tipo. Diferencias completas: CFDIUse 23 vs 3, ShowIEPS true vs false, PaymentTerms 30 vs 0, CFDIPaymentTerm con valor vs vacío — todo son valores del payload, nada discrimina el tipo.
⭐ El discriminador observable es la SECUENCIA DE FOLIOS: las prefacturas de la UI comparten numeración con las facturas (2384 → 2385 → 2386 fue nuestro incidente); nuestros false por API caen en la secuencia de remisiones (arrancó en 1000, virgen porque Balam no usa remisiones). Hipótesis operativa: la UI etiqueta por secuencia/typo interno; el body de Invoices_AddInvoice trae Number y Serie — candidato a experimento seguro: POST con false + Number apuntando a la secuencia compartida (+ espejo exacto de 2384: CFDIUse=23, ShowIEPS=true, plazo), verificar en UI cómo cae, y borrar si cae mal. Riesgo máximo: un documento no fiscal borrable con folio raro. Solo con go-ahead explícito y Bind:Mode=Write en sesión.
Detección construible YA sin tocar nada: prefactura de UI = fila false nueva (ligable a cotización/ticket por cliente+monto+fecha) y su facturación = fila pasa a 2 + gemela true timbrada. El flujo "plataforma cotiza → Araceli genera prefactura en BIND → plataforma detecta, liga y avisa el timbrado" funciona con el API actual, sin escribir.

ADENDA 2 (27-ago, madrugada) — el API público queda agotado por eliminación TOTAL. Experimentos autorizados de la sesión Write con Johann (todos con false, todos borrables):

Op #79 (folio 1002, $580, FAC-109/cotización 1029): se mandó Number: 2387 (siguiente de la secuencia compartida) + espejo de la 2384 (ShowIEPS, plazo 30) → BIND IGNORÓ el Number y asignó 1002 en la secuencia de remisiones. La palanca del folio no existe hacia adentro.
Sonda de campos no documentados (folio 1003, $116, borrada → "Cancelada"): un POST con 12 candidatos a campo interno de tipo (UseStock, ApplyStock, AffectsInventory, DocumentType/DocType/SaleType/InvoiceType: 2, IsPreInvoice/IsPrefactura/IsPreliminary/IsDraft/Prefactura: true) → todos ignorados (folio de remisiones, sin cambio de tipo). DELETE /api/Invoices/{id} funciona (204) pero es borrado suave: deja la fila como Cancelada.
Dump crudo del APIM: 98 operaciones (no 130), ninguna de prefactura/conversión. /api/Series?docType=0..20 todo vacío; CompanyProfile sin foliado. La web app (app.bind.com.mx) es ASP.NET MVC con login — su creación de ventas NO pasa por api.bind.com.mx.
Conclusión definitiva: Invoices_AddInvoice produce Remisión (false) o CFDI timbrado (true); el tipo Prefactura se decide en un camino interno de su UI al que el API público no llega por ningún campo, folio ni recurso.
La manera que SÍ queda (además de detección y de soporte BIND): capturar el endpoint interno de la UI con un navegador instrumentado (Playwright, script captura-prefactura.mjs — registra POST/PUT a bind.com.mx excluyendo login/credenciales) y evaluar replicarlo con sesión de cookies (RPA ligero) o usarlo como evidencia ante BIND para pedir el campo en su API.

Lectura estratégica:

La salvaguarda que funcionó fue la de diseño, no la de inferencia: dry-run + confirmación humana + verificación por lectura acotaron el daño a un folio cancelable. La lección: contra un API sin sandbox, ninguna inferencia negativa ("no hay operación X ⇒ X no puede pasar") es válida sin prueba positiva.

Candado triple ya en código (commit local fbb31fc): IsFiscalInvoice=false clavado en el builder, permitirFiscal:false clavado en la llamada, y el 409 en Confirmed. EsFiscal quedó inerte.

Experimento decisivo pendiente (riesgo cero): que un humano cree UNA prefactura en la UI de BIND (documento no fiscal, borrable) y re-escanear el API para ver si aparece y con qué firma. Si no aparece, el flujo de plataforma debe asumir que la prefactura es invisible por API y la detección automática solo puede ocurrir al timbrado (la factura sí es visible).

⚠️ Al 26-ago (tarde) la 2386 sigue Activa con UUID en BIND — la cancelación SAT no se ha ejecutado. Y 1000/1001 siguen activas (existe DELETE /api/Invoices/{id} si se quiere limpiar por API, con autorización).

71 · Ago 21, 2026 — 7:32 AM · Correo · Johann → Noé (CC Pedro) · "Seguimiento FAC-106": la causa del error y la primera cotización real

Dirección: enviado. Evidencia: buzón (hilo "Seguimiento FAC-106"); borrador en ../planeacion/Correo-error-resuelto-2026-08-21.md. Complementa el #69. (Registrado el 29-sep-2026 al cerrar los huecos de bitácora.)

Resumen: tras la sesión de las 7:00 am, Johann informa que ya encontró la causa del error y que la cotización desde FAC-106 ya se genera correctamente en BIND. El problema no eran los datos del ticket ni el formulario nuevo ("quedó muy bien"), sino dos detalles del API de BIND que no están en su documentación y solo se descubren probando: (1) cada partida lleva Type (producto vs servicio) sin valores documentados — con el valor de producto BIND buscaba el servicio en el catálogo equivocado y devolvía el error genérico de "comunicarte con soporte técnico"; (2) la escala del IVA por partida. Noé respondió el 24-ago con el mecanismo de la UI (#74).

72 · Ago 21, 2026 — 1:00 PM · Llamada · "Seguimiento - PAF (2)" · Homologación de estados del flujo ticket → cotización → prefactura → factura

Participan: Johann, Pedro (convocatoria de Pedro a las 7:14 am con la liga a FAC-106; Noé convocado). Canal: Teams. Evidencia: informe de Read AI (1:34 pm), solo el extracto del correo, sin transcript — ../fuentes/2026-08-21 a 2026-09-29 - Read AI - Informes Seguimiento PAF (extractos del correo).md. ⚠️ Reconstruida el 29-sep desde ese extracto.

Resumen: se definió la integración Jira ↔ BIND ↔ plataforma de punta a punta: creación del ticket → cotización → prefactura → factura → timbrado. Se acordó homologar los estados del flujo: la prefactura se reflejaría como "En proceso de facturación" y la factura completada como "Facturado" — coincide con la regla del #62: la aprobación de Araceli va entre esos dos estados. Quedó pendiente la prueba de escritura en Jira (cambiar el estado de un ticket desde la plataforma). Johann y Pedro acordaron repetir una prueba desde cero para validar la generación de la cotización y la escritura en BIND.

Pendientes que surgieron:

Johann — prueba de escritura en Jira (transición de estado de un ticket).
Johann — validar con Pedro la cotización creada en BIND cuando él tenga acceso para revisarla.

73 · Ago 24, 2026 — 7:00 AM · Llamada · "Seguimiento - PAF" · Validación cotización → prefactura (MXN/USD, IVA 16 %/0 %) y la primera semántica dura: `IsFiscalInvoice=false` = REMISIÓN

Participan: Noé, Pedro, Johann. Canal: Teams. Evidencia: informe de Read AI (7:44 am), extracto. Preparación: la noche del 23-ago se construyó en la plataforma el camino cotización → prefactura (POST /api/emision/prefactura con el mismo protocolo ADR-001; commits a893fa9…a07fff6 del repo del cliente): el wizard deja de simular (paso 4 = borrador, paso 5 = aprobación y generación real) y CFDIUse, ServiceID y PriceListID se heredan de una factura real y del detalle del cliente porque BIND los exige aun en prefactura.

Resumen: se validó el flujo de conversión de cotizaciones a prefacturas en BIND — captura, revisión, aprobación y registro financiero — con pruebas en moneda nacional e internacional, IVA 16 % y 0 %. Se identificaron ajustes pendientes en la lógica fiscal y en la clasificación del documento: los POST con IsFiscalInvoice=false produjeron los folios 1000 y 1001 como Remisiones, no prefacturas. Ajuste en vivo (commit 77d3767, 7:38 am): false = remisión; la prefactura pasa a modelarse como "factura sin timbrar" con opt-in explícito; la bandeja gana una columna BIND. Se evaluará automatizar el paso Jira → BIND como cotización para reducir clics. Noé condicionó los accesos de Azure a que las pruebas funcionen y pidió a Johann habilitar la aplicación en un VPS para facilitar las pruebas — origen de la publicación provisional (#77).

Puntos de acción (según Read AI):

Noé — gestionar los accesos de Azure una vez validado el funcionamiento de las pruebas.
Johann — habilitar la aplicación en el VPS para facilitar las pruebas.

Lectura estratégica: la hipótesis "true = factura sin timbrar = la prefactura del flujo" nació aquí, de la evidencia de que false era remisión y de que el API no tenía operación de timbrado. Dos días después resultó falsa (#70).

74 · Ago 24–25, 2026 · Correo · Noé ↔ Johann · dos hilos: cómo se hace una PREFACTURA en BIND ("Generar Venta") y los requisitos exactos de Azure ⭐

Dirección: recibidos (24-ago 3:48 pm y 3:52 pm; 25-ago 4:19 pm) y enviado (25-ago 4:54 pm). Evidencia: ../fuentes/2026-08-24 - Correo - Noe Generar Venta = prefactura (Re Seguimiento FAC-106).md y ../fuentes/2026-08-25 - Correo - Noe y Johann Acceso a Azure Balam y permisos.md.

1 · "Re: Seguimiento FAC-106" (Noé, 24-ago 3:48 pm, con 4 capturas de pantalla). Balam revisó las cotizaciones que se convirtieron en Remisión y explica el camino de la UI: "Cuando una cotización se hace y se quiere convertir en Prefectura [sic] se selecciona la opción en Acciones en Bind que dice 'Generar Venta', si se selecciona la opción Generar Pedido se hace remisión y eso no lo manejamos en Balam." Y en la ventana siguiente "se selección la opción 'Prefectura' para revisar antes de mandar la factura al cliente". ⭐ Primera descripción escrita del mecanismo interno: el tipo de documento se elige en la UI, después de "Generar Venta" — no existe en el API público (adenda 2 del #70, #83).

2 · "Acceso a Azure Balam y permisos" (Noé, 25-ago 4:19 pm; antes, 24-ago 3:52 pm en el hilo de Jira). "Para cerrar el tema del acceso a Azure y no dar más vueltas, ¿nos ayudas a detallar exactamente qué necesitas para publicar el ambiente? … lo validamos con la cuenta que estamos preparando para este uso y te damos acceso." Johann respondió el 25-ago 4:54 pm con la lista exacta: suscripción a nombre de Balam; grupo de recursos dedicado (rg-balam-paf-staging); rol Contributor solo sobre ese grupo; Key Vault Secrets Officer; proveedores para App Service Linux (.NET 10), PostgreSQL Flexible Server 17, Key Vault, Storage y Application Insights/Log Analytics; identidad OIDC para CI/CD desde GitHub; y los cinco datos a recibir (Tenant ID, Subscription ID, grupo, región, cuenta). Sin Global Admin ni facturación.

Acción derivada: Azure sigue en manos de Balam (#76); la plataforma se publica provisionalmente en un VPS propio (#77).

75 · Ago 26, 2026 — 7:00 AM · Llamada · "Seguimiento - PAF" · la sesión en la que el POST se TIMBRÓ (complemento del #70)

Participan: Noé, Pedro, Johann. Canal: Teams. Evidencia: informe de Read AI (7:35 am), extracto. Preparación: la noche del 25-ago se construyó el camino prefactura → factura (commits 1ad0e27…02cb042): detección del timbrado al instante, puertas idempotentes, y el botón "Timbrar" enlaza a BIND porque "el API no lo permite (130 operaciones revisadas, ninguna de timbrado/CFDI)" — la inferencia que falló esa misma mañana.

Resumen: la sesión revisó la habilitación de permisos y el flujo remisión / prefacturación / facturación entre la plataforma y BIND. Noé señaló que algunas funcionalidades aún debían construirse para permitir el uso completo de la plataforma. Johann explicó que BIND no permite timbrar por API y propuso generar la prefactura desde la plataforma y timbrar en BIND. Al confirmar desde el wizard (op #73, cotización 1028 / ticket FAC-108), BIND creó la venta 2386 como CFDI y la timbró: el incidente, su contención y la investigación están en el #70. Johann estimó que la revisión del flujo de prefacturación podría quedar resuelta durante el día — lo que quedó resuelto ese día fue el diagnóstico, no la creación.

Puntos de acción (según Read AI):

Pedro — solicitar apoyo para cancelar la factura generada durante la prueba (2386).
Noé — construir las funcionalidades necesarias para habilitar los permisos solicitados.
Johann — revisar y ajustar "el estatus y el parámetro" que provoca que la operación se genere como factura en lugar de prefactura → resultado: ese parámetro no existe en el API (adenda 2 del #70).

76 · Sep 3, 2026 — 7:00 AM · Llamada · "Seguimiento PAF - 02/09/26" · Datos del tenant de Azure, los conceptos de Acuntia por headcount y una definición: ítem por CÓDIGO de catálogo, concepto = título del ticket

Participan: Noé, Pedro, Johann. Canal: Teams. Evidencia: informe de Read AI (7:28 am), extracto (6 capítulos, no visibles).

Resumen: la reunión se enfocó en automatizar la generación de cotizaciones y facturas de Acuntia entre Jira, BIND y el ambiente de Azure. Se revisaron los datos necesarios "de Jitco" [sic, Read AI] para configurar el tenant de Azure y permitir el montaje. Para Acuntia, los conceptos dependen del headcount activo e incluyen textos por colaborador — coherente con "1 factura por colaborador, ~40" del Discovery. Definición de Balam (Pedro): la categoría del combo Servicio/Producto de Jira se traduce a un código del catálogo de servicios de BIND (p. ej. "Servicios Profesionales Generales" → 101), el ítem se conserva tal cual y solo el concepto se sobreescribe con el título del ticket. Sustituye el GUID del servicio 027 que iba fijo en la UI desde el 21-ago. Implementado el mismo día (commit ed4c819): GET /api/Services en BindClient, mapeo configurable Emision:ServicioPorCategoria, selector de ítem en la pantalla de cotización, y la caché de la bandeja se invalida al cotizar — en producción la pantalla mostraba "—" hasta un minuto después de crear la cotización.

Puntos de acción (según Read AI):

Noé — reenviar por correo a Pedro la solicitud de datos para configurar el tenant de Azure.
Balam/Johann — a la 1:30 pm, ejercicio de conversión de dos o tres tickets en cotizaciones (#78).

77 · Sep 3, 2026 · Desarrollo · La plataforma queda PUBLICADA en https://paputec.mx/balam/ — ambiente provisional propio mientras llega Azure ⭐

Evidencia: commit 03582af del repo del cliente (pusheado el 15-sep) y runbook ../balam-plataforma/deploy/paputec/README.md. Origen: la petición de Noé del 24-ago de habilitar la aplicación en un VPS para facilitar las pruebas (#73).

Qué se publicó: frontend Angular bajo /balam/ y API en /balam/api/, en un VPS propio (Ubuntu 24.04 · Plesk · Apache · Docker): Postgres 17 sin puertos publicados; API en contenedor chiseled (usuario sin privilegios, FS de solo lectura, cap_drop ALL) escuchando solo en loopback; Apache como única cara pública (TLS, HSTS, CSP); deploy.sh reproducible; rol balam_app sin BYPASSRLS (cierra el hueco de RLS del #53); respaldo diario con 14 días de retención; seeder de un solo administrador. Endurecimiento del API: rate limit por IP (global y de login), bloqueo 15 min tras 5 fallos, contraseñas ≥ 12, no-store/nosniff, sin banner, X-Forwarded-* solo desde loopback. Secretos solo en /opt/balam/.env (root, 0600): nada en el repo ni en imágenes. Producción corre con Bind:Mode=ReadOnly y Jira:Mode=ReadOnly; para una sesión acompañada de escritura se enciende Write y se apaga al terminar (regla del cliente, ADR-001).

Lectura estratégica: Azure llevaba cinco semanas sin destrabarse (#59, #63, #65, #74). Publicar en infraestructura propia convirtió las sesiones de pantalla compartida en pruebas sobre una URL viva: la tarde de ese mismo día Balam cotizó tres tickets reales desde ahí (#78). El costo: la plataforma vive fuera del tenant del cliente hasta que Azure exista.

78 · Sep 3, 2026 — 1:30 PM · Llamada · "Seguimiento PAF (2) 03/09/26" · Tres tickets de Pedro convertidos en cotizaciones desde la plataforma publicada

Participan: Pedro, Johann. Canal: Teams. Evidencia: informe de Read AI (1:51 pm), extracto (capítulos y acciones bloqueados).

Resumen: se validó la aplicación para convertir tickets en cotizaciones como etapa previa a la facturación. Johann confirmó que los tres tickets de Pedro ya se habían enviado como cotizaciones a BIND y que el concepto usa el nombre del ticket (definición de la mañana, #76). En una prueba con un ticket de Linares se verificó [el resto del informe está truncado]. Primera vez que Balam opera la plataforma sobre la URL publicada.

79 · Sep 7, 2026 · Desarrollo · Cotización EN LOTE desde la bandeja: una cotización BIND por ticket, dry-run y confirmación en serie

Evidencia: commit fbdbd18 del repo del cliente (pusheado el 15-sep); documentado en su CLAUDE.md.

La bandeja permite marcar varios tickets (solo los que aún no tienen cotización) y "Cotizar seleccionados" abre solicitudes/cotizar-lote?ids=…: una fila por ticket, prellenada con las mismas reglas que la pantalla individual (cotizacion-prefill.ts), editable, con vista previa (dry-run) y confirmación por ticket. Cada confirmación es una WriteOperation y un QuoteInvoiceLink independientes; un rechazo de BIND deja la fila en error y no aborta el lote. Las llamadas van en serie para respetar la cuota de BIND y no mezclar folios. Responde al caso Acuntia (~40 facturas al mes, una por colaborador, #76).

80 · Sep 9, 2026 — 1:00 PM · Llamada · "Seguimiento PAF - Prefactura" · Araceli crea una prefactura en vivo con "Generar venta" y aparece el endpoint interno: `InvoiceDetails` ⭐

Participan: Araceli, Pedro, Johann (Noé convocado). Canal: Teams, con pantalla compartida de Araceli. Evidencia: informe de Read AI (1:24 pm), extracto (capítulos y acciones bloqueados). Es la vía "endpoint interno de la UI" que dejó abierta la adenda 2 del #70.

Resumen: el equipo revisó el procedimiento para crear una prefactura a partir de una cotización y confirmó que debe usarse "Generar venta" — "Generar pedido" no habilita esa función (lo mismo que Noé escribió el 24-ago, #74). Durante las pruebas, Araceli creó y guardó una prefactura mientras Johann analizaba las peticiones registradas en las herramientas de desarrollador del navegador. Identificaron InvoiceDetails como la petición interna de app.bind.com.mx involucrada en la creación [el resto del informe está truncado].

Lo que NO quedó documentado en ningún lado (verificado el 29-sep en repo, disco y buzón): URL completa, método, payload, respuesta ni el manejo del anti-forgery token. Solo el nombre.

81 · Sep 10, 2026 — 1:00 PM · Llamada · "Seguimiento PAF - Prefactura" · Con Pedro: cotización 1078 (Acuntia) y captura de la petición de red de la prefactura para evaluar su réplica

Participan: Pedro, Johann. Canal: Teams. Evidencia: informe de Read AI (1:21 pm), extracto (capítulos y acciones bloqueados).

Resumen: Johann y Pedro analizaron la cotización 1078 de Acuntia para identificar la petición de red que la UI usa al generar una prefactura y evaluar su posible replicación manual e integración posterior. Configuraron DevTools: caché deshabilitada, preserve log y columna de método [el resto está truncado]. Conclusión operativa de estas dos sesiones: para replicar la petición hace falta una sesión web propia (cookies + token) — Johann no tenía usuario en app.bind.com.mx; se pidió a Balam y llegó el 29-sep (#83).

82 · Sep 15–16, 2026 · Administración · Corte de horas 10-ago → 16-sep (94.58 h), Excel de avance con fechas reales publicado en Google Sheets, y push de los tres commits de septiembre al repo del cliente

Evidencia: commits d9047de, 69e06df, 68aedc7 (este repo); ../planeacion/Seguimiento-horas.md; Avance-Balam-2026-09-16.xlsx; Sheet compartido "Avance-Balam" en Drive:/Balam.

39.25 h del 10-ago al 15-sep reconstruidas con evidencia (commits, correos, informes de Read AI) y marcadas reconstruida en el CSV; seis sesiones sin bitácora quedaron listadas como huecos — cerrados en este bloque (#72–#81). Etapa 2 sin ajuste Jira: 23.75 h de 38–46 estimadas; el ajuste Jira → BIND rebasó (14.75 h de 7–10) por las semánticas indocumentadas del API y cinco sesiones acompañadas. El Excel muestra fechas reales por tarea (primer y último día trabajado). Los commits 03582af, ed4c819 y fbdbd18 se pushearon al repo del cliente el 15-sep.

Participan: Pedro, Johann (Noé convocado; las cuentas son de Noé). Canal: Teams. Convocatoria de Pedro el 28-sep 5:10 pm. Evidencia: informe de Read AI (7:23 am), extracto con capítulos y acciones: ../fuentes/2026-08-21 a 2026-09-29 - Read AI - Informes Seguimiento PAF (extractos del correo).md.

Resumen: la reunión se enfocó en validar accesos y ejecutar una prueba de integración ERP creando cotizaciones y prefacturas en BIND. Pedro confirmó que su perfil estaba habilitado y que las cuentas de Noé tienen permisos para crear facturas, prefacturas y operaciones relacionadas. Johann solicitó las credenciales; se acordó entregarlas en un archivo TXT para usarlas en la aplicación. Con eso, al cierre del día Johann ya tiene login web a app.bind.com.mx. Durante la prueba apareció un error que impide cargar la solicitud al crear una cotización desde la plataforma; queda como acción de Johann.

Puntos de acción (según Read AI):

Johann — revisar el error que impide cargar la solicitud al crear una cotización en BIND.
Johann — crear la cotización en BIND después de corregir el error.

Investigación de cierre (29-sep, solo lectura, sin tocar BIND):

El modelo de dos endpoints queda confirmado con fuente primaria. El SDK oficial de BIND (Bind-ERP/BindERP-Python, cuyo swagger es el contrato autoritativo) expone un único POST de creación de ventas, Invoices_AddInvoice, con el modelo NewInvoice: 7 campos requeridos (currency_id, client_id, location_id, warehouse_id, cfdi_use, invoice_date, price_list_id) y opcionales entre los que están is_fiscal_invoice, serie, number, credit_days, services[], emails[], purchase_order y payments[] — y ningún campo de tipo de documento (DocumentType, Prefactura, IsPreInvoice… no existen). En todo el repo del SDK no hay un solo archivo con "prefactura", "proforma" o "remision". Explica por qué las 12 sondas y el Number del #70 fueron ignorados: no están en el contrato y el deserializador los descarta.
Externo = api.bind.com.mx → Remisión (false) o CFDI timbrado (true). Interno = app.bind.com.mx (ASP.NET MVC, sesión por cookie, login en /Login/Login) → Acciones → Generar Venta → Prefactura, petición InvoiceDetails (#80).
En el foro público de mejoras de BIND existe una solicitud abierta "agregar PREFACTURA" (binderp.featureupvote.com, bloqueado por Cloudflare para lectura automática): otros clientes piden lo mismo.
⚠️ Lo que sigue sin especificarse: URL, método, Content-Type, shape del payload, respuesta, cookies y __RequestVerificationToken de InvoiceDetails, y el flujo de login. La captura del 10-sep no se guardó en el repo, en disco ni en correo. Con el login propio ya se puede recapturar sin depender de nadie.

Lectura estratégica:

Se abrió la vía que el #70 dejó como única salida. Un mes después del incidente, Balam entrega la llave (login web) y autoriza la prueba con prefacturas. La prefactura por UI es un documento no fiscal y borrable: el riesgo es cero comparado con el timbrado.

Antes de codificar el cliente interno hay que escribir su contrato, como se hizo con Quotes_NewQuote en el #64: capturar con la sesión propia, sanitizar (sin cookies ni token) y dejarlo en la bitácora. Después, BindUiClient con el mismo protocolo ADR-001 (dry-run → confirmación humana → verificación por lectura).

Tres riesgos abiertos: (1) las prefacturas creadas así saldrán con CreatedByName = cuenta de Noé — hay que acordarlo o pedir un usuario de servicio; (2) replicar la UI es frágil ante cambios de BIND y posiblemente ajeno a sus términos de servicio — conviene pedir en paralelo el campo oficial a soporte BIND con esta evidencia; (3) las credenciales llegan en TXT: van a user-secrets/.env gitignoreado y el TXT se destruye (lección del token de julio, VALIDACION-API.md §8.12).

84 · Sep 29, 2026 · Sesión de trabajo · App en modo escritura, token de Jira y plan del webhook FAC → vista previa de cotización ⭐

Contexto: sesión de Johann con Claude Code. Nota: la bitácora no tiene entradas entre el #70 (26-ago) y este; el trabajo del 9/10-sep (puente a la UI de BIND para la prefactura) está documentado solo en balam-plataforma/CLAUDE.md y se sube al repo en esta misma fecha.

⚠️ Renumerado de #71 a #84 el 30-sep, al fusionar las dos sesiones paralelas del 29-sep: la otra numeró #71–#83 con las sesiones del 21-ago al 29-sep. Los commits d76496f…e5912bf de este repo y la documentación de la plataforma dicen "Registro #71" y se refieren a esta entrada. La nota de arriba sobre el hueco entre el #70 y este quedó superada por esos registros. A su vez, este registro deja atrás lo que el #83 da por pendiente: el endpoint interno de la UI ya está especificado y construido (BindUiClient, AddInvoiceTransaction, commit 4d6b3d8 del repo del cliente; ver punto 5).

1. Levantar la app en modo escritura. Se arrancó Docker Desktop (estaba apagado) → Postgres balam-postgres-dev en 5438, frontend en 4200 y API en 5078 con Bind__Mode=Write, Bind__Ui__Enabled=true y Bind__Ui__Mode=Write como variables de entorno de esa corrida (los user-secrets siguen en Bind:Mode=ReadOnly, así que al apagar vuelve sola a solo lectura).

⚠️ Choque entre dos sesiones de Claude Code: otra sesión en la misma máquina levantó su propia API a las 13:24 (y de nuevo a las 15:28, --no-build) sin las variables de escritura. La API de esta sesión murió sin excepción en el log y el reinicio falló con address already in use. La API que quedó viva en 5078 era la de la otra sesión, en Bind:Mode=ReadOnly.
Evidencia en pantalla: el paso 3 del wizard (Vista previa y creación (ADR-001)) generó la operación #15 · POST /api/Quotes como dry-run registrado en WriteOperations, con el botón Crear cotización en BIND deshabilitado: "el servidor está en modo ReadOnly". No se escribió nada en BIND.
Lección: una sola sesión debe ser dueña de la API durante una sesión de escritura; verificar el dueño del puerto (no solo que esté escuchando).

2. Token de Jira. Existe Jira:ApiToken en user-secrets de Balam.Api (junto con Bind:ApiKey, Jwt:SigningKey, etc.); configuración en appsettings.Development.json: balam-jsm-temp.atlassian.net, usuario pedro.ayala@… (token personal de Pedro), proyecto FAC, Mode=ReadOnly. No se verificó el valor (el clasificador de permisos bloqueó leerlo, correctamente). Prueba práctica de vigencia: que la bandeja de Solicitudes FAC cargue.

3. ¿Se puede leer la creación de un ticket y automatizar la cotización?

Leer: sí, hoy. Polling con JQL delta (SearchJqlAsync + SyncSchedulerService + checkpoint con solape, ADR-002) o webhook. Recordatorio del 10-ago: el disparador acordado (En proceso de facturación) dura ~3 min, así que el poller debe leer el changelog, no el estatus actual.
Crear la cotización sin humano: técnicamente sí, pero rompe ADR-001 (dry-run + confirmación humana en cada escritura a BIND producción). Propuesta aceptada como camino: el webhook/poller deja lista la vista previa y un humano confirma con un clic. Automatización total solo con autorización escrita de Balam y enmienda a ADR-001.

4. Webhook / Jira Automation — qué se necesita. URL pública (ngrok ya instalado en la máquina de Johann; productivo = Azure o dominio fijo), endpoint nuestro POST /api/jira/webhook (no existe aún), y el disparador en Jira. Con el token actual: construir el endpoint sí (no requiere permisos de Jira); crear el webhook/regla en Jira solo si el usuario de Pedro es admin y con autorización expresa, porque es escribir en la configuración del Jira productivo a su nombre.

Johann confirma que existe autorización escrita de Pedro para hacerlo. ⚠️ Aún no archivada en fuentes/.

Fase 1 del plan — ejecutada el mismo 29-sep (solo GET, nada creado ni ejecutado): myself 200 → Pedro Alberto Ayala Elizondo, activo · mypermissions en FAC: ADMINISTER = true (admin de Jira), ADMINISTER_PROJECTS = true, CREATE_ISSUES = true, SYSTEM_ADMIN = false (no se necesita) · GET /rest/webhooks/1.0/webhook 200 → 0 webhooks de sitio (el endpoint exige admin: acceso confirmado) · API de Automation (api.atlassian.com/automation/public/jira/{cloudId}/rest/v1/rule/summary) 200 con el mismo token → 50+ reglas visibles (primera página), casi todas de alcance sitio; relevantes para FAC: Confirmación ticket creado - FACT, Factura por soporte técnico, Facturación Anticipada. Conclusión: el token de Pedro puede crear tanto el webhook de sitio (Vía A) como reglas de Automation (Vía B). Queda archivar la autorización y decidir el evento.

Resultado: plan en ../planeacion/Plan-Webhook-Jira-2026-09-29.md: 5 fases (verificar permisos por GET → endpoint con secreto/idempotencia/relectura → ngrok con traffic policy de una sola ruta → una escritura auditada en Jira, preferentemente webhook de sistema → ticket de prueba y reversa).

5. Hallazgos del mismo día hechos en la OTRA sesión de Claude Code (fuente: balam-plataforma/CLAUDE.md, §Puente a la UI; no verificados en esta sesión):

⭐ 29-sep 16:08 — PRIMERA PREFACTURA REAL DESDE LA PLATAFORMA: folio 2467 (ACUNTIA, $777,777 MXN, IVA 0, sin UUID, Activa), desde la cotización 1083 / ticket FAC-166, op #28, por el puente AddInvoiceTransaction con el usuario nuevo CTO (a nombre de Noé Rocha Castillo). BIND dejó la 1083 como Surtida.
- Lecciones: el API público tarda más de un minuto en ver lo que crea la web app (hay reintentos); todo lo posterior al POST quedó en try/catch para que un documento creado nunca se reporte como fallo.
- ⚠️ BIND dejó CFDIPaymentTerm = PUE aunque el cuerpo iba en PPD (igual que la 2462 hecha a mano): se define al timbrar. Choca con la salvaguarda #4 (PPD por default); revisar antes del timbrado.
⚠️ El API público (api.bind.com.mx) responde 500 en TODOS los endpoints con la API key de arturo|128469 (pasa autenticación y falla adentro; la web app sí funciona). El sync no avanza desde el 10-sep. Hipótesis: Balam tocó el acceso de Arturo al crear el usuario CTO. Salida propuesta: API key del usuario CTO en Bind:ApiKey.
🔒 Web app de BIND: una sesión por usuario. La plataforma entra, opera y sale en cada operación; nadie debe usar el usuario CTO en un navegador mientras la plataforma opera.
⛔ Escritura accidental: QuotesAPI/FillQuote resultó ser "Marcar como Surtida" y escribe por GET. Se invocó por error y dejó la cotización de prueba 1079 en Surtida (sin documento ni efecto fiscal; irreversible desde la UI). Desde entonces el lector solo permite /Assets/*, /Sales/*Details y *API/Get*.
La web app expone un API interno (66 rutas InvoicesAPI/*, 12 QuotesAPI/*, 26 ClientsAPI/Get*): plan B si el API público sigue caído. GetClientSelectedById resuelve las dos suposiciones del builder (PaymentMethod, CFDI_Use).

Repo de la plataforma: se sube el puente de prefactura por la UI de BIND (BindUiClient, PrefacturaUiEndpoints, tarjeta del wizard y pruebas) sobre 4 commits remotos de la otra máquina (26-ago: experimento de folio compartido; 15-sep: publicación en paputec.mx, catálogo de servicios, cotización en lote). Tres conflictos resueltos: se conservó el candado 409 de POST /api/emision/prefactura (el commit remoto del 26-ago noche lo había retirado para el experimento de Number, que el 27-ago BIND ignoró), se combinaron los campos de NewInvoice (Number/ShowIEPS + PrevInvoice/IsCFDI/QuoteID) y los usings de Program.cs. Verificado después del rebase: 108 pruebas en verde y frontend compilando; escaneo del diff sin secretos. Commit 4d6b3d8.

ADENDA (29-sep, noche) — PILOTO DEL WEBHOOK VALIDADO DE PUNTA A PUNTA (autorización expresa de Johann para las tres escrituras de prueba en Jira; Pedro autorizó el uso de su token):

Plataforma (commit d7238da en el repo del cliente): POST /api/jira/webhook con secreto (HMAC X-Hub-Signature o token), relectura del ticket por API (solo GET), tabla JiraTicketEvents con RLS e idempotencia, GET /api/jira/eventos; sin secreto responde 404. 8 pruebas nuevas, suite de la API en 38/38. Instancia expuesta en el puerto 5079 con Bind:Mode=ReadOnly y el puente UI apagado; ngrok con traffic policy que solo deja pasar el webhook (verificado desde internet: todo lo demás 404).
Antes de escribir, inventario de Automation (solo GET): 64 reglas (42 activas); de las 17 que se disparan al crear un ticket, solo "Confirmación ticket creado - FACT" aplica a FAC (proyecto 10034) y manda correo al reporter. Notificaciones de FAC al crear/borrar: reporter + watchers → con el ticket de prueba todo le llegó solo a Pedro.
Jira-op 1 (19:05:53): webhook de sitio id 1 registrado — jira:issue_created, filtro project = FAC, con secreto HMAC, apuntando a https://gregoria-disjoined-marcelino.ngrok-free.dev/api/jira/webhook.
Jira-op 2: ticket de prueba FAC-169 creado por API (asignado a Pedro, marcado como prueba). → Jira entregó una sola vez, firmado HMAC, desde "Atlassian Webhook HTTP Client"; la plataforma lo registró verificado (estatus Open) 14.4 s después del timestamp del evento (la creación por API tardó ~11 s en responder; el aviso llegó ~3 s después).
Jira-op 3 (19:07:44): FAC-169 borrado (204; GET posterior → 404). En la BD local queda el evento id 1 como evidencia.
Estado al cierre: el webhook id 1 sigue registrado y activo, pero el túnel y la instancia 5079 se apagaron al cerrar la sesión → Jira entrega a una URL caída hasta moverlo. Destino estable: https://paputec.mx/balam/api/jira/webhook (Apache ya proxya /balam/api/). Script de operación: ../planeacion/jira-webhook-prueba.py (subcomandos estado, mover, borrar-webhook, crear-ticket, borrar-ticket).

Lectura estratégica: el webhook no cambia el protocolo de escritura: lo que acelera es la captura, no la decisión. Y el caso más valioso no es la creación del ticket sino el cruce de 3 minutos por En proceso de facturación, que el polling de 15 min pierde.

85 · Sep 30, 2026 — madrugada (≈12:10–12:35 AM) · Despliegue · El webhook de Jira FAC queda EN PRODUCCIÓN (paputec): publicado, secreto nuevo, webhook id 1 movido y prueba de punta a punta con FAC-170 en 1.05 s ⭐

Contexto: sesión de Johann con Claude Code, continuación del #84 en la otra máquina (la que tiene la llave SSH de paputec). Autorizaciones de Johann dadas en la sesión, una por una: ejecutar el plan (pull, publicación, secreto), el PUT del webhook, y crear + borrar el ticket de prueba. Evidencia: commit 9351aa4 del repo del cliente, fila id 1 de JiraTicketEvents en la BD de paputec y log del contenedor balam-api.

1. Las dos bitácoras del 29-sep chocaban. Esta máquina tenía sin publicar los registros #71–#83 (commit 3de2739); la otra publicó la sesión del webhook también como "#71". Al fusionar (commit e88b5e1) la del webhook pasó a ser el #84, con nota de renumeración. Lección: antes de numerar un registro, git pull.

2. Publicación en paputec. Plataforma en 5145801 (cuatro commits nuevos para producción: 4d6b3d8 puente a la UI de BIND, d7238da webhook, 8479e96, 5145801). Antes de publicar: 116 pruebas en verde (13 + 14 + 51 + 38), respaldo manual de la BD (balam-20260930-062117.sql.gz) y la imagen anterior etiquetada balam-api:pre-webhook-20260930 para rollback. deploy/paputec/deploy.sh completo (frontend + API) → API sana, frontend 200. La migración 20260930005018_JiraTicketEvents se aplicó al arrancar (la última aplicada era la del 12-ago). Log de arranque: los dos mensajes benignos del runbook y, en cuanto corre el scheduler, el ciclo de sync falla con BIND API 500 on /api/Clients (tres reintentos y fail, a los 15 s del arranque y otra vez a los 15 min): es el bloqueo conocido del API público, ahora confirmado en el log de producción. El puente a la UI de BIND queda apagado en producción (no hay Bind__Ui__* en el .env; default Enabled=false).

3. Secreto nuevo. openssl rand -base64 32, guardado en ~/jira-webhook-secret.txt (0600) de esta máquina y agregado a /opt/balam/.env como Jira__Webhook__Secret (doble guion bajo: la clave de configuración es Jira:Webhook:Secret). Nunca se imprimió; se compararon los sha256 de ambos lados y coinciden. docker compose up -d api. El secreto del piloto del 29-sep (el que iba en la URL de ngrok) queda sin uso.

4. Verificación sin tocar Jira, a través de Apache (https://paputec.mx/balam/api/jira/webhook): antes del secreto → 404 (receptor apagado); con ?token=malo → 401; sin credencial → 401; X-Hub-Signature inventada → 401; firma HMAC correcta con un evento no suscrito → 202 ignorado (no toca Jira ni la BD), también con un cuerpo de 280 KB; GET → 405. Apache no bloquea el POST anónimo; el cuerpo grande, con HTML y SQL en el texto, pasó sin filtro.

5. Escrituras en el Jira del cliente (continúan la numeración del #84):

Jira-op 4 (00:25:18): PUT /rest/webhooks/1.0/webhook/1 → 200 (el PUT existe; no hizo falta borrar y registrar). Releído por GET: nombre "Balam plataforma · FAC ticket creado", destino https://paputec.mx/balam/api/jira/webhook sin query (solo HMAC), habilitado, jira:issue_created, filtro project = FAC.
Jira-op 5 (00:28:29): ticket de prueba FAC-170 (id 17865) creado por API, asignado a Pedro → producción lo registró como evento id 1: Verified = true, AuthMethod = hmac, estatus Open, 1.05 s después del timestamp del evento (emitido 00:28:29.530, recibido 00:28:30.579). Log: [jira-webhook] jira:issue_created FAC-170 detectado · verificado=True · auth=hmac · retraso=1.0s.
Jira-op 6 (00:28:38): FAC-170 borrado (204; GET posterior → 404). Vivió 9 segundos. Como con FAC-169, a Pedro le llega el correo de la regla "Confirmación ticket creado - FACT".

6. Hallazgo: producción corre con Bind__Mode=Write. Así estaba /opt/balam/.env (el contenedor reemplazado llevaba 3 semanas arriba), contra lo que dicen el runbook y el #77. No se tocó. Johann decidió dejarlo en Write (30-sep). El receptor del webhook no escribe en BIND en ningún caso, y Jira__Mode sigue en ReadOnly.

7. Script de operación (../planeacion/jira-webhook-prueba.py): esperar CLAVE paputec consulta la BD de producción por ssh (antes solo el contenedor local), y la fecha del ticket de prueba ya no va fija en 29-sep.

Estado al cierre: la detección de tickets creados en FAC funciona en producción y ya no depende de ninguna máquina encendida. Ninguna escritura en BIND. Sigue abierto lo urgente del #84: el API público de BIND en 500 (sync detenido desde el 10-sep) y la prefactura 2467 por confirmar con Balam.

Lectura estratégica:

El primer eslabón de "ticket creado → cotización" ya es infraestructura, no demo. Falta lo que le da valor: que cada detección arme sola la vista previa (dry-run) y el ticket aparezca como "lista para revisar". La confirmación sigue siendo humana (ADR-001).

⚠️ Ese siguiente paso choca con el bloqueo del API de BIND: el prellenado de la cotización resuelve moneda, ubicación, almacén y servicio con los catálogos del API público (GET /api/emision/catalogos), que hoy responde 500. Sin la API key del usuario CTO (o el acceso de Arturo reparado), la vista previa automática se puede construir y probar con FakeHandler, pero no validar contra BIND.

El webhook es de un solo intento útil: sin el poller de respaldo, un aviso que Jira no logre entregar (paputec caído, despliegue en curso) se pierde. Conviene construirlo junto con la vista previa.

86 · Sep 30, 2026 — madrugada (≈12:35–12:50 AM) · Desarrollo · Vista previa AUTOMÁTICA de la cotización por cada ticket detectado: "Lista para revisar" en la bandeja — construida, probada y PUBLICADA (ver adenda); le falta la API key nueva de BIND para servir

Contexto: misma sesión del #85; es la "siguiente meta" del plan del webhook (#84). Evidencia: commits locales 1c37eaa y 287cb65 del repo del cliente (sin push y sin desplegar: eso espera la orden de Johann). No se tocó Jira, BIND ni producción.

Qué hace. Cada JiraTicketEvent verificado se encola y un trabajador en segundo plano prepara, fuera de la petición del webhook (Jira no espera a BIND), el dry-run de la cotización de ese ticket: relee el ticket, carga los catálogos de BIND, prellena con las mismas reglas de la pantalla y guarda el body en WriteOperations como DryRun firmado por webhook-jira. El resultado queda en el evento y la bandeja lo pinta en la columna BIND:

Lista para revisar — el dry-run está guardado; falta que un humano lo revise y confirme.
Faltan datos — con el detalle: cliente sin coincidencia única en BIND, categoría Servicio/Producto sin mapear a un código, o sin monto. No adivina.
Vista previa pendiente — BIND o Jira no respondieron; un barrido la reintenta cada 15 min durante 7 días y se detiene en la primera falla para no quemar cuota.
Ticket ya cotizado o borrado: no se pinta nada.

Lo que NO cambia (ADR-001). El servicio solo hace lecturas (GET a Jira y a los catálogos de BIND) y no tiene ningún camino a la creación de la cotización: confirmar sigue siendo de un humano en la pantalla de cotización. Las pruebas lo afirman contra un BIND y un Jira falsos que registran cada petición. Bind__Mode no se tocó.

Cómo está construido. VistaPreviaCola + VistaPreviaWorker + VistaPreviaCotizacionService; CotizacionPrefill.cs es un port fiel de cotizacion-prefill.ts (más la carga de emitir-cotizacion.ts); CatalogosEmision comparte lectura y caché con GET /api/emision/catalogos; la validación y el armado del body se extrajeron del endpoint para que la vista previa y la pantalla usen los mismos. Migración aditiva JiraTicketEventsVistaPrevia (5 columnas en JiraTicketEvents). POST /api/jira/eventos/{id}/vista-previa la repite a mano (rol de escritura). Apagable con Jira__Webhook__AutoPreview=false.

Verificación. Suite completa en verde: 147 pruebas (antes 116): 24 casos del prellenado y 7 de integración sobre Postgres real (ticket completo → Lista con el body correcto y solo GETs; incompleto → dice qué falta; BIND en 500 → Error y reintento; ya cotizado; repetición a mano con permisos; apagado; y el contrato de GET /api/emision/catalogos, que la pantalla sigue leyendo igual). Frontend compila. ⚠️ No verificado: el chip no se vio en un navegador, y nada se probó contra el BIND real (API público en 500).

Lectura estratégica:

En producción, hoy, toda vista previa quedaría en "pendiente": el prellenado necesita los catálogos del API público de BIND, que sigue en 500. La pieza está lista para el día que Balam entregue la API key del usuario CTO; el barrido recogería solo lo acumulado de los últimos 7 días.

Deuda consciente: las reglas de prellenado viven dos veces (TypeScript y C#). Hay pruebas del lado del servidor y avisos en ambos archivos, pero lo correcto es que las pantallas consuman el prellenado del servidor.

Limitación: el estado es una foto del momento de la creación. Si alguien completa el ticket en Jira después, "Faltan datos" no se entera (el webhook solo escucha issue_created); se repite a mano o al abrir la pantalla.

ADENDA (30-sep, ≈12:50–1:00 AM) — push, publicación y la causa del 500 de BIND. Johann ordenó "haz push y publica" y dio la pista: el 500 se debe a que producción usa la API key vieja; la nueva está en el appsettings.local.json de desarrollo.

Push de los dos repos (1c37eaa y 287cb65 al repo del cliente; la bitácora a git.paputec.mx).
⭐ La pista era correcta. La key del archivo local es de cto|128469 (emitida el 29-sep; la de producción es otra, comparadas por huella sin imprimirlas) y responde 200: GET /api/Currencies → 4 monedas, GET /api/Clients?$top=1 → 1 fila. Dos lecturas, nada más. La key de arturo sigue en 500 en todos los endpoints: el API público de BIND no está caído; lo que dejó de servir es esa key.
Publicación (00:53): respaldo manual (balam-20260930-065306.sql.gz), imagen anterior etiquetada balam-api:pre-vistaprevia-20260930, deploy.sh completo → API sana. Migración 20260930063914_JiraTicketEventsVistaPrevia aplicada. El trabajador arrancó ([vista-previa] Activa: barrido de pendientes cada 15 min) y su primer barrido resolvió el único evento que había: FAC-170 → NoAplica ("El ticket ya no existe en Jira"), lo esperado para el ticket de prueba borrado. El webhook sigue respondiendo (401 con token malo, 202 con firma válida).
⛔ Lo que NO se hizo: cambiar Bind__ApiKey en /opt/balam/.env. El control de permisos de Claude Code bloqueó la escritura de ese secreto y no se intentó por otra vía; el servidor quedó intacto. Producción sigue con la key de arturo: el sync sigue fallando con 500 (visto en el log tras publicar) y toda vista previa nueva quedará en "Vista previa pendiente". Queda como acción de Johann (rotación de secreto del runbook: editar el .env y up -d api); al entrar la key nueva, el sync se reanuda solo y el barrido prepara lo pendiente de los últimos 7 días.
⚠️ El appsettings.local.json de esta máquina está en backend/ y el API lo busca en backend/src/Balam.Api/appsettings.Local.json: donde está, no se carga. Y trae Bind:Mode=Write y Bind:Ui:Mode=Write: al moverlo, la instancia local arrancaría en escritura.

87 · Sep 30, 2026 — madrugada (≈1:00–1:45 AM) · Producción + desarrollo · La API key de `cto` entra a producción (el sync vuelve tras 20 días), la vista previa se valida contra el BIND REAL (FAC-171) y se construye el MODAL EN VIVO con "Aceptar", la campana y el modo automático configurable ⭐🔥

Contexto: misma sesión del #85/#86. Instrucciones de Johann en la sesión (sus palabras, con la ortografía normalizada): "te autorizo cambiar el token en producción, lo siguiente que quiero hacer es validar el flujo de jira-cotización, que cuando se cree un ticket se cree la cotización automáticamente"; sobre el alcance: "por ahora, agrega un modal con un 'aceptar', y que después con una animación fluida se vaya a notificaciones si pasa mucho tiempo, y le puedas dar en ver detalle, quiero que se vea que fue en tiempo real, haz configurable el que se haga en automático o el que pida confirmación a través del modal"; y para el ticket de prueba: "Autorizo: cliente ACUNTIA, crear y borrar". Evidencia: commit aac7447 del repo del cliente (publicado a las 6:53 AM, ver adenda), capturas y video en ../planeacion/modal-en-vivo-2026-09-30/, fila id 2 de JiraTicketEvents y operación #155 en la BD de paputec.

1. La API key nueva ya está en producción. Con la autorización de Johann se reemplazó Bind__ApiKey en /opt/balam/.env por la del usuario cto (sin imprimirla; huellas comparadas). La anterior quedó comentada en el mismo archivo para rollback. Al reiniciar: [sync] Ciclo OK — 17 clientes, 1,202 facturas vistas (2 nuevas, 2 actualizadas, 2 pagos detectados) y 3 cotizaciones nuevas. El sync estaba detenido desde el 10-sep.

2. Radiografía del formulario y del catálogo (solo lecturas). El formulario "Cotización Bind" (service desk 35, request type 1196) exige diez campos: empresa origen, título, cliente (17 opciones), servicio/producto (17), cantidad, moneda, monto sin IVA, IVA (16 %/0 %), vencimiento y descripción. El catálogo de servicios de BIND ya está depurado: 11 ítems, códigos 100–110. Con las reglas de prellenado de hoy:

Clientes: 17 de 17 opciones del combo resuelven a un único cliente de BIND.
Categorías: 9 de 17. Las ocho que NO resuelven y caerían en "Faltan datos": Gestión de Proyectos Senior / PMO, Gestión de Mesa de Servicio (SDM), Soporte Especializado Nivel 1 (L1) y Nivel 2 (L2), Gestión de Incidentes, de Cambios y de Capacidad, y Servicio de Enlace (en BIND se llama "Servicios de Enlace", código 106). Falta que Balam diga a qué código va cada una (Emision:ServicioPorCategoria; sobran en BIND el 102 "Proffesional Services" y el 106).

3. Vista previa validada contra Jira y BIND reales, en producción (dos escrituras en Jira, autorizadas):

Jira-op 7 (01:07:21): ticket de prueba FAC-171 creado por el API de Jira Service Management con el formulario completo (ACUNTIA, Servicios Profesionales Generales, 1 × $1,234.00 MXN, IVA 16 %). → detectado 1.04 s después (HMAC, verificado) → vista previa Lista a los 4.32 s (incluye la primera lectura de catálogos a BIND) → operación #155 en DryRun, firmada por webhook-jira, sin confirmar. El body quedó como lo armaría la pantalla: cliente ACUNTIA, ítem de código 101, concepto = título del ticket, Price 1234, Qty 1, VAT 0.16, Type 2, VATRate 0.16, lista de precios "A", ExchangeRate 1. BIND solo recibió lecturas.
Jira-op 8 (01:07:42): FAC-171 borrado (204; GET → 404). Vivió 21 segundos.
⚠️ El evento id 2 quedó Lista en la BD de paputec (su ticket ya no existe). Aceptarlo no crearía nada — la aceptación verifica antes que el ticket siga en Jira — pero aparecerá como pendiente en la campana cuando se publique el modal: descartarlo ahí o limpiarlo al publicar.

4. Lo construido: del ticket a la cotización, a un clic (aac7447, local):

Modal en vivo. Al crearse el ticket, a quien tenga la app abierta le aparece solo un modal con la línea de tiempo y sus tiempos reales (creado en Jira → detectado → vista previa → cotización), los números de la cotización y "Aceptar y crear cotización". Llega por un canal abierto del servidor al navegador (SSE); si el canal no se sostiene, la app consulta cada 4 s. La bandeja de solicitudes también se actualiza sola.
Campana. Si nadie decide en 30 s, el modal vuela con una animación al ícono de la barra superior y queda resaltado, con "Ver detalle" para reabrirlo. El cursor encima pausa la cuenta.
Aceptar es la confirmación humana de ADR-001: se envía a BIND el body exacto del dry-run guardado, una sola vez, con candado en la base para que dos clics o dos personas no creen dos cotizaciones. Si BIND rechaza o no se sabe si creó, queda "sin confirmar" y no se reintenta sola. También se puede "Revisar y editar" (la pantalla de siempre) o descartar.
Modo configurable. En la campana: "Pedir confirmación" (default) o "Crear en automático". El automático nace apagado dos veces: el servidor debe permitirlo (Jira__Webhook__AutoCreateQuoteAllowed, hoy false en paputec) y además elegirlo un usuario con rol de escritura. Tope de monto opcional.
Se agregó deploy/demo-local/: Jira y BIND falsos para ver todo esto sin tocar los reales.

5. Verificación. Backend 170 pruebas en verde (eran 147) y frontend 10. Incluyen: dos aceptaciones simultáneas → una sola cotización; rechazo de BIND → una sola escritura y sin reintento; ticket borrado → nada se escribe; roles; el canal en vivo entrega "Detectado" y luego "Lista"; modo automático con y sin permiso del servidor, con tope y con BIND en solo lectura. Se comprobó que tres pruebas fallan si se rompe el candado a propósito. En un navegador real (Chromium, contra los falsos): el modal apareció 1.3 s después de crear el ticket (1.0 s es la entrega simulada del webhook), "Aceptar" disponible a los 2.2 s, guardado solo a los 30.5 s, modo automático en 2.3 s, y por sondeo (sin canal en vivo) en 4.3 s. Sin errores de consola. Capturas y video: ../planeacion/modal-en-vivo-2026-09-30/.

⚠️ No verificado: nada de esto corre todavía en paputec. Falta ver el canal en vivo a través de Apache (si lo retuviera, entra el respaldo de 4 s) y no se ha creado ninguna cotización real con "Aceptar": hacerlo en producción crea una cotización de verdad en BIND.

ADENDA (30-sep, 6:53 AM) — push, publicación y el modo automático PERMITIDO en el servidor. A la pregunta de qué hacer con lo construido, Johann eligió "Push y publicar, con automático permitido" (la opción decía que el plan del 29-sep pedía autorización escrita de Balam para eso).

Push de aac7447 al repo del cliente y del registro a git.paputec.mx.
Publicación: respaldo manual (balam-20260930-125311.sql.gz), imagen anterior etiquetada balam-api:pre-modal-20260930, deploy.sh completo → API sana, frontend 200. Migración 20260930071635_CotizacionDesdeTicket aplicada. Las rutas nuevas exigen sesión (canal en vivo, campana y aceptar → 401 sin token) y el webhook sigue respondiendo (401 con token malo, 202 con firma válida). El sync corre con la key nueva.
Jira__Webhook__AutoCreateQuoteAllowed=true quedó en /opt/balam/.env (verificado dentro del contenedor). El modo efectivo sigue siendo "Pedir confirmación": la preferencia del tenant nació en false y solo cambia si un usuario con rol de escritura elige "Crear en automático" en la campana (con confirmación en pantalla). Sin tope de monto (AutoCreateMaxSubtotal sin definir). Bind__Mode sigue en Write.
En la campana aparecerá pendiente el evento de prueba FAC-171 (id 2, ticket borrado): aceptarlo no crea nada (responde que el ticket ya no existe); lo correcto es descartarlo.
⚠️ Sigue sin verse en un navegador contra producción (no hay credenciales de la app en esta sesión): falta confirmar el punto verde de la campana (canal en vivo por Apache) y un ticket real de punta a punta con Johann frente a la pantalla.

Lectura estratégica:

La petición literal era "que se cree la cotización automáticamente"; lo que quedó por default es el clic. El plan del 29-sep dejó la creación sin confirmación fuera de alcance hasta tener autorización escrita de Balam y enmendar ADR-001. Johann decidió el 30-sep permitirlo en el servidor (adenda): desde entonces lo único que separa a producción del modo automático es que alguien lo elija en la campana. La autorización de Balam y la enmienda de ADR-001 siguen sin archivarse.

El cuello de botella dejó de ser técnico: con 8 de 17 categorías sin mapear, casi la mitad de los tickets caería en "Faltan datos" aunque todo funcione. Es una tabla de ocho renglones que tiene que dar Balam.

Tiempos reales medidos: Jira entrega el aviso en ~1 s y la vista previa queda en 1–4 s. "En tiempo real" es verdad.

88 · Sep 30, 2026 — 7:50 AM y 8:30–9:40 PM · Producción + desarrollo · El puente de PREFACTURA queda encendido en producción; lo que salió al probarlo con Pedro (totales en cero, estados atrasados, "servicios", Arturo) y cuatro bugs reales detrás ⭐🔥

Contexto: tras la sesión con Pedro de las 7:26 AM (wizard del FAC-173 con la generación de prefactura "DESHABILITADA"), Johann pidió a las 7:50: "Activa la creación de prefactura desde producción. También estos botones de 'Generar prefactura' desde /cotizaciones no lleva a ninguna parte y parece no funcionar. El campo de 'Total' no se está trayendo los datos. También, cuando se trae un ticket de Jira no se está trayendo el campo de 'servicios' por lo que marcaba que faltaba un campo. También, de la lista de personas para autorizar quita a arturo r, ya no trabaja en balam." La sesión quedó en pausa de ~8:30 AM a ~8:30 PM. Evidencia: commit local 597c8a2 del repo del cliente (sin push ni despliegue), capturas en ../planeacion/prefactura-desde-produccion-2026-09-30/, .env de paputec y la BD de producción.

1. Lo que se cambió en producción (sin desplegar código):

8:02 AM — Puente a la web app de BIND encendido: Bind__Ui__Enabled=true y Bind__Ui__Mode=Write en /opt/balam/.env, API reiniciado. Con esto el wizard deja de mostrar la tarjeta "DESHABILITADA" (409 del API público) y ofrece la tarjeta del puente. ⛔ Las credenciales del usuario CTO NO se escribieron: el control de permisos de Claude Code bloqueó escribir ese secreto en el servidor (el mismo bloqueo que la API key en la madrugada, que se destrabó con una autorización explícita de Johann) y no se intentó por otra vía. Mientras no estén, la tarjeta pide pegar la cookie de la sesión de BIND (F12 → Network → Cookie) — camino funcional pero incómodo. Bind__Mode sigue en Write y Jira__Mode en ReadOnly.
8:04 AM — "Servicio de Enlace" mapeado al ítem 106 (Emision__ServicioPorCategoria__ServicioDeEnlace=106), reinicio. Esto era lo de "no se trae el campo de servicios": el campo sí llegaba; FAC-172 y FAC-173 traían la categoría «Servicio de Enlace» y en BIND el ítem se llama «Servicios de Enlace» (código 106, el que Pedro eligió a mano en los dos). Con la radiografía del formulario (10 campos obligatorios, 17 clientes, 17 categorías) contra el catálogo de BIND (11 ítems, códigos 100–110): 17/17 clientes resuelven; 10/17 categorías resuelven y las otras 7 no tienen ítem equivalente en BIND — PMO, Mesa de Servicio (SDM), Soporte L1, L2, Gestión de Incidentes, de Cambios y de Capacidad: necesitan que Balam diga a qué código van.
8:14 AM — Relectura completa de cotizaciones: comparando la BD contra la lista completa de BIND (117 cotizaciones) 11 aparecían "Activas" en la plataforma y BIND las tenía canceladas o surtidas (entre ellas #1079, #1067–#1064 y #1027–#1029 de la captura de Johann), con el botón "Generar prefactura" ofrecido sobre ellas. Se puso en null el cursor del sync de cotizaciones (SyncCheckpoints) para que el siguiente ciclo releyera todo; a las 8:35 PM: 0 desfasadas, 2 activas según ambos. Causa: el sync barría solo una ventana por fecha de creación y nunca volvía a ver las viejas.

2. Cuatro bugs reales encontrados al investigar (todos con prueba que los reproduce):

"Total" en cero al crear una cotización. El detalle de BIND (GET /api/Quotes/{id}) devuelve Total y Subtotal siempre en cero (verificado en 8 cotizaciones reales, MXN y USD); la plataforma guardaba ese cero al crear (ops #154, #157, #159: total: 0.0) y la pantalla, el wizard y Cotizaciones mostraban $0.00 hasta el siguiente sync (15 min). Por eso Pedro tuvo que capturar el precio a mano en el paso 3. Ahora los importes salen de OriginalCurrencySubtotal (moneda del documento) + impuestos (vienen en MXN base, se dividen entre el TC); si la lectura falla, de lo enviado.
Totales en dólares mostrados en pesos. La lista de BIND trae Total en MXN base y TotalOriginalCurrency en la moneda del documento; el sync guardaba el primero con la etiqueta de la moneda real: 71 de las 117 cotizaciones (todas las de USD) se veían con el monto en pesos y "USD" al lado. Ahora se guarda el de la moneda del documento, y una columna nueva Subtotal (migración aditiva) alimenta el wizard, que cobraba el IVA dos veces (partía del total con IVA como precio unitario).
El post-proceso del puente tronaba después de crear la prefactura — muy probablemente el 500 del 29-sep que "escondió" la 2467: al guardar el registro local, CFDIPaymentTerm llega como "PAGO EN UNA SOLA EXHIBICIÓN" (27 caracteres) y la columna admite 10; y si el API aún no muestra la venta, la fecha de respaldo iba en UTC a una columna sin zona. Resultado real: la prefactura existía en BIND pero sin vínculo con el ticket ni cotización surtida en la plataforma. Corregido y cubierto por PrefacturaUiEndpointTests (11 pruebas contra una web app de BIND falsa).
Duplicados posibles: el puente comprobaba el estado de la cotización solo en la BD (atrasada). Ahora se lo pregunta a BIND al momento (QuoteDetail.Status: surtida o cancelada → 409 y corrige la BD) y, tras un guardado aceptado, bloquea 10 minutos un segundo envío de la misma cotización (el API tarda más de un minuto en ver lo que la web app crea).

3. Hallazgos con fuente primaria: el app.js público de la web app de BIND muestra que la respuesta de AddInvoiceTransaction trae InvoiceId y Payments[] y que para una venta no fiscal la pantalla solo redirige a /Sales/InvoiceDetails?ID=… — el POST único es la operación completa; el lector del GUID ahora prioriza InvoiceId. Un GUID inexistente responde 200 con cuerpo null (no 404) en Quotes/{id} e Invoices/{id}. CurrencyName del detalle de venta sí es el código de 3 letras. La prefactura 2467 ya aparece Cancelada en BIND y las cotizaciones 1084 y 1085 (de la sesión con Pedro) también se cancelaron en BIND durante el día.

4. Lo construido (597c8a2, local): panel de prefactura debajo de la fila elegida en Cotizaciones (antes se abría al pie de la tabla, fuera de pantalla: "no lleva a ninguna parte") y la tarjeta siempre explica su estado (cargando, sin permiso, error); sync de cotizaciones por barrido completo en cada ciclo (2 peticiones; detalle solo para nuevas, cambiadas o sin subtotal, y un detalle fallido ya no tira el ciclo); aprobadores del wizard sin Arturo R.; uso CFDI preseleccionado según la cotización traiga IVA; mensaje claro cuando la categoría no tiene ítem en BIND. Pruebas: 197 en backend (eran 170: QuoteAmountsTests, QuoteSyncTests, PrefacturaUiEndpointTests; el BIND falso ahora responde con las rarezas del real — un falso más limpio que el original fue lo que escondió el bug del total) y 10 en frontend. Se comprobó que las pruebas fallan al reintroducir cada bug. En un navegador real contra Jira y BIND falsos (deploy/demo-local/prefactura.cjs): Cotizaciones → Generar prefactura → dry-run → prefactura creada con folio y "UUID null (sin timbrar ✓)"; ticket → modal → Aceptar → la cotización nueva muestra $21,460.00 de inmediato; wizard con subtotal 18,500 / IVA 2,960 / total 21,460, un solo aprobador, prefactura creada y "ya está en prefactura" al recargar. Sin errores de consola.

⚠️ No verificado: nada de lo construido corre todavía en paputec (producción sigue con el código de las 6:53 AM más los dos cambios de .env). Ninguna prefactura real se ha creado desde producción. Entre 7:28 y 7:43 AM otra sesión (no esta) tocó Seed__Admin__Password en el .env de producción y reinició el API dos veces; quedó retirado.

Lectura estratégica:

Los cuatro bugs eran invisibles con un BIND falso "limpio". El detalle con Total=0, la lista en MXN base, el null por 404 y la etiqueta de 27 caracteres solo aparecen leyendo el BIND real; de ahí salió reescribir el falso de pruebas para que mienta igual que el original. Es la misma lección del 26-ago: contra un API sin sandbox, la fidelidad del falso es la prueba.

El puente está encendido pero sin credenciales: la activación completa depende de una decisión de Johann (escribir las del usuario CTO en el servidor, o pegarlas él). Hasta entonces, cada prefactura desde producción requiere pegar la cookie de BIND.

Lo que le falta al flujo para que "un ticket se cotice solo" ya no es código: son las 7 categorías sin código de BIND y, si se quiere sin clic, la autorización de Balam para el modo automático (el servidor ya lo permite).

Resumen ejecutivo del hilo (para contexto rápido)

Estado actual (al 30-sep-2026 — Etapa 2 en producción provisional)

La plataforma está publicada en https://paputec.mx/balam/ desde el 3-sep (ambiente provisional propio; Azure sigue sin entregarse, #74/#76) y Balam ya la opera en sesiones acompañadas: cotizaciones reales desde tickets, individuales y en lote (#77–#79). Producción corre con Bind__Mode=Write por decisión de Johann del 30-sep (#85). La cadena ya llegó a la prefactura: por el API público es imposible — false = remisión, true = CFDI timbrado; incidente 2386 del 26-ago (#70), confirmado con el SDK oficial (#83) — pero el puente a la UI de BIND (BindUiClient, Generar Venta → Prefactura, con el login web que Balam entregó el 29-sep) creó ese mismo día la primera prefactura real, folio 2467 (#84); desde el 30-sep el puente está encendido en paputec (sin credenciales en el servidor todavía: pide la cookie de BIND) (#88). Y la cadena ya arranca sola: desde el 30-sep el webhook de Jira avisa a producción cada ticket creado en FAC (#85). La vista previa automática de la cotización ("Lista para revisar" en la bandeja) también quedó publicada el 30-sep (#86); la confirmación sigue siendo humana (ADR-001). La API key del usuario cto entró a producción el 30-sep y el sync volvió; la vista previa se validó contra Jira y BIND reales con FAC-171 (#87). El modal en vivo con "Aceptar" y la campana quedaron publicados el 30-sep, con el modo automático permitido en el servidor pero sin elegir (#87). Al probarlo con Pedro el 30-sep salieron totales en cero, cotizaciones con estado atrasado y una categoría sin mapear; detrás había cuatro bugs reales (importes del detalle de BIND siempre en cero, USD mostrado en pesos, el post-proceso del puente tronando, duplicados posibles), corregidos y probados en el commit local 597c8a2 (#88). Siguiente hito: publicar 597c8a2, decidir las credenciales del usuario CTO en el servidor, primera prefactura real desde producción con Johann frente a la app, y que Balam dé el código de BIND de las 7 categorías de servicio que no resuelven. Seguimiento con Pedro (sesiones "Seguimiento PAF" a las 7:00 am o 1:00 pm; informes de Read AI de Noé). Horas al 16-sep: 94.58 h; Excel de avance en Google Sheets (#82). Abiertos: credenciales CTO en producción y publicación de 597c8a2, archivar la autorización de Balam y enmendar ADR-001 antes de que alguien elija el modo automático (el servidor ya lo permite), prefactura 2467 (ya Cancelada en BIND) y cotizaciones 1084/1085 por confirmar con Balam, cancelación SAT de la 2386, remisiones 1000/1001, Azure, a quién se reportan horas, y el error al cargar la solicitud al crear cotización visto el 29-sep.

Datos duros confirmados por Balam

BIND ERP: API existe y es viable (confirmado 25-may). Límite 20K req/día. PAC para CFDI integrado en BIND.
BUK: ✅ tiene API (confirmado 27-may por Pedro). No es prioridad para MVP — habilita Fase 2 post-MVP. Link pendiente de recibir.
Bancos: 3 bancos, solo PDFs. Banco americano = IBC Bank Texas (confirmado en llamada del 19-may).
Sandbox: solo producción (BIND y BUK).
Volumen: 45 colaboradores + 5 freelancers, ~55 facturas/mes de 4–6 clientes (el mayor exige 1 factura por colaborador, ~40) — actualizado 6-jul.
EUR: fuera del MVP; solo MXN + USD.
Lista blanca cobranza: ~~ACUNTIA + top 3, configurable~~ → ELIMINADA (6-jul): Ara decidió recordatorios a todos los clientes morosos, sin excepciones. (La capacidad configurable se conserva, hoy vacía.)
Cotización BIND obligatoria (6-jul): todo lo que se facture parte de una cotización en el ERP (requisito fijado por Ara).
Flujo actual: Jira ITSM mandatorio (~1 mes) → validación administración (Arturo) → prefactura BIND → CFDI → envío por correo con particularidades por cliente (Excel pendiente de Ara/Arturo).
Cobranza actual (mapeada 7-jul): el cliente avisa el pago por correo/mensaje (estado de cuenta) → el despacho contable registra los pagos en BIND uno por uno → Power BI de cartera (desactualizado). Se concilia por folio (la referencia no distingue facturas); los fees generan diferencias contra el total. Quieren recordatorios proactivos (1–5 días de vencimiento).
Book = SaaS (no interno).
Jira: solo gestión de proyectos con clientes.
Nube preferida: Azure.
Contacto operativo durante MVP: Noe + gerente administrativo.

Pendientes que Ara (Araceli) debía responder

Banco americano específico (resuelto en llamada: IBC Texas).
Tax compliance para clientes Texas (resuelto en llamada: estándar).
Tickets físicos en pagos con tarjeta.
Guía de marca / assets.

Señales clave del CTO

Llamada del 19-may (transcript aparte): Noe pidió textualmente "no le queremos estar poniendo estrellitas al pino, nada más estrictamente lo que se necesita". Foco = facturación + conciliación.
Correo del 25-may: Noe pide explícitamente que la propuesta se recorte a "solo ERP BIND" primero, dejando bancos/conciliación para fase posterior.

Estado actual (al 15-jul-2026 — Etapa 0 en validación, Etapa 1 iniciada en local)

Contrato firmado, kickoff y Discovery completos. El prototipo de la Etapa 0 fue entregado por correo el 10-jul y Balam lo revisa internamente. La sesión formal de validación quedó confirmada para el jueves 23-jul a las 7:00 pm.

Johann inició en local las actividades independientes de Etapa 1. La sesión para cerrar dudas y reglas quedó el miércoles 22-jul con Arturo y la CEO. Deben resolverse alta de cliente nuevo, tratamiento del fee, particularidades de envío y si la automatización Jira → cotización BIND se incorpora al alcance.

Accesos: token BIND y manual de marca recibidos; repositorio GitHub autorizado por Noé y en proceso de invitación para Johann-28; Azure programado para la semana del 21-jul; CI/CD y secretos separados para el 24-jul. Jira técnico no se necesita salvo que se apruebe la integración automática Jira→BIND.

Comercial: propuesta v1.2 recibida por Erika, pero la confirmación para emitir la factura de 30 h sigue pendiente mientras Noé y la CEO están fuera del país. No hay rechazo ni pago vencido.

Seguimiento: se abrió control local de horas en ../planeacion/Seguimiento-horas.csv. El Excel de cobranza/días vencidos queda condicionado a la retroalimentación del prototipo; el Excel de particularidades de envío sigue pendiente de Balam.

Términos vinculantes del contrato: sin anticipo + firma previa (cumplida) · facturación semanal los viernes por horas efectivamente trabajadas, pago a 30 días · garantía 45 días · alcance MVP BIND-first · arranque condicionado a accesos + API de BIND con lectura/escritura.

Calendario vigente: Etapa 1 en local desde 13-jul · repo 15–16 jul · Azure semana del 21-jul · sesión de reglas 22-jul · validación prototipo 23-jul · CI/CD y secretos 24-jul. Etapas 2–3 se afinan después de esas validaciones.

Acciones inmediatas de Johann: capturar/reconstruir horas reales; aceptar y validar el repositorio; continuar backend local; preparar las preguntas del 22-jul; cerrar hallazgos/ADRs tras las sesiones; mantener lista la factura sin emitirla todavía.

En espera de Balam: invitación al repo, acceso Azure, flujo Jira para horas, Excel de particularidades de envío, definiciones de Arturo/CEO y confirmación para emitir la primera factura.

Pendiente menor: (opcional) pedir 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).

Conciliación: sigue como posible primer alcance si el Discovery libera horas (mini-scope + estimación al cierre del Discovery).

257 KiB Raw Blame History Unescape Escape

REGISTRO · Bitácora de comunicaciones — Proyecto Balam

0 · Abr 8–28, 2026 · Correo · Prehistoria comercial — cómo se fijó la tarifa por hora

1 · Apr 30, 2026 — 4:38 PM · Erika Chavez → Johann

2 · May 4, 2026 — 3:30 PM · Johann → Erika (CC Noe, Ara)

Integraciones

Facturación

Cobranza

Datos y sistemas

Operación

Infraestructura y diseño

3 · May 4, 2026 — 7:59 PM · Noe Rocha → Johann (respuestas inline)

3a · May 6, 2026 — Araceli Sánchez → Johann · respuestas "en verde"

3b · May 6, 2026 — Johann → Balam · acuse

4 · May 8, 2026 — 5:06 PM · Johann → Noe

5 · May 11, 2026 — 5:47 PM · Noe → Johann

6 · May 12, 2026 — 10:27 PM · Johann → Noe

7 · May 16, 2026 — 10:32 AM · Noe → Johann

7a · May 16, 2026 — Johann → Noe · confirma sesión + comparte teléfono

8 · May 25, 2026 — 10:41 PM · Noe → Johann

9 · May 27, 2026 — AM · Pedro (desarrollador, Balam) → Johann ⭐ (último mensaje)

10 · May 29, 2026 — 2:44 PM · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta

11 · Jun 2, 2026 — 5:33 PM · Pedro → Johann, Noe (CC Ara, Erika)

12 · Jun 2, 2026 — 9:39 PM · Johann → Pedro, Noe (CC Ara, Erika)

13 · Jun 3, 2026 · Pedro → Johann, Noe (confirmación + liga Teams)

14 · Jun 4, 2026 — 7:00 AM · Llamada de revisión de propuesta ⭐

15 · Jun 8, 2026 — 6:15 PM · Correo · Noe → Johann (CC Ara, Erika, Pedro) · aclaraciones y preguntas

16 · Jun 10, 2026 — 6:11 PM · Johann → Noe (CC Ara, Erika, Pedro) · respuesta + propuesta v1.1

17 · Jun 16, 2026 — 3:35 PM · Noe → Johann, Pedro (CC Ara, Erika) · luz verde ⭐

18 · Jun 25, 2026 — Balam (vía Paola, RH) → Johann · contrato de servicios para firma

19 · Jun 26, 2026 — WhatsApp Johann ↔ Paola (RH) · ajustes finales y FIRMA del contrato ⭐

20 · Jun 29, 2026 — WhatsApp Erika → Johann · arranque del plan de actividades ⭐

21 · Jun 29–30, 2026 — WhatsApp Johann ↔ Erika · plan de actividades entregado + kickoff agendado ⭐

22 · Jul 1, 2026 — 7:00 AM · Llamada · Kickoff del proyecto ⭐

23 · Jul 1, 2026 — 7:33 AM · Correo · Pedro → Johann · manual de imagen corporativa

24 · Jul 1, 2026 — WhatsApp Erika ↔ Johann · agenda la sesión "Proceso actual de facturación y cobranza" (lunes 6-jul)

25 · Jul 2, 2026 — 4:18–4:41 PM · WhatsApp Erika ↔ Johann · agenda/materiales para la sesión del 6-jul

26 · Jul 2, 2026 — 5:39 PM · Correo · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta v1.2

27 · Jul 6, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de facturación y cobranza ⭐

El proceso actual, paso a paso

Dolores (en palabras de Ara, dirección general)

🔄 Cambios de reglas de negocio (decididos en la sesión)

28 · Jul 6, 2026 — 9:01 AM–12:40 PM · WhatsApp Erika ↔ Johann · token de BIND ENTREGADO ⭐

29 · Jul 6, 2026 — 12:38 PM · Correo · Pedro → Johann (CC Noe, Erika) · entrega formal del token de BIND ✅

30 · Jul 6, 2026 — 3:01 PM · WhatsApp Johann → Erika · propone sesión de cobranza (martes 7-jul)

31 · Jul 6, 2026 — 4:33 PM · Correo · Noé → Johann, Pedro (CC Erika) · salvaguardas sobre el token ⚠️

31a · Jul 6, 2026 — 4:46 PM · Correo · Johann → Noé, Pedro (CC Erika) · respuesta formal con las salvaguardas ✅

32 · Jul 6, 2026 — tarde · Validación técnica de la API de BIND con la cuenta real ⭐ ✅

33 · Jul 6, 2026 — 4:34–5:03 PM · WhatsApp Erika → Johann · confirma operar solo-lectura (eco del correo de Noé)

34 · Jul 6, 2026 — 6:36–6:40 PM · WhatsApp + convocatoria Outlook/Teams · confirma sesión de cobranza (martes 7-jul) ⭐

35 · Jul 7, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de cobranza (sin grabación) ⭐

36 · Jul 7, 2026 — 12:27 PM · WhatsApp Erika → Johann · seguimiento del pendiente de BIND (¿probar escritura?)

37 · Jul 7, 2026 — 3:56–5:49 PM · WhatsApp Erika ↔ Johann · seguimiento al usuario de lectura de BIND

38 · Jul 8, 2026 — 10:09 AM–10:55 AM · WhatsApp Erika ↔ Johann · datos ficticios para los Exceles de cobranza

39 · Jul 9–10, 2026 · WhatsApp Erika ↔ Johann · avance de Fase 0 + prototipo sin sesión de validación agendada

40 · Jul 10, 2026 · Correo · Johann → Erika, Noé (CC Pedro) · entrega del prototipo Etapa 0 ⭐

40a · Jul 10, 2026 · Correo · Reacción de Balam al prototipo: acuse de Erika y Noé fuera de oficina

41 · Jul 13, 2026 · WhatsApp Erika ↔ Johann · continuidad de Etapa 1, sesión con Arturo y factura de 30 h

42 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · dos sesiones confirmadas para 22–23 jul

43 · Jul 14–15, 2026 · WhatsApp Erika ↔ Johann · ajuste de accesos y repositorio GitHub autorizado

44 · Jul 14, 2026 · WhatsApp Erika ↔ Johann · Excel de días vencidos condicionado a validación

45 · Jul 15, 2026 · Gestión interna · se inicia control local de horas

46 · Jul 16, 2026 · WhatsApp · Erika ↔ Johann · invitación Git, procedimientos y solicitud de avance

46a · Jul 16, 2026 — 1:01 PM · Correo · Erika → Johann · procedimientos de carga de facturas (5 portales) 📎

47 · Jul 19, 2026 · Gestión interna · demo del 18-jul no realizada; entorno local montado en la Mac

48 · Jul 19, 2026 — noche · Desarrollo · B0+B1 completados (adelantados del lunes) + Scalar UI

49 · Jul 19, 2026 — noche · Desarrollo · B2 completado (adelantado del lunes): auth JWT + policies + bitácora

50 · Jul 19, 2026 — noche · Desarrollo · B3 completado: sync de clientes CONTRA PRODUCCIÓN + hallazgo de datos

51 · Jul 21, 2026 · WhatsApp Erika ↔ Johann · estimación Jira→BIND comunicada (10 h) y alcance confirmado por Erika ⭐

52 · Jul 21, 2026 — noche · Desarrollo · B4 completado: sync de facturas/cotizaciones + cartera por moneda + SYNC HISTÓRICO ⭐

53 · Jul 21, 2026 — noche · Desarrollo · B6: RLS real de Postgres (contractual) — código completo; verificación local pendiente de rol de app

54 · Jul 22, 2026 — 7:00 AM · Llamada · Sesión de reglas Etapa 1: alta de clientes, fee bancario y flujo Jira ⭐

55 · Jul 24, 2026 — 11:00 AM · Llamada · Validación del prototipo Etapa 0 — APROBADO (queda 1 definición de proceso) ⭐

56 · Jul 27, 2026 — mañana · Llamada · Sesión API de Jira con Pedro: token comprometido y bandeja "Facturación" (FAC) identificada ⭐

57 · Jul 21–27, 2026 · WhatsApp Erika ↔ Johann · coordinación de sesiones, envío del flujo de facturación y reagenda 23→24 jul

57a · Jul 22, 2026 — 2:24 PM · Correo · Erika → Johann · flujo de facturación de Jira (diagrama) 📎

58 · Jul 27–28, 2026 · WhatsApp Erika ↔ Johann · avance de Etapa 1 entregado, Excel de horas para FACTURACIÓN y Jira aún sin licencia ⭐

59 · Jul 28–29, 2026 · WhatsApp Erika ↔ Johann · requisitos Azure escalados a Noé, propuesta v1.3 + Excel de etapas entregados, seguimiento API Jira ⭐

59a · Jul 29, 2026 · Correo · Erika ↔ Johann · seguimiento a la API de Jira en el hilo de Pedro

60 · Jul 29–30, 2026 · Correo · Johann → Noé (CC Ara, Erika, Pedro) · propuesta v1.3 (Jira→BIND) enviada y APROBADA por el CTO ⭐

257 KiB

Raw Blame History

73 · Ago 24, 2026 — 7:00 AM · Llamada · "Seguimiento - PAF" · Validación cotización → prefactura (MXN/USD, IVA 16 %/0 %) y la primera semántica dura: `IsFiscalInvoice=false` = REMISIÓN

80 · Sep 9, 2026 — 1:00 PM · Llamada · "Seguimiento PAF - Prefactura" · Araceli crea una prefactura en vivo con "Generar venta" y aparece el endpoint interno: `InvoiceDetails` ⭐