Anida el ajuste Jira→BIND dentro de la Etapa 2 (antes leía como una 5ª etapa)

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>

planeacion/generar_plan_completo_2026_07_28.py

@@ -170,7 +170,7 @@ ETAPA3 = ("Etapa 3 — Cobranza, tablero, reportes y cierre",
      "24/08/2026", "04/09/2026", "—", "⚪ Incluida en el cierre · sin costo"),
 ])
 
-JIRA = ("Integración Jira → BIND (ajuste propuesta v1.3, en aprobación)",
+JIRA = ("» Ajuste dentro de la Etapa 2: Integración Jira → BIND (en aprobación, v1.3)",
         "27/07/2026", "29/07/2026", 7, 10, [
     ("Cliente de la API de Jira (token PAF): lectura de tickets FAC y control de límites",
      "27/07/2026", "27/07/2026", "2–3", PROX_JIRA),
@@ -225,7 +225,7 @@ for i, (txt, ancho) in enumerate(zip(ENC, ANCHOS), start=1):
 ws.row_dimensions[FILA_ENC].height = 26
 
 
-def pinta_fila(r, nombre, ini, fin, pct, est, trab, stat, etapa=False):
+def pinta_fila(r, nombre, ini, fin, pct, est, trab, stat, etapa=False, fill=None):
     c = ws.cell(row=r, column=1, value=nombre)
     c.font = Font(bold=etapa, size=10, color=CAFE)
     c.alignment = Alignment(vertical="center", wrap_text=True, indent=0 if etapa else 1)
@@ -270,7 +270,7 @@ def pinta_fila(r, nombre, ini, fin, pct, est, trab, stat, etapa=False):
     for col in range(1, 8):
         ws.cell(row=r, column=col).border = box
         if etapa and col in (1, 2, 3):
-            ws.cell(row=r, column=col).fill = PatternFill("solid", fgColor=CREMA)
+            ws.cell(row=r, column=col).fill = PatternFill("solid", fgColor=fill or CREMA)
 
 
 r = FILA_ENC + 1
@@ -283,8 +283,14 @@ for f in hechas:
                f["stat"], etapa=f["etapa"])
     r += 1
 
-for titulo, ini, fin, lo, hi, acts in (ETAPA2, ETAPA3, JIRA):
+for seccion in (ETAPA2, JIRA, ETAPA3):
-    pinta_fila(r, titulo, ini, fin, 0, f"{lo}–{hi}", None, "", etapa=True)
+    titulo, ini, fin, lo, hi, acts = seccion
+    # El ajuste Jira se pinta ANIDADO dentro de la Etapa 2 (mismo lugar en la
+    # propuesta): relleno ámbar "pendiente" en vez del crema de una etapa
+    # contractual, y prefijo "»" para que no se lea como una 5ª etapa.
+    es_jira = seccion is JIRA
+    pinta_fila(r, titulo, ini, fin, 0, f"{lo}–{hi}", None, "", etapa=True,
+               fill=A_FILL if es_jira else None)
     r += 1
     for nombre, aini, afin, est, stat in acts:
         pinta_fila(r, nombre, aini, afin, 0, est, None, stat)
@@ -303,11 +309,13 @@ notas = [
      "y están sujetas a la definición del flujo de facturación (en revisión interna "
      "de Balam) y al acceso a Azure. El soporte post-lanzamiento (2 semanas, sin "
      "costo) corre del 24-ago al 4-sep, después del cierre.", False),
-    ("Integración Jira → BIND (7–10 h): ajuste no contemplado en la propuesta "
+    ("Integración Jira → BIND (7–10 h), señalada con » dentro de la Etapa 2: "
-     "original, incorporado en la propuesta ajustada v1.3; se ejecuta tras su "
+     "ajuste no contemplado en la propuesta original, incorporado en la propuesta "
-     "aprobación por escrito y una vez definido el flujo. Se programó a partir "
+     "ajustada v1.3; se ejecuta tras su aprobación por escrito y una vez definido "
-     "del lunes 27-jul —día en que Pedro entregó el token PAF— en paralelo con "
+     "el flujo. Se agrupa junto a la Etapa 2 porque automatiza el mismo entregable "
-     "el cierre de la Etapa 1 y el arranque de la Etapa 2.", False),
+     "(creación de cotizaciones); se programó a partir del lunes 27-jul —día en que "
+     "Pedro entregó el token PAF— en paralelo con el cierre de la Etapa 1 y el "
+     "arranque de la Etapa 2.", False),
     (f"Total del plan con el ajuste: {TOT_MIN:.0f}–{TOT_MAX:.0f} h. El avance global "
      f"({PCT_GLOBAL:.0%}) se calcula sobre el plan completo; el corte anterior (80%) "
      "se calculaba solo sobre las Etapas 0-1.", False),

propuesta/00 - PROPUESTA-COMERCIAL.md

@@ -125,7 +125,7 @@ La selección tecnológica privilegia robustez empresarial, mantenibilidad a lar
 
 > **Sobre las versiones.** Las versiones indicadas son la referencia vigente a mayo de 2026; se fijan al inicio del proyecto sobre la rama estable/LTS de cada tecnología. Se prioriza **.NET 10** por ser versión de soporte extendido (LTS), apropiada para una aplicación financiera de largo plazo.
 
-El proyecto se organiza en cuatro etapas secuenciales, más el **ajuste Jira → BIND** incorporado en julio de 2026 (al final de esta sección). Cada bloque concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).
+El proyecto se organiza en cuatro etapas secuenciales, más el **ajuste Jira → BIND** incorporado en julio de 2026 dentro de la Etapa 2 (ver más abajo). Cada bloque concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).
 
 ### Etapa 0 — Discovery, infraestructura y prototipo visual · *Semana 1 · 18 – 22 h*
 
@@ -179,6 +179,27 @@ El proyecto se organiza en cuatro etapas secuenciales, más el **ajuste Jira →
 
 > **Fuera de esta etapa:** generación automática de facturas desde eventos de negocio (Jira → BUK → factura), soporte EUR e integración con BUK. El timbrado CFDI permanece a cargo del PAC de BIND.
 
+#### » Ajuste dentro de la Etapa 2 — Integración Jira → BIND (jul-2026) · *inicia el lunes 27 de julio (token PAF ya entregado) · 7 – 10 h*
+
+**Antecedente.** La versión anterior de esta propuesta dejó Jira fuera del alcance conforme a la información disponible al cotizar. En las sesiones del 22, 24 y 27 de julio la dirección confirmó que el proceso interno evolucionó — todo el flujo de facturación nace y se gobierna en Jira — y quedó confirmada la viabilidad técnica: la API de Jira cubre lectura y escritura de tickets, se entregó el token de integración (**"PAF"**, vigente al 27-jul-2027) y se documentaron los límites de consumo de Atlassian. La estimación (~10 h) se comunicó a la PM el 21 de julio; esta sección la formaliza conforme al control de cambios (§10). Se agrupa aquí, dentro de la Etapa 2, porque automatiza exactamente el mismo entregable de esa etapa — **creación de cotizaciones** — solo que a partir de un ticket de Jira en vez de captura manual.
+
+**Entregables:**
+
+- **Conexión con la API de Jira** mediante el token PAF y lectura de los tickets de la bandeja **Facturación (`FAC-`)**, con consumo autorregulado conforme a los límites de velocidad documentados por Atlassian.
+- **Generación automática de la cotización en BIND** cuando un ticket alcanza el estatus disparador que Balam defina (candidato natural: la entrada del ticket al proceso de facturación, previo a "resuelto"), a través de la misma capa de escritura controlada del MVP.
+- **Trazabilidad ticket ↔ cotización ↔ prefactura/factura**, visible en la plataforma y registrada en la bitácora de auditoría; los tickets leídos alimentan además la vista *"qué necesita atención"* del tablero.
+- **Pruebas controladas:** scripts de consulta y de creación/edición sobre un registro de prueba, y una **prueba observada** con el equipo de Balam antes de habilitar la generación automática en operación.
+
+```
+Ticket Jira (FAC) → Cotización BIND (automática) → Prefactura → Aprobación humana → Timbrado (PAC de BIND)
+```
+
+> **El control fiscal no cambia.** La integración crea **cotizaciones, nunca facturas**: se mantiene la cadena acordada — cotización → prefactura → **aprobación humana** → timbrado por el PAC de BIND — con modo de simulación (*dry-run*), feature flag y registro en bitácora. No existe timbrado automático.
+
+**No incluye:** (a) el **alta automática de clientes en BIND** — si el cliente del ticket no existe, la plataforma lo detecta y lo notifica; darlo de alta automáticamente es una decisión de proceso abierta que, de aprobarse, se estima por separado; (b) **tickets con múltiples facturas** — el supuesto es *un ticket → una cotización*; el manejo del caso masivo se define junto con Balam y, si requiere desarrollo adicional, se estima por separado; (c) **otros usos de Jira** (reporteo de horas de consultores, tableros sobre otras bandejas, espacio comercial) y los módulos del Anexo B.
+
+> **Dependencia clave.** La implementación inicia una vez que Balam cierre la **definición del flujo de facturación** (en revisión interna), de la cual salen el estatus disparador y las reglas de prefactura.
+
 ### Etapa 3 — Cobranza, tablero, reportes y cierre · *Semanas 6-7 · 24 – 29 h*
 
 **Objetivo.** Cerrar el flujo operativo con visibilidad para Dirección y realizar la entrega formal.
@@ -198,27 +219,6 @@ El proyecto se organiza en cuatro etapas secuenciales, más el **ajuste Jira →
 
 > **Fuera de esta etapa:** recordatorios automáticos a clientes, pagos en línea, conciliación bancaria, asientos contables automáticos e integración bancaria en vivo.
 
-### Integración Jira → BIND — ajuste de alcance (jul-2026) · *inicia el lunes 27 de julio (token PAF ya entregado) · 7 – 10 h*
-
-**Antecedente.** La versión anterior de esta propuesta dejó Jira fuera del alcance conforme a la información disponible al cotizar. En las sesiones del 22, 24 y 27 de julio la dirección confirmó que el proceso interno evolucionó — todo el flujo de facturación nace y se gobierna en Jira — y quedó confirmada la viabilidad técnica: la API de Jira cubre lectura y escritura de tickets, se entregó el token de integración (**"PAF"**, vigente al 27-jul-2027) y se documentaron los límites de consumo de Atlassian. La estimación (~10 h) se comunicó a la PM el 21 de julio; esta sección la formaliza conforme al control de cambios (§10).
-
-**Entregables:**
-
-- **Conexión con la API de Jira** mediante el token PAF y lectura de los tickets de la bandeja **Facturación (`FAC-`)**, con consumo autorregulado conforme a los límites de velocidad documentados por Atlassian.
-- **Generación automática de la cotización en BIND** cuando un ticket alcanza el estatus disparador que Balam defina (candidato natural: la entrada del ticket al proceso de facturación, previo a "resuelto"), a través de la misma capa de escritura controlada del MVP.
-- **Trazabilidad ticket ↔ cotización ↔ prefactura/factura**, visible en la plataforma y registrada en la bitácora de auditoría; los tickets leídos alimentan además la vista *"qué necesita atención"* del tablero.
-- **Pruebas controladas:** scripts de consulta y de creación/edición sobre un registro de prueba, y una **prueba observada** con el equipo de Balam antes de habilitar la generación automática en operación.
-
-```
-Ticket Jira (FAC) → Cotización BIND (automática) → Prefactura → Aprobación humana → Timbrado (PAC de BIND)
-```
-
-> **El control fiscal no cambia.** La integración crea **cotizaciones, nunca facturas**: se mantiene la cadena acordada — cotización → prefactura → **aprobación humana** → timbrado por el PAC de BIND — con modo de simulación (*dry-run*), feature flag y registro en bitácora. No existe timbrado automático.
-
-**No incluye:** (a) el **alta automática de clientes en BIND** — si el cliente del ticket no existe, la plataforma lo detecta y lo notifica; darlo de alta automáticamente es una decisión de proceso abierta que, de aprobarse, se estima por separado; (b) **tickets con múltiples facturas** — el supuesto es *un ticket → una cotización*; el manejo del caso masivo se define junto con Balam y, si requiere desarrollo adicional, se estima por separado; (c) **otros usos de Jira** (reporteo de horas de consultores, tableros sobre otras bandejas, espacio comercial) y los módulos del Anexo B.
-
-> **Dependencia clave.** La implementación inicia una vez que Balam cierre la **definición del flujo de facturación** (en revisión interna), de la cual salen el estatus disparador y las reglas de prefactura.
-
 ---
 
 ## 3. Modelo de colaboración
@@ -278,8 +278,8 @@ La inversión de la primera etapa se desglosa por entregable, conforme al esquem
 | 0 | Discovery, infraestructura Azure y **prototipo visual navegable** | 18 – 22 | $10,800 – $13,200 |
 | 1 | Plataforma base, sincronización con BIND y capa de escritura | 32 – 39 | $19,200 – $23,400 |
 | 2 | Facturación (consulta y **emisión** MXN/USD), catálogo y multimoneda | 38 – 46 | $22,800 – $27,600 |
+| » Ajuste (dentro de la Etapa 2) | **Integración Jira → BIND** (lectura de la bandeja FAC, cotización automática, trazabilidad y pruebas) — jul-2026 | 7 – 10 | $4,200 – $6,000 |
 | 3 | Cobranza, tablero, reportes y cierre | 24 – 29 | $14,400 – $17,400 |
-| Ajuste jul-2026 | **Integración Jira → BIND** (lectura de la bandeja FAC, cotización automática, trazabilidad y pruebas) | 7 – 10 | $4,200 – $6,000 |
 | **Total primera etapa** | | **119 – 146 h** | **$71,400 – $87,600** |
 
 > Cifras antes de IVA. Plazo estimado: **6 – 8 semanas** a media jornada (~20 h/semana, con flexibilidad hasta 25 h en semanas pico).

propuesta/Propuesta-Balam.html

@@ -182,6 +182,14 @@
   .etapa .et-t{ font-family:var(--serif); font-size:13pt; font-weight:700; color:var(--ink); line-height:1.2; }
   .etapa .et-meta{ font-family:var(--sans); font-size:8.5pt; font-weight:700; letter-spacing:.05em; text-transform:uppercase; color:var(--accent-d); margin-top:3pt; }
 
+  /* nested sub-block: an add-on that belongs to the PRECEDING .etapa, not a phase of its own */
+  .ajuste-anidado{ margin:12pt 0 14pt 10pt; padding:10pt 14pt 11pt; background:var(--cream); border-left:2.5pt solid var(--accent); border-radius:0 5pt 5pt 0; break-inside:avoid; }
+  .ajuste-anidado .aj-kick{ font-family:var(--sans); font-size:7.6pt; font-weight:700; letter-spacing:.14em; text-transform:uppercase; color:var(--accent-d); }
+  .ajuste-anidado .aj-t{ font-family:var(--serif); font-size:12pt; font-weight:700; color:var(--ink); line-height:1.2; margin-top:2pt; }
+  .ajuste-anidado .aj-meta{ font-family:var(--sans); font-size:8.5pt; font-weight:700; letter-spacing:.03em; color:var(--muted); margin-top:3pt; }
+  .ajuste-anidado > .aj-body{ margin-top:9pt; }
+  .ajuste-anidado p, .ajuste-anidado ul{ margin:6pt 0; }
+
   /* ---------------- TABLES ---------------- */
   table{ width:100%; border-collapse:collapse; margin:10pt 0; font-size:9.2pt; }
   thead{ display:table-header-group; }
@@ -447,7 +455,7 @@
 
   <div class="callout"><strong>Sobre las versiones.</strong> Las versiones indicadas son la referencia vigente a mayo de 2026; se fijan al inicio del proyecto sobre la rama estable/LTS de cada tecnología. Se prioriza <strong>.NET 10</strong> por ser versión de soporte extendido (LTS), apropiada para una aplicación financiera de largo plazo.</div>
 
-  <p>El proyecto se organiza en cuatro etapas secuenciales, más el <strong>ajuste Jira → BIND</strong> incorporado en julio de 2026 (al final de esta sección). Cada bloque concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).</p>
+  <p>El proyecto se organiza en cuatro etapas secuenciales, más el <strong>ajuste Jira → BIND</strong> incorporado en julio de 2026 dentro de la Etapa 2 (ver más abajo). Cada bloque concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).</p>
 
   <div class="etapa"><div class="et-t">Etapa 0 — Discovery, infraestructura y prototipo visual</div><div class="et-meta">Semana 1 · 18 – 22 h</div></div>
   <p><strong>Objetivo.</strong> Validar el comportamiento real de la API de BIND con la cuenta de Balam, preparar la infraestructura en Azure, dejar el repositorio operativo y <strong>entregar un prototipo visual navegable</strong> que alinee expectativas de producto antes de iniciar el desarrollo del backend.</p>
@@ -495,6 +503,38 @@
   </ul>
   <div class="callout cool"><strong>Fuera de esta etapa:</strong> generación automática de facturas desde eventos de negocio (Jira → BUK → factura), soporte EUR e integración con BUK. El timbrado CFDI permanece a cargo del PAC de BIND.</div>
 
+  <div class="ajuste-anidado">
+    <div class="aj-kick">Ajuste dentro de la Etapa 2</div>
+    <div class="aj-t">Integración Jira <span class="aw">→</span> BIND (jul-2026)</div>
+    <div class="aj-meta">Inicia el lunes 27 de julio (token PAF ya entregado) · 7 – 10 h</div>
+
+    <div class="aj-body">
+    <p><strong>Antecedente.</strong> La versión anterior de esta propuesta dejó Jira fuera del alcance conforme a la información disponible al cotizar. En las sesiones del 22, 24 y 27 de julio la dirección confirmó que el proceso interno evolucionó — todo el flujo de facturación nace y se gobierna en Jira — y quedó confirmada la viabilidad técnica: la API de Jira cubre lectura y escritura de tickets, se entregó el token de integración (<strong>"PAF"</strong>, vigente al 27-jul-2027) y se documentaron los límites de consumo de Atlassian. La estimación (~10 h) se comunicó a la PM el 21 de julio; esta sección la formaliza conforme al control de cambios (§10). Se agrupa aquí, dentro de la Etapa 2, porque automatiza exactamente el mismo entregable de esa etapa —<strong>creación de cotizaciones</strong>— solo que a partir de un ticket de Jira en vez de captura manual.</p>
+
+    <p><strong>Entregables:</strong></p>
+    <ul>
+      <li><strong>Conexión con la API de Jira</strong> mediante el token PAF y lectura de los tickets de la bandeja <strong>Facturación (<code>FAC-</code>)</strong>, con consumo autorregulado conforme a los límites de velocidad documentados por Atlassian.</li>
+      <li><strong>Generación automática de la cotización en BIND</strong> cuando un ticket alcanza el estatus disparador que Balam defina (candidato natural: la entrada del ticket al proceso de facturación, previo a "resuelto"), a través de la misma capa de escritura controlada del MVP.</li>
+      <li><strong>Trazabilidad ticket ↔ cotización ↔ prefactura/factura</strong>, visible en la plataforma y registrada en la bitácora de auditoría; los tickets leídos alimentan además la vista <em>"qué necesita atención"</em> del tablero.</li>
+      <li><strong>Pruebas controladas:</strong> scripts de consulta y de creación/edición sobre un registro de prueba, y una <strong>prueba observada</strong> con el equipo de Balam antes de habilitar la generación automática en operación.</li>
+    </ul>
+
+    <div class="flow">
+      <span class="chip">Ticket Jira <small>(FAC)</small></span><span class="arrow">→</span>
+      <span class="chip accent">Cotización BIND <small>(automática)</small></span><span class="arrow">→</span>
+      <span class="chip">Prefactura</span><span class="arrow">→</span>
+      <span class="chip">Aprobación humana</span><span class="arrow">→</span>
+      <span class="chip">Timbrado <small>(PAC de BIND)</small></span>
+    </div>
+
+    <div class="callout"><strong>El control fiscal no cambia.</strong> La integración crea <strong>cotizaciones, nunca facturas</strong>: se mantiene la cadena acordada — cotización → prefactura → <strong>aprobación humana</strong> → timbrado por el PAC de BIND — con modo de simulación (<em>dry-run</em>), feature flag y registro en bitácora. No existe timbrado automático.</div>
+
+    <p><strong>No incluye:</strong> (a) el <strong>alta automática de clientes en BIND</strong> — si el cliente del ticket no existe, la plataforma lo detecta y lo notifica; darlo de alta automáticamente es una decisión de proceso abierta que, de aprobarse, se estima por separado; (b) <strong>tickets con múltiples facturas</strong> — el supuesto es <em>un ticket → una cotización</em>; el manejo del caso masivo se define junto con Balam y, si requiere desarrollo adicional, se estima por separado; (c) <strong>otros usos de Jira</strong> (reporteo de horas de consultores, tableros sobre otras bandejas, espacio comercial) y los módulos del Anexo B.</p>
+
+    <div class="callout cool"><strong>Dependencia clave.</strong> La implementación inicia una vez que Balam cierre la <strong>definición del flujo de facturación</strong> (en revisión interna), de la cual salen el estatus disparador y las reglas de prefactura.</div>
+    </div>
+  </div>
+
   <div class="etapa"><div class="et-t">Etapa 3 — Cobranza, tablero, reportes y cierre</div><div class="et-meta">Semanas 6-7 · 24 – 29 h</div></div>
   <p><strong>Objetivo.</strong> Cerrar el flujo operativo con visibilidad para Dirección y realizar la entrega formal.</p>
   <div class="mini-label">Entregables</div>
@@ -511,32 +551,6 @@
     <li>Transferencia y soporte posterior al lanzamiento de 2 semanas (corrección de defectos).</li>
   </ul>
   <div class="callout cool"><strong>Fuera de esta etapa:</strong> recordatorios automáticos a clientes, pagos en línea, conciliación bancaria, asientos contables automáticos e integración bancaria en vivo.</div>
-
-  <div class="etapa"><div class="et-t">Integración Jira <span class="aw">→</span> BIND — ajuste de alcance (jul-2026)</div><div class="et-meta">Inicia el lunes 27 de julio (token PAF ya entregado) · 7 – 10 h</div></div>
-
-  <p><strong>Antecedente.</strong> La versión anterior de esta propuesta dejó Jira fuera del alcance conforme a la información disponible al cotizar. En las sesiones del 22, 24 y 27 de julio la dirección confirmó que el proceso interno evolucionó — todo el flujo de facturación nace y se gobierna en Jira — y quedó confirmada la viabilidad técnica: la API de Jira cubre lectura y escritura de tickets, se entregó el token de integración (<strong>"PAF"</strong>, vigente al 27-jul-2027) y se documentaron los límites de consumo de Atlassian. La estimación (~10 h) se comunicó a la PM el 21 de julio; esta sección la formaliza conforme al control de cambios (§10).</p>
-
-  <p><strong>Entregables:</strong></p>
-  <ul>
-    <li><strong>Conexión con la API de Jira</strong> mediante el token PAF y lectura de los tickets de la bandeja <strong>Facturación (<code>FAC-</code>)</strong>, con consumo autorregulado conforme a los límites de velocidad documentados por Atlassian.</li>
-    <li><strong>Generación automática de la cotización en BIND</strong> cuando un ticket alcanza el estatus disparador que Balam defina (candidato natural: la entrada del ticket al proceso de facturación, previo a "resuelto"), a través de la misma capa de escritura controlada del MVP.</li>
-    <li><strong>Trazabilidad ticket ↔ cotización ↔ prefactura/factura</strong>, visible en la plataforma y registrada en la bitácora de auditoría; los tickets leídos alimentan además la vista <em>"qué necesita atención"</em> del tablero.</li>
-    <li><strong>Pruebas controladas:</strong> scripts de consulta y de creación/edición sobre un registro de prueba, y una <strong>prueba observada</strong> con el equipo de Balam antes de habilitar la generación automática en operación.</li>
-  </ul>
-
-  <div class="flow">
-    <span class="chip">Ticket Jira <small>(FAC)</small></span><span class="arrow">→</span>
-    <span class="chip accent">Cotización BIND <small>(automática)</small></span><span class="arrow">→</span>
-    <span class="chip">Prefactura</span><span class="arrow">→</span>
-    <span class="chip">Aprobación humana</span><span class="arrow">→</span>
-    <span class="chip">Timbrado <small>(PAC de BIND)</small></span>
-  </div>
-
-  <div class="callout"><strong>El control fiscal no cambia.</strong> La integración crea <strong>cotizaciones, nunca facturas</strong>: se mantiene la cadena acordada — cotización → prefactura → <strong>aprobación humana</strong> → timbrado por el PAC de BIND — con modo de simulación (<em>dry-run</em>), feature flag y registro en bitácora. No existe timbrado automático.</div>
-
-  <p><strong>No incluye:</strong> (a) el <strong>alta automática de clientes en BIND</strong> — si el cliente del ticket no existe, la plataforma lo detecta y lo notifica; darlo de alta automáticamente es una decisión de proceso abierta que, de aprobarse, se estima por separado; (b) <strong>tickets con múltiples facturas</strong> — el supuesto es <em>un ticket → una cotización</em>; el manejo del caso masivo se define junto con Balam y, si requiere desarrollo adicional, se estima por separado; (c) <strong>otros usos de Jira</strong> (reporteo de horas de consultores, tableros sobre otras bandejas, espacio comercial) y los módulos del Anexo B.</p>
-
-  <div class="callout cool"><strong>Dependencia clave.</strong> La implementación inicia una vez que Balam cierre la <strong>definición del flujo de facturación</strong> (en revisión interna), de la cual salen el estatus disparador y las reglas de prefactura.</div>
 </section>
 <!-- ===== 3. MODELO DE COLABORACIÓN ===== -->
 <section class="sec">
@@ -594,8 +608,8 @@
       <tr><td class="k ctr">0</td><td>Discovery, infraestructura Azure y <strong>prototipo visual navegable</strong></td><td class="num">18 – 22</td><td class="num">$10,800 – $13,200</td></tr>
       <tr><td class="k ctr">1</td><td>Plataforma base, sincronización con BIND y capa de escritura</td><td class="num">32 – 39</td><td class="num">$19,200 – $23,400</td></tr>
       <tr><td class="k ctr">2</td><td>Facturación (consulta y <strong>emisión</strong> MXN/USD), catálogo y multimoneda</td><td class="num">38 – 46</td><td class="num">$22,800 – $27,600</td></tr>
+      <tr><td class="k ctr">»</td><td><strong>Integración Jira → BIND</strong> (dentro de la Etapa 2 — lectura de la bandeja FAC, cotización automática, trazabilidad y pruebas) — jul-2026</td><td class="num">7 – 10</td><td class="num">$4,200 – $6,000</td></tr>
       <tr><td class="k ctr">3</td><td>Cobranza, tablero, reportes y cierre</td><td class="num">24 – 29</td><td class="num">$14,400 – $17,400</td></tr>
-      <tr><td class="k ctr">Ajuste</td><td><strong>Integración Jira → BIND</strong> (lectura de la bandeja FAC, cotización automática, trazabilidad y pruebas) — jul-2026</td><td class="num">7 – 10</td><td class="num">$4,200 – $6,000</td></tr>
       <tr class="total"><td colspan="2">Total primera etapa</td><td class="num">119 – 146 h</td><td class="num">$71,400 – $87,600</td></tr>
     </tbody>
   </table>