Integrate PR #556 (brand-refreshed onboarding) on top of main

[Kosinkadink]

Targeting the long-lived feat/brand-redesign branch, not main.

The brand refresh is a multi-PR effort (this integration + the auxiliary follow-ups listed at the bottom). To avoid landing a half-finished design on main, we collect all brand work on feat/brand-redesign and merge that branch into main once the full redesign is shipped. Bug fixes on main are pulled into feat/brand-redesign periodically via git merge origin/main.

Order of merging:

1. This PR → feat/brand-redesign (carries feat: redesign onboarding flow, install/progress screens, and shared design tokens #556 + reconciliation).
2. Follow-up PRs (TrackModal / LoadSnapshotModal / QuickInstallModal brand opt-in, then Settings + Detail, then Tier 2 progress trio, then chooser refresh) all target feat/brand-redesign.
3. Once everything's in, feat/brand-redesign → main as a single feature merge.
   Integration of feat: redesign onboarding flow, install/progress screens, and shared design tokens #556 (MaanilVerma/feat/redesign-launcher-screens) on top of current main. PR feat: redesign onboarding flow, install/progress screens, and shared design tokens #556 was branched from 0a7d6e3 (the smoke-test commit before feat(host): seamless in-place window-mode transitions + foundational cleanup #551 merged), so it had none of feat(host): seamless in-place window-mode transitions + foundational cleanup #551's renderer composable extractions or main-side host refactor. GitHub flagged it "not mergeable".

Strategy: merge origin/main into the PR branch in one shot — this kept the conflict surface to two files only (TitleBarApp.vue, PanelApp.vue) and let the reconciliation be done once on top of the new composable layout, instead of replaying the same drift across each of #556's 23 commits.

Reconciled files

src/renderer/src/comfyTitleBar/TitleBarApp.vue

• Kept feat(host): seamless in-place window-mode transitions + foundational cleanup #551's composable wiring intact (useTitleBarHoverGate, useTitleBarMenus, useTitleBarIdentity, useTitleBarTooltip, useUpdatePills).
• Applied feat: redesign onboarding flow, install/progress screens, and shared design tokens #556's brand pill on top: ComfyCLogo leading slot, fixed-width center pill (360px), --brand-surface-bg background, --comfy-yellow outline, three-slot layout (leading / center / trailing).
• Switched the title-bar background from var(--surface) to var(--titlebar-bg) so the new dark titlebar token applies.
• Extended the chrome-suppression gate to the full first-use takeover (consent-lockdown AND post-consent), not just consent-lockdown — waffle, downloads tray, and Send Feedback all stay hidden for the entire onboarding flow. Added an isFirstUseTakeover computed to useTitleBarIdentity to drive this; isConsentLockdown is preserved for the existing is-consent-lockdown header class.

src/renderer/src/panel/PanelApp.vue

• Kept feat(host): seamless in-place window-mode transitions + foundational cleanup #551's composable extraction intact (usePanelOverlays, useFirstUseChain, useChooserHandoff, useDeepLinkRouter, useAppUpdatePrompts, useSendFeedback) and the try / finally bootstrap guard.
• Wired feat: redesign onboarding flow, install/progress screens, and shared design tokens #556's name-step pre-seed: added pendingFirstUseInstName: Ref<string | null> to useFirstUseChain's API and exposed a consumePendingFirstUseInstName() reader on its hooks. usePanelOverlays.openFlowTakeover drains the ref when it opens the new-install Tier 3 takeover and forwards it as initialName to newInstallRef.open({ initialName }).
• Updated handleFirstUseChainLocal(payload?: { instName?: string }) to accept and stash the takeover's chain-local payload.
• Added :brand-chrome="chainingFirstUseToNewInstall" to the Tier 3 ProgressModal so the chained install's progress overlay opts into the brand wrapper. :hide-back-to-dashboard="chainingFirstUseToNewInstall" on <NewInstallModal> (already there post-feat(host): seamless in-place window-mode transitions + foundational cleanup #551) doubles as the brand-chrome gate inside NewInstallModal (see useBrandConfig in that file).

Verification

• pnpm run typecheck ✅
• pnpm run lint ✅
• pnpm run build ✅
• pnpm run test ✅ (937/937)
• pnpm exec playwright test --project=lifecycle ✅ (9/9)
• pnpm exec playwright test --project=windows ✅ (43/43)

Caveats / open questions

These are flagged for review but considered acceptable for landing per #556's authorial intent — please confirm:

• Forced dark theme during onboarding. BrandTakeoverLayout hard-codes data-theme="dark", so light-mode users get a forced theme flip across the takeover. PR feat: redesign onboarding flow, install/progress screens, and shared design tokens #556 commits indicate this is intentional ("light-mode brand parity is deferred").
• backdrop-filter: blur on --brand-surface-blur. Performance check on Linux Chromium under X11 / Wayland would be useful — historically backdrop-filter regresses there.
• CSS anchor positioning. BrandTakeoverLayout uses position-anchor / anchor() for the SVG plum beams, which requires Chromium ≥125 / Electron ≥28. Worth verifying the bundled Electron version and adding a @supports fallback if not.
• useMigrateAction silent variant pick. The Migrate-to-Standalone confirm modal no longer shows the device/variant card grid — it auto-picks the recommended variant. Confirm the modal's summary clearly tells the user which variant was picked. There is no "Show advanced" expansion to override; this would need a follow-up if requested.
• pendingFirstUseInstName on back-out. On Skip Onboarding mid-chain the ref is cleared by completeFirstUseAndDismiss. Worth a manual smoke of: takeover → name step → back arrow → re-enter Local fork → verify the new run starts blank rather than carrying the previous name. The consumePendingFirstUseInstName() hook design clears on read, so the second openFlowTakeover for new-install will start from null even without an explicit Skip — but this depends on FirstUseTakeover not auto-re-emitting the same payload after a back-out.

Auxiliary follow-ups (NOT in this PR)

The following surfaces visually drift away from the new brand language once #556 lands. Per #556's "Not in scope / follow-ups" section they're explicitly deferred. Tracking here so they don't get lost; suggested order is consistency-with-NewInstallModal first, then unified Settings, then Tier 2 progress overlays, then the chooser refresh as its own design pass:

1. Install-flow wizards opting into .modal-box--brand: views/TrackModal.vue, views/LoadSnapshotModal.vue, views/QuickInstallModal.vue — same Tier 3 install-flow class as NewInstallModal.
2. views/SettingsModal.vue + views/DetailModal.vue — Tier 1 unified settings; the frosted-overlay update on ModalDialog is already affecting the backdrop, but the box itself needs .modal-box--brand.
3. Tier 2 progress trio: components/RestoreModal.vue, components/SnapshotInspector.vue, components/SnapshotTab.vue, views/AppUpdateAction.vue — transient overlays; opt them in so they don't read as "old UI" on top of the brand chrome.
4. Chooser refresh as a separate design pass (views/ChooserView.vue, views/chooser/ChooserInstallTile.vue, views/chooser/chooser-tiles.css).

References: PR #556, PR #551 (7dfd109).