decision-path — Grafo de dependencias ASCII de decisiones pendientes
Las decisiones no ocurren en el vacío. Lo que parece razonable de forma aislada frecuentemente bloquea trabajo posterior, presupone requisitos no construidos o elude puertas de seguridad establecidas. decision-path trae causalidades, secuencias de ejecución y contradicciones de forma transparente al terminal.
Cuándo usarlo
- Existe un inventario de decisiones abiertas (de decision-briefing Fase 1, un contexto de sesión o un resumen de decisiones de un ticket) que necesita ser estructurado.
- Debes identificar qué decisiones pueden ejecutarse de inmediato (nodos raíz) y cuáles dependen de requisitos previos o bloqueadores externos.
- Necesitas una visión general de qué recomendaciones encajan armoniosamente y dónde dos recomendaciones chocan lógica u operativamente.
- Palabras desencadenantes:
/decision-path, "qué decisiones dependen unas de otras", "grafo de dependencias de decisiones", "visualizar camino de decisión", "árbol de decisiones ASCII", "contradicciones entre decisiones", "verificar dependencias causales". - No uses:
- Para descubrir e inventariar preguntas abiertas por primera vez — eso lo hace decision-briefing Fase 1.
- Para agrupar opciones recomendadas en un concepto coherente para aprobación — eso lo hace decision-draw.
- Para bloques compactos de cinco partes con opciones y pros/contras por opción — eso lo hace decision-shot.
- Para evaluar metódicamente una sola decisión compleja con marcos de trabajo (puntuación ponderada, análisis de escenarios) — eso lo hace decide.
Límites en la familia de decisiones
| Skill | Rol | Entrada | Salida |
|---|---|---|---|
decide | Estructura metódicamente una sola decisión | Criterios, opciones | Matriz de puntuación, decisión única |
decision-briefing | Descompone muchas decisiones abiertas en preguntas individuales con opciones | Lista de puntos pendientes | Resumen numerado A/B/C/D, marcadores de dependencia aproximados, reserva por lotes |
decision-path | Valida y visualiza causalidades y contradicciones entre muchas decisiones | Marcadores aproximados del resumen / registro | Grafo de dependencias ASCII con 5 evaluaciones por nodo y estado de aristas |
decision-draw | Agrupa recomendaciones en un todo coherente para aprobación | Paquetes de decision-path | Concepto, interacción (solo variante recomendada), transferencia inversa |
decision-shot | Comprime análisis terminados a su esencia ejecutiva (1 decisión o paquete cerrado) | 1 pregunta analizada o grupo | Forma breve de cinco partes con opciones, pros/contras y enlace al análisis completo |
decision-avatar | Modela preferencias del usuario e historial de comportamiento | Contexto, elecciones pasadas | Clasificación de confianza 🟢 / 🟡 / 🔴 |
Contrato y responsabilidad respecto a decision-briefing
decision-briefing Fase 1 ya deriva dependencias aproximadas y orden de ejecución durante la ingesta (p. ej., a partir de señales como "Después automáticamente:", bloqueadores o referencias de tickets). decision-path no duplica esta derivación, sino que se basa directamente en estos marcadores aproximados:
- decision-briefing proporciona marcadores aproximados: Proporciona el inventario bruto de elementos pendientes y pistas de acoplamiento iniciales.
- decision-path valida, evalúa y visualiza: Verifica las señales contra hechos documentados, separa aristas confirmadas de las supuestas, asigna las cinco evaluaciones por nodo y expone colisiones de puertas.
- Bucle de retroalimentación sobre discrepancias: Si
decision-pathdescubre una dependencia faltante o mal representada en el resumen, nunca la absorbe silenciosamente, sino que la reporta explícitamente como una nota de corrección al resumen.
Las cinco valoraciones por nodo (y estado de verificación de aristas)
Las cinco dimensiones [S E U Z W] evalúan los nodos (decisiones pendientes o resueltas en su contexto sistémico). Las aristas llevan su tipo de relación semántica (p. ej., desbloqueo, bloqueo, requisito previo) y estado de verificación (confirmado vs. supuesto).
Cada nodo en el grafo muestra una cadena de evaluación compacta de cinco elementos:
[S+ E:<Option> U<Direction><Confidence> Z+ W-]
-
Sensato (
S) — Solidez técnica y arquitectónica:S+: La solución es robusta, aborda un problema real, evita complejidad artificial.S~: Parcialmente sólida, pero con costos de mantenimiento u operativos.S-: Falsa solución, activismo cosmético o un callejón sin salida probado (p. ej., filtrar en el nivel incorrecto).
-
Recomendado (
E) — Acción recomendada concreta y basada en evidencia:E:<Option>: Elección clara (p. ej.,E:A,E:B,E:resolve,E:Step1).E-: No es posible una recomendación accionable (hechos faltantes o pregunta de política de alto nivel).
-
Típico del usuario (
U) — Alineación con los hábitos pasados y reglas codificadas del usuario (víadecision-avatar): Codifica dirección (¿la opción se ajusta a los hábitos?) y confianza de verificación por separado:- Dirección (primer carácter después de U):
+: Típico del usuario — coincide con decisiones pasadas, políticas (CLAUDE.md) o preferencias explícitas.~: Neutral / abierto — no hay preferencia histórica dominante documentada.-: Atípico — se desvía del flujo de trabajo habitual o de hábitos establecidos.
- Confianza de verificación (segundo carácter):
- ASCII puro dentro del grafo ASCII:
!: Alta / fundamentada (en prosa: 🟢 documentada).~: Media / plausible (en prosa: 🟡 la compensación pertenece fundamentalmente al usuario).?: Baja / no verificada (en prosa: 🔴 pregunta de política, sin precedentes). ¡Escalar en lugar de adivinar!
- ASCII puro dentro del grafo ASCII:
- Ejemplos:
U+!(típico y documentado),U+~(típico, pero juicio del usuario),U-!(atípico documentado),U~?(abierto, sin precedentes -> escalar).
- Dirección (primer carácter después de U):
-
Coherente (
Z) — Armonía arquitectónica y estilística suave con nodos vecinos:Z+: Se integra perfectamente con predecesores y decisiones posteriores; forma un todo cohesivo sin fricción.Z~: Fricción estilística menor o costo operativo, pero funcionalmente viable.Z-: Fricción notable en la interacción sistémica (p. ej., proliferación de configuración, acoplamiento incómodo), pero no rompe una regla estricta.
-
Contradictorio (
W) — Contradicción dura o violación de política/puerta (la salida más crítica — ¡alarma!):W-: Libre de contradicciones contra otras recomendaciones, políticas y puertas de seguridad activas.W+: Colisión dura / ¡alarma! Invalida otra recomendación, viola una política establecida (CLAUDE.md, P-00x) o elude una puerta de seguridad activa. Los nodos en colisión siempre se resaltan explícitamente en la secciónCONTRADICCIONEScon causa raíz y ruta de resolución.
Tipos de aristas y reglas de derivación
Las dependencias se derivan estrictamente del texto fuente, nunca se inventan. Las aristas llevan su tipo de relación y estado de verificación:
| Señal en la fuente | Tipo de arista | Notación | Significado |
|---|---|---|---|
| "Después automáticamente: ...", "desbloquea", "habilita" | Desbloquea | +--> | La decisión objetivo se vuelve accionable solo después de la decisión fuente (documentado) |
| "bloquea", "previene", "la puerta de seguridad se activa" | Bloquea | => | El objetivo está bloqueado hasta que se resuelva la fuente |
| "requiere", "necesita antes", "requisito previo" | Requiere | --> | El objetivo lógica y cronológicamente requiere la fuente |
| "decisión de seguimiento", "paso 2 después" | Secuencia | --> | Progresión lógica descendente después de la ejecución |
| "refutado por medición", "obsoleto", "reemplazado" | Invalida | --X--> | La idea fuente hace que el objetivo quede obsoleto |
| D-ID, Ticket-ID o mismo subsistema compartidos sin prueba textual | Presunta | ?--> | Acoplamiento plausible sin prueba causal documentada (no verificado) |
Regla para aristas no verificadas: Cuando no existe una declaración causal explícita en el texto, la arista debe marcarse como presunta (
?-->) — nunca como un hecho confirmado. Cuando no hay relación documentada, los nodos permanecen desconectados lado a lado.
Directrices de formato para el grafo ASCII
- Monoespaciado y optimizado para terminal: Ancho máximo de línea 100 columnas. Sin tablas anchas que se ajusten y rompan el diseño del terminal.
- Conjunto de caracteres y pureza: ASCII puro. Dentro del bloque de código del grafo, no pueden aparecer emojis (🟢🟡🔴); la confianza se representa exclusivamente mediante marcadores ASCII (
!,~,?). - IDs de nodo: Solo identificadores existentes (
PD-A,MD-A,BH-A,VM-A,QR-A,CL-A,MO-A,D-001,732597768). ¡Nunca inventes IDs sintéticos! Si un elemento carece de abreviatura, se usa su número de elemento. Los pasos internos de seguimiento se representan como anotaciones de arista sin numerar(...). - Estructura en capas:
NIVEL 0 - independiente: Nodos raíz, elementos desbloqueados, desencadenantes externos.NIVEL 1 - depende exactamente de uno: Seguimientos directos.NIVEL 2 - depende de múltiples / cadena profunda: Múltiples dependencias o nodos secuenciales profundos.CONTRADICCIONES: Colisiones duras, violaciones de puerta y recomendaciones conflictivas (W+).LEYENDA: Obligatoria en cada salida del grafo. Cada carácter estructural utilizado en el grafo (|,=Option,(...), flechas de arista) debe ser listado y explicado en la leyenda.
- Bloque Mermaid opcional: Se puede agregar un bloque de código
mermaidadicional si es útil; el grafo ASCII sigue siendo la salida principal y autorizada.
Ejemplo (Conjunto de datos piloto: Ticket-Master 2026-09-13)
Extracto real del resumen de decisiones Ticket-Master (732597768, MO-A, CL-A, QR-A, 387521104, CL-B):
====================================================================================================
DECISION-PATH: GRAFO DE DEPENDENCIAS (Piloto Ticket-Master 2026-09-13)
====================================================================================================
NIVEL 0 - independiente (Decisiones raíz y bloqueadores externos)
[732597768] Resolver problema de facturación de GitHub [S+ E:resolve U+! Z+ W-]
| desbloquea
+--> [MO-A] Lanzar Wave 2 [S+ E:A U+~ Z+ W-]
[CL-A] fusionar PR de administración de clutch #6 y #8 [S+ E:A U+! Z+ W-]
| bloqueado por: [Puerta "1 Revisión de aprobación" (autoaprobación imposible)]
--> (decisión de seguimiento: establecer protección de rama a 0 o bot)
[QR-A] Renombrar unión NTFS de cola (_TICKETS -> TICKETS) [S+ E:B U+! Z+ W-]
+--> [387521104] Ejecuciones en ventana nocturna (documentado: solo bajo B)
[CL-B] Revisar puerta piloto: clave de firma de Mac [S+ E:Step1 U+~ Z+ W-]
--> (pasos de seguimiento 2-4: automatización del modelo después del aprovisionamiento de clave)
NIVEL 1 - depende exactamente de un precursor
[MO-A] Lanzar Wave 2 [S+ E:A U+~ Z+ W-]
| requiere: [732597768] (facturación resuelta, puertas de CI remoto activas de nuevo)
| requiere: [Puerta PRIVATE.txt "CI remoto verde"]
--> (paso de seguimiento: alternar visibilidad sigue siendo acción solo del usuario)
NIVEL 2 - depende de múltiples / cadena profunda
[387521104] Ejecución de migración autónoma en ventana nocturna [S+ E:B U+! Z+ W-]
| requiere: [QR-A]=B (unión NTFS establecida)
| requiere: (unión establecida en el segundo host mediante ticket de transferencia -
| número de ticket no indicado en el resumen)
----------------------------------------------------------------------------------------------------
CONTRADICCIONES Y COLISIONES DE PUERTA
----------------------------------------------------------------------------------------------------
[MO-A]=B X [Puerta PRIVATE.txt "CI remoto verde"]
Conflicto: La opción B lanzaría Wave 2 basándose únicamente en pruebas locales,
aunque dos contratos de módulo exigen explícitamente CI remoto verde.
Resolución: La recomendación A fuerza [732597768] (facturación) primero, resolviendo la colisión.
[CL-A]=StatusQuo X [Puerta "1 Revisión de aprobación" (autoaprobación imposible)]
Conflicto: master exige 1 revisión, pero la única cuenta de repositorio es lukisch.
Resolución: La recomendación A (fusión de administrador) rompe legítimamente el callejón sin salida.
----------------------------------------------------------------------------------------------------
LEYENDA Y CLAVE DE VALORACIÓN
----------------------------------------------------------------------------------------------------
Aristas y estructura:
+--> desbloquea / habilita (causalidad documentada en la fuente)
=> bloquea / previene (puerta o bloqueador externo)
--> requiere / secuencia (precondición o paso de seguimiento)
?--> dependencia presunta (acoplamiento plausible, pero no documentado)
--X--> invalida / reemplaza (la idea de la fuente hace que el objetivo quede obsoleto)
X contradicción / colisión (puerta o violación de política)
| línea de jerarquía vertical / mapeo de atributos
[ID] nodo de decisión (abreviatura del elemento o número de elemento del resumen)
[Puerta] puerta externa / regla / contrato - NO es un nodo de decisión
=Opt opción específica para un nodo (p. ej., [MO-A]=B)
(...) anotación de arista sin numerar / paso de seguimiento (sin ID sintético inventado)
Evaluación del nodo [S E U Z W]:
S: Sensato (+ sólido / ~ calificado / - no sólido)
E: Recomendado (A, B, C, resolve, Step1, - ninguno)
U: Típico del usuario (dirección: + típico / ~ neutral / - atípico;
confianza: ! fundamentado / ~ compensación / ? escalación)
[! = documentado (verde en prosa), ~ = compromiso del usuario (amarillo en prosa),
? = no verificado / escalación (rojo en prosa)]
Z: Coherente (+ armoniza / ~ fricción leve / - ruptura arquitectónica)
W: Contradictorio (- sin conflicto / + colisión dura con puerta o política)
====================================================================================================
Lo que decision-path NO hace
- No toma decisiones: El skill proporciona transparencia estructural. La autoridad para decidir permanece en el usuario.
- No inventa opciones: El skill no genera nuevas alternativas ni criterios de ponderación; eso pertenece a decide o decision-briefing.