Die Markdown-Datei bleibt die Quelle. Diese Seite macht daraus eine greifbare Arbeitskarte: Was ist Core-Arbeit, was ist Safety, welche Projektfamilien gibt es, und welche Entscheidung kommt als naechstes.
Diese Datei ist die verwertbare Ernte aus ProjectIntakeTower.
Ursprünglicher Auftrag:
Meine Projekte mappen, ihren Zustand verstehen, und daraus eine kontrollierte nächste Arbeitsreihenfolge ableiten.
Nicht-Zweck:
Echte Arbeit: Projektinventar, Triage, Top-10-Actions, Job-Contracts, Verifier, Visual Summary und Owner Digest.
Das ist der 'Was habe ich eigentlich auf meinem System?'-Teil.Kaskadenkontrolle: Panic Stop-Loss, Control Room, Night Stop, STOP_NOW, Morning Resume und Safety-nahe Consolidator-Artefakte.
Das ist Betriebsunfall-Management. Wertvoll, aber anders wertvoll als Produktarbeit.Vollstaendige, lange Artefakte wie HUMAN_DECISION_REQUIRED, Backlog, Evidence-JSONs und Generated Reports.
Durchsuchbar, aber nicht zuerst lesen.Zweck:
Mein langfristiger Agent Control Tower / Dashboard / Steuerungsraum.
Relevante Projekte aus dem Scan:
Aktueller Zustand:
Viele Varianten derselben Grundidee.
Noch nicht weiterbauen.
Erst Konsolidierungsentscheidung treffen.
Nächste menschliche Entscheidung:
Welches Repo wird Anchor für Agent Control Tower?
Kandidaten:
Status:
HUMAN_DECISION_REQUIRED.
Relevante Projekte:
Aktueller Zustand:
Sehr wichtig, aber potentiell gefährlich, weil operativer Kern.
.hermes hat viele uncommitted changes.
Nächste menschliche Entscheidung:
Erst Sicherheits-Snapshot, dann keine wilden Änderungen.
Status:
STABILIZE_FIRST.
Relevante Projekte:
Aktueller Zustand:
Klarer Duplicate-/Merge-Cluster.
Nicht refactoren.
Erst entscheiden:
Welche Version ist Referenz?
Welche Version ist Archiv?
Welche Version enthält einzelne gute Ideen?
Wahrscheinliche Richtung:
Sidecar-V7 als historisch wertvoller Stand.
Sidecar-V8 / Sidecar-ng prüfen als neuere Adapter-Ideen.
Aber keine Merge-Aktion ohne explizite Entscheidung.
Status:
MERGE_DECISION_LATER.
Relevante Projekte:
Aktueller Zustand:
Nützlich, aber nicht heute Hauptanker.
AgentTestUniSupport ist dirty und braucht Stabilisierung, wenn es aktiv genutzt werden soll.
Status:
KEEP_BUT_NOT_TODAY.
Relevante Projekte:
Aktueller Zustand:
Teilweise wertvoll, teilweise Merge-/Pause-Kandidaten.
WerBinIch ist konkret und wahrscheinlich gut stabilisierbar.
PromptGarage/PromptGarageUI wirkt wie Merge-Familie.
Status:
SECONDARY.
Beispiele:
Aktueller Zustand:
Wahrscheinlich keine aktiven Projekte.
Eher Cache, Fixture, Evaluation oder Altlast.
Status:
ARCHIVE_CANDIDATE.
Aber nicht löschen.
Nur später markieren.
Ist ProjectIntakeTower als Karte brauchbar genug?
Antwort heute:
Ja, als Rohkarte.
Nein, nicht als automatisch vertrauenswürdiger Wahrheitsspeicher.
Nächster Schritt:
Verifier laufen lassen und nur Fehler notieren.
Welches eine Repo bekommt zuerst einen Sicherheits-Snapshot?
Kandidaten:
Meine Tendenz:
Erst .hermes, weil es operatives Nervensystem ist.
Aber nur read-only anschauen und Snapshot planen, nicht blind committen.
Welches Repo wird Agent-Control-Tower-Anchor?
Kandidaten:
Noch nicht entscheiden, bevor die Konsolidierungsartefakte gelesen wurden.
Welche Sidecar-Version ist Referenz?
Kandidaten:
Noch nicht mergen.
Nur vergleichen.
Für heute ignoriere ich:
Keine neuen Agenten.
Keine Builds.
Keine Refactors.
Keine Merges.
Ausgeführt in:
/home/smlflg/Projekte/AgentProjectMinenraeumer/ProjectIntakeTower
Ergebnis:
python3 verifier/verify_inventory.py — passed, 500 projectspython3 verifier/verify_job_contracts.py — passed, 139 pending jobspython3 verifier/verify_artifacts.py — passedInterpretation:
ProjectIntakeTower ist als Rohkarte brauchbar genug, um damit weiter zu verdichten.
Das macht die Karte nicht zu einem automatisch vertrauenswürdigen Wahrheitsspeicher.
Es heißt nur: die Hauptartefakte sind konsistent genug, um kontrolliert weiterzuarbeiten.
Nächste Entscheidung bleibt:
Ausgeführt aus:
/home/smlflg/Projekte/AgentProjectMinenraeumer/ProjectIntakeTower
Ergebnis:
python3 verifier/verify_inventory.py verify_inventory: passed (500 projects) python3 verifier/verify_job_contracts.py verify_job_contracts: passed (139 pending jobs) python3 verifier/verify_artifacts.py verify_artifacts: passed
Bewertung:
ProjectIntakeTower ist als Rohkarte verwendbar. Die Verifier bestätigen Inventar, Job-Contracts und Kernartefakte, aber sie bestätigen nicht automatisch, dass jede Triage- oder Human-Decision-Ableitung inhaltlich richtig ist.
Nächste Entscheidung:
Entweder ProjectIntakeTower weiter zu einer kleineren Owner-Map verdichten oder genau ein Repo read-only für einen Sicherheits-Snapshot vorbereiten. Die stärkste Snapshot-Tendenz bleibt /home/smlflg/.hermes, aber nur mit explizit begrenztem Read-only-Plan.
Diese Datei ist die verwertbare Ernte aus ProjectIntakeTower.
Ursprünglicher Auftrag:
Meine Projekte mappen, ihren Zustand verstehen, und daraus eine kontrollierte nächste Arbeitsreihenfolge ableiten.
Nicht-Zweck:
ProjectIntakeTower hat eine brauchbare Rohkarte erzeugt.
Wichtige Zahlen:
Achtung:
OWNER_DIGEST.md und triage/HUMAN_DECISION_REQUIRED.md wirken nicht vollständig konsistent.
OWNER_DIGEST.md spricht von wenigen Human-Decisions, HUMAN_DECISION_REQUIRED.md zählt 66.
Darum gilt:
Zweck:
Mein langfristiger Agent Control Tower / Dashboard / Steuerungsraum.
Relevante Projekte aus dem Scan:
Aktueller Zustand:
Viele Varianten derselben Grundidee.
Noch nicht weiterbauen.
Erst Konsolidierungsentscheidung treffen.
Nächste menschliche Entscheidung:
Welches Repo wird Anchor für Agent Control Tower?
Kandidaten:
Status:
HUMAN_DECISION_REQUIRED.
Relevante Projekte:
Aktueller Zustand:
Sehr wichtig, aber potentiell gefährlich, weil operativer Kern.
.hermes hat viele uncommitted changes.
Nächste menschliche Entscheidung:
Erst Sicherheits-Snapshot, dann keine wilden Änderungen.
Status:
STABILIZE_FIRST.
Relevante Projekte:
Aktueller Zustand:
Klarer Duplicate-/Merge-Cluster.
Nicht refactoren.
Erst entscheiden:
Welche Version ist Referenz?
Welche Version ist Archiv?
Welche Version enthält einzelne gute Ideen?
Wahrscheinliche Richtung:
Sidecar-V7 als historisch wertvoller Stand.
Sidecar-V8 / Sidecar-ng prüfen als neuere Adapter-Ideen.
Aber keine Merge-Aktion ohne explizite Entscheidung.
Status:
MERGE_DECISION_LATER.
Relevante Projekte:
Aktueller Zustand:
Nützlich, aber nicht heute Hauptanker.
AgentTestUniSupport ist dirty und braucht Stabilisierung, wenn es aktiv genutzt werden soll.
Status:
KEEP_BUT_NOT_TODAY.
Relevante Projekte:
Aktueller Zustand:
Teilweise wertvoll, teilweise Merge-/Pause-Kandidaten.
WerBinIch ist konkret und wahrscheinlich gut stabilisierbar.
PromptGarage/PromptGarageUI wirkt wie Merge-Familie.
Status:
SECONDARY.
Beispiele:
Aktueller Zustand:
Wahrscheinlich keine aktiven Projekte.
Eher Cache, Fixture, Evaluation oder Altlast.
Status:
ARCHIVE_CANDIDATE.
Aber nicht löschen.
Nur später markieren.
Ist ProjectIntakeTower als Karte brauchbar genug?
Antwort heute:
Ja, als Rohkarte.
Nein, nicht als automatisch vertrauenswürdiger Wahrheitsspeicher.
Nächster Schritt:
Verifier laufen lassen und nur Fehler notieren.
Welches eine Repo bekommt zuerst einen Sicherheits-Snapshot?
Kandidaten:
Meine Tendenz:
Erst .hermes, weil es operatives Nervensystem ist.
Aber nur read-only anschauen und Snapshot planen, nicht blind committen.
Welches Repo wird Agent-Control-Tower-Anchor?
Kandidaten:
Noch nicht entscheiden, bevor die Konsolidierungsartefakte gelesen wurden.
Welche Sidecar-Version ist Referenz?
Kandidaten:
Noch nicht mergen.
Nur vergleichen.
Für heute ignoriere ich:
Keine neuen Agenten.
Keine Builds.
Keine Refactors.
Keine Merges.
Ausgeführt in:
/home/smlflg/Projekte/AgentProjectMinenraeumer/ProjectIntakeTower
Ergebnis:
python3 verifier/verify_inventory.py — passed, 500 projectspython3 verifier/verify_job_contracts.py — passed, 139 pending jobspython3 verifier/verify_artifacts.py — passedInterpretation:
ProjectIntakeTower ist als Rohkarte brauchbar genug, um damit weiter zu verdichten.
Das macht die Karte nicht zu einem automatisch vertrauenswürdigen Wahrheitsspeicher.
Es heißt nur: die Hauptartefakte sind konsistent genug, um kontrolliert weiterzuarbeiten.
Nächste Entscheidung bleibt:
Ausgeführt aus:
/home/smlflg/Projekte/AgentProjectMinenraeumer/ProjectIntakeTower
Ergebnis:
python3 verifier/verify_inventory.py verify_inventory: passed (500 projects) python3 verifier/verify_job_contracts.py verify_job_contracts: passed (139 pending jobs) python3 verifier/verify_artifacts.py verify_artifacts: passed
Bewertung:
ProjectIntakeTower ist als Rohkarte verwendbar. Die Verifier bestätigen Inventar, Job-Contracts und Kernartefakte, aber sie bestätigen nicht automatisch, dass jede Triage- oder Human-Decision-Ableitung inhaltlich richtig ist.
Nächste Entscheidung:
Entweder ProjectIntakeTower weiter zu einer kleineren Owner-Map verdichten oder genau ein Repo read-only für einen Sicherheits-Snapshot vorbereiten. Die stärkste Snapshot-Tendenz bleibt /home/smlflg/.hermes, aber nur mit explizit begrenztem Read-only-Plan.