Remove dead FirstMeeting onboarding flow

[devin-ai-integration]

Summary

The FirstMeeting/ onboarding flow (FirstMeetingFlowView and its 9 child views) is dead code — FirstMeetingFlowView is never instantiated anywhere in the codebase. The active onboarding uses OnboardingFlowView with a completely different step sequence (WakeUp → APIKey → APIKeyEntry → ImproveExperience). This PR deletes the unreachable code and cleans up associated state.

Why this is safe to remove — git history evidence

The FirstMeeting flow was an experimental variant that lasted ~1 day before being deliberately disconnected. The files were never reconnected.

Date	Commit	What happened
Feb 12	7738d6efe (#1350)	FirstMeetingFlowView added, wired into OnboardingWindow via variant routing (if state.onboardingVariant == .firstMeeting)
Feb 12–13	#1352–#1356	Child views built out (CapabilitiesBriefing, Observation, Egg/Hatch, Introduction)
Feb 13	1b2c0bdc0 (#1405)	"Remove onboarding variant picker and fix card centering" — deliberately removed variant routing from OnboardingWindow, making FirstMeetingFlowView unreachable. Commit message: "simplify onboarding to use only the default flow."
Feb 13 – present	Multiple PRs	Onboarding redesigned 3+ times (avatar evolution #4682, managed sign-in #16668, API key redesign #17344). FirstMeeting files never reconnected — only received mechanical changes (color token migrations, icon swaps, preview removals).

What changed

Deleted (10 files, ~1,660 lines):

• FirstMeetingFlowView, FirstMeetingEggView, FirstMeetingHatchView
• FirstMeetingIntroductionView, FirstMeetingIntroductionViewModel
• CapabilitiesBriefingView, CapabilitiesModalView
• ObservationModeView, ObservationSessionView, ObservationSummaryView

Kept (2 files in FirstMeeting/):

• JITPermissionManager.swift — actively used by MainWindowView
• JITPermissionView.swift — actively used by MainWindowView

Cleaned up in OnboardingState.swift:

• Removed OnboardingVariant enum (.default / .firstMeeting)
• Removed 7 first-meeting-specific properties (firstMeetingCrackProgress, conversationCompleted, capabilitiesBriefingShown, observationCompleted, firstTaskCandidate, observationDurationMinutes, observationInsights)
• Removed variant-based branching in crackProgress, init(), and persist()
• Simplified step clamping to a constant maxStep = 3
• clearPersistedState() still removes the old onboarding.variant and onboarding.firstMeetingCrackProgress keys so they get cleaned up on logout/retire

Review & Testing Checklist for Human

• Verify step clamping simplification — The old code checked MacOSClientFeatureFlagManager.shared.isEnabled("managed_sign_in_enabled") before falling through to maxStep = 3. Both managed and non-managed paths already resolved to maxStep = 3; only the now-deleted firstMeeting variant had maxStep = 4. Confirm let maxStep = 3 is equivalent in all flag states.
• Build in Xcode — Swift-only changes, cannot verify compilation on Linux.
• Spot-check onboarding — Run through the active flow (WakeUp → APIKey → APIKeyEntry → ImproveExperience → hatching) to confirm no regressions.
• Verify JIT permission flow — JITPermissionManager and JITPermissionView were kept. Confirm the JIT permission overlay in MainWindowView still works.

Test plan: Launch the app → trigger onboarding → complete all steps through to hatching. Separately, trigger a JIT permission prompt (e.g. accessibility) to verify the overlay still appears.

Notes

• clearPersistedState() retains the old onboarding.variant and onboarding.firstMeetingCrackProgress keys in its cleanup list so any orphaned UserDefaults values are removed on logout/retire. persist() no longer writes them.
• This was originally scoped as a VModal migration for CapabilitiesModalView (LUM-282), but investigation revealed the view is unreachable. Issue updated to Won't Do.

Link to Devin session: https://app.devin.ai/sessions/771fad2a97c547ee91fb8306e99a216f
Requested by: @ashleeradka

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[linear]

LUM-282 Migrate CapabilitiesModalView to use VModal

Context

Sub-issue of LUM-276 (lower priority). Migrate CapabilitiesModalView to use the shared VModal component.

File: clients/macos/vellum-assistant/Features/Onboarding/FirstMeeting/CapabilitiesModalView.swift

Current State

• Uses Meadow/material background (.ultraThinMaterial + Meadow.panelBackground) instead of standard VColor.surfaceOverlay
• No header with title/close button
• Single "Got it" VButton as footer
• Uses @Environment(\.dismiss) for dismiss
• 400x480pt frame with VRadius.xl corner radius
• Onboarding-only view (specialized context)

Considerations

• This view has a unique visual style (Meadow theme) that may intentionally differ from standard modals
• VModal may need to support custom background overrides, or this view may be an exception

Acceptance Criteria

• Replace hand-rolled chrome with VModal where appropriate
• Determine if Meadow background should be preserved or standardized
• Add proper header with close button if appropriate for onboarding context
• Preserve all capability sections content
• No visual regressions
• Verify visually after migration

---

Summary: Migrate the onboarding CapabilitiesModalView to the shared VModal component while preserving its current layout and verifying visual parity.

Key Context:

• Current view uses a Meadow/material-styled background (.ultraThinMaterial + Meadow.panelBackground) instead of VColor.surfaceOverlay; decide whether to preserve this or standardize.
• Modal chrome is currently custom (no header/title/close), with a single “Got it” footer button and dismissal via @Environment(\.dismiss).
• Fixed sizing/styling today: 400×480pt frame and VRadius.xl corner radius; ensure no regressions after migration.

✨ Generated by Linear Issue Context Agent

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

[devin-ai-integration]

Closing this PR — CapabilitiesModalView is dead code. FirstMeetingFlowView (the only consumer) is never instantiated anywhere in the codebase. The current onboarding flow (OnboardingFlowView) uses a completely different step sequence (WakeUp → APIKey → APIKeyEntry → ImproveExperience) that doesn't include the capabilities briefing step.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 2 additional findings in Devin Review.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 2 additional findings in Devin Review.

[devin-ai-integration]

Git History Evidence: Why These Files Are Dead Code

The FirstMeeting/ flow was an experimental onboarding variant that lasted ~1 day before being deliberately disconnected. The files were never cleaned up.

Timeline

Date	Commit	What happened
Feb 12, 2026	7738d6efe (#1350)	FirstMeetingFlowView added and wired into OnboardingWindow via variant routing (if state.onboardingVariant == .firstMeeting)
Feb 12, 2026	#1352–#1356	Child views built out: CapabilitiesBriefing, Observation, Egg/Hatch, Introduction
Feb 13, 2026	1b2c0bdc0 (#1405)	"Remove onboarding variant picker and fix card centering" — explicitly removed the FirstMeetingFlowView routing from OnboardingWindow, simplifying to default-only flow. Commit message: "simplify onboarding to use only the default flow."
Feb 13 – present	Multiple PRs	Onboarding redesigned multiple times (managed sign-in, API key flow, avatar evolution). FirstMeeting files never reconnected.

Key Evidence

• Commit 1b2c0bdc0 is the smoking gun — it deliberately removed the variant routing that was the only way to reach FirstMeetingFlowView. After this commit, FirstMeetingFlowView was never instantiated again.
• After the variant was removed, the onboarding was redesigned at least 3 more times (avatar evolution in feat: avatar evolution during onboarding #4682, managed sign-in in feat: implement managed sign-in setup flow for onboarding #16668, API key redesign in feat: redesign onboarding hosting selector with Coming Soon states and conditional API key entry #17344), each moving further from the FirstMeeting design.
• The files continued to receive only mechanical/automated changes (color token migrations, icon library swaps, preview block removals) — no one was developing this flow.

Kept Files

• JITPermissionManager.swift and JITPermissionView.swift are still actively used by MainWindowView for just-in-time permission prompts.