The gateway connection resolver short-circuited to "请先登录 svc.plus"
whenever the account was signed out, before checking whether a manual
bridge was configured or whether capability discovery was still running.
A saved manual bridge could therefore never be used while signed out.
- Only emit the signed-out prompt when neither an account session nor a
manual bridge is configured (`!accountSignedIn && !bridgeConfigured`).
- Gate the sync-blocked branch on `accountSignedIn` so it no longer
hijacks the manual-bridge discovery path.
Adds tests covering manual-bridge discovery and discovery-failure while
signed out. See docs/cases/manual-bridge-login-state/README.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
让现有 release/v1.1.5 分支自身包含门禁 workflow（pull_request_target 用 base 分支版本）。
详见 iac_modules/docs/tldr-github-branch-model.md
Co-authored-by: Haitao Pan <haitao.pan@xworkmate.ai>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Every gateway turn's prompt prefix injected three near-duplicate absolute paths:
currentTaskWorkspace + localWorkspace + remoteWorkspaceHint. localWorkspace is the
App's LOCAL thread dir (~/.xworkmate/threads/...) which the gateway agent cannot
access, and remoteWorkspaceHint duplicates currentTaskWorkspace. The conflicting
paths leave the agent unsure where to work and can block conversation continuation.
For gateway turns the prompt now carries only currentTaskWorkspace (the plugin owns
the artifact scope); localWorkspace is kept only for non-gateway (local agent runs
there); remoteWorkspaceHint is dropped when equal to currentTaskWorkspace. sessionKey
is kept (short, not a path). UI is unaffected (chat bubble shows the raw user message;
the prompt-debug parser only special-cases Execution context / Preferred skills /
Attached files). Tests updated; assistant_execution_target_test green (74).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live-verified one gateway turn across all four layers against 8787 (bridge 188ca4b,
gateway 6 plugins): session.start → real plugin session.prepare mapping → chat.send
→ xworkmate.tasks.get returns status=completed, constraintSatisfied=True, and
summary.md (438B) actually landed in tasks/<sani(sessionKey)>/<runId>/ and is
retrievable via xworkmate.artifacts.export. All xworkmate.* gateway methods ✓.
T12 metrics all 0 (no resilience fallback needed). Supersedes the earlier
no_native_task_record observation, which was a derived symptom of the plugin not
being loaded (the S0 symlink root cause).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Flip stale §5 checkboxes (T1/T2/T3/T4/T6) to done with code anchors —
they had lagged behind §2/§6 which already marked them merged.
- Add §9: authoritative full-chain status across all 4 repos' main
(app/bridge/openclaw/playbooks HEADs), the completed stability closure,
and the precise remaining backlog (S1 redo, S2 status ambiguity, T8b
cross-restart persistence) with acceptance criteria + anti-regression
recommendations.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root cause of the plugin not loading was a symlink
~/.openclaw/extensions/openclaw-multi-session-plugins -> /tmp/... (ephemeral).
Replaced with a real dir, registered via `openclaw plugins install --force`,
restarted the gateway: now boots with "6 plugins ... openclaw-multi-session-plugins"
from the stable path, provenance warning gone, and xworkmate.session.prepare returns
the real plugin mapping (no bridge fallback). Survives restart.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rewrites the timeline (§1) and topology (§2) as the correct FOUR-layer chain
App → bridge → openclaw-multi-session-plugins → OpenClaw gateway, and documents the
plugin's multi-session/multi-thread role: session mapping (appThreadKey⇄openclawSessionKey),
per-(session,run) artifactScope = tasks/<sanitize(sessionKey)>/<runId>, the strict
sessionKey/runId/artifactScope triplet validation, and the expectedArtifactDirs
workspace-root fallback scan.
Live-verified against 127.0.0.1:8787 (plugin loaded, commit 2333c3e):
- session.prepare returns a real mapping; chat.send returns runId; xworkmate.tasks.get
is handled by the plugin but returns no_native_task_record with an empty task scope
(chain reaches the plugin layer; the agent run produced no queryable task / no file —
a layer-4 execution/landing issue).
Adds §7 stability improvements grounded in this live run:
- S0 install the plugin from a stable path (not /private/tmp) — the primary reliability fix.
- S1 expectedArtifactDirs was [] → the plugin's workspace-root fallback is inert; bridge
should always pass default dirs (reports/, artifacts/).
- S2 no_native_task_record status ambiguity (running vs completed-without-artifact).
- S3 sessionKey/runId/artifactScope triplet consistency (don't pre-prefix agent:main:).
- S4 runtime observability across all four layers.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live verification disproved the earlier "xworkmate.* protocol namespace drift"
conclusion. The xworkmate.* gateway methods are REAL — registered at runtime by
the openclaw-multi-session-plugins plugin (index.ts registerGatewayMethod). The
actual failure: the running OpenClaw gateway did not load that plugin because its
source path was the ephemeral /private/tmp/openclaw-multi-session-plugins/... and
the gateway booted (09:21) ~9h before those files were populated (18:40), so it
started with 5 plugins (no multi-session) and every xworkmate.* returned
"unknown method". Restarting the gateway loads 6 plugins and the methods work
(errors shift to plugin-level param validation).
Changes:
- Add a corrected conclusion banner up top distinguishing the primary root cause
(plugin load) from the T1-T9 robustness hardening.
- Replace the wrong "protocol drift / native alignment" section with the
plugin-not-loaded root cause + evidence + the abandoned-branch note
(fix/gateway-task-protocol-alignment must NOT be merged).
- Fix failure-row 10, T13 (runtime-state check now covers gateway plugin load),
and the landing-order to put the plugin fix as step 0.
- Cross-reference openclaw-gateway-e2e-regression/ROOT_CAUSE_ANALYSIS.md (which
was already correct about the 4-layer chain).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds the 2026-06-26 decisive finding: the bridge forwards `xworkmate.*` method
names the OpenClaw 2026.6.2 gateway does not implement (it uses native
tasks.get/list/cancel and artifacts.list/get/download). Documents the corrected
end-to-end turn timeline with the three break points (tasks.get unknown method;
{taskId}-only param shape + taskId!=runId; artifacts.* drift blocking .md delivery),
the evidence (gateway source + schema + CHANGELOG), the implemented task-lifecycle
fix, and the precisely-specified remaining work (artifact-method alignment + test
fixture migration). Corrects the earlier (wrong) "push/pull mismatch" conclusion.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Records the durable per-session run-registry implementation (bridge branch
fix/gateway-durable-run-registry): T7 gateway-unconfirmed fallback, T8 terminal
result cache, T9 DeadlineAt interrupt — with the trade-offs (no gatewayruntime
pending-map rewrite; per-session in-memory store not yet cross-restart durable;
T9 only force-terminates when the gateway is unconfirmed) and the test names that
cover each.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Symptom: a gateway turn shows "任务运行中..." forever and 停止 has no effect,
even though the OpenClaw gateway has already finished (ACP_HTTP_CONNECTION_CLOSED).
- T3: add a hard deadline to the running-handle poll branch so the client no
longer polls forever when tasks.get keeps returning "running". Budget is
derived from taskLoadClass (10/30/60min, aligned with the bridge) + grace;
on timeout the turn lands in a recoverable `interrupted` state
(OPENCLAW_RUN_POLL_TIMEOUT) prompting the user to resend.
- T4: make 停止 locally authoritative — capture the association, mark the turn
aborted immediately (clears pending, exits the poll loop), then fire
tasks.cancel best-effort so a hung/failed cancel RPC can't block termination.
- T6: applyGatewayChatFailureInternal now authoritatively clears the pending
flag (both raw + normalized key). Previously runOpenClawGatewayQueuedTurnInternal's
finally never cleared it, leaving "error shown but still running".
Full cross-repo analysis + remaining TODO in docs/cases/06.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reposition the remote provider contract check as a skippable test-stage
quality gate (needs: build, continue-on-error) so it can never block
build or release. release uses always() to wait without being gated.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
