* fix(model-fallback): treat empty non-GPT completions as failed candidates (#120132)
Empty and whitespace-only completions from non-GPT models were counted as
candidate_succeeded, silently dropping the turn on visible channels. Apply
the empty/reasoning-only classification to every model; deliberate silent
replies and committed outbound deliveries remain successful.
* fix(model-fallback): classify mixed reasoning-plus-blank completions as failed (#120148)
A completion like [{ isReasoning: true, text: "thinking" }, { text: " " }]
carries no user-visible reply: reasoning text is invisible to the shared
visibility test (includeReasoningPayloads: false), so counting it as visible
made the run look successful and silently ended visible-channel turns.
Filter reasoning payloads out of the empty/whitespace predicate so mixed
reasoning-plus-blank results classify as empty_result (fallback-worthy),
while mixed reasoning-plus-visible-text results stay successful.
Regression tests: mixed reasoning+blank -> empty_result; mixed
reasoning+visible -> success.
* fix(model-fallback): require deliverable assistant results
Use one owner-boundary deliverability predicate for fallback classification, preserve intentional terminal outcomes, and add a mock-channel Gateway scenario for mixed reasoning-plus-blank recovery.\n\nCo-authored-by: 李琪0668001400 <li.qi16@xydigit.com>
* chore: preserve contributor credit
Co-authored-by: 李琪0668001400 <li.qi16@xydigit.com>
* test(qa): cover default model fallback scenario
Make the mixed reasoning-plus-blank fixture recover through both the catalog default alternate and the explicit proof model.
Co-authored-by: 李琪0668001400 <li.qi16@xydigit.com>
---------
Co-authored-by: licheer-zte <licheer-zte@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Resolve reply mode through the selected Telegram account so account overrides and top-level inheritance reach outbound reply context.
Co-authored-by: Tak Hoffman <781889+Takhoffman@users.noreply.github.com>
* fix(subagents): wake the parent when a follow-up finishes a yielded child
A sub-agent that calls sessions_yield on its own behalf parks its run and
correctly withholds the parent's announce. But a later follow-up to that same
child session registered a sibling registry row instead of continuing the paused
one, so the requester defaulted to the child's own main session and the original
parent — itself idle behind sessions_yield — was never woken. The paused row also
stayed an unsettled descendant, deferring the parent's settle batch forever with
nothing recorded explaining the silence.
Follow-up dispatch now adopts the paused row through the existing post-steer
replacement seam, inheriting the requester identity and carrying the settle-wake
credential forward with its frozen batch membership remapped to the new run id.
A follow-up that names its own requester keeps registering separately, since an
explicit requester is a delivery opt-in that adoption would silently drop.
Also stops frozen-result refill from targeting paused rows: a yield clears the
result on purpose, so refilling from the session would attribute a later turn's
text to the paused run.
Closes#120157
* fix(subagents): select the paused owner past a requester-bound sibling
Adoption looked up the newest run for the child session and adopted it only
when that row was itself paused. A requester-bound follow-up deliberately stays
a sibling, but it registers at a higher generation and becomes that newest row,
so any later default follow-up saw an unpaused newest row, declined adoption,
and registered yet another sibling. The original requester stayed parked behind
a paused row that can never announce -- the same silent stall this fix exists to
remove, reached through a valid mixed-delivery sequence.
The latest-run query now takes an optional predicate applied before the
generation comparison, so a caller that owns a specific row class selects the
newest row of that class. Adoption asks for the newest `sessions_yield` row
directly instead of inferring it from generation order.
Docs now state that continuation applies to default delivery, since a follow-up
carrying its own requester runs as a sibling by design.
* test(qa): prove post-yield follow-up delivery through the gateway boundary
The unit and gateway-method tests for paused-run adoption assert on registry
rows, which proves the bookkeeping but not that an operator ever sees the
result. This adds the boundary proof: a real gateway child, the QA mock channel,
and the mock provider driving a subagent that pauses itself and finishes only on
a later follow-up.
A fixture plugin owns both legs. Its `before_dispatch` hook spawns the child with
`completionDelivery: "current-requester"`, so the announce has the operator turn
as its audience. An HTTP route then dispatches the follow-up to that same paused
session using default delivery -- the path adoption is meant to catch. A
requester-bound follow-up would opt into its own audience and run as a sibling
instead, so the two legs must differ here.
The mock provider gains a child that yields on its own behalf. Both of its turns
match on the current prompt rather than the shared transcript, so the yielded
kickoff cannot make the follow-up turn yield a second time.
The scenario asserts both sides of the invariant: no outbound traffic while the
child is paused, and exactly one announce carrying the follow-up marker once it
ends.
Reverting the adoption call site fails this test in the way that matters: the
child still produces its marker and the run still ends with stopReason=stop, but
nothing reaches the requester and the wait times out. The result is computed and
then silently dropped -- which is the failure this repair exists to remove.
* fix(ci): match QA Lab fixture plugin entries as a group in knip
The all-exports pass listed one fixture entry by name, so every new QA Lab
fixture plugin lands as an unused file and turns check-dependencies red until
someone remembers this file. Nothing imports these entries by design: the
Gateway E2E loads them through plugin config paths.
* docs(subagents): scope yield continuation to plugin runtime follow-ups
Adoption is gated on plugin_subagent task tracking, which only
createGatewaySubagentRuntime().run sets, so api.runtime.subagent.run is the
sole route into it. Writing that as one example implied other follow-up paths
to a paused session continue the run too; they are not tracked as sub-agent
runs and announce nobody.
* fix(subagents): reject undurable paused-run adoption
Fail plugin follow-up admission closed when the paused-run ownership swap cannot be persisted, while retaining the existing restart-recovery return-false contract. Trim duplicate tests and keep boundary coverage for requester routing, wake-batch remapping, repeated yield, and persistence rollback.
Co-authored-by: zhou.huanfeng <woundfongv3@163.com>
* docs(subagents): clarify yielded-run steering
Co-authored-by: zhou.huanfeng <woundfongv3@163.com>
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* test(qa): add managed-worktrees CLI lifecycle scenario coverage
Managed worktrees had zero QA scenario-pack coverage despite being a
headline feature. Mint agent-runtime.managed-worktrees-lifecycle in the
taxonomy, add a runtime scenario, and prove the real child CLI through
create with .worktreeinclude provisioning and the .openclaw setup hook,
dirty removal pinning a snapshot ref, restore rebuilding tracked,
untracked, and provisioned files with their modes, and gc preserving
manual worktrees.
* fix(qa): align model-switch catalog assertion with expectedAlternate flow
qa/scenarios/models/model-switch-follow-up.yaml switched to
expectedAlternate.model in 5a795f4dda but the catalog test still greps
for the retired alternate?.model literal; the test is outside the PR
change-classification lanes, so the break only surfaces on direct runs.
* test(qa): narrow managed-worktrees taxonomy description to proven manual-owner gc
ClawSweeper P2 on #120335: the scenario proves manual-owner gc retention
only; session and Workboard cleanup lifecycles are not exercised, so the
coverage description must not claim them.
Prevent retained plugin closures from recreating, adopting, or stopping successor runtimes across shutdown and restart.
Add deterministic lifecycle regressions for pending startup, exact-owner stop, retained tools, and generation restart.
* fix(discord): thread archive/delete closes sessions in each agent's store
closeDiscordThreadSessions resolved the sessions store with the Discord
account id as agentId ('default' on the default path), which points at a
nonexistent agent's store — archiving or deleting a thread silently closed
nothing. The store now resolves per routed agent via listAgentIds and every
agent's matching sessions are deleted.
* fix(discord): type thread session cleanup across agent stores
* fix(discord): scope thread-session scan per agent and keep it read-only
* test(discord): cover thread deletion across agent stores
* fix(imessage): text echo matching honors message-id conflicts; own sends stop feeding the loop limiter
Two silent-drop paths in the iMessage monitor:
1. The persisted 12h echo cache matched inbound user text against old
outbound text even when the GUIDs conflicted — a user sending 'ok' within
12h of the agent sending 'ok' was dropped as an echo. The text branch now
applies the same hasConflictingMessageIds guard the media branch has;
genuine reconnect echoes still match by id or id-less entries.
2. Every from-me row fed the echo loop rate limiter, so a normal outbound
burst (agent replies, multi-chunk sends, operator phone traffic) could trip
the limiter and silently suppress the next legitimate inbound message.
'from me' is no longer counted as a loop signal, and a tripped limiter now
logs a default-level warning once per conversation instead of verbose-only.
* fix(imessage): preserve delayed echo guards
* refactor(test): exercise real session rewind policy
* refactor(test): use real Telegram media policy
* refactor(test): exercise real HTTP cancellation lifecycle
* test(gateway): prove mutations clear queued session work
Peter Steinberger