decision-draw — Vue d'ensemble et approbation groupée pour les décisions liées
Lorsque cinq ou dix décisions sont en attente, on se perd facilement dans les détails des options isolées et on perd de vue le système émergent. decision-draw ne décrit pas les alternatives ; il peint l'ensemble fonctionnel : comment les systèmes coopèrent-ils une fois toutes les recommandations en place ? L'utilisateur approuve l'image dans son ensemble ou fournit un retour ciblé.
Quand l'utiliser
- Plusieurs décisions interdépendantes (issues de decision-briefing ou d'un document de briefing) ne doivent pas être traitées comme une fastidieuse liste de contrôle de questions individuelles.
- L'utilisateur souhaite voir comment les composants interagissent réellement dans la pratique quotidienne après la mise en œuvre, avant de les approuver.
- Un groupe de décisions étroitement couplées, identifié via le graphe de dépendances (decision-path), peut être approuvé ensemble en tant qu'unité fonctionnelle.
- Mots déclencheurs :
/decision-draw, "à quoi ressemble l'ensemble si nous sommes d'accord sur tout", "dessine la vue d'ensemble", "concept de décision global", "decision draw", "comment les systèmes fonctionnent-ils ensemble après", "image d'approbation globale". - Ne pas utiliser :
- Lorsque l'utilisateur souhaite évaluer des options distinctes par élément et choisir via des lettres (A/B/C) — cela relève de decision-briefing.
- Pour une analyse pure de causalité et de goulots d'étranglement dans le terminal — cela relève de decision-path.
- Pour des évaluations d'options isolées en blocs discrets en 5 parties (contexte, avantages/inconvénients par option, recommandation) pour des problèmes uniques ou des questions étroitement groupées — cela relève de decision-shot.
- Pour évaluer méthodiquement une seule question de politique ouverte — cela relève de decide.
Limites au sein de la famille de décisions
| Skill | UX & Focus | Position sur les options | Mode d'approbation |
|---|---|---|---|
decision-briefing | Décompose en éléments individuels | Montre toutes les options A/B/C/D | Codes lettres (1A 2C 3B) |
decision-path | Structure les causalités | Évalue les options dans un graphe | Diagnostic terminal (ASCII) |
decision-draw | Image cible cohérente (regroupe les décisions interdépendantes) | Décrit uniquement la variante recommandée (alternatives liées) | Approbation holistique ou phrase de correction |
decision-shot | Blocs discrets structurés (pour problèmes uniques ou groupes restreints) | Montre les options avec 2 à 4 puces d'avantages/inconvénients | Décision exécutive / révision individuelle |
decide | Élabore un seul problème | Matrice d'évaluation (critères) | Recommandation analytique |
Règle fondamentale :
decision-drawdécrit exclusivement la variante recommandée. Les alternatives rejetées n'ont pas disparu — elles sont documentées dans decision-briefing, decision-shot, ou des tickets liés, et sont référencées dans le tableau d'en-tête. Un dessin sans ce lien retire le choix à l'utilisateur au lieu de le simplifier.
Structure obligatoire (sept parties)
Un decision-draw complet suit strictement cette disposition en sept parties :
1. Lot et périmètre
Résumé tabulaire de tous les éléments inclus dans le lot :
- Abréviation / ID (ex.
BH-A,MD-A,CF-A) - Référence du ticket
- Titre court de l'élément
- Recommandation supposée (la prémisse de cette image d'ensemble)
- Confiance de l'
decision-avatar(🟢 documenté, 🟡 compromis, 🔴 nécessite une escalade) - Lien vers l'analyse complète / les alternatives
2. Concept
L'état cible en prose cohérente :
- Quel paysage système ou flux de travail émerge lorsque toutes les recommandations sont exécutées exactement comme prévu ?
- Pas de comparaison côte à côte des options, pas d'hypothèses au conditionnel ("on pourrait aussi").
- Indicatif clair et confiant : Voici comment le système fonctionne dans son état cible.
3. Interaction
Le noyau fonctionnel du skill :
- Comment les composants décidés s'emboîtent-ils réellement après la mise en œuvre ?
- Structuré autour d'un flux opérationnel concret de bout en bout (ex. "Un ticket arrive → l'agent démarre → le backend assigne → déploiement sur l'hôte") plutôt qu'une liste statique de composants.
- Clarifie les flux de données, les interfaces et les responsabilités opérationnelles.
4. Mise en œuvre
La séquence concrète des étapes de déploiement :
- Que se passe-t-il en pratique, étape par étape ?
- Hérite de la séquence d'exécution et de la logique de dépendance directement de decision-path.
- Les flux de travail indépendants sont représentés honnêtement comme des pistes parallèles (n'inventez pas de chaînes causales artificielles ; un lot peut comprendre plusieurs pistes parallèles). L'ordre séquentiel n'est affirmé que là où des dépendances ou des délais justifiés existent.
- Met en évidence les points de contrôle, les scripts de migration et les vérifications de validation.
5. Ce que cette image ne couvre pas
Défense des limites contre une fausse exhaustivité :
- Quelles questions secondaires, problèmes non résolus ou confiances 🔴 sont délibérément exclus ?
- Où se situent les limites par rapport aux systèmes voisins ?
- Une image qui cache ses marges produit un faux sentiment de sécurité.
6. Approbation
L'interaction avec l'utilisateur :
- L'utilisateur examine l'image dans son ensemble.
- Option de réponse 1 : Approbation explicite globale ("Ça a l'air bon", "Approuvé", "Tout mettre en œuvre comme proposé"). Ce n'est que dans ce cas que tous les éléments du lot sont enregistrés comme décidés.
- Option de réponse 2 : Correction ciblée en langage naturel ("Préférer la variante plus petite pour BH-A", "Pas de redémarrage automatique pour MD-A", "Garder VM-A tel quel"). Déclenche la décomposition en décisions discrètes ; tous les éléments non corrigés restent ouverts.
7. Rétro-transfert
La traduction systématique des retours utilisateur en écritures individuelles dans le registre :
- Pas de co-enregistrement automatique : Les éléments non modifiés sont enregistrés uniquement sur approbation explicite globale. Une correction partielle n'est pas une approbation globale !
- Isolement lors de la correction : Si l'utilisateur soumet une correction, elle est décomposée en décisions individuelles ; tous les autres éléments du lot restent strictement ouverts (dans les tickets source / registre) jusqu'à ce que l'utilisateur accepte l'image ajustée dans son ensemble ou confirme les éléments restants individuellement.
- Tableau de rétro-transfert obligatoire : Chaque retour partiel génère un tableau d'évaluation structuré avec quatre colonnes :
- Correction originale : Déclaration textuelle de l'utilisateur.
- Clés affectées : Quels ID de lot sont modifiés (y compris les multi-impacts lorsqu'une déclaration touche plusieurs décisions).
- Statut domino : Quels nœuds dépendants ou hypothèses en aval dans decision-path s'effondrent ou nécessitent une réévaluation.
- Ambiguïtés ouvertes : Où la correction permet plusieurs interprétations nécessitant des éclaircissements avant l'enregistrement.
- Gestion des multi-impacts : Une seule déclaration utilisateur peut modifier plusieurs décisions simultanément. Le rétro-transfert doit démêler ce couplage et capturer toutes les clés affectées ensemble.
- Chemin d'écriture exclusif via la Phase 4 :
decision-drawn'a aucun chemin d'écriture natif vers les tickets ou les registres. Les mises à jour du registre se font exclusivement via le protocole standardisé de decision-briefing Phase 4 (journalisation et persistance dansDECIDED-AND-DONE.mdouTO-DECIDE-USER.txt).
Exemple (Jeu de données pilote : Ticket-Master 2026-09-13 — Cluster BACH & Système)
Lot réel du briefing décisionnel Ticket-Master daté du 2026-09-13 : BH-A, MD-A, CF-A, VM-A, PD-A.
# DECISION-DRAW: Cœur du cluster BACH et intégrité opérationnelle
## 1. Lot et périmètre
| Clé | Ticket / Source | Sujet | Recommandation supposée | Confiance | Alternatives & Détails |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | Backend modèle = Heart | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Déploiement Mac & redémarrage | A1 + script (lecture seule pour 24/7) | 🟢 | Ticket `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | Cibles de configuration sur les hôtes | 1C (justifié) / 2B (dépendant hôte) / 3B (élevée) | 🟢 / 🟡 | Ticket `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | Fuseau horaire VersicherungsManager | A (paramètres globaux comme routinika) | 🟢 | Ticket `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | Visibilité de la page USMC | A (aligner déclaration sur public, statu quo) | 🟢 | Ticket `T-20260913-609930207.txt` |
*Note : Toutes les alternatives rejetées (ex. BH-A E5=B ocean-heart, MD-A A2 clés d'écriture complètes, VM-A B zones par profil) restent documentées dans le briefing décisionnel Ticket-Master.*
---
## 2. Concept
Nous établissons une architecture multi-hôte propre et découplée où le backend de modèle
est exploité comme un module central indépendant nommé `agents-heart`. Les rôles, droits et budgets
sont proprement maintenus dans une base de données SQLite relationnelle, tandis que les décisions
de routage de modèle se produisent en deux étapes : BACH construit l'ensemble de candidats qualifiés par domaine, et clutch sélectionne
le modèle optimal en termes de coût et de capacité dans cet ensemble.
Sur le Mac Studio, les services d'arrière-plan 24/7 fonctionnent de manière sûre et fiable en utilisant une clé de déploiement
en lecture seule ; les mises à jour de code sont extraites automatiquement, et les services 24/7 en cours
sont notifiés en douceur plutôt que terminés violemment. Les configurations peuvent rester spécifiques à l'hôte là où
les performances l'exigent, tandis que les paramètres globaux (tels que les fuseaux horaires dans VersicherungsManager
suivant le modèle éprouvé de routinika) sont câblés de manière déterministe. USMC
reste la façade mémoire publique canonique et conserve sa place sur le site web public.
---
## 3. Interaction
Les cinq éléments ne forment pas une chaîne causale en série ; ils représentent plutôt des piliers modulaires et découplés de l'intégrité opérationnelle quotidienne qui s'emboîtent en parallèle dans tout le système :
- **Architecture centrale et routage de modèle (`BH-A`) :** Le module `agents-heart` découple l'assignation des modèles. Lorsqu'une tâche arrive, BACH détermine l'ensemble de candidats qualifiés par domaine et clutch sélectionne le modèle optimal en termes de coût et de capacité.
- **Configuration hôte et intégrité du déploiement (`CF-A`, `MD-A`) :** Alors que l'effort de raisonnement cohérent s'applique au portable et à la station de travail (`CF-A` ; les modèles dépendants de l'hôte restent transparents), le Mac Studio exécute des processus persistants en arrière-plan avec des paramètres validés. Pour les mises à jour, le Mac extrait le code via une clé de déploiement en lecture seule (`MD-A`) ; le serveur GUI redémarre tandis que les services 24/7 de longue durée notifient en douceur le tableau de bord des besoins de mise à jour.
- **Persistance domaine et échéances (`VM-A`) :** Les applications telles que VersicherungsManager persistent les échéances par rapport à une table `settings` globale suivant le modèle routinika. Les calculs et les surveillants d'échéances fonctionnent de manière déterministe sur tous les profils dans le même fuseau horaire IANA.
- **Présentation publique (`PD-A`) :** Le constructeur de site nocturne valide les états du dépôt. USMC est publié proprement sous sa déclaration `public` corrigée, ne déclenchant aucune alerte dans les passerelles de sécurité.
---
## 4. Mise en œuvre
Parce que l'ensemble de données source ne justifie pas une chaîne en série à travers ces cinq éléments dans le graphe de dépendances ([decision-path](../decision-path/SKILL.md)), le déploiement est honnêtement structuré en quatre flux de travail indépendants et parallèles (Approche a : pistes parallèles au lieu de causalité inventée). L'ordre séquentiel ne s'applique que là où des délais externes ou des étapes internes existent :
- **Piste A (Critique en termes de temps — Échéance 2026-09-14) :**
1. Aligner les métadonnées USMC sur `public` (`PD-A`) ; supprimer le projet de PR #2. Les retards ne peuvent être tolérés en raison de l'exécution du constructeur nocturne, mais cette étape est techniquement complètement indépendante de toutes les autres pistes.
- **Piste B (Configuration hôte & déploiement Mac — Parallélisable) :**
1. B1 : Codifier les cibles de configuration dans `.SYNC` (`CF-A`), en synchronisant l'effort de raisonnement à `high` sur les deux hôtes.
2. B2 (indépendant de B1) : Installer la clé de déploiement en lecture seule sur le Mac Studio et configurer le script d'extraction et de rapport automatique (`MD-A`).
- **Piste C (Base de données domaine — Parallélisable) :**
1. Implémenter la migration de la table `settings` globale dans VersicherungsManager suivant le modèle routinika (`VM-A`), établissant la base de référence propre pour le développement ultérieur de l'éditeur.
- **Piste D (Extraction architecturale — Plan interne en plusieurs étapes) :**
1. D1 : Configurer le schéma SQLite pour les rôles et budgets dans `agents-heart` (`BH-A` E1).
2. D2 : Extraire le catalogue backend en tant que module Python (`BH-A` E3) et lier la couture d'allocation clutch (`BH-A` E2).
3. D3 : Extraire et lier le module `agents-heart` (`BH-A` E5, E6).
---
## 5. Ce que cette image ne couvre pas
- **Condition de concurrence pour la revendication de tâche :** Le bogue de concurrence permettant les revendications en double de tâche
est traité dans un ticket de correctif dédié et est en dehors de cette approbation.
- **Frontend du cockpit :** Le cockpit de surveillance (`BH-A` E4) est délibérément reporté jusqu'à ce que
le backend produise des données télémétriques opérationnelles en direct.
- **Publication des dépôts publics :** La fusion et la mise en scène du code ne rendent pas automatiquement
les dépôts privés publics ; les bascules de visibilité finales restent réservées à l'utilisateur.
---
## 6. Approbation
Vous pouvez approuver ce cluster système dans son ensemble ou fournir des ajustements en langage naturel :
- **Approbation explicite globale :** "Ça a l'air bon, mettre en œuvre exactement comme proposé." (Cela seul déclenche l'enregistrement de tous les éléments).
- **Exemples de corrections :**
- *"Pas de traitement spécial spécifique à l'hôte pour le Mac : MD-A a besoin de clés d'écriture complètes (A2) pour un push direct, et CF-A doit aligner strictement toutes les configurations sur la station de travail (Groupe 1=A, 2=A)."* (Multi-impact)
- *"Pour BH-A E5, nommez-le ocean-heart au lieu de agents-heart."*
- *"Reportez VM-A pour l'instant ; l'éditeur peut attendre."*
---
## 7. Rétro-transfert
Lorsque le concept est approuvé ou modifié, le skill traduit le feedback en écritures du registre :
### Cas A : Approbation explicite globale
Quand l'utilisateur approuve explicitement l'image d'ensemble dans son intégralité (ex. *"Ça a l'air bon, mettre en œuvre exactement comme proposé"*) :
- Les cinq éléments (`BH-A: 1A/2A/3A/4B/5A/6A`, `MD-A: A1`, `CF-A: 1C/2B/3B`, `VM-A: A`, `PD-A: A`) sont passés comme DECIDED à la Phase 4 de [decision-briefing](../decision-briefing/SKILL.md).
- La Phase 4 effectue l'écriture dans le registre, met à jour `DECIDED-AND-DONE.md`, supprime les tickets sources, et marque tous les éléments comme fermés.
### Cas B : Correction partielle (avec ou sans multi-impact)
Quand l'utilisateur soumet une correction (ex. *"Pas de traitement spécial pour le Mac : MD-A a besoin de clés d'écriture complètes (A2)"*) :
1. La correction est décomposée en une ou plusieurs décisions discrètes affectant `MD-A` (et potentiellement d'autres).
2. Un tableau de rétro-transfert est généré :
| Correction originale | Clés affectées | Statut domino | Ambiguïtés ouvertes |
|---|---|---|---|
| "MD-A a besoin de clés d'écriture complètes (A2)" | `MD-A` | `CF-A` (dépendance sur le mécanisme de déploiement) | La clé A2 remplace-t-elle A1 ou s'agit-il d'un remplacement complet ? |
3. `MD-A` est marqué comme "corrigé — à réévaluer" ; tous les autres éléments (`BH-A`, `CF-A`, `VM-A`, `PD-A`) restent strictement **ouverts** dans leurs tickets sources.
4. Le résultat est transmis à la Phase 4 de [decision-briefing](../decision-briefing/SKILL.md) pour une clarification et une éventuelle réouverture du cycle.