# PENDIENTES — acciones abiertas

Acciones vivas del proyecto. Formato: `[ ]` abierta · `[x]` cerrada (no se borran, dejan rastro). Cada una con responsable y, si aplica, fecha. Ver contexto en [REGISTRO.md](REGISTRO.md).

_Última actualización: **2026-10-02** — ⭐ **prefacturas en lote** (Cotizaciones y bandeja → una prefactura por cotización, en serie; timbrado también desde el detalle de la factura), en el commit local `73d1c2a`, sin publicar ([REGISTRO #90](REGISTRO.md)). Anterior: **2026-10-01, madrugada** — ⭐🔥 **el TIMBRADO entra a la plataforma** (prefactura → CFDI por el puente, con dry-run, palabra TIMBRAR, verificación por lectura y bloqueo de reenvío), la cadena completa queda revisada (estado incierto de los POST cerrado, consecutivo sin la serie B, uso CFDI del mismo cliente), probada (212 + 10 pruebas, recorrido completo en navegador) y **publicada** (`f5b3743`) para la **prueba completa del 1-oct con Balam**; guion en `planeacion/` ([REGISTRO #89](REGISTRO.md)). Anterior: **2026-09-30, noche** — 🔥 **el puente de prefactura queda ENCENDIDO en producción** (sin credenciales del usuario `CTO` en el servidor: bloqueo del control de permisos, decisión de Johann pendiente), «Servicio de Enlace» mapeado al 106 y 11 cotizaciones con estado atrasado corregidas; lo que Pedro vio a las 7:26 (totales en cero, botones que "no llevan a ninguna parte", "servicios", Arturo) tenía detrás **cuatro bugs reales**, corregidos, probados (197 + 10 pruebas) y **publicados en paputec a las 9:44 PM** (`597c8a2`, migración `QuoteSubtotal`); las credenciales del usuario `CTO` entraron al servidor a las 9:41 PM con autorización de Johann: el puente queda completo ([REGISTRO #88](REGISTRO.md)). Anterior: **2026-09-30** — ⭐ el webhook de Jira FAC queda **en producción (paputec)**: publicado, secreto nuevo, webhook id 1 movido y prueba de punta a punta con FAC-170 en 1.05 s ([REGISTRO #85](REGISTRO.md)); y la vista previa automática de la cotización queda **publicada** ([#86](REGISTRO.md)). 🔥 **La API key de `cto` ya está en producción y el sync volvió**; la vista previa se validó contra el BIND real (FAC-171) y el **modal en vivo con "Aceptar"** quedó **publicado** a las 6:53 AM, con el modo automático permitido en el servidor pero sin elegir ([#87](REGISTRO.md)). Además, fusión de las dos sesiones paralelas del 29-sep: la del webhook pasa a ser el [#84](REGISTRO.md) (nació como #71 en la otra máquina). Anterior: **2026-09-29** — ⭐ Balam entrega **login web a BIND** con permisos de prefactura; endpoint interno de la UI confirmado (*Generar Venta → Prefactura*, petición `InvoiceDetails`) y el modelo de dos endpoints corroborado con el SDK oficial ([REGISTRO #83](REGISTRO.md)). **Huecos de registro cerrados:** las sesiones del 21-ago al 10-sep se reconstruyeron desde el buzón ([#71](REGISTRO.md)–[#82](REGISTRO.md)). Anterior: **2026-09-15** — corte de horas 10-ago→15-sep reconstruido y huecos de registro listados (seis sesiones sin bitácora). Anterior: **2026-08-21, mediodía** — ⭐ primera cotización real emitida (folio 1026; la 2.ª, corregida, pendiente de confirmar). Anterior: **2026-08-20, noche.** Cruce completo del buzón contra la bitácora (MCP ms365): se incorporaron 9 comunicaciones faltantes y se corrigieron 2 errores de registro. **Hay sesión mañana viernes 21-ago, 7:00 am** con Noé, Ara y Pedro sobre el formulario modificado y `FAC-106`. Ver [REGISTRO #65](REGISTRO.md)–[#68](REGISTRO.md)._

## ⭐ 2-oct — prefacturas en lote ([REGISTRO #90](REGISTRO.md))

- [ ] 🚀 **Johann — decidir push + publicación de `73d1c2a`** (prefacturas en lote + timbrado en el detalle de la factura). Sin migración; mismo protocolo (respaldo, imagen de rollback, `deploy.sh`).
- [ ] 📝 **Registrar el resultado de la prueba completa del 1-oct** (¿se timbró? folio, UUID, qué devolvió `EmitCFDI`, qué se canceló) en el #91.
- [x] ~~🔧 Deuda: la tarjeta de timbrado no vive aún en el detalle de la factura~~ → **HECHO el 2-oct** (`73d1c2a`): `/facturas/:id` muestra la tarjeta para prefacturas.

## 🔥🔥 1-oct — PRUEBA COMPLETA con Balam: ticket → cotización → prefactura → CFDI ([REGISTRO #89](REGISTRO.md), [guion](../planeacion/Guion-prueba-completa-2026-10-01.md))

- [ ] 🔥 **Johann — seguir el guion** durante la llamada: nadie en BIND como `CTO`; ticket con cliente de BIND y una de las 10 categorías mapeadas; monto reconocible; leer el **método de pago (PUE/PPD)** en el dry-run del CFDI antes de teclear TIMBRAR; acordar quién cancela el CFDI de prueba.
- [ ] 🔴 **Primer `EmitCFDI` contra el BIND real** — lo único no verificado: la forma de la respuesta y los textos de rechazo del PAC. Anotar en la bitácora lo que devuelva (queda en `WriteOperations.ResultJson`).
- [ ] 📋 **Pedir a Balam en la llamada:** los códigos de BIND de las 7 categorías sin mapear y si quieren el **modo automático** (sin clic) — con autorización escrita (ADR-001).
- [ ] 🔧 **Al cerrar la prueba:** cancelar el CFDI en BIND (Balam) → «Verificar» en la plataforma → *Cancelada*; registrar folio, UUID y tiempos en el #90.
- [ ] 🧹 Imagen de rollback `balam-api:pre-timbrado-20261001` en paputec: borrarla con las demás `pre-*` cuando la versión lleve unos días estable.
- [ ] 🧹 Evento de prueba **FAC-171** (id 2, `Lista`, ticket borrado): descartarlo desde la campana antes de la llamada para que no estorbe.
- [x] ~~🔧 Deuda: la tarjeta de timbrado no vive aún en el detalle de la factura (`/facturas/:id`)~~ → **HECHO el 2-oct** ([#90](REGISTRO.md)).
- [ ] 🔧 Deuda: el método de pago de la prefactura lo decide BIND (PUE) aunque el cuerpo lleve PPD; si Balam quiere PPD por default, hay que entender qué campo manda (`PaymentMethodCFDI33`/`PaymentTermType` del cliente) o editar la prefactura en BIND antes de timbrar.

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

- [x] ~~🔑🔴 **Johann — credenciales del usuario `CTO` de BIND en `/opt/balam/.env`**~~ → **HECHO el 30-sep, 9:41 PM, con autorización explícita de Johann** (adenda del [#88](REGISTRO.md)): las tres variables en el `.env` (root 0600), huella verificada en el contenedor, API sana. El puente ya entra solo a la web app; la cookie queda como respaldo.
- [x] ~~🚀 **Johann — decidir push + publicación de `597c8a2`**~~ → **HECHO el 30-sep, 9:44 PM** (adenda del [#88](REGISTRO.md)): push a GitHub y a git.paputec.mx, respaldo `balam-20261001-034359.sql.gz`, imagen `balam-api:pre-prefactura-20260930`, migración `QuoteSubtotal` aplicada, bundles nuevos servidos. Primer ciclo del sync: 50 subtotales; los 67 restantes en los dos ciclos siguientes.
- [ ] 🧹 Imagen de rollback `balam-api:pre-prefactura-20260930` en paputec (ya son cuatro `pre-*-20260930`): borrarlas cuando la versión lleve unos días estable.
- [ ] 🧪 ~~**Primera prefactura real desde producción**, solo con Johann frente a la app~~ → **pasa a la prueba completa del 1-oct** (bloque de arriba): cotización → prefactura → CFDI en una sola sesión con Balam.
- [x] ~~📋 Mapear «Servicio de Enlace»~~ → **HECHO el 30-sep, 8:04 AM:** `Emision__ServicioPorCategoria__ServicioDeEnlace=106` en producción. Era la causa de "faltaba el campo de servicios" en FAC-172/173 (el campo sí llegaba; faltaba el mapeo). Quedan **7 categorías** sin ítem en BIND (bloque del #87, abajo).
- [ ] 📋 **Confirmar con Balam** que la prefactura **2467** aparezca Cancelada por decisión suya (así se ve en BIND el 30-sep) y que las cotizaciones **1084/1085** de la sesión con Pedro se cancelaron a propósito.
- [ ] ⚠️ **Una sola sesión operando el servidor.** Entre 7:28 y 7:43 AM otra sesión tocó `Seed__Admin__Password` en el `.env` de producción y reinició el API dos veces mientras esta sesión diagnosticaba. Dos manos en `/opt/balam/.env` al mismo tiempo pueden pisarse cambios.
- [ ] 🧹 Las 11 cotizaciones que la plataforma tenía "Activas" y BIND no ya quedaron corregidas (cursor en null + relectura, 0 desfasadas a las 8:35 PM); con `597c8a2` publicado el sync barre todo cada ciclo y no vuelve a pasar.

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

- [x] ~~🚀 **Johann — decidir push + publicación del modal en vivo**~~ → **HECHO el 30-sep, 6:53 AM** (`aac7447`, migración aplicada). Falta ver el punto de la campana en un navegador: verde = canal en vivo por Apache; ámbar = respaldo cada 4 s.
- [ ] 🧪 **Validar en producción con Johann frente a la app:** ticket de prueba (con autorización) → modal en vivo → "Aceptar". ⚠️ Eso crea una **cotización REAL en BIND**: usar un monto de prueba reconocible y cancelarla después.
- [ ] 🔴 **Modo automático: el servidor ya lo PERMITE** (`Jira__Webhook__AutoCreateQuoteAllowed=true`, decisión de Johann del 30-sep) pero nadie lo ha elegido: producción sigue pidiendo confirmación. Antes de que alguien lo elija en la campana: **archivar la autorización escrita de Balam, enmendar ADR-001** y fijar un tope (`Jira__Webhook__AutoCreateMaxSubtotal`, hoy sin definir). Para volver a prohibirlo: `false` en el `.env` y `up -d api`.
- [ ] 📋 **Pedir a Balam (Pedro) el código de BIND para 7 categorías** del combo Servicio/Producto que no resuelven y caen en "Faltan datos": Gestión de Proyectos Senior / PMO · Gestión de Mesa de Servicio (SDM) · Soporte Especializado L1 · L2 · Gestión de Incidentes · de Cambios · de Capacidad. Se cargan en `Emision__ServicioPorCategoria__…` del `.env`. *(30-sep: «Servicio de Enlace» → 106 ya está en producción, [#88](REGISTRO.md); 10 de 17 categorías y 17 de 17 clientes resuelven. Las 7 restantes no tienen ítem equivalente en el catálogo de BIND de 11 ítems: necesitan un ítem nuevo o una decisión de Balam.)*
- [ ] 🧹 **Evento de prueba FAC-171** (id 2 en paputec, `Lista`, ticket ya borrado): descartarlo desde la campana (sigue ahí al 1-oct).
- [ ] 🧹 La API key anterior (usuario `arturo`) quedó **comentada** en `/opt/balam/.env` para rollback: borrarla cuando la de `cto` lleve unos días estable.
- [ ] 👀 En esta Mac sigue corriendo desde el **3-sep** una instancia local del API (puerto 5078) y del frontend (4200), con el código de ese día: no se tocó. Apagarla o reiniciarla cuando convenga.
- [ ] 🔧 La tabla de la bandeja se sale del ancho a 1440 px (la columna BIND y los botones quedan cortados); ya pasaba antes del chip nuevo.
- [ ] 🔧 Deuda del modal: enseña el resumen de la cotización, no el JSON del dry-run (está en `WriteOperations`); agregar "ver el body" si Balam lo pide. El canal en vivo es en memoria: vale para una sola instancia del API.

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

- [x] ~~🔧 **Siguiente meta:** con cada `JiraTicketEvent` verificado, armar la vista previa (dry-run) de la cotización y marcar el ticket "lista para revisar" en la bandeja.~~ → **CONSTRUIDA el 30-sep** (commits locales `1c37eaa` y `287cb65`, 147 pruebas en verde, [#86](REGISTRO.md)). La confirmación sigue siendo humana (ADR-001).
- [x] ~~🚀 **Johann — decidir push + publicación de la vista previa automática**~~ → **HECHO el 30-sep por orden de Johann:** push de `1c37eaa` + `287cb65` y publicación en paputec (migración aplicada, trabajador activo, FAC-170 → `NoAplica`). Ver adenda del [#86](REGISTRO.md).
- [x] ~~🔥🔑 **Poner la API key del usuario `cto` en `Bind__ApiKey` de `/opt/balam/.env`**~~ → **HECHO el 30-sep con autorización de Johann** ([#87](REGISTRO.md)): `[sync] Ciclo OK`, el sync volvió tras 20 días.
- [x] ~~🧪 Con la key nueva en producción: ticket de prueba para ver una vista previa real de punta a punta.~~ → **HECHO del lado del servidor con FAC-171** (vista previa `Lista` en 4.32 s, operación #155, [#87](REGISTRO.md)). Verla en el navegador pasa al bloque del modal en vivo, arriba.
- [ ] 🧹 Imagen de rollback `balam-api:pre-vistaprevia-20260930` en paputec (además de la `pre-webhook`): borrarlas cuando la versión lleve unos días estable.
- [ ] 🔧 **Deuda:** las reglas de prellenado viven dos veces (`cotizacion-prefill.ts` y `CotizacionPrefill.cs`). Que las pantallas de cotización (individual y lote) consuman el prellenado y el dry-run ya preparado del servidor.
- [ ] 🔧 Suscribir `jira:issue_updated` (o repetir la vista previa al abrir el ticket) para que "Faltan datos" se actualice cuando alguien completa el ticket en Jira.
- [x] ~~⚠️ **Producción corre con `Bind__Mode=Write`** … falta alinear esa documentación con la decisión~~ → **Documentación alineada el 30-sep en `597c8a2`** (runbook y `CLAUDE.md` de la plataforma dicen que producción corre en Write y con el puente encendido por decisión de Johann, y cómo apagarlo). Regresar a ReadOnly solo cuando Johann lo indique.
- [ ] 🔑 **El secreto del webhook cambió:** el vigente está en `/opt/balam/.env` (`Jira__Webhook__Secret`) y en `~/jira-webhook-secret.txt` de la Mac desde la que se hizo el despliegue. El `~/jira-webhook-secret.txt` de la otra máquina (piloto del 29-sep) **ya no sirve**: reemplazarlo por un canal seguro antes de usar ahí el subcomando `mover`/`registrar`.
- [ ] 🧹 Imagen de rollback `balam-api:pre-webhook-20260930` en paputec: borrarla cuando la versión nueva lleve unos días estable.
- [ ] 🔧 **Poller de respaldo** del webhook (JQL delta con checkpoint): sigue sin construirse; hoy un aviso perdido no se recupera solo.

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

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

## ⭐ 29-sep — webhook Jira FAC → vista previa de cotización ([REGISTRO #84](REGISTRO.md), [plan](../planeacion/Plan-Webhook-Jira-2026-09-29.md))

- [ ] 📄 **Archivar en `fuentes/` la autorización escrita de Pedro** para crear el webhook/regla en Jira; anotar su alcance (¿incluye crear un ticket de prueba en FAC?).
- [x] ~~🔎 **Fase 1 (solo GET):** `myself` + `mypermissions` (ADMINISTER / ADMINISTER_PROJECTS en FAC) + inventario de webhooks → decide Vía A (webhook de sistema) o Vía B (regla de Automation).~~ → **HECHO (29-sep):** `ADMINISTER`=true, 0 webhooks de sitio, API de Automation accesible (50+ reglas). Vía A y Vía B disponibles.
- [x] ~~🔴 **Decidir el evento:** creación del ticket, transición a *En proceso de facturación* (dura ~3 min), o ambos.~~ → **Creación del ticket** (`jira:issue_created`) para el piloto; la transición a *En proceso de facturación* queda para después.
- [x] ~~🔧 **Fase 2:** `POST /api/jira/webhook` con secreto, relectura del ticket, idempotencia y solo dry-run; pruebas con `FakeHandler`. Poller de respaldo.~~ → **HECHO (29-sep, `d7238da`).** Falta el poller de respaldo.
- [x] ~~🌐 **Fase 3:** ngrok con traffic policy de una sola ruta; API en ReadOnly mientras el túnel esté abierto.~~ → **HECHO (29-sep)**; túnel apagado al cerrar la sesión.
- [x] ~~✍️ **Fase 4:** alta del webhook/regla como operación numerada (id, URL, fecha, autorización).~~ → **HECHO: webhook de sitio id 1** (19:05:53).
- [x] ~~🧪 **Fase 5:** ticket de prueba → "lista para revisar" → verificar que BIND no recibió escritura. Reversa documentada.~~ → **HECHO: FAC-169** creado → detectado en 14.4 s (HMAC, verificado) → borrado. Ver adenda del [#84](REGISTRO.md).
- [x] ~~🔥 **Mover el webhook id 1 a paputec** (`https://paputec.mx/balam/api/jira/webhook`)~~ → **HECHO el 30-sep** ([#85](REGISTRO.md)): plataforma publicada (`5145801`), secreto nuevo en `/opt/balam/.env`, `PUT` del webhook 1 → 200 (solo HMAC, sin token en la URL) y prueba con **FAC-170** detectada en 1.05 s y borrada.
- [x] ~~🔧 **Siguiente paso de la meta:** vista previa (dry-run) de la cotización por cada detección.~~ → **Construida el 30-sep** ([#86](REGISTRO.md)); su publicación está en el bloque del 30-sep, arriba.
- [x] ~~☁️ **Destino productivo del webhook:** ngrok con dominio fijo (de pago) vs Azure (sigue bloqueado por el cliente).~~ → **Resuelto por ahora con paputec** (30-sep), el mismo ambiente provisional de la plataforma. Cuando exista Azure, el webhook se mueve con otro `PUT`.
- [ ] ⚠️ **Una sola sesión de Claude Code dueña de la API** en sesiones de escritura (el 29-sep otra sesión la relanzó en ReadOnly).
- [x] ~~🔥 **API público de BIND en 500 en todos los endpoints** (key de Arturo)~~ → **RESUELTO el 30-sep** con la key del usuario `cto` en producción ([#87](REGISTRO.md)). Original: — sync detenido desde el 10-sep. Pedir a Balam la API key del usuario `CTO` o revisar el acceso de Arturo. **→ 30-sep: causa encontrada.** El API no está caído: la key de `arturo` es la que falla; la de `cto` responde 200. Falta cambiarla en paputec (bloque del 30-sep, arriba).
- [ ] 🔥 **Prefactura 2467 ($777,777 MXN, ACUNTIA, FAC-166):** confirmar con Balam si es prueba (cancelar/borrar antes de que alguien la timbre) o real; revisar que al timbrar quede **PPD**, no el PUE que BIND le puso.
- [ ] 📧 **Avisar a Pedro de la cotización 1079 marcada como Surtida por error** (`QuotesAPI/FillQuote` escribe por GET); sin efecto fiscal, irreversible desde la UI.
- [ ] 🔧 Tomar el bloque `Client` de `ClientsAPI/GetClientSelectedById` y que el wizard no muestre G03/16% cuando el puente manda lo de BIND. *(1-oct: el uso CFDI ya no se hereda de otro cliente — solo del mismo, o 23/S01 con aviso — [#89](REGISTRO.md); el bloque exacto sigue pendiente.)*
- [ ] 📝 **Hueco de bitácora:** registrar el trabajo del 9/10-sep (puente a la UI de BIND, prefactura 2463, sonda #12 / remisión 1004) — hoy solo vive en `balam-plataforma/CLAUDE.md`.

## 🚨 Huecos de registro (detectados en el corte del 15-sep)

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

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

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

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

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

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

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

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

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

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

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

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

- [x] ~~🔥 **Johann — responder el correo del hilo de Jira**~~ → **Enviado el 10-ago.** Pide ticket de ejemplo, propone mié 12 / jue 13 a las 7:00 am, fija el alcance en la cotización y recuerda Azure. Texto en [REGISTRO #62](REGISTRO.md).
- [x] ~~🔥 **Araceli — levantar el TICKET DE EJEMPLO capturado "como debería ser"** (ruteado por Noé el 11-ago; la noche del 11 no existía)~~ → **Lo resolvió PEDRO el 20-ago con `FAC-106`**, tras rehacer el formulario de Jira contra el Excel de campos de BIND ([#66](REGISTRO.md), [#67](REGISTRO.md)). ⚠️ **No consta que Araceli haya capturado el molde** que Noé le pidió: el camino fue otro — Balam modificó el formulario y Pedro levantó el ticket. Los planes B y C (captura en vivo / `FAC-100`) quedan sin usar.
- [x] ~~🔥 **Balam/Noé — confirmar la sesión** (mié 12 o jue 13, 7:00 am)~~ → **CONFIRMADA por Noé (11-ago, 10:41 am): miércoles 12-ago, 7:00 am.** Además, **Azure se explora en la misma sesión** con una cuenta nueva creada para este uso. Ver [REGISTRO #63](REGISTRO.md).
- [ ] 🔴 **Conceptos/partidas — la vía quedó definida el 12-ago: DEPURAR EL CATÁLOGO, no agregar un campo.** Araceli mostró que el combo de servicios de BIND está sucio (`040` y `029` son el mismo servicio; entradas con nombres de personas, "monitor Samsung", periodos en el nombre) y se acordó dejar **solo opciones genéricas**, volver **combo** la descripción del ticket y **homologar los combos de Jira con los de BIND**. Pedro ejecutó la depuración: **67 → 17 categorías**, pendientes de validar **mañana** con Noé y Ara. Dato fiscal: horas de consultoría = unidad SAT **`E48`**. Ver [REGISTRO #65](REGISTRO.md) §5, [#67](REGISTRO.md).
- [ ] 🔴 **ACUNTIA — se resuelve con el segundo ticket de ejemplo.** `FAC-100` trae **un solo** `Monto sin IVA` (7,594.00 USD) para el ticket que históricamente representa 40–48 facturas. ¿Un ticket → una cotización? Ver [REGISTRO #55](REGISTRO.md) punto 6.
- [ ] ⚠️ **Tickets de `Automation for Jira` — convertido en SUPUESTO, ya no bloquea.** 10 de 69 no tienen request type ni un solo campo (incluido `FAC-91`, vivo en validación nacional). En el correo del 10-ago se asienta que **siguen tramitándose a mano** y que la automatización cubre solo los que entran por el portal. Si Balam objeta, la regla de Automation tendría que propagar los campos (trabajo de ellos). El molde capturado a mano no puede resolver esto.
- [ ] ⚠️🔥 **Johann — decidir el destino de la cotización de la prueba en BIND.** El ejercicio escribe una **cotización real en BIND producción**. Dos salidas: cancelarla al terminar o apuntarla a un cliente de prueba. **Decidir esta noche y anunciarlo al abrir la sesión del 12, antes de ejecutar.**
- [x] ~~🔴 **¿El comercial ya genera la cotización en BIND, o la genera la plataforma?**~~ → **RESUELTO en la sesión del 12-ago: la genera la PLATAFORMA.** Noé le preguntó a Araceli si le serviría que Jira hiciera la cotización y evitarle el primer paso → *"Sí, sí me serviría"* → *"vamos a hacer ese ejercicio, Johann"*. El paso comercial de cotizar a mano desaparece para **venta nueva**; la **recurrente** sigue fuera de alcance (comercial solo avisa el periodo y administración prefactura). Ver [REGISTRO #65](REGISTRO.md) §3.
- [x] ~~**Alcance del ejercicio en vivo: ¿cotización o prefactura?**~~ → **Decidido (10-ago): termina en la COTIZACIÓN.** Es lo que contestó Arturo el 4-ago; la aprobación de Araceli va entre `En proceso de facturación` y `Facturado`, así que la prefactura pertenece después; Arturo pidió gradualismo explícito; y la cotización se cancela sin efecto fiscal mientras la prefactura es un registro en `Invoices` con `UUID = null`. La prefactura queda para la segunda sesión. Candados acordados: **cotización → prefactura → aprobación humana → timbrado** ([REGISTRO #55](REGISTRO.md)).
- [ ] ⚠️ **La transición automática depende de Azure.** En la prueba del miércoles el disparo es **manual** (pipeline `Draft→DryRun→Confirmed` de ADR-001 con flags apagados). Para que corra automática hace falta el ambiente publicado y corriendo continuo — otro argumento para insistir en el acceso a Azure.
- [x] ~~🔥 **Johann — preparar el flujo contra el ticket de ejemplo**~~ → **CONSTRUIDO (11-ago, noche):** contrato `Quotes_NewQuote` obtenido del portal público, `CreateQuoteAsync` con guardas, `POST /api/emision/cotizacion` (dry-run/confirmación auditadas en `WriteOperations`), pantalla `solicitudes/:id/cotizar` y vínculo ticket→cotización. 73/73 pruebas. **Corre contra cualquier ticket FAC** — el molde solo mejora los datos. La escritura real sigue gateada a `Bind:Mode=Write`, que se enciende SOLO en la sesión. Ver [REGISTRO #64](REGISTRO.md).
- [ ] 🔥 **Johann — enviar a Noé/Pedro el script de la prueba** esta noche (`../planeacion/Script-cotizacion-sesion-2026-08-12.md`) — cumple la condición del 24-jul de compartirlo antes.
- [ ] 🔥 **Johann — en la sesión: encender `Bind:Mode=Write` solo para emitir y regresarlo a ReadOnly antes de cerrar.** ⚠️ La semántica fina de partidas (`Type`/`SelectedUnit`/VAT) se valida contra la primera respuesta real; si BIND rechaza, el error se lee en pantalla y se ajusta en vivo.
- [x] ~~**Balam/Noé — fecha para la prueba acompañada de escritura.**~~ → **Es la sesión confirmada del mié 12-ago, 7:00 am** (Noé, 11-ago). Formato aceptado desde el 7-ago; **no habrá `FACTEST`**. Ver [REGISTRO #63](REGISTRO.md).
- [ ] **Balam — ¿nacional vs extranjero cambia la cotización** o solo el paquete de salida (PDF+XML vs PDF)? Hay dos estatus de validación y una aprobación por rama.
- [ ] **Balam/Pedro — migrar a cuenta de servicio** en vez de la cuenta personal de Pedro. Planteado el 29-jul, sin respuesta: hoy todo lo que escriba la plataforma queda firmado como Pedro y una rotación suya mata la integración.
- [ ] **Johann — levantar el sandbox Jira Cloud propio** (plan Free, proyecto JSM que replique el workflow de FAC). Con `FACTEST` descartado, es el único lugar donde se puede equivocar sin costo.
- [ ] ⚠️ **Johann — implementar la detección por changelog, no por estatus actual.** `FAC-100` estuvo **2m44s** en el estatus disparador; un poller de 15 min que consulte el estado actual se pierde la mayoría de los disparos. Refuerza el caso de pedir un webhook / regla de Automation a Pedro.
- [ ] **Johann — mover el token de Jira a user-secrets/Key Vault** y borrarlo de disco (ya está en `.gitignore:9`). Mismo pendiente que arrastra `bind_token_api.txt`.

## 🔴 Johann (proveedor) — inmediato

- [x] ~~⚠️🔥 **Enviar la propuesta/adenda ajustada por la integración Jira→BIND**~~ → **Hecho (29-jul):** v1.3 enviada por WhatsApp (8:18 am) y por correo (3:56 pm) a Noé, CC Ara/Erika/Pedro. **APROBADA por Noé el 30-jul:** "De acuerdo con la propuesta actualizada". Alcance: 7–10 h ($4,200–$6,000 MXN + IVA); total primera etapa 119–146 h. Ver [REGISTRO #59](REGISTRO.md), [#60](REGISTRO.md).
- [x] ~~📊 **Enviar el Excel de horas de las etapas siguientes (2, 3)**~~ → **Hecho (29-jul, 8:18 am):** `Avance-Balam-2026-07-28.xlsx` por WhatsApp; 👍 de Erika. Ver [REGISTRO #59](REGISTRO.md).
- [x] ~~🔑 **Destrabar el acceso a la API de Jira (401 del 29-jul)**~~ → **Resuelto (30-jul):** Pedro confirmó el correo del apikey (`pedro.ayala@...`), regeneró el token y `GET /myself` respondió 200. Ver `../planeacion/Investigacion-API-Jira.md` (Bloque 0).
- [x] ~~🌱 **Seeder de datos de prueba (B9)**~~ → **Hecho (1-ago):** `DevDataSeeder` opt-in con datos ficticios (5 estados × MXN/USD × PUE/PPD). El desfase con lo reportado a Erika el 27-jul quedó saldado. Ver [REGISTRO #61](REGISTRO.md).
- [x] ~~🔑 **Copiar `propuesta/token-jira.txt` a esta máquina** y correr `../planeacion/pruebas-jira-lectura.sh`~~ → **Hecho (6-ago):** script corrido completo contra FAC (todo 200; auth OK con el token renovado) + sondeo dirigido de customfields. **Los IDs quedaron capturados y documentados** en `../planeacion/Investigacion-API-Jira.md` (sección 6-ago): sí existen "Monto sin IVA"/"Monto con IVA" pero casi nadie los llena (2/69); "Nombre del Cliente" y "Periodo de Incidencias" llegan como ADF. ⚠️ El token estaba suelto en `balam-plataforma/token-jira.txt` (repo del cliente, sin ignorar): se movió a `propuesta/` + user-secrets y se blindó el `.gitignore` del subrepo.
- [ ] 🧪 **Crear el sandbox Jira Cloud Free propio** (decidido 1-ago) para desarrollar escritura (transiciones/comentarios/creación) sin tocar FAC; la prueba en la instancia real sigue reservada a la sesión acompañada que autorizó Noé.
- [ ] ⏱️ **Capturar horas 28-jul→1-ago en el CSV** (propuesta preparada, validar montos) y **regenerar `Avance-Balam` desde script** — la copia en disco del 28-jul está desincronizada (re-guardado manual).
- [ ] 📅 **Demo del viernes 7-ago:** material listo — frontend (login→cartera→facturas→detalle+PDF→clientes), seeder demo como respaldo si BIND falla, scheduler en vivo.

- [x] ~~**Asistir al kickoff con Noé (mié 1-jul, 7:00 am)**~~ → **Hecho (1-jul).** Ver [REGISTRO #22](REGISTRO.md).
- [x] ~~📅 **Asistir a la sesión "Proceso actual de facturación y cobranza" (lun 6-jul, 7:00 am)**~~ → **Hecha (6-jul).** Proceso mapeado end-to-end; lista blanca eliminada; cotización BIND obligatoria. Ver [REGISTRO #27](REGISTRO.md).
- [x] ~~🎨 **Preparar y entregar el prototipo de la Etapa 0**~~ → **Entregado por correo (10-jul)** a Erika + Noé, CC Pedro, con PDF y versión navegable. Refleja facturación, envío, cobranza y reglas del Discovery. Ver [REGISTRO #40](REGISTRO.md).
- [x] ~~📧 **Enviar por correo el prototipo (imágenes) + comentarios**~~ → **Hecho (10-jul).** Balam respondió que lo revisaría internamente.
- [x] ~~📊 **Responder a Erika el % de avance de Fase 0**~~ → **Atendido mediante el Excel de avance ajustado y entrega del prototipo.** La validación final sigue abierta.
- [x] ~~📅 **Preparar y asistir a la sesión de reglas/dudas de Etapa 1 (mié 22-jul)**~~ → **Hecha (22-jul, 7 am):** alta de cliente/proveedor mapeada (Arturo en pantalla), fee = lo registra el despacho (plataforma solo detecta), Jira confirmado en el proceso (estatus final "resuelto"; validación PDF+XML nacional / PDF internacional). No se tocaron particularidades de envío ni PUE/PPD. Ver [REGISTRO #54](REGISTRO.md) y minuta en `../planeacion/Sesion-Etapa1-2026-07-22.md`.
- [ ] 📅 **Preparar y asistir a la validación del prototipo (jue 23-jul, 7:00 pm).** Llevar decisiones que requieren visto bueno y separar MVP de Anexo B. **Aprovechar para meter la pregunta PUE/PPD que no se alcanzó el 22-jul.** Ver [REGISTRO #42](REGISTRO.md).
- [x] ~~📊 **Compartir con Erika el corte de avance de la Etapa 1 solicitado el 16-jul**~~ → **Hecho (16-jul, 8:40 pm):** Excel `Plan-actividades-avance-2026-07-16.xlsx` enviado por WhatsApp; Erika acusó recibo ("Ntp, gracias"). Ver [REGISTRO #46](REGISTRO.md).
- [ ] 📄 **Revisar los procedimientos de carga de facturas por cliente enviados por correo el 16-jul.** Conservar correo/adjuntos como evidencia y contrastar destinatarios, adjuntos, asunto, cuerpo y nomenclatura contra el Discovery y el prototipo. Ver [REGISTRO #46](REGISTRO.md).
- [x] ~~🔐 **Validar permiso de escritura en el repositorio privado de Balam**~~ → **Comprobado (16-jul):** push exitoso del scaffold inicial (backend .NET 10 + Angular 21, commits `220942a..1f7f098`) a `pedro-balam-itsm/BALAM`. Ver [REGISTRO #46](REGISTRO.md).
- [ ] ⏱️ **Validar el corte reconstruido de 30 h** en `../planeacion/Seguimiento-horas.csv`: 22 h de Etapa 0 + 8 h de Etapa 1. Solo 3.08 h corresponden a sesiones con duración comprobable; las otras 26.92 h están marcadas como reconstruidas. Ajustarlas si la memoria/evidencia indica otra distribución y después conciliar con Jira. Ver [REGISTRO #45](REGISTRO.md).
- [ ] 📝 **Cerrar el documento de hallazgos + ADRs** (`../planeacion/Hallazgos-y-decisiones-Etapa0.md`) después de las sesiones del 22–23 jul.
- [ ] 🔐 **Decidir/aplicar el rol local `balam_app` para que RLS aplique en desarrollo:** la política RLS de B6 está aplicada, pero el usuario `balam` del contenedor es superuser (BYPASSRLS) y la ignora. Falta: `CREATE ROLE balam_app LOGIN NOSUPERUSER NOBYPASSRLS` + `REASSIGN OWNED` + apuntar la cadena de conexión de desarrollo (appsettings.Development y DesignTimeDbContextFactory) a ese rol + repetir la verificación psql. En Azure no existe este hueco (el usuario de app no es superuser). Ver [REGISTRO #53](REGISTRO.md).
- [ ] ⚠️ **Preguntar a Arturo: ¿por qué TODO el histórico se factura PUE?** 1,374/1,374 facturas con método de pago = PUE, cero PPD, aunque cobran a crédito 30–90 días. Toca la regla "PPD default" de la capa de escritura (B7) y el requerimiento del SAT que ellos mismos sufrieron. **No se alcanzó a preguntar en la sesión del 22-jul** — reintentar el 23-jul (validación del prototipo) o en la sesión de API Jira con Pedro. Ver [REGISTRO #52](REGISTRO.md), [#54](REGISTRO.md).
- [x] ~~📅 **Proponer a Erika usar la sesión del martes 7-jul para COBRANZA**~~ → **Propuesto (6-jul, 3:01 pm) y CONFIRMADO (6-jul, 6:36 pm):** convocatoria de Teams enviada para el martes 7-jul, 7:00–8:00 am, con Araceli y Arturo (CC Noé). Ver [REGISTRO #34](REGISTRO.md).
- [x] ~~📅 **Asistir a la sesión de cobranza (mar 7-jul, 7:00 am)**~~ → **Hecha (7-jul).** Sin grabación. Ver [REGISTRO #35](REGISTRO.md).
- [x] ~~📝 **Documentar el proceso de cobranza** de la sesión del 7-jul (sin grabación)~~ → **Hecho (7-jul):** reconstruido de memoria el mismo día. Notas en `../fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md`; entrada [REGISTRO #35](REGISTRO.md).
- [ ] 📊 **Exceles de cobranza (condicional):** si Balam valida que el prototipo representa bien su operación, ya no se requieren. Si pide ajustes, solicitar a Arturo estructura con datos ficticios de abiertas/canceladas/días vencidos, pago↔folio y estado de cuenta. **No confundir con el Excel de particularidades de envío**, que sigue pendiente. Ver [REGISTRO #44](REGISTRO.md).
- [ ] 🔑 **Dar seguimiento a si Pedro crea el usuario de solo lectura de BIND** que pidió Noé (mientras tanto Erika opera con el usuario de Arturo, sin bloqueo) — sigue sin resolverse una semana después (7-jul). Ver [REGISTRO #37](REGISTRO.md).
- [x] ~~🔧 **Decidir si probar endpoints de escritura (POST/PUT) de BIND**~~ → **Decidido (7-jul): NO todavía.** Contradice la instrucción de Noé de mantener solo-lectura mientras Pedro confirma el alcance del token; sin sandbox, el riesgo fiscal es real. Alternativa segura: catalogar operaciones de escritura desde el **portal de desarrolladores de BIND** (documentación), no probarlas en vivo. Ver [REGISTRO #36](REGISTRO.md).
- [x] ~~📧 **Responder el correo de Pedro**~~ → **Enviado (6-jul, ~3:28 pm):** acuse de recibo + usuario de Arturo documentado + arranque de trabajo con la API, sin comprometer entregas adicionales. Ver [REGISTRO #29](REGISTRO.md).
- [x] ~~📧⚠️ **Responder el correo de Noé (importancia alta, 4:33 pm)** describiendo las salvaguardas ya operando~~ → **ESTABA HECHO DESDE EL 6-JUL, 4:46 PM** (13 minutos después del correo de Noé), a Noé y Pedro con Erika en copia. Cubre las cinco salvaguardas: solo-lectura bloqueado en código, consumo acotado, token en gestor de secretos fuera del repo, sin datos reales en la documentación, y escritura diferida. *(Corrección del 20-ago: este pendiente llevaba mes y medio abierto por error — el correo apareció al cruzar el buzón.)* Ver [REGISTRO #31a](REGISTRO.md).
- [ ] ⚠️ **No atar nada al token actual:** Pedro está revisando permisos y puede **reemplazarlo** por uno de un usuario nuevo de solo lectura — mantener el token como variable de entorno intercambiable (ya es así en el sandbox). Ver [REGISTRO #31](REGISTRO.md).
- [x] ~~🔑 **Validar la API de BIND con el token real**~~ → ✅ **Hecha (6-jul, adelantada un día):** 117 peticiones GET-only, Plan A del saldo CONFIRMADO, flujo MVP 100% sostenible en lectura, PDF por API. Hallazgo duro: **sin recurso de pagos/REP**. Documento: [`../bind-api-sandbox/VALIDACION-API.md`](../bind-api-sandbox/VALIDACION-API.md). Ver [REGISTRO #32](REGISTRO.md).
- [ ] 📨 **Escalar a Pedro las preguntas técnicas de la API** (juntas, esta semana): (1) ¿existe endpoint de **pagos individuales / complementos de pago (REP)** no documentado? — es el hueco más relevante para el flujo PPD, _y ganó caso de negocio el 7-jul: el despacho registra los pagos en BIND uno por uno a mano_; (2) **tabla de mapeo `CFDIUse`** interno → clave SAT; (3) shape del endpoint `/{id}/xml`; (4) ¿webhooks/eventos o solo polling?; (5) ⚠️ **qué token alimenta el Power BI** — el 7-jul Arturo mostró su Power BI conectado con **su** token, pero el kickoff acordó Ara=Power BI / Arturo=desarrollo; BIND emite 1 token por usuario, así que si ambos usos comparten el de Arturo, reemplazarlo por el usuario solo-lectura que planteó Noé rompería uno de los dos. Ver [REGISTRO #32](REGISTRO.md) §10, [#35](REGISTRO.md).
- [ ] 🔐 **Higiene del token:** moverlo a un gestor de secretos y **borrar `bind_token_api.txt`** de la raíz del repo y del correo/descargas (está gitignoreado, pero sigue en disco).
- [ ] ⚠️ **Aclarar expectativa de recordatorios a clientes:** lo que Ara/Arturo describieron el 6-jul son recordatorios automáticos **a clientes**, que están **diferidos al Anexo B** (el MVP trae alertas *internas*). Aclararlo pronto o anticipar que pidan ese módulo al cierre del MVP. Igual con la idea de **agentes observando Jira** (Nivel 3, fase posterior) y el deseo **multi-empresa** (Regiotour, Elmstone). **Reapareció el 7-jul:** quieren correos automáticos al cliente pasados 1–5 días de vencimiento ("ser proactivos"). Ver [REGISTRO #27](REGISTRO.md), [#35](REGISTRO.md).
- [x] ~~**Ajustar la propuesta** (30 h explícitas, sin "Etapa 0", términos comerciales en una sección)~~ → **Hecho (1-jul):** propuesta **v1.2** — se agregó el concepto **"Facturación inicial: 30 h / $18,000 + IVA"** (cubre Etapa 0 + inicio de Etapa 1; Etapa 0 se mantiene en 18–22 h) y se consolidó **§3.3 Condiciones comerciales**. PDF generado y enviado el 2-jul.
- [x] ~~📧 **Enviar el correo** (Noé, CC Pedro, Ara, Erika) con la propuesta v1.2 ajustada, vinculando la **facturación inicial de 30 h** al acuerdo~~ → **Hecho (2-jul, 5:39 PM):** enviado con `Propuesta-Balam.pdf` adjunto, sin esperar el correo de Erika+Paola. Ver [REGISTRO #26](REGISTRO.md).
- [ ] 💸 **NO facturar todavía.** Erika confirmó el 13-jul que recibió la propuesta v1.2; la validación para emitir sigue pendiente porque Noé y la CEO están fuera del país. Mantener la factura lista y emitir en cuanto llegue el visto bueno, con pago a 30 días. Ver [REGISTRO #41](REGISTRO.md).
- [ ] **Configurar Jira y aprender el flujo con Pedro** — reportar horas ahí (incluye material informativo); Erika hace el corte los lunes. Mientras tanto usar `../planeacion/Seguimiento-horas.csv`.
- [x] ~~Usar los **tokens de marca** en el prototipo~~ → **Hecho:** prototipo y capturas usan Amarillo `#F7BD0C`, Café `#331F0E` y Poppins.
- [x] ~~Preparar el Excel de actividades~~ → **Entregado y consolidado:** la única versión operativa se conserva en `../planeacion/Plan-actividades-avance-2026-07-10-ajustado.xlsx`; contiene el corte reconstruido de 30 h al 15-jul.
- [x] ~~Proponer sesiones de Discovery~~ → **Hecho (29-jun):** propuestas y aceptadas; **Erika coordina las agendas** (intermediaria de sesiones).
- [ ] Cambiar régimen fiscal (en proceso) para poder facturar (CFDI semanal los viernes, pago a 30 días).
- [x] ~~Confirmar **qué permisos exactos de Azure** necesita~~ → **Definido:** acceso `Contributor` acotado a un grupo de recursos de Balam; no se requiere Global Admin ni una cuenta nueva. Solicitar durante la semana del 21-jul.
- [x] ~~**Arrancar el Discovery** una vez Balam entregue los accesos~~ → **Hecho (6–7 jul):** facturación, envío y cobranza mapeados.
- [ ] (Opcional) Pedir a Balam **copia limpia del contrato**: la cláusula de Firma Electrónica de la última página quedó duplicada y aún dice "EL PATRÓN" (residuo de plantilla, bajo riesgo). Ver [REGISTRO #19](REGISTRO.md).
- [x] ~~Revisar y firmar el contrato de servicios~~ → **Hecho (26-jun):** revisado, negociados 2 ajustes (pago de horas al terminar + aceptación a 10 días) y **FIRMADO**. Ver [REGISTRO #18](REGISTRO.md), [#19](REGISTRO.md).
- [x] ~~Responder el correo de Noe (8-jun)~~ → **Hecho (10-jun):** aceptados los 4 ajustes y respondidas las 3 preguntas técnicas. Ver [REGISTRO #16](REGISTRO.md).
- [x] ~~Decisión comercial: sin anticipo / pago a 30 días~~ → **Aceptado (10-jun)**, con la condición de **firmar el contrato/orden de trabajo antes de arrancar** (sustituye al anticipo como mecanismo de compromiso).
- [x] ~~Preparar propuesta v1.1~~ → **Enviada (10-jun)** con los 4 ajustes reflejados. Ver [REGISTRO #16](REGISTRO.md):
  - [x] **Soporte:** bolsa de horas a $600/h, vigencia 12 meses (sin caducidad mensual).
  - [x] **Garantía:** 45 días.
  - [x] **Comercial:** sin anticipo; factura de Etapa 0 + pago a 30 días; avances a 30 días.
  - [x] **Conciliación bancaria:** reflejada como primer alcance condicionado a horas liberadas por el Discovery.
  - [x] **Dashboard/reporteo:** ajustado para no solapar con el tablero Power BI de Pedro (conservar cobranza + alertas).

## 🟡 Balam

- [ ] ☁️⚠️ **Noé: otorgar el acceso a Azure** — grupo de recursos con permiso **Contributor** (app + BD + Key Vault); no requiere Global Admin ni cuenta nueva. Requisitos comunicados por Johann el 28-jul 4:53 pm; **Erika lo escaló a Noé** (5:23 pm). Bloquea ambiente, staging y CI/CD. **Movimiento (11-ago): Noé propone explorar/validar los accesos EN la sesión del 12-ago, con una cuenta que están creando para este uso** — llevar los requisitos a la mano. Ver [REGISTRO #59](REGISTRO.md), [#63](REGISTRO.md).
- [ ] 📅⚠️ **Erika/Arturo: avisar fecha de la sesión del flujo de facturación** tras la revisión interna (Ara de viaje desde el 28-jul). **Desbloquea B7 (capa de escritura).** Ver [REGISTRO #58](REGISTRO.md).
- [ ] 🧾 **Balam: decisiones de negocio de la integración Jira→BIND** — estatus disparador, request type a observar, fuente de monto y conceptos de la cotización. Sin esto no se escribe código productivo de la integración. Ver `../planeacion/Investigacion-API-Jira.md`.
- [x] ~~**Balam:** enviar el documento/contrato de firma~~ → **Hecho (25-jun):** contrato enviado vía Paola (RH); ajustado y **firmado el 26-jun**. Ver [REGISTRO #18](REGISTRO.md), [#19](REGISTRO.md).
- [ ] 🔑 **Balam: completar accesos de Etapa 1** — token BIND ✅; manual de marca ✅; invitación al repo GitHub recibida y acceso confirmado informalmente (falta validar escritura); Azure programado para semana del 21-jul. Ya no bloquea el desarrollo local, pero Azure sí condiciona despliegue/CI-CD.
- [x] ~~Erika (PM): pedir el plan de actividades~~ → **Recibido (30-jun).** Erika es la **intermediaria de todas las sesiones**, agendó el **kickoff (1-jul, 7am)** y monta el **tablero Kanban en Jira**. Ver [REGISTRO #21](REGISTRO.md).
- [x] ~~**Noe:** formalizar por correo~~ → **Hecho:** aclaraciones (8-jun, [#15](REGISTRO.md)) y **luz verde + redacción del documento de firma** (16-jun, [#17](REGISTRO.md)).
- [ ] **Pedro + Erika:** armar el **tablero de seguimiento en Jira** y revisarlo juntos (instruido formalmente por Noe el 16-jun).
- [x] ~~**Pedro:** enviar **manual de marca**~~ → **Hecho (1-jul):** enviado por correo. Tokens en [`../marca/Marca-Balam.md`](../marca/Marca-Balam.md). Ver [REGISTRO #23](REGISTRO.md).
- [x] ~~**Erika:** entregar el **token de BIND**~~ → ✅ **ENTREGADO por correo (6-jul, 12:40 pm)**, mismo día en que se solicitó. Ver [REGISTRO #28](REGISTRO.md).
- [x] ~~**Balam:** confirmar **a qué usuario pertenece el token**~~ → ✅ **Confirmado (6-jul, 12:38 pm):** Pedro lo entregó por correo (`bind_token_api.txt`) indicando que fue generado con el **usuario de Arturo Rosas** — conforme al kickoff (Arturo=dev, Ara=Power BI). Ver [REGISTRO #29](REGISTRO.md).
- [ ] **Pedro/Balam:** confirmar permisos de **escritura** para `Johann-28` en el repositorio GitHub privado. Pedro envió la invitación el 15-jul y Johann confirmó acceso el 16-jul; falta una prueba efectiva de escritura. Ver [REGISTRO #43](REGISTRO.md), [#46](REGISTRO.md).
- [ ] **Pedro:** enseñar a Johann el **flujo de Jira** (reporte de horas como los demás consultores).
- [ ] **Pedro + Noé:** **configurar Azure** y permisos (Noé otorga donde Pedro tiene limitantes).
- [x] ~~**Erika:** **coordinar la sesión de Discovery con Arturo + Araceli**~~ → **Hecho:** agendada (1-jul) y **realizada (6-jul, 7am)**. Ver [REGISTRO #24](REGISTRO.md), [#27](REGISTRO.md).
- [ ] 📊 **Ara + Arturo:** enviar el **Excel de particularidades de envío por cliente** (destinatarios + adjuntos + nomenclatura). Erika confirmó el 13-jul que continúa en preparación y que esperan entregarlo durante la semana. Ver [REGISTRO #41](REGISTRO.md).
- [ ] **Arturo:** definir el proceso para cuando el **cliente NO esté dado de alta en BIND** — el ASIS del alta ya quedó mapeado en la sesión del 22-jul ([REGISTRO #54](REGISTRO.md)); **sigue abierta la decisión de MVP: ¿la plataforma solo detecta que falta el cliente o también lo crea?** (cruza con la estimación Jira→BIND de ~10 h). Ver [REGISTRO #27](REGISTRO.md), [#51](REGISTRO.md).
- [ ] 📤 **Arturo/Pedro:** enviar a Johann el **diagrama del flujo Jira de facturación** en tamaño legible (comprometido en la sesión del 22-jul; el screenshot era ilegible). Ver [REGISTRO #54](REGISTRO.md).
- [ ] 📅 **Erika:** agendar la **sesión con Pedro (+Arturo)** para explorar la **API de Jira** (conexión, campos, webhook), la **facturación recurrente** (~30 facturas/mes) y qué facturas son automáticas vs manuales — acordada en la sesión del 22-jul. Ver [REGISTRO #54](REGISTRO.md).
- [ ] **Erika + Paola / Noé:** confirmar la propuesta v1.2 para emitir las 30 h. Erika confirmó recepción; validación pendiente por viaje de Noé y CEO. Ver [REGISTRO #41](REGISTRO.md).
- [ ] **Arturo:** dar acceso/contexto de **bancos** (para conciliación). _Las reglas de negocio de facturación ya quedaron mapeadas en la sesión del 6-jul ([REGISTRO #27](REGISTRO.md)); bancos sigue pendiente._

## ⚙️ Acordado (referencia, ya cerrado)

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