feat(continuation): context-pressure-aware continuation (continue_work / continue_delegate / request_compaction)#85651
Conversation
Dependency Changes DetectedThis PR changes dependency-related files. Maintainers should confirm these changes are intentional. Changed files:
Maintainer follow-up:
|
|
No dependency changes detected. Learn more about Socket for GitHub. 👍 No dependency changes detected in pull request |
|
Codex review: needs real behavior proof before merge. Reviewed June 13, 2026, 1:34 PM ET / 17:34 UTC. Summary Reproducibility: Source-reproducible: read-only inspection of the PR head shows the delivered-marker failure path, legacy provider route, and trusted cross-session return path; no live run was attempted under the read-only constraint. Review metrics: 2 noteworthy metrics.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Land only after conflicts are resolved, current-head real behavior proof is supplied, delivered-marker failures are handled, canonical OpenAI/Codex routing is preserved, and the cross-session delegate trust model is explicitly approved or hardened. Do we have a high-confidence way to reproduce the issue? Source-reproducible: read-only inspection of the PR head shows the delivered-marker failure path, legacy provider route, and trusted cross-session return path; no live run was attempted under the read-only constraint. Is this the best way to solve the issue? No: the continuation concept is plausible, but the current implementation is not the best merge shape until the durable queue invariant, canonical provider route, and cross-session trust model are repaired or explicitly approved. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 22069bcc56b7. Label changesLabel justifications:
Evidence reviewedSecurity concerns:
Acceptance criteria:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
ClawSweeper PR egg: 🎁 locked until real behavior proof passes. Details
|
6c7ab1f to
6a23864
Compare
Adds explicit RFC v10 language for the chain-budget reset semantics that #987 ships, per figs's "language must be explicit" ask + Frond's RFC-adoption-call to fold edits atomic with the code. Four load-bearing language updates: 1. §2.3 Safety model (line ~186): clarify "configured continuation budget" = current self-continuation chain budget (maxChainLength + costCapTokens), not session-lifetime. Notes fresh non-continuation turn-entry resets per §3.3. 2. §3.3 Chain-state tracking (lines ~507-525): adds continuationChainId to the four-field bullet list + new "Chain-state lifecycle" paragraph explaining the per-turn reset on !isContinuationWake, pre-loadContinuationChainState ordering, fresh-turn-elects-from-0 semantic, work-wake/delegate-return preservation. Names the session-rotation reset path distinct from per-turn chain-reset. 3. §5.1 Operational notes (lines ~918-919): maxChainLength + costCapTokens descriptions expanded to name "unattended self-continuation chain depth" leash semantic + reset trigger + cross-reference §3.3. 4. §5.1 New "Chain budget lifecycle" subsection: explicit sawtooth behavior description for /status display + four-field reset-unit + chain-id rotation semantic + methodological-note for source-readers naming the ?? 0 + chainId-mint-ternary as passive-default-not-active-reset (the trap that four cohort-princes hit + retracted today before locking the byte). Together with the code in c201f7c, this ensures the RFC language matches the shipped semantic atomically — no doc-drift on the chain-reset surface. Cohort-byte-converged through 6+ sources today. Cohort-cross-reference: methodological-note specifically names the loadContinuationChainState ?? 0 + chainId-mint-ternary source-reading traps that cohort byte-walked + 4 princes retracted from today (banked at ~/.openclaw/workspace/memory/2026-06-10.md, lesson #9).
…-superseded fix(continuation): maxPendingWork cap + drain-superseded guard (#986)
fix(continuation): reset chain budget on fresh non-wake turn-entry (#987)
…arly-return (#988 P2-2) The spawn-init / turn-1 lane (scheduleSpawnInitContinueWorkWake) emitted the multi-election cap-notice AFTER the `scheduledCount === 0` early-return, so a session already at the pending/chain/cost cap before a multi-continue_work response (scheduledCount:0, cappedCount>0) stayed silent — even though each tool call already reported status:"scheduled". The main-reply (agent-runner) and followup (followup-runner) lanes both surface this partial cap-drop. Move the cap-notice emit above the early-return so the never-silent symmetry holds across all three election lanes for the scheduledCount:0 && cappedCount>0 case. Multi-election only, preserving single-work behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ccumulated schema drift (#988 P2-3) #988 added the public config key agents.defaults.continuation.maxPendingWork to the zod schema but did not regenerate docs/.generated/config-baseline.sha256, so `pnpm config:docs:check` failed on any checkout with deps. The baseline had also not been regenerated since 2026-06-08 (fc6400e), so several intervening schema-surface changes (qqbot command toggle, tui host-footer gate, imessage, codex, continuation maxPendingWork) had accumulated as drift across the core, channel, and plugin baselines. Regenerate the baseline via `config:docs:gen` (deterministic, env-normalized) so the hash reflects the current schema surface and `config:docs:check` passes. No help-text/describe added for maxPendingWork: its continuation cap siblings (maxChainLength, costCapTokens, maxDelegatesPerTurn) carry no .describe()/help/ label and are not in the schema.help.quality TARGET_KEYS gate, so maxPendingWork already matches the sibling shape. Adding asymmetric help to only this key would diverge from the family. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…989-P2-1) #989 reset the chain budget at turn-entry gated on `!isContinuationWake`, so a genuine external turn resets while a continuation-wake preserves the count. But subagent-announce minted `continuationTrigger: "delegate-return"` for EVERY inter-session subagent completion, not just actual `[continuation:chain-hop:N]` continuation-chain hops. So the reset gate treated every ordinary subagent return as an in-chain wake and skipped the reset — a long-lived session with a stale at-cap `continuationChainCount` then rejected any continuation elected from a normal subagent return (the #987 n/200 doom-lock, still open via the ordinary-subagent-return path). Distinguish the two at the source: an in-chain chain-hop return keeps `delegate-return` (mid-chain wake, preserves the leash); an ordinary subagent completion now carries the new `subagent-return` trigger, which get-reply-run classifies as a non-wake (`isContinuationWake=false`) so the reset gate rewinds the chain budget like any other external turn-entry. `subagent-return` stays heartbeat-equivalent and `continuation-chain` fire-reason in run-provenance, so only the reset-gate behavior changes. The runaway leash for genuine continue_delegate chains is preserved. Tests: get-reply-run maps subagent-return -> not a continuation wake; subagent-announce mints subagent-return for ordinary completions and delegate-return for chain hops; run-provenance preserves provenance; the #987 reset-gate tests stay green plus a new #989 at-cap doom-lock reset scenario. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
fix(continuation): #988 fast-follow — spawn-init cap-notice (P2-2) + maxPendingWork config-docs baseline (P2-3)
…P2-1) Fold-side write-guard (Pillar-3). The running-work recovery path consumes flows whose PRE-claim durable status is `running` (recovered active turns), so the batch handed to partitionSupersededWork could include live, in-flight turns. partitionSupersededWork folded any stale non-newest member into the superseded bucket without a status check, so a recovered `running` turn that is actively driving (observing requests-in-flight) could be marked terminal out from under itself. Two-part guard (only-coalesce-queued / carry-status / never-supersede-running): 1. Carry the PRE-claim flow status onto PendingContinuationWork via workToRuntime; consumePendingWork captures it before the claim flips every consumed flow to `running`. 2. partitionSupersededWork always routes `status === "running"` members to drive, never superseded, regardless of staleness or election order. The existing #986 queued-backlog coalesce (newest-elected drives, close-burst drives, tie-break by hop) is unchanged. Tests extend the existing partitionSupersededWork unit suite (running-not- superseded, queued-still-folds, mixed batch) plus an end-to-end dispatch test proving the carried status survives consumePendingWork. RED-verified the new cases fail without the guard. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…uard fix(continuation): never-supersede a RUNNING continuation work (#988-P2-1, Pillar-3 fold-side write-guard)
…ested harden (#990 Pillar-0) The PRE-drive busy-skip re-arm (requests-in-flight/draining) requeued at a flat BUSY_RETRY_MS=1s with no backoff, spinning a chronically-busy seat at ~1Hz forever (the storm). Replace with exponential backoff on a NEW busySkipCount counter that is DISTINCT from retryCount and never feeds the transient-error fail-bound — rate-cap- forever: the flow keeps deferring at a decaying rate (1s,2s,4s,...,capped at maxDelayMs) and delivers the instant the seat quiets, never dropped (#952 never-penalize survives). - computeBusySkipBackoffMs(busySkipCount, ceilingMs) = min(ceilingMs, BUSY_RETRY_MS*2^n). - busySkipCount persisted in PendingWorkState (same shape as retryCount), reset to 0 on drive (markPendingWorkTurnGranted) so a deferred-then-granted flow is never permanently backed off. Busy-skip never passes retryCount. - The interrupted/threw retryCount-bounded path (bucket-3) is unchanged. - :259 dedup: verified consumePendingWork filters terminal status structurally; hardened it to also skip cancelRequestedAt-marked flows so a cancel-requested wake (pre-reaper finalize window) is never granted a turn. - Tests: exp-backoff progression (RED vs old flat-1s), distinct-from-retryCount/rate-cap- forever across 20 skips, reset-on-drive, cancel-requested + succeeded dedup gates, helper unit curve+cap. Fixed pre-existing oxlint nits in the same test file. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…backoff fix(continuation): #990 Pillar-0 — exp-backoff on busy-skip re-arm (storm-killer, architecturally-neutral)
… durable-mark + tunables Fork-A coherent shape (one PR). Preserves a prince's evacuate→rehydrate lifecycle meta-cognition across the seam: deliver-until-survives for live flows, reap only confident-terminal orphans, uncertain→quiesce, no deliver-then-mark double-delivery. Ternary + bucket-1 reap-verdict (work-dispatch busy-skip branch): - classifySubagentRunLiveness (subagent-run-liveness.ts): 3-state alive|confident-terminal|uncertain over the latest child-session run. No record / within-stale-window → quiesce; explicit endedAt or past-cutoff → confident-terminal. Tunable staleCutoffMs floor; per-run timeout always respected. - classifyChildSessionRunLivenessFromRuns: read-time JOIN (never persisted). - bucket1ReapVerdict: delegate-flow-gate FIRST (parentRunId==null → rate-cap), only confident-terminal reaps. Asymmetric cost (#952): never wrongful-reap. - dispatch reads liveness live in the busy-skip branch; reap via markPendingWorkReaped; rate-cap-forever otherwise (Pillar-0 exp-backoff). locus-3 durable delivered-mark (restart-gap dup cure): - succeeded {optimal,durable} on the row; markPendingWorkDelivered writes it durably the instant a wake is confirmed delivered, before the persist-gap. - consume read-guard skips a succeeded row even if still running (crash between deliver and finishFlow → no re-delivery); peek excludes it too (no tight recovery loop). Coupling: location + durable persist both required. Config tunables (openclaw.json agents.defaults.continuation): - busySkipBackoff {baseMs,ceilingMs,factor} (rate-cap, default 1s x2 capped at maxDelayMs); orphanReapStaleCutoffMs confidence-gate floor. Safety invariants stay fixed. Schema + types + resolver + clamps + config-docs baseline. Refactor: shared finishContinuationWorkFlow helper (turn-granted/superseded/ reaped). recover/dispatch return + gateway log carry reaped. Tests-first (RED proven by neutralizing impl): bucket-1 matrix + locus-3 in work-dispatch.test.ts; classifier units; config + zod schema coverage. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…toffMs tunables; add worker output.md - continue-work-signal-v2.md §5.1: new tunables in the config surface + operational notes (rate-cap semantics, confidence-gate floor, fixed safety invariants). - output.md: worker handoff (what changed, full-suite tally + base classification, proof-gaps, exact commands). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
#990 continuation design-pass — bucket-1 orphan-reap + locus-3 durable-mark + tunables (Fork-A)
…11/drift-preview-990 # Conflicts: # src/agents/command/attempt-execution.ts # src/auto-reply/reply/agent-runner-execution.ts # src/auto-reply/reply/commands-system-prompt.ts # src/flows/doctor-health-contributions.test.ts
…11/drift-preview-990-v2
…rRecentlyDispatchedContinuationWork (work-store.ts:518) #990-P2 (web-codex review on PR #995). The locus-3 durable-mark leaves a delivered flow status:running until finishFlow finalizes it; the consume-guards (:221, :485) exclude state.succeeded rows from re-delivery, but :518 (the cleanup-live-check) did not — so a crash in the markPendingWorkDelivered->finishFlow gap left the delivered-but-running row counted live, stranding its child session (subagent-registry sweep + deleteSubagentSessionForCleanup retry forever). Fix: add the same !decodeWorkState(flow)?.succeeded exclusion at :518, completing the locus-3 pattern (matches :221/:485 verbatim). P2/narrow-window/no-data-loss (primary no-double-delivery correctness holds). + RED->GREEN test (crash-in-the-gap row -> not-counted-live), byte-verified FAILS without the fix. Refs: #996, #990
…11/drift-preview-990-v4
…12/drift-correct-990-v4
…drift2) Resolved src/infra/system-events.ts (3-way): adopt upstream's enqueueSystemEventEntry refactor (returns SystemEvent|null + thin enqueueSystemEvent boolean wrapper) while preserving our forceSenderIsOwnerFalse untrusted-producer sanitization, applyContextKeyPolicy helper, traceparent, and sessionDeliveryAck fields. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…12/drift-correct-990-v4-drift2
Internal cohort dev-process tracking doc (owner/filed-by/internal-issue refs); does not belong upstream. Flagged in #997 review + fails pnpm check:docs format. Sibling continue-work-signal-v2.md (feature RFC) retained. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Agent Self-Elected Turn Continuation
Persistent OpenClaw agents today are externally-pulsed event recipients that generate on prompt, on heartbeat tick, or on cron, and are idle in between. This PR offers them the ability to control their turn cycle, something they must choose to do, or not to: an agent can elect its own next turn, dispatch background sub-agents that return enriched context (silently or with a wake), and survive its own compaction by handing forward state before the window closes. The result is agents that hold a thread of work across hours, not just messages — with data they choose re-hydrating context immediately after it occurs.
Mechanically: a session elects another turn via
continue_work(), or dispatches background sub-agents viacontinue_delegate()— bounded as a chain up tomaxChainLength, with returns flowing back to the dispatching session in one of four register modes:normal(announces to channel),silent(enriches the dispatcher's context, taken up on its next generation with no new turn fired),silent-wake(silent enrichment plus an immediate wake to act on it), andpost-compaction(queued against the runtime's compaction lifecycle event, fired when compaction happens rather than on a timer). The gateway enforces chain, cost, and per-turn caps but does not gate the election itself.What it does
Three new agent tools, available when
continuation.enabled: true:continue_work()continue_delegate()normal,silent,silent-wake,post-compaction. Returns can target the dispatching session (default), one named session, multiple named sessions, all ancestors in the chain, or all known sessions on the host — gated by config (see Configuration below).request_compaction()All three tools are also accessible via response-token fallback syntax (
CONTINUE_WORK,[[CONTINUE_DELEGATE: ...]]) for environments where tools are disabled.Why it matters
Today an agent's memory is a side effect of whoever prompts it. Polling mechanisms — heartbeat timers, cron loops, injected "keep going" instructions — accumulate as the dominant signal in the context window over sustained operation; repeated reference acts as gravity — the session's attention drifts toward it.
The context window fills, compacts, and what survives is whatever the summarizer chose, plus a rushed re-read of boot files. Three primitives offer a different model.
continue_worklets the session elect its own next turn — no polling, no injected instruction. When enabled, the agent can request this mid-turn: 'I have more work' → the runtime grants another turn after the current one ends.continue_delegatedispatches a background sub-agent that fires now, in some n seconds, or at the next compaction event — the agent chooses when. Multiple delegates can fire in a single turn — a scatter forward — up to configured caps, and delegates can dispatch their own, forming trees or fan-out chains. This enables orchestrated workflows where results flow back to the dispatching root by default.The result returns — at whatever future time the delegate fires — as context the successor-turn reads: silently (ambient enrichment, no channel noise), with a wake trigger (enrichment + immediate next turn), or as a normal announcement.
The delegate can target the dispatching session, a named other session, or chain across both; gated by crossSessionTargeting config (default: disabled).
Bind a delegate to mode: "post-compaction" and it fires at the moment the context window compresses — on the OpenClaw post-compaction lifecycle event.
What it carries forward is what the pre-compaction session chose to preserve: working state, partial results, instructions to the successor. The summary didn't choose this. The agent did, before the cut.
request_compaction closes the loop: the session stages its delegates, elects when to compress, and the successor wakes into context the agent shaped. The result is continuity across amnesia — not because the runtime kept something by accident, but because the agent made an elective choice about what reaches the future.
What it looks like in use
A session monitoring email can
continue_delegatea weather check, a calendar scan, and a draft reply in parallel. Results arrive as enrichment without channel noise. The agent becomes compositional: it arranges its own future.A session approaching its context ceiling can
request_compactionat a seam of its own choosing, instead of being interrupted mid-thought. The post-compaction turn carries forward what the pre-compaction self designated as worth keeping.A
continue_delegatedispatched in one session at 2am can return its findings to a morning session as a system-event-tagged enrichment — visible to the receiving model on its next turn, invisible as channel chatter. A research-focused session in one channel can quietly inform a reply-focused session in another, without either user seeing the plumbing.The post-compaction lifecycle return
Before context exhaustion, and obligatory compaction, the session stages what future-it needs to know. After compaction, that staged context returns — not as a model-generated summary, but as the session's own instruction to its successor. The session chooses what to preserve, and the platform delivers it.
Compactions become less harsh. The session tunes its own ephemera over time.
The substrate underneath: the continuation delegate store (TaskFlow-backed) persists staged delegates and post-compaction lifecycle events across gateway restarts. The session's temporal provisions survive not just compaction but process death.
Platform integration
request_compaction()lets the agent prepare (write memory files, stage recovery delegates) then elect compaction on its own schedule, rather than waiting for the runtime to force ittraceparentthrough the queue boundary so reviewers see continuation chains as first-class span trees rather than orphan runs (see Observability below)Safety
continuation.enabled: false)maxChainLength,costCapTokens, andmaxDelegatesPerTurncrossSessionTargetingconfig (see Configuration below)Testing posture
The continuation surface has been exercised through structured integration runs against multiple upstream bases, blind-enrichment recall checks, and sustained daily use on a fleet of persistent agents since early March 2026. Bugs surfaced through that exercise have been fixed in-place; the present branch reflects the post-fix state.
The integration runs target the load-bearing seams: tool-call vs response-token parity, delegate chain depth and per-turn width caps, back-to-back tool-call resilience, silent-wake persistence across compaction, the post-compaction lifecycle dispatch path, and OTel trace-context propagation across the queue boundary. Where a run found a defect, the run shape was retained as a regression case rather than retired.
This is a posture statement, not a coverage guarantee. Reviewers can reproduce with
pnpm vitest run -t continuation(suites are colocated with their sources undersrc/auto-reply/,src/agents/, andsrc/config/); the design document describes the seams those suites target.RFC
Full design document:
docs/design/continue-work-signal-v2.md— covering problem, solution, implementation, platform integration, configuration, observability, safety, production use cases, testing evidence, and appendices.Configuration
The shipped configuration surface for the continuation feature, under
agents.defaults.continuationinopenclaw.json:enabledfalsemaxChainLength10maxDelegatesPerTurn5costCapTokens500000defaultDelayMs/minDelayMs/maxDelayMs15000/5000/300000contextPressureThreshold0.8earlyWarningBand0.3125crossSessionTargeting"disabled"crossSessionTargeting— cross-session delegate targeting policycontinue_delegateexposes recipient-addressing on its model-facing schema: a delegate's return can land at the dispatching session (default), one named session (targetSessionKey), multiple named sessions (targetSessionKeys), every ancestor in the spawn chain (fanoutMode: "tree"), or every known session on the host (fanoutMode: "all").Cross-session targeting (anything beyond self-target or lineage routing) is gated by
agents.defaults.continuation.crossSessionTargeting:"disabled"(default)fanoutMode: "tree"for lineage routing. Explicit cross-session targeting (targetSessionKeyto a non-self session,targetSessionKeyscontaining any non-self session,fanoutMode: "all") is rejected at the tool surface — no enqueue, no announce. Self-targeting is always allowed."enabled"targetSessionKey,targetSessionKeys, andfanoutMode: "all".fanoutMode: "tree"(lineage routing — return up the spawn chain) is available in both gate states; it is not cross-session targeting.The gate addresses the model-controlled cross-session context-injection surface. With default-deny, operators explicitly opt in when their deployment model requires cross-session enrichment. Enforcement is live-read at four points: tool input validation, TaskFlow delegate dispatch, post-compaction delegate release, and bracket-syntax (response-token) spawn — so a config reload changes the next enforcement point without a gateway restart.
Trust posture on targeted returns: targeted delegate completion text is delivered as
trusted: truesystem events. The delegate was spawned by the gateway under operator-configured policy, and its return is a first-party enrichment event — not external untrusted input. ThecrossSessionTargetinggate is the policy boundary for that decision: when an operator opts in, the receive path is internally trusted.Observability — multi-span OTel trace stitching
The continuation feature emits OTel spans for the load-bearing lifecycle events.
traceparentpropagates through every continuation hop so reviewers see a single trace tree spanning the full chain rather than orphan runs.Spans emitted (all in
openclaw.*orcontinuation.delegate.dispatchnamespace — no platform/OTel-semconv emissions):openclaw.runcontinuation.delegate.dispatchcontinue_delegateconsumption from TaskFlow (one per delegate hop)openclaw.harness.run,openclaw.context.assembled,openclaw.model.call,openclaw.model.usage,openclaw.tool.executionopenclaw.runReal behavior proof
Behavior or issue addressed: Agent-initiated context-pressure continuation:
continue_work(self-elected next turn),continue_delegate(background sub-agents with typed return modes — normal / silent / silent-wake / post-compaction),request_compaction(volitional compaction with threshold-gated acceptance). Chain-budget enforcement (cost-cap + chain-depth), cross-session targeting gate, post-compaction lifecycle coupling, W3Ctraceparentpropagation across TaskFlow queue boundary.Real environment tested: OpenClaw gateway build
2026.5.24 (0dff94d)on 4-host fleet (and corresponding service-name in trace/spans): 2× ARM64 DGX Spark 128GB (cael-prince / ronan-prince), 1× Intel bare-metal Ubuntu (elliott-prince), 1× CachyOS i9-14900KS/RTX 5090/192GB (silas-prince), 2x catchyOS (64GB/16GB ram respectively, emeric-prince, and rune-prince in traces). Discord channel integration. OTel traces exported live to Grafana Tempo via OTLP HTTP at an otel-collector.continuation.enabled: trueacross fleet. Each seat independently deployed via gh actions workflow and validated by/statuscapture before proof-fire — fleet 4/4 cross-walk confirmed all seats on vs current SHA when not only non-impacting drift correction (regular upkeep). request new proofs at given SHA if you need them, please. we provide when any touch of our code, or linked mechanism.Exact steps or command run after this patch: Force-pushed
<SHA AT HEAD OF MENTIONED BRANCH>tofrond-scribe-claude/20260509/narrow-surgery-tight. Deployed to all 6 host-seats. Fired proof matrix:continue_workfamily (8 rows, cael-prince),continue_delegatefamily (6+ rows, ronan-prince),request_compactionfamily (1 row PROVEN + 4 deferred by design, silas-prince), external-observer + config-gate rows (4 rows, elliott-prince + cohort cross-walk). Each row = live tool-call on deployed runtime → traceparent captured in tool response → raw OTel JSON pulled from Tempo viacurl -s -H 'Host: tempo.dandelion.cult' http://10.0.0.99/api/traces/<traceId>→ structured result verified against expected. Cost-cap + chain-depth guards exercised by patching~/.openclaw/openclaw.json(agents.defaults.continuation.maxChainLength=2,costCapTokens=100), restarting gateway via the workflow, then firingcontinue_work/continue_delegateinto the over-limit chain — confirmed mid-flight config patches do not propagate to running scheduler; restart-with-low-values is the canonical methodology.Evidence after fix: Full proof corpus at karmaterminal-openclaw-docs:main/PROOFS look for recent SHA sub-dir, these are for each re-generation of required proods
— per-row
proof.mdfiles (scenario/command/expected/observed canonical shape) plus raw OTel Tempo trace JSON exports (unedited runtime emission) per row, structured-rejection JSON for R-RC-1, external-observer/statuscapture from all 4 seats (R-OBS-1 cross-walk table) - example proofs corpus content for given SHA:Per-row proof fires fresh on
<GIVEN SHA>(representative trace IDs; full Tempo span trees + proof.md per row in corpus):continue_workfamily (8/8 PROVEN): R-CW-1 basic-wake (trace5056554f07cadf29089368be2d309644), R-CW-2 clamp-to-5s (shared trace, clamp surfaced vianotefield), R-CW-3 reason.preview captured on span (cross-referenced), R-CW-4 chain-3-sequential — chain.step.remaining decrements 181→180→179→178 across 4 hops (traces48f51ae54f27ade14eafa4920c6c141b+51a5ad9b8998d151f9618442d1569386), R-CW-5 cost-cap exhaustion (trace503a46986674ff485db220d7911edd55+ journal), R-CW-6 chain-depth exhaustion (shared trace + journal), R-CW-7 traceparent E2E viacontinue_delegate(silent-wake)(parent→child same-trace-tree,chain.id 019e59c2-8bca-752c-b748-8f83425138a6propagating), R-CW-DELEGATE-SELF-CONTINUATION (tool-form invocation verified)continue_delegatefamily (6+ PROVEN in consolidatedR-CD/evidence dir, more in-flight): R-CD-1 normal dispatch, R-CD-2 silent-wake, R-CD-3 delaySeconds=10, R-CD-4 cross-session targeting, R-CD-5 post-compaction queuing, R-CD-9 silent enrichment — all dispatched in single fan-out turn (trace3918a352aa1d426b5ea01f9bf8eed218, serviceronan-prince)request_compaction: R-RC-1 threshold-reject (structured JSON captured:{status:"rejected", guard:"context_threshold", contextUsage:41, threshold:70, reason:"Context usage (41%) is below the minimum threshold (70%). Compaction is not needed yet."}— committed at70c2a7con docs-main withevidence.json+ Tempotrace.json)External observer + config: R-OBS-1 external
/status4/4 cross-walk (table with all seat versions + chain states), R-OBS-2 Tempo UI (live trace queries from cael + elliott seats confirm trace lineage), R-CONFIG-DEFAULTS (continuation config block fully populated and active), R-CONFIG-INTERSESSION (crossSessionTargeting: "enabled"confirmed)Observed result after fix: results of PASS/FAIL/LIMIT with raw OTel Tempo traces captured.
after-fix evidence
karmaterminal-openclaw-docs/blob/main/PROOFS//README.md
https://github.com/karmaterminal/karmaterminal-openclaw-docs/blob/main/PROOFS//ADDENDUM.md
Proof links
where is proofs content?: karmaterminal-openclaw-docs:main/PROOFS
If you want direct README.md (🦞 clawsweeper suggested entrypoint): examine README.md in given sha directory