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.