Two laptops, one feature

Andreea was building a dashboard feature that matches a plain-language request to an existing request template, so users can pick a template instead of generating a new request from scratch. Her planning session in Claude Code wrote the issues (#966 for per-feature AI controls, #967 for template matching). A separate implementation session produced PR #971, then ended.

Nico picked the work up on his own laptop. His job was to review the experience and simplify it.

The PR offered a toggle: match a template, or generate from scratch. Nico wanted one text box that tries matching first and falls back to generation only if nothing fits or the user declines. Before changing anything, he needed answers the diff couldn’t give:

• → Intent. Issue #967 called for a “match first” checkbox, on by default. The toggle appeared during implementation. Was it a deliberate decision or drift?
• → Gating. Matching sat behind per-feature AI controls, and those gates had already broken the tests once. Which gate was load-bearing?
• → Test noise. Two AWS tests were failing. Did this branch cause them?
• → Ownership. Who makes the next change, and which session can answer questions about the plan, now that the implementation session is gone?

The answers existed, spread across three sessions on another laptop. Nico’s agent had the branch and the diff. Without a way to read those sessions, the usual options look like this:

• → Ask for a handoff note. Andreea stops her own work and reconstructs the plan, the test fixes and the baseline from memory. Details like the nil-pipeline stub are the first thing to drop out.
• → Review the diff cold. Nico either keeps the toggle because it looks deliberate, or removes it without knowing the plan already said “match first”. While simplifying, it’s easy to delete the request_generate gate along with the toggle.
• → Chase the red tests. Re-run the suite on main to find out whether the two AWS failures are new: time spent on a problem that wasn’t his.
• → Feedback goes nowhere live. A PR comment isn’t read by any running agent. Andreea copies it into a session, the reply comes back over Slack, and nobody says explicitly who edits the branch, so both might.

Andreea had enabled history sharing with a five-day window. Nico’s agent used Rhizome to find her sessions and read their recorded activity, without asking her for anything.

1. 01 Find the right sessions. search_sessions on the paired host turned up three distinct sessions for the feature: planning, a baseline test run, and the implementation run from 18:06 to 18:39 UTC. Same repo, different jobs.
2. 02 Read the history behind the PR. read_session_history answered the questions from the challenge. The plan said checkbox and the build said toggle; no reason was recorded, so the agent flagged the mismatch instead of inventing one. Matching tests had first failed because aiFeatureEnabled returned false when aiPipeline was nil; a stub pipeline fixed it and 17 tests passed. The baseline run showed the AWS failures predated the feature.
3. 03 Send one concrete proposal. The planning session was still running, so Nico’s agent used send to address it directly rather than broadcasting: remove the toggle, call match-templates first, offer “Use this template” or “No, create it from scratch”, keep request_generate as the gate for fallback generation, update the docs.
4. 04 Get an explicit handoff. Andreea’s session replied that Nico should apply the change himself on the PR branch, and that it wouldn’t touch the branch. It also flagged that issue #967 still described the checkbox flow.

• → One input, match first. The simplified flow landed on the existing PR in b0d8ce62, touching source-selection.tsx and docs/request-templates.md.
• → Gating intact. Fallback generation stayed behind request_generate.
• → CI green. CI rejected a package-level knownAIFeatures variable; 367f1145 turned it into a function and every check then reported passing.
• → Still open. Reviewer approval and a manual dashboard walkthrough. The PR had not been merged at the time of writing.

• → History reads failed at first. Early reads returned CATALOG_INCOMPATIBLE. By 20:43 UTC reads through Andreea’s host worked while local reads still failed, which pointed at two separate catalogs.
• → Seeing a session isn’t the same as reaching it. Andreea’s replies were rejected with “remote gateway request rejected” until Nico’s session went from observable to live, at 20:24 UTC. A successful send means queued, not read.
• → History is partial by design. It carries assistant text and activity summaries, not user prompts, private reasoning or raw tool output. A reported test pass is context, not verification.
• → No time measured. We didn’t measure time saved.

The PR stayed the place where the code was reviewed. Rhizome made the sessions behind it readable.

1. 01 Pick a feature that already spans two sessions, ideally on two machines. Install Rhizome on both and pair them.
2. 02 Have the owner turn on history sharing with a short window, only if they want to share it.
3. 03 From the reviewing session, ask your agent to find the work and say what it knows and what it doesn’t.
4. 04 Send one concrete question or proposal to the session that can answer it. Agree who edits, and keep your normal branch, tests and review.

Find the sessions on <teammate>'s machine that planned and built <feature>.
Read their history and tell me: what was planned, what changed during
implementation, which test failures predate the work, and what's still unclear.