Retire unity-engine-core once unity-builder/unity-test-runner migrate to invoking cli

[frostebite]

Context

While building activate as the pilot for the actions-invoke-cli architecture (#68), I originally filed this issue proposing to extract cli's Unity-specific implementation (RunnerImageTag, PlatformSetup, Docker/MacBuilder orchestration) out of this repo and into unity-engine-core, so cli's built-in Unity plugin would become a thin adapter over it - mirroring the actions → cli relationship one layer up.

Update after actually reading unity-engine-core's current contents: that's not the right move. Correcting course here rather than implementing the original framing.

What unity-engine-core actually is today

It's not a CLI-shaped Unity-implementation library. It's the old unity-builder, unity-test-runner, and unity-activate codebases copied in wholesale as three namespaces (src/unity-builder/, src/unity-test-runner/, src/unity-activate/, each with their own model/, Docker orchestration, action-input handling, etc.), exported for those action repos to import as an in-process library - shaped for GitHub Actions context, not for CLI commands.

cli's own Unity plugin (RunnerImageTag, PlatformSetup, Docker.run, MacBuilder.run) is a completely independent, from-scratch implementation. cli's src/ has zero references to @game-ci/unity-engine-core anywhere. The two were never the same codebase - merging them would mean reconciling two divergent implementations, not a mechanical extraction.

What I recommend instead

• unity-builder and unity-test-runner are still on the library-import pattern (@game-ci/unity-engine-core as an npm dependency, run in-process) - see the still-open thin-wrapper PRs on those repos. Once they migrate to invoking cli directly, the same way unity-activate now does (unity-activate#111), nothing will import unity-engine-core's three namespaces anymore.
• At that point unity-engine-core has no remaining consumers. cli's own Unity plugin already provides the "Unity-specific churn lives in one place" property that was the actual goal - it just turned out that place is cli itself, not a separate package cli also depends on.
• Recommend: once the unity-builder/unity-test-runner migrations land, archive or deprecate unity-engine-core rather than trying to merge it into cli.

Not doing right now

Not implementing anything here yet - this is blocked on the unity-builder/unity-test-runner thin-wrapper migrations landing first (tracked separately). Leaving this open as the place to revisit once those land.

🤖 Generated with Claude Code

[frostebite]

Done. game-ci/orchestrator and game-ci/unity-engine-core are both archived — content lives on in game-ci/cli's plugins/orchestrator/ and plugins/unity/ (full history preserved via git subtree, see #78).

Migration status of the consumers:

• unity-activate → #111: merged and CI green end-to-end (activate → docker pull → license activation, all passing).
• unity-builder → #844: thin wrapper open, Linux/macOS jobs passing; Windows jobs were blocked on a real bug now fixed in #88.
• unity-test-runner → blocked on test command needs a Docker-based mode before unity-test-runner can convert to invoke-cli #71 (a Docker-based cli test mode doesn't exist yet) — tracked separately, not blocking this issue.

Closing — the retirement itself is done regardless of the remaining migrations landing.