chore: Move editor readiness policy into Domain

[hatayama]

Summary

• Move the pure editor-state readiness decision into the Domain layer.
• Keep the Application guard as the adapter that preserves existing tool busy exceptions.

User Impact

• No user-facing behavior changes.
• Tool busy responses for Unity compile and asset database updates keep the same payload shape.

Changes

• Add ToolExecutionEditorReadyPolicy with decision DTOs in Domain.
• Keep UnityCliLoopEditorStateGuard in Application as the exception adapter.
• Retarget editor-ready tests to assert Domain policy decisions.

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 "io.github.hatayama.UnityCliLoop.Tests.Editor.ToolExecutionEditorReadyPolicyTests.*"
• dist/darwin-arm64/uloop run-tests --project-path "$(git rev-parse --show-toplevel)" --test-mode EditMode --filter-type regex --filter-value "io.github.hatayama.UnityCliLoop.Tests.Editor.UnityCliLoopToolExecutionServiceTests.*"

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 10 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: a3cadc5e-9a84-4cfa-9d2a-e214de54b2f2

📥 Commits

Reviewing files that changed from the base of the PR and between 7cedae3 and 530773b.

📒 Files selected for processing (1)

• Packages/src/Editor/Application/UnityCliLoopEditorStateGuard.cs

📝 Walkthrough

Walkthrough

A new ToolExecutionEditorReadyPolicy class was introduced in the Domain layer to evaluate editor readiness for tool execution based on compiling/updating/playing/paused state. UnityCliLoopEditorStateGuard.ValidateForState was refactored to delegate to this policy instead of inline guard logic. Old guard-level tests were removed and replaced with policy-level tests.

Changes

Editor-readiness policy extraction

Layer / File(s)	Summary
Policy contracts and evaluation logic Packages/src/Editor/Domain/ToolExecutionEditorReadyPolicy.cs	Introduces ToolExecutionEditorReadyPolicy with operation-name constants, GuardCondition enum, Evaluate/GetCondition logic, and immutable ToolExecutionEditorState/ToolExecutionEditorReadyDecision types.
Guard refactor to consume policy Packages/src/Editor/Application/UnityCliLoopEditorStateGuard.cs	ValidateForState builds a ToolExecutionEditorState, calls the policy, and throws UnityCliLoopToolBusyException from the returned decision, removing prior inline branching.
Policy tests replacing guard tests Assets/Tests/Editor/ToolExecutionEditorReadyPolicyTests.cs, Assets/Tests/Editor/UnityCliLoopEditorStateGuardTests.cs	Adds NUnit tests for compile-busy, asset-update-busy, and read-only ready-decision scenarios against the new policy; removes the previous guard-level test file.

Estimated code review effort: 2 (Simple) | ~15 minutes

Possibly related PRs

• hatayama/unity-cli-loop#1164: Builds on the same guard/exception behavior that this PR delegates to the new readiness policy.
• hatayama/unity-cli-loop#1215: Aligns with the busy-error translation and tool-name assertions now driven by the policy decision.
• hatayama/unity-cli-loop#1528: Introduced passing isPlaying/isPaused into the guard, which this PR's policy now consumes directly.

🚥 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 clearly summarizes the main change: moving the editor readiness policy into Domain.
Description check	✅ Passed	The description matches the changeset and accurately describes the Domain policy move and Application adapter.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/c5-2-editor-ready-policy

---

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.}

[coderabbitai]

🧹 Nitpick comments (1)

Packages/src/Editor/Application/UnityCliLoopEditorStateGuard.cs (1)

24-48: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider a guard-level test for the exception mapping.

The delegation itself is correct — ToolExecutionEditorState field order matches the constructor, and UnityCliLoopToolBusyException parameter order matches decision.RunningOperationName/RequestedToolName/IsPlaying/IsPaused. However, the previous UnityCliLoopEditorStateGuardTests.cs was removed and replaced entirely with policy-level tests, so there's no longer a test asserting that ValidateForState actually throws UnityCliLoopToolBusyException with the correct fields (or returns normally when ready). This adapter mapping is the actual externally-observable contract; a future edit to field order/wiring here wouldn't be caught by the policy tests alone.

Consider adding a small guard-level test (e.g., using a fake IEditorRuntimeStatePort) that verifies the busy/ready outcomes end-to-end.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Packages/src/Editor/Application/UnityCliLoopEditorStateGuard.cs` around lines
24 - 48, Add a guard-level test for
UnityCliLoopEditorStateGuard.ValidateForState to cover the adapter contract
end-to-end. The current policy tests do not verify that ValidateForState returns
normally when ToolExecutionEditorReadyPolicy says ready, or that it throws
UnityCliLoopToolBusyException with the correct RunningOperationName,
RequestedToolName, IsPlaying, and IsPaused values when busy. Use the existing
UnityCliLoopEditorStateGuard and UnityCliLoopToolBusyException symbols to add a
small test (ideally via a fake IEditorRuntimeStatePort) that exercises both
ready and busy outcomes.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@Packages/src/Editor/Application/UnityCliLoopEditorStateGuard.cs`:
- Around line 24-48: Add a guard-level test for
UnityCliLoopEditorStateGuard.ValidateForState to cover the adapter contract
end-to-end. The current policy tests do not verify that ValidateForState returns
normally when ToolExecutionEditorReadyPolicy says ready, or that it throws
UnityCliLoopToolBusyException with the correct RunningOperationName,
RequestedToolName, IsPlaying, and IsPaused values when busy. Use the existing
UnityCliLoopEditorStateGuard and UnityCliLoopToolBusyException symbols to add a
small test (ideally via a fake IEditorRuntimeStatePort) that exercises both
ready and busy outcomes.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 407acc2d-c440-42c0-a5d9-4ff8dac86918

📥 Commits

Reviewing files that changed from the base of the PR and between 99e449e and 7cedae3.

⛔ Files ignored due to path filters (3)

• Assets/Tests/Editor/ToolExecutionEditorReadyPolicyTests.cs.meta is excluded by none and included by none
• Packages/src/Editor/Application/UnityCliLoopEditorStateGuard.cs.meta is excluded by none and included by none
• Packages/src/Editor/Domain/ToolExecutionEditorReadyPolicy.cs.meta is excluded by none and included by none

📒 Files selected for processing (4)

• Assets/Tests/Editor/ToolExecutionEditorReadyPolicyTests.cs
• Assets/Tests/Editor/UnityCliLoopEditorStateGuardTests.cs
• Packages/src/Editor/Application/UnityCliLoopEditorStateGuard.cs
• Packages/src/Editor/Domain/ToolExecutionEditorReadyPolicy.cs

💤 Files with no reviewable changes (1)

• Assets/Tests/Editor/UnityCliLoopEditorStateGuardTests.cs

[cubic-dev-ai]

No issues found across 7 files

_{Re-trigger cubic}