Release-Radar: hermes-Releases woechentlich gegen die Eigenbau-Landkarte halten

Baustein 2-4 des Plans "mehr Hermes nativ, weniger Eigenkreationen":
- deploy/hermes-release-radar-feed.sh: woechentlicher Cron-Feed (Muster chef-gutachter) —
  GitHub-Releases seit letztem Stand holen (nur Tags, kein main-Churn), Ein-Schuss-Abgleich
  gegen ~/wissens-vault/eigenbau-landkarte.md (Analyst gpt-oss-120b, Vertretung GLM),
  Zitat-Pflicht, fremdblick-Gegenpruefung bei Treffern, stiller Briefkasten-Spiegel
  (source=release-radar). Informiert nur — Updates bleiben manuell (Entscheid 04.07.).
- deploy/release-radar-prompt.md: versionierter Auftrag fuer den Boten-Agenten.
- deploy.sh: Feed nach ~/.hermes/scripts/ ausrollen.
- Skills wartung+orchestrator: Hermes-first-Leitplanke (vor Neubau nativ pruefen,
  Befund in den Vorschlag).
- backup.sh/restore.sh: Nebenbefund geschlossen — ~/.hermes/cron (ALLE Cron-Jobs!) und
  ~/.hermes/state wurden bisher nicht gesichert; Restore haette sie still verloren.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

deploy/skills/orchestrator/SKILL.md

@@ -62,6 +62,10 @@ dann kleiner.
   Modell) gegengelesen werden, bevor du vorschlaegst. Ein Manager, der Worker-Output blind
   zusammenklebt, produziert leisen Muell.
 - **Security-Config ist TABU:** keine Tokens, approvals, ufw, sudoers, ssh-Keys anfassen.
+- **Hermes-first (10.07.2026):** Bevor ein Teil-Task NEUE Infrastruktur baut (Skript, Dienst,
+  Tool, Cron), pruefe ob hermes-agent das nativ kann — erst in die Eigenbau-Landkarte schauen
+  (`~/wissens-vault/eigenbau-landkarte.md`), notfalls `bash -lc 'hermes --help'`. Den
+  Pruef-Befund in den Vorschlag schreiben („nativ vorhanden: nein/ja, weil …").
 - Gate rot oder Kritiker dagegen → trotzdem ehrlich melden (Branch bleibt liegen), nichts beschoenigen.
 
 ## Ablauf

deploy/skills/wartung/SKILL.md

@@ -22,6 +22,11 @@ NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
 
 - NIEMALS auf `main` committen. NIEMALS mergen. NIEMALS deployen oder Dienste neu starten.
 - Security-Config ist TABU: keine Tokens, approvals, ufw, sudoers anfassen.
+- **Hermes-first (10.07.2026):** Bevor du NEUE Infrastruktur baust oder vorschlägst (Skript,
+  Dienst, Tool, Cron), prüfe ob hermes-agent das nativ kann — erst in die Eigenbau-Landkarte
+  schauen (`~/wissens-vault/eigenbau-landkarte.md`: Eigenbauten ↔ nativ, Verdikte), notfalls
+  `bash -lc 'hermes --help'`. Den Prüf-Befund in den Vorschlag schreiben („nativ vorhanden:
+  nein/ja, weil …"). Weniger Eigenkreationen = weniger Wartungsberg.
 - Die Live-Instanz (`~/mission-control-v2`) bleibt unberührt — gearbeitet wird NUR im Worktree.
 - Am Ende steht IMMER ein Telegram-Vorschlag; die Entscheidung trifft der User.
 - Gate rot oder Reviewer dagegen → trotzdem ehrlich melden (Branch bleibt liegen), nichts beschönigen.