# 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