Files
mission-control-v2/docs/wissen
Hitonabi 961b003df4 Zuendung (S4): Idle-Radar + Grossbau-Etappen-Regeln
- deploy/idle-radar-feed.sh (Hermes-Cron 03:45): destilliert aus Journal-
  Fehlermustern (24h) + juengster Traum-Notiz max. 2 belegte Wartungs-
  Kandidaten und legt sie als rohe Ideen (triage) ins native Kanban.
  Ehrlichkeits-Gate: Beleg-Zitat wird MECHANISCH gegen das Material
  geprueft (reproduziert-oder-abgelehnt). Stau-Bremse (>=4 offene Queue-
  Aufgaben oder >=3 offene Karten -> nichts Neues), Dedup dreifach
  (State-Datei + Board-Abgleich inkl. archivierter + --idempotency-key),
  Security/Config/Updates tabu. Analyst gpt-oss-120b, Vertretung GLM.
- deploy/idle-radar-prompt.md: versionierter Boten-Auftrag (Lucys Stimme,
  max 3 Saetze, nichts selbst umsetzen).
- deploy.sh: kopiert idle-radar-feed.sh nach ~/.hermes/scripts/ (greift
  wegen Selbst-Reset-Falle erst ab dem 2. Deploy -> Vorinstallation
  einmalig von Hand; Cron-Registrierung einmalig: hermes cron create).
- Grossbau-Etappen-Regeln (Zielbild-Entscheid 4, 10.07.): werkstatt-SOUL
  Regel 6 + wartung-/orchestrator-SKILL Scope-Check: Grosses nicht mehr
  ablehnen, sondern in Etappen bauen - jede Etappe eigener Branch, fuer
  sich lauffaehig + annehmbar, Folge-Etappen als neue Queue-Aufgaben,
  NIE auf unangenommene Branches aufbauen.
- Doku: AUFTRAGSBUCH.md (Idle-Radar-Abschnitt), wissen/OFFENE-FAEDEN.md.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-12 18:58:05 +02:00
..

docs/wissen/ — Die Wissens-Heimat für ALLE Agenten

Angelegt 10.07.2026 (Übergabe-Session S1). Dieses Verzeichnis ist die kuratierte Übergabe des Claude-Projektwissens ins Repo — damit Box-Hermes, Hermes Desktop, Gemini/Antigravity und jeder künftige Agent dieselbe Wahrheit lesen.

Warum hier: Die Box liest ~/mission-control-v2/docs/wissen/, Antigravity liest den F:\-Checkout — versioniert, deploybar, kein Agent-privates Gedächtnis. Der Wissens-Vault (~/wissens-vault/) bleibt Lucys LERNSCHICHT (Träume, Radar-Funde, Eigenbau-Landkarte); hier liegt das kuratierte PROJEKT-Wissen.

Die Dateien (Lese-Reihenfolge für einen frischen Agenten)

Datei Inhalt Wann lesen
ZIELBILD.md Richtungs-Entscheid 10.07.: Box übernimmt alles, 4-Session-Paket Immer zuerst — das ist der Kurs
ARBEITSWEISE.md Wer der User ist + die nicht verhandelbaren Arbeitsregeln Vor JEDER Arbeit
STACK.md IPs, Ports, Dienste, Modelle, Backups, Security (live verifiziert) Vor SSH/Deploy/Config
VERDIKTE.md Finale Technik-Entscheide mit Warum — NICHT neu aufrollen Bevor man etwas "Besseres" vorschlägt
FALLEN.md Hart erarbeitete Betriebs-Fallen (Git, Deploy, llama-swap, Hermes, Mem0, PC) Bevor man in eine davon läuft
OFFENE-FAEDEN.md Die EINE Liste offener Punkte + Termine Bei "was ist noch zu tun?"

Dazu im Repo-Wurzelverzeichnis bzw. docs/: AGENTS.md (verbindliche Projekt-Regeln), docs/GEMINI_BRIEFING.md (Notfall-/Review-Briefing für Gemini), docs/RUNBOOK.md (1-Seiten-Mensch-Anleitung), docs/ANTIGRAVITY_REVIEW.md (Review-Prompt).

Pflege-Regeln

  1. Erledigtes raus, Neues rein — OFFENE-FAEDEN.md ist die einzige offene Liste, keine neuen "pending"-Dateien anlegen.
  2. Verdikte werden nur mit neuem, belegtem Anlass wieder geöffnet (Messung, Release, User-Entscheid) — dann in VERDIKTE.md den alten Eintrag ERSETZEN, nicht löschen.
  3. Verifizieren vor Behaupten: Stand-Angaben tragen ein Datum; wer STACK.md ändert, hat live auf der Box gemessen/gelesen, nicht vermutet.
  4. Änderungen laufen wie alles über die Pipeline: Branch → Karte im Auftragsbuch → Klick. Reine Doku hier gehört zu den "Bagatellen ohne Klick"-Klassen (siehe ZIELBILD.md), erscheint aber immer in Morgenlage/Chronik.