Recover the state.
Defend a fresh rule.

04 / ONE SERVER CLOCK

Late delivery does not move the past.

A server tick advances the simulation once. A network callback delivers a message; it does not necessarily advance a tick. This model processes 50 ms ticks and limits catch-up after a long pause. The accepted input receives its expiry from the server's current tick, not from a client timestamp.

Input admitted at tick T remains active through T+4. At T+5 it stops unless a newer input renewed it. An equal or older sequence does not renew the expiry. A disconnected browser may stop delivering messages while its existing server actor continues until expiry. Resuming that session preserves the actor; a new session creates a different actor.

npm run core:prepare -- timing

In the printed workspace, implement predictTiming(record). First write predictions and a reconnect explanation in response.md. The checker compares your model with the real engine and clock at each labelled action.

npm run core:check -- --assistance "none"

Transfer: a pause spans sixteen nominal ticks but only a bounded number are processed. Explain why wall time, processed ticks and client-supplied time cannot be interchanged. Then predict a fresh-sequence input arriving exactly at expiry. Record any hints and retain the first response.

10 / A RELEASE IS MORE THAN ITS CODE

Choose a compatible recovery point.

A configuration supplies values such as the allowed interaction radius. A state schema specifies the shape of saved data. The trial changes the radius from 250 to 100 mm and writes a new state envelope. A legal boundary pickup now fails. Restoring the old code while retaining the new envelope cannot restore the old state.

Your selector must return an existing, compatible package/configuration/snapshot tuple. Follow the declared target release, verify configuration identity and select the newest compatible snapshot. Do not invent a migration or silently substitute another release. A hash identifies bytes; it does not authenticate who approved them.

npm run core:prepare -- recovery

Implement selectRecovery(evidence), record stop conditions and explain which later actions are lost. Check from the prepared workspace, then run your completed self-contained policy from the reference project:

npm run core:check -- --assistance "none"
# From the reference project:
npm run recovery:trial -- /path/to/policy.mjs artifacts/recovery-01.json

The trial uses the real owned engine in memory; it changes no deployed service or files beyond the requested report. Recovery discards actions after the selected snapshot. The restored branch has its own lineage. Returning from acknowledged sequence 12 to saved sequence 3 reopens sequences 4–12 in this model. A real service needs a recovery epoch or an external acknowledgement floor before accepting retries. A new pickup after restore does not reimburse a lost delivery or prove production rollback safety.

Additional transfer, separate from the worksheet: a repair also sends a physical print job. Restoring old state cannot retract the physical output. State the additional receipt or reconciliation contract you would need before recommending retry.

11 / BUILD AND INDEPENDENTLY CHALLENGE

A repair has a price. A retry is not another purchase.

Build a separate repair-station extension to the owned arena. The server owns position, credits and energy. A request contains only requestId and stationId. At a distance of at most 400 mm, a repair costs two credits and restores three energy, capped at ten. The initial balance is six credits and four energy.

The first successful ID records a receipt. A retry of that ID for the same station returns the original receipt, even after movement, without charging again. A conflicting station refuses. Failed requests reserve no ID. When the two-receipt capacity is full, new IDs refuse instead of evicting old receipts and reopening a double-charge path.

Write an explanation before using the worked example. Identify the authority boundary, give a concrete double-charge counterexample, explain the receipt-capacity tradeoff and propose an independent regression test. Transfer to a different resource with a delayed completion and decide when its receipt becomes final.

npm run core:prepare -- capstone

Implement both capstone/policy.mjs and capstone/scenario.mjs. The scenario must independently assert HTTP status, server balances, receipts and unchanged state after refusal. It must accept two correct implementations and expose the supplied wrong variants. The panel includes isolated wrong-energy, wrong-receipt and refusal-side-effect controls. Passing shows discrimination on those controls; it does not prove the dataflow of arbitrary assertions. Use ordinary JavaScript assertions on observed values. A test that always throws or checks only status strings cannot pass the panel.

npm run core:check -- --assistance "none"
# Optional worked request trace from the reference project:
npm run capstone:trace -- /path/to/policy.mjs artifacts/repair-01.json