Hitonabi/mission-control-v2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
mission-control-v2/docs/AUTONOMIE_PLAN.md
T
Hitonabi df8ec46018 Radar (E4): IDE-/Agent-Tool-Kategorie in die Watch-Liste (Roo-Code-Lehre) 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 19:53:22 +02:00

9.4 KiB
Raw Permalink Blame History

AUTONOMIE-PLAN — „Die Box wartet sich selbst" (Kapitel 0)

Erstellt: 02.07.2026, abends — als Kickoff-Paket für die Bau-Session („leg los"). Nordstern (User): Haushaltsgerät, kein Dev-Projekt. Der User macht KEINE Updates, fasst keine Konsole an. Er bekommt Meldungen von Lucy (Telegram) und sagt höchstens „mach". In 6 Monaten ohne KI-Hilfe darf nichts brachliegen — schlimmster erlaubter Zustand: „selbst-gepinnt und läuft".

Kontext-Quellen: Memory open-threads.md (Kapitel 0, Bausteine a–k) · verdicts.md · project-stack-state.md · dieser Plan. Review-Historie: docs/REVIEW_2026-07-02.md.

Architektur: 3 Säulen + Werkstatt

  1. Stabilität — eigene Software (MC2, Lucy) EINGEFROREN + Selbsterhaltung. Gitea = Tresor, kein Update-Kanal.
  2. Frische — Fremd-Software (OS/Engine/Router/Hermes) updatet sich per Timer, mit Gate + Auto-Rollback + Selbst-Pinning.
  3. Evolution — Radar (Hermes-cron + Web-Suche) findet Sprünge/neue Tools; Modelle bencht die Box selbst.
  4. Werkstatt — Box-KIs setzen Wartung/Migrationen selbst um: Telegram-Ping → User „mach" → Branch → Code → Gate → Deploy → Bericht.

Leitplanken (nicht verhandelbar): Merge/Deploy nie ohne grünes Gate · Security-Config (approvals/Tokens/ufw) nie ohne explizites User-Ja · alles reversibel (Backup+Branch+Pin) · kleine Wartung autonom, große nur vorbereitet+freigegeben.

Multi-Agent-Verdikt (recherchiert + entschieden 03.07.2026)

JA — chirurgisch an 2 Stellen; NEIN bei allem Echtzeit-nahen. Hermes-Delegation ist reif: delegate_task (goal/context/toolsets, tasks-Array = parallel, role leaf|orchestrator), Config delegation: (max_concurrent_children, max_spawn_depth, eigenes delegation.model/provider).

  • E4 Radar = Fan-out-Muster: Manager delegiert pro Komponente/Kategorie einen isolierten Leaf-Subagent (eigener 65k-Kontext) → recherchiert, filtert Marketing-Müll, liefert nur Substanz-Summary → Manager konsolidiert. Müll erreicht den Haupt-Kontext nie.
  • E6 Werkstatt = Worker/Reviewer-Muster: Worker patcht im Worktree, SEPARATER Reviewer- Subagent (frischer Kontext) prüft Diff gegen Auftrag, dann erst Gate+Telegram. (Verdent-Muster, lokal nachgebaut.)
  • NICHT bei Lucy-Voice (Konsens 2026: Agent-Ketten ≈ 3× Latenz bei Echtzeit — unsere 2 s sind heilig). Lucy bekommt stattdessen Delegation als FEATURE: „recherchier ich im Hintergrund" → Background-Subagent → Ergebnis via Telegram. NICHT bei der IDE-Lane (eigene Agent-Loops).
  • Kein Hirn-Tausch: Parent bleibt Qwen3.6; delegation.model/provider → MC2-Gateway. Manager-/Reviewer-Kandidat = gpt-oss-120b (Faden B5 entscheidet heavy-Lane UND Manager-Rolle in einem). max_concurrent_children: 2 — passt exakt auf die 2 Hirn-Slots (keine Swap-Thrashes); max_spawn_depth: 1 zum Start (flat), Orchestrator erst bei Bedarf.
  • Ehrliche Physik: eine GPU ⇒ Parallelität bringt KEIN Tempo (geteilte Bandbreite), sondern Kontext-Isolation + Qualität. Für nächtliche cron-Jobs genau richtig; deshalb Voice-Ausschluss.

Was schon existiert (nutzen, nicht neu bauen!)

Baustein Wo
Update-Pipeline je Ebene mit Backup+Checks UI-Buttons: OS/Engine (deploy/update-engine.sh — hat schon stack-postcheck+Auto-Rollback!), Router (update-swap.sh), Hermes (POST /api/maintenance/hermes-update → backup→update→doctor→Postcheck)
Qualitäts-Gate (Abnahmetest für ALLES) deploy/hermes-postcheck.sh: Mem0+Plugin+Config-Drift-Scan+Tool-Smoke+Voice-Smoke, E2E grün. ⚠️ pipefail-Lektion: Stream-Probes brauchen set +o pipefail-Subshell
Tägliches Backup + Restore deploy/backup.sh (Timer 03:30) / restore.sh
Telegram Hermes-Gateway läuft mit Telegram; CLI hermes send (Syntax in Session verifizieren: hermes send --help)
Cron hermes cron (Subcommand existiert)
Coding-KI Qwen3-Coder-Next (coder-Lane, 131k ctx); Hermes v0.18 hat „Coding Projects mit git-worktree-Management"
PC-Fernsteuerung client/hermes-pc Executor (Token HERMES_PC_TOKEN) — für Lucy-Builds auf dem Windows-PC
Bench-Harnesses deploy/bench/brain-bench.sh + deploy/bench/model-bench.sh (mit diesem Kickoff ins Repo gelegt)
Health/Repair LucyHealthCard + /api/health brain-Check; systemd Restart=on-failure überall

Etappen (in dieser Reihenfolge bauen)

E1 · Nervensystem: Meldeweg (klein, zuerst — alles Weitere nutzt ihn)

  • deploy/notify.sh "<Nachricht>": primär hermes send (Telegram), Fallback: Logfile + wall. Syntax von hermes send zuerst auf der Box verifizieren (bash -lc 'hermes send --help').
  • Verifikation: Testnachricht landet beim User auf Telegram.

E2 · Frische: Auto-Update-Timer + Rollback + Pin-Register

  • Pin-Register: /srv/models/mc2-pins.json — {komponente: {pinned: bool, version, grund, datum}}. Gepinnte Ebene wird vom Timer übersprungen; Pin-Meldung ging via E1 raus.
  • deploy/autoupdate.sh (Reihenfolge: swap → engine → hermes; Modelle NICHT auto): je Ebene: Update-Check → wenn Update: bestehenden Pfad nutzen (update-engine.sh / update-swap.sh / hermes-update-Job via API + Job-Polling) → Postcheck rot ⇒ Rollback (existiert je Pfad) + Pin setzen + notify; grün ⇒ notify „eingespielt: X→Y".
  • systemd-User-Timer mc2-autoupdate.timer (wöchentlich So 04:30, nach Backup), Unit nach ~/.config/systemd/user/, in deploy/deploy.sh registrieren (Muster: mc2-backup.timer).
  • OS-Ebene: apt braucht sudo → unattended-upgrades (nur Security) in der EINMALIGEN sudo-Session einrichten (zusammen mit Faden C14: stale v1-Unit weg). Bis dahin: OS aus dem Timer raus.
  • Verifikation: Timer-Dry-Run (bash autoupdate.sh), einmal echt durchlaufen lassen, Telegram-Meldungen prüfen; künstlichen Fehlschlag provozieren (Postcheck-FAIL faken) → Rollback+Pin+Meldung.

E3 · Stabilität: Lucy-Produktiv-Build (einfrieren)

  • Im Lucy-Repo (F:\Coding Stuff\lucy): electron-builder ergänzen (portable oder NSIS), asar-Caveat: app.getAppPath() zeigt im Build woanders hin → LUCY_TTS_DIR absolut setzen (Installer-Config oder Start-BAT) — siehe Kommentar in lucy-desktop/src/main/index.ts.
  • Verknüpfung auf den Build; Lucy-Neustart.bat auf Build umstellen; Dev-Modus bleibt für Wartung.
  • Verifikation: Build starten → Worker-Pool bereit, Sprech-Roundtrip.
  • Danach gilt Lucy als EINGEFROREN (Änderungen nur noch via Werkstatt-Kreislauf).

E4 · Evolution: Radar

  • Hermes-cron (monatlich, z. B. 1. des Monats 09:00): Prompt-Job — „Inventar von /api/maintenance/updates + /v1/models + Versionsliste einlesen; per web_search Changelogs/Neuigkeiten zu: llama.cpp, llama-swap, hermes-agent, pocket-tts, onnx-asr/Parakeet, Silero, smart-turn, Electron, three-vrm + Kategorie-Scan (bessere lokale Coder-/Vision-/TTS- Modelle für Strix Halo 128 GB) + IDE-/Agent-Tool-Kategorie (Kilo Code, OpenCode, Claude Code — Lehre 03.07.: Roo Code war Stunden nach der Empfehlung als „eingestellt seit April" entlarvt; genau solche Tod-/Nachfolger-Meldungen muss das Radar fangen); gegen verdicts halten (Verworfenes nicht wieder vorschlagen); Ergebnis als kurzer deutscher Report → notify.sh".
  • Ablage des Prompts versioniert: deploy/radar-prompt.md, cron ruft ihn.
  • Verifikation: Cron einmal manuell feuern, Telegram-Report prüfen (Qualität grob checken).

E5 · Evolution: Modell-Selbst-Evaluation

  • deploy/bench/model-bench.sh <gguf-pfad> [extra-flags] (liegt bei) → pp/tg-Zahlen.
  • Workflow (halbautonom v1): Radar meldet Kandidat → User „mach" → Hermes lädt (hf CLI im backend-venv existiert) → bencht → notify mit Vergleichstabelle → User-Entscheid → Config-Eintrag.
  • Verifikation: einmal mit vorhandenem Modell durchspielen.

E6 · Werkstatt: Wartungs-Workflow (der Schachzug — zuletzt, auf E1–E5 aufbauend)

  • Hermes-Skill/Workflow „wartung": Auftrag (aus Radar oder User) → git worktree im Box-Checkout (MC2) bzw. via PC-Executor (Lucy) → Änderung durch coder-Lane → Gate = Postchecks + Build → Branch-Push zu Gitea → notify mit Diff-Zusammenfassung → User „merge"/„verwerfen" via Telegram (Hermes approvals-Mechanik nutzen) → bei merge: Deploy-Pfad + Backup + Postcheck.
  • Scope v1 BEWUSST klein: Config-Schlüssel-Migrationen, Dependency-Bumps (Lockfile), Ein-Datei- Patches. Architektur-Umbauten: nur Plan+Branch vorbereiten.
  • Verifikation: einen echten Klein-Fall durchspielen (Kandidat: ServicesCard-Restart-Bug, Faden B9 — perfekte Werkstatt-Gesellenprüfung: 1 Datei, klarer Fix, Gate vorhanden).

Definition of Done (Kapitel 0)

  1. Wöchentlicher Auto-Update-Lauf mit Telegram-Meldung, verifiziertem Rollback+Pin-Pfad.
  2. Lucy läuft als gebaute, eingefrorene App.
  3. Monatlicher Radar-Report kommt auf Telegram an.
  4. Ein Modell-Kandidat wurde einmal selbst gebencht + gemeldet.
  5. Die Werkstatt hat EINEN echten Klein-Fix eigenständig bis zum Merge-Vorschlag gebracht.
  6. Runbook-Seite existiert (docs/RUNBOOK.md, 1 Seite Mensch-Anleitung).

Session-Start-Checkliste („leg los")

  1. git -C ~/mission-control-v2 log --oneline -1 auf der Box == origin/main? (SSH: hitonabi@192.168.178.151)
  2. Health: curl -s http://192.168.178.151:9001/api/health → brain ready?
  3. bash -lc 'hermes send --help' → Syntax für E1 klären.
  4. Dann E1 → E6 der Reihe nach; jede Etappe committen + deployen + real verifizieren (Telegram!). Gitea-Push: PowerShell, Auth flatterhaft → einmal Retry.
Reference in New Issue View Git Blame Copy Permalink