Proposal: a small internal registry for right-panel surfaces, piloted by moving Diff with no visible change

[saphid]

Problem

Each right-panel surface (Diff, Preview, Device, Files) is mounted by its own hand-written branch in ChatView. To add, replace or move a panel, you edit a ~9k-line component and copy its lazy-load, title and tab wiring. Forks that want a different panel carry invasive patches to it.

Proposed direction

• Internal static panel registry. It is first-party and build-time only: { id, title, placement: "side-panel", load: () => import(literal) }. Duplicate ids are rejected, and panels render through React.lazy under the existing Suspense. No runtime loading, persistence, RPC or package.
• Diff moves first, with zero visible change. The panel moves unchanged. Stores, keys, entry points, queries, CSP/IPC and mobile stay as they are. Its unused shell modes are removed.
• Then one panel per PR. Each PR moves one existing panel onto the registry and deletes its bespoke mount.
• No SDK, installer or remote code loading unless a client-isolation design is approved separately.

What we're asking you to decide

1. Would you accept a static, first-party panel registry in apps/web?
2. If yes, is Diff the right first panel, and is a no-visible-change move an acceptable first PR?
3. Should the pilot be approved only together with a named second panel? The seam only pays off once a second panel uses it.
4. Anything to exclude or change first?

If the answer is no, we drop the pilot and it stays unmerged.

Evidence (pilot built locally, no PR)

• Size. One commit on current main: 10 files, +329/−113 including tests, +16 net production lines. No store, contract, server, mobile, CSP or IPC changes.
• Parity. Before/after production builds were compared on one isolated backend. Folds, ref picker, context expansion, a 6,000-line virtualized diff, lazy-patch retry and the narrow sheet are pixel-identical. Request records are byte-equivalent, with at most 4 concurrent patch reads and the same renders per streaming tick in both builds.
• Live provider. Real Claude turns ran on both builds, and all 8 checks passed. A populated turn shows its diff. Revert-with-files restores the tree and the panel updates. A Diff line comment reaches the sent message. Electron chrome shows 0 differing pixels in the Diff panel.
• Tests. 247 focused tests pass. New tests cover the registry lifecycle and environment isolation for a shared thread id.
• Not yet verified. Relay/tunnel file actions, and a native mobile screenshot (mobile code is untouched).

Media will be uploaded to GitHub and linked here.

What we will NOT do

• No third-party, installable or remotely loaded panel code, and no blob: or CSP changes.
• No SDK package, schema catalogue or second persistence layer.
• No duplicate implementations: panels are moved, never copied.
• No layered PR stacks. Each PR covers one panel and can be reverted on its own.
• No PR until this discussion has an explicit answer.

🤖 Generated with Claude Code

[saphid]

The concrete pilot for this proposal is now open: #15010 — refactor(web): register the Diff side panel.

• Zero visible change: Diff moves behind a small internal, static registration point; the native implementation and its bespoke mount are deleted in the same change (moved, not duplicated). +16 net production lines, one commit.
• Before/after evidence against upstream main (captured before a clean rebase; focused checks re-run after it): live Claude turn Diff, sent review comment, checkpoint file restoration, and built Electron chrome (8/8 checks), plus focused tests, typecheck, build and Release Smoke.
• If the direction is acceptable, later panels would follow one per PR, each deleting its native code as it moves. If not, the PR can simply be closed; nothing else depends on it.

[saphid]

Updated proposal (replaces the four questions above).

We opened #15010 before getting an answer here, against what this post said. We did that so you can judge real code and before/after evidence rather than a sketch. Here is what we're asking you to approve:

Accept a static, first-party panel registry in apps/web, landed as two PRs:

1. refactor(web): register the Diff side panel #15010: Diff moves onto the registry. No visible change, +16 net production lines, one commit. Diff's bespoke mount in ChatView is deleted in the same change. Before/after evidence covers a live Claude turn, review comments, checkpoint revert and the Electron window frame (8/8 checks). CI is green.
2. Preview next. It's the same mechanical move: Preview's lazy import and bespoke mount come out of ChatView. That second panel is where the registry starts paying for itself. We'll open it within a few days of approval.

Scope stays fixed: no SDK, no runtime or remote loading, no third-party panels, no CSP/IPC or persistence changes, one panel per PR, and every PR can be reverted on its own.

Prior discussion: this is the internal panel host proposed in #1377 ("Could be cool, if you have a clear idea how you'd do it feel free to send a draft PoC"), with the same goal as splitting ChatView (#830). #15010 is that PoC, starting with Diff. Third-party extension ideas (#6837, #6977, #6714) stay out of scope here; this registry is first-party and build-time only.

What we need from you: approval of this direction and scope, or a "no". If it's no, we close #15010 and stop here.

[saphid]

The whole panel host is now open as a stack of ready PRs.

Instead of waiting for an answer on the pilot, we finished the work so you can judge all of it. Each PR moves one surface onto the registry from #15010 or fixes one bug found along the way. Each was tested at its own head, reviewed, and has before/after captures on web and desktop, plus a remote --share pass where the change crosses the wire. GitHub can't stack PRs from a fork, so each PR targets main and includes the commits below it. Each body says which commit to review.

Order	PR	What it does
1	#15010	Registers the Diff side panel (the pilot, no visible change).
2	#16038	Registers the Preview side panel. The registered panels describe their own launcher entries (no visible change).
3	#16039	Opens the right-panel terminal through the panel host.
4	#16040	Fix: device results stay in the thread that started them. Applies to main on its own.
5	#16041	Opens the Device side panel through the panel host.
6	#16042	Opens the pull request side panels through the panel host.
7	#16043	Opens the Files side panel through the panel host. CONTRIBUTING names Files-as-a-tab as needing product approval, so it is a separate PR.
8	#16044	Fix: a pending Files action stays with the visit that started it. A late Add to chat no longer lands in another thread's composer, and a browser the server opened shows in its own thread.

Stores, keybindings, storage keys, server, contracts and mobile are unchanged throughout. The two fixes (#16040, #16044) are useful on their own if you'd rather not take the host. If the answer to the proposal is no, we'll close #16038–#16043 and keep only what you want.

The plugin system that builds on this (plugin views as right-panel tabs) is listed on #6837.