Summary

Problem. Agent Teams could deliver a subagent completion event whose status was
failed: subagent run lost active execution context while the same event carried a
non-empty child result (the report shows a full # ARCHITECTURE.md). The lifecycle
status and the delivered result disagree, so a parent orchestrating with
sessions_spawn / sessions_yield treats successful work as a plain failure and can
retry, stall, or leave the workflow inconsistent.

Root cause. When the registry sweeper finds a stale active run whose in-memory
context is gone and whose session store has not settled a terminal status,
resolveCompletionFromSessionEntry() returns null and the sweep falls through to a
hardcoded lost-context error (subagent-registry.ts, the sweeper-lost-context
branch). It never consults the child transcript, even though the announce path has
already captured a real final result from it.

Fix. Before emitting the lost-context error, the sweeper now reconciles the child
transcript and, only when the child produced a genuine terminal result, settles the
run as ok so the lifecycle status matches the delivered result. When there is no
genuine result it keeps the existing lost-context error.

The success predicate is the key. Rather than reusing the broad display helper
readSubagentOutput (which also surfaces a synthetic "N tool call(s) made without visible output." summary) or a fresh "any visible text" check (which ignores a
trailing sessions_yield wait), this adds a strict predicate that reuses the existing
sessions_yield-aware snapshot (summarizeSubagentOutputHistory) and returns a result
only when there is final visible assistant text and the child is not parked waiting.
This is exactly the boundary the two prior attempts (#90492, #91400) got wrong. The
predicate also rejects a toolUse assistant turn that carries visible pre-tool text
plus a tool call (the model expected to continue after tool results), and any trailing
tool-only turn after a text turn — in both cases the child is still working, not finished.

Changes

• src/agents/subagent-announce-output.ts
  • Extract loadSubagentHistoryMessages() (shared history source).
  • Add resolveTerminalChildResultText(messages) — strict terminal-result predicate.
    Returns the final visible assistant text only; undefined for sessions_yield
    waits, toolUse turns (visible pre-tool text plus a tool call), trailing tool-only
    turns, tool-call-only histories, silent markers, and empty histories. A new
    lifecycle-only latestAssistantTurnTerminal snapshot flag tracks this; the display
    selector (selectSubagentOutputText / readSubagentOutput) ignores it, so display
    behavior is unchanged.
  • Add readTerminalChildResult(sessionKey, options) — reads a child session and
    applies the strict predicate (reuses the same source as readSubagentOutput).
• src/agents/subagent-registry.ts
  • In the sweeper-lost-context branch, attempt readTerminalChildResult first; on a
    genuine result complete as ok (sweeper-lost-context-recovered). A read failure
    is caught and falls through to the existing lost-context error so the run is still
    settled (the sweep is never aborted).

What did NOT change (scope)

• readSubagentOutput keeps its existing display semantics — only its internals were
  factored into a shared loader.
• No announce-delivery, spawn, orphan-recovery, or Gateway API changes. Runs without a
  genuine terminal result still complete with the existing lost-context error.

Reproduction

1. Run a task that uses sessions_spawn to create a subagent and sessions_yield to
   wait for completion.
2. Arrange for the child to produce a final result while its in-process run context is
   cleared before the session store settles a terminal status (the sweeper then enters
   the lost-context branch).
3. Before: the parent receives status: "error" /
   "subagent run lost active execution context" even though the same event carries the
   child's result.
4. After: when a genuine terminal result is present, the parent receives
   status: "ok" with the result; tool-call-only and yield-wait children still settle
   as lost-context errors.

Real behavior proof

Behavior or issue addressed: The lost-context sweeper branch labeling a stale child
run as failed: subagent run lost active execution context while a real child result
was delivered, and the inverse risk of recovering a non-terminal child (tool-call-only
or sessions_yield wait) as a successful completion (#90299).

Real environment tested: Linux (Ubuntu 24.04, Node v22.22). A standalone harness
writes three real child transcripts as on-disk .jsonl files in OpenClaw's transcript
format, then drives the shipping reconciliation and output code against them: the real
resolveCompletionFromSessionEntry, the real transcript reader
(readSessionMessagesAsync), and the real output predicates. The child's in-memory run
context is genuinely absent and the session entry status genuinely lags as running, so
resolveCompletionFromSessionEntry returns null and the lost-context branch is
exercised exactly as in the report. Each predicate decision is computed by the real
shipping code over the real parsed transcript; the prior approaches (#90492's
readSubagentOutput and #91400's hasVisibleAssistantOutput) are run side by side over
the same files for comparison.

Exact steps or command run after this patch:

• Write four real transcripts to a temp dir: child-terminal.jsonl (final assistant
  result), child-tool-only.jsonl (tool call, no visible result), child-yield.jsonl
  (visible progress text followed by a sessions_yield wait), and child-pretool.jsonl
  (visible pre-tool text plus a tool call, stopReason: "toolUse").
• Run the harness: node_modules/.bin/tsx oc-proof-90299.ts.

Evidence after fix:

Trigger condition — session store reconciliation:
  resolveCompletionFromSessionEntry(status="running" lagging entry) => null
  => null  ⇒ the sweep falls through to the lost-context branch (as in the bug report).

SCENARIO: genuine terminal result (child delivered the deliverable)   correct: ok
  ORIGINAL  (main)                   : status=error ✗ WRONG  delivered child result IS present → status disagrees with result (the bug)
  PR #90492 (readSubagentOutput)     : status=ok    ✔
  PR #91400 (hasVisibleAssistant.)   : status=ok    ✔
  THIS FIX  (readTerminalChildResult): status=ok    ✔  recovered ("# ARCHITECTURE.md\n## System Overview\nPure Python"…)

SCENARIO: tool-call-only run (no visible result)                      correct: error
  ORIGINAL  (main)                   : status=error ✔
  PR #90492 (readSubagentOutput)     : status=ok    ✗ WRONG  false-ok via readSubagentOutput → "1 tool call(s) made without visible outp"…
  PR #91400 (hasVisibleAssistant.)   : status=error ✔
  THIS FIX  (readTerminalChildResult): status=error ✔  no genuine terminal result → kept lost-context

SCENARIO: visible text THEN sessions_yield wait (parked on descendants)  correct: error
  ORIGINAL  (main)                   : status=error ✔
  PR #90492 (readSubagentOutput)     : status=error ✔
  PR #91400 (hasVisibleAssistant.)   : status=ok    ✗ WRONG  recovered via hasVisibleAssistantOutput (ignores trailing yield)
  THIS FIX  (readTerminalChildResult): status=error ✔  no genuine terminal result → kept lost-context

SCENARIO: visible pre-tool text + tool call (toolUse, still working)  correct: error
  ORIGINAL  (main)                   : status=error ✔
  PR #90492 (readSubagentOutput)     : status=ok    ✗ WRONG  false-ok via readSubagentOutput → "Let me read RELEASE_BRIEF.md first."…
  PR #91400 (hasVisibleAssistant.)   : status=ok    ✗ WRONG  recovered via hasVisibleAssistantOutput
  THIS FIX  (readTerminalChildResult): status=error ✔  no genuine terminal result → kept lost-context

Observed result after fix: On the genuine-terminal-result transcript the run settles
as ok with the captured result instead of the contradictory failed: lost active execution context, resolving the reported disagreement. On the tool-call-only,
text-then-sessions_yield, and pre-tool-toolUse transcripts the run correctly stays on
the lost-context error path. Across the four real transcripts this is the only predicate
correct on all of them: the original main reports failed even with a delivered result;
readSubagentOutput falsely recovers the tool-call-only and pre-tool-toolUse runs;
hasVisibleAssistantOutput falsely recovers the yield-wait and pre-tool-toolUse runs.

What was not tested: A full live Gateway socket round-trip with a real LLM-backed
subagent process that loses context mid-run was not driven. The harness exercises the real
reconciliation, transcript parsing, and predicate code over real on-disk transcripts and a
real lagging session entry, but it synthesizes the lost-context window rather than killing
a live gateway process, and it does not depend on any external model/provider.

Notes

AI-assisted change. Automated coverage added and passing: unit tests for
resolveTerminalChildResultText / readTerminalChildResult (terminal result, tool-only,
sessions_yield wait, text-after-yield, toolUse pre-tool text, trailing tool-only,
whitespace, empty) and three sweeper integration tests in subagent-registry.test.ts
(recovers ok with a genuine result; keeps the lost-context error for tool-call-only and
for a toolUse pre-tool-text turn). Core and test typechecks are clean.

Fixes #90299. Supersedes the inactive #90492 (and the closed #91400), addressing the
predicate-breadth findings ClawSweeper raised on both: tool-call-only histories,
sessions_yield waits, and toolUse turns with visible pre-tool text are not recovered
as success, and a transcript-read failure preserves the lost-context error instead of
aborting the sweep.