4 Commits
Author SHA1 Message Date
pastilhasandClaude Opus 5 45e3e86d72 write down what to test, and what is most likely broken
The serve is the only path now, so this is not a comparison against a fallback.

Split by what I have actually driven end to end versus what probes cannot answer. The second
list is the real testing: resume from history (never exercised against the serve, and my
pick for most likely broken), an idle session, a sidecar restart mid-turn, an officer restart
mid-turn, and two conversations at once — that last one because the live event stream is
global and a wrong sessionID filter would splice one conversation into another.

Known gaps are listed so they do not get reported as bugs, and the one silent failure mode
with a single cause — a turn producing nothing at all — points at the credential line from
boot, which I have chased twice already.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 19:34:48 +01:00
pastilhasandClaude Opus 5 a058cbb3fd inject a mid-turn message instead of replacing the turn
Phase C server half, and a real flaw in phase B.

On the subprocess path a second message could only supersede — kill the process, start again,
lose the turn — because opencode run has no input channel. The serve takes another prompt
into the running turn, so a message arriving mid-turn is handed over with delivery steer and
the existing turn is left exactly as it is.

Keeping the same turn object is the load-bearing part. Phase B retired it and registered a
replacement, which stops officer routing events the serve is still producing while the serve
carries on regardless: output goes nowhere and the turn looks hung.

Verified end to end through the chat socket — sent a count to 50, injected a change of plan
eight seconds in, and BANANA INJECTED came back inside the same turn with deltas streaming
throughout.

No client change was needed. Officer composer already sends while generating; the difference
is only what the sidecar does with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 19:17:26 +01:00
pastilhasandClaude Opus 5 feb9010097 phase A: map the serve event stream, routed nowhere
The mapping half of the serve migration, written and pinned before anything depends on it,
so the switch-over is not also the moment the parsing turns out to be wrong. Nothing routes
through this — turns are still opencode run subprocesses, and the claude path is untouched.

The finding that matters: the serve publishes each turn TWICE, and reading the wrong one
makes it look like it cannot stream at all.

  /api/session/{id}/event?after=  durable, per session, replayable, durable.seq on every
                                  event, whole values only, NO deltas
  /api/event                      live, GLOBAL, ephemeral, carries text.delta and
                                  tool.input.delta, no cursor

Same turn: 13 events durable, 21 live, the difference being 3 text.delta and 5
tool.input.delta. I probed the per-session one first and nearly recorded "no streaming" as
a fact — it would have removed the main reason to migrate. The split maps exactly onto what
officer already does for claude: durable to chat_session_events, live to UI deltas. The cost
is that the live stream is global, so a consumer must filter on sessionID.

tool:start is emitted on tool.called, not tool.input.started, because only tool.called has
the resolved input object — the input arrives as JSON fragments ({"comman) and a tool row
rendered with half-parsed arguments is worse than one that appears a moment later.

step.ended with finish tool-calls is a step boundary MID-turn, not the end of the turn, so
nothing terminal is emitted for it. Treating it as the end would cut every tool-using
conversation in half.

Fixtures are verbatim captures from 1.18.16. Replaying both real streams through the mapper
reconstructs the turn identically from each, with the reassembled deltas exactly equal to
the committed text and identical cost, and zero unrecognised events.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:33:33 +01:00
pastilhasandClaude Opus 5 38ebe168f0 retire two phantom gaps, and plan the migration
Crash-recovery state is not a gap: state:sync goes to the proxy capability and carries
proxySecret, and syncState/getCachedState have no callers at all. The row compared opencode
against a mechanism officer never consults. The real recovery story now exists and is better
— a sidecar restart stops in-flight turns and writes the reason to chat_session_events.

Identity is deferred, not forgotten: TODO.md already records it, and chat is kind execution,
which the grants API refuses to share at any level, so no member can reach it.

Also adds the serve migration plan, written while the facts are fresh and nothing is on
fire. It leads with the five things that will bite whoever implements it — per-request
location, the data wrapper, delivery defaulting to steer, silent failure on an unconnected
credential, and the session.next event names — because none of them are in the API docs and
each cost time to find today.

Phased so the old path stays one config flip away, and so warm-session lifetime (idle GC,
orphan adoption, the supersede race) is imported deliberately rather than discovered.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:27:23 +01:00