decision-draw — Gesamtbild & übergreifende Freigabe für gebünde…

decision-draw — Gesamtbild & übergreifende Freigabe für gebündelte Entscheidungen

Wenn fünf oder zehn Entscheidungen anstehen, verliert man schnell den Überblick über isolierte Optionen und das entstehende System aus den Augen. decision-draw beschreibt nicht die Alternativen; es malt das funktionierende Ganze: Wie arbeiten die Systeme zusammen, sobald alle Empfehlungen umgesetzt sind? Die Nutzer*innen geben das Bild als Ganzes frei oder geben gezieltes Feedback.

---

Wann verwenden

• Mehrere voneinander abhängige Entscheidungen (aus decision-briefing oder einem Entscheidungsdokument) sollen nicht als mühsame Checkliste von Einzelfragen abgearbeitet werden.
• Die Nutzer*innen möchten sehen, wie Komponenten im täglichen Betrieb nach der Implementierung tatsächlich interagieren, bevor sie diese freigeben.
• Ein Cluster eng gekoppelter Entscheidungen, der über den Abhängigkeitsgraphen (decision-path) identifiziert wurde, kann als funktionale Einheit gemeinsam freigegeben werden.
• Auslösewörter: /decision-draw, „wie sieht das Ganze aus, wenn wir allem zustimmen“, „zeichne das große Bild“, „Gesamtentscheidungskonzept“, „Entscheidungszeichnung“, „wie arbeiten die Systeme danach zusammen“, „Gesamtfreigabebild“.
• Nicht verwenden:
  • Wenn die Nutzer*innen verschiedene Optionen pro Punkt bewerten und per Buchstaben (A/B/C) auswählen möchten – das erfolgt durch decision-briefing.
  • Für reine Kausalitäts- und Engpassanalyse im Terminal – das erfolgt durch decision-path.
  • Für isolierte Optionsbewertungen in 5-teiligen diskreten Blöcken (Kontext, Pro/Kontra pro Option, Empfehlung) für Einzelthemen oder eng gruppierte Fragen – das erfolgt durch decision-shot.
  • Zur methodischen Bewertung einer einzelnen offenen Grundsatzfrage – das erfolgt durch decide.

---

Abgrenzung innerhalb der Entscheidungsfamilie

Skill	UX & Fokus	Haltung zu Optionen	Freigabemodus
decision-briefing	Zerlegt in Einzelpunkte	Zeigt alle Optionen A/B/C/D	Buchstabencodes (1A 2C 3B)
decision-path	Strukturiert Kausalitäten	Bewertet Optionen im Graphen	Terminaldiagnostik (ASCII)
decision-draw	Kohärentes Zielbild (bündelt interdependente Entscheidungen)	Beschreibt nur die empfohlene Variante (Alternativen verlinkt)	Ganzheitliche Freigabe oder Korrektursatz
decision-shot	Strukturierte diskrete Blöcke (für Einzelthemen oder enge Gruppen)	Zeigt Optionen mit 2–4 Pro/Kontra-Stichpunkten	Führungsentscheidung / Einzelprüfung
decide	Erarbeitet Einzelthema	Bewertungsmatrix (Kriterien)	Analytische Empfehlung

Kernregel: decision-draw beschreibt ausschließlich die empfohlene Variante. Die verworfenen Alternativen sind nicht verschwunden – sie sind in decision-briefing, decision-shot oder verknüpften Tickets dokumentiert und werden in der Kopfzeilentabelle referenziert. Eine Zeichnung ohne diese Verknüpfung nimmt der Nutzer*in die Wahl, anstatt sie zu vereinfachen.

---

Verbindliche Struktur (Sieben Teile)

Ein vollständiger decision-draw folgt strikt diesem siebenteiligen Aufbau:

1. Bündel und Umfang

Tabellarische Zusammenfassung aller im Bündel enthaltenen Punkte:

• Abkürzung / ID (z. B. BH-A, MD-A, CF-A)
• Ticket-Referenz
• Kurztitel des Punktes
• Angenommene Empfehlung (die Prämisse dieses Gesamtbildes)
• decision-avatar-Konfidenz (🟢 dokumentiert, 🟡 Trade-off, 🔴 Eskalation erforderlich)
• Link zur vollständigen Analyse / zu den Alternativen

2. Konzept

Der Zielzustand in kohärenter Prosa:

• Welche Systemlandschaft oder welcher Workflow entsteht, wenn alle Empfehlungen genau wie geplant ausgeführt werden?
• Kein Side-by-Side-Optionsvergleich, kein konjunktivisches Zögern („man könnte auch“).
• Klarer, selbstbewusster Indikativ: So funktioniert das System in seinem Zielzustand.

3. Zusammenspiel

Der funktionale Kern des Skills:

• Wie greifen die entschiedenen Komponenten nach der Implementierung tatsächlich ineinander?
• Entlang eines konkreten End-to-End-Ablaufs (z. B. „Ein Ticket trifft ein → Agent startet → Backend weist zu → Auf dem Host bereitstellen“) anstatt einer statischen Liste von Komponenten.
• Klärt Datenflüsse, Schnittstellen und betriebliche Verantwortlichkeiten.

4. Implementierung

Die konkrete Abfolge der Rollout-Schritte:

• Was passiert in der Praxis Schritt für Schritt?
• Übernimmt die Ausführungsreihenfolge und Abhängigkeitslogik direkt von decision-path.
• Unabhängige Arbeitsstränge werden ehrlich als parallele Spuren dargestellt (erfinden Sie keine künstlichen Kausalketten; ein Bündel kann aus mehreren parallelen Spuren bestehen). Sequenzielle Anordnung wird nur dort behauptet, wo begründete Abhängigkeiten oder Fristen bestehen.
• Hebt Meilensteine, Migrationsskripte und Validierungsprüfungen hervor.

5. Was dieses Bild nicht abdeckt

Abgrenzung gegen falsche Vollständigkeit:

• Welche sekundären Fragen, ungelösten Probleme oder 🔴 Konfidenzen werden bewusst ausgeschlossen?
• Wo sind die Grenzen zu benachbarten Systemen?
• Ein Bild, das seine Ränder verbirgt, erzeugt ein falsches Sicherheitsgefühl.

6. Freigabe

Die Benutzerinteraktion:

• Die Nutzer*innen prüfen das Bild als Ganzes.
• Antwortoption 1: Explizite Gesamtfreigabe („Sieht gut aus“, „Genehmigt“, „Alles wie vorgeschlagen umsetzen“). Nur in diesem Fall werden alle Bündelposten als entschieden gebucht.
• Antwortoption 2: Gezielte Korrektur in natürlicher Sprache („Bei BH-A die kleinere Variante bevorzugen“, „Kein automatischer Neustart für MD-A“, „VM-A wie belassen“). Löst die Zerlegung in einzelne Entscheidungen aus; alle unkorrigierten Posten bleiben offen.

7. Rückübertragung

Die systematische Übersetzung von Benutzerfeedback in einzelne Ledger-Einträge:

• Keine automatische Mitbuchung: Unveränderte Posten werden nur bei expliziter Gesamtfreigabe gebucht. Eine Teilkorrektur ist keine Gesamtgenehmigung!
• Isolation bei Korrektur: Wenn die Nutzer*innen eine Korrektur einreichen, wird diese in einzelne Entscheidungen zerlegt; alle anderen Posten im Bündel bleiben bis zur Annahme des angepassten Gesamtbildes oder der individuellen Bestätigung der restlichen Posten streng offen (in Quelltickets / Ledger).
• Verbindliche Rückübertragungstabelle: Jedes Teilfeedback erzeugt eine strukturierte Bewertungstabelle mit vier Spalten:
  1. Ursprüngliche Korrektur: Wörtliche Aussage der Nutzer*innen.
  2. Betroffene Schlüssel: Welche Bündel-IDs werden geändert (einschließlich Mehrfachtreffer, wenn eine Aussage mehrere Entscheidungen betrifft).
  3. Domino-Status: Welche abhängigen Knoten oder nachgelagerten Annahmen in decision-path fallen weg oder erfordern eine Neubewertung.
  4. Offene Unklarheiten: Wo die Korrektur mehrere Interpretationen zulässt, die vor der Buchung einer Klärung bedürfen.
• Behandlung von Mehrfachtreffern: Eine einzelne Aussage der Nutzer*innen kann mehrere Entscheidungen gleichzeitig ändern. Die Rückübertragung muss diese Kopplung entwirren und alle betroffenen Schlüssel gemeinsam erfassen.
• Exklusiver Schreibpfad via Phase 4: decision-draw hat keinen nativen Schreibpfad zu Tickets oder Ledgern. Ledger-Updates erfolgen ausschließlich über das standardisierte Protokoll in decision-briefing Phase 4 (Protokollierung und Persistenz in DECIDED-AND-DONE.md oder TO-DECIDE-USER.txt).

---

Beispiel (Pilot-Datensatz: Ticket-Master 2026-09-13 — BACH & System-Cluster)

Reales Bündel aus dem Ticket-Master-Entscheidungsdokument vom 2026-09-13: BH-A, MD-A, CF-A, VM-A, PD-A.

# DECISION-DRAW: BACH Core Cluster & Betriebliche Integrität

## 1. Bündel und Umfang

| Kennung | Ticket / Quelle | Thema | Angenommene Empfehlung | Konfidenz | Alternativen & Details |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | Modell-Backend = Heart | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Mac-Bereitstellung & Neustart | A1 + Skript (nur Bericht für 24/7) | 🟢 | Ticket `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | Konfigurationsziele auf Hosts | 1C (begründet) / 2B (hostabhängig) / 3B (hoch) | 🟢 / 🟡 | Ticket `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | VersicherungsManager Zeitzone | A (app-weite Einstellungen wie routinika) | 🟢 | Ticket `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | USMC-Seitensichtbarkeit | A (Deklaration auf public ausrichten, Status quo) | 🟢 | Ticket `T-20260913-609930207.txt` |

*Hinweis: Alle verworfenen Alternativen (z. B. BH-A E5=B ocean-heart, MD-A A2 volle Schreibschlüssel, VM-A B profilbezogene Zonen) bleiben im Ticket-Master-Entscheidungsdokument dokumentiert.*

---

## 2. Konzept

Wir etablieren eine saubere, entkoppelte Multi-Host-Architektur, bei der das Modell-Backend
als unabhängiges Kernmodul namens `agents-heart` betrieben wird. Rollen, Rechte und Budgets
werden sauber in einer relationalen SQLite-Datenbank verwaltet, während Modell-Routing-Entscheidungen
in zwei Stufen erfolgen: BACH erstellt die domänenqualifizierte Kandidatenmenge, und Clutch wählt
das kosten- und fähigkeitsoptimale Modell innerhalb dieser Menge aus.

Auf dem Mac Studio laufen 24/7-Hintergrunddienste sicher und zuverlässig mit einem schreibgeschützten
Bereitstellungsschlüssel; Code-Updates werden automatisch abgerufen, und laufende 24/7-Dienste werden
sanft benachrichtigt, anstatt gewaltsam beendet zu werden. Konfigurationen können host-spezifisch
bleiben, wo die Leistung es erfordert, während App-weite Einstellungen (wie Zeitzonen im
VersicherungsManager nach dem bewährten Routinika-Muster) deterministisch fest verdrahtet werden.
USMC bleibt die kanonische öffentliche Gedächtnisfassade und behält seinen Platz auf der öffentlichen
Website.

---

## 3. Zusammenspiel

Die fünf Punkte bilden keine serielle Kausalkette; sie stellen vielmehr modulare, entkoppelte
Säulen der täglichen Betriebsintegrität dar, die parallel über das System hinweg ineinandergreifen:

- **Kernarchitektur & Modell-Routing (`BH-A`):** Das Modul `agents-heart` entkoppelt die Modellzuweisung. Wenn eine Aufgabe eintrifft, bestimmt BACH die domänenqualifizierte Kandidatenmenge und Clutch wählt das kosten- und kapazitätsoptimale Modell aus.
- **Host-Konfiguration & Bereitstellungsintegrität (`CF-A`, `MD-A`):** Während konsistenter Reasoning-Aufwand für Laptop und Workstation gilt (`CF-A`; host-abhängige Modelle bleiben transparent), führt der Mac Studio persistente Hintergrundprozesse unter validierten Einstellungen aus. Für Updates zieht der Mac Code über einen schreibgeschützten Bereitstellungsschlüssel (`MD-A`); der GUI-Server wird neu gestartet, während langlebige 24/7-Dienste das Dashboard sanft über Update-Anforderungen benachrichtigen.
- **Domänenpersistenz & Fristen (`VM-A`):** Anwendungen wie der VersicherungsManager persistieren Fristen gegen eine app-weite `settings`-Tabelle nach dem Routinika-Muster. Berechnungen und Fristenwächter arbeiten deterministisch über alle Profile hinweg in derselben IANA-Zeitzone.
- **Öffentliche Präsentation (`PD-A`):** Der nächtliche Site-Builder validiert Repository-Zustände. USMC wird sauber unter seiner korrigierten `public`-Deklaration veröffentlicht, was null Alarme in den Sicherheits-Gates auslöst.

---

## 4. Implementierung

Da der Quelldatensatz keine serielle Kette über diese fünf Punkte im Abhängigkeitsgraphen ([decision-path](../decision-path/SKILL.md)) belegt, wird der Rollout ehrlich in vier unabhängige, parallele Arbeitsstränge strukturiert (Ansatz a: parallele Spuren anstatt erfundener Kausalität). Sequenzielle Anordnung gilt nur, wo externe Fristen oder interne Schritte bestehen:

- **Spur A (Zeitkritisch — Frist 2026-09-14):**
  1. USMC-Metadaten auf `public` ausrichten (`PD-A`); Draft PR #2 verwerfen. Verzögerungen sind aufgrund des nächtlichen Builder-Laufs nicht tolerierbar, dennoch ist dieser Schritt technisch völlig unabhängig von allen anderen Spuren.
- **Spur B (Host-Konfiguration & Mac-Bereitstellung — Parallelisierbar):**
  1. B1: Konfigurationsziele in `.SYNC` kodifizieren (`CF-A`), Reasoning-Aufwand auf `high` für beide Hosts synchronisieren.
  2. B2 (unabhängig von B1): Schreibgeschützten Bereitstellungsschlüssel auf dem Mac Studio installieren und das Pull-and-Report-Automatisierungsskript einrichten (`MD-A`).
- **Spur C (Domänendatenbank — Parallelisierbar):**
  1. Die App-weite `settings`-Tabellenmigration im VersicherungsManager nach dem Routinika-Muster implementieren (`VM-A`), um die saubere Basis für die anschließende Publisher-Entwicklung zu schaffen.
- **Spur D (Architekturextraktion — Interner mehrstufiger Plan):**
  1. D1: SQLite-Schema für Rollen und Budgets in `agents-heart` einrichten (`BH-A` E1).
  2. D2: Den Backend-Katalog als Python-Modul auslagern (`BH-A` E3) und die Clutch-Zuweisungsnaht binden (`BH-A` E2).
  3. D3: Das `agents-heart`-Modul extrahieren und binden (`BH-A` E5, E6).

---

## 5. Was dieses Bild nicht abdeckt

- **Task-Claiming Race Condition:** Der Parallelitätsfehler, der doppelte Task-Ansprüche ermöglicht, wird in einem dedizierten Hotfix-Ticket bearbeitet und liegt außerhalb dieser Freigabe.
- **Cockpit-Frontend:** Das Überwachungs-Cockpit (`BH-A` E4) wird bewusst zurückgestellt, bis das Backend Live-Betriebstelemetrie liefert.
- **Veröffentlichen öffentlicher Repositories:** Das Zusammenführen und Bereitstellen von Code macht private Repositories nicht automatisch öffentlich; endgültige Sichtbarkeitsumschalter bleiben den Nutzer*innen vorbehalten.

---

## 6. Freigabe

Sie können diesen Systemcluster als Ganzes freigeben oder Anpassungen in natürlicher Sprache vornehmen:

- **Explizite Gesamtfreigabe:** „Sieht gut aus, genau wie vorgeschlagen umsetzen.“ (Nur dies löst die Buchung aller Punkte aus).
- **Beispielkorrekturen:**
  - *„Keine Host-spezifische Sonderbehandlung für den Mac: MD-A benötigt volle Schreibschlüssel (A2) für direktes Pushen, und CF-A sollte alle Konfigurationen strikt an der Workstation ausrichten (Gruppe 1=A, 2=A).“* (Mehrfachtreffer)
  - *„Für BH-A E5 nenne es ocean-heart anstelle von agents-heart.“*
  - *„VM-A vorerst verschieben; der Publisher kann warten.“*

---

## 7. Rückübertragung

Wenn das Konzept genehmigt oder geändert wird, übersetzt der Skill das Feedback in Ledger-Einträge:

### Fall A: Explizite Gesamtfreigabe
Wenn die Nutzer*innen das Gesamtbild als Ganzes ausdrücklich genehmigen (z. B. *„Sieht gut aus, genau wie vorgeschlagen umsetzen“*):
- Alle fünf Punkte (`BH-A: 1A/2A/3A/4B/5A/6A`, `MD-A: A1`, `CF-A: 1C/2B/3B`, `VM-A: A`, `PD-A: A`) werden als ENTSCHEIDEN an [decision-briefing](../decision-briefing/SKILL.md) Phase 4 übergeben.
- Phase 4 führt die Ledger-Eintragung durch.