Verify Motion v1 on a physical device: camera, pose mapping, ReplayKit, and control feel

[sarthakagrawal927]

Why now

The iOS app compiles cleanly for the iOS Simulator but has never run on physical hardware — the Simulator has no camera. This is already recorded in two places:

• PROJECT_STATUS.md (2026-08-11): "App Store Connect record creation and physical camera/ReplayKit verification remain separate manual gates."
• foundry-evidence.json: device.state: blocked — "No physical device in CI; camera + ReplayKit need a device."

#20 (App Store Connect record + TestFlight upload) was deferred by the owner on 2026-08-13 specifically until this verification is complete. Since #20 was the repository's only open issue, the gate it waits on was untracked — #20 pointed at work that had no home. This issue is that home.

It is also Motion's reopen condition in the fleet portfolio: "Reopen for focused physical-device playtesting of one genuinely fun control loop."

Acceptance

• The app runs on a physical iPhone or iPad with camera and Photos permissions granted.
• Apple Vision 2D body-pose detection runs on the front camera at a usable rate. Record observed FPS and input latency.
• Left/right joint mapping matches the player. Front-camera mirroring is the specific risk called out in README.md.
• ReplayKit captures the WKWebView game content rather than a black frame. The second risk called out in README.md.
• The combined recording (game plus camera inset) saves to Photos as one video.
• The bundled webgame/ path works with no Vite dev server and no Mac on the network.
• Screen-mirrored to a TV via AirPlay, Chromecast, or QuickTime, the game remains playable at that added latency.
• After a few minutes of Motion Maker grab/toss, a written verdict on control feel.

The first seven are pass/fail engineering checks. The last one is the actual decision. README.md and PROJECT_STATUS.md both state that the central product risk is control feel, not infrastructure — which is why v1 deliberately strips out every server and network hop. Nothing currently asks that question.

Out of scope

• The App Store Connect record and TestFlight upload — that is Create the personal App Store Connect record and upload to TestFlight #20, and it stays deferred until this closes.
• v2 work: the PartyKit relay, browser display, Chromecast receiver, and multiplayer. All parked in-repo on purpose.
• New game mechanics. This verifies the loop that exists.

Done when

Recorded evidence exists (FPS, input latency, one saved recording) alongside a written verdict on control feel, and then either:

• Create the personal App Store Connect record and upload to TestFlight #20 is reactivated and Motion proceeds to TestFlight, or
• Motion stays Hold with the reason written down.

[sarthakagrawal927]

Blocked

Blocked on: a physical iPhone. Not reproducible in CI or the Simulator.

foundry-evidence.json records device.state: blocked — "no physical device in CI; camera + ReplayKit need a device". PROJECT_STATUS.md (2026-08-11) records physical camera/ReplayKit verification as a separate manual gate.

The Simulator has no camera, so none of the 8 acceptance items can be exercised: FPS/latency, front-camera mirroring left/right mapping, ReplayKit WKWebView capture, Photos save, or AirPlay/TV latency. The final item is a human written verdict on control feel, which is inherently not automatable.

This is the gate that blocks #20 (TestFlight upload).

Who can unblock: owner — run the device playtest.

[sarthakagrawal927]

Blocker (2026-09-06): blocked: device-test — needs the owner to run the physical-device playtest (camera, pose mapping, ReplayKit, control feel).