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/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).