Files
mission-control-v2/docs/wissen/ARBEITSWEISE.md
HitonabiandClaude Fable 5.1 479fecd2c6
Ampel / ampel (push) Failing after 24s
Auftragsbuch ausgebaut: Karten-Annahme, Bagatell-Annahme, Lucy-Annahme raus — Gate ist Ampel + User-Merge
Die Vorschlags-Inbox (routers/services auftragsbuch, AuftragsbuchView, /auftraege, Cockpit-
Kachel + Handlungsbedarf-Eintrag, deploy/auftrag-annehmen.sh, lucy-annahme.sh, bagatell-
annahme.sh, docs/AUFTRAGSBUCH.md) war seit 02.08.2026 ungenutzt: Kanban-Tools seit 21.08. aus,
v3-Umbau lief ueber Branch -> Ampel -> Merge -> deploy.sh, PC-Executor-IP in Box und Config
veraltet. Doku behauptete den Karten-Weg trotzdem als Standard.

Jetzt:
- Cockpit: Kachel "Ideen" (offen/haengend) statt "Auftragsbuch"; Handlungsbedarf zeigt haengende
  Ideen und springt in die Ideen-Ansicht.
- Guide/Schaubild: Kreislauf Idee -> Ideen-Queue -> IDE am PC -> Ampel -> DEIN Merge -> Live.
- events.py: kein Auftragsbuch-Fingerprint mehr; config.py: PC_EXECUTOR_URL-Default auf .22.
- Skills/Skripte: selbst-inventur ohne Karten-Abschnitt, morning-report nennt offene Branches,
  konzept-fliessband verweist auf die Ideen-Ansicht.
- Doku: STACK "Deploy & Pipeline" = Branch -> Ampel -> User-Merge -> deploy.sh (einziger Weg),
  GRENZEN/ARBEITSWEISE/FALLEN/README/BEDIENUNG/RUNBOOK/GEMINI_BRIEFING/gitea-workflow angepasst,
  ZIELBILD Punkt 9, OFFENE-FAEDEN + RAPHAEL.md: erledigt.
- Bewusst geblieben: werkstatt-SOUL/projektstart-SOUL (Werkstatt-Persona, eigener Faden),
  Chronik-Kategorie "auftragsbuch" fuer historische Eintraege.
Auf der Box bereits erledigt (Hand): mc2-bagatell.timer deaktiviert + Units archiviert,
PC-Executor-URL in ~/.hermes/config.yaml auf .22.

Baut auf wartung/lucy-stimme-proxy-raphael auf (Proxy /api/lucy/stimme/*).
Gates: eslint 0 Fehler, vitest 59/59, tsc + vite build gruen, frontend/dist committet,
py_compile gruen.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 16:25:05 +02:00

4.2 KiB

Arbeitsweise — wer der User ist und wie hier gearbeitet wird

Kuratiert 10.07.2026. Gilt für JEDEN Agenten, der an diesem System arbeitet (Box-Hermes, Hermes Desktop, Gemini/Antigravity, künftige).

Der User (Hitonabi / „Commander")

  • Kein Software-Entwickler. Selbstbild: „ich mache keine Updates". Er fasst keine Konsole an und drückt keine Update-Knöpfe — alles muss ohne ihn funktionieren oder per Knopf/Lucy/Telegram bedienbar sein.
  • GUI-first / „klicki bunti": visuelle, klickbare Oberflächen sind sein Geschmack; Terminal-Lösungen sind Fremdkörper. Sein Referenz-Erlebnis ist der Antigravity-Agent-Manager-Stil: Aufträge verteilen, Agenten zuschauen, Diffs abnicken.
  • Produkt-Instinkt ernst nehmen: seine „naiven" Fragen treffen oft den Kern (Marketing-Filter → Fan-out-Kritiker; „alles autonom" → Appliance-Prinzip; „Update verpassen?" → Radar). Vorschläge ernsthaft prüfen, nie abtun.
  • Sprache: Deutsch, locker, direkt. Lucy nennt ihn „Commander".
  • Nordstern (wörtlich): „Das komplette System muss AUTONOM funktionieren — in 6 Monaten ohne Claude darf nichts brachliegen." Robustheit/Autonomie schlägt Features.

Die nicht verhandelbaren Regeln

  1. Verifizieren vor Behaupten. Vor jeder Aussage/Änderung auf der Box messen (SSH, Logs, curl, bench) statt aus Doku/Memory/Web zu schließen. Der Agenten-Erzählung (auch der eigenen) nie glauben — Transcripts, worker.log, git-Status sind Beweise. Mehrere erste Befunde kippten erst bei sauberer Gegenprobe.
  2. Scope challengen. Ein Tool-/Technik-Vorschlag (auch vom User) ist kein Umsetzungsbefehl: erst Use-Case klären, bei erkennbarer Fehlannahme kurz stoppen und warnen. Lehrbuch-Best-Practice ≠ unser Use-Case (Beispiele: LobeChat, Tool Search).
  3. Propose-only + Mensch-Gate. Jede Code-Zeile geht als Branch nach Gitea; gemergt wird nur vom User (Ampel grün). Merge/Deploy NIE ohne grünes Gate. Bagatell-Klassen ohne Klick sind ausschließlich: Doku/Wiki/Vault/Chronik/tote Dateien — nichts mit Code-Logik, immer Morgenlage-Bericht.
  4. Security-Config NIE ohne explizites User-Ja (approvals, Tokens, ufw, sudoers, command_allowlist). Direkt-Push auf main braucht ebenfalls ein explizites Ja.
  5. Fremd-Modell-Kritiker als Korrektiv. Wer baut, benotet nicht selbst. Zwei-Kritiker-Gate (Coder-Next + GLM), Urteil nach der Regel REPRODUZIERT-ODER-ABGELEHNT — Freispruch nur mit belegtem Vorher/Nachher.
  6. Hermes-first vor Eigenbau. Vor jedem Neubau prüfen, ob Hermes es nativ kann (Eigenbau-Landkarte im Vault → hermes --help); Befund in den Vorschlag schreiben. Hermes-Quellcode wird NIE gepatcht/geforkt.
  7. Alles reversibel: Branch + Backup + Zeitmaschine + Pin-Register. Nichts bauen, was Lucys ~1-s-Sprech-Latenz oder das Warm-Set gefährdet.
  8. Deutsch für alles User-Sichtbare (Meldungen, Skills, Summaries, Karten). Erste Zeile von Meldungen idealerweise: „Musst du etwas tun? NEIN/JA: …"

Rollen-Abgrenzung der Türen

  • Lucy (Electron-App) = Zuruf, Voice, Begleitung — schlanke api_server-Lane, nicht mästen.
  • Hermes Desktop = Arbeit: Projekte, Coding, Review, lange Threads (cli-Lane). Faustregel: „Repo oder >2 Minuten → Desktop".
  • Telegram = mobil + Melde-/Freigabe-Kanal (Alarmkette, Cron-Delivery).
  • MC2-Web-UI = Verwaltung, Ideen, Chronik/Zeitmaschine, Wissen. Steuerpult, kein Chat — Gesprächs-/Voice-Funktionen gehören zu Lucy/Telegram, nicht in MC2.
  • Gemini/Antigravity = Notfall + Außen-Review, siehe GEMINI_BRIEFING.

Bevor du ein Feature baust: GRENZEN.md — die volle „was gehört wohin"-Landkarte inkl. Code-Ebenen (MC2 vs. Lucy vs. Hermes-Config/Skill/Hook, Quelle tabu) und der roten Linien.

Wissens-Orte

  • docs/wissen/ (dieses Verzeichnis) = kuratierte Projekt-Wahrheit für alle Agenten.
  • AGENTS.md (beide Repos) = verbindliche Bau-Regeln je Repo (lesen Zed/Kilo/Hermes nativ).
  • ~/wissens-vault/ = Lucys Lernschicht (Träume, Radar, Eigenbau-Landkarte) — git-versioniert, im MC2-UI als Wissens-Tab.
  • Mem0 (:8765) = das LIVE-Gedächtnis (auto-lernend, semantisch) — kein Ablageort für Doku.