chore: Keep setup startup coordination out of the window

[hatayama]

Summary

• Keep setup startup auto-show and migration auto-scan behavior unchanged while moving the coordination code out of the setup window.
• Preserve the existing setup window UI mechanics and focus/open behavior.

User Impact

• Setup still auto-opens only for the same package, dispatcher, CLI, and skill-update conditions as before.
• Third-party migration auto-scan still runs only after the same V2-to-V3 startup signal.

Changes

• Add SetupWizardStartupFlow to coordinate startup auto-show, third-party migration auto-scan, version recording, and skill update checks.
• Keep window opening mechanics in SetupWizardWindow by injecting Action callbacks for version-change open and third-party auto-scan.
• Retarget setup startup source-text guards to scan both SetupWizardWindow.cs and SetupWizardStartupFlow.cs, so delay scheduling guards do not become vacuous after extraction.

Timing Invariants

• Editor startup still registers services before creating the startup flow, then registers the initial delayCall with startupFlow.TryShowOnVersionChange after the asset-import-worker and batch-mode guards.
• The flow still evaluates version state in the delayed callback, then sets the auto-scan session flag before registering the auto-scan delayCall.
• The setup window open callback is registered through delayCall only after ShouldAutoShowForVersion returns true.

Deviations

• SetupWizardStartupFlow has a private compatibility glue helper that calls CliSetupCompatibility.Evaluate with the injected CliSetupApplicationService minimum version. This avoids reaching back through SetupWizardWindow static service state from the extracted flow.
• ForceFlatSkillInstall was widened from private const to internal const because both the setup window UI flow and the extracted startup flow use the shared value; duplicating the value would be worse, and the window-side use remains in SetupWizardWindow.cs.
• Two parameterized static helpers gained argument precondition Debug.Assert checks as boundary contracts, matching the accepted CliPathSetupPrompt pattern.
• Four retargeted tests gained missing behavior comments so the moved assertions continue to satisfy the test comment rule.

Verification

• dist/darwin-arm64/uloop compile --project-path "$(git rev-parse --show-toplevel)"
• dist/darwin-arm64/uloop run-tests --project-path "$(git rev-parse --show-toplevel)" --test-mode EditMode --filter-type regex --filter-value "(SetupWizardWindowTests|OnionAssemblyDependencyTests)"
• After review fixes: dist/darwin-arm64/uloop compile --project-path "$(git rev-parse --show-toplevel)"
• After review fixes: dist/darwin-arm64/uloop run-tests --project-path "$(git rev-parse --show-toplevel)" --test-mode EditMode --filter-type regex --filter-value "(SetupWizardWindowTests|OnionAssemblyDependencyTests)"

[coderabbitai]

Warning

Review limit reached

@hatayama, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 24 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 2cca50c3-4868-4f5b-a1b5-eb36006bd586

📥 Commits

Reviewing files that changed from the base of the PR and between 28dd456 and 042c18f.

📒 Files selected for processing (3)

• Assets/Tests/Editor/OnionAssemblyDependencyTests.cs
• Assets/Tests/Editor/SetupWizardWindowTests.cs
• Packages/src/Editor/Presentation/Setup/SetupWizardWindow.cs

📝 Walkthrough

Walkthrough

Startup, version-change, auto-show, and third-party migration auto-scan decision logic previously implemented inline in SetupWizardWindow has been extracted into a new SetupWizardStartupFlow class. SetupWizardWindow now delegates these decisions and state recording via EditorApplication.delayCall, and tests were updated accordingly.

Changes

SetupWizardStartupFlow extraction

Layer / File(s)	Summary
Startup flow contract and construction Packages/src/Editor/Presentation/Setup/SetupWizardStartupFlow.cs	New class with injected dependencies, constructor validation, and version-separator configuration.
Auto-show and migration-scan decisions Packages/src/Editor/Presentation/Setup/SetupWizardStartupFlow.cs	Adds ShouldAutoShowForVersion, ShouldAutoScanThirdPartyToolMigration, MaybeMarkThirdPartyToolMigrationAutoScan, state-recording helpers, HasSkillUpdateForSetupWizard, and version-check entry points.
Async version-change evaluation flow Packages/src/Editor/Presentation/Setup/SetupWizardStartupFlow.cs	Implements the async EvaluateVersionChange flow, CLI compatibility checks, off-main-thread skill-update detection, and delayCall-based UI/scan scheduling.
SetupWizardWindow delegation and cleanup Packages/src/Editor/Presentation/Setup/SetupWizardWindow.cs	Wires SetupWizardStartupFlow into startup, delegates state recording, removes now-redundant local decision helpers and session-flags getter, and widens ForceFlatSkillInstall accessibility.
Test updates for delegated logic Assets/Tests/Editor/OnionAssemblyDependencyTests.cs, Assets/Tests/Editor/SetupWizardWindowTests.cs	Tests assert delayCall wiring through SetupWizardStartupFlow and route decision/state calls through it with explicit repository/port arguments.

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant EditorStartup
  participant SetupWizardWindow
  participant SetupWizardStartupFlow
  participant SkillDetection
  participant SetupWizardWindowUI

  EditorStartup->>SetupWizardWindow: InitializeForEditorStartup
  SetupWizardWindow->>SetupWizardStartupFlow: register TryShowOnVersionChange on delayCall
  SetupWizardStartupFlow->>SetupWizardStartupFlow: EvaluateVersionChange
  SetupWizardStartupFlow->>SetupWizardStartupFlow: NeedsCliUpdateForSetupWizardAsync
  SetupWizardStartupFlow->>SkillDetection: HasSkillUpdateForSetupWizardAsync (Task.Run)
  SkillDetection-->>SetupWizardStartupFlow: skill update result
  SetupWizardStartupFlow->>SetupWizardWindowUI: delayCall ShowWindowOnVersionChange
  SetupWizardStartupFlow->>SetupWizardWindowUI: delayCall ShowWindowForAutoScan

Loading

Possibly related PRs

• hatayama/unity-cli-loop#1277: Both PRs touch ShouldAutoShowForVersion and HasSkillUpdateForSetupWizard, which the main PR relocates into SetupWizardStartupFlow.
• hatayama/unity-cli-loop#1420: Both PRs modify the auto-show/last-seen decision logic involving dispatcher minimum version comparison, moved here into SetupWizardStartupFlow.
• hatayama/unity-cli-loop#1376: Both PRs touch the third-party migration auto-scan path, with the main PR rerouting scheduling through SetupWizardStartupFlow.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title accurately summarizes the main change: extracting setup startup coordination out of the window.
Description check	✅ Passed	The description is clearly related to the changeset and matches the extracted startup flow behavior.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/c4-12-extract-setup-startup-flow

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

1 issue found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="Packages/src/Editor/Presentation/Setup/SetupWizardStartupFlow.cs">

<violation number="1" location="Packages/src/Editor/Presentation/Setup/SetupWizardStartupFlow.cs:290">
P2: The extracted `SetupWizardStartupFlow` still depends on `SetupWizardWindow.ForceFlatSkillInstall`, which couples non-UI startup coordination back to the UI window class. This undermines the PR goal of keeping startup coordination out of the window. Consider injecting `forceFlatSkillInstall` through the constructor (consistent with the existing `Action` callback injection pattern) or moving the constant to shared configuration so `SetupWizardStartupFlow` does not reference `SetupWizardWindow`.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: The extracted SetupWizardStartupFlow still depends on SetupWizardWindow.ForceFlatSkillInstall, which couples non-UI startup coordination back to the UI window class. This undermines the PR goal of keeping startup coordination out of the window. Consider injecting forceFlatSkillInstall through the constructor (consistent with the existing Action callback injection pattern) or moving the constant to shared configuration so SetupWizardStartupFlow does not reference SetupWizardWindow.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At Packages/src/Editor/Presentation/Setup/SetupWizardStartupFlow.cs, line 290:

<comment>The extracted `SetupWizardStartupFlow` still depends on `SetupWizardWindow.ForceFlatSkillInstall`, which couples non-UI startup coordination back to the UI window class. This undermines the PR goal of keeping startup coordination out of the window. Consider injecting `forceFlatSkillInstall` through the constructor (consistent with the existing `Action` callback injection pattern) or moving the constant to shared configuration so `SetupWizardStartupFlow` does not reference `SetupWizardWindow`.</comment>

<file context>
@@ -0,0 +1,311 @@
+            List<SkillSetupTargetInfo> targets = await Task.Run(
+                () => _skillSetupUseCase.DetectSkillTargetsForLayoutAtProjectRoot(
+                    projectRoot,
+                    !SetupWizardWindow.ForceFlatSkillInstall),
+                ct);
+            if (ct.IsCancellationRequested)
</file context>