Actualiza cierre de Etapa 0 y control de horas

bitacora/REGISTRO.md

@@ -11,7 +11,7 @@
 - **Pedro Alberto Ayala Elizondo** — Desarrollador / contacto técnico, Balam — `pedro.ayala@balamtalentoestrategico.com`
 - **Paola** — Recursos Humanos, Balam — coordinó la firma del contrato (WhatsApp)
 
-**Periodo:** 30 abr 2026 → 6 jul 2026 (última actualización: sesión de Discovery del proceso de facturación, 6-jul)
+**Periodo:** 30 abr 2026 → 10 jul 2026 (última actualización: avance de Fase 0 + envío del prototipo por correo, 10-jul)
 **Orden:** cronológico (más antiguo arriba)
 
 ---
@@ -386,7 +386,7 @@ Erika (PM, contacto principal) confirma que **ya pasaron los temas administrativ
 
 ## 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: `../planeacion/Plan-actividades.xlsx` (+ `.md`).
+> 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").
@@ -643,6 +643,191 @@ Noé responde al hilo de la entrega del token con dos instrucciones:
 
 ---
 
+## 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)): *"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é (borrador listo, ver [PENDIENTES.md](PENDIENTES.md)) — conviene enviarla igual para dejar constancia en el canal formal, tal como pidió Noé.
+
+> **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](#30--jul-6-2026--301-pm--whatsapp-johann--erika--propone-sesión-de-cobranza-martes-7-jul-)). 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](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)).
+
+> **Lectura estratégica:**
+> - **Cierra el hueco de Discovery que quedó abierto el 6-jul:** facturación y envío ya están mapeados ([#27](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)); 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](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)). 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](#32--jul-6-2026--tarde--validación-técnica-de-la-api-de-bind-con-la-cuenta-real--)) 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](#32--jul-6-2026--tarde--validación-técnica-de-la-api-de-bind-con-la-cuenta-real--)) 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](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)) **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](#32--jul-6-2026--tarde--validación-técnica-de-la-api-de-bind-con-la-cuenta-real--)).
+
+> ⚠️ 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)), 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](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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)), 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](#31--jul-6-2026--433-pm--correo--noé--johann-pedro-cc-erika--salvaguardas-sobre-el-token-)) **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](#35--jul-7-2026--700-am--llamada--discovery-proceso-actual-de-cobranza-sin-grabación-): 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](#35--jul-7-2026--700-am--llamada--discovery-proceso-actual-de-cobranza-sin-grabación-), 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](#35--jul-7-2026--700-am--llamada--discovery-proceso-actual-de-cobranza-sin-grabación-): 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.
+
+---
+
+## 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:
+
+1. **Miércoles 22-jul:** sesión de dudas y definiciones de la Etapa 1 con Arturo y participación solicitada de la CEO.
+2. **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.
+
+---
+
 ## Resumen ejecutivo del hilo (para contexto rápido)
 
 ### Datos duros confirmados por Balam
@@ -655,6 +840,7 @@ Noé responde al hilo de la entrega del token con dos instrucciones:
 - **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.
@@ -670,20 +856,25 @@ Noé responde al hilo de la entrega del token con dos instrucciones:
 1. **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.
 2. **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 6-jul-2026 — Discovery en marcha)
-**Contrato FIRMADO (26-jun)**, **kickoff realizado (1-jul)** y **primera sesión de Discovery realizada (6-jul, 7am, con Ara + Arturo — [#27](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)).** El proceso de **facturación** quedó mapeado end-to-end: **Jira ITSM (mandatorio) → validación administración → prefactura BIND → CFDI → envío por correo con particularidades por cliente**. **La cobranza sigue sin mapear** (candidata para la sesión del martes 7-jul). Dos reglas cambiaron en la sesión: **lista blanca eliminada** (recordatorios a todos) y **cotización BIND obligatoria** como inicio del flujo. Ara/Arturo deben enviar hoy el **Excel de particularidades de envío**; Johann trabaja el **prototipo** con el flujo real. **Propuesta v1.2 enviada (2-jul)** — en espera de confirmación de Balam para emitir la factura de 30 h. **Token de BIND sigue pendiente** (no se tocó en la sesión).
+### Estado actual (al 15-jul-2026 — Etapa 0 en validación, Etapa 1 iniciada en local)
 
-**Definido en el kickoff:** token **de Arturo** para BIND (solo consulta; se prueba primero) · **Balam crea el repo** (GitHub privado) y **gestiona Azure** (Pedro+Noé) · Johann reporta **horas en Jira** (Pedro le enseña; corte de Erika los lunes) · Discovery **con Arturo + Araceli** (Erika agenda). **Dos bloqueadores vivos:** (1) **accesos** (token BIND, Azure, repo) y (2) **emisión de la 1ª factura** — Johann ya envió la propuesta v1.2 ajustada (2-jul); **no factura hasta que Balam confirme por correo**.
+**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 tentativo:** kickoff 1-jul · Etapa 0 (Discovery) sem del 6-jul · Etapa 1 13–24 jul · Etapa 2 27-jul–7-ago · Etapa 3 10–21 ago. Las fechas se confirman/afinan al cerrar el Discovery (dependen de los accesos).
+**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:**
-- **Asistir al kickoff (1-jul, 7am)** con material listo (agenda + lista de accesos a pedir + preguntas de Discovery).
-- Cambiar régimen fiscal (para facturar) y confirmar permisos exactos de Azure.
+**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:** entregar **accesos** (API BIND vía cuenta maestra ARA / llave de Arturo, Azure con Guajardo/Erika, manual de marca de Pedro) y reglas de negocio + bancos con Arturo. El **Discovery arranca** una vez recibidos.
+**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).