AgentProjectMinenraeumer / ProjectIntakeTower /CONSOLIDATION_DECISION_PACKET.md
smlflg's picture
Initial public upload from Projekte/AgentProjectMinenraeumer
3f604b3 verified
|
Raw History Blame Contribute Delete
16.5 kB

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

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. 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

  1. 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