Daemon ACP-over-HTTP → Offizieller ACP Streamable HTTP Transport

Ziele: daemon_mode_b_main. Branch: feat/daemon-acp-http-streamable. Autor: arnoo.gao. Datum: 2026-05-24. Status: Design v1 → Implementation. Design-First gemäß Repo-Workflow: Dieses Dokument landet vor/mit dem Implementierungs-PR, sodass der Wire-Contract überprüfbar ist.

0. TL;DR

Der Daemon (qwen serve) spricht derzeit einen maßgeschneiderten REST+SSE-Dialekt mit Web-/SDK-Clients, während er echtes ACP JSON-RPC über stdio mit dem gestarteten qwen --acp-Kindprozess spricht. Dieser Vorschlag fügt einen zweiten nordwärtigen Transport hinzu, der den offiziellen ACP Streamable HTTP Transport (RFD #721) an einem einzigen /acp-Endpunkt implementiert, sodass jeder ACP-native Client (Zed, Goose, zukünftige SDKs) den Daemon direkt über das Standardprotokoll steuern kann – ohne qwen-spezifische REST-Kenntnisse.

Entscheidung: Dual-Transport, additiv. Der neue /acp-Endpunkt wird neben der bestehenden REST-Oberfläche bereitgestellt und verwendet dieselbe HttpAcpBridge + EventBus im Hintergrund. Die REST-API wird nicht entfernt. Begründung in §6.

Entscheidung: Erweiterungs-Namespace = _qwen/… (Single-Underscore-Präfix, die von der ACP-Spezifikation reservierte Form für benutzerdefinierte Methoden) für Daemon-Funktionen, die keine standardmäßige ACP-Methode haben (Modellwechsel, Workspace-Inspektion, Heartbeat, Multi-Client-Berechtigungsrichtlinie, SSE-Backpressure-Tuning). Begründung in §5.

Eine vollständige, lokal ausführbare Referenzimplementierung wird in diesem PR mitgeliefert (packages/cli/src/serve/acp-http/) plus ein Verifikations-Harness (scripts/acp-http-smoke.mjs).

1. Hintergrund – was „ACP über HTTP“ heute bedeutet

Drei Ebenen (verifiziert bei Commit 0c0430939):

┌──────────────┐  bespoke REST + SSE (HTTP/1.1)   ┌────────────┐  ACP JSON-RPC   ┌──────────────┐
│ web / SDK    │ ───────────────────────────────► │  qwen      │  (stdio NDJSON) │ qwen --acp   │
│ client       │ ◄─── GET /session/:id/events ──── │  serve     │ ◄─────────────► │ child (Agent)│
│ (ACP client) │       (text/event-stream)        │  (daemon)  │  ndJsonStream   │              │
└──────────────┘                                   └────────────┘                 └──────────────┘
        northbound: NOT ACP wire                       bridge          southbound: real ACP

1.1 Nordwärts (Client ↔ Daemon) – maßgeschneidert, heute

• Express 5 App in packages/cli/src/serve/server.ts (~30 Routen).
• Diskrete REST-Verben, nicht JSON-RPC:
  • POST /session (erstellen), POST /session/:id/prompt, POST /session/:id/cancel, POST /session/:id/load|resume, POST /session/:id/model, POST /session/:id/permission/:requestId, POST /session/:id/heartbeat, DELETE /session/:id, plus /workspace/*, /capabilities, /health.
• Server→Client-Streaming: GET /session/:id/events → text/event-stream.
  • Frames: id: <n>\nevent: <type>\ndata: <json>\n\n (server.ts:formatSseFrame, ~2626).
  • Pro-Sitzung monoton steigende id + Last-Event-ID-Wiederaufnahme, gestützt durch einen Ringpuffer EventBus (acp-bridge/src/eventBus.ts).
  • Ereignis-types: session_update, client_evicted, slow_client_warning, state_resync_required, stream_error, …
• Auth: Authorization: Bearer <token> (serve/auth.ts), CORS deny + Host-Allowlist.
• Backpressure: pro-Verbindung serialisierte Schreibkette + 15 s Heartbeat-Kommentare.

1.2 Südwärts (Daemon ↔ Kind) – bereits ACP

• acp-bridge/src/spawnChannel.ts startet qwen --acp, umschließt stdin/stdout mit ndJsonStream von @agentclientprotocol/sdk (^0.14.1).
• acp-bridge/src/bridge.ts:729 new ClientSideConnection(() => client, channel.stream) — der Daemon ist der ACP Client, das Kind ist der ACP Agent.
• Erweiterungsmethoden bereits in Verwendung auf dieser Verbindung: unstable_setSessionModel, unstable_resumeSession, unstable_listSessions (acp-integration/acpAgent.ts).

1.3 Warum die Nordwärts-Verbindung migrieren

• Jeder Client (webui, TS SDK, Java SDK, Python SDK, VSCode companion) implementiert das maßgeschneiderte REST-Mapping neu. Ein ACP-Standardendpunkt erlaubt ACP-nativen Editoren den Anschluss ohne qwen-spezifische Klebearbeit.
• Richtet die entfernte Oberfläche des Daemons an dem Protokoll aus, das er bereits intern spricht.

2. Ziel: ACP Streamable HTTP (RFD #721)

Gemergter Entwurf RFD (agentclientprotocol/agent-client-protocol#721, gemergt 2026-04-22). Noch nicht normativ; noch in keinem SDK. Wir implementieren gegen das Wire-Design des RFD.

2.1 Endpunkt & Verben (einzelner /acp)

2.2 Zweistufige langlebige Streams

• Verbindungsbezogener Stream: GET /acp mit Header Acp-Connection-Id, kein Session-Header. Überträgt verbindungsbezogene Antworten (session/new, session/load, authenticate) und Benachrichtigungen.
• Sitzungsbezogener Stream: GET /acp mit Acp-Connection-Id und Acp-Session-Id. Überträgt session/update-Benachrichtigungen, Agent→Client-Anfragen (session/request_permission, fs/read_text_file, …) und Antworten auf Session-POSTs (session/prompt, session/cancel).

2.3 Identität (3 Ebenen)

• Acp-Connection-Id (HTTP-Header) – Transportbindung, wird bei initialize erstellt.
• Acp-Session-Id (HTTP-Header) – erforderlich für sitzungsbezogene GET + Session-POSTs.
• sessionId (JSON-RPC-Parameter) – innerhalb der Methodenparameter (muss mit dem Header übereinstimmen).

2.4 Abweichungen von MCP StreamableHTTP

ACP verwendet langlebige Streams (kein pro-Request-SSE), zwei ID-Header (Verbindung vs. Session), 202 für Nicht-initialize, HTTP/2-Pflicht, WebSocket-Pflicht-Client. Wir übernehmen das Single-Endpoint + POST/GET-SSE + Session-Header-Skelett, passen es aber an das langlebige Zwei-ID-Modell an. Wir verwenden nicht @modelcontextprotocol/sdk’s StreamableHTTPServerTransport (sein pro-Request-Stream-Modell und einzelnes Mcp-Session-Id passen nicht).

2.5 Standardmethoden (aus aktuellem Schema bestätigt)

• Client→Agent-Anfragen: initialize, authenticate, session/new, session/load, session/prompt, session/resume, session/close, session/list, session/set_mode, session/set_config_option, logout.
• Client→Agent-Benachrichtigung: session/cancel.
• Agent→Client-Anfragen: fs/read_text_file, fs/write_text_file, session/request_permission, terminal/create|output|wait_for_exit|kill|release.
• Agent→Client-Benachrichtigung: session/update.

3. Architektur des neuen Transports

Der Daemon muss nordwärts eine ACP-Agent-Oberfläche über HTTP bereitstellen, während er südwärts ein ACP-Client zum Kind-Prozess bleibt. Die /acp-Schicht ist daher ein JSON-RPC-Router, der den HTTP-Transport terminiert und in die bestehende HttpAcpBridge einbindet.

            POST /acp (JSON-RPC requests/responses/notifs)
client  ──────────────────────────────────────────────►  ┌───────────────────────────┐
(editor)                                                  │  AcpHttpTransport         │
        ◄── GET /acp  (verbindungsbezogenes SSE) ───────  │  - Verbindungsregister   │
        ◄── GET /acp  (sitzungsbezogenes SSE) ──────────  │  - JSON-RPC id-Korrelation│
                                                          │  - Methoden-Dispatch      │
                                                          └────────────┬──────────────┘
                                                                       │ verwendet wieder
                                                          ┌────────────▼──────────────┐
                                                          │  HttpAcpBridge + EventBus  │  (unverändert)
                                                          └────────────┬──────────────┘
                                                                       │ ACP stdio (unverändert)
                                                                 qwen --acp child

3.1 Neues Modul-Layout (packages/cli/src/serve/acp-http/)

Keine Änderung an bridge.ts / eventBus.ts (nur hinzugefügte Konsumenten).

3.2 Verbindungs- und Sitzungslebenszyklus

1. POST /acp {initialize} → erstellt connectionId, legt AcpConnection an, antwortet 200 mit {protocolVersion, agentCapabilities, _meta:{qwen:{…}}} + Acp-Connection-Id-Header.
2. Client öffnet GET /acp (verbindungsbezogen) mit Acp-Connection-Id.
3. POST /acp {session/new} → 202; Daemon ruft bridge.createSession(...) auf; sendet die JSON-RPC-Antwort (mit sessionId) über den Verbindungs-Stream.
4. Client öffnet GET /acp (sitzungsbezogen) mit Acp-Connection-Id+Acp-Session-Id; Daemon bridge.subscribeEvents(sessionId) und leitet übersetzte Frames weiter.
5. POST /acp {session/prompt} → 202; bridge.sendPrompt(...); session/update-Benachrichtigungen werden live auf dem Sitzungs-Stream gesendet; die endgültige prompt-Antwort ({id, result:{stopReason}}) wird auf dem Sitzungs-Stream gesendet, sobald sie feststeht.
6. Agent→Client-Anfrage (z. B. session/request_permission) wird als JSON-RPC-Anfrage auf dem Sitzungs-Stream mit einer vom Daemon vergebenen Id gesendet; der Client antwortet per POST /acp {id, result}; dispatch löst sie über die Berechtigungs-API der Bridge auf.
7. DELETE /acp (oder Verbindungs-Stream-Schließen + TTL) baut Sitzungen/Abonnements ab.

4. Übersetzungstabelle (Brücke ⇄ ACP/HTTP)

4.1 Eingehend (Client POST → Brücke)

| ACP-Methode | Brückenaufruf | Antwort weitergeleitet an | | ------------------------------------------- | ------------------------------------------------------- | --------------------------------------- | ----------------- | | initialize | (keine; Fähigkeiten aus capabilities.ts) | inline 200 | | authenticate | existierender Auth-Provider (serve/auth/*) | Verbindungsstream | | session/new | bridge.createSession | Verbindungsstream | | session/load / session/resume | bridge.restoreSession('load' | 'resume') | Verbindungsstream | | session/prompt | bridge.sendPrompt | Sitzungsstream (zurückgestellt bis Abschluss) | | session/cancel (Benachrichtigung) | bridge.cancel | — | | session/list | bridge.listSessions (unstable_listSessions) | Verbindungsstream | | session/set_mode | Approval-Mode-Routenlogik | Sitzungsstream | | JSON-RPC Antwort (auf Agent→Client-Anfrage) | ausstehende auflösen (§4.3) | — | | _qwen/session/set_model | bridge.setSessionModel (unstable_setSessionModel) | Sitzungsstream | | _qwen/workspace/list etc. | Arbeitsbereich-Instrospektionsrouten | Verbindungsstream | | _qwen/session/heartbeat | bridge.heartbeat | Verbindungsstream |

4.2 Ausgehend (BridgeEvent → JSON-RPC auf Sitzungsstream)

4.3 Ausstehende Agent→Client-Anfragen

AcpConnection verwaltet Map<jsonRpcId, {sessionId, kind, bridgeRequestId, resolve}>. Wenn der Client ein JSON-RPC-Antwortobjekt per POST sendet, gleicht dispatch die id ab und ruft dann den Brückenauflösungspfad auf (z. B. internes Äquivalent von POST /session/:id/permission/:requestId).

v1-Status: nur der session/request_permission-Agent→Client-Rundlauf ist implementiert. fs/*- und terminal/*-Agent→Client-Weiterleitung sind zurückgestellt (§7) – der Daemon gibt noch keine fs/terminal-Client-Fähigkeitsaushandlung auf /acp bekannt, daher sollten ACP-Clients in v1 keine Dateisystem-/Terminal-Semantik über diesen Transport erwarten. Der angestrebte Endzustand (Weiterleitung von fs/* an den Client; Rückfall auf das Arbeitsbereichs-Dateisystem des Daemons, wenn der Client nicht über die fs-Fähigkeit verfügt) ist das in §7 beschriebene Follow-up.

5. Erweiterungsstrategie (Anforderung #2)

ACP reserviert alle Methoden, die mit _ beginnen, für benutzerdefinierte Erweiterungen und stellt _meta auf jedem Typ bereit. Der südliche Teil der Codebasis verwendet bereits unstable_*-Methodennamen.

Nordseite-Wahl: anbieternamensräumliche _qwen/<Bereich>/<Verb>-Methodennamen (konformer _-Präfix). Fähigkeiten werden unter agentCapabilities._meta.qwen bei initialize angekündigt, sodass Clients die Funktionen vor der Nutzung erkennen können.

6. Dual-Transport vs. Ersetzung (Anforderung #4)

Entscheidung: Dual-Transport (additiv).

• Der offizielle Transport ist ein Entwurfs-RFD, nicht normativ und in keinem SDK vorhanden – eine harte Ersetzung würde uns an ein nicht ratifiziertes Design koppeln und gleichzeitig WebUI + 3 SDKs + VSCode Companion brechen.
• Die REST-Oberfläche enthält Funktionen, die noch keine saubere ACP-Abbildung haben (Workspace-Introspection, Multi-Client-Berechtigungsvermittlung, Ringbuffer-Resume, Capability-Registry). Diese werden auf /acp zu _qwen/*-Erweiterungen degradiert, aber die REST-Oberfläche bleibt maßgeblich, bis der RFD ratifiziert ist.
• Beide Transporte teilen sich eine einzige HttpAcpBridge- + EventBus-Instanz, sodass es keine Zustandsverdopplung gibt – /acp und /session/* können sogar gleichzeitig dieselbe Live-Sitzung steuern (Multi-Client wird von der Bridge bereits unterstützt).
• Toggle (v1, ausgeliefert): standardmäßig aktiviert; QWEN_SERVE_ACP_HTTP=0 deaktiviert den Mount. Ein --no-acp-http-CLI-Flag und ein acp_http-Tag in /capabilities zur Client-Feature-Erkennung sind auf einen Folge-PR verschoben (nicht in v1) – bis dahin erkennen Clients den Transport durch Abfragen von POST /acp {initialize}.

Migrationspfad: Sobald der RFD ratifiziert ist und SDKs ausgeliefert werden, können REST-Routen als dünner Kompatibilitäts-Shim über /acp umformuliert werden (separater, späterer PR).

7. Umfang des Implementierungs-PRs

Im Umfang (lauffähig + lokal verifiziert):

• POST /acp-Dispatch für initialize, session/new, session/prompt, session/cancel, session/load, JSON-RPC-Antwortverarbeitung.
• Verbindungsbezogene + sitzungsbezogene GET /acp-SSE-Streams mit JSON-RPC-Framing.
• session/update-Streaming + finale Prompt-Antwort-Korrelation.
• session/request_permission-Agent→Client-Rundlauf.
• _qwen/session/set_model-Erweiterung als ausgearbeitetes Beispiel für #2.
• Wiederverwendung von Bearer-Auth + Host-Allowlist (gleiche Middleware wie REST).
• Unit-Tests (acp-http/*.test.ts) + ein Black-Box-Smoke-Skript, das einen echten Daemon steuert.

Verschoben (dokumentiert, jetzt nicht gebaut):

• WebSocket-Upgrade-Pfad (RFD-erforderliche Client-Fähigkeit; SSE reicht für lokale Verifizierung).
• HTTP/2-Multiplexing (wir verwenden HTTP/1.1; POST und langlebige GET verwenden separate Sockets, was für CLI/Node-Clients und Browser mit ≤6 Verbindungen funktioniert). Dokumentierte Abweichung.
• Vollständige fs/*- + terminal/*-Agent→Client-Weiterleitung (der Berechtigungspfad beweist den Mechanismus; der Rest ist mechanische Nacharbeit).
• SSE-Resumability-Härtung in Parität mit dem Ringpuffer (Phase 4 im RFD).

8. Lokaler Verifizierungsplan

1. npm run build (oder Workspace-Build von cli + acp-bridge).
2. Daemon starten: qwen serve --listen 127.0.0.1:0 --token <t> (oder Token aus Umgebungsvariable).
3. node scripts/acp-http-smoke.mjs ausführen:
   • POST /acp {initialize} → 200 + Acp-Connection-Id erwarten.
   • Verbindungs-SSE öffnen; POST {session/new} → Antwort im Stream erwarten.
   • Sitzungs-SSE öffnen; POST {session/prompt:"say hi"} → mindestens ein session/update gefolgt von einem finalen {result:{stopReason}} erwarten.
   • Ein Tool auslösen, das eine Berechtigung benötigt → session/request_permission-Anfrage erwarten, eine Genehmigungsantwort POSTen → Prompt-Vervollständigung erwarten.
   • POST {_qwen/session/set_model} → Modellwechsel + session/update erwarten.
4. Vitest: acp-http/*.test.ts grün.

9. Risiken

10. Implementierungs- & Verifizierungsprotokoll (v1)

Implementiert in packages/cli/src/serve/acp-http/ (json-rpc.ts, sse-stream.ts, connection-registry.ts, dispatch.ts, index.ts), eingebunden von server.ts über mountAcpHttp(app, bridge, { boundWorkspace }).

Automatisiert (packages/cli/src/serve/acp-http/*.test.ts)

transport.test.ts startet einen echten Express-Server + den echten mountAcpHttp über eine steuerbare Fake-Bridge und treibt ihn mit fetch + manuellem SSE-Parsing an. 15 Tests grün, abdeckend: initialize 200 + Acp-Connection-Id; unbekannte Verbindung 400; session/new-Antwort im Verbindungsstream; Prompt → session/update-Stream + finales Ergebnis korreliert; session/request_permission-Agent→Client→Agent-Rundlauf; _qwen/session/set_model; Methode nicht gefunden; DELETE-Abbau.

Live-Daemon (echtes Modell)

Gestartet: qwen serve --port 8767 --token … --workspace … (Bundle-Einstieg, sodass der gestartete qwen --acp-Kindprozess in sich abgeschlossen ist) und scripts/acp-http-smoke.mjs ausgeführt:

✓ initialize: connectionId=… protocolVersion=1
✓ session/new: sessionId=…
→ prompt: "Reply with the single word: pong"
pong
✓ prompt complete: 10 session/update frames, stopReason=end_turn
✓ DELETE /acp — connection closed
ALL CHECKS PASSED ✅

Der Fehlerpfad wurde auch live bestätigt: Als der Child-Prozess nicht starten konnte, erschien das Bridge-Timeout beim Client als JSON-RPC-Fehlerframe auf dem Verbindungsstream ({"id":2,"error":{"code":-32603,…}}), was die ID-Korrelation und die 202/SSE-Aufteilung unter Fehlerbedingungen belegte.

Review-Einklappung — Bridge-vergebene clientId (in Live-Verifikation gefunden)

Der erste Live-Lauf schlug bei session/prompt mit “client id … ist nicht für die Sitzung registriert” fehl. Ursache: spawnOrAttach/loadSession ignorieren eine vom Aufrufer bereitgestellte clientId, die die Bridge nie vergeben hat, und vergeben eine frische (zurückgegeben in BridgeSession.clientId); der Dispatcher wiederholte die eigene (nicht registrierte) id des Verbindung auf sendPrompt. Behebung: Die von der Bridge vergebene id auf dem SessionBinding persistieren und bei jedem sitzungsbezogenen Aufruf (sessionCtx) wiederholen. Erneute Verifikation oben grün.

11. Review-Runde 2 — Einklappungen

Zwei unabhängige Reviews (Korrektheit/Nebenläufigkeit + Protokollkonformität/Sicherheit) plus eine Selbstlektüre. Alle Korrekturen durch die erweiterte Vitest-Suite (18 Tests) + einen frischen Live-Smoke-Run verifiziert (21 session/update-Frames → stopReason=end_turn).

Akzeptiert / dokumentiert (nicht behoben in v1)

• Prompt-Resultat vs. nachlaufendes session/update-Ordering (P2): handlePrompt erwartet sendPrompt und schreibt dann den Result-Frame, während Updates gleichzeitig streamen. In der Praxis veröffentlicht die Bridge alle session/updates auf den Bus, bevor sendPrompt aufgelöst wird, und beide teilen sich eine geordnete SSE-Schreibkette, daher landet das Resultat zuletzt (bestätigt: 21 Updates, dann Resultat). Eine strikte Barriere ist eine mögliche spätere Härtung, falls sich ein Client-Reducer als empfindlich erweist.
• Browser EventSource kann kein Authorization setzen — /acp GET-Streams erfordern den Bearer-Header, daher benötigen Browser den deferred WebSocket-Pfad (§7); CLI/Node-Clients sind nicht betroffen.
• Die eigentliche Vertrauensgrenze des Daemons bleibt der Bearer-Token + Single-Workspace-Bind (wie bei der REST-Oberfläche); die Besitzprüfung von R3 ist Defense-in-Depth + Vertragskorrektheit, keine Mandantengrenze.

12. Review-Runde 3 — PR-Bot-Einarbeitungen (#4472)

Zwei automatisierte PR-Reviewer plus der Zusammenfassungs-Bot. Alle Korrekturen durch die Suite (jetzt 22 Tests) + einen frischen Live-Durchlauf (16 session/update → end_turn) verifiziert.

Noch zurückgestellt (dokumentiert): Pro-Verbindungs-Geheimnis für DELETE/Verbindungsbesitz (Token bleibt die Grenze); WebSocket + HTTP/2 (§7); strikte Prompt-Ergebnis- vs. nachlaufende-Update-Barriere (§11).

13. Review-Runde 4 — PR-Fold-Ins (rebased auf #4469)

Branch rebased auf daemon_mode_b_main (#4353 + #4469) — sauber, keine Konflikte. Zwei PR-Reviewer (GPT-5 + qwen3.7-max). Suite jetzt 25 Tests; live erneut verifiziert (125 session/update → end_turn).

14. Review-Durchlauf 5 — PR-Fold-Ins

Ein weiterer Prüferdurchlauf (qwen3.7-max). Suite 26 Tests, live erneut verifiziert.

15. Review-Durchlauf 6 — PR-Fold-Ins

Ein weiterer Prüferdurchlauf (qwen3.7-max). Suite 28 Tests, live erneut verifiziert.

16. Review-Runde 7 — PR-Einarbeitungen

Ein weiterer Prüfdurchlauf (qwen3.7-max). Suite mit 30 Tests, live erneut verifiziert.

17. REST-Äquivalenzangleich + Audit-Umsetzung des Erweiterungsschemas (Runde 8)

Ziel: /acp als äquivalenten Ersatz für REST+SSE etablieren.

Diese Charge basiert auf den Audit-Ergebnissen und restrukturiert das Erweiterungsschema, und ergänzt die von Bridge bereits exponierten Fähigkeiten; Fähigkeiten, die Bridge noch nicht besitzt (Datei-I/O, Gerätestreams, Agents/Memory CRUD) werden gemäß den Architektur-Korrektheitsanforderungen zuerst durch acp-bridge ergänzt (siehe §17.3).

17.1 Audit des Erweiterungsschemas → Umsetzung (Ersetzt das alte Schema aus §5)

Basierend auf dem tatsächlich im Repository implementierten SDK @agentclientprotocol/sdk@0.14.1 (nicht nur die Website):

• session/set_config_option ist eine erstklassige (nicht unstable_) Methode, Request {sessionId, configId, value}, category enthält model/mode/thought_level; während set_model weiterhin über unstable_setSessionModel läuft.
• Die Spezifikation behält das _-Präfix für Erweiterungen vor, Beispiele sind domain-basiert wie _zed.dev/…; Herstellerdaten werden in _meta nach Domain-Schlüssel abgelegt.

Umsetzung:

• Namespace _qwen/ → Reverse-Domain _qwen/; _meta einheitlich _meta:{ "qwen": … } (enthält initialize-Fähigkeitsanzeige und requestId von session/request_permission).
• Modell + Genehmigungsmodus → Standard session/set_config_option (configId:"model"|"mode"), routing zu vorhandenen bridge.setSessionModel/setSessionApprovalMode; session/new-Ergebnis wirbt configOptions an (entnommen aus dem Subprozess-Sitzungsstatus getSessionContextStatus().state.configOptions, bereits in ACP-Form). Löschen des herstellerspezifischen _qwen/session/set_model.
• REST (http+sse) erfordert keine synchronen Änderungen: Beide Transports teilen sich dieselbe Bridge, der Zustand ist von Natur aus konsistent.

17.2 Neu in dieser Charge hinzugefügte /acp-Methoden (bridge bereits unterstützt, 1:1-Entsprechung zu REST)

(Bereits vorhanden: session/new·load·resume·close·list·prompt·cancel, heartbeat, permission, events sind abgeglichen.)

17.3 Noch bestehende Lücken → acp-bridge muss zuerst ergänzt werden (Architekturkorrektheit)

RESTs Datei-I/O (/file /glob /list /stat /file/write /file/edit), Geräte-Flow-Anmeldung (/workspace/auth/*), Agents CRUD (/workspace/agents), Memory CRUD (/workspace/memory) befinden sich derzeit nicht auf HttpAcpBridge – die REST-Routen rufen direkt die Routen-Dienste auf (WorkspaceFileSystemFactory, DeviceFlowRegistry, SubagentManager, writeWorkspaceContextFile), und umgehen dabei die Bridge.

Entscheidung (Review-/Owner-Meinung berücksichtigt): Der /acp-Transport soll diese Routen-Dienste nicht direkt ansprechen (das würde die Architekturabweichung von REST kopieren und die Transport-Kopplung verdoppeln). Richtig ist es, zuerst in @qwen-code/acp-bridge’s HttpAcpBridge diese Fähigkeiten zu ergänzen (z.B. readWorkspaceFile/writeWorkspaceFile/globWorkspace, startDeviceFlow/pollDeviceFlow, listAgents/upsertAgent/deleteAgent, readMemory/writeMemory), sodass sowohl REST als auch /acp über die Bridge gehen. Dann können bei /acp noch _qwen/fs/*, _qwen/auth/*, _qwen/workspace/agent*, _qwen/workspace/memory* hinzugefügt werden (Datei-Lesen ist ein legitimer Herstellererweiterung, da es keine Standard-ACP-Client→Agent-Methode gibt).

Vollständige Äquivalenz = diese Charge (bereits in der Bridge vorhandene Fähigkeiten) + spätere Charge nach Ergänzung der Lücken in acp-bridge.

18. Review Round 9 — PR-Fold-ins

Rebased auf den neuesten daemon_mode_b_main (#4473/#4483/#4484/#4500), keine Konflikte. Suite 33 Tests, live erneut verifiziert.

19. Roadmap / Nachfolge-PRs (zur Erinnerung)

Dieser PR (#4472) = ACP Streamable HTTP Transport + alle bridge-gestützten Fähigkeiten abgeglichen + offizielle Erweiterungslösung. Jetzt auf ready gesetzt. Für die vollständige Äquivalenz von /acp mit REST+SSE sind noch nötig:

1. Follow-up PR 1 — acp-bridge Fähigkeiten ergänzen (Vorbedingung / bridge-first): HttpAcpBridge erhält neue Methoden für Datei-I/O, Geräte-Flow, Agents CRUD, Memory CRUD; REST-Routen werden über die Bridge geführt (Beseitigung der direkten Verbindung zu den Routen-Diensten).
2. Follow-up PR 2 — Rest-Abgleich von /acp (abhängig von PR 1): _qwen/fs/*, _qwen/auth/*, _qwen/workspace/agent*, _qwen/workspace/memory* → vollständige Äquivalenz zu REST. Verfolgung: #3803 (open decisions), #4175 (Mode B roadmap) wurden beide kommentiert. Die deferred-Elemente sind in der PR-Beschreibung unter „Known deferred“ aufgeführt.

20. Extension-Namespace-Umbenennung + SDK-Transport-Analyse (Runde 11)

• Namespace _qwen.ai/ → _qwen/: Die einzige harte Regel des ACP ist der führende Unterstrich _; das Segment _zed.dev/ ist eine Konvention à la Beispiel, kein Muss. Da qwen unverwechselbar ist, verwenden wir die kürzere, reine Form. Der _meta-Schlüssel lautet ebenfalls "qwen". (Überblick über reale Agents: Zed/gemini-cli verwenden meist _meta bei Standardmethoden + ACPs eigene unstable_*-Methoden; reine benutzerdefinierte _-Methoden sind selten – unsere _qwen/*-Operationen sind wirklich neuartige Workspace/Session-Vorgänge ohne Standardäquivalent, daher ist eine _-Methode das richtige Mittel.)
• Warum handgefertigter Transport (nicht SDK-basiert): Das TS-SDK liefert nur ndJsonStream (Stdio); RFD #721 HTTP ist SDK Phase 3 (nicht implementiert). Die SDK-Connection ist ein Einzel-Duplex-Stream; unser Transport ist Multi-Stream (POSTs + Verbindungs-SSE + Pro-Session-SSE) und benötigt ausgehende Demultiplexierung nach sessionId – was unser Dispatcher zur Routing-Zeit bereits kennt. Eine vollständige SDK-Neuschreibung bekämpft dieses Modell und würde die Hauptlast (Brückenübersetzung, SSE-Lebenszyklus, Eigentumsverhältnisse, EventBus→JSON-RPC) nicht entfernen. Pragmatische Verbesserung (mögliches Follow-up): Übernahme der Zod-Schema-Validatoren und -Typen des SDK für die Parametervalidierung bei gleichzeitiger Beibehaltung des handgefertigten Transports. SDK-Clients, die extMethod('_qwen/…') verwenden, sind mit unseren Handlern kompatibel (identisches Drahtformat).