Regression 0.29.0 → 0.34.0: assistant messages from ACP turns no longer persisted to session store (wire.jsonl)

Summary

Regression between 0.29.0 and 0.34.0: assistant messages produced during
ACP-driven turns (kimi acp) are no longer persisted to the session store.
In 0.29.0 they were persisted correctly — so the original design intent was
to persist. In 0.34.0, only the user prompts of ACP turns are written.

Two-version control experiment

Same ACP flow (initialize → session/new → session/prompt) compared across
versions, measured by inspecting agents/main/wire.jsonl afterwards:

TUI-driven turns persist both prompt and assistant output in all tested
versions. The regression window 0.29.0 → 0.34.0 should be bisectable.

Concrete sessions (can be shared on request):

• 0.29.0 OK: session_efd1517a-7a02-45ce-b70c-c81f814f6f0b
• 0.34.0 broken: session_d1a75eb5-979f-4830-899a-6c7a12a844a7 (session/new),
  session_36707bee-e502-4124-b682-525a5df4c098 (session/load, 3 ACP turns)

Impact

1. Resuming the session in the TUI (kimi -S <id>) replays ACP-side user
   prompts but not the assistant answers.
2. Subsequent model context misses ACP-side assistant output — information
   produced via ACP is effectively lost to future turns. Side effect: when a
   later turn runs from either client, unanswered foreign-side prompts are
   treated as pending and get answered again (observed in a concurrent
   TUI+ACP test).
3. Affects ACP integrations generally (editors and remote/mobile clients).

Environment

• kimi-code 0.34.0 (control: 0.29.0), macOS (Darwin 25.6.0)
• Session store: ~/.kimi-code/sessions/wd__//agents/main/wire.jsonl

Reproduction (0.34.0)

1. kimi acp → initialize → session/new → session/prompt → answer streams
   correctly to the ACP client (streaming itself is fine).
2. Inspect agents/main/wire.jsonl: the ACP turn contains turn.prompt,
   context.append_message, step.begin, llm.request — but zero
   content.part / step.end / turn.ended events for the assistant output.
3. Resume in TUI: the ACP user prompt is replayed, the assistant answer is
   missing.
4. Repeat on 0.29.0: content.part events are present for the same flow.

Expected

Persist assistant messages from ACP-driven turns as 0.29.0 did.

Notes

• turnId appears to be a per-process local counter (collisions observed
  between ACP and TUI processes, both used turnId=2); loop events carry a
  global uuid, turn-level events do not.
• Full event-level logs (one session's 54 events classified by type, plus the
  two-version control runs) available on request.

Start with the kimi acp session/new and session/prompt entry points and inspect how their events are written to agents/main/wire.jsonl. Compare the 0.29.0 and 0.34.0 flows, using the provided event sequence as a guide. Done means ACP turns persist assistant content.part, step.end, and turn.ended events and those answers reappear when the session is resumed in the TUI.