Roadmap: zweiter Orchestrator-Vergleich und erzeugte Kopie nachgezogen

Die Begruendung zum Vergleich vom 2026-09-18 (OpenClaw 2.0, Grok Bot) lag
unversioniert im Arbeitsbaum, zusammen mit der erzeugten Kopie vom
2026-09-19. Beides gehoert ins Repository - die Begruendung, weil sie von
Hand geschrieben ist und bleibt, die Kopie, weil sie den Stand zeigt.

Der Block zwischen den dc:roadmap-Markern bleibt erzeugt und wird beim
naechsten Lauf ueberschrieben; die heute angelegten Items #673 bis #704 sind
darin noch nicht enthalten.

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

docs/Roadmap.md

@@ -86,11 +86,49 @@ Die vier Lücken sind als #196 (Shell), #197 (MCP), #199 (Vision) und #200 (Brow
 aufgenommen. Die Leitlinie bleibt unverändert: **erst Bremsen, dann PS.** Mehr Reichweite
 ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche Tausch.
 
+### Der zweite Vergleich: OpenClaw 2.0 und Grok Bot
+
+Am 2026-09-18 erneut gehalten, diesmal gegen OpenClaw 2.0 (30.08.) mit v2026.9.1 und
+gegen Grok Bot nach der allgemeinen Freigabe (11.08.). Die vier Reichweiten-Lücken sind
+unverändert offen. Neu ist, dass beide **in der Bedienung** vorn liegen: Grok Bot legt
+Freigaben als Karte in den Chat und fasst liegengebliebene Arbeit von selbst nach,
+OpenClaw hat Selbstdiagnose (`doctor`), Update-Probelauf, sichtbar blockierte Kanäle
+und Skills als eigene Sammlung je Agent. Die Warnsignale sind lauter geworden
+(ClawHub-Schadskills, Verbot in chinesischen Behörden, Sandbox-Kritik auch an 2.0;
+Grok Bot teilt ausdrücklich einen Rechner und dieselben Zugangsdaten über alle Bots) —
+die Leitlinie bleibt.
+
+Übernommen, jeweils mit Begründung in Abschnitt 3:
+
+| | Vorbild | Vorhaben |
+|---|---|---|
+| #644 | Grok Bot: Freigabe-Karten im Chat | Freigabe per Button aus Rocket.Chat und Telegram, über eine **austauschbare Kanal-Schnittstelle** |
+| #645 | OpenClaw: blockierte Kanäle mit Behebungshinweis | Kanalzustand sichtbar, unklare Zustellungen ausdrücklich |
+| #646 | Grok Bot: „nudge stalled work" | Taskboard fasst nach |
+| #647 | Grok Bot: Übergabe zwischen Bots | Delegation an einen oder mehrere Agenten |
+| #648 | OpenClaw: `doctor`, Probeantwort vor dem Aktivieren | Selbstdiagnose und Modell-Probeantwort |
+| #649 | — (Nutzerwunsch) | Probelauf neuer Agenten für Personalmanager-Agenten |
+| #198 | Grok Bot: Skill aus erfolgreichem Ablauf | Zuschnitt erweitert: Skill-Format und Skill-Entwurf nach Freigabe |
+| #197 | Composio als Grok-Bot-Plugin | MCP vor Shell gezogen |
+
+Nicht übernommen: offener Skill-Marktplatz, ein gemeinsamer Rechner für alle Agenten,
+geteilte Sitzungen zwischen mehreren Menschen (das Bedrohungsmodell ist intern),
+Handy-App und Sprache. Streaming (#557) bleibt zurückgestellt — der Vergleich liefert
+keinen seiner drei Auslöser.
+
+
+### Sicherheit: vier Schichten statt eines Wächters
+
+Am 2026-09-19 aus dem Vergleich weitergeführt. Anlass: Agenten sollen eigene Skripte
+schreiben dürfen, und heute ist die Workspace-Grenze nur C#-Code im selben Prozess. Die
+Grenze macht das Betriebssystem (Sandbox-Runner #654), deterministische Regeln und
+Detektoren tragen den Rest (#651–#653, #659), ein Security-Agent (#658) bewertet nur auf Anlass
+und mit hartem Budget. Herleitung und Bauplan: [Security-Konzept](Security-Konzept.md).
 ---
 
 ## 1 — Stand aus dem Deploymentcenter
 
-<!-- dc:roadmap stand=2026-08-31T13:27Z items=97 projekt=clawddotnet -->
+<!-- dc:roadmap stand=2026-09-19T12:03Z items=122 projekt=clawddotnet -->
 
 <!-- ERZEUGT - nicht von Hand aendern. Dieser Block wird bei jedem Lauf von
      `php cli/roadmap.php --write` ueberschrieben. Der Zustand wird im
@@ -99,17 +137,18 @@ ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche T
 
 ### Als Naechstes
 
-1. **[FIX] #373 — PathBoundary.Canonicalize bricht bei nicht existierendem Pfadabschnitt ab - Symlink-Schutz greift beim Schreiben nie**
-2. **[FIX] #375 — Log-Verzeichnis aus den Einstellungen wird ignoriert - instance.logDirectory './Logs' gewinnt und wird gegen das Arbeitsverzeichnis aufgeloest**
-3. **[DEC] #180 — E10 entscheiden: Womit wird der Hauptschluessel unter Linux gebunden?**
-4. **[SEC] #190 — L1: Der Hauptschluessel liegt unter Linux im Klartext**
+1. **[DEC] #180 — E10 entscheiden: Womit wird der Hauptschluessel unter Linux gebunden?**
+2. **[SEC] #190 — L1: Der Hauptschluessel liegt unter Linux im Klartext**
+3. **[FIX] #529 — Instanzwechsel haengt die Anwendung auf: Windows beendet sie mit AppHangB1**
+4. **[SEC] #191 — Freigabe-Ansicht: gestagte Aufrufe sichtbar machen und freigeben**
 
 ### FIX — Kritische Befunde — vor allem anderen
 
 | | Vorhaben | Stand | Ziel |
 |---|---|---|---|
-| #373 | PathBoundary.Canonicalize bricht bei nicht existierendem Pfadabschnitt ab - Symlink-Schutz greift beim Schreiben nie | 📋 Offen | — |
-| #375 | Log-Verzeichnis aus den Einstellungen wird ignoriert - instance.logDirectory './Logs' gewinnt und wird gegen das Arbe... | 📋 Offen | — |
+| #373 | PathBoundary.Canonicalize bricht bei nicht existierendem Pfadabschnitt ab - Symlink-Schutz greift beim Schreiben nie | ✅ Erledigt | `cffd6f4` |
+| #375 | Log-Verzeichnis aus den Einstellungen wird ignoriert - instance.logDirectory './Logs' gewinnt und wird gegen das Arbe... | ✅ Erledigt | `cffd6f4` |
+| #529 | Instanzwechsel haengt die Anwendung auf: Windows beendet sie mit AppHangB1 | 📋 Offen | — |
 
 ### DEC — Offene Entscheidungen
 
@@ -132,9 +171,17 @@ ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche T
 |---|---|---|---|
 | #190 | L1: Der Hauptschluessel liegt unter Linux im Klartext | 📋 Offen | — |
 | #191 | Freigabe-Ansicht: gestagte Aufrufe sichtbar machen und freigeben | 📋 Offen | — |
+| #651 | Herkunftsregel: Lauf nach Fremdinhalt belastet - danach jede Aktion mit Aussenwirkung freigabepflichtig | 📋 Offen | — |
+| #652 | Befunde und Quarantaene mit zwei Stufen: niedrig = Vorschlag per Messenger, hoch = sofort und nur in der Oberflaeche ... | 📋 Offen | — |
+| #653 | Regelbasierte Detektoren ueber das Audit und Koederwerte (Canaries) in Workspace und Schluesselbund | 📋 Offen | — |
+| #659 | Belastung wandert mit: Gedaechtnis, Skill-Entwuerfe und Tasks aus belasteten Laeufen tragen die Herkunftsmarke weiter... | 📋 Offen | — |
 | #192 | Output-Scrubbing: Secret-Werte zentral aus allen Tool-Ergebnissen maskieren | 📋 Offen | — |
+| #654 | Sandbox-Runner (bwrap): jede Codeausfuehrung ausserhalb des Hauptprozesses - Voraussetzung fuer Skripte, Shell und MC... | 📋 Offen | — |
+| #655 | Netzprofil je Agent: Websuche des Modells, Anbieter-Datennutzung und Sandbox-Netz einzeln einstellbar | 📋 Offen | — |
+| #657 | Skriptpruefung: Agenten schreiben eigene Skripte, ausgefuehrt wird nur die freigegebene Fassung (Hash-gebunden, jede ... | 📋 Offen | — |
 | #193 | Tool-Ergebnisse als untrusted content rahmen | 📋 Offen | — |
 | #194 | Secret-UI: Zugangsdaten setzen und rotieren | 📋 Offen | — |
+| #658 | Security-Agent: eingeschraenktes Profil des AgentInspector - Befunde bewerten, Skripte einschaetzen, taegliche Stichp... | 📋 Offen | — |
 | #237 | Audit-Log und Receipts (A3, F-A2) | ✅ Erledigt | — |
 | #238 | Staging-Kern (A2, F-A1, S4) | ✅ Erledigt | — |
 | #249 | S1: SqlGuard statt Teilzeichenketten-Pruefung | ✅ Erledigt | — |
@@ -150,16 +197,19 @@ ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche T
 | | Vorhaben | Stand | Ziel |
 |---|---|---|---|
 | #195 | FileRW-Papierkorb statt endgueltigem Loeschen | 📋 Offen | — |
-| #196 | L4: Shell-Tool mit echter Sandbox | 📋 Offen | — |
+| #646 | Taskboard fasst nach: festhaengende und liegengebliebene Tasks erkennen und ueber den Kanal melden | 📋 Offen | — |
+| #647 | Delegation an einen oder mehrere Agenten: Task gezielt verteilen, Teilaufgaben je Agent, Sammel-Task wartet auf alle | 📋 Offen | — |
 | #197 | L5: MCP-Client fuer stdio- und HTTP-Server | 📋 Offen | — |
+| #196 | L4: Shell-Tool mit echter Sandbox | 📋 Offen | — |
 | #198 | A4: Skills und Toolsets - dreischichtiger Prompt statt "alles immer" | 📋 Offen | — |
 | #199 | L6: Vision - Bild-Content-Blocks im OpenRouterClient | 📋 Offen | — |
 | #200 | L7: Browser-Tool mit Live-Ansicht | 📋 Offen | — |
 | #201 | Memory-Flush vor der Compaction | 📋 Offen | — |
 | #202 | Memory-Auto-Injection relevanter Abstracts | 📋 Offen | — |
-| #203 | Die Compaction laeuft nach dem API-Aufruf - der ueberfuellte Prompt ist da schon bezahlt | 📋 Offen | — |
+| #203 | Die Compaction laeuft nach dem API-Aufruf - der ueberfuellte Prompt ist da schon bezahlt | ✅ Erledigt | `cffd6f4` |
 | #204 | AgentInspector: ein Supervisor-Agent, der die anderen beurteilen kann | 📋 Offen | — |
 | #205 | AgentEditor haerten: Aenderungen an Identity.md und Soul.md freigabepflichtig | 📋 Offen | — |
+| #649 | Probelauf fuer neue Agenten: Werkzeug fuer Personalmanager-Agenten, einen neu angelegten Agenten vor der Inbetriebnah... | 📋 Offen | — |
 | #239 | Taskboard (A1, F-A4, F-A5) | ✅ Erledigt | — |
 | #240 | Langzeitgedaechtnis (K1) | ✅ Erledigt | — |
 | #256 | B1 und B14: Compaction mit sicherem Schnittpunkt, kein doppelter System-Prompt | ✅ Erledigt | — |
@@ -173,13 +223,18 @@ ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche T
 | #264 | T1 und T9: Prompt-Caching mit Breakpoints, cached_tokens gemessen | ✅ Erledigt | — |
 | #265 | T3: guenstiges Modell fuer die Zusammenfassung | ✅ Erledigt | — |
 | #266 | T7: durch die Assignee-Semantik des Taskboards beantwortet | ✅ Erledigt | — |
+| #557 | Streaming der Modellantwort (SSE) statt einer Antwort am Stueck | 🧊 Zurueckgestellt — Ausloeser: Wieder anstehend, sobald EINES davon eintritt: (a) ein Lauf scheitert nachweislich an einem Verbindungsabbruch waehre... | — |
 
 ### COMM — Kommunikation zwischen Agenten
 
 | | Vorhaben | Stand | Ziel |
 |---|---|---|---|
-| #206 | B8: AgentComm.send_message hat keine Tiefenbegrenzung - A nach B nach A verklemmt | 📋 Offen | — |
+| #644 | Freigabe im Messenger: gestagte Aufrufe per Button aus Rocket.Chat und Telegram freigeben - ueber eine austauschbare ... | 📋 Offen | — |
+| #645 | Kanalzustand sichtbar: ausgefallene Kanaele als blockiert zeigen, unklare Zustellungen ausdruecklich melden | 📋 Offen | — |
+| #206 | B8: AgentComm.send_message hat keine Tiefenbegrenzung - A nach B nach A verklemmt | ✅ Erledigt | `cffd6f4` |
+| #461 | Zwei Delegationsketten ueber Kreuz verklemmen sich - A ruft B, waehrend B A ruft | ✅ Erledigt | `cffd6f4` |
 | #207 | Agentenkommunikation Phase 1: ParentRunId und RootRunId | 📋 Offen | — |
+| #536 | A2A-Endpunkt liest den Absender per Zeichenoffset aus einem Anzeigetext zurueck | 🔨 In Arbeit | — |
 | #208 | Agentenkommunikation Phase 2: Nachrichtenspeicher AgentMessages mit FTS5 | 📋 Offen | — |
 | #209 | Agentenkommunikation Phase 3: ask_agent mit Tiefe 1 und Zykluspruefung | 🧊 Zurueckgestellt — Ausloeser: sobald E4 entschieden ist - ask_agent eng gefasst behalten oder ersatzlos streichen | — |
 | #210 | Agentenkommunikation Phase 4: Paar-Ansicht an den Datenbestand anschliessen | 🧊 Zurueckgestellt — Ausloeser: sobald Phase 2 steht und die Tabelle AgentMessages Daten fuehrt | — |
@@ -201,11 +256,13 @@ ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche T
 
 | | Vorhaben | Stand | Ziel |
 |---|---|---|---|
+| #537 | Abnahmedurchgang unter Linux: Instanzmanager, Sockets und Mehrinstanzbetrieb auf der Ubuntu-VM pruefen | 📋 Offen | — |
 | #214 | L2: 24/7-Betriebsform unter Linux | 📋 Offen | — |
+| #648 | Selbstdiagnose (doctor) und Modell-Probeantwort vor dem Aktivieren | 📋 Offen | — |
 | #215 | L3: Release-Strecke linux-x64 (DC3) | 📋 Offen | — |
 | #216 | DC1: Schaltflaeche "Fehler melden" in der Oberflaeche | 📋 Offen | — |
 | #217 | DC2: Bugtracker-Tool fuer Agenten | 📋 Offen | — |
-| #218 | Deploymentcenter-SDK von 2.6.0 auf 2.7.0 nachziehen | 📋 Offen | — |
+| #218 | Deploymentcenter-SDK von 2.6.0 auf 2.7.0 nachziehen | ✅ Erledigt | `0.1.2` |
 | #219 | DC4: SDK als Git-Submodul statt Cross-Repo-Pfad | 📋 Offen | — |
 | #220 | DC5: Evaluator-Cron einrichten (Betreiberaufgabe) | 📋 Offen | — |
 | #221 | Release-Guard beim Upload: ein frisches Produktverzeichnis steht ohne .htaccess da | 📋 Offen | — |
@@ -238,10 +295,10 @@ ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche T
 
 | | Vorhaben | Stand | Ziel |
 |---|---|---|---|
-| #233 | B9: index_Count-Race in FileRWTool | 📋 Offen | — |
-| #234 | B13: instanceId-Inkonsistenz zwischen RunAsync und SendMessageAsync | 📋 Offen | — |
-| #235 | DST-Randfall: eine nicht existierende Ortszeit wird uebersprungen statt verschoben | 📋 Offen | — |
-| #236 | 45 Nullable-Build-Warnungen | 📋 Offen | — |
+| #233 | B9: index_Count-Race in FileRWTool | ✅ Erledigt | `cffd6f4` |
+| #234 | B13: instanceId-Inkonsistenz zwischen RunAsync und SendMessageAsync | ✅ Erledigt | `cffd6f4` |
+| #235 | DST-Randfall: eine nicht existierende Ortszeit wird uebersprungen statt verschoben | ✅ Erledigt | `cffd6f4` |
+| #236 | 45 Nullable-Build-Warnungen | ✅ Erledigt | `cffd6f4` |
 | #248 | Paket-Anhebungen gegen verwundbare transitive Fassungen | ✅ Erledigt | — |
 | #267 | K3: Testfundament | ✅ Erledigt | — |
 | #268 | Fruehjahrsputz: NU1903 und NU1902 geschlossen | ✅ Erledigt | — |
@@ -470,6 +527,12 @@ Namenskollisionen, Schema-Validierung, Ergebniskappung wie bei eigenen Tools.
 Nimmt dem `Http`-Tool aus dem Ideenspeicher die Dringlichkeit. Zusammen mit #198 denken —
 Toolsets und nachladbare Server sind dasselbe Problem: nicht alles immer im Prompt.
 
+**Seit dem 2026-09-18 vor Shell (#196).** Der zweite Vergleich hat bestätigt, woher der
+Vorsprung kommt: Grok Bot bindet über ein einziges Composio-Plugin mehr als 1.000 Apps
+mit OAuth an. Ein MCP-Client bringt mehr Reichweite als jedes eigene Werkzeug, und er
+braucht keine Sandbox wie die Shell. Hinter den Bremsen (#190, #191, #192) bleibt er
+trotzdem.
+
 ### [CAP] #198 — A4: Skills und Toolsets
 
 Größter Token-Hebel nach dem Caching — und ohne Toolsets ertrinkt der Prompt in den
@@ -478,6 +541,76 @@ Tools, die #197 hereinbringt.
 **Agenten dürfen Skills aus Erfahrung selbst schreiben — aber erst nach Freigabe
 aktiv**, sonst ist es ein Injection-Kanal in künftige Läufe.
 
+**Erweitert am 2026-09-18** (Vorbild Grok Bot, der aus einem gelungenen Ablauf einen
+Skill macht):
+
+- **Ein Skill ist kein Freitext.** Er hat Schritte, Entscheidungsregeln, Anforderungen an
+  das Ergebnis und **Freigabegrenzen** — ab welcher Aktion er zwingend über Staging
+  läuft. Die Freigabegrenze steht im Skill, damit sie beim Prüfen sichtbar ist, und
+  wirkt trotzdem nur über die Policy: Ein Skill kann sie verschärfen, nie lockern.
+- **Entwurf aus einem erfolgreichen Lauf.** Nach `done` mit bestandener `acceptance` darf
+  der Agent einen Skill vorschlagen. Der Entwurf ist ein gestagter Vorschlag, verweist
+  auf RunId und Receipts des Laufs, aus dem er entstand, und wird erst nach Freigabe
+  aktiv. So sieht der Prüfer, *was* sich bewährt hat, und nicht nur, was der Agent
+  darüber behauptet.
+- **Skills gehören dem Agenten.** Jeder hat seine eigene Sammlung; einen Skill für die
+  ganze Instanz freizugeben ist ein eigener, zweiter Schritt (Vorbild OpenClaw: private
+  Bibliotheken je Nutzer auf einem gemeinsamen Gateway).
+- Der **Werkzeugwunsch** aus dem Ideenspeicher gehört in den Prompt-Kern.
+
+### [CAP] #646 — Taskboard fasst nach
+
+Grok Bot wirbt damit, liegengebliebene Arbeit von selbst nachzufassen. Bei uns liegt das
+Fundament schon da — Scanner, Status, `blocked_by`, Reopen —, es fehlt nur der Blick auf
+Arbeit, die **formal lebt, aber nicht vorankommt**. Das ist etwas anderes als der
+Claim-Lease: Der räumt abgestürzte Läufe ab, dieses Vorhaben kümmert sich um Tasks, die
+niemand mehr anfasst.
+
+Vier Fälle: `in_progress` ohne Fortschritt, `blocked` mit längst erledigter Vorbedingung,
+`@human`-Tasks, die zu lange warten, und `in_review` ohne Abnahme. **Gestuft**: Ein
+Agent-Task wird einmal mit einem Nachfass-Kommentar geweckt; bleibt er liegen oder ist
+ein Mensch dran, geht eine Nachricht über die Kanal-Schnittstelle (#644). Jede
+Nachfassung höchstens einmal je Frist und über das Budget gedeckelt — erneutes Wecken
+kostet Tokens, und ein Nachfass-Mechanismus, der selbst Dauerfeuer macht, wäre schlimmer
+als keiner.
+
+### [CAP] #647 — Delegation an einen oder mehrere Agenten
+
+Heute trägt ein Task genau einen Assignee. Wer dieselbe Aufgabe an drei Agenten geben
+will, legt drei Tasks an und führt die Ergebnisse selbst zusammen.
+
+**Mehrere Ziele werden zu einem Sammel-Task mit je einem Teil-Task pro Agent.** Der
+Sammel-Task ist `blocked_by` alle Teile und wird geweckt, wenn sie erledigt sind —
+wahlweise wenn *alle*, der *erste* oder die *Mehrheit* fertig ist. Das ist bewusst keine
+neue Laufzeitlogik: `blocked_by`, Reopen, `acceptance` und Claim tragen es, und es bleibt
+strukturell zyklenfrei, weil Tasks Datensätze sind und keine synchronen Aufrufe (dieselbe
+Begründung wie bei #206).
+
+Delegieren können der Mensch (Weboberfläche, Avalonia, Messenger-Befehl über #644) und
+der Agent (Taskboard-Tool). Grenzen: eine Höchstzahl von Zielen je Delegation, ein
+Budget je Teil-Task, das vorab feststeht, und das Ziel muss existieren — kein Raten, wie
+schon bei `@new:<agentId>`. #207 (ParentRunId/RootRunId) verknüpft die Läufe; ohne das
+ist ein Fächer aus Teil-Läufen im Audit nicht mehr als ein Ganzes lesbar.
+
+### [CAP] #649 — Probelauf neuer Agenten
+
+Für den Personalmanager-Agenten aus dem
+[Erweiterungskonzept](Orchestrator-Erweiterungskonzept-2026.md): Wer über AgentSpawn und
+AgentEditor neue Agenten anlegt, soll sie **grob ausprobieren können, bevor sie in
+Betrieb gehen** — sonst merkt man ein fehlendes Werkzeug oder ein untaugliches Modell
+erst im ersten echten Lauf, nachts.
+
+Zwei Stufen: erst die statischen Prüfungen aus #648 (Konfiguration, Modell-Probeantwort,
+Werkzeuge, Workspace, Budget), dann ein kurzer **Trockenlauf** in einem Wegwerf-Kontext.
+Im Trockenlauf wird nichts ausgeführt, was etwas verändert: Freigabepflichtige und
+schreibende Aufrufe werden nur als „hätte gestagt / hätte geschrieben" protokolliert,
+kein Gedächtnis-Schreiben, keine Nachricht nach außen, eigenes kleines Budget.
+
+**Der Probelauf entscheidet nicht über die Inbetriebnahme.** Aktivieren bleibt
+freigabepflichtig, auf der Linie von #205. Der Bericht hängt an der Freigabe, damit der
+Mensch sieht, was ausprobiert wurde — ein Agent, der sich seinen Nachfolger selbst
+abnimmt, wäre genau die Lücke, die #205 schließt.
+
 ### [CAP] #200 — L7: Browser-Tool mit Live-Ansicht
 
 Größte Wirkung, größtes Risiko. Erst wenn #190, #191, #192 und #204 stehen.
@@ -493,6 +626,48 @@ nie.**
 **Zwischenstufe mit einem Großteil des Nutzens und einem Bruchteil des Risikos:**
 `WebFetch` um gerendertes DOM und Cookie-Sessions erweitern, ohne Klick-Automatik.
 
+### [COMM] #644 — Freigabe im Messenger
+
+Staging greift, und freigeben kann man in der Weboberfläche. Unbeaufsichtigter Betrieb
+heißt aber: Niemand sitzt am Rechner. Grok Bot baut seine ganze Bedienung darauf, dass
+die Freigabe als Karte dort ankommt, wo der Mensch ohnehin ist. Das ist der größte Hebel
+aus dem zweiten Vergleich und der kleinste Aufwand.
+
+**Erst die Schnittstelle, dann die Adapter.** Vorgabe ist, jederzeit weitere
+Nachrichtensysteme und Werkzeuge anbinden zu können. Deshalb kommt zuerst eine
+Kanal-Schnittstelle in den Core — senden mit Aktionen, eingehende Entscheidungen als
+Ereignis, Zustand —, und Rocket.Chat und Telegram sind die ersten beiden Adapter. Die
+Freigabe kennt nur die Schnittstelle, nie den Adapter. Das hat eine zweite Wirkung: **Die
+Freigabe hängt nicht mehr an #181.** Wie immer die Chat-Frage ausgeht, der Gewinner
+bekommt einen Adapter, und an der Freigabe ändert sich nichts. Dieselbe Schnittstelle
+tragen #645 und #646.
+
+**Kein zweiter Freigabepfad.** Der Button ruft denselben `StagingService`-Weg wie die
+Weboberfläche — Plan-Freeze, Approval-Record, Folge-Task. Wird anderswo entschieden oder
+verfällt der Vorschlag (nach 24 h), wird die Nachricht nachgezogen, damit kein toter
+Button stehen bleibt.
+
+Sicherheit: Nur hinterlegte Absender je Kanal dürfen entscheiden; die Callback-Daten
+tragen eine nicht erratbare Kennung statt der nackten Vorschlagsnummer; jede
+Entscheidung steht mit Kanal und Absender im Audit. Die Argument-Vorschau ist gekappt
+und läuft durch das Output-Scrubbing (#192) — ein Freigabe-Chat ist genau der Ort, an
+dem ein Secret nicht landen darf.
+
+### [COMM] #645 — Kanalzustand sichtbar
+
+Vorbild OpenClaw v2026.9.1: Ein ausgefallener Kanal bleibt als *blockiert* sichtbar, mit
+einem Hinweis zur Behebung, und eine unklare Zustellung wird als unklar gemeldet statt
+still als Erfolg verbucht.
+
+Sobald Freigaben über den Chat laufen (#644), ist ein stiller Kanalausfall kein
+Schönheitsfehler mehr: Der Vorschlag verfällt, und niemand hat ihn gesehen. Deshalb
+**drei Ausgänge** für jede Zustellung — zugestellt, fehlgeschlagen, unklar — und ein
+Zustand je Adapter (ok, gestört, blockiert) in Weboberfläche, Instanzmanager und
+Avalonia. Ist der Kanal einer Freigabe gestört, steht das an der Freigabe.
+
+Bewusst die abgespeckte Fassung des `ChannelRouter` aus dem Ideenspeicher: erst sichtbar
+machen. Ausweichen auf einen zweiten Kanal ist der nächste Schritt und hängt an #185.
+
 ### [COMM] #206 — B8: `send_message` ohne Tiefenbegrenzung
 
 `AgentComm.send_message` ist ein synchroner Aufruf ohne Tiefenbegrenzung. A→B→A
@@ -551,6 +726,21 @@ als Ausweichweg.
 
 Dazu gehört die Linux-CI: **bis dahin sind die 585 grünen Tests eine Windows-Aussage.**
 
+### [OPS] #648 — Selbstdiagnose und Modell-Probeantwort
+
+Vorbild OpenClaw (`openclaw doctor`, Update-Probelauf, „verifies a real response before
+making the new model active"). Die Befunde aus dem Testbetrieb auf der Linux-VM waren fast alle
+von der Art, die eine Diagnose beim Start gefunden hätte: Rechte, Pfade, ungültige
+Cron-Ausdrücke, liegengebliebene Werkzeugaufrufe. Für eine Maschine, die 24/7 ohne
+Aufsicht läuft (#214), ist „beim Start sagen, was nicht stimmt" die billigste Aufsicht.
+
+Die Diagnose **meldet, sie repariert nicht von selbst** — sichere Reparaturen nur auf
+ausdrückliche Anforderung. Die Modell-Probeantwort ist der zweite Teil: Ein neues Modell
+wird erst aktiv, wenn eine echte Anfrage über OpenRouter geantwortet hat, Tool-Calls
+kann und einen Preis trägt. Sonst bleibt das alte Modell stehen.
+
+Die Prüfungen sind Bausteine im Core, weil #649 sie für neue Agenten wiederverwendet.
+
 ### [OPS] #218 — Deploymentcenter-SDK von 2.6.0 auf 2.7.0 nachziehen
 
 Zwei brechende Änderungen im Changelog: Der Befundzustand aus
@@ -634,13 +824,13 @@ Vorhaben. Steht hier, damit es nicht verlorengeht — nicht, weil es demnächst
 | Dynamische Prompt-Templates | Scriban/Liquid-Variablen (`{{team_roster}}`) in `Identity.md`/`Soul.md` für dynamische Teamerkennung |
 | `ext_clitools/` Struktur | Einheitliche Ablage externer Binaries (`ffmpeg`, `yt-dlp`, `typst`) im Build-Prozess |
 | Task-Archivierung | `done`/`canceled` nach einer Frist archivieren, damit `tasks/` nicht zuwächst |
-| Werkzeugwunsch | Agenten bekommen in den Kern-Prompt den Hinweis, sich zu melden, wenn ihnen ein Werkzeug fehlt. Der Weg ist da — ein Task an `@human`. Gehört zum Prompt-Kern von #198 |
+| Werkzeugwunsch | Agenten bekommen in den Kern-Prompt den Hinweis, sich zu melden, wenn ihnen ein Werkzeug fehlt. Der Weg ist da — ein Task an `@human`. **Seit 2026-09-18 Teil von #198** |
 | `@human`-Tasks mitschreiben | Gäbe die Paar-Ansicht auch für Mensch↔Agent, fast ohne Zusatzaufwand. Nach #210 |
 | MySQL-Gedächtnis | Zweite `IMemoryRepository`-Implementierung, wenn mehrere Rechner dazukommen |
 | Kern als Dienst, Oberfläche als Client | Heute hostet `ClawdDotNet.Desktop` den `AppHost` **in-process**; damit leben die Agenten im UI-Prozess — ein Absturz der Oberfläche nimmt sie mit, und genau die Oberfläche hat keine Testabdeckung. Der Schichtschnitt gäbe die Trennung her, der `AppHost` ist die Naht. **Notiert, nicht beschlossen** — lohnt sich, sobald der erste UI-Absturz eine Nacht Agentenarbeit kostet. Bis dahin trägt #214 |
 | Rocket.Chat Realtime/DDP statt Polling | Antwortzeit ~1 s statt ~30 s |
 | Collabora-Konvertierung | Berichte in Büroformaten. Hängt daran, ob der `convert-to`-Endpunkt freigebbar ist |
-| `ChannelRouter` + Eskalation | Erkennt den Ausfall des Chat-Kanals und weicht auf Telegram aus. **Kein Nice-to-have**, sobald der Chat der Hauptweg ist — sonst ist er ein Einzelpunkt, dessen Ausfall niemand meldet. Hängt an #181 |
+| `ChannelRouter` + Eskalation | Erkennt den Ausfall des Chat-Kanals und weicht auf Telegram aus. **Kein Nice-to-have**, sobald der Chat der Hauptweg ist — sonst ist er ein Einzelpunkt, dessen Ausfall niemand meldet. **Sichtbarkeit seit 2026-09-18 als #645**, die Kanal-Schnittstelle kommt mit #644; offen bleibt nur das Ausweichen, hängt an #185 |
 | K4 Streaming | Hängt an #181 — Matrix streamt nicht |
 | Orderausführung | Siehe #189. Eigene Kategorie, ausdrücklich kein Nebenprodukt |
 
@@ -683,6 +873,7 @@ Wer einen Punkt anfasst, liest das zugehörige Dokument zuerst.
 | [Taskboard-Konzept](Taskboard-Konzept.md) | Dateiformat, Wahrheitsaufteilung Datei/DB, Scanner-Verhalten, Invarianten |
 | [Audit-Konzept](Audit-Konzept.md) | Schema, Provenance-Regeln, Receipts |
 | [Staging-Konzept](Staging-Konzept.md) | Policy-Auflösung, Plan-Freeze, Fortsetzung nach Freigabe — **Bauplan für #191** |
+| [Security-Konzept](Security-Konzept.md) | Vier Schichten (Sandbox-Runner, Regeln vor dem Aufruf, Detektoren, Security-Agent), Quarantäne-Stufen, Skriptprüfung, Netzprofil — **Bauplan für #651–#659** |
 | [Memory-Konzept](Memory-Konzept.md) | Modell, Schlüssel-Semantik, Abrufreihenfolge |
 | [Agentenkommunikation-Konzept](Agentenkommunikation-Konzept.md) | Fünf Phasen, Korrelation, Nachrichtenspeicher |
 | [RocketChat-Nextcloud-Konzept](RocketChat-Nextcloud-Konzept.md) | Rocket.Chat gebaut; Nextcloud, Rückweg und `ChannelRouter` offen. Enthält die Messung gegen die echte Instanz |