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>

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>