feat(studio): fold variables into the design panel + summonable manager

[jrusso1020]

What

Retires the dedicated Variables tab and folds variable management into the Design panel, per Miguel's feedback ("variables doesn't need a new tab… can we modify them directly in the design panel"). Stacked on #2084.

Design rationale (adversarially reviewed)

Before building, I ran two design subagents — one attacking the "just fold it in" proposal, one steelmanning it. They converged on:

1. Drop the tab — creation + default-editing already live in the Design panel (the ◇ var promote pill / ◆ {id} bound chip), so the tab was a redundant second home.
2. The one real trap is losing bind-to-existing (define-once, bind-many). This PR avoids it by construction: the manager hosts the existing VariablesPanel unchanged, which still contains the "Bind selected" card.
3. Keep the "previewing N overrides" signal always visible — the trigger button carries it while the manager is closed.

How

• ◆ Variables trigger in the inspector header (VariablesManagerTrigger) opens an on-demand slide-over; accent-styled + count when preview overrides are active.
• VariablesManagerSlideOver — right-anchored overlay hosting VariablesPanel verbatim (declare / edit / remove / preview / handoff / other-comps / bind-to-existing). Closes on backdrop click or Esc.
• Bound ◆ chip in the Design panel is now clickable → opens the manager (manage-where-you-see-it).
• Tab removed from StudioRightPanel, RightPanelTab, and VALID_TABS; ?tab=variables deep links fall back to the default. Selection-outline logic that special-cased the old tab is simplified (the manager overlays the Design panel, so bounds already show).

Follow-up (deferred, not a regression)

Per-control "New variable / Bind to existing…" on the ◇ pill (bind-to-existing from the control itself) — the capability is preserved today via the manager's bind card; this would add locality. Left for a follow-up.

Testing

Full studio suite green (1423). Typecheck + lint + fallow + filesize gates pass. ⚠️ Live browser UX (slide-over layout, chip-opens-manager, override-signal accent) wants a human pass — agent-browser canvas-selection driving is unreliable in this repo.

🤖 Generated with Claude Code

[jrusso1020]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(studio): fold variables into the design panel + summonable manager #2101 👈 (View in Graphite)
• feat(core): aggregate template sub-comp variable defaults from the root div on the render path #2084
• feat(sdk,studio): editable template sub-compositions + promote sub-comp element properties #2081
• feat(studio): promote to variable from the design panel #2071
• feat(studio): bind selected element properties to variables #2055
• feat(core): declarative variable bindings — data-var-src, data-var-text, css custom props #2054
• fix(studio): code-review and live-test fixes for the variables stack #2052
• feat(studio): render with preview variables + template handoff + docs #2051
• feat(studio): variables inspector panel with live preview values #2050
• feat(studio-server): preview variable injection + render variables forwarding #2049
• feat(sdk): variable usage scan + preview-values adapter seam #2048
• feat(sdk): variable declaration edit ops (declare/update/remove) #2047
• feat(sdk): variable declaration read APIs + browser-safe variables entry #2046
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[miguel-heygen]

Re-reviewing the updated stack at 35f2b4527. The design direction is right: the permanent Variables tab is removed from the tab union (packages/studio/src/utils/studioHelpers.ts:16), stale tab=variables URLs now normalize away (packages/studio/src/utils/studioUrlState.ts:22), and the full manager becomes summonable from the Design surface instead of occupying a permanent tab (packages/studio/src/components/StudioRightPanel.tsx:507). Focused local coverage passes after building workspace deps: studioUrlState.test.ts + variablePromoteIntegration.test.ts = 15/15.

Blocker

• packages/studio/src/components/editor/PromotableControl.tsx:88 opens the Variables manager with only a global boolean, while the manager renders the right panel's sdkSession (packages/studio/src/components/StudioRightPanel.tsx:582, packages/studio/src/components/panels/VariablesManagerSlideOver.tsx:97). That session is the active/master composition session. But Design-panel promotion itself deliberately targets selection.sourceFile || activeCompPath || "index.html" (packages/studio/src/components/DesignPanelPromoteProvider.tsx:33) so selecting an element inside an inlined sub-composition edits the sub-comp file, not the host. Result: promote/bound-state works against compositions/card.html, then clicking the bound chip opens a manager for the host composition and the variable you just bound is missing or edits the wrong file. This regresses exactly the sub-composition variable workflow the stack adds. Fix shape: make the manager store/open carry a target path (or target session) and have the bound chip open it for the same selection.sourceFile session that VariablePromoteProvider uses; the header trigger can keep using the active/master target.

Important follow-ups still present from prior stack review

• packages/sdk/src/types.ts:457 still says getVariableValues() mirrors runtime getVariables() exactly, but the implementation is now intentionally per-file/per-declaration-element scoped. That is the right product model for Studio sessions, but the public hover docs should say that rather than promising bundled-document runtime parity.
• docs/concepts/compositions.mdx:134 and packages/lint/src/rules/composition.ts:671 still tell authors to declare variables on <html> only. The runtime/lint implementation now supports <html> plus template/fragment root divs, so these should be updated to avoid teaching the old model.

— Magi

Verdict: REQUEST CHANGES
Reasoning: The tab-removal/summonable-manager direction is good, but the manager currently opens the wrong composition session for selected sub-composition elements, breaking the core Design-panel variable flow until it carries the same target path as promotion.

[jrusso1020]

Thanks @miguel-heygen — all three addressed.

Blocker (manager opened the wrong session for sub-comp elements) — fixed. The manager store now carries a targetPath. The bound ◆ chip passes promote.targetPath (the same selection.sourceFile || activeCompPath resolution DesignPanelPromoteProvider/VariablePromoteProvider use), and the slide-over opens a dedicated session for it via useSdkSession, only while overriding (target set AND ≠ active comp). VariablesPanel gained a compPathOverride prop so its declarations, persist write-target, handoff command, and "other compositions" exclusion all key off that file. The header trigger passes no target → active/master, unchanged. The slide-over header now shows the targeted file path. Pure decision extracted as resolveManagerOverridePath + unit-tested (5 cases: closed / no-target / same-file / different-file / master-view).

Follow-up 1 — getVariableValues hover docs (#2046, types.ts). Rewrote the JSDoc to drop the "mirrors runtime getVariables() exactly" claim; it now states per-file/per-declaration-element scope explicitly and notes the two only diverge when sub-comp declarers are inlined into one bundled document.

Follow-up 2 — <html>-only guidance (#2081). docs/concepts/compositions.mdx and the unknown_variable_binding lint fixHint (packages/lint/src/rules/composition.ts) now say "the composition root — <html>, or the [data-composition-id] root element for a template/fragment comp."

Full studio suite green (1428). Live browser UX still wants a human pass (agent-browser canvas driving is unreliable here). Re-requesting review.

[jrusso1020]

Closing this — we're reverting to the dedicated Variables tab (#2050) rather than folding the overview into a summoned surface.

Rationale: the inline promote/edit in the Design panel (#2071 — the ◇ var pill / ◆ chip) already delivers Miguel's core ask ('modify variables directly in the design panel'). That stays. The overview/manage-all surface, though, is a browse-and-manage task that wants a persistent, roomy, discoverable home — a tab you opt into reads correctly whether empty or full, whereas a drawer/popover that appears mostly-empty (or dims the live preview) does not. So: keep inline editing in the Design panel; keep the tab as the roster. No net capability change vs. this PR; the sub-comp targeting and doc/JSDoc fixes from the review are preserved on #2046/#2081.