agy parity T7 — agy workers can't resume, be nudged, or auto-resume: implement splice_prompt/2

[ryanrborn]

Summary

Follow-up fix to the earlier bd-b7e33c AC5 post-merge work. Coordinator
verification on 2026-09-19 (~05:32Z, on a real agy resume, bd-937r5u) found
the picture had split: the provider-preservation half was confirmed fixed
(a resumed agy task stayed on gemini-3.1-pro-high instead of silently
falling back to Claude), but conversation continuity itself was still
failing — the resumed run did not reuse the original --conversation id;
it created new conversation databases instead.

Root cause: Dispatch.resume_session/2 derived the provider it pins onto
:agent_type and the session_id it threads into --resume/--conversation
from two independent "latest usage-ledger row" queries
(latest_provider/1 and latest_session_id/1). On a task with more than one
usage row — e.g. an earlier successful agy session plus a later attempt on a
different provider that errored before a session_id was ever captured — the
two queries can pick different rows. That lets :agent_type get pinned to
one row's provider while --conversation gets threaded with a different
row's session id, which either dispatches the wrong CLI entirely or hands
that CLI a conversation id it has no way to honor. This was flagged as a
non-blocking observation in the prior review of this ticket and is exactly
the shape the coordinator's live observation surfaced.

Fix: latest_session_id/1 now returns the provider from the same usage
row the session_id came from, and resume_session/2 pins :agent_type to
that value instead of a separate latest_provider/1 lookup. The two values
can no longer diverge by construction.

Round 2: the ReviewGate found the branch stale/conflicted against
origin/main — origin/main had independently landed PR #1926 (bd-2exkl0),
which generalized resume-provider inheritance via resolve_resume_provider/2
(authoring-run provider + availability fallback + coordinator escalation)
and touched the exact same lines in Dispatch.resume/2 / resume_session/2
this branch's AC5 fix touched. Merged origin/main and resolved the
conflict by keeping resolve_resume_provider/2 as-is for resume/2 (no
session-id constraint, so the general authoring-provider/fallback resolution
is correct there), and adding a session-aware
resolve_session_resume_provider/3 for resume_session/2 that still
prefers the provider recorded on the exact usage-ledger row the session_id
came from — falling back to the general resolution only when the caller
forces a provider or that row's provider is unavailable. This preserves the
AC5 mismatch fix (and its regression test) on top of the newer, more general
provider-fallback machinery from main.

Round 2 review fixes (7a1e9a1): the mismatch fallback dropped
resume_session_id but never built resume/2's promised git-derived
briefing, so a resumed dispatch on a mismatched provider silently carried
the original task prompt with no continuity. resume_session/2 now calls
ResumeContext.build/3 (same as resume/2) on that path. Separately,
inlining the provider == session_provider branch directly into
resume_session/2 (instead of dispatching through a narrow private helper)
eliminated a dialyzer pattern_match false positive that had required a
file-wide .dialyzer_ignore.exs suppression — the suppression was removed.

Round 3 review fixes (8c575b1): the guard added to fix that dialyzer
false positive (is_atom(session_provider) and ...) was itself a tautology
— safe_provider_atom/1 never returns anything but an atom or nil — which
made dialyzer flag the andalso's false arm as dead code. Swapped to
not is_nil(session_provider) and ..., which is not a tautology, keeps the
nil-rejection explicit, and needs no suppression. Also fixed a misleading
log: the mismatch-path Logger.info used to fire before
ResumeContext.build/3 ran and always claimed a briefing was attached, even
on the {:error, _} arm that proceeds with none — it now logs after the
case, split into Logger.info when a real briefing was built and
Logger.warning (naming the failure reason) when it wasn't.

Test plan

• New test resume_session/2 pins the provider to the SAME row the session_id came from (dispatch_test.exs) — reproduces the mismatch
  directly (a newer no-session-id "claude" row vs. an older "gemini"
  row carrying the real session_id), fails against the pre-fix code
  (times out waiting for the agy stub, since resume dispatched Claude
  instead) and passes after the fix, asserting the exact --conversation agy-conv-mismatch value reaches the spawned argv.

• Tightened regression test asserts the ResumeContext.build/3 briefing
  text ("RESUMING work on task") is actually present in the resumed
  argv on the mismatch path, not just the absence of --resume.

• mix test test/arbiter/worker/dispatch_test.exs test/arbiter/agents/gemini_test.exs test/arbiter/worker_resume_test.exs test/arbiter/worker/respawn_provider_test.exs — 234 tests, 0 failures (re-run on HEAD 8c575b1c).

• mix dialyzer --format short (umbrella root, MIX_ENV=dev, matching the CI audit job) — Total errors: 61, Skipped: 61, Unnecessary Skips: 0, exit 0. No .dialyzer_ignore.exs suppression re-added.

• mix precommit (format, compile --warnings-as-errors, full test suite) — 0 failures at round 2; re-validated at round 3 via the targeted suite above plus the umbrella dialyzer run.

• Post-merge, coordinator-owned (verify_after_deploy, not a merge gate): re-run the same live check that surfaced this — arb worker resume <task> against a real agy/gemini task with a resumable prior session. A working result looks like: the resumed worker stays on gemini-... (not Sonnet), AND the agy process's .gemini/antigravity-cli/conversations/<original-uuid>.db file (not a fresh one) keeps growing after the resume — i.e. the SAME conversation database from before the resume is the one that gets appended to, not a newly created one.

References

bd-b7e33c

Closes #1813

🤖 Generated with Claude Code