- Seguimiento-horas.csv: 30 filas nuevas (sesiones 'Seguimiento PAF' del 21, 24
y 26-ago y 3, 9 y 10-sep acotadas por los informes de Read AI; bloques de
desarrollo por commits y mtimes; comunicación con Pedro y Noé). Marcadas
`reconstruida` salvo la sesión del 12-ago (transcript). Actividades nuevas
E1-09, E2-02, E2-03, E3-01, E3-02. Etapa 1 32.25 h, Etapa 2 23.75 h, ajuste
Jira 14.75 h (rebasa las 7–10 aprobadas), Etapa 3 1.50 h.
- Avance-Balam-2026-09-15.xlsx generado desde generar_avance_2026_09_15.py
(parte del corte 06b; el reparto por fila aborta si no cuadra con el CSV):
publicación provisional en paputec.mx, cotización individual y en lote,
prefactura por API bloqueada por BIND.
- Seguimiento-horas.md: sección del corte y criterios de la reconstrucción.
- PENDIENTES.md: huecos de registro del corte (seis sesiones sin REGISTRO,
publicación del 3-sep y lote del 7-sep sin registrar, validación de horas,
correos de Noé del 24-ago).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sesión del 21-ago: tres intentos en vivo fallaron (uno con error explícito
que se corrigió al momento, dos con 500 genérico); se aplicó el protocolo,
se verificó por lectura que nada quedó en BIND, y con autorización de Balam
se siguió sobre el ticket de prueba. La causa fue Items[].Type (2 =
servicio, el catálogo donde BIND busca el ID) y, ya emitida, la escala de
Items[].VAT (tasa, no monto) que dejó el folio 1026 con IVA absurdo y debe
cancelarse. La segunda emisión corregida queda pendiente de confirmar.
Incluye el borrador del correo a Balam con la causa y el Excel de campos y
catálogos de BIND que fue el insumo del formulario nuevo de Jira.
Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>
Preparación para la sesión del 21-ago. Todo solo lectura + dry-run.
FAC-106 (creado por Pedro el 20-ago, asignado a Araceli) trae el
formulario nuevo con request type "Cotización Bind". Servicio/Producto,
Cantidad, IVA y Cliente ya son campos estructurados: el hueco de
conceptos/partidas que bloqueaba B7 queda resuelto en el origen.
Diagnóstico del 500 del 12-ago, leyendo 4 cotizaciones reales de BIND:
- VATRate va como fracción (0.16), no como 16
- el VAT de partida es un MONTO, no una tasa (Price*Qty*0.16)
- cada cotización usa un PriceListID distinto y ninguno coincide con el
único que devuelve GET /api/PriceLists; conviene omitirlo
Dry-run corregido ejecutado (operación #18); el body queda en el informe.
Tres preguntas nuevas para la sesión: Empresa origen tiene 3 valores y
hay un solo token; el combo IVA no ofrece 0% aunque hay clientes de
exportación; y "Servicio de Enlace" existe 5 veces en BIND con unidad,
unidad SAT y ChargeVAT distintos, sin mapeo definido.
Bind:Mode está en Write fuera de sesión — hay que regresarlo a ReadOnly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Transcript de la sesión del 12-ago localizado y archivado en fuentes/.
Reemplaza el stub que quedó abierto en el commit anterior.
Lo que resuelve:
- Noé anuncia que Erika deja de ser la PM y el seguimiento pasa a Pedro.
El anuncio fue solo verbal; nunca se comunicó por escrito.
- Se decide que la cotización la genera la PLATAFORMA, no el comercial
(venta nueva). Cierra la contradicción abierta desde el 6-jul.
- El molde que Noé encargó a Araceli nunca existió: Pedro construyó un
formulario nuevo en vivo, apoyado en el Excel enviado esa mañana.
- El catálogo de BIND está sucio (servicios duplicados, nombres de personas,
periodos en el nombre). Se acuerda depurarlo y homologar los combos de
Jira con los de BIND: de ahí salen las 17 categorías de Pedro.
- La primera escritura real a BIND devolvió ERROR 500: faltan campos que el
portal manda en ceros y la lista de precios. No se creó cotización.
Corrige la lectura del #64, que quedaba en 73/73 de dry-run.
Reglas abiertas que dejó la sesión: edición vs historial de cotizaciones,
récord de cancelaciones sin ejecutarlas, quitar SLA a los tickets de
cotización, grabaciones de BIND que Pedro no envió, y la herramienta de
seguimiento del proyecto (Jira de paga vs SharePoint vs Drive).
Azure no se tocó pese a estar en la agenda; queda con Pedro.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lectura del correo de Outlook vía MCP ms365 (94 mensajes del dominio Balam
desde enero) cruzada contra REGISTRO.md.
Entradas nuevas:
- #0 prehistoria comercial de abril (hilo "Propuesta de servicios por hora"),
inventario; cuerpos aún sin leer
- #31a respuesta formal de las salvaguardas del token — SÍ se envió el 6-jul 4:46 pm
- #40a reacción de Balam al prototipo: acuse de Erika y Noé fuera de oficina
- #46a procedimientos de carga de facturas (5 portales; ATC Consolidados y
Victec nunca aparecieron en el Discovery)
- #57a diagrama del flujo de facturación de Jira
- #59a seguimiento a la API de Jira por correo, no solo por WhatsApp
- #65 sesión del 12-ago SIN MINUTA (hueco abierto a propósito)
- #66 Excel de campos y catálogos de la cotización BIND enviado a Pedro
- #67 WhatsApp 18-20 ago: Pedro reduce el catálogo a 17 categorías, Balam
modifica el formulario de Jira y se agenda el viernes 21-ago con FAC-106
- #68 correo "Seguimiento - PAF" con la convocatoria
Correcciones:
- #3a el correo "en verde" de Araceli apareció íntegro: IBC Bank y tax estándar
dejan de ser inferencia de la llamada del 19-may
- #33 el pendiente de responder a Noé llevaba mes y medio abierto por error
- #62 hora del reenvío del 7-ago: 11:34 am, no 5:34 pm (UTC leída como local)
Evidencia recuperada a fuentes/, incluidos los dos adjuntos que la bitácora
pedía conservar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La entrada remota '#59' colisionaba con las #59–#61 locales; se renumeró a #62
(con nota de merge) y sus referencias en PENDIENTES se ajustaron. El briefing
de Investigacion-API-Jira toma los párrafos del 10-ago y conserva el sondeo
del 6-ago; PENDIENTES queda con la sección nueva del flujo Jira→BIND.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
El wizard de 5 pasos de la VISTA 3 quedó navegable en balam-plataforma con
datos reales de solo lectura (cotizaciones de /api/quotes y ticket FAC vivo):
selección de cotización, datos de factura con regla PPD/PUE y advertencia SAT,
IVA por regla con totales reactivos, prefactura simulada con marca de agua y
aprobación humana visual; el timbrado queda deshabilitado hasta B7 (commits
2164f6c, 90f7633 y 0600f2f en el repo del cliente). Excel de avance del 2.º
corte generado desde script (el corte matutino no se toca); la fila de
conversión cotización→factura pasa a 40% como interfaz en simulación.
El bloque quedó anidado bajo la Etapa 2 en el commit anterior, pero se
pintaba DESPUÉS de las 10 actividades propias de la etapa (29 jul-12 ago)
aunque sus 3 días (27-29 jul) son cronológicamente anteriores — al leer
de arriba a abajo, la fecha retrocedía 2 semanas de golpe. Se movió el
bloque Jira a inmediatamente debajo del encabezado de Etapa 2 y antes de
sus propias actividades: la lectura ahora es monotónica (27, 28, 29, 29,
30, 31 jul... 12 ago) sin perder el anidado visual del turno anterior.
No se tocó el orden interno de Etapa 0/Etapa 1: su ligero traslape de
fechas (el desarrollo de Etapa 1 arrancó mientras se cerraba la
validación de Etapa 0) es agrupación real por etapa contractual, no un
error de orden — desintercalarlas rompería la estructura sin ganar
claridad.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Propuesta: mueve el bloque completo (antecedente, entregables, diagrama,
candados fiscal, exclusiones, dependencia) de después de la Etapa 3 a
justo después de la Etapa 2, y le baja el peso visual — de un div .etapa
de peso igual a las 4 etapas reales, a una caja .ajuste-anidado con
barra de acento, fondo crema y kicker "AJUSTE DENTRO DE LA ETAPA 2"
(h4 bajo el h3 de Etapa 2 en el markdown). La fila de la tabla de
Inversión (§4) se reordena igual, entre Etapa 2 y Etapa 3.
Excel: mismo reordenamiento (Etapa 2 → ajuste Jira → Etapa 3) con relleno
ámbar distinto del crema de una etapa contractual, para que no compita
visualmente como una etapa más.
Cambio incidental: el glifo ↳ no existe en Caladea/Carlito y Chromium
caía a un fallback de sistema (LucidaGrande-Bold) en la fila de la tabla;
se sustituyó por » en los 3 archivos y las fuentes vuelven a embeber limpio.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Recalcula todas las cifras dependientes en la propuesta v1.3: fila Ajuste
$4,200-$6,000, total primera etapa 119-146 h / $71,400-$87,600 (antes
121-148 h / $72,600-$88,800). El bloque de la §2 y su Excel homólogo pasan
de "se ejecuta junto con las Etapas 2-3" a "inicia el lunes 27 de julio
(token PAF ya entregado)", reflejando que la conexión a la API de Jira no
depende de la definición del flujo de facturación, solo del token que
Pedro ya entregó ese día. Las 3 actividades del plan se re-fechan a
27-29/jul y sus rangos siguen sumando exacto el total de la etapa.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reemplaza el enfoque de adenda separada: la propuesta completa sube a v1.3
con la integración Jira→BIND incorporada en §1-2 (bloque de ajuste con
entregables, candados fiscales y exclusiones), §4 (fila Ajuste 9-12 h /
$5,400-$7,200; total 121-148 h / $72,600-$88,800), §7 (supuestos del token
PAF y del flujo) y anexos A/B. PDF reconstruido con fuentes embebidas
(antes dependía de fuentes de Windows) y fixes visuales: flechas en títulos
serif, tabla de inversión sin partir, label A.4 sin huérfano.
El Excel para Erika (Avance-Balam-2026-07-28.xlsx) extiende el formato del
27-jul con Etapas 2-3 y el ajuste Jira desglosados en actividades diarias
cuyos rangos suman exactamente los contractuales; se rebalancearon los
rangos de Etapa 1 (sumaban 34-42 vs 32-39 contractual) recortando las tres
actividades con horas reales muy por debajo del estimado, con asserts que
lo verifican. Verificado con 5 agentes (paridad MD↔HTML, cifras vs
bitácora/CSV, formato y calendario, cobertura de entregables, PDF visual).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Los dos pendientes que Erika re-preguntó el 28-jul: la adenda formaliza la
generación automática de cotizaciones desde tickets FAC ($5,400–$7,200 + IVA,
consistente con las ~10 h comunicadas el 21-jul) como solicitud de cambio
conforme a la §10 de la propuesta v1.2; el Excel resume horas por etapa
(E0 cerrada en 21.83 h, E1 en 19.75 h, E2/E3 con rangos contractuales) con
importes para facturación. PDF con el mismo diseño del paquete v1.2.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Las horas quedan validadas una por una contra evidencia fechada y el Excel
deja de tener cifras escritas a mano: se generan desde Seguimiento-horas.csv
y el script aborta si el detalle no cuadra con el total.
Correcciones de fondo:
- El Excel reportaba 17 h de Etapa 1 contra 16 h en el CSV (override manual).
- Comas sin escapar en el CSV ocultaban 1.00 h del 19-jul al parseo.
- El 10-jul estaba mal etiquetado: la mayor parte fue pulido del prototipo
(E0-05), no el entregable de cierre (E0-06). Mismo total, etiquetas reales.
- Se incorporan 3.50 h no cobradas con evidencia: diseño del plan de Etapa 1
(2.00 h) y preparación de las sesiones del 22 y 24-jul (1.50 h).
- Ajustes a la baja de Johann en horas reconstruidas: análisis del Discovery
1.92→1.00 h, documentación de cobranza 1.50→0.75 h, guion 0.75→0.45 h.
Las duraciones con transcript no se tocaron. Etapa 0 vuelve al rango 18–22 h.
Presentación del avance:
- Se reporta 75 % de Etapa 1 = 6 de 8 entregables cerrados, en lugar del 82 %
ponderado anterior, que no distinguía trabajo hecho de trabajo bloqueado.
- Capa de escritura al 40 % (diseño, ADR-001 y modelo listos; falta el
BindWriteClient y los shapes de los POST) y Jira al 90 % (conectividad
resuelta el 27-jul; falta qué estatus dispara qué, sujeto a la definición
de Balam). Modelo de facturas al 85 % con horas propias: ya no aparece
avanzado con cero horas.
- Las 7 h que acumulaba "Demostración semanal" se reparten a las filas
técnicas que les corresponden; esa fila se queda con gestión (1.75 h).
Nuevo: Avance-Balam-2026-07-27.xlsx, versión simple para Erika, derivada del
Excel interno para que ambos no puedan contradecirse.
Bitácora #58: Erika confirma que el Excel de horas es el insumo de
FACTURACIÓN, corrige su lectura de la capa de escritura al 100 %, y vuelve a
pedir la propuesta ajustada por Jira (pendiente desde el 22-jul). La sesión
del flujo de facturación no queda agendada: Balam la revisa internamente.
- REGISTRO #55: validación del prototipo Etapa 0 (24-jul) APROBADA; único bloqueo = definir el flujo de facturación en Jira (sesión propuesta por Araceli para el martes 28)
- REGISTRO #56: sesión de API de Jira con Pedro (27-jul) — token PAF a 1 año, bandeja FAC; + seguimiento por correo del mismo día con los límites de velocidad (65k puntos/h, burst/s, por-issue) y entrega del token por Google Drive
- REGISTRO #57: hilo de WhatsApp con Erika (21-27 jul) — coordinación, envío del flujo por correo y reagenda 23→24 jul; 3 imágenes inferidas
- Transcripciones y correo en fuentes/; guion de validación en planeacion/
- Avance-Etapa1-2026-07-27 (nota + mensaje para Erika) y Excel del corte del 27-jul (núcleo verificado; capa de escritura en pausa por definición de Balam)
- Seguimiento-horas: sesiones del 24-jul (validación) y 27-jul (API Jira)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Transcript renombrado con fecha, entrada #54 en el REGISTRO, minuta de la
sesión llenada, PENDIENTES al día (PUE/PPD y particularidades de envío no
se tocaron; nuevos compromisos: diagrama Jira y sesión API con Pedro) y
0.80 h confirmadas en el control de horas.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Excel de avance enviado por WhatsApp con acuse de recibo; cierra ese
pendiente y el de permisos de escritura al repo (comprobado con el
push del scaffold). Actualiza fuente #46, REGISTRO y PENDIENTES.
- Plan-Etapa1.md: plan detallado por fases/bloques (B0-B9) con horas,
decisiones de arquitectura y lo bloqueado hasta el 22-jul
- Avance-Etapa1-2026-07-16.md + Excel de avance ordenado por fechas
(con script generador y de ordenamiento)
- WhatsApp 16-jul: invitación al Git recibida, procedimientos de
clientes enviados por correo, Erika pide avance de Etapa 1
- Actualiza PENDIENTES y REGISTRO
- Login de demo (credenciales precargadas arturo@balam.mx) antes de entrar
a la app; el chip de usuario en el sidebar ahora cierra sesión.
- Estado de cuenta · ACUNTIA: F-2026-0034 ilustra el caso real de la
llamada del 7-jul (Arturo cruza pagos con Acuntia y los totales no
cuadran por el fee) — Total/Pagado/Saldo alineados para comparar de un
vistazo, más la alerta que traduce el residual ($180 MXN, dentro del
umbral de $200) a lenguaje llano.
Antes solo la fila de ACUNTIA abría un panel embebido en la página; las
otras tres mostraban un toast aclarando que era demo. Ahora las 4 abren
el mismo modal (backdrop oscuro, cierra con click fuera o Escape),
consistente con el pedido de revisar Cobranza para la reunión de mañana.
Mostraba COT-2026-0448 (mismo cliente, proyecto de Arq. Jorge Salinas) como
alternativa seleccionable, sin indicar que pertenece a otro ticket
(FAC-0868, ya facturado) — confuso, riesgo de elegir la cotización
equivocada. El paso 1 ahora solo confirma la cotización vinculada al
ticket; se quita pickQuote() por quedar sin uso.
Era equivalente a activar el filtro "Listos para facturar" en Solicitudes
(Jira) — mismos 3 tickets, sin aportar nada nuevo. El wizard de emisión
sigue accesible desde el detalle de una solicitud ("Iniciar facturación").
Antes el ítem del sidebar abría directo el wizard hardcodeado de FAC-0876,
igual que "Iniciar facturación" desde la solicitud — dos accesos al mismo
destino sin explicar el badge de "3". Ahora tiene su propia bandeja con los
3 tickets "listos para facturar" (mismo criterio que el filtro en
Solicitudes); solo FAC-0876 abre el wizard completo, los otros dos
muestran un toast que deja claro que es demo. Cancelar en el paso 1 regresa
a esta bandeja en vez de saltar a Solicitudes.
JohannVelazquez