Proposal: expose existing session relationships in kimi vis

What feature would you like to see?

Motivation

kimi vis currently answers one question well:

How did an agent run (in a single session)?

But a user managing many sessions keeps hitting a different set of questions that the trace view doesn't address:

• Which session should I resume? — a session id alone doesn't say where work stopped or whether the last step succeeded.
• Where did two branches diverge? — sessions can be forked, but their relationship is never shown.
• What changed between two attempts? — when you retry an approach, the difference is rarely the text; it's the strategy path (which tools, which prompts).

This feature request is about exposing data kimi-code already persists to answer those questions — not about building new UI for its own sake.

Proposed views

Three views, scoped from smallest to largest. I'd suggest treating them as sub-features of one effort rather than three independent ones.

1. Resume card

Today, picking a session to resume looks at a flat list of ids. A resume card turns each session's last TodoWrite snapshot into a quick status read — done / in-progress / pending — so the choice is obvious:

session_a1b2c3d4  Refactor auth module  (2026-07-28 22:25)
──────────────────────────────────────────────────────────
  ✔  Set up the new route scaffolding
  ✔  Migrate users table schema
  ⧗  Write integration tests for login flow
  ○  Update the API client error handling
  ○  Update the docs and changelog
  ○  Open a PR for review
──────────────────────────────────────────────────────────
  6 tasks: 2 done · 1 active · 3 pending

In agent-CLI terms, this promotes a session from a "history entry" to a "resumable task state".

2. Fork tree

Sessions already record their lineage, but it's never rendered as a relationship. A fork tree surfaces parent-child links so branching becomes navigable instead of invisible.

3. Session comparison

When retrying an approach, what differs between two sessions is usually the trajectory — which prompts were issued, which tools were called — rather than raw text. A first version wouldn't need a full AST diff; it could start by showing prompt divergence and tool trajectory differences side by side.

Additional information

Implementation notes — I've verified all three are derivable from the current on-disk format (protocol 1.4). Nothing here requires new persisted data:

• Resume card — tools.update_store records with key === 'todo' (last-wins, full snapshot). Already modeled by @moonshot-ai/transcript's TranscriptTodo / TodoStatus and reconstructed by foldWireRecordFacts.
• Fork tree — state.json carries forkedFrom (from fork()) and custom.parent_session_id / custom.child_session_kind (from createChildSession()); wire journals carry the {type: 'forked'} boundary. SessionListQuery even has a childOf filter. But kimi vis's SessionRail is a flat list — it never surfaces these links.
• Session comparison — prompts from turn.prompt (with origin.kind === 'user'); tool calls from context.append_loop_event. Forked siblings share an identical wire prefix up to the {type: 'forked'} marker, giving a natural divergence anchor.

One caveat: forkedFrom and parent_session_id are only populated when a session is actually forked/child-created, so the fork tree is empty until users exercise /fork.

Happy to scope a PR. I'd lean toward starting with the resume card — it's a pure presentation change over already-reconstructed transcript data, with the smallest surface area.

Start with the flat SessionRail and the existing SessionListQuery, then trace resume data from tools.update_store through foldWireRecordFacts and TranscriptTodo. Begin by agreeing on the resume-card scope; done means the selected session exposes its todo status, with fork relationships and session comparison treated as separate follow-up views.