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