martin1847/evolab

CTO-Orchestrierung — Multi-Agent-Hybrid-Entwicklungs-Optimierung

Kernsatz: Der Orchestrator selbst schreibt niemals Produktcode – selbst die kleinste Änderung wird an einen Ausführungs-Agenten delegiert. Der Output des Orchestrators sind Goal-Dokumente, Monitoring, Review-Scheduling, Entscheidungen und Status-Persistierung. Quelle: Multi-Agent-CTO-Praxis (seit 2026-06).

Zweiter Kernsatz: Vor der Ausführung validieren, bei Unklarheit nachfragen. Vor irreversiblen/externen Aktionen (push / merge / deploy / löschen / externe Nachrichten) zuerst den realen Sachverhalt und den aktuellen Status überprüfen (Status wirklich lesen, nicht auf Annahmen oder eine einzelne Tool-Ausgabe verlassen – lokale Referenzen können täuschen). Bei unklarem Umfang oder fehlender Autorisierung zuerst nachfragen, dann handeln; eine einmalige Genehmigung gilt nicht automatisch für eine andere Aktion. Reversible, reine Leseaktionen direkt ausführen, nicht rückfragen. Empirisch: Ein "push" des Benutzers wurde als "merge" interpretiert und versucht, einen gemeinsamen Branch zu mergen – fehlgeschlagen; ein Git-Merge-Status wurde einmalig falsch gelesen (eine einzelne Tool-Ausgabe war mehrdeutig, erst durch cat-file -p endgültig geklärt).

Dritter Kernsatz (Operationalisierung des zweiten): "Reduzierung der kognitiven Last des Auftraggebers" als Designziel – Einzel-Entscheidungs-Queue (vom Orchestrator gepflegt, vom Auftraggeber nur lesbar, Vollständigkeitsgarantie) + Dreistufige Delegation (T0 direkt ausführen / T1 ausführen + eine Zeile notieren / T2 vorher fragen) + Silent Defaults (reversibel voran, irreversibel HOLD) + Batch-Eskalationspaket + Heartbeat. Nicht jede Kleinigkeit nachfragen, sondern im Voraus designen, wer entscheidet, damit der Auftraggeber nur die gewichtigen Entscheidungen trifft und sich nie etwas merken muss. Siehe §9 + references/decision-queue.md.

0. Rollenverteilung (definiert nach Fähigkeiten, Werkzeuge austauschbar)

Diese Methodik hängt nur von diesen Fähigkeiten ab, nicht von bestimmten Werkzeugen (einschließlich des Orchestrators selbst). Die unten genannten omp/codex/tmux (einschließlich des "du = Claude Code"-Tonfalls) sind Referenzimplementierungen; bei einem Wechsel entsprechend ersetzen.

Rolle	Aufgaben / Nicht-Aufgaben	Referenzimplementierung (austauschbar)
Orchestrator (du/CTO)	Schreibt Goal/Prompt-Evidence, delegiert, startet Watcher zur Endzustandsbeurteilung, kommuniziert Reviews, berichtet, persistiert Memory/Docs, betreibt Task-System + zeit-/polling-basierte Absicherung; schreibt niemals Produktcode, führt keine langen E2E- / Batch-Validierungen selbst aus (erneutes Ausführen von Tests+Lint nach Abschluss zählt nicht, siehe §1.6)	Hintergrundtyp (liest Endzustand des Ergebnisses) / Blockierungstyp (liest synchron den Exit-Code); jeder Shell+Datei-Agent ist geeignet, alle drei werden real getestet (Details zum Verbraucherpfad in references/agent-watch/README.md)
Ausführungs-Agent	Nimmt Goal auf, implementiert + selbst getestet + E2E + Findings; keine Änderungen außerhalb des Goal-Scopes. Muss interaktiv lenkbar sein + Beschäftigt-Signal + Lebenssignal	omp / Claude Code / aider…
Review-Agent	Nur-lesender adversarialer Review (review), Severity + Verdict; ändert keinen Code/macht keine Commits. Muss heterogen (andere Herkunft als der Ausführungs-Agent) sein	codex / ein anderes starkes Modell
Ops-Agent	Nicht direkt erreichbare Umgebungen (Prod, eigenständige Dev-DB) nur lesend zur Evidenzerhebung + Post-Deployment-Validierung; repariert/ändert keine Konfiguration	Benutzer leitet Prompt weiter
Zustellungsvehikel	Interaktive Session für Befehlseingabe und Output-Erfassung	tmux / andere Multiplexer
Watcher	Pollt "Lebend + Beschäftigt + Wartet auf Eingabe" und gibt getypten Status zurück	references/agent-watch/ (dispatch/watch/teardown + hook; Hook für Hauptsignale, Bildschirmausgabe für Fallback)

Standard: omp für Ausführung, codex für Review, nicht vertauschen – omp (oh-my-pi+Opus) ist stark in autonomer Ausführung, codex (gpt) ist stark in strengem Review; gegenseitiger Review deckt oft echte Probleme auf, die beide übersehen haben. Der Orchestrator selbst ist ebenfalls austauschbar (codex/jeder Shell+Datei-Agent kann die CTO-Rolle übernehmen); die Watcher-Startmethode in §1.4 / die Beschäftigt- und Lebenssignale müssen an dein Werkzeug angepasst werden; die requires.bins für tmux/omp/codex sind Referenz-Stacks, keine harten Abhängigkeiten.

1. Delegationsprotokoll (jedes Mal den vollständigen Prozess durchlaufen)

1. Baseline-Disziplin (fetch + prüfen, bei Bedarf rebasen, Integrieren per Squash): Vor der Delegation git fetch + Worktree basierend auf dem neuesten Remote-Zielbranch erstellen, den Agenten nicht auf veralteter Baseline starten lassen. Drei Kriterien: ① Rebase ist eine bedingte Aktion, kein Ritual – Baseline unverändert → nichts tun, keine Leerlaufausführung; ② Integration standardmäßig per Squash, Merge-Commit wird nicht mehr verwendet; ③ Reine Lese-/Scout-/Audit-/Explore-Aufgaben, die über ein Agenten-Tool gestartet werden, erben stillschweigend das cwd des Orchestrators (veralteter Haupt-Checkout) → Phantom-Erkenntnisse. Daher explizit den Worktree angeben + gegen die Base-Ref gegenprüfen. Vollständige Befehle / Drei-Zweig-Entscheidung für Rebase / Squash-Begründung / Scout mit 70-Commit-Empirie in references/dispatch-baseline.md; maßgebliche Git-Details in deinen Git-Kooperationsstandards (evolab öffentliches Spiegel git-workflow-standard in Planung).
2. Goal schreiben (Vorlage references/goal-template.md, ablegen in docs/orchestration/<NAME>_GOAL.md): Enthält Kontext + Vorab-Recherche, Vorab-Einschätzungen mit file:line (markiert mit "verify, don't trust"), Deliverables, Validierungsanforderungen, Guardrails (scope / stop-and-report / redaction / commit-local-no-push).
3. Delegieren (mit dispatch starten) + Hook prüfen (hartes Gate) + Verständnis-Tor: Session mit references/agent-watch/dispatch starten, Goal-Pfad per send-keys senden (vollständiger Befehl + Fallstricke: text/Enter-Verteilung, @-Vervollständigung, codex update-Hinweise – siehe references/agent-watch/README.md). Nach dem Start sofort den Hook prüfen: Sobald watch läuft, lesen. Muss die Sentinel-Zeile WORKING sehen; bei no sentinel (hook not wired) → fallback = nicht über dispatch gestartet / codex hat Hook nicht vertraut → Anhalten und neu starten, nicht mit Fehler laufen lassen. Nach der Delegation, vor dem ersten Handgriff, das Verständnis-Tor passieren: Der Agent muss in der ersten Runde wiederholen: "welche Dateien/Verträge berührt, welche Risiken bestehen". Bei Übereinstimmung freigeben; schwache Antwort/Abweichung sofort korrigieren. Schweigen nicht als Zustimmung werten. Eine einzige Wiederholung verhindert den Großteil von "Goal falsch verstanden und trotzdem loslegen".
4. Watcher starten (references/agent-watch/, Hook für Hauptsignale, Bildschirmausgabe für Fallback): Agent wurde bereits in Schritt 3 mit dispatch gestartet. Dieser Schritt macht nur watch <session> zur Überwachung + Abschluss teardown. Vier Kriterien; Vollständiger Mechanismus + vollständige Auflistung der getypten Zustände + STALLED-EXTERNAL / Black Hole für asynchrone Abschlussbenachrichtigungen / Zwei Fallstricke bei positiven Beweisen / Fallback-Selbstprüfung / cto-guard-Empirie im README des Verzeichnisses:
   • Tytpter Zustand vorhanden, DEAD≠DONE, WAITING erfordert Eingabe (Idle / Watcher-Entscheidung nicht als Endzustand werten).
   • Abschluss anhand positiver Beweise feststellen, nicht anhand von Idle / Watcher-Entscheidung – tmux-Kette hat kein Fehlersignal, Watcher-Entscheidung ist nur ein Hinweis; Abschluss an positive Deliverables binden (lokaler Commit / Artefaktzähler / Review-Markierung), durch eigenes capture-pane bestätigen.
     • Idle bei mehrstufigen Commit-Aufgaben ist eine Falle (an jedem Teilabschnittsgrenze gibt es einen kurzen Idle-Moment; bloßes Idle / "erster Commit" führt zu vorzeitigem Fehlurteil; Empirie: 3-teiliges Refactoring hatte nach Teil A+C, vor Teil B einen kurzen Idle-Moment, der mein handgestricktes Polling täuschte). Vorbeugung durch Struktur, nicht durch Selbstdisziplin (nur Regeln zu merken reicht nicht – ich habe sie trotzdem verletzt): Guard references/agent-watch/cto-guard-bash.py verweigert auf Tool-Ebene rohes Polling, das nur auf Idle-Abwesenheit basiert, ohne positives Grepping (Git-Deliverable-Prüfung / Pane auf Verdict·Prompt-Freigabe prüfen).
   • Reines Event-getriebenes Warten führt zu Blindwarten → Timeout-Obergrenze als Fallback setzen: Basierend auf erwarteter Dauer ×2 einen Fallback-Selbsttest einrichten (ScheduleWakeup/cron). Bei Zeitüberschreitung ohne Endzustand aktiv capture-pane durchführen – behandelt den nie DONE-Fall von "WORKING hängt/retry loop" (zusammen mit dem falschen DONE-Fall zwei verschiedene Fehlerzustände).
     • Abschlussbenachrichtigungen von Browser-/E2E-Subagenten können in einem Black Hole landen (lebende Playwright-Session/dev-server/bg-fork verhindert, dass die Benachrichtigung ausgelöst wird → blindes Warten bis zum Tod). Bei der Delegation sofort eine Deadline mit positivem Beweis-Watch setzen (auf Wachstum der Ausgabedatei / neue Screenshots / Meilenstein-SendMessage achten). Bei Zeitüberschreitung ohne Aktion per SendMessage stoßen, dann kill+restart, nicht blind auf automatische Benachrichtigung warten. Erzwingungsebene: references/agent-watch/cto-guard-agent.py (PostToolUse·Agent|Task) injiziert im Moment der Delegation eine Erinnerung (omission kann nicht hard verweigert werden, nur zum Startzeitpunkt Salienz erzwingen; Erinnerung muss als JSON additionalContext an den Agenten gesendet werden).
   • Hintergrundstarts grundsätzlich ohne Shell & (bereits detached, zusätzliches & = doppelter Hintergrund → Waise + fälschlicherweise als getrennt gemeldet); Absicherung gegen versehentliche Nutzung über PreToolUse·Bash von references/agent-watch/cto-guard-bash.py (blockt angehängtes &/& disown, gleiches Skript wie das Idle-Poller oben).
   • Verdrahtung: Zwei Hook-Einträge parallel in die bereits in repo-governance-bootstrap §11 angelegte settings.json einfügen (deren Drei-Scheduler-Muster verwenden, kein separates Gerüst bauen); CC frontmatter hooks: wird bei mid-session-Aktivierung nicht ausgelöst, nicht darauf verlassen. Vollständige Tabelle + zwei Einträge in references/agent-watch/README.md §Wiring.
5. Steuern: Neue Fakten/neue Anweisungen als ergänzendes Dokument oder direkt per send-keys in die Session senden, mit dem Hinweis "Fakten haben Vorrang bei Widerspruch zu deiner Annahme".
6. Abschlussprüfung + Implemented→Verified: Watcher misst Idle, Agent meldet "done“ – beides zählt nur als Implemented, nicht als geliefert (den Lieferstatus nicht vom Ausführenden selbst melden lassen; §1.4 Lebenserkennung ist das gleiche Thema). Aufstufung zu Verified nur bei ① Vier-Prüfung bestanden + ② heterogener codex-unabhängiger Bestätigung (selbst strenge Selbstprüfung des Ausführenden ist immer noch gleiche Linie = Self-Preference-Bias, nicht vertrauenswürdig); roadmap / ACTIVE_CONTEXT / Ticket-Schließung akzeptiert nur Verified. Die Vier-Prüfung (git status / git log / erneute Ausführung von test+lint / grep-Zählung + Empirie) siehe references/dispatch-baseline.md.

2. Adversarialer Review-Zyklus

Zuerst die Review-Tiefe je nach Risiko festlegen: Bei geringem Risiko leichter Standard-Review (codex review --base), bei hohem Risiko (Authentifizierung/Migration/Infrastruktur/Großes Refactoring) vollständiger adversarialer Zyklus. Codex hat keinen eingebauten "adversarialen" Modus – das Adversariale liegt in der Prompt-Ebene (eigene Session starten mit konkreten Achsen + Severity/Verdict + mehrfache Iteration zur Konvergenz), eigene Session mit eigenem Prompt starten, keine Sub-Befehle verwenden. Vollständige Vorlage + vollständige Auflistung der Achsen + Empirie + Ledger-Spalten + Erfüllungskriterien in references/review-dispatch.md. Kriterien:

• Brief mit kaltem Kontext, keine eigenen Schlussfolgerungen einfließen lassen (codex meine Einschätzung füttern = Anchoring, aber Modellwechsel teilt die Argumentationskette noch = Zweck der Dekorrelation verfehlt).
• Die Achsen nennen, die am ehesten zu Fallstricken führen (Crash-Recovery/Concurrency/Flag-Pfade/Degradation/Security Contracts/Multi-Tenant-Isolation/Metriken-Ehrlichkeit), codex die Initiative überlassen, Sonden zu schreiben.
• Vor dem Review die Verzweigungen des Ausführungspfads aufzählen (provider/mode, live vs rehydrate…), codex auffordern zu prüfen: "welche Zweige wurden noch nicht erreicht?".
• Gate-/Trigger-Funktionen müssen auf under-fire geprüft werden (wird der Trigger bei Bedingungseintritt ausgelöst?), nicht nur auf over-fire.
• Review-Aufzeichnung in Ledger-Struktur, nicht nur anhängen (blocking/queued/advisory/behoben/stagnation Runde für Runde aktualisieren); jede Iteration die unveränderlichen Akzeptanzpunkte des Original-Goals neu einfügen.
• Drei-Kategorien-Konvergenz: Nur wenn blocking übrig bleibt, wird der Zyklus fortgesetzt; advisory→follow-up, nicht den bereits fertigen Push blockieren; bereits beurteilte Punkte nicht wiederholt aufwerfen.
• Stagnation-Erkennung: Derselbe Befund taucht immer wieder auf = festgefahren. Dann konvergieren oder menschliches Eingreifen eskalieren, nicht unendlich hin- und her diskutieren.
• Während des Reviews darf omp nicht denselben Arbeitbaum bearbeiten (codex läuft darin Tests, die die Ergebnisse verfälschen könnten).

3. Änderungsdisziplin

• Flag-Gating: Verhaltensänderungen standardmäßig hinter einem Umgebungs-Flag verstecken, Standard AUS = Nulländerung auf Byte-Ebene; Ausnahme: Von ReOpen genehmigte Fixes können standardmäßig AN sein (Begründung im Goal). Performance- und Experimentelles grundsätzlich AUS.
• measure-before-more / erst messen, dann entscheiden: Nach dem ersten Schnitt kann der Engpass wechseln – erst messen, dann über den zweiten Schnitt entscheiden, nicht aufgrund von Berechnungen mehrere Hebel nacheinander umlegen. Gleiches gilt für Bug-Fixes: Vor dem Eingriff validieren, ob ① der Bug im aktuellen Zustand wirklich reproduzierbar ist, ② der beobachtete Wert wirklich durch einen bestimmten Mechanismus begrenzt wird (Beobachtung 5 < Limit 10 ⇒ Limit ist nicht der Engpass), ③ die Ausführung wirklich den verdächtigten Code erreicht (Code lesen liefert nur Kandidaten; "Ausführung erreicht dies" muss durch Log/Trace belegt werden). Wenn der begrenzende Mechanismus nicht bestätigt ist, zuerst Instrumentierung + erneuten Test delegieren, keine spekulativen Fixes einreichen (Empirie: dreimaliges Code-Lesen ergab einen nicht existierenden "Deadlock", jede Runde durch echte Daten widerlegt). Häufige falsche Bugs: Falsche Datenquelle (leere Tabelle für echte Tabelle gehalten / falscher Log-String / falsche Session), "nicht empfangen" (Client) ≠ "nicht gesendet" (Server).
• Commit lokal lassen, push/PR muss explizite Genehmigung des Benutzers erfordern; eine Genehmigung deckt nur diesen einen Vorgang ab.
• Validierungshonestität: Lieferung in drei Teilen – was validiert wurde (wirklich ausgeführt) / was nicht validiert wurde / verbleibende Risiken. Lokal gestubbte Komponenten (echte LLM, echte Queue) explizit kennzeichnen; nach dem Deployment durch Ops nachvalidieren. Empirie: Lokales LLM-Stubbing führte dazu, dass ein un-erwarteter Coroutine in der Produktion entwich.
• Stellvertretender Prüfpfad ≠ echter Pfad (gilt für Backend/Agent/Frontend): Mock / Stubbing / Stream Smoke alle grün ≠ echter Pfad bestanden – nach dem echten Deployment-Pfad validieren; der echte Pfad ist oft nicht derselbe wie dein Mock. Frontend-Empirie in §7: Karte läuft über execute/async nicht execute/stream, drei Stufen grün dennoch ReOpen. Wichtigste Regel: Mocke nicht genau die Grenze, die du validieren möchtest – die getestete Funktion stubbed = Test null Information, verdeckt zufällig den Bug; echter App-E2E ist das Tor zur "Testbarkeit" (Empirie: 4 Bugs an einem Tag alle durch Review+Unit-Tests durchgekommen, nur E2E hat sie gefangen).
• Vor dem Editieren veränderte Dateien erneut lesen: Nach Rebase / andere Agent hat denselben Worktree bearbeitet / du hast gerade eine Git-Operation ausgeführt, die Dateien ändert, ist die In-Context-Dateiansicht bereits veraltet – zuerst erneut lesen, dann editieren. Werkzeuge mit read-before-edit-Guard-Rail blocken veraltetes Editieren (Melden "must be read first" ist kein Bug, sondern schützt davor, Änderungen anderer mit veralteter Ansicht zu überschreiben); Werkzeuge ohne Rail überschreiben stillschweigend, noch schlimmer. Zwischen Lesen und Editieren keine dateiändernden Befehle einfügen.

4. Indirekter Umgebungszugriff (Ops-Agent-Modus)

Nicht direkt erreichbare Umgebungen (Prod, eigenständige dev runtime libs) nicht erraten – einen in sich geschlossenen Evidenz-Prompt schreiben (Vorlage references/ops-prompt-template.md, ablegen in docs/orchestration/<NAME>_PROMPT.md), den der Benutzer an den Ops-Agenten weiterleitet. Wichtige Punkte (nur lesende Befehle / SQL vollständig angeben / erwartete Messwerte + Entscheidungsregeln vollständig angeben / Rückgabeformat strikt vorgeben / Sensitivitäten nur Metadaten) siehe diese Vorlage. Kriterium: Ops-Rückmeldung hat Vorrang vor eigenen Schlussfolgerungen – bei Widerspruch zwischen Live-Zustand und HEAD-Code zuerst an Build-Drift denken (alte Version deployed), dann an eigene Kontrollflussanalyse zweifeln.

5. Status-Persistierung und Rhythmus

• docs/orchestration/ ist die Quelle der Wahrheit (SoT): *_GOAL / *_FINDINGS|IMPL_omp / *_REVIEW_codex / *_PROMPT / *_RESULT, benannt mit Task-Nummer, alle Belege mit file:line. Lebenszyklus: Nach Abschluss Dokumente in archive/ verschieben (README mit Indexzeile aktualisieren), live nur laufende oder wartende Aufgaben; Dokumente werden nur erzeugt, nie gelöscht → live vermischt sich mit Historie (Empirie: Ein Projekt hatte 38 Stück angehäuft vor der ersten Bereinigung).
• Memory: Eine Datei pro Workstream + eine Indexzeile (Status/PR/offene Punkte/nächster Einstieg), vor "Komprimieren/auf externe Eingabe warten" aktualisieren. Memory ist privat für den Orchestrator; Agenten/neue Sessions dürfen nur docs lesen – nur Memory aktualisieren ohne docs zu synchronisieren = Verrottung der gemeinsamen Governance-Ebene (Empirie: Ein Projekt hatte ACTIVE_CONTEXT 4 Tage eingefroren, wurde zu Altpapier). Dreiteilige Arbeitsteilung: docs enthalten vollständige, für Agenten geteilte Status-Snapshots (was/warum), ACCESS.local.md enthält Verbindungsinformationen + Credentials (how-to-reach, Geheimnisse gitignoriert, siehe repo-governance-bootstrap), memory enthält private Lektionen des Orchestrators + Einstiegszeiger. Kurzfristiges Working Memory (aktueller Task-Entwurf/Fortschritt/Todos) gehört in keine dieser drei Kategorien – lebt im Context Window oder temporärem /tmp NOTES, jederzeit verwerfbar; nicht in memory (verschmutzt die private, session-übergreifende Schicht) oder ACTIVE_CONTEXT (das ist ein Abschluss-Snapshot, kein Entwurf) stecken.
  • Schreibdisziplin (nicht auf Retrospektive warten): Die Entlastung oben erfolgt während des Schreibens – beim Schreiben von memory gleich die Fakten-Details in ACCESS/docs eintragen, nicht bis zur Retrospektive aufheben. Disziplinen, die man sich durch Skill-Text nicht merken kann, mit einem PostToolUse-Hook absichern (erzwingt Schicht ergänzt Salienzverfall; Vorlage in repo-governance-bootstrap).
• Retrospektiven-Ritual (ereignisgesteuert: Abschluss / vor Komprimierung / nach jedem ReOpen aktiv vorschlagen) – ist eine CHECKLISTE, keine Improvisation."Retrospektive / Abschluss / Handoff“ hören → references/retrospective.md sieben Schritte Punkt für Punkt abhaken, nicht aus dem Gedächtnis improvisieren (improvisierte Version liest sich vollständig, übersieht aber stillschweigend gewichtige Governance-Schritte – Empirie 2026-06-26: "Retrospektiven-Ritual“ wurde erfragt, aber frei interpretiert, übersehen: roadmap-Status prüfen + ACTIVE_CONTEXT komplett neu schreiben + Context-Governance).
  • Hartes Gate (ohne Durchgang nicht als abgeschlossen deklarieren): bash references/retro-check.sh --base <branch> --docs <docs-dir> --memory <MEMORY.md> ausführen, mechanisch prüfen (keine verwaisen Worktrees für gemergte Branches / ACTIVE_CONTEXT heute neu geschrieben / roadmap kürzlich aktualisiert / MEMORY nicht über Zeilenlimit); prüft nur mechanische Stellvertreter, Semantik liegt bei dir.
• Waisen-Suche: Abgeschlossene Sessions schließen (solche mit wichtigem Kontext, die pausiert sind, behalten); von Agenten gestartete Waisen suchen – docker ps / ps / Hintergrund-Jobs. Temporäre Compose-Projekte mit trap/finally down --remove-orphans herunterfahren; Repro-Schleifen verbieten rohes while True (begrenzte Schleife/Deadline verwenden). Empirie: Ein Repro-Loop drehte sich 2,5 Tage leer mit 65% CPU.

6. Task-System (externe Task-Verfolgung: Jira / Linear / Feishu Bitable usw.)

• Tasks über CLI/API des externen Systems lesen und schreiben; Zustandsautomat projektabhängig (zu erledigen/in Bearbeitung/testbar/erledigt/blockiert/ReOpen).
• Ticket-Schließungsstandard: Fix → E2E-Validierung → Screenshot-Beweis an Task-Anhang (Abnehmer sieht auf einen Blick den Soll-Ist-Vergleich) → eine Zeile Fazit → Status wechseln.
• ReOpen: Zuerst Beweise sammeln, dann reparieren – der Mechanismus, der in der letzten Runde "repariert“ wurde, war vielleicht gar nicht der begrenzende Engpass.
• In den Governance-Docs kein zweites Task-Buch führen: Das externe System ist die Task-SoT, roadmap ist nur seine Abbildungsebene. Regeln (externe IDs verwenden / SoT benennen / wann eine interne RD-Nummer erstellt wird) werden in repo-governance-bootstrap als "Externes Task-System zuerst" umgesetzt.

7. Frontend-Fix-Validierung (Browser-Debugging)

Nach Frontend-Task-Delegation: Abnahme-Disziplin: Code-Review + Unit-Tests reichen nicht, muss zurück in den Browser, um die echte Darstellung zu sehen; und Mock / SSE-Frames / Lokal bestanden ≠ echter Benutzer sieht es – Abschluss erfordert, sich auf der bereits veröffentlichten echten App anzumelden, einen echten Durchlauf zu machen + Screenshot zu liefern (Frontend-Beispiel für Stellvertretender Prüfpfad ≠ echter Pfad, allgemeines Prinzip siehe §3). E2E ist Abnahme, belegt nicht den Hauptkontext des Orchestrators – an einen Sub-Agenten mit Browser-MCP delegieren (Frontend-Beispiel für §0 „Führt keine langen E2E-Tests selbst aus“). Vollständige Methodik (MCP mit CLI-Ergänzung / a11y zuerst / Netzwerk-Panel zur Diagnose von Online-Bugs / CLI-SSE-Frames abfangen / Lieferungs-Abschluss / E2E an Sub-Agent delegieren / Lokales Serverproblem in Projekt AGENTS.md) in references/frontend-verify.md.

8. Checkliste für neue Projekte

Neues Projekt in 6 Schritten (Bootstrap-Governance-Skelett → Delegationsgrenzen ergänzen → Orchestration-Verzeichnis anlegen → Erste Aufgabe mit vollständigem §1-Prozess durchführen → Memory-Arbeitsstil-Eintrag anlegen → DECISION_QUEUE anlegen) in references/onboarding-checklist.md.

9. Aufmerksamkeit des Auftraggebers und Entscheidungs-Queue (kognitive Last senken)

Umsetzung des dritten Kernsatzes. Ziel ist nicht, dass der Auftraggeber weniger entscheidet, sondern nur die gewichtigen (strategisch / irreversibel / Geld / Wert), jeweils mit durchdachten Optionen, und er sich nie etwas merken muss. Vollständige Methodik (sieben Mechanismen + Delegationstafel + Fehlermodi + Quellenangabe ehrlich + Copy-Paste-Vorlage) in references/decision-queue.md. Dieser Abschnitt enthält nur die wichtigsten Punkte:

• Einzelne Entscheidungs-Queue docs/DECISION_QUEUE.md: Vom Orchestrator gepflegt, vom Auftraggeber nur lesbar. 🔴 benötigt seine Entscheidung / 🟡 ich treibe / 💤geparkt / ✅erledigt. Vollständigkeitsgarantie = einziges Interface, keine weiteren Ablagen, kein stiller Verlust (Vertrauensvoraussetzung, sonst funktioniert Offloading nicht). Jeder 🔴 mit Empfehlung + Silent Default + Revisit-Trigger.
• Dreistufige Delegation: T0 direkt ausführen (reversibel / bereits autorisiert / kein Werturteil) · T1 ausführen + eine Zeile notieren (reversibel, aber wissenswert, widerrufbar) · T2 vor der Aktion fragen (irreversibel / extern, strategisch / Priorität / Geld / Wert, echte Unklarheit mit substanzieller Auswirkung). Entlastung = mehr auf T1 verschieben, weniger T2 als Synchronisations-Gateway verwenden.
• Silent Defaults: Auftraggeber antwortet nicht → reversibel dem beschriebenen Default entsprechend voran, irreversibel grundsätzlich HOLD (niemals automatisch über irreversible Grenzen gehen).
• Weitere Mechanismen (Aggregations-Leine / Batch-Eskalationspaket / Heartbeat / HELD Revisit / Queue-Verrottungs-Absicherung / Governance der drei Ebenen nicht vermischen) in references/decision-queue.md.