[dop42]

Two modules that together cover "something other than the player owns the view".
Both hand a resource something it must return, and both fail in a way that looks like a
crash from the player's chair.

The release guarantee, which is the point

The platform already releases the view on resource stop, reload, an uncaught coroutine
error, death, an unreadable body, world exit, shutdown, destroy and supersede. Every
one of those fires on a generation that has already failed or gone away. A live
caller is covered by none of them: a pcall-caught error, an early return down an
untested branch, a panel closed by the one path that forgets the hand-back.

Camera.Shot(id, options, body) closes exactly that gap — take, await the blend, run
the body under pcall, hand the view back on every exit, await the returning blend.
When it returns, the player has their own eyes back, on them rather than mid-blend.

A raise becomes shot_raised rather than an unwind, because propagating it after the
restore is the one ordering that loses the error and keeps the symptom. A rejected take
means the shot never happened, so the body does not run — it would draw over a view
somebody else now owns. Screen.Black is the same scope for the image.

The honest boundary is written into the header: a body that never returns is never left
by any path, and there the platform's own rules are the only backstop.

The promise that arrives second

Seven natives answer a promise as a second value, which Native.Call cannot carry —
it keeps the first. They are reached directly, and the promise rides on the Result under
a name that says what it settles on: .blend, .covered, .restored, .finished. A
cut carries none, and Await(nil) answers Ok so no call site needs the if.

Refusals that answer the question they leave you with

camera_held_by:<resource> is lifted onto .holder with no extra native call; a bare
camera_held spends one cameras() read to answer the same question; if the build will
say neither, the detail says that rather than inventing a holder.
camera_budget_exhausted names 16 and 64. screen_busy says the slot is shared with
the server relay and points at isFaded().

One source disagreement, recorded rather than resolved

The reference and the devkit's own example read cameras().held two incompatible ways —
"true only for you" versus "true for anybody". They cannot both be right and there is no
game here to settle it. State therefore decides on the holder name, compared
against our own, which is correct under either reading; held is consulted only when
there is no name, and answers a deliberately vague 'held'.

Verification

375 → 547 checks, 0 failed. Every one of the fourteen new blocks was mutation-tested
— the source broken once per block, the block confirmed red, then reverted. All six CI
gates run by hand.

Every native verified against the devkit at op77.76; nothing unverified. But the live
server runs 82+, so this is "verified at 76", not "verified live" — and no promise
rejection token, no camera_not_active tolerance and no fadeIn refusal has ever been
observed in a game.

🤖 Generated with Claude Code