# Watch dimming is not a recording interruption The initial Watch scene handler called the shared interruption method for every non-active phase. That method deliberately cancels calibration, stops acquisition and saves an interrupted recording. On watchOS, however, inactive can mean a dimmed app that is still frontmost. The iPhone interruption policy was therefore too aggressive for the Watch. Route Watch scene phases through one testable handler: active resumes preview, inactive preserves acquisition, background performs the existing interrupted save. Record lifecycle events before stopping, preserving host timestamps alongside sensor samples. A regression against the original handler reached saved state with no new samples after inactive. After the fix, samples span the inactive interval and background still finalizes correctly. User-controlled Return to Clock can lengthen frontmost residence up to one hour. It does not promise uninterrupted high-rate sampling. Verify that separately on the physical Watch with natural dimming, no interaction and no attached debugger. A debugger can mask runtime restrictions. Compare actual sample timestamps with lifecycle intervals; do not use a visible timer as the acceptance signal. Sources: [frontmost app state](https://developer.apple.com/documentation/watchkit/taking-advantage-of-frontmost-app-state), [handling transitions](https://developer.apple.com/documentation/WatchKit/handling-common-state-transitions). ## Physical evidence supersedes the settings hypothesis The real build 9 hands-off trial persisted only 24.13 seconds with an incomplete master. A later two-minute remote probe captured about 121 seconds but stalled during finalization; neither proves dimmed execution. Add separate process/lifecycle journals and explicit stop-callback, writer-finalize and save-completion boundaries so an END marker cannot be mistaken for a completed save. Preserve partial masters. A runtime request may fail even when WKApplicationState reports active: build 13 remote launch received extended-runtime error 3, requiring active interaction before resigning active. Request synchronously from a physical user control, then verify the delegate's grant and actual timestamp coverage. The physical-therapy category applies only to the stationary guided range-of-motion use case. Build 14's user-tap trial remains pending; no continuous-runtime success is claimed. Use a continuous clock for hands-off deadlines and journal both continuous elapsed time and sensor/host clocks. Retire a timed probe when finalization begins; use a generation token so cancellation cannot interrupt a replacement capture. Calibration retries may keep the same controller state, so observe calibration stage as well as recording state when reacquiring a released runtime grant. The build 14 physical user-tap trial subsequently obtained the runtime grant and persisted 604.818 seconds without sampling gaps while inactive. Capture-stop completion succeeded, but writer finalization did not complete. Keep these as separate acceptance gates: execution support can be verified even while save completion remains broken. The retained real master allows investigating save behavior without repeating ten minutes of acquisition.