decision-draw

decision-draw — Panorama General y Aprobación Final para Decisiones Agrupadas

Cuando hay cinco o diez decisiones pendientes, uno fácilmente se pierde en los detalles de las opciones aisladas y pierde de vista el sistema emergente. decision-draw no describe las alternativas; dibuja el conjunto funcional: ¿Cómo cooperan los sistemas una vez que todas las recomendaciones están en su lugar? El usuario aprueba el panorama en su conjunto o proporciona comentarios específicos.

---

Cuándo usar

• Múltiples decisiones interdependientes (de decision-briefing o un documento de resumen de decisiones) no deben ser procesadas como una tediosa lista de verificación de preguntas individuales.
• El usuario quiere ver cómo los componentes realmente interactúan en la práctica diaria después de la implementación, antes de aprobarlos.
• Un grupo de decisiones estrechamente acopladas identificadas a través del gráfico de dependencias (decision-path) puede ser aprobado como una unidad funcional.
• Palabras clave: /decision-draw, "¿cómo se ve todo si estamos de acuerdo con todo?", "dibuja el panorama general", "concepto general de decisión", "decision draw", "¿cómo funcionan los sistemas juntos después?", "imagen de aprobación general".
• No usar:
  • Cuando el usuario quiere evaluar opciones distintas por elemento y elegir mediante letras (A/B/C) — eso lo hace decision-briefing.
  • Para análisis puro de causalidad y cuellos de botella en la terminal — eso lo hace decision-path.
  • Para evaluaciones de opciones aisladas en bloques discretos de 5 partes (contexto, pro/contra por opción, recomendación) para problemas únicos o preguntas agrupadas — eso lo hace decision-shot.
  • Para evaluar metódicamente una única cuestión política abierta — eso lo hace decide.

---

Límites en la Familia de Decisiones

Habilidad	UX y Enfoque	Postura sobre las Opciones	Modo de Aprobación
decision-briefing	Descompone en elementos individuales	Muestra todas las opciones A/B/C/D	Códigos de letras (1A 2C 3B)
decision-path	Estructura causalidades	Evalúa opciones en gráfico	Diagnóstico de terminal (ASCII)
decision-draw	Imagen objetivo cohesiva (agrupa decisiones interdependientes)	Describe solo la variante recomendada (alternativas enlazadas)	Aprobación holística o frase de corrección
decision-shot	Bloques discretos estructurados (para problemas únicos o grupos reducidos)	Muestra opciones con 2–4 viñetas de pro/contra	Decisión ejecutiva / revisión individual
decide	Elabora un problema único	Matriz de evaluación (criterios)	Recomendación analítica

Regla Fundamental: decision-draw describe exclusivamente la variante recomendada. Las alternativas descartadas no han desaparecido — están documentadas en decision-briefing, decision-shot o tickets enlazados, y se hace referencia a ellas en la tabla de encabezado. Un dibujo sin este enlace le quita al usuario la elección en lugar de simplificarla.

---

Estructura Obligatoria (Siete Partes)

Un decision-draw completo sigue estrictamente esta estructura de siete partes:

1. Lote y Alcance

Resumen tabular de todos los elementos incluidos en el lote:

• Abreviatura / ID (ej. BH-A, MD-A, CF-A)
• Referencia del ticket
• Título breve del elemento
• Recomendación asumida (la premisa de este panorama general)
• Confianza de decision-avatar (🟢 documentado, 🟡 compensación, 🔴 necesita escalada)
• Enlace al análisis completo / alternativas

2. Concepto

El estado objetivo en prosa cohesiva:

• ¿Qué panorama del sistema o flujo de trabajo surge cuando todas las recomendaciones se ejecutan exactamente según lo planeado?
• Sin comparación de opciones en paralelo, sin titubeos en subjuntivo ("también se podría").
• Modo indicativo claro y seguro: Así es como opera el sistema en su estado objetivo.

3. Interacción

El núcleo funcional de la habilidad:

• ¿Cómo se entrelazan realmente los componentes decididos después de la implementación?
• Enmarcado a lo largo de un flujo operativo concreto de extremo a extremo (ej. "Un ticket llega → el agente inicia → el backend asigna → despliega en el host") en lugar de una lista estática de componentes.
• Aclara flujos de datos, interfaces y responsabilidades operativas.

4. Implementación

La secuencia concreta de pasos de implementación:

• ¿Qué sucede en la práctica, paso a paso?
• Hereda la secuencia de ejecución y la lógica de dependencias directamente de decision-path.
• Los flujos de trabajo independientes se representan honestamente como pistas paralelas (no inventar cadenas causales artificiales; un lote puede consistir en múltiples pistas paralelas). La ordenación secuencial solo se afirma donde existen dependencias o plazos comprobados.
• Destaca puntos de control, scripts de migración y comprobaciones de validación.

5. Lo Que Este Panorama No Cubre

Defensa de límites contra una falsa completitud:

• ¿Qué preguntas secundarias, problemas no resueltos o confianzas 🔴 se excluyen deliberadamente?
• ¿Dónde están las líneas límite con los sistemas vecinos?
• Una imagen que oculta sus márgenes produce una falsa sensación de seguridad.

6. Aprobación

La interacción del usuario:

• El usuario revisa el panorama en su conjunto.
• Opción de respuesta 1: Aprobación general explícita ("Se ve bien", "Aprobado", "Implementar todo como se propuso"). Solo en este caso todos los elementos del lote se registran como decididos.
• Opción de respuesta 2: Corrección específica en lenguaje natural ("Prefiero la variante más pequeña para BH-A", "Sin reinicio automático para MD-A", "Mantener VM-A como está"). Esto desencadena la descomposición en decisiones discretas; todos los elementos no corregidos permanecen abiertos.

7. Transferencia Inversa

La traducción sistemática de los comentarios del usuario en asientos contables individuales:

• Sin Coreserva Automática: Los elementos no modificados se reservan solo ante una aprobación general explícita. ¡Una corrección parcial no es una aprobación general!
• Aislamiento ante Corrección: Si el usuario envía una corrección, se descompone en decisiones individuales; todos los demás elementos del lote permanecen estrictamente abiertos (en tickets fuente / libro contable) hasta que el usuario acepte la imagen ajustada en su totalidad o confirme los elementos restantes individualmente.
• Tabla de Transferencia Inversa Obligatoria: Cada comentario parcial genera una tabla de evaluación estructurada con cuatro columnas:
  1. Corrección Original: Declaración textual del usuario.
  2. Claves Afectadas: Qué IDs del lote se modifican (incluyendo impactos múltiples cuando una declaración toca varias decisiones).
  3. Estado de Dominó: Qué nodos dependientes o supuestos posteriores en decision-path colapsan o requieren reevaluación.
  4. Ambigüedades Abiertas: Dónde la corrección permite múltiples interpretaciones que requieren aclaración antes de la reserva.
• Manejo de Impactos Múltiples: Una sola declaración del usuario puede modificar varias decisiones simultáneamente. La transferencia inversa debe desenredar este acoplamiento y capturar todas las claves afectadas juntas.
• Ruta de Escritura Exclusiva a través de la Fase 4: decision-draw no tiene una ruta de escritura nativa a tickets o registros. Las actualizaciones del libro contable ocurren exclusivamente a través del protocolo estandarizado en decision-briefing Fase 4 (registro y persistencia en DECIDED-AND-DONE.md o TO-DECIDE-USER.txt).

---

Ejemplo (Conjunto de Datos Piloto: Ticket-Master 2026-09-13 — Clúster BACH y del Sistema)

Lote real del resumen de decisiones de Ticket-Master con fecha 2026-09-13: BH-A, MD-A, CF-A, VM-A, PD-A.

# DECISION-DRAW: Clúster Central BACH e Integridad Operativa

## 1. Lote y Alcance

| Clave | Ticket / Fuente | Tema | Recomendación Asumida | Confianza | Alternativas y Detalles |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | Backend de modelo = Heart | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Despliegue y reinicio en Mac | A1 + script (solo informe para 24/7) | 🟢 | Ticket `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | Objetivos de configuración entre hosts | 1C (justificado) / 2B (dependiente del host) / 3B (alto) | 🟢 / 🟡 | Ticket `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | Zona horaria del VersicherungsManager | A (configuración para toda la aplicación como routinika) | 🟢 | Ticket `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | Visibilidad de página USMC | A (alinear declaración a público, statu quo) | 🟢 | Ticket `T-20260913-609930207.txt` |

*Nota: Todas las alternativas descartadas (ej. BH-A E5=B ocean-heart, MD-A A2 claves de escritura completa, VM-A B zonas por perfil) permanecen documentadas en el resumen de decisiones de Ticket-Master.*

---

## 2. Concepto

Establecemos una arquitectura limpia y desacoplada de múltiples hosts donde el backend del modelo se opera como un módulo central independiente llamado `agents-heart`. Los roles, derechos y presupuestos se mantienen limpiamente en una base de datos SQLite relacional, mientras que las decisiones de enrutamiento del modelo ocurren en dos etapas: BACH construye el conjunto candidato calificado por dominio, y clutch selecciona el modelo óptimo en costo y capacidad dentro de ese conjunto.

En la Mac Studio, los servicios en segundo plano 24/7 operan de manera segura y confiable usando una clave de despliegue de solo lectura; las actualizaciones de código se extraen automáticamente, y los servicios 24/7 en ejecución se notifican suavemente en lugar de terminarse violentamente. Las configuraciones pueden permanecer específicas del host donde el rendimiento lo exija, mientras que las configuraciones para toda la aplicación (como las zonas horarias en VersicherungsManager siguiendo el patrón probado de routinika) están cableadas de manera determinista. USMC sigue siendo la fachada de memoria pública canónica y conserva su lugar en el sitio web público.

---

## 3. Interacción

Los cinco elementos no forman una cadena causal en serie; en cambio, representan pilares modulares y desacoplados de la integridad operativa diaria que se entrelazan en paralelo a través del sistema:

- **Arquitectura Central y Enrutamiento de Modelos (`BH-A`):** El módulo `agents-heart` desacopla la asignación de modelos. Cuando llega una tarea, BACH determina el conjunto candidato calificado por dominio y clutch selecciona el modelo óptimo en costo y capacidad.
- **Configuración del Host e Integridad del Despliegue (`CF-A`, `MD-A`):** Mientras que el esfuerzo de razonamiento consistente se aplica a la laptop y la estación de trabajo (`CF-A`; los modelos dependientes del host permanecen transparentes), la Mac Studio ejecuta procesos en segundo plano persistentes bajo configuraciones validadas. Para las actualizaciones, la Mac extrae el código mediante una clave de despliegue de solo lectura (`MD-A`); el servidor GUI se reinicia mientras que los servicios 24/7 de larga duración notifican suavemente al panel de control sobre los requisitos de actualización.
- **Persistencia de Dominio y Plazos (`VM-A`):** Aplicaciones como VersicherungsManager persisten plazos contra una tabla `settings` de toda la aplicación siguiendo el patrón de routinika. Los cálculos y los observadores de plazos operan de manera determinista en todos los perfiles en la misma zona horaria IANA.
- **Presentación Pública (`PD-A`):** El constructor del sitio nocturno valida los estados del repositorio. USMC se publica limpiamente bajo su declaración `public` corregida, sin generar alertas en las puertas de seguridad.

---

## 4. Implementación

Debido a que el conjunto de datos fuente no respalda una cadena en serie a través de estos cinco elementos en el gráfico de dependencias ([decision-path](../decision-path/SKILL.md)), el despliegue se estructura honestamente en cuatro flujos de trabajo independientes y paralelos (Enfoque a: pistas paralelas en lugar de causalidad inventada). La ordenación secuencial se aplica solo donde existen plazos externos o pasos internos:

- **Pista A (Crítica en el Tiempo — Fecha Límite 2026-09-14):**
  1. Alinear los metadatos de USMC a `public` (`PD-A`); descartar el PR borrador #2. No se pueden tolerar retrasos debido a la ejecución del constructor nocturno, sin embargo, este paso es técnicamente completamente independiente de todas las demás pistas.
- **Pista B (Configuración del Host y Despliegue en Mac — Paralelizable):**
  1. B1: Codificar los objetivos de configuración en `.SYNC` (`CF-A`), sincronizando el esfuerzo de razonamiento a `high` en ambos hosts.
  2. B2 (independiente de B1): Instalar la clave de despliegue de solo lectura en la Mac Studio y configurar el script de automatización de extracción e informe (`MD-A`).
- **Pista C (Base de Datos de Dominio — Paralelizable):**
  1. Implementar la migración de la tabla `settings` de toda la aplicación en VersicherungsManager siguiendo el patrón de routinika (`VM-A`), estableciendo la base limpia para el desarrollo posterior del editor.
- **Pista D (Extracción Arquitectónica — Plan Interno Multietapa):**
  1. D1: Configurar el esquema SQLite para roles y presupuestos en `agents-heart` (`BH-A` E1).
  2. D2: Separar el catálogo backend como un módulo Python (`BH-A` E3) y vincular la costura de asignación de clutch (`BH-A` E2).
  3. D3: Extraer y vincular el módulo `agents-heart` (`BH-A` E5, E6).

---

## 5. Lo Que Este Panorama No Cubre

- **Condición de Carrera de Reclamación de Tareas:** El error de concurrencia que permite reclamaciones duplicadas de tareas se está abordando en un ticket de corrección urgente dedicado y está fuera de esta aprobación.
- **Frontend de la Cabina de Mando:** La cabina de mando de monitoreo (`BH-A` E4) se aplaza deliberadamente hasta que el backend produzca telemetría operativa en vivo.
- **Publicación de Repositorios Públicos:** Fusionar y preparar el código no hace que los repositorios privados sean automáticamente públicos; los conmutadores de visibilidad final siguen reservados para el usuario.

---

## 6. Aprobación

Puede aprobar este clúster del sistema en su totalidad o proporcionar ajustes en lenguaje natural:

- **Aprobación General Explícita:** "Se ve bien, implementar exactamente como se propuso." (Solo esto desencadena la reserva de todos los elementos).
- **Correcciones de Ejemplo:**
  - *"Sin manejo especial específico del host para la Mac: MD-A necesita claves de escritura completa (A2) para envío directo, y CF-A debe alinear estrictamente todas las configuraciones a la estación de trabajo (Grupo 1=A, 2=A)."* (Impacto múltiple)
  - *"Para BH-A E5, nómbralo ocean-heart en lugar de agents-heart."
  - *"Posponer VM-A por ahora; el editor puede esperar."*

---

## 7. Transferencia Inversa

Cuando el concepto es aprobado o modificado, la habilidad traduce los comentarios en asientos contables:

### Caso A: Aprobación General Explícita
Cuando el usuario aprueba explícitamente el panorama general en su totalidad (ej. *"Se ve bien, implementar exactamente como se propuso"*):
- Los cinco elementos (`BH-A: 1A/2A/3A/4B/5A/6A`, `MD-A: A1`, `CF-A: 1C/2B/3B`, `VM-A: A`, `PD-A: A`) se pasan como DECIDIDOS a [decision-briefing](../decision-briefing/SKILL.md) Fase 4.
- La Fase 4 realiza el asiento contable en `DECIDED-AND-DONE.md`.

### Caso B: Corrección Parcial
Cuando el usuario proporciona una corrección específica (ej. la corrección de impacto múltiple anterior):
1. La corrección se descompone en decisiones individuales:
   - `MD-A`: cambiar de A1 a A2.
   - `CF-A`: cambiar a 1A/2A.
2. Los elementos restantes (`BH-A`, `VM-A`, `PD-A`) permanecen estrictamente **ABIERTOS**.
3. Tabla de Transferencia Inversa:

| Corrección Original | Claves Afectadas | Estado de Dominó | Ambigüedades Abiertas |
|---|---|---|---|
| "Sin manejo especial específico del host... MD-A necesita claves de escritura completa (A2) para envío directo, y CF-A debe alinear estrictamente todas las configuraciones a la estación de trabajo (Grupo 1=A, 2=A)." | `MD-A`, `CF-A` | La dependencia de `MD-A` en `CF-A` para la consistencia de configuración puede colapsar; `BH-A` asume que la configuración del host es correcta, pero no se ve afectada por este cambio. | ¿"todas las configuraciones" incluye también las que eran dependientes del host en 2B? ¿El Grupo 2=A significa que 2B se reemplaza por 2A, o se elimina? |

Esta estructura de siete partes es obligatoria para cada decision-draw.