Migration plan: extracting frame-engine into its own repo

[diego3]

Summary

Adds docs/frame_engine_migration_plan.md: a plan for splitting this repo's core engine out
into diego3/frame-engine as a standalone, importable
Go module, with frame becoming a thin application layer (main.go, WASM entry point, games/)
depending on it.

What's in it

• Full package/doc inventory classifying every current directory as Move / Stay / Split,
  with a one-line rationale each — event/, object/, physics/, ports/, process/,
  resource/, script/, vec2/, view/{ui,input,camera}, and all of application/ move;
  games/, main.go, logic/ stay; docs/adr/+docs/tdr/ mostly move (they document engine
  decisions, not this specific game).
• The one blocking design problem found during the audit: view/scene.MainMenu, meant to be
  the engine's generic reusable scene type, has accumulated real Metal-Slug-specific gameplay
  rules over the course of this demo's build-out (hit-detection damage math, hardcoded spawn
  event names, camera-target selection by object name). Copying it into a "generic" engine
  library as-is would just move today's layering violation from a package boundary to a repo
  boundary. The plan proposes splitting it into a generic toolkit (goes to frame-engine) and a
  Metal-Slug-specific scene implementation (stays in frame, built on that toolkit) — as its own
  phase, done before the repo split, inside the current single repo where the existing test
  suite can catch regressions.
• Resolving that split also resolves the // FIXME already sitting in
  application/engine/engine.go (hardcoded scene registration) as a side effect, not a separate
  cleanup.
• A 5-phase build order (split MainMenu → scaffold frame-engine → move the scene toolkit →
  wire frame to depend on it via a go.mod replace during co-development → cleanup), and an
  open-questions section flagging real decisions that need a human call (the module path,
  whether object.Enemy/object.Projectile are generic enough to move, move-vs-copy for
  ADRs/TDRs, license parity).
• Confirms via list_pull_requests that the only currently-open PRs (Propose game-architecture skill (Game Coding Complete patterns) #23, ADR-011: GameObject attachment hierarchy (parent/child transforms) #24) are docs-only and
  don't touch anything this migration would relocate, so there's no rebase-storm risk in
  starting now.

No engine or game code changes — this PR only adds the plan document, so it can be reviewed and
adjusted before any file actually moves.

---

Generated by Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.