decision-path — Graphe de dépendances ASCII des décisions en attente
Les décisions n'arrivent pas dans le vide. Ce qui semble raisonnable isolément bloque souvent le travail ultérieur, présuppose des précurseurs non construits, ou contourne des barrières de sécurité établies. decision-path met en lumière les causalités, les séquences d'exécution et les contradictions, directement dans le terminal.
Quand l'utiliser
- Un inventaire existant de décisions ouvertes (provenant de decision-briefing Phase 1, d'un contexte de session, ou d'un brief de décision ticket-master) doit être structuré.
- Vous devez identifier quelles décisions peuvent être exécutées immédiatement (nœuds racines) et lesquelles dépendent de prérequis ou de blocages externes.
- Vous avez besoin d'une vue d'ensemble des recommandations qui s'accordent harmonieusement et de celles qui entrent en collision logique ou opérationnelle.
- Mots déclencheurs :
/decision-path, "quelles décisions dépendent les unes des autres", "graphe de dépendances des décisions", "visualiser le chemin de décision", "arbre de décision ASCII", "contradictions entre décisions", "vérifier les dépendances causales". - Ne pas utiliser :
- Pour d'abord découvrir et inventorier les questions ouvertes — cela est fait par decision-briefing Phase 1.
- Pour regrouper les choix recommandés en un concept unique cohérent pour validation — cela est fait par decision-draw.
- Pour des blocs compacts en cinq parties avec options et pour/contre par option — cela est fait par decision-shot.
- Pour évaluer méthodiquement une seule décision complexe avec des cadres (score pondéré, analyse de scénarios) — cela est fait par decide.
Limites au sein de la famille Décisions
| Compétence | Rôle | Entrée | Sortie |
|---|---|---|---|
decide | Structure méthodiquement une seule décision | Critères, options | Matrice de score, décision unique |
decision-briefing | Décompose plusieurs décisions ouvertes en questions individuelles avec options | Liste des points en attente | Briefing numéroté A/B/C/D, marqueurs de dépendance approximatifs, réservation par lot |
decision-path | Valide et visualise les causalités et contradictions entre plusieurs décisions | Marqueurs approximatifs du briefing / registre | Graphe de dépendances ASCII avec 5 évaluations par nœud et statut des arêtes |
decision-draw | Regroupe les recommandations en un tout cohérent pour validation | Lots de decision-path | Concept, interactions (variante recommandée uniquement), retour |
decision-shot | Condense les analyses terminées en leur essence exécutive (1 décision ou lot serré) | 1 question ou groupe analysé | Format court en cinq parties avec options, pour/contre et lien vers l'analyse complète |
decision-avatar | Modélise les préférences et l'historique comportemental de l'utilisateur | Contexte, choix passés | Évaluation de confiance 🟢 / 🟡 / 🔴 |
Contrat et responsabilité vis-à-vis de decision-briefing
decision-briefing Phase 1 dérive déjà des dépendances approximatives et un ordre d'exécution lors de la réception (par exemple, à partir de signaux tels que "Ensuite automatiquement :", des bloqueurs ou des références de tickets). decision-path ne duplique pas cette dérivation, mais s'appuie directement sur ces marqueurs approximatifs :
- decision-briefing fournit des marqueurs approximatifs : Il fournit l'inventaire brut des éléments en attente et les premiers indices de couplage.
- decision-path valide, évalue et visualise : Il vérifie les signaux par rapport aux faits documentés, sépare les arêtes confirmées des arêtes présumées, attribue les cinq évaluations par nœud et expose les collisions de portes.
- Boucle de rétroaction sur les divergences : Si
decision-pathdécouvre une dépendance manquante ou mal représentée dans le briefing, il ne l'absorbe jamais silencieusement, mais la signale explicitement comme une note de correction au briefing.
Les cinq évaluations par nœud (et statut de vérification des arêtes)
Les cinq dimensions [S E U Z W] évaluent les nœuds (décisions en attente ou résolues dans leur contexte systémique). Les arêtes portent leur type de relation sémantique (par exemple, déblocage, blocage, prérequis) et leur statut de vérification (confirmé vs. présumé).
Chaque nœud du graphe affiche une chaîne d'évaluation compacte à cinq éléments :
[S+ E:<Option> U<Direction><Confiance> Z+ W-]
-
Sensé (
S) — Robustesse technique et architecturale :S+: Solution robuste, répond à un problème réel, évite la complexité artificielle.S~: Partiellement sensée, mais entraîne des coûts de maintenance ou d'exploitation.S-: Fausse solution, activisme cosmétique, ou une impasse avérée (par exemple, filtrer au mauvais niveau).
-
Recommandé (
E) — Action recommandée concrète et fondée sur des preuves :E:<Option>: Choix clair (par ex.E:A,E:B,E:resolve,E:Step1).E-: Aucune recommandation exploitable possible (faits manquants ou question de politique de haut niveau).
-
Typique-utilisateur (
U) — Alignement avec les habitudes passées et les règles codifiées de l'utilisateur (viadecision-avatar) : Codes direction (l'option correspond-elle aux habitudes ?) et confiance de vérification séparément :- Direction (premier caractère après U) :
+: Typique de l'utilisateur — correspond aux décisions passées, politiques (CLAUDE.md), ou préférences explicites.~: Neutre / ouvert — aucun historique de préférence dominant documenté.-: Atypique — s'écarte du flux de travail habituel ou des habitudes établies.
- Confiance de vérification (deuxième caractère) :
- ASCII pur dans le graphe ASCII :
!: Élevée / fondée (en prose : 🟢 documenté).~: Moyenne / plausible (en prose : 🟡 le compromis appartient fondamentalement à l'utilisateur).?: Faible / non vérifié (en prose : 🔴 question de politique, sans précédent). Escalader plutôt que deviner !
- ASCII pur dans le graphe ASCII :
- Exemples :
U+!(typique et documenté),U+~(typique, mais jugement de l'utilisateur),U-!(atypique documenté),U~?(ouvert, sans précédent -> escalader).
- Direction (premier caractère après U) :
-
Cohérent (
Z) — Harmonie architecturale et stylistique avec les nœuds voisins :Z+: S'intègre parfaitement avec les précurseurs et les décisions en aval ; forme un tout cohérent sans friction.Z~: Friction stylistique mineure ou surcharge opérationnelle, mais fonctionnellement viable.Z-: Friction notable dans l'interaction systémique (par exemple, prolifération de configuration, couplage maladroit), mais ne brise pas une règle stricte.
-
Contradictoire (
W) — Contradiction dure et violation de politique/porte (sortie la plus critique — alarme !) :W-: Exempt de contradictions avec d'autres recommandations, politiques et portes de sécurité actives.W+: Collision dure / alarme ! Invalide une autre recommandation, viole une politique établie (CLAUDE.md, P-00x), ou contourne une porte de sécurité active. Les nœuds en collision sont toujours explicitement mis en évidence dans la sectionCONTRADICTIONSavec la cause racine et le chemin de résolution.
Types d'arêtes et règles de dérivation
Les dépendances sont dérivées strictement du texte source, jamais inventées. Les arêtes portent leur type de relation et leur statut de vérification :
| Signal dans la source | Type d'arête | Notation | Signification |
|---|---|---|---|
| "Ensuite automatiquement : ...", "débloque", "permet" | Débloque | +--> | La décision cible devient réalisable uniquement après la décision source (documenté) |
| "bloque", "empêche", "la porte de sécurité se déclenche" | Bloque | => | La cible est bloquée jusqu'à ce que la source soit résolue |
| "nécessite", "a besoin au préalable", "prérequis" | Nécessite | --> | La cible nécessite logiquement et chronologiquement la source |
| "décision de suivi", "étape 2 ensuite" | Séquence | --> | Progression logique en aval après exécution |
| "réfuté par mesure", "obsolète", "remplacé" | Invalide | --X--> | L'aperçu de la source rend l'objectif obsolète |
| D-ID partagé, Ticket-ID, ou même sous-système sans preuve textuelle | Présumé | ?--> | Couplage plausible sans preuve causale documentée (non vérifié) |
Règle pour les arêtes non vérifiées : Lorsqu'aucune déclaration causale explicite n'existe dans le texte, l'arête doit être marquée comme présumée (
?-->) — jamais comme un fait confirmé. Lorsqu'aucune relation n'est documentée, les nœuds restent non connectés côte à côte.
Consignes de format pour le graphe ASCII
- Monospace et Optimisé pour le Terminal : Largeur de ligne maximale 100 colonnes. Aucun tableau large qui s'enroule et casse la disposition du terminal.
- Jeu de caractères et Pureté : ASCII pur. Dans le bloc de code du graphe, aucun emoji (🟢🟡🔴) ne peut apparaître ; la confiance est représentée exclusivement par des marqueurs ASCII (
!,~,?). - Identifiants de nœuds : Uniquement des identifiants existants (
PD-A,MD-A,BH-A,VM-A,QR-A,CL-A,MO-A,D-001,732597768). Ne jamais inventer d'identifiants de synthèse ! Si un élément manque d'abréviation, son numéro d'élément est utilisé. Les étapes internes de suivi sont représentées comme des annotations d'arête non numérotées(...). - Structure en couches :
NIVEAU 0 - indépendant: Nœuds racines, éléments non bloqués, déclencheurs externes.NIVEAU 1 - dépend d'exactement un: Suivis directs.NIVEAU 2 - dépend de plusieurs / chaîne profonde: Nœuds à dépendances multiples ou séquentiels profonds.CONTRADICTIONS: Collisions dures, violations de portes et recommandations contradictoires (W+).LÉGENDE: Obligatoire dans chaque sortie de graphe. Chaque caractère structurel utilisé dans le graphe (|,=Option,(...), flèches d'arête) doit être listé et expliqué dans la légende.
- Bloc Mermaid optionnel : Un bloc de code
mermaidsupplémentaire peut être ajouté si utile ; le graphe ASCII reste la sortie principale et faisant autorité.
Exemple (Jeu de données pilote : Ticket-Master 2026-09-13)
Extrait réel du briefing de décision Ticket-Master (732597768, MO-A, CL-A, QR-A, 387521104, CL-B) :
====================================================================================================
CHEMIN DE DÉCISION : GRAPHE DE DÉPENDANCES (Pilote Ticket-Master 2026-09-13)
====================================================================================================
NIVEAU 0 - indépendant (Décisions racines & blocages externes)
[732597768] Résoudre le problème de facturation GitHub [S+ E:resolve U+! Z+ W-]
| débloque
+--> [MO-A] Version 2 du déploiement [S+ E:A U+~ Z+ W-]
[CL-A] fusion admin clutch PR #6 & PR #8 [S+ E:A U+! Z+ W-]
| bloqué par : [Porte "1 Revue d'approbation" (auto-approbation impossible)]
--> (décision de suivi : définir la protection de branche à 0 ou bot)
[QR-A] Renommer la jonction NTFS de la file d'attente (_TICKETS -> TICKETS) [S+ E:B U+! Z+ W-]
+--> [387521104] Exécutions de la fenêtre de nuit (documenté : seulement sous B)
[CL-B] Porte pilote de révision : clé de signature Mac [S+ E:Step1 U+~ Z+ W-]
--> (étapes de suivi 2-4 : modéliser l'automatisation après l'approvisionnement de la clé)
NIVEAU 1 - dépend d'exactement un précurseur
[MO-A] Version 2 du déploiement [S+ E:A U+~ Z+ W-]
| nécessite : [732597768] (facturation résolue, portes CI distantes actives à nouveau)
| nécessite : [Porte PRIVATE.txt "CI distante verte"]
--> (étape de suivi : basculer la visibilité reste une action de l'utilisateur uniquement)
NIVEAU 2 - dépend de plusieurs / chaîne profonde
[387521104] Exécution de migration autonome en fenêtre de nuit [S+ E:B U+! Z+ W-]
| nécessite : [QR-A]=B (jonction NTFS établie)
| nécessite : (jonction définie sur le deuxième hôte via un ticket de transfert -
| numéro de ticket non indiqué dans le briefing)
----------------------------------------------------------------------------------------------------
CONTRADICTIONS & COLLISIONS DE PORTES
----------------------------------------------------------------------------------------------------
[MO-A]=B X [Porte PRIVATE.txt "CI distante verte"]
Conflit : L'option B publierait la version 2 basée uniquement sur des tests
locaux, même si deux contrats de module exigent explicitement une CI distante verte.
Résolution : La recommandation A force [732597768] (facturation) d'abord, résolvant la collision.
[CL-A]=StatutQuo X [Porte "1 Revue d'approbation" (auto-approbation impossible)]
Conflit : master exige 1 revue, mais le seul compte du dépôt est lukisch.
Résolution : La recommandation A (fusion admin) contourne légitimement l'impasse.
----------------------------------------------------------------------------------------------------
LÉGENDE & CLÉ D'ÉVALUATION
----------------------------------------------------------------------------------------------------
Arêtes & Structure :
+--> débloque / permet (causalité documentée dans la source)
=> bloque / empêche (porte ou bloqueur externe)
--> nécessite / séquence (précondition ou étape de suivi)
?--> dépendance présumée (couplage plausible, mais non documenté)
--X--> invalide / remplace (l'aperçu de la source rend l'objectif obsolète)
X contradiction / collision (porte ou violation de politique)
| ligne de hiérarchie verticale / mappage d'attribut
[ID] nœud de décision (abréviation de l'élément ou numéro de l'élément du briefing)
[Porte] porte externe / règle / contrat - PAS un nœud de décision
=Opt option spécifique pour un nœud (par ex. [MO-A]=B)
(...) annotation d'arête non numérotée / étape de suivi (aucun ID de synthèse inventé)
Évaluation du nœud [S E U Z W] :
S : Sensé (+ solide / ~ qualifié / - non sensé)
E : Recommandé (A, B, C, resolve, Step1, - aucun)
U : Typique-utilisateur (direction : + typique / ~ neutre / - atypique ;
confiance : ! fondée / ~ compromis / ? escalade)
[! = documenté (prose vert), ~ = compromis utilisateur (prose jaune),
? = non vérifié / escalade (prose rouge)]
Z : Cohérent (+ harmonise / ~ friction légère / - rupture architecturale)
W : Contradictoire (- sans conflit / + collision dure avec porte ou politique)
====================================================================================================
Ce que decision-path NE fait PAS
- Ne prend pas de décisions : La compétence offre une transparence structurelle. L'autorité de décision reste à l'utilisateur.
- N'invente pas d'options : La compétence ne génère pas de nouvelles alternatives ou de critères de pondération ; cela relève de decide ou de decision-briefing.