feat: Make Unity tools easier to extend and maintain

[hatayama]

Summary

• Restructures the Unity Editor side around onion-style assembly boundaries so the core host stays thin and tool implementations are easier to replace.
• Moves bundled tools onto the same first-party tool contract model expected for future custom tools.
• Updates E2E coverage so replay and mouse UI checks stay deterministic across Game View resolution changes.

User Impact

• Tool authors get a clearer extension surface through UnityCLILoop.ToolContracts instead of depending on the internal application layer.
• Built-in tools and third-party-style tools now follow the same shape, making future tool additions less special-cased.
• The project has stricter assembly dependency tests, which should catch architecture drift earlier.

Changes

• Adds explicit Domain, Application, Presentation, Infrastructure, FirstPartyTools, ToolContracts, and CompositionRoot assembly boundaries.
• Moves built-in tool entry points such as compile, get-logs, execute-dynamic-code, screenshot, run-tests, input, hierarchy, and game-object discovery into first-party tool modules.
• Moves dynamic compilation and transport concerns behind infrastructure and composition-root registration.
• Removes legacy internal-only tools and stale MCP-era naming from the active tool surface.
• Adds an architecture migration plan document and dependency boundary tests.
• Stabilizes mouse/replay E2E scripts and tests by setting the required Game View resolution before coordinate-sensitive checks.

Verification

• uloop compile
• uloop get-logs --log-type Error --max-count 20
• uloop run-tests --test-mode PlayMode --filter-type regex --filter-value .E2ETests.
• sh scripts/test-simulate-mouse-demo.sh
• Focused EditMode coverage for onion boundaries, dynamic compilation, runtime contracts, and tool factories was run during the migration.

Notes

• Created as a draft because the diff is intentionally broad and should be reviewed as an architecture migration.

[cubic-dev-ai]

1 issue found across 1305 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/FirstPartyTools/ClearConsole/Skill/SKILL.md">

<violation number="1" location="Packages/src/Editor/FirstPartyTools/ClearConsole/Skill/SKILL.md:48">
P2: This documentation change weakens the clear-console output contract: it no longer states that failure details are in `Message` while `ErrorMessage` stays empty.

(Based on your team's feedback about keeping clear-console failure details in `Message` and `ErrorMessage` empty.) [FEEDBACK_USED]</violation>
</file>

_{Note: This PR contains a large number of files. cubic only reviews up to 75 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.}

[cubic-dev-ai]

1 issue found across 45 files (changes from recent commits).

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/FirstPartyTools/ExecuteDynamicCode/DynamicCodeFriendlyErrorConverter.cs">

<violation number="1" location="Packages/src/Editor/FirstPartyTools/ExecuteDynamicCode/DynamicCodeFriendlyErrorConverter.cs:13">
P2: Use `CompilationErrors` as the first source when deriving friendly error guidance; relying only on `ErrorMessage`/`Logs` misses compiler diagnostics and degrades failures to generic messages.

(Based on your team's feedback about checking `CompilationErrors` first for execute-dynamic-code failures.) [FEEDBACK_USED]</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}