phase1c: Deploy mit Rueckweg und Prueftor, tote Deploy-Dateien raus

- deploy.sh zweistufig: Sperre, laufende Update-Jobs verschieben den Deploy, fast-forward,
  dann laeuft die NEUE Fassung als Stufe 2 (Aenderungen am Skript wirken sofort).
  Stufe 2: Prueftor, Abhaengigkeiten, llama-swap-Config nur bei Aenderung des Abzugs in
  diesem Deploy (ohne Motor-Neustart, -watch-config reicht; 5 Sicherungen), alle Repo-Units
  und Drop-ins, Cron-Skripte nach ~/.hermes/scripts, Skills/Plugins, Neustart, Nachpruefung.
  Scheitert etwas: zurueck auf den alten Stand (inkl. llama-swap-Config), Dienste neu,
  dringende Meldung, Eintrag in /srv/models/mc2-deploy.log.
- deploy/pruefen.sh ersetzt die tote CI-Ampel: Shell-/Python-Syntax, ruff, Importe, pytest.
  Laeuft am PC vor dem Push und auf der Box vor dem Umschalten (pytest via requirements-dev.txt).
- Units, die nur auf der Box lagen, jetzt im Repo: projekte-sync.*, lucy-stimme.service,
  mission-control-2-Override.
- Tot und entfernt: Werkstatt-/Projektstart-/Betrieb-SOULs, worker.sh, Agent-Hooks, Ampel-CI
  (samt .gitea-Workflow und Saat in gitea-repo-create.sh), gitea-pr, Governor-Plugin, Specs,
  Selbst-Inventur, Self-Smoke, venv-Audit, setup_autonomous_crons.sh (haette alte Jobs neu
  angelegt), Einmal-Skripte, alte Bench-Skripte, .agents/mcp_config.json, client/ide-skills,
  mcp/requirements.txt. Gitea-Host-Notizen nach docs/archiv/gitea-host.
- morgenmeldung.sh begrenzt das Melde-Log (ueber 3 MB bleiben die letzten 2 MB).
- AGENTS.md: Prueftor und neuer Deploy beschrieben.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

AGENTS.md

@@ -24,18 +24,21 @@ Engine (llama-swap) · Builtin-Routing-Gateway (`model: auto`) · MC2 (FastAPI +
 - **`frontend/dist` WIRD committet.** Auf der Box läuft KEIN Node-Build; das Backend liefert die
   gebauten Assets direkt aus. Nach jeder Frontend-Änderung: `cd frontend && npm run build`, dann
   **das neue `frontend/dist` mit-committen**. Vergessen = Box zeigt alten Stand.
-- **Deploy macht `git pull origin main`** (`deploy/deploy.sh`). Heißt: **`main` muss vor dem
-  Deploy auf Gitea liegen**, und Änderungen an getrackten Dateien im Box-Checkout lassen den Pull
-  scheitern — dort nie von Hand ändern. Neue Schritte in `deploy.sh` greifen erst beim nächsten Lauf.
-  Schritt 3 überschreibt die lebende llama-swap-Config, wenn sie vom Abzug abweicht
-  (`MC_DEPLOY_SKIP_SWAP_CONFIG=1` verhindert das).
+- **Deploy** (`bash ~/mission-control-v2/deploy/deploy.sh` auf der Box) holt `origin/main` per
+  fast-forward — **`main` muss vorher auf Gitea liegen**, im Box-Checkout nie von Hand ändern.
+  Zweistufig seit 24.09.2026: Stufe 1 holt den Stand und startet die NEUE Fassung des Skripts,
+  Stufe 2 prüft (pruefen.sh), spielt Units/Cron-Skripte/Skills aus, startet neu und prüft nach.
+  Scheitert etwas: automatisch zurück auf den alten Stand + dringende Meldung. Laufende Update-Jobs
+  verschieben den Deploy. Die llama-swap-Config wird nur überschrieben, wenn sich der Repo-Abzug im
+  selben Deploy geändert hat (sonst gewinnt die lebende Datei, die MC2 selbst schreibt).
 - **Nie direkt auf `main` arbeiten.** Immer Branch (`wartung/...`), Gate grün, dann Merge/Deploy.
 
 ## Agentic IDE & Vibe Coding
 - **Zero Middle-Layers:** Coding passiert zu 100% lokal auf dem Dev-PC in der **OpenCode Desktop IDE**.
 - Es gibt keinen Zed-Workflow, keine OpenCode-CLI-Mittelschicht und keinen Governor mehr.
 - Der Agent in OpenCode Desktop nutzt via MCP (`.agents/mcp_config.json`) die API der Box (`:9001/v1`), um autonom Projekte zu bauen.
-- **Mix-Ansatz beim Testen:** Der Agent testet lokal. Vor dem Push muss er prüfen, ob das Gitea-`VERIFY`-Skript fehlerfrei durchläuft.
+- **Prüftor:** `bash deploy/pruefen.sh` (Shell-/Python-Syntax, ruff, Importe, pytest) muss vor jedem Push grün sein.
+  Der Deploy auf der Box führt es vor dem Umschalten noch einmal aus; rot = automatisch zurück auf den alten Stand.
 
 ## Zeit & Umgebung
 - **Box = Ubuntu, läuft in `Europe/Berlin`** (seit 03.07.2026; vorher UTC). Dev-PC = Windows.
@@ -47,7 +50,7 @@ Engine (llama-swap) · Builtin-Routing-Gateway (`model: auto`) · MC2 (FastAPI +
   (Single Source of Truth — Router bleiben dünn). Beispiel-Lehre: Restart-Allowlist lebt NUR in
   `services.maintenance` (System-Dienste via `sudo -n`, User-Dienste via `systemctl --user`);
   keine zweite Allowlist in einem Router duplizieren.
-- **Gate vor Commit:** `python -m py_compile <geänderte .py>` muss durchlaufen.
+- **Gate vor Commit:** `bash deploy/pruefen.sh` (enthält `py_compile`, `ruff check .` und die Tests).
 - Wartung ist **sudo-frei** gedacht (systemctl --user). Wo doch sudo nötig ist (llama-swap =
   System-Dienst), sauber über die NOPASSWD-Whitelist / `password_required`-Rückgabe, nie hart failen.
 - ‼️ **Die feingranularen sudoers.d-Regeln sind faktisch wirkungslos.** In `/etc/sudoers` steht