fix(pixel): a harness revision or continuation prompt keeps the owner's request scope

[Lightheartdevs]

What went wrong

In the fleet's live event search (rounds 105–112), the journey runs in the same chat as the website and coding journeys, so the chat already has a published preview. When the answer cited pages Pixel had not opened, completion assurance asked for one revision:

Revise your answer: replace each listed URL with a page you actually read successfully in this response that supports the same claim, or remove that URL and mark the claim as unverified.

OpenClaw sends that revision as the next attempt's prompt of the same run. observeRun re-derived the owner's request from every attempt's prompt, and "remove that URL" matches the visual-follow-up classifier (remove + that). With a verified preview in the session, the research run became a visual continuation of that preview. Every source-attribution revision that reached the model in these rounds went wrong this way:

Host, round, model	What happened in the revision pass	Result
tower3 r105, Qwen3.5-27B	web_fetch and pixel_ods_web_extract of the cited pages refused: "Keep this visual follow-up in the bound artifact directory…"	tool limit; partial answer with the old website's preview link appended; pixel_outcome failed
laptop r109, Qwen3.5-9B	same refusals for web_search and web_fetch	same
tower2 r112, Qwen3-Coder-Next	the guard's visual-continuation stage ("Pixel is updating the most recently verified visual artifact…") sent the model to read, edit and republish the coding project's public/index.html ("Philadelphia Events & Expense Report CLI")	pixel_outcome passed, in a turn that said "Do not create files"

The trajectories show the prompt each attempt received, so the revision text is not inferred. The same re-derivation also changes the verification contract after a continuation prompt. In a unit probe, an owner request to run the unit tests went from failed (not run) to none once the mid-turn continuation text was observed.

The change

A run answers one owner message, and its first attempt carries it. observeRun now treats a later attempt of the same run whose text differs from that message as a harness attempt. A harness attempt keeps what the first attempt established and re-derives nothing from its own text:

• research date;
• preview and workspace obligations;
• requested checks;
• Operations scope and ODS tool routing;
• private-URL access;
• GitHub target.

Session bookkeeping and cancellation handling still run on every attempt. When OpenClaw resubmits the owner's own text after a pre-prompt overflow, it is classified as before.

Tests

• tool_loop_guard.test.mjs, new test (fleet replay). A website preview is published in the session. The research run's source revision is armed, then the revision attempt is observed with OpenClaw's exact prefix and ODS's instruction. The cited page read is not refused, the revised answer is accepted without a visual-continuation pass, and delivery is none. On main this fails at the page read: it is blocked with the visual-scope reason.
• tool_loop_guard.test.mjs, second new test. A coding request that asks to run unittest keeps its failed (not run) verification after the mid-turn continuation prompt, after a revision prompt, and after a resubmission of the owner's text. On main it becomes none.
• preview_directory_hint.test.mjs. One test had observed a second owner message ("Do not display or publish any preview.") inside the same run. That cannot happen: a new owner message is a new run. The test now carries that instruction in the run's own owner message. It still checks that no publication hint is given, and the adjacent test still shows the hint when publication is allowed.
• Full plugin JS suite on tower2 (Node 22.23.1): this head 3205 tests, 3167 pass, 0 fail, 38 skipped. main 5afd46c: 3203 tests, 3165 pass, 0 fail.
• Real OpenClaw 2026.6.33 integration tests on tower2, main and this head:
  • runtime_cancel_recovery and runtime_preview_delivery: 8/8 on both.
  • After the completion-recovery repair, runtime_progress_finalization, runtime_stop_synthesis and runtime_owner_visible_reply: 8/8 on both.

Not in this PR (found in the same investigation)

• Revisions refused after pixel_ods_web_extract. OpenClaw refuses a before_agent_finalize revision after any plugin tool, even one declared replay-safe (runtime_completion_assurance.integration.mjs documents this). In 5 in-scope failures the model had used targeted extraction, so the armed partial or replacement delivery was final: tower3 r107, tower2 r108, laptop r108, tower1 r109 and tower2 r110. Host citation verification is the path that works there, which is what fix(pixel): accept year-less event page dates the page does not contradict #6730 and fix(pixel): show schema.org event and offer data from a page's markup in the shared reader #6733 improve.
• Revision lost after a pre-prompt overflow. When the revision attempt itself overflows the pre-prompt check, OpenClaw compacts and retries with the original owner prompt, not the revision. This happened on laptop r105, tower3 r108 and tower3 r111. fix(pixel): recover owner-turn context overflows by trimming tool output when that fits #6715 changes which recovery runs, not which prompt the retry uses.
• Conflicts. This touches observeRun lines that fix(pixel): plan within the output limit, continue a cut Portal turn once, report otherwise #6743 and fix(pixel): a refused rm -rf keeps a current passing test, and the owner gets a receipt instead of guard text #6753 also change, so the conflicts are textual:
  • fix(pixel): plan within the output limit, continue a cut Portal turn once, report otherwise #6743: keep its ownerChatUser and outputLimitRetried statements above the guarded if.
  • fix(pixel): a refused rm -rf keeps a current passing test, and the owner gets a receipt instead of guard text #6753: its new receiptAnswersOwnerRequest line should also get && !harnessAttempt.

🤖 Generated with Claude Code