| # Consolidation Decision Packet |
|
|
| ## 1. Executive Decision |
|
|
| System of Record fuer die Agent-Control-Tower-Projektfamilie ist ab jetzt: |
|
|
| `/home/smlflg/Projekte/Zentrale` |
|
|
| Begruendung: `Zentrale` beschreibt sich selbst als lokale adaptive Agent-Zentrale fuer Projektstart, Routing, Context Packs und Harness-Delegation. Es sitzt ueber Claude Code, Codex, OpenCode, Hermes und Gemini und besitzt damit die breiteste Control-Tower-Semantik. Andere Linien definieren explizit Teilrollen: `KomandoZentral` als deterministische Routing-Engine, `AIOS-Cockpit` als Cockpit-Layer, `ACT-agentcommandotower` als minimaler Operator-Cockpit-Snapshot, `MultiHarnessStudio` als Spine/Integrationsidee. Deshalb wird nicht die juengste oder sauberste Linie gewaehlt, sondern die Linie mit der umfassendsten SoR-Semantik. |
|
|
| Wichtige Einschraenkung: `Zentrale` ist dirty und human-gated. Diese Entscheidung erlaubt keine autonome Weiterentwicklung. Sie setzt nur die Konsolidierungsrichtung: verdichten nach `Zentrale`, nicht expandieren in weitere Tower-Linien. |
|
|
| Evidenz: |
| - `ProjectIntakeTower/OWNER_DIGEST.md` — `Zentrale` Top-10 active, Score 70. |
| - `ProjectIntakeTower/triage/PROJECT_PRIORITIZATION.md` — `Zentrale` KEEP, URGENT, HUMAN_DECISION_REQUIRED. |
| - `ProjectIntakeTower/inventory/evidence/zentrale-193cdb6361.json` — README-Summary: Routing, Context Packs, Harness-Delegation, Multi-Harness-Orchestrator. |
| - `ProjectIntakeTower/inventory/evidence/aios-cockpit-0ba0ee2b88.json` — AIOS-Cockpit sagt explizit, dass `Zentrale` Context Packs, Harness Profiles und Run Records besitzt. |
|
|
| ## 2. Project Family Map |
|
|
| | Projekt | Rolle | Status | Warum | Evidenzpfade | |
| |---|---|---|---|---| |
| | Zentrale | Canonical Agent Control Tower: Projektstart, Routing, Context Packs, Harness-Delegation, Run Records | system_of_record | Umfassendste Control-Tower-Semantik; Top-10 active; aber dirty und human-gated | `OWNER_DIGEST.md`; `triage/PROJECT_PRIORITIZATION.md`; `inventory/evidence/zentrale-193cdb6361.json`; `inventory/project_cards/zentrale-193cdb6361.md` | |
| | KomandoZentral / Kommandozentrale | Deterministische Routing-Engine und Decision-Layer | active_supporting | Klare Teilrolle: regelbasiertes Routing fuer AI-Harnesses; sauberer Git-Zustand; nicht UI/SoR ersetzen | `inventory/evidence/komandozentral-46af91fa1c.json`; `inventory/project_cards/komandozentral-46af91fa1c.md`; `inventory/projects.jsonl` | |
| | ACT / Agent Command Tower (`ACT-agentcommandotower`) | Minimaler Operator-Cockpit-Snapshot mit Issue/Branch/Artifact/Review-Disziplin | merge_candidate | Hoher Score und gute Guardrail-Artefakte, aber gleiche Grundidee wie `Zentrale`; sollte als Pattern/Template in `Zentrale` einfliessen, nicht eigene Linie bleiben | `OWNER_DIGEST.md`; `triage/TOP_10_NEXT_ACTIONS.md`; `inventory/evidence/act-agentcommandotower-0112bb030d.json`; `inventory/project_cards/act-agentcommandotower-0112bb030d.md` | |
| | AIOS-Cockpit | Cockpit/UI-Layer ueber vorhandenen Sources of Truth | merge_candidate | README sagt selbst: ersetzt SoR nicht; verweist auf `KomandoZentral` und `Zentrale`. UI/Handoff-Ideen spaeter selektiv mergen | `triage/PROJECT_PRIORITIZATION.md`; `inventory/evidence/aios-cockpit-0ba0ee2b88.json`; `inventory/project_cards/aios-cockpit-0ba0ee2b88.md` | |
| | MultiHarnessStudio | Spec-first Spine/Integrationsschicht zwischen Evidence, Decision, Execution, AgentIDE, Observatory | idea_storage | Wertvoll als Architektur-/Spine-Idee; nicht SoR, weil es mehrere externe SoRs voraussetzt und eher spec-first ist | `triage/PROJECT_PRIORITIZATION.md`; `inventory/evidence/multiharnessstudio-e49f75b275.json`; `inventory/project_cards/multiharnessstudio-e49f75b275.md` | |
| | HarnessDashboard | Harness/Adapter-Visibility, Codex adapter tests, overview API | merge_candidate | Praktische Adapter-/Dashboard-Slices koennen spaeter in Zentrale/AIOS-Layer ausgewertet werden; kein README/keine SoR-Semantik gefunden | `triage/PROJECT_PRIORITIZATION.md`; `inventory/evidence/harnessdashboard-780af9846d.json` | |
| | MegaHarness (`/home/smlflg/Projekte/megaHarness`) | Alte Harness-/Tower-Idee mit unklarem Implementierungsstand | archive_candidate | Evidence deutet auf broken/dirty und fruehere Aussage: keine belastbare Implementierung; nur als Ideenspeicher nach Sichtung | `inventory/evidence/git_repos.json`; `inventory/evidence/broken_projects.json`; `inventory/evidence/todos_fixmes.json`; `inventory/raw_scan.jsonl` | |
| | FusionKomandoZentraleZentrale | Sauberer Neuaufbau von null, minimaler 4-Schritte-Ansatz | idea_storage | Wertvoll als Simplifizierungs-/Neubau-Idee; nicht SoR, weil es ein Fusion/Restart ist und nicht die existierende aktive SoR-Linie | `triage/PROJECT_PRIORITIZATION.md`; `inventory/evidence/fusionkomandozentralezentrale-f1e7d8e139.json` | |
| | Sidecar-nahe Projekte | Safety-/Coaching-/Context-Injection-Layer; nur Abhaengigkeit fuer Tower | human_gated | Mehrere Sidecar-Linien sind Duplicate/Merge/Token-burn; User-Scope sagt: nur als Abhaengigkeit betrachten, nicht umbauen | `OWNER_DIGEST.md`; `triage/MERGE_CANDIDATES.md`; `triage/NEEDS_HUMAN.md`; `triage/PROJECT_PRIORITIZATION.md` | |
| | Agent IDE | Operator-UI / moegliche IDE-Integration | human_gated | OWNER_DIGEST rankt AgentIDE als needs_human; User-Scope sagt: nur human-gated betrachten, nicht weiterbauen | `OWNER_DIGEST.md`; `triage/NEEDS_HUMAN.md`; `inventory/projects.jsonl` | |
|
|
| ## 3. Duplicate Energy |
|
|
| ### Dashboard / Visibility |
|
|
| - `AIOS-Cockpit` — local cockpit, detail pages, handoffs, source-of-truth visibility. |
| - `HarnessDashboard` — adapter/overview API and tests, Codex adapter visibility. |
| - `ProjectDashboard`, `CodexDashBoard`, `ClaudeCodePanel`, `Sidecar-ng-dashboard` — visibility/dashboard energy adjacent to the tower family, but not primary SoR here. |
|
|
| Decision: keep dashboard energy subordinate to `Zentrale`. Do not build a second cockpit until `Zentrale` has a frozen role boundary. |
|
|
| ### Agent routing / orchestration |
|
|
| - `Zentrale` — broad orchestrator and SoR. |
| - `KomandoZentral` — deterministic routing/decision engine. |
| - `ACT-agentcommandotower` — minimal operator cockpit and bounded agent workflow. |
| - `FusionKomandoZentraleZentrale` — clean-room simplification of the same idea. |
|
|
| Decision: `Zentrale` owns the tower. `KomandoZentral` remains active as the routing engine. `ACT` and `Fusion...` become merge/idea sources. |
|
|
| ### Harness adapters |
|
|
| - `HarnessDashboard` — adapter tests/overview API. |
| - `MultiHarnessStudio` — spec-first Spine between Decision/Execution/UI/Evidence layers. |
| - `MegaHarness` — old/unclear harness ambition. |
|
|
| Decision: no adapter expansion. Preserve useful adapter contracts as evidence; do not create more harness repositories. |
|
|
| ### Sidecar / safety layer |
|
|
| - `Sidecar`, `Sidecar-V5`, `Sidecar-V6`, `Sidecar-V7`, `Sidecar-V7-Lite`, `Sidecar-V8`, `Sidecar-ng`, `codex-sidecarV1`, dashboards/governors. |
|
|
| Decision: dependency only. No autonomous Sidecar build, merge, daemon change, process kill, global hook change, or safety-layer refactor. |
|
|
| ### Intake / triage |
|
|
| - `ProjectIntakeTower` — current consolidation evidence and owner digest. |
| - `OWNER_DIGEST.md`, `triage/*.md`, `inventory/evidence/*.json`, project cards. |
|
|
| Decision: `ProjectIntakeTower` remains the evidence/control artifact layer for this consolidation, not the product SoR. |
|
|
| ### UI shell |
|
|
| - `AIOS-Cockpit`, `ACT-agentcommandotower`, `AgentIDE`, `Fusion... thin VSCode client docs`, dashboard projects. |
|
|
| Decision: UI shell is deferred. Agent IDE and VSCode/IDE integrations are human-gated. |
|
|
| ### Old experiments |
|
|
| - `MegaHarness`, `FusionKomandoZentraleZentrale`, older dashboard/control variants, old Sidecar variants. |
|
|
| Decision: freeze as idea storage or archive candidates; extract only named decisions/evidence after Samuel review. |
|
|
| ## 4. Keep / Merge / Freeze / Archive |
|
|
| ### Bleibt aktiv |
|
|
| 1. `Zentrale` bleibt aktiv als System of Record, aber nur nach Stabilisierung des dirty Zustands. |
| 2. `KomandoZentral` bleibt aktiv als supporting deterministic routing/decision engine. |
| 3. `ProjectIntakeTower` bleibt aktiv als read-only evidence and triage harness. |
|
|
| ### Wird zusammengefuehrt |
|
|
| 1. `ACT-agentcommandotower` -> Merge-Kandidat in `Zentrale` fuer bounded-job templates, issue/branch/artifact/review discipline, minimal tower CLI semantics. |
| 2. `AIOS-Cockpit` -> Merge-Kandidat in `Zentrale` fuer cockpit/handoff/UI slices, aber erst nach SoR-Datenmodellentscheidung. |
| 3. `HarnessDashboard` -> Merge-Kandidat fuer adapter/overview API patterns, nicht als eigenes aktives Dashboard. |
|
|
| ### Wird eingefroren |
|
|
| 1. `FusionKomandoZentraleZentrale` als clean-room simplification reference. |
| 2. `MultiHarnessStudio` als Spine/spec-first idea storage. |
| 3. Sidecar-nahe Tower-Dashboards und governors fuer diese Konsolidierung. |
| 4. `MegaHarness` bis human review bestaetigt, ob es noch mehr als Idee/Altlast ist. |
|
|
| ### Archiv-Kandidat |
|
|
| 1. `MegaHarness` — wegen broken/unclear implementation evidence. |
| 2. Aeltere dashboard-only Linien, falls sie keine eindeutige Funktion liefern, die nicht in `Zentrale`/`AIOS-Cockpit`/`HarnessDashboard` bereits enthalten ist. |
| 3. Duplicate Sidecar lines nur nach separater Sidecar-Konsolidierung, nicht in diesem Tower-Paket. |
|
|
| ### Darf ohne Samuel nicht angefasst werden |
|
|
| - Sidecar-Linien und Hook/Daemon/Safety-Layer. |
| - Agent IDE. |
| - Repo-Merges, Archive/Delete/Move. |
| - Datenmodell fuer `Zentrale`/`KomandoZentral`/`AIOS-Cockpit`. |
| - Prozess-Kill/Automation, service/systemd/autostart, global hooks, global Hermes/Claude/Codex/OpenCode Profile. |
|
|
| ## 5. Human Gates |
|
|
| 1. Sidecar: keine Aenderungen an Hooks, Daemons, fail-open/fail-closed Verhalten, Coaching-Regeln, Prozesssteuerung oder Dashboard-Control ohne Samuel. |
| 2. Agent IDE: nur sichten; keine Weiterentwicklung, kein Refactor, kein Pipeline-/Requirements-Change ohne Samuel. |
| 3. Architekturentscheidungen: SoR-Grenzen zwischen `Zentrale`, `KomandoZentral`, `AIOS-Cockpit`, `ACT` und `MultiHarnessStudio` nur nach Owner-Review aendern. |
| 4. Datenmodell: Run Records, Context Packs, Harness Profiles, Decision Output Schema und Handoff-Schema nicht autonom vereinheitlichen. |
| 5. Prozess-Kill/Automation: keine safe-stop/kill/resume/autostart/service-Automation bauen oder aktivieren. |
| 6. Repo-Merges: keine Branch-Merges, PRs, Commits, Pushes oder Cross-Repo-Dateiuebernahmen ohne explizite Freigabe. |
| 7. Archive/Delete: keine Repos verschieben, archivieren, loeschen oder umbenennen ohne explizite Freigabe. |
| 8. Dirty Repos: `Zentrale`, `ACT-agentcommandotower`, Sidecar-Linien, AgentIDE und andere dirty Repos nicht als Build-Ziel verwenden, bevor Zustand stabilisiert ist. |
| 9. Credentials/Auth: jede Integration mit GitHub, lokalen Tokens, Anbieter-Keys, OAuth oder private config stoppt auf needs_human. |
| 10. Global profiles: keine Aenderung an globalen Hermes/Claude/Codex/OpenCode Regeln aus dieser Konsolidierung heraus. |
| |
| ## 6. Top 10 Decisions |
| |
| ### Do now |
| |
| 1. Entscheidung: `Zentrale` als System of Record markieren. |
| - Begruendung: breiteste Control-Tower-Semantik; Top-10 active; AIOS verweist auf Zentrale als Owner fuer Context Packs, Harness Profiles und Run Records. |
| - Evidenzpfad: `inventory/evidence/zentrale-193cdb6361.json`; `inventory/evidence/aios-cockpit-0ba0ee2b88.json`; `OWNER_DIGEST.md`. |
| - Naechster minimaler Schritt: dieses Decision Packet als Konsolidierungsanker verwenden; keine Source-Aenderung. |
| - Darf Codex das machen: yes. |
|
|
| 2. Entscheidung: `KomandoZentral` bleibt active_supporting, nicht SoR. |
| - Begruendung: klar abgegrenzte Routing-/Decision-Engine; sauberer Git-Zustand; wichtige Teilrolle, aber nicht gesamte Tower-Schicht. |
| - Evidenzpfad: `inventory/evidence/komandozentral-46af91fa1c.json`; `inventory/project_cards/komandozentral-46af91fa1c.md`. |
| - Naechster minimaler Schritt: Rolle schriftlich einfrieren; keine Code-Aenderung. |
| - Darf Codex das machen: yes. |
|
|
| 3. Entscheidung: `ACT-agentcommandotower` wird merge_candidate statt eigener aktiver Linie. |
| - Begruendung: gute Guardrails und Minimal-Cockpit-Idee, aber gleiche Tower-Energie wie `Zentrale`. |
| - Evidenzpfad: `inventory/evidence/act-agentcommandotower-0112bb030d.json`; `triage/TOP_10_NEXT_ACTIONS.md`. |
| - Naechster minimaler Schritt: nur Template-/Guardrail-Ideen listen, nicht portieren. |
| - Darf Codex das machen: human_review_only. |
|
|
| ### Defer |
|
|
| 4. Entscheidung: `AIOS-Cockpit` UI/Handoff-Slices werden deferred. |
| - Begruendung: README sagt selbst, es ersetzt die bestehenden SoRs nicht; UI ohne geklaertes Datenmodell wuerde Duplikation erzeugen. |
| - Evidenzpfad: `inventory/evidence/aios-cockpit-0ba0ee2b88.json`. |
| - Naechster minimaler Schritt: UI-Slices als Merge-Kandidat markieren; kein Build. |
| - Darf Codex das machen: human_review_only. |
|
|
| 5. Entscheidung: `MultiHarnessStudio` bleibt idea_storage. |
| - Begruendung: wertvolle Spine-Spezifikation, aber es setzt mehrere externe Schichten voraus und ist nicht der operative SoR. |
| - Evidenzpfad: `inventory/evidence/multiharnessstudio-e49f75b275.json`; `inventory/project_cards/multiharnessstudio-e49f75b275.md`. |
| - Naechster minimaler Schritt: nur referenzieren, nicht ausbauen. |
| - Darf Codex das machen: no. |
|
|
| 6. Entscheidung: UI-Shell/IDE-Frage wird deferred. |
| - Begruendung: AgentIDE ist needs_human; UI-Entscheidungen koennen SoR-Grenzen verfestigen, bevor sie stabil sind. |
| - Evidenzpfad: `OWNER_DIGEST.md`; `triage/NEEDS_HUMAN.md`; `inventory/projects.jsonl`. |
| - Naechster minimaler Schritt: AgentIDE nur als human-gated Abhaengigkeit im Packet belassen. |
| - Darf Codex das machen: no. |
| |
| ### Archive / merge candidates |
| |
| 7. Entscheidung: `HarnessDashboard` ist merge_candidate, nicht aktive Produktlinie. |
| - Begruendung: Adapter-/Overview-API-Patterns sind nuetzlich, aber keine SoR-Semantik und kein README gefunden. |
| - Evidenzpfad: `inventory/evidence/harnessdashboard-780af9846d.json`; `triage/PROJECT_PRIORITIZATION.md`. |
| - Naechster minimaler Schritt: Adapter-Ideen spaeter gezielt reviewen. |
| - Darf Codex das machen: human_review_only. |
|
|
| 8. Entscheidung: `MegaHarness` ist archive_candidate bis Gegenbeweis. |
| - Begruendung: Evidence nennt broken/dirty und unklaren Implementierungsstand; alte Harness-Ambition wuerde Token-Burn erzeugen. |
| - Evidenzpfad: `inventory/evidence/git_repos.json`; `inventory/evidence/broken_projects.json`; `inventory/evidence/todos_fixmes.json`. |
| - Naechster minimaler Schritt: kein Build; nur Samuel fragen, ob archivieren oder als Ideenspeicher behalten. |
| - Darf Codex das machen: no. |
|
|
| 9. Entscheidung: `FusionKomandoZentraleZentrale` bleibt idea_storage, nicht neuer SoR. |
| - Begruendung: clean-room/minimaler Neuaufbau ist wertvoll als Gegenentwurf, aber ein weiterer SoR wuerde die Projektfamilie splitten. |
| - Evidenzpfad: `inventory/evidence/fusionkomandozentralezentrale-f1e7d8e139.json`; `triage/PROJECT_PRIORITIZATION.md`. |
| - Naechster minimaler Schritt: nur die 4-Schritte-Simplifizierung als Decision-Input behalten. |
| - Darf Codex das machen: human_review_only. |
|
|
| ### Must-not-touch warning |
|
|
| 10. Entscheidung: Sidecar- und AgentIDE-nahe Systeme duerfen aus dieser Konsolidierung heraus nicht autonom veraendert werden. |
| - Begruendung: Sidecar ist Safety/Hook/Daemon-Schicht und mehrfach duplicate/token-burn; AgentIDE ist explizit needs_human. Falsche Aenderungen koennen globale Arbeitsumgebung und Datensicherheit betreffen. |
| - Evidenzpfad: `triage/MERGE_CANDIDATES.md`; `triage/NEEDS_HUMAN.md`; `OWNER_DIGEST.md`; `triage/PROJECT_PRIORITIZATION.md`. |
| - Naechster minimaler Schritt: als Human Gate im Packet belassen. |
| - Darf Codex das machen: no. |
| |
| ## 7. Next Single Code Task |
| |
| Naechster einziger erlaubter Code-Fix nach dieser Konsolidierung: |
| |
| In `/home/smlflg/Projekte/Zentrale` nur den bestehenden dirty Zustand stabilisieren, indem ein read-only Vorcheck plus bestehende Tests/Syntaxchecks laufen und genau ein bereits vorhandener, belegter Pfad-/Registry-Fehler gefixt wird, falls der Verifier ihn reproduziert. Kein Feature, kein UI-Ausbau, kein Cross-Repo-Port, kein Merge. |
| |
| Minimaler erlaubter Scope fuer diesen spaeteren Code-Task: |
| - Repo: `/home/smlflg/Projekte/Zentrale` |
| - Ziel: Stabilisierung des System-of-Record-Repos, nicht Funktionsausbau |
| - Erlaubt: ein kleiner Bugfix an vorhandener Pfad-/Registry-Logik, wenn reproduzierbar |
| - Verboten: neue Tower-Features, neue Repos, Sidecar/AgentIDE-Aenderungen, Datenmodell-Migration, Commit/Push/Merge |
| - Verifier: bestehende Tests/Syntaxcheck plus Git-Diff-Review |
| - Human Gate: wenn Tests mutierende Services, Secrets, globale Profile, Prozess-Kill oder Cross-Repo-Migration verlangen |
| |
