[Feature]: Internal panel host for first-party panel composition

[gmackie]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

ChatView.tsx is the largest component in the web app (#830 tracks splitting it). Right now, adding a new panel or sidebar section — like a planning workbench or browser preview — requires editing ChatView directly, wiring up state, and coordinating layout concerns in one place.

This makes the codebase harder to maintain and harder to split, because every panel is tightly coupled to the root layout.

Proposed solution

A small, internal-only panel host that lets first-party panels register themselves declaratively. Each panel declares which slot it renders into (e.g., right panel) and the host resolves and renders them with error boundary isolation.

Concretely:

• A SidePanelHost component that wraps panel content with an error boundary
• A panelRegistry.ts where first-party panels register their slot, label, and render function
• Existing panels migrated to register through the host instead of being hardcoded in ChatView

No external plugin API. No dynamic loading. No SDK. Just a registry pattern that decouples panel code from layout code.

Why this matters

This directly unblocks the ChatView decomposition tracked in #830. It also makes it structurally easier to add, remove, or rearrange first-party panels without touching layout code. The benefit is maintainability and separation of concerns for the existing codebase.

Smallest useful scope

A first pass only needs to cover the right-panel slot (where the plan sidebar already lives). Sidebar sections and header actions can follow later. The registry is a plain TypeScript map — no runtime discovery, no dynamic imports, no external API surface.

Alternatives considered

1. Manual decomposition of ChatView without a registry — works, but every new panel still requires editing the layout component directly.
2. A full plugin system with external API surface — significantly larger scope, and the project is not ready for that kind of commitment yet.

Risks or tradeoffs

• Adds a small layer of indirection. If the team prefers direct composition, this is not worth it.
• Must not become a public API or expand into external extensibility without an explicit decision to do so.

Contribution

• I would be open to helping implement this.

[gmackie]

For context — this is a different angle from the component extraction approach in #985 / #860. Ymit24 found that pulling components out of ChatView was harder than expected because the hooks and callbacks are tightly intertwined. A declarative registry sidesteps that: each panel owns its own state and renders from a context object, so there's no need to thread ChatView's internal state through as props. The panel host just resolves which panel to render and wraps it in an error boundary.

I kept this intentionally narrow — the smallest useful version is wrapping the existing PlanSidebar in an error boundary host. Happy to start there if the direction seems right.

[juliusmarminge]

Could be cool, if you have a clear idea how you'd do it feel free to send a draft PoC.

I guess it would allow for a more configurable layout as well? (Like having terminal drawer "register" itself to the right of the chat view. Or am i misunderstanding your idea here?