V0.5+: support /fork, /rename, /rewind slash commands

[yyq1025]

Summary

V0 ships a hardcoded slash-command whitelist of 5 commands (/init, /review, /clear, /compact, /model). V0.5+ should extend to /fork, /rename, /rewind — all three are in Claude Desktop's curated in-session picker (Anthropic's product team treats them as session-context essentials).

Per-command design notes

/rename

Difficulty: low. Scaffolding already in packages/daemon/src/sidecode-sessions.ts:

• title: string + titleSource: "auto" | "user" fields persisted per session
• File header explicitly anticipates V0.5+ /rename and locks the auto-title path once titleSource === "user" is set

Real design question is the desktop-mirror UX:

Option	Behavior	Trade-off
(a)	/rename only on sidecode-owned sessions; desktop-mirror rows hide/disable the rename affordance	Preserves V0 invariant "never touch Desktop's session storage"; zero new metadata namespace
(b)	Add a "title override" side-table keyed by sessionId; desktop-mirror titles shadowed in sidecode UI only	Full parity; new namespace; potential confusion when Desktop's own /rename lands

Recommend (a) for V0.5+. Revisit (b) if user feedback demands it.

/fork

Difficulty: medium-high. Source: claude-code/src/commands/fork/index.ts (type:'local'). Fork = new conversation seeded from a parent transcript at a chosen point.

• Owned session: copy SDK session.jsonl up to fork point, spawn new SDK session via resume + replay, link parent_id in metadata
• Mirror session: natural UX is "convert to sidecode-owned via fork" — read Desktop's session.jsonl, replay into a fresh SDK session, drop a sidecode metadata file pointing at it

Investigate Claude Code's fork implementation before committing to a seeding strategy (likely SDK --resume + --replay-user-messages or equivalent).

/rewind

Difficulty: medium. Source: claude-code/src/commands/rewind/index.ts (type:'local'). Rewind = restore conversation (and/or code) to a previous point.

• Owned session: truncate transcript at point, re-init SDK at the truncated state
• Mirror session: V0 invariant blocks Desktop transcript mutation → natural UX is "fork at chosen point" which produces an owned child whose tail is the rewound state. Rewind-on-mirror = fork-at-point, no extra mechanism.

V0.5+ scope: conversation rewind only. Claude Code's /rewind can also restore filesystem state via git/backup — defer that to V1+.

Open design questions

• Should /fork and /rewind on desktop-mirror sessions auto-promote to a sidecode-owned copy without asking?
• Do we need a separate "convert this session to sidecode-owned" affordance, distinct from fork?
• Should rename Option (b) be revisited if users immediately complain about (a)?

Picker integration

Once shipped, extend packages/protocol/src/slash-commands.ts (created in the V0 slash whitelist PR):

Command	Contexts	Handling
/rename	in-session	intercept (mutates sidecode metadata only, no SDK call)
/fork	in-session	intercept (sidecode-side conversation duplication)
/rewind	in-session	intercept (sidecode-side truncate + re-init)

All three are intercept-handling because they touch sidecode's persistence layer, not the SDK conversation API directly.