Summary

What problem does this PR solve?

When an agent's last tool call is update_plan (or any tool with empty/no-op result), and the model then produces a final plain-text turn with stopReason="stop", three cascading bugs cause a silent send miss:

1. resolveIncompleteTurnPayloadText reads stale lastAssistant.stopReason === "toolUse" instead of the actual final assistant message
2. The incomplete-turn branch discards all collected assistantTexts and returns only the error warning
3. The user receives nothing — dashboards report green

Why does this matter now?

This fires for any agent following checklist discipline (closing tasks with update_plan), which is the default behavior pattern, not an edge case. Impact is HIGH — silent data loss with no observability signal.

What is the intended outcome?

• Users receive their agent's final visible answer alongside the incomplete-turn warning
• The incomplete-turn classifier uses currentAttemptAssistant as the authoritative source for stopReason, avoiding stale snapshots

What is intentionally out of scope?

• P1 observability improvements (structured alarms, delivery-queue/failed/ logging, openclaw recover --run-id)
• Live WhatsApp/channel proof (L2 only — vitest + temp state)

What does success look like?

The assistantTexts collected during the run are included as non-error payloads before the warning text, so even if the incomplete-turn classification is a false positive, the user still receives their content.

What should reviewers focus on?

The currentAttemptAssistant ?? lastAssistant resolution in resolveIncompleteTurnPayloadText: this is the fix for the stale snapshot. Verify it does not suppress legitimate incomplete-turn detection for the original #76477 use case (interrupted tool chain with genuinely missing final text).

Linked context

Which issue does this close?

Closes #80918

Which issues, PRs, or discussions are related?

Related #76477

Was this requested by a maintainer or owner?

No — contributor-identified and self-fixed.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Silent send miss from stale lastAssistant snapshot after update_plan tool call
• Real environment tested: Local vitest (no live OpenClaw/WhatsApp setup)
• Exact steps or command run after this patch: See Tests section below
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

{
  "test": "src/agents/embedded-agent-runner/run.incomplete-turn.test.ts",
  "result": "116 passed",
  "key_change": "payloads[0] is now assistantText (isError=false), payloads[1] is warning (isError=true)"
}

 Test Files  1 passed (1)
      Tests  116 passed (116)

• Observed result after fix: The incomplete-turn branch includes assistantTexts as deliverable non-error payloads before the warning. The classifier uses currentAttemptAssistant for the stopReason check.
• What was not tested: Live WhatsApp/channel end-to-end delivery (no live environment available)
• Proof limitations or environment constraints: L2 only — unit tests with mocked session state. No L3 live channel proof.
• Before evidence (optional but encouraged): The original report in Silent send miss: incomplete-turn classifier discards stopReason=stop final after update_plan #80918 includes detailed trace.artifacts showing didSendViaMessagingTool=false and messagingToolSentTexts=[]

Tests and validation

Which commands did you run?

pnpm test src/agents/embedded-agent-runner/run.incomplete-turn.test.ts
pnpm test src/agents/embedded-agent-subscribe.handlers.lifecycle.test.ts

What regression coverage was added or updated?

Updated existing test: "emits incomplete-turn warning when tool-use assistant dropped final text" now asserts that assistantTexts[0] appears as payload[0] (isError=false) before the warning at payload[1] (isError=true).

What failed before this fix, if known?

The test previously expected payloads[0].isError === true. Now it expects the assistant text payload first, reflecting the fix.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes — users now receive their agent's final answer instead of silence when the incomplete-turn classifier fires after a tool-use stop reason.

Did config, environment, or migration behavior change? (Yes/No)

No

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No

What is the highest-risk area?

False-negative risk: if a truly incomplete turn now delivers partial text alongside the warning, users might see preliminary analysis. The warning text still clearly indicates the turn was classified as incomplete.

How is that risk mitigated?

• Assistant texts are delivered BEFORE the warning, so the warning remains visible
• The incomplete-turn guard still fires and produces the warning
• The currentAttemptAssistant resolution only changes behavior when the final message has stopReason="stop" — genuinely interrupted tool chains still have stopReason="toolUse" and are unaffected

Current review state

What is the next action?

Wait for CI to complete; then maintainer review.

What is still waiting on author, maintainer, CI, or external proof?

• CI checks
• Maintainer review

Which bot or reviewer comments were addressed?

N/A — first submission