@homie-rocks/studio 0.37.1 → 0.38.0

package/parts/PARTS.md

@@ -1,14 +1,10 @@
 # Studio parts
 
-Studios build on each other by sharing **parts**: a reusable piece of a game, app, music or video that its studio chooses to share, so somebody
-making another game can use it. A creature from one game, a level from another, a bot brain from a third. That is
-the whole idea. Without parts, a creator's AI has to come up with everything on its own.
-
-Mashing up is not a command: it is making a game with parts from several games.
+Studios share **parts**: reusable files another studio can find, license and install. A part may be a game mechanic, an app's quiz, menu board or waitlist screen, a music loop or complete track, or video. It can be free or priced. The licence says where it may be used, including a venue when the seller chooses that use.
 
 ## The rules
 
-1. **A part is a reusable piece, never a whole game or app.** Remix, which handed over an entire game, is retired;
+1. **The lifting command extracts a piece, never a whole game or app.** Music, video and app assets can be authored directly in a part folder. Remix, which handed over an entire game, is retired;
    parts are what replaces it.
 2. **A part can take any form** that suits the piece: code, assets, data, a JSON description, a tuned config, or a
    mix. Form is not restricted.
@@ -89,11 +85,12 @@ named after it):
 | Field | What it is |
 | --- | --- |
 | `id`, `name`, `kind`, `version`, `summary` | `version` is three numbers; a shared version never changes, so a change is a new version. `summary` is one sentence. |
-| `kind` | `character`, `rig`, `clips`, `environment`, `effect`, `sound`, `ui`, `mechanic`, `shader`, `level-generator`, `bot-brain`, `audio-pack`, `set-piece`. `quiz`, `menu-board`, `waitlist`, `live-total`, `loop`, `stem`, `track`, `video-intro`, `video-template` also name parts. There is no kind for a whole game or app. |
+| `kind` | `character`, `rig`, `clips`, `environment`, `effect`, `sound`, `ui`, `mechanic`, `shader`, `level-generator`, `bot-brain`, `audio-pack`, `set-piece`. These are suggestions, not a whitelist. `app`, `music` and `video` are also suggested; any lowercase label of letters, digits and hyphens is accepted. |
 | `license`, `attribution` | Needed to share: an SPDX identifier, and who a game using the part credits. |
 | `share` | **Default `false`.** The part's own switch, and the only thing that decides whether it is shared. |
-| `uses` | Optional intended uses: `game`, `app`, `venue`, `cause`, `music`, `video`. Describe the purpose, independently of licence and any future pricing. |
-| `from` | The source and studio: `game`, `app`, `music` or `video` with its id. Written when a part is lifted out of a game. |
+| `from` | The source and studio: existing `{game, studio}` stays valid; non-game work may use `{kind, id, studio}`. Written when a part is lifted out of a game. |
+| `uses` | Optional intended uses: `game`, `app`, `venue`, `cause`, `music`, `video`; the licence governs permission. |
+| App/media provenance | The source and studio: `game`, `app`, `music` or `video` with its id. Written when a part is lifted out of a game. |
 | `entry` | For a part with code: the module a game imports. A part of assets or data has none. |
 | `files` | Every file with its SHA-256 and size, **written by the tool, never by hand**. A file may carry `"rights"` (below). |
 | `preview` | `page`: a self-contained HTML page shown in a sandboxed frame. `image`: a still. `aspect`: the frame's shape as `"W:H"` (whole numbers 1 to 32, no flatter than 3:1, no taller than 1:2; default `"16:9"`). `phoneAspect`: the shape when the frame is narrower than 600 px. |
@@ -169,6 +166,237 @@ build, whether or not the add named the game.
   alone.
 - The plumbing behind the tools is `homie-studio parts find | new | add | share | unshare | check`.
 
-App parts use the same lift/import/credit paths as game parts. Music and video parts can start empty with the corresponding kind; add their selected files, licence and provenance before sharing. `uses` describes what they are for, not permission to use them: the licence controls that. No price or checkout behavior is introduced; future commercial metadata can be added separately without changing the meaning of `share`.
+App parts use the same lift/import/credit paths as game parts. Music and video parts can start empty with the corresponding kind; add their selected files, licence and provenance before sharing. `uses` describes what they are for, not permission to use them: the licence controls that. Optional `sale` metadata adds pricing without changing the meaning of `share`.
 
 For example: `homie-studio parts new welcome-queue --kind waitlist --uses app,venue`, or `parts new gala-loop --kind loop --uses venue,cause`. A source app is selected by the existing `--from <id>` and `--game <id>` options.
+
+## Selling a part to another studio
+
+A part can be free or have `sale` in its `part.json`. The seller chooses its price,
+licence and refund terms. Homie takes no cut and sets no price or spending ceiling
+for studio purchases. Existing player shop rules apply to players, not these licences.
+
+```json
+{
+  "license": "LicenseRef-Studio-Commercial",
+  "licenseTerms": "LICENSE.txt",
+  "sale": {
+    "amount": 2500,
+    "currency": "usd",
+    "billing": "one-time",
+    "scope": "studio",
+    "source": true,
+    "updates": "major",
+    "taxCode": "txcd_10000000",
+    "refund": "Contact the studio for the refund terms written in LICENSE.txt.",
+    "onRefund": "terminate",
+    "onExpiry": "retain",
+    "commercialUse": true,
+    "transferable": false,
+    "publicFiles": ["preview/demo.js"]
+  }
+}
+```
+
+This fragment is added to a complete part; choose the tax code for the actual goods.
+`LICENSE.txt` must contain the complete seller-chosen licence and refund terms and
+identify each custom licence. `license` also accepts SPDX expressions (`MIT OR
+Apache-2.0`, for example); the toolkit never chooses an alternative for the buyer.
+`LicenseRef-…` identifies a custom commercial licence, not an SPDX listed licence.
+The structured summary and licence text must agree; the text is what the parties read.
+
+- `amount` is a positive integer in Stripe's currency minor units (JPY has no cents).
+  There is no toolkit price ceiling; Stripe's own supported amounts still apply.
+- `billing`: `one-time`, `day`, `week`, `month`, `year` (the recurring intervals Stripe supports). Recurring sales use Stripe Billing, with
+  paid-through periods from paid invoices. Cancellation uses Stripe's customer portal.
+- `scope` is the seller’s label for licensed use (for example `studio`, `game`, `seat`, `venue` or `app`). A game licence names the buyer's game. A seat
+  licence has a quantity; seat assignment and transfer follow the written terms.
+- `source`, `commercialUse`, `transferable` are explicit booleans. Package only the
+  files being sold. `source: false` does not strip or obfuscate files automatically.
+- `updates`: `none`, `major`, `all`. Existing purchases use their original update
+  promise. Later list prices and new-buyer terms never remove the purchased promise. Included updates remain licensed under the purchased terms.
+- `refund` is the seller's policy in plain words; `onRefund` and `onExpiry` choose
+  `retain` or `terminate` for rights to already downloaded copies. Full refunds and
+  lost disputes stop new downloads. Partial refunds leave the licence active.
+- `publicFiles` explicitly names preview dependencies that may be downloaded without
+  buying. The preview page, image and licence text are public automatically. A browser
+  demo exposes whatever code and assets it uses. Keep private source out of previews.
+
+On an already deployed studio, ask the AI to connect the shop and sell the part. The AI runs `shop init` if needed, `shop connect`, configures private storage and shares the release. **One browser approval** connects Stripe when its CLI session is not already authorized; an existing session needs **zero** new approvals. Account onboarding and Cloudflare authorization are separate provider requirements. Products, Prices, Payment Links and the webhook are created through Stripe's official CLI. The webhook signing secret and an automatically generated purchase signing key go privately into the Worker. No person finds, copies or pastes either secret.
+
+The default hosted fallback uses these Payment Links with **no Stripe API key in the Worker**. The hosted review records the accepted terms, then redirects to Stripe with an opaque order reference. A verified signed event binds the exact link, revision, currency, amount and mode before granting files. Lost events wait for Stripe redelivery; the owner's AI can resend them through Stripe's CLI. Refund in Stripe or ask that connected AI. Keyless retirement returns the subscriptions for that AI to cancel through Stripe; signed cancellation events let retirement finish without revoking paid-period downloads. The shop's signed refund snapshots update access; the Worker makes no Stripe API request. The AI can preconfigure any positive quantities in `parts/offers.json`, for example `{"camera":{"quantities":[1,5,20]}}`, then run `shop connect`; it creates a fixed link for each chosen quantity. The default is one unit. A quantity without a matching link needs that setup sync or the fuller Session connection, so the paid quantity always matches the approved quote. Signed paid invoices supply recurring access periods; invoice-payment events associate their refunds. A later billing period never removes the rights the seller promised for earlier downloads.
+
+Paid releases use a **separate private R2 bucket and `PURCHASE_MEDIA` binding**. Never enable a public R2 domain for it. Deploy verifies the selling Worker before uploading private files and reads every uploaded hash back. No paid payload is copied into public static assets; the normal Worker cannot read this bucket. Technical file and request limits are security/resource safeguards, not spending limits.
+
+### Which payment paths need credentials
+
+| Path | Stripe API key in Worker? | Other requirements |
+| --- | --- | --- |
+| Hosted Payment Link fallback | **No** | CLI browser approval at setup; signed webhook; private signing key and storage |
+| MPP Stripe shared payment tokens | **Yes** | Authenticated PaymentIntent creation, account profile and SPT eligibility |
+| MPP over MCP | **Yes** | The same Stripe shared-token charge, carried by MCP |
+| x402 Base recorded into Stripe | **Yes** | Authenticated transaction-verification PaymentIntent; live CDP facilitator credentials; Stripe-approved deposit address |
+| Dynamic Checkout Sessions, direct refunds, provider-read recovery | **Yes** | Stripe API access for those operations |
+
+Stripe's [MPP guide](https://docs.stripe.com/payments/machine/mpp) initializes the Stripe client with a secret credential. Its [x402 guide](https://docs.stripe.com/payments/machine/x402) separates the on-chain facilitator settlement from authenticated PaymentIntent recording. **x402 itself does not require a Stripe API key**; this supported path records money into the seller's Stripe books as Stripe documents. The keyless Payment Link path uses [signed webhooks](https://docs.stripe.com/webhooks) instead of provider reads. CLI OAuth is not exported as a Worker REST credential; see [the setup research](../../../docs/stripe-connect-research.md).
+
+For a fuller connection, the AI operates Stripe's [key-creation page](https://docs.stripe.com/keys), selects the necessary permissions and clicks Copy, then runs `shop connect --from-clipboard` (`--live` for live mode). The local command privately reads the clipboard, verifies the key, makes the webhook and writes secrets to Wrangler stdin, then clears the clipboard. **The human only handles provider sign-in, verification or approval prompts**; their count is controlled by Stripe. Never ask the person to find or paste a key when browser control is available. No supported public API to mint a persistent Stripe REST credential from the CLI approval was established. On macOS this uses `pbpaste`/`pbcopy`, Windows its clipboard commands, and Linux Wayland `wl-paste`/`wl-copy`; other desktops require an equivalent private credential transport. The manual local form remains an explicit fallback, not the default instruction. Live CDP credentials likewise belong to the seller and should be transferred privately by the AI from the provider's setup; no Homie account is involved.
+
+Turnstile is optional. If the studio configures it, the fallback verifies its hostname and action. The per-address Worker rate limiter remains configurable flood protection. Machine payment proofs are verified by the protocol libraries.
+
+A release's bytes never change. `parts/offers.json` holds only price overrides and
+availability choices. Other terms come from the release being offered. Each accepted
+offer version stores the complete terms and price together. Earlier free copies cannot be recalled. `share: false` stops discovery
+and new checkout after deploy; R2 keeps paid releases for existing buyers. Do not
+remove purchased releases. Keep the packed files, D1 purchase records and signing key
+in the seller's backups. Run shop connect again after adding paid parts to register the additional
+subscription webhook events and permissions. Stripe's Dashboard must have its customer
+portal enabled for subscription management; refunds and cancellation are separate.
+
+## Buying and keeping the proof
+
+Requires studio **0.36.0**. Discovery uses `/.well-known/api-catalog`, linking
+`/parts/catalog.json`, `/purchases/keys.json`, the HTTP resource and MCP endpoints.
+The seller's public page and catalogue contain schema.org Product and Offer descriptions.
+
+The buyer sees the full offer and exact quote before approving payment. Set
+`HOMIE_PARTS_WALLET` to the person's installed `link-cli` or `purl` client.
+The tool calls the wallet, which owns all spending authority and limits. Link card spends
+currently require approval in the Link app. Retry the same purchase after that approval.
+A compatible funded crypto wallet can use its existing authority. No seller checkout
+page is involved in a successful protocol exchange.
+
+MPP uses Stripe shared payment tokens. Tempo is disabled. x402 exact uses Base
+payments to the studio's Stripe deposit address. Both return files, a payment receipt
+and signed purchase proof. MCP uses MPP's JSON-RPC challenge and receipt binding.
+Checkout remains the human fallback, and handles subscriptions, non-USD prices and final
+tax calculation. Managed Payments is a Checkout option; machine charges use the studio
+as seller. In fallback Checkout the person accepts the licence and presses Pay; an
+assistant must not submit acceptance with a browser tool.
+
+`shop connect` obtains the profile and stablecoin deposit addresses from Stripe and writes
+`PURCHASE_MACHINE_PAYMENTS` and a mode/key-bound `PURCHASE_PAYMENT_CAPABILITIES` record. It needs
+**PaymentIntents Write**, Business Profiles access, Payment Method Configurations reads and
+Crypto Deposit Addresses access, as well as the existing Checkout and webhook permissions.
+The fuller connection reports Stripe readiness errors. Connect and scheduled checks read the
+profile, enabled methods and existing deposit addresses. They create no provider objects.
+These reads establish configuration, not PaymentIntents Write permission, funded settlement
+or SPT eligibility. Real purchase outcomes update readiness. The scheduled check retries
+failures with backoff and rechecks successful configuration every six hours.
+Stablecoins still require Stripe approval; the office reports unavailable methods and the
+catalogue lists the available paths. Live Base additionally needs the studio's own
+`CDP_API_KEY_ID` and `CDP_API_KEY_SECRET`. The toolkit does not invent those credentials.
+
+At the documentation check on 2026-10-08, the Link wallet supports US and Canadian wallet accounts and a $500 spend-request
+limit. An x402 client's default spend control can be $1 per payment; the wallet owner decides
+whether to change it. These are provider/client constraints, not studio pricing limits.
+`part_add` also accepts a `wallet` argument. A failed token clears pending wallet approval. Explicit wallet refusals, missing wallet software,
+unsupported methods and unavailable machine paths offer a clearly labelled hosted Checkout fallback. An uncertain settlement must be reconciled before paying again.
+
+`/openapi.json`, linked as `service-desc` from the API catalogue, publishes each offer's
+request schema and `x-payment-info`. Buyers can submit the published `offerVersion`.
+Challenges bind to the server hostname and an individual purchase resource URL. Unpaid
+machine orders and challenges last five minutes; reprice, withdrawal and retirement close
+old unpaid offers. The limiter applies before protected R2 file reads too.
+
+Verified stablecoin settlements grant access even while Stripe recording is unavailable.
+`purchase_jobs` retains the recording parameters and transaction reference. A five-minute
+cron and on-demand order refresh retry recordings and re-read processing PaymentIntents.
+If paid files cannot be restored, the owner must refund the order manually. Maintenance never
+refunds for a storage outage. Every five minutes it reads unresolved Stripe objects and retries
+delivery availability. The owner can run the same recovery with
+`POST /_studio/api/shop/reconcile-payments` and an optional `order` identifier; buyers retrying
+their purchase also trigger this read. Existing payment facts and order identifiers are retained
+for late webhooks. Authentication, permission and idempotency errors are not charge refusals.
+After 23 hours, no charge is replayed. Reads continue: a paid object is recorded; a canceled or
+unpaid object releases the claim. An exhausted complete list after the deadline also releases
+the claim while keeping its order. If Stripe remains unreadable, the office shows the order,
+request key, recorded PaymentIntent (if known), age and last error. Reconnect the key and use
+Reconcile payments now. If you have the exact PaymentIntent id, use Read this payment beside
+the recovery row (or pass `payment` and `order` to the same endpoint). Its order metadata must
+match. Use the normal refund action once Stripe confirms payment; an unpaid canceled object
+releases the claim. Never infer no charge from an API error.
+
+An explicit sandbox readiness check is available through
+`POST /_studio/api/shop/readiness`. It reads current configuration without creating any provider object, order, entitlement or refund. Failures expire after five minutes;
+success expires after six hours. The report records the check time and its limited scope.
+Scheduled capability checks are read-only, at most four successful checks per day, with
+backoff after failure. No extra permissions or checks apply to a shop without paid releases.
+
+Paid objects live under `paid-parts/` in the private `PURCHASE_MEDIA` bucket, separate from
+public `MEDIA`. Deployment creates that bucket, deploys the guarded Worker, then uploads and
+verifies the files. Failure before deployment uploads nothing. An older public Worker has no
+binding to those objects. Public routes also refuse the prefix if it is bound accidentally.
+
+The studio can tune `PURCHASE_RATE_LIMITER` in its Wrangler configuration; deployment keeps
+that binding’s chosen limit and period. It is an abuse control, not a spending allowance.
+
+Stripe can initiate Managed Payments refunds within 60 days in certain cases, including
+support escalations left unanswered for 48 hours, and can accept disputes. A customer’s
+data-deletion request cancels their Managed Payments subscriptions. These are Stripe’s
+rules, described in its [Managed Payments guide](https://docs.stripe.com/payments/managed-payments/how-it-works).
+Provider reconciliation observes refunds and cancellation regardless of who requested them.
+
+## Seller settings and recovery
+
+`part.json.sale` supplies terms for each immutable release. `parts offer <id> --amount`
+sets only a persistent price override. Other terms change with a new release. Offers are
+versioned from all terms, resource and price; a buyer keeps the version they purchased.
+The build does not write `parts/offers.json`. Only the newest release sells by default;
+`--release <version> --keep-on-sale` retains an older release. Release settings merge,
+so adding an included upgrade does not silently withdraw an older release.
+
+`--withdraw` closes new sales; `--on-sale` explicitly reopens an offer. Deployment expires
+obsolete open Checkout sessions. A completed payment is honored even if its webhook
+arrives after withdrawal or another release. `parts retire` closes sales and cancels
+future subscription billing, preserving already-paid periods. `--upgrade included` may
+add rights; changing it back cannot revoke promised or already-granted releases.
+
+`intentMinutes` is 30–1440 and controls the approval intent before Checkout. Stripe chooses
+the Checkout Session's default expiration, keeping retry parameters stable. Download
+credentials last five minutes. Reconciliation happens once per grant rather than per file.
+The studio can configure its abuse rate limit; it is not a spending cap.
+
+`refundWindowDays` enables buyer self-service refunds when present and positive. It counts
+from the current payment's paid timestamp, including renewals. Otherwise ask the seller.
+`refundEndsSubscription` cancels future billing only after a successful full refund.
+Pending or failed refunds keep billing intact. Credit-only invoices have no charge to refund.
+`immediateDelivery: true` adds the consumer immediate-delivery acknowledgement beside Pay;
+the seller chooses it to match its full licence and obligations.
+
+A public test-card payment gets no protected files until the owner identifies the order
+and runs `parts test-access <order>`. This authorizes that claim only while the shop remains
+in test mode. Reissue needs new approval. Never approve an unknown test buyer. Use a second
+studio for tests: one Worker has one Stripe key/mode, and switching a live shop to test
+interrupts its live buyers. A grant or proof from test never becomes a live purchase.
+
+Claims, download tokens and pristine backups live in `.homie/paid-parts`, outside public
+source. Back them up privately. A long-lived Ed25519 proof cannot download; a short-lived
+grant can. Updates derive from the purchased licence. A verified backup restores offline;
+new delivery and updates require the seller to remain reachable. There is no project escrow.
+
+If a claim is lost, `parts recover <seller>/<part> --order <order>` generates a new private
+claim and public claim hash. Give the hash and Stripe receipt to the seller. The seller
+matches the payer/receipt in Stripe and runs `parts reissue <order> --claim-hash <hash>
+--receipt-verified`. Never pass `--receipt-verified` on the assistant's own word. Reissue
+revokes the former claim and downloads. An order ID alone proves nothing. A healthy local
+claim cannot be overwritten by recovery. Transfer requires the purchased terms to allow it.
+
+`parts manage` creates a fresh Stripe portal session. Without a local record, a seller's
+configured `purchasesPortalLogin` lets Stripe authenticate the buyer and provide billing and
+receipt access for assisted recovery. Run refunds only when requested by the person.
+
+Paid resource setup uses the `shop connect` page for `TURNSTILE_SITE_KEY` and
+`TURNSTILE_SECRET` (hosted fallback), and `CDP_API_KEY_ID` and `CDP_API_KEY_SECRET`
+(live Base). Machine and fallback readiness are independent. Base is an explicit choice
+with manual refund responsibility; Tempo is disabled. If Stripe cannot record a settled
+Base transfer, the office names the payer, token, atomic amount and transaction. Send any
+owed refund from the studio's own wallet and use `shop refund <order> --manual-transaction
+<hash>` to verify and record it after owner confirmation. Missing storage never authorizes
+an automatic refund. Configure the studio's own Base RPC in purchase settings for recovery.
+
+The recovery status `fulfilled` means the purchased files are available and the entitlement
+has been issued; it is not proof that the buyer downloaded them. An unpaid challenge retains
+a five-minute quote row so a retry uses the same terms and the owner can grant test access.
+It creates no provider object. Cleanup removes that row only if no provider or settlement job
+was ever attached. A paid order whose files cannot be restored needs an owner's manual refund.

package/port/probe.ts

@@ -123,7 +123,8 @@ export function exposePort(net: Netplay<unknown, unknown, unknown> | null, opts:
     rows.push([t, me ? me.x : NaN, me ? me.y : NaN, b.right[0], b.right[1], b.up[0], b.up[1], m, busy]);
     if (rows.length > RING) rows.splice(0, rows.length - RING);
   };
-  const loop = (t: number): void => { sample(t); requestAnimationFrame(loop); };
+  // The position is sampled now; rAF may carry an earlier timestamp on a busy renderer.
+  const loop = (): void => { sample(performance.now()); requestAnimationFrame(loop); };
   if (typeof requestAnimationFrame === 'function') requestAnimationFrame(loop);
   const probe: PortProbe = {
     v: 1,

package/rules/core.ts

@@ -177,7 +177,7 @@ export interface Core {
  * `noted`: told, as it happens, of a value the rules wrote that the runtime changed to make it fit, or dropped (pack.ts
  * `Adjusted`; also `effect`, `think` and `decision`): the handler, what was done, the field's name and what was written.
  */
-export function createCore(c: Compiled, opts: { observe?: (kind: string, handler: string, error?: string) => void; noted?: (kind: string, handler: string, what: string, at: string, written: string) => void; seed?: number; epoch?: number; restore?: SavedCore | null; restoreEpoch?: number; stage?: string; decisions?: boolean } = {}): Core {
+export function createCore(c: Compiled, opts: { moved?: (kind: string, tick: number, input: Readonly<Record<string, unknown>>, before: import('./pack.ts').MoveBody, after: import('./pack.ts').MoveBody) => void; observe?: (kind: string, handler: string, error?: string) => void; noted?: (kind: string, handler: string, what: string, at: string, written: string) => void; seed?: number; epoch?: number; restore?: SavedCore | null; restoreEpoch?: number; stage?: string; decisions?: boolean } = {}): Core {
   if (c.dims !== 2) throw new Error('this release runs rules with space.dims: 2; bodies with height (dims: 3) arrive in a later one');
   const dims = c.dims;
   const tickHz = c.settings.tickHz;
@@ -1002,6 +1002,7 @@ export function createCore(c: Compiled, opts: { observe?: (kind: string, handler
         }
         if (!k.move) continue;
         const b = { pos: e.pos, vel: e.vel, heading: e.heading, grounded: e.grounded, motion: e.mself };
+        const beforeMove = opts.moved ? { pos: e.pos, vel: e.vel, heading: e.heading, grounded: e.grounded, motion: { ...e.m } } : null;
         moveRadius = body.radius;
         run(k.name, 'move', e, 'move', () => (k.move as NonNullable<KindTable['move']>)(b, e.input, moveCtx), 'body');
         // The runtime rounds to 32-bit floats, here and in the browser, so both step from exactly the same numbers.
@@ -1011,6 +1012,7 @@ export function createCore(c: Compiled, opts: { observe?: (kind: string, handler
         naming('body', 'pos'); e.pos = clampIn(V(own(b, 'pos')), body.radius); naming('body', 'vel'); e.vel = V(own(b, 'vel')); naming('body', 'heading'); e.heading = dir(own(b, 'heading'), dims); naming();
         G.note = null;
         e.grounded = own(b, 'grounded') === true;
+        if (beforeMove) opts.moved!(k.name, tick, e.input, beforeMove, { pos: e.pos, vel: e.vel, heading: e.heading, grounded: e.grounded, motion: { ...e.m } });
       }
       // Phase 2: for every entity, its commands and then its tick, starting from a different entity each tick.
       const list = [...ents.values()];

package/rules/host.ts

@@ -58,6 +58,8 @@ export interface HostClock {
 }
 export interface HostOptions {
   game: string;
+  /** The build check compares a movement step before any tick handler can change it. */
+  moved?: NonNullable<Parameters<typeof createCore>[1]>['moved'];
   /** Told of every handler as it ends, and what it threw if it threw (core.ts `observe`): the build check listens. */
   observe?(kind: string, handler: string, error?: string): void;
   /** Told of a written value the runtime changed to make it fit (core.ts `noted`): the build check listens. */
@@ -226,7 +228,7 @@ export function createHost(o: HostOptions): Host {
     }
   }
   if (saved && saved.v !== 1) throw new Error('this save was written by another version of the runtime');
-  const core = createCore(c, { observe: o.observe, noted: o.noted, seed: Math.floor(random() * 4294967296) >>> 0, epoch: saved ? undefined : (Math.floor(random() * 4294967295) >>> 0) + 1, restore: saved?.core ?? null, restoreEpoch: o.restoreEpoch, stage: o.stage, decisions: !o.check });
+  const core = createCore(c, { moved: o.moved, observe: o.observe, noted: o.noted, seed: Math.floor(random() * 4294967296) >>> 0, epoch: saved ? undefined : (Math.floor(random() * 4294967295) >>> 0) + 1, restore: saved?.core ?? null, restoreEpoch: o.restoreEpoch, stage: o.stage, decisions: !o.check });
   let epoch = core.epoch;
   if (saved && (o.startPaused ?? o.restoreEpoch !== undefined)) for (const body of core.bodies()) if (body.driver !== 'bot' && body.owner !== 'reserved') core.seatAway(body.seat, true);
   let lastSaveAt = o.clock.now();

package/rules/pack.ts

@@ -263,12 +263,39 @@ export interface MoveBody { pos: Vec3; vel: Vec3; heading: Vec3; grounded: boole
  */
 export function stepMove(fn: (body: MoveBody, input: unknown, ctx: unknown) => void, body: MoveBody, input: Readonly<Record<string, unknown>>, ctx: unknown, quota: number, motion: FieldList, dims: number, failed: (error: unknown) => void): MoveBody & { used: number } {
   G.left = quota;
+  const bag = coerceFields(motion, body.motion, dims);
+  const target: Record<string, unknown> = {};
+  const work: Record<string, unknown> = {};
+  // Match core.typed: scalar writes round immediately; collections copy on first read and settle at the end.
+  for (const [name, fd] of motion) {
+    const held = (v: unknown): unknown => { naming('body.motion', name); const out = coerce(fd, v, dims); naming(); return out; };
+    Object.defineProperty(target, name, { enumerable: true,
+      get: () => {
+        if (!mutable(fd)) return bag[name];
+        if (work[name] === undefined) {
+          const size = fd.t === 'list' ? 1 + (bag[name] as unknown[]).length * cellsOf(fd.of as Field)
+            : fd.t === 'map' ? 1 + Object.keys(bag[name] as object).length * (1 + cellsOf(fd.of as Field)) : cellsOf(fd);
+          charge(6 * size); work[name] = thaw(fd, bag[name]);
+        }
+        return work[name];
+      },
+      set: (v: unknown) => {
+        charge(mutable(fd) ? 6 * est(fd, v) : cellsOf(fd) === 1 ? 3 : 6 * cellsOf(fd));
+        bag[name] = held(v); work[name] = undefined;
+      },
+    });
+  }
+  body.motion = Object.preventExtensions(target);
   try { fn(body, input, ctx); } catch (error) { failed(error); }
+  try {
+    for (const [name, fd] of motion) if (work[name] !== undefined) {
+      charge(6 * est(fd, work[name])); naming('body.motion', name); bag[name] = coerce(fd, work[name], dims); naming();
+    }
+  } catch (error) { failed(error); }
   const used = quota - (G.left > 0 ? G.left : 0);
   G.left = Infinity;
-  naming('body', 'pos'); const pos = vec3(body.pos, dims); naming('body', 'vel'); const vel = vec3(body.vel, dims); naming('body', 'heading'); const heading = dir(body.heading, dims);
-  naming('body', 'motion'); const held = thawFields(motion, coerceFields(motion, body.motion, dims)); naming();
-  return { pos, vel, heading, grounded: body.grounded === true, motion: held, used };
+  naming('body', 'pos'); const pos = vec3(body.pos, dims); naming('body', 'vel'); const vel = vec3(body.vel, dims); naming('body', 'heading'); const heading = dir(body.heading, dims); naming();
+  return { pos, vel, heading, grounded: body.grounded === true, motion: thawFields(motion, bag), used };
 }
 
 /** How many values `pack` has packed since this was last set to 0: the core reads it to charge a tick for the state it sends. */