Restricted behavior responses

Select a static object in the atelier, open Behavior…, and choose Custom response. The starting recipe makes the object glow on every third touch. Two travelers contribute to the same counter. Choose its active finish, edit the JSON, preview, save and apply the revision to try it together.

Preview validates the source and shows the active finish; it does not execute the response. Runtime errors leave the previous state and appearance intact. Three faults park that binding until its source or configuration changes. Changing an unrelated object does not clear a parked fault. Check applied response shows the live revision, fault count and source path using the private editor key; an unapplied draft is identified explicitly. This inspection omits private state values, random state and event payloads. Switching between Touch glow and Custom response starts the new behavior with fresh state; editing an existing custom response retains its state.

The authored adapter accepts language version 1 with exactly one onInteract hook. It offers two state fields: lit (boolean) and count (integer, 0–1,000,000). configuration.active and configuration.inactive name the two installed material variants. Source is limited to 3,072 characters and the complete authored configuration to 4,096 canonical JSON characters. A rejected edit keeps the saved world and running room unchanged.

#Language

A program is { "format": 1, "hooks": { "onInteract": [ /* instructions */ ] } }. JSON comments are not accepted. Scalar literals are expressions. The other expressions are:

Operators are not, and, or, eq, ne, lt, le, gt, ge, add, sub, mul, div, mod, min and max. not takes one argument; the others take two. Arguments evaluate eagerly. Arithmetic does not coerce strings; division by zero, nonfinite results and numbers outside ±10¹² fail. Equality accepts scalars. Tick identity remains a decimal uint64 string.

Instructions are:

Observations remain the immutable beginning-of-hook state. setState does not change subsequent get expressions in the same invocation. Use locals for computed values. Locals are shared across blocks within one invocation and discarded afterward.

A simple toggle response:

{
  "format": 1,
  "hooks": {
    "onInteract": [
      {"let":"lit","value":{"op":"not","args":[{"get":["state","lit"]}]}},
      {"setState":{"object":{"lit":{"var":"lit"},"count":{"get":["state","count"]}}}},
      {"if":{"var":"lit"},
       "then":[{"write":"MaterialSelection","value":{"object":{"variant":"active"}}}],
       "else":[{"write":"MaterialSelection","value":{"object":{"variant":"inactive"}}}]}
    ]
  }
}

#Engine boundary

packages/behavior/script.ts compiles validated JSON into an owned, immutable execution plan. It does not evaluate JavaScript, resolve imports, expose globals, perform network or filesystem access, schedule promises, or allow dynamic capability names. Accessor properties, executable values, cycles, exotic prototypes, sparse arrays and prototype-related keys reject at ingress. Diagnostics carry a JSON instruction path such as hooks.onInteract[2].value.

Only the engine supplies read/write/event/job grants to compileScript. Source cannot add grants. The generic interpreter supports the existing behavior hook names, but an embedding adapter must declare which hooks it actually schedules. The shared custom-response adapter rejects clock/spawn hooks instead of accepting source that the room would never execute.

Fixed language limits are 512 syntax nodes, depth 20, 64 entries per collection, 32 locals, 1,024 evaluation/statement/loop steps and eight staged commands per invocation. Data observations/results have an 8,192-unit limit and cumulative logical allocation has a 65,536-unit limit. Units count visited values, keys and string characters; they are not a measured VM heap-byte limit. Generic source has a 16,384-unit limit. The smaller authored-source/configuration limits also apply in the atelier. Authors cannot raise any of these budgets.

Ordinary commands are buffered until evaluation finishes. Job requests stage in the enclosing behavior transaction during evaluation so their IDs can be used by later instructions. The host BehaviorRuntime then validates and atomically commits those commands, jobs, state, random stream and outbox. A failed script never starts an executor. Engine integrations must run scripts inside that transaction; a standalone arbitrary callback context does not provide transactional storage. Invalid component values, missing material variants, schema errors, exceptions and exhausted budgets roll back. Existing instance, invocation, event and command bounds remain in force.

The relay executes shared responses using its admitted actor pose and reach checks. Private counters/execution records stay in its checkpoint; clients receive only the public material selection. Duplicate intents use the existing persisted receipt/high-water mechanism. A relay restart restores the private count. Ordinary browser replicas do not execute the source authoritatively. The generic async adapter below does not automatically enable jobs in saved shared-room object responses; that host integration remains separate.

#Runtime choice and remaining gates

The existing trusted JavaScript module API is useful for operator-installed code but cannot interrupt arbitrary loops or remove ambient JavaScript capabilities. Embedding a general VM or WASM runtime would additionally require a separately verified instruction/memory budget, import/host-function bridge and data marshalling policy. Neither alternative is claimed to have been implemented or benchmarked here.

The selected interpreted data language provides a small, auditable surface for bounded object responses and reusable engine hooks. A native trusted callback is the performance baseline, not a security substitute. The comparison and limit-exhaustion measurements are recorded with acceptance evidence. This does not implement general JavaScript compatibility, asynchronous creator jobs, creator UI isolation or the full milestone-13 permission/tool system. Public untrusted creator hosting remains disabled pending those gates and broader hostile-content qualification.

Run npm run check, npm test, npm run test:browser:behaviors, npm run test:browser:scripts and npm run bench:scripts. Each browser command owns a separate isolated editor/relay because live updates must retain world identity. They exercise installed Touch glow and custom responses with two real travelers. Acceptance evidence records the exact tested source and remaining limits.

#Sensor-driven responses

In a tile world, 2D sensor response uses the separate engine.sensor-script@1 adapter and an onEvent hook. Connect it from a pressure plate's settings. The default recipe follows occupancy; event fields and durable cursor behavior are documented in Scripted 2D sensor responses. The creator-visible state remains lit and count; the engine separately owns plate occupancy inside the private state component. The wrapper uses one of the eight per-invocation command slots to record that cursor. Shared relay rooms persist it; lightweight solo saves and the PostgreSQL persistent service do not provide this behavior persistence/execution path.

#Restricted jobs and recorded replay

Run npm run demo:restricted-jobs. The JSON program in games/async-observatory/script.json asks an operator-installed catalog job for a constellation. It receives the typed answer through onJobResult on a later tick. The demo records the result, restores a checkpoint taken while the request was pending, and replays to an identical native checkpoint with zero external I/O calls during replay. It writes test-results/restricted-job-replay.json, containing the baseline checkpoint, result records and expected final checksum. This is a terminal SDK reference, not an editor scene or a shared-room job service.

The public async factory defineScriptBehavior(source, definition, policy) combines untrusted JSON with host-owned state/configuration schemas and explicit capabilities. It hashes its owned source and policy into the executable revision, so changing source or grants cannot reuse an ordinary checkpoint identity. Install the returned module and matching typed job definitions in a trusted BehaviorProgram or operator plugin. Source cannot install executors or request its own grants. Job names are literal compile-time capabilities; arguments are validated again by the runtime's typed request contract. requestJob and cancelJob count toward the same eight-command language limit. The interpreter exposes no promises, network or filesystem globals.

requestJob assigns an invocation-local request ID; store it in declared state to match onJobResult.event.requestId later. Result events include the job ID, outcome, validated result value and bounded error. Cancellation and stale entity/configuration/ code fencing follow the native job contract. A changed binding discards the old result; game code must decide how to reset any of its own pending UI/state when rebinding. Job-capable scripts must execute inside BehaviorRuntime's atomic hook transaction.

Recording is explicit: call startJobRecording(frame) before the runtime's first pump and periodically call drainJobRecords(frame). Records contain request identity, validated request/result, job revision, exact result tick, and binding identity. The in-memory buffer holds at most 256 records; an undrained full buffer rejects the next result instead of silently losing replay evidence. Cancellation caused by a script or binding change is reproduced by replaying those same inputs; external successes, failures and deadlines are recorded. Recording is off by default.

After restoring the matching native checkpoint, call useJobReplay(records, frame) before its first pump. Supply only records after that checkpoint tick. No executor or wall-clock deadline starts in replay mode. Results apply only on their recorded tick and only to a matching request, typed payload and binding. Missing results stay pending; mismatched, late, duplicate or orphaned records reject. Call assertJobReplayComplete() at the intended ending boundary to reject missing or unconsumed results. This completion check is required; advancing some ticks alone is not proof of a complete replay. Replay selection is an explicit host action on each restored runtime, not a serialized executor or an implicit restore mode.

Keep these records private: they can contain configuration and job data. The host owns pairing a baseline, input stream and result stream. The demonstration has no post-baseline user inputs; real games must also replay their ordered inputs and preserve code/world/physics compatibility.

Acceptance record: 17 focused script/job checks pass, including static grants, loop-fault rollback, cancellation, stale binding suppression, native checkpoint identity, replay without I/O, missing/malformed results and wrong request/binding rejection. The runnable reference performs one external lookup, records one result, and reproduces the final native checkpoint with zero replay executions. Type/import/ generated checks and the client build pass with existing chunk-size warnings.

Creator installation and durable hosting: the portable async-response.1 profile now declares typed contracts in a saved package, with independently granted operator executors and durable shared result consumption. See The Creator Lantern for editor installation, the runnable two-player reference and limitations.

Return during integration/qualification: streamed replay windows beyond the bounded in-memory trace and production/native-program replay adapters (portable creator recordings now have browser playback; see below); uninterrupted program upgrades and hosted editor Apply integration (compatible stopped-room migrations are available); deadline/failure/ cancellation traces, mixed inputs, long captures, retention, capacity and full browser/device/crash/backup matrices. External effects still need their own idempotency keys; recording is not an exactly-once transaction with an external service. Final art remains untouched and required.

#Browser recordings for creator jobs

Open /diagnostics.html → Follow the light again → Try the lantern recording. The worker restores a complete native checkpoint, follows recorded movement and behavior inputs, consumes the saved typed job outcome and compares the final sealed checkpoint. A matching hash is required; incomplete traces never receive a success result. Use Choose a creator response recording → Replay recording for another recording, Cancel replay to stop it, and Download replay result for its small comparison report. Import and replay stay in the browser; they do not join a room or upload the recording. The bundled example contains synthetic reference state.

npm run replay:record -- /tmp/my-lantern-replay.json records the same independent creator lantern with one real operator-approved lookup. It verifies replay before writing a new file (existing files are preserved unless --replace is explicit). The source in tools/cli/record-creator-replay.ts demonstrates integrating recording with an installed world-response program. packages/testkit/job-replay.ts exposes sealJobReplay, readJobReplay, applyJobReplayCommand and replayJobRecording for capture/playback tools. The original restricted-observatory SDK demo remains available.

The world-response-jobs.1 envelope includes the full world, baseline checkpoint, ordered commands, typed result records, final tick/hash and an outer checksum. The browser reconstructs the world's installed restricted response program and uses unavailable executors with an explicit zero-execution check. It verifies checkpoint content/program identity and the full final checkpoint, including native physics. No executable module names, source imports or arbitrary JavaScript are loaded from the file. Native operator programs require a separate pinned replay adapter; this profile does not silently substitute a world-only program for one of those baselines.

Limits are 16 MiB per recording, 4,096 commands, 4,096 advanced ticks, 256 job results and the existing world/source limits. Only ordinary input, pause, interaction, behavior input (onInteract/onEvent), event drain and advance commands are accepted. A recording cannot directly dispatch onJobResult. A dedicated worker has a 60-second deadline and is terminated on success, error, cancellation or page exit. Raw recordings include private baseline/job data; the downloadable comparison report contains only summary counts, hashes and job outcome names/ticks.

Requests issued after the restored baseline recover their recorded opaque request ID by entity, job/revision, request tick/value, binding scope/generation and sequence. This preserves script state even though process-local ECS handles can change on restore. Multiple matching identities reject. Existing pending requests still use their saved IDs. Missing records remain pending and fail the final completeness check; wrong bindings, wrong payloads, orphaned records and a different final hash reject.

Review later: capture/export of production room baselines plus ordered admission and job journals; native operator-program adapters; large/streamed recordings and retention windows; interruption and worker-timeout stress, imported asset budgets, long input/failure/cancellation traces and cross-device replay qualification. Those remain full-plan work. This bounded portable creator profile does not close all milestone-6/13 replay gates or change the final art requirement.

Acceptance record: eleven focused recording/restricted/native job checks pass, including post-baseline requests, ordered movement, missing/mismatched traces, invalid typed payloads, input budgets, ambiguous identities and stale-job fencing. The generator performs one real lookup, then reproduces the identical native checkpoint with zero replay executions. A real browser plays the bundled sample, rejects missing results, reloads a valid file and releases the replay worker after each outcome. The interface was visually reviewed. The browser harness's client and retained-engine builds pass with existing chunk-size warnings. Integration caught and fixed the sample's static asset route; it is now a retained hashed asset. Production exports, native adapters and broader qualification remain open as described above.

#Live movement takes

Creators can opt to Continue in a new take when full. The host seals each bounded take and starts the next separately named take before verifying the previous one in a separate process; there can still be an unrecorded gap during the handoff. Continuation stops at the eight-take workspace limit or if the next take cannot start, and the editor shows the reason. New continued takes retain a series identity across room ownership changes. Once two or more takes are verified, choose Replay series in the editor and use Previous take and Next take in the studio. Each take is loaded and checked separately through the open same-origin editor; gaps, removed takes and unfinished takes are disclosed. Download series now packages the verified takes as a single JSON file for later use without the editor. Open it in replay studio and use the same take navigation; each take is independently checked in the browser. Series are limited to eight takes and 128 MiB, with a 16 MiB per-take replay limit. A browser fixture downloaded a synthetic two-take series, closed the editor and replayed both takes; malformed manifest checks passed. Large files, mobile memory use and a live-room series export remain to qualify. A two-traveler test checked ordered saved metadata, an ownership-change test checked persistence, and a browser fixture checked forward/back navigation and the closed-editor message. The browser fixture used sample replay data rather than a live multi-take journey. Takes made before series metadata was added remain individually replayable; reconnecting an open series and live end-to-end series playback remain to qualify. Pending creator jobs can make the preceding take partial. A two-traveler live test checked that the next take starts while the first is verifying and replayed successive takes; the status was visually reviewed with representative data. Sealed takes remain recoverable after interrupted verification. An attempted eight-take run exceeded its 20-second polling window; the full limit, sustained worker resource use, long sessions, chat notice timing, packaged live deployment and restart behavior remain to qualify. A take is saved to the persistent authoring volume after sealing and before verification. If verification is interrupted, Recover and verify reruns verification before the take can be replayed or downloaded. A live restart test recovered a sealed creator take and confirmed room-owner fencing; the control was visually reviewed. On a healthy planned shutdown, the host saves travelers and attempts to seal an active take for later verification without waiting for replay. A connected-traveler restart test recovered a creator take. During a take with creator responses, the editor also offers Finish now: it keeps the committed creator prefix and completed job results without waiting for outstanding jobs, marks an incomplete take, and allows a new recording to start. A live room test checked the partial replay and next start; the control was visually reviewed with representative data. Concurrent result timing, long takes and shutdown deadlines remain to qualify. If a creator job is pending at shutdown, the host can preserve a partial take with movement, observed events, committed creator events and completed job results; unfinished results are absent. If the creator snapshot is unavailable, it falls back to a take without creator responses. The editor and replay identify these limitations. A live pending-job restart test recovered and verified the committed creator prefix without rerunning external jobs; the new replay wording still needs visual review. Running takes now save a recoverable checkpoint roughly every 450 host frames without ending the take. If the room stops unexpectedly, Recover and verify can restore the last saved prefix, which is labeled because later activity may be missing. Completed creator results are retained when available; unfinished jobs are marked incomplete. A live pending-job test restored checkpoint bytes after restart and verified the saved prefix without rerunning jobs; the recovery labels were visually reviewed with representative data. This test simulated the interrupted file state rather than killing the host process. Checkpoint I/O, abrupt process death, long takes and storage failures remain to qualify. Failed seals or a stop before the first checkpoint can still leave a take incomplete; long takes and shutdown deadlines remain to qualify. A broader host lifecycle run timed out in the database-loss and storage-failure-during-drain cases. An isolated rerun passed the storage-failure case; database-loss timed out again after 30 seconds but passed a subsequent instrumented rerun in 22 seconds. Its timing remains to qualify.

New takes retain each traveler’s name at first entry, including people who join later. Replay uses these names in the map, selector, events and world view; duplicate names are distinguished and older takes use numbered labels. A live join/reconnect recording and a representative browser fixture passed; later name changes are not recorded. Names are included in exported recordings. Owners may opt in to including room chat in a take; the option is off by default. Messages are stored in downloads and replay results as observed text and shown on the timeline; they are not reexecuted as new chat. A two-traveler live recording captured both sides, a default take omitted chat, and a representative browser fixture checked scrubbing and literal rendering. The take stops near its 512-message cap. Large bursts remain to qualify. Players now see an in-game recording indicator on the chat button and in the chat panel while opted-in chat capture is active, including when they join after it starts; older clients receive a room notice in chat. A live two-traveler test checked start, stop, late join and a default-off take, and the chat notice was visually reviewed with representative data. Full mobile layout and reconnect timing remain to qualify.

Run npm run dev:movement and open the printed private editor URL. The retained-take demo uses .data/movement-lantern.17; earlier demo directories are preserved. Join the room in one or more browser profiles, expand Keep shared movement, name the take and start recording. Walk to the gold circle labeled The Quiet Garden and interact to visit the garden. Take the portable lantern from its stand, open your satchel to carry or stow it, then return to the editor and choose Finish and verify. Choose Replay in studio to open and verify the saved take directly, or download it and select the file in the studio later. The one-time same-origin handoff does not put the editor key in the studio URL; allow pop-ups if your browser blocks the new tab. A two-traveler browser journey verified the handoff and the controls were visually reviewed. New takes show a playable, scrubbable top-down map on the common host-frame timeline, including recorded action markers, committed response and job-result markers, and a selector for places. Search recorded moments or use Previous and Next to reach any event; selecting a traveler’s action follows that traveler. A browser check with 150 sample actions covered later-page selection, search and empty results, and the controls were visually reviewed. Long real recordings and mobile layout still need qualification. The map represents paths. The top-down map caches movement paths during forward playback and rebuilds them on backward scrubbing. A 16,000-sample two-traveler browser fixture matched the previous drawing, including a rejoin gap; real long sessions and device performance remain to qualify. Show world view opens an engine-rendered reconstruction of the saved authored scene and recorded traveler positions, following a selectable traveler with the same playback and scrub controls. A two-traveler browser journey verified both scene histories and switching viewpoints. A browser journey verified opening, scrubbing and closing the view; the interior camera was visually reviewed. The replay camera avoids collidable box walls; model-based occluders, other layouts, additional character motion states and multi-device graphics qualification remain to review. The view projects shared changes seen by the selected traveler during movement replay, including item visibility, doors, props and observed lighting. A focused browser test checked a lantern pickup and a backward scrub. It is not a complete authoritative room reconstruction: changes between movement ticks and some creator responses may be absent. If the combined scene projections exceed 8 MiB, the view retains the last reconstructed scene with a notice; if a traveler’s scene cannot be constructed at all, it falls back to the saved authored scene. Markers remain on the timeline. Older takes without shared frame numbers still verify without a map or world view.

Recorded authored-body interactions can now include the committed shared states before and after the action. Replay requires a matching accepted physical event, checks the revision and unchanged shared fields, cross-checks both states against the room-state catalog, and joins the transition to the room history. A live gate reversal and pickup reconstructed two consecutive transitions without gaps, and an altered transition was rejected; the studio shows the result. SQL execution, spawned-body interaction transitions and broader mixed histories remain open.

Recorded rider alignments now retain the room frame used by the host. Replay applies the same floating synchronization and rider carry to the previous traveler checkpoint and compares the resulting next checkpoint. A two-rider spawned-cargo round trip passed on both backends and rejected an altered frame; a live authored-body room also replayed an ordinary action from the deck. The studio reports the alignment count. Other mixed action sequences and full SQL transaction replay remain to qualify.

Room-physics contact samples now include travelers supported by moving bodies. Replay checks support identity and transform against the traveler simulation, along with position, velocity and grounded state. A live two-rider spawned-cargo round trip passed on both backends and an altered support was rejected; the studio shows the take. Locked action alignment on moving bodies and broader mixed-history qualification remain open.

A final pending spawned-body creator change is now retained as a terminal physics boundary even if the room never runs another physics step. Replay applies the recorded program preparation and checks the final frame without advancing time. A live take raised and removed the stones without a physics gap, and a terminal-boundary fixture passed on both backends; the studio shows the cleared scene. Terminal boundaries currently cover creator changes, not arbitrary pending cargo or physical interactions. Mixed histories and SQL transaction replay remain open.

When the host observes a matching committed creator event, a spawned-physics preparation records that event ordinal. Replay compares the preparation values with the creator program’s reexecuted public state; mismatches fail. A live stone-spawning take passed and rejected a wrong source ordinal; the studio reports the link. If creator responses are omitted or unavailable, physics inputs remain recorded observations and are not counted as linked. Removals, mixed histories and SQL transaction execution remain to qualify.

Creator-driven multi-place body preparation can now be captured in the ordered physics sequence, including public component values, admitted traveler positions and the resulting native checkpoint. Replay runs the same preparation and checks that checkpoint. A live take spawned the stones without a physics gap and rejected an altered checkpoint; the studio shows the scene. Inputs are still recorded observations rather than linked to the replayed creator event; removals, wider mixed sessions and full SQL transaction replay remain to qualify.

Multi-place spawned-body rooms now record native physics checkpoints, traveler inputs and committed step frames, and replay their cargo preparations inside the physics sequence. A live two-rider round trip included both crossings on Rapier and owned backends; the studio shows the replay. Creator-driven body changes may still create gaps, supported-rider contacts are not linked to movement, and SQL transaction reexecution and wider mixed-history qualification remain open.

Authored cargo transfers can now occur inside the recorded physics event sequence. Replay resolves the matching accepted cargo action, checks its input checkpoint against the current physics owner, reruns cargo preparation and checks the destination checkpoint before advancing. A live crossing with two riders and an observer passed with no physics gap and rejected an unrelated action; the studio shows the destination. This does not rerun SQL or cover spawned-body owners; owned-backend live cargo and mixed crossings remain to qualify.

Physics capture now stores up to 64 ordered interactions and scene revisions between steps. Replay applies each event in sequence and checks its resulting frame; older recordings with separate revision and interaction fields remain supported. Both backends passed an interleaved interaction/revision fixture and rejected reordered events; live door and gate/pickup takes passed, and the studio showed the door take. The multi-event sequence has not yet been exercised in a live room; cargo, unrecorded changes and SQL transaction reexecution remain open.

Physics-scene revisions produced by supported ordinary interactions now carry their originating actor and operation. Replay checks the accepted action, ordering and reducer result against the physics revision configuration before replaying the scene. A live door action passed and a mismatched operation was rejected; the studio reports the link. Revisions without a supported action proof remain recorded inputs, and SQL transaction replay and mixed histories remain open.

Room-physics capture can now retain a single scene revision between steps when the native checkpoint is continuous. Replay invokes the real physics-owner revision with its recorded shared configuration and checks the resulting frame before continuing. A live 3D door action and moving body replayed without a physics gap and rejected an altered revision frame; the studio view was reviewed. The revision input is recorded state, not yet linked directly to its action proof. Multiple revisions or interactions in unsupported ordering still form gaps; owned-backend live coverage and broader transaction replay remain to qualify.

Recorded ordinary interaction resolutions now include room-body membership when present. The action verifier validates membership and uses it for traveler and peer poses before rerunning the existing interaction reducer; matching pickup receipts and shared-state transitions join the room history. A live body-enabled gate-and-pickup take passed and rejected an altered pickup receipt; the studio shows the result. SQL transaction execution and more complex mixed cargo histories remain to qualify.

Physics capture keeps a span continuous across changes to shared state when doors and props are unchanged and the native checkpoint matches; these are the fields the room physics owner uses to decide whether it needs a revised scene. A live gate action and item pickup replayed with no physics gap, and revision-only continuity passed on both backends; the replay view was reviewed. The pickup is not a reexecuted SQL transaction, and configuration changes or native discontinuities still create gaps.

Replay now matches movement inputs to reexecuted room-physics results by authority sequence and compares the entire frame. A live take linked movement inputs and rejected a changed frame; the world view uses those exact matches. Frames without a recorded result remain unlinked; full room transactions, interrupted and mixed histories remain to qualify.

When available, the replay world view now uses the reexecuted room-physics frame matching the authority sequence consumed at a traveler movement tick, and uses observed body frames when no match exists. A live take verified the presentation inputs, and Chromium opened and scrubbed the world view. The view samples rather than interpolates; body changes without a subsequent movement tick, span gaps, moving-support coverage and full transaction reexecution remain open.

Eligible traveler contacts at room-physics steps now carry movement boundaries; replay compares the recorded place, position, velocity and grounded state with the traveler simulation. A live take checked contacts and rejected an out-of-range boundary, and both physics backends passed focused checks. The studio reports checked contacts. Moving-body-supported travelers are excluded, and this does not reexecute room transactions; long, interrupted and mixed histories remain to qualify.

Eligible recorded physical interactions now capture their traveler movement boundary, and replay checks the recorded interaction place and position against the replayed traveler at that boundary. A live gate interaction passed and an out-of-range boundary was rejected; the studio view shows the count. This check excludes travelers with moving-body support and does not verify every contact or other pose field. Older interactions without a boundary remain replayable. Mixed moving-support and interrupted histories remain to qualify.

New recorded physical interactions carry their operation identity. Replay joins each to a unique accepted room action by traveler, operation, target and physics-step frame bounds; mismatches fail replay. Older interactions without an operation remain replayable and are not counted as linked. A live gate action passed and an altered action was rejected; the studio view reports the link. SQL transactions and the physical interaction pose are not reconstructed by this cross-check; mixed and interrupted histories remain to qualify.

Accepted room-body interactions between captured steps can now be rerun using the same physical interaction and candidate fork, and their resulting frames are compared before subsequent physics steps. A live gate reversal and both physics backends passed focused checks; the studio view reports the interaction count. This checks physical effects, not the ledger transaction or its linkage to movement, and an interaction after the final captured step is not included. Physics configuration changes and unrecorded mutations remain gaps.

Shared physics takes can additionally replay bounded continuous spans of the room-owned physics backend from saved checkpoints, comparing each resulting frame. Recorded traveler contacts are inputs to this replay, not yet derived from the movement replay. Changes between spans are reported as gaps; changes before the first or after the last span are outside the count. Captures are limited to 2 MiB, 4,096 steps and 128 spans; a truncated capture is marked partial. Focused tests cover both backends and a live trusted-room take; the studio view is shown here. Checkpoint capture cost, long sessions, mixed transactions, device coverage and full authoritative transaction reexecution remain to qualify.

This early take records trusted movement inputs plus the shared and collision frames consumed at each tick, plus an ordered journal of accepted and declined shared actions at their observed traveler-tick boundaries. New takes store repeated shared state once and cross-check shared, floating and same-place collision snapshots across travelers on each common host frame. A two-traveler browser test verified the smaller take and reported frame checks; a changed same-frame reference was rejected and a creator-response recording passed. The updated studio also reads older takes; an older studio does not read the new take format. These checks do not reexecute the full shared authority. In a room with a supported installed program, the same take also records its response journal and saved external job results. Finishing waits for pending jobs; retry when they have completed. The studio independently replays the movement tracks and the program response chain, without executing external jobs. The host records when committed responses became visible on the shared frame timeline; this is an observation boundary, not the exact database commit time. New takes capture the host’s known shared state at the start and finish and journal subsequent changed shared states at host broadcast boundaries. A creator-room and two-traveler recording passed, a no-movement fixture rejected a missing finish boundary, and the markers were visually reviewed with representative data. The world view projects them even without a later movement tick, and labels them as observed room states. These are observations, not reexecuted transactions. The studio displays the latest captured resources for the selected traveler during playback, including ability, travel and NPC damage results; changes between snapshots can be missing. A live NPC-and-ability recording and a representative browser scrubbing and traveler-switching fixture passed. Same-frame ordering without player revisions and full live studio combat playback remain to qualify. A live creator-room recording checked the initial observation, and a focused fixture projected it without movement; the baseline is observed host state, not prior transaction replay. A focused fixture also checked a final observation and rejected an invalid traveler boundary; a two-traveler live-room recording captured and replayed the published states. The marker was visually reviewed with representative data. Takes finish early near the 4,096-observation limit. Long live-room recordings, scene appearance and unbroadcast changes remain to qualify. Movement and response state are still verified independently, not yet replayed as a single synchronized room. For recordings with shared revision coherence, replay joins individually verified interaction, transfer, NPC and eligible creator-program transitions into contiguous shared-revision spans. For creator updates, it checks the program projections before and after the event, the preceding shared revision and unchanged non-program fields. A live creator-job recording reconstructed such a transition without rerunning the external job; older recordings remain compatible. Accepted creator interactions now explicitly link their room transaction to the recorded program event and before/after shared states, including when the public projection is unchanged. A live creator-job recording rejected an action linked to the wrong event and replayed an older take; a focused fixture checked unchanged projections. Mixed histories and full transaction replay remain for qualification. For multiple program events observed in one host batch, replay can use the first event’s projection when each subsequent projection is continuous and shares the same boundary. A focused fixture covers batch continuity and boundary changes; the live creator-room recording still passes. Actual multi-event batches and missing prior states remain to qualify. The studio reports reconstructed transitions and gaps between recorded states, and the downloaded result includes the spans and gaps. Changes before the first or after the last recorded state are outside that count; observed but unsupported transitions are gaps, not reexecuted transactions. A focused fixture covers consecutive transitions, missing revisions and conflicting state, and a two-traveler recording checks the live action chain. The summary was visually reviewed with representative data; mixed NPC and creator histories still need qualification. For supported shared interactions, the studio also reruns the same interaction reducer against the captured state, pose, peers and collision inputs. This checks that reducer’s decision and output, not the subsequent database transaction or other action kinds; those outcomes remain recorded observations. Eligible chest deposits and withdrawals separately replay their deterministic reach, ownership, capacity and item revision checks and the resulting item transfer. The live SQL update is compared against that transfer before commit. New takes also link supported action positions to the recorded movement checkpoint sampled before the transaction; a two-traveler chest browser journey and travel/return recording passed, altered positions were rejected, and older takes replay without this check. NPC and combat recording checks also passed. Yaw and floating-support positions remain unlinked. New takes also link other travelers’ positions in supported interaction and travel decisions to their recorded movement when the published pose matches the sampled motion. The studio reports the number checked. A two-traveler chest browser journey rejected an altered peer position and older takes replayed; a two-traveler travel/return recording also passed. The updated summary wording was visually reviewed with representative data. Stale, untracked and floating-support observations, and yaw, remain unlinked. New recordings also check inventory, item ownership, stored revision and chest count against the input shared state, and reconstruct the complete resulting shared state including equipment removal. New takes additionally capture and verify the before/after player inventory and revision against the live receipt; the studio reports the receipt checks. Verified non-pickup interactions now retain before/after player inventory receipts as well, connecting pickup, equip, stow and supported ability actions through matching player revisions. The replay timeline can show these captured inventory states. A two-traveler pickup/equip/stow test verified the links, rejected an altered inventory and replayed an older take; a shared combat recording also passed. The inventory display itself is unchanged; full live studio playback and other transaction types remain to qualify. Pickup receipts also capture the item revision change and before/after player inventory; replay links pickup and chest receipts sharing a player revision. A two-traveler pickup/deposit/withdraw studio journey rejected an independently valid but conflicting item revision, and older takes without receipts replay. New takes also capture each acting traveler’s owner-visible inventory, keepsakes and gameplay state after ordinary recorded transactions, including creator actions and declined attempts. The studio lists these snapshots by action and lets the owner jump to their timeline position; matching player revisions are cross-checked with recorded proofs and boundaries. A shared combat test captured an earned keepsake at its action, rejected a conflicting snapshot and replayed an older take; a representative browser fixture checked the display and navigation. Snapshots are observations, not full transaction reexecution. Cargo action snapshots, large action lists, privacy review and full live studio playback remain to qualify. For supported recorded reward actions, replay now reconstructs award eligibility from the verified interaction and ability result, checks the before/after owner-visible keepsakes and marks earned keepsakes on the traveler’s timeline. The random identity and award time are recorded inputs; replay does not issue another award. A shared combat take checked earned and ineligible outcomes, rejected altered award data and replayed older takes; a focused fixture covers an already-owned keepsake. The timeline marker was visually reviewed with representative data. Creator-driven rewards, multiple rewards and full database transaction replay remain to qualify. The studio displays the selected traveler’s latest captured inventory from verified pickup and chest receipts and segment boundaries. A two-traveler recording confirmed these snapshots; a representative browser fixture checked scrubbing and traveler switching. Full live studio playback remains for qualification. Ground-item history before the take and intervening inventory transactions are not reconstructed; stale retry with pickup receipts still needs qualification. For successful non-ability interactions, replay reconstructs the resulting shared state and links consecutive action inputs when the room revision is unchanged. The studio reports the combined action-state count. A two-traveler pickup, equip and stow recording verified all three results and an action link in the studio, and an altered pickup state was rejected. New ability takes capture host time and private resource inputs and reconstruct channel start/completion, combat damage, retaliation and the resulting shared state with the same transition as the host. A two-traveler guardian fight and studio replay, channel fixtures and altered-result rejection passed. Run npm run dev:sentinel, open its printed private editor and use Keep shared movement to record a fight. For non-navigating combat rooms, automatic target respawns now record host time and before/after shared state; replay verifies the transition and the studio marks and projects the return. A two-traveler defeat-and-return browser journey, altered-time rejection, event-frame projection and older-take compatibility passed. Navigating NPC takes also capture host time, traveler positions and private gameplay inputs, then rerun navigation, attacks, respawns and resulting shared state. Eligible NPC traveler inputs are linked to their recorded movement checkpoints at the host sampling boundary, with the check count in the studio. A two-traveler pursuit and attack passed in the studio, including moving travelers; altered positions, NPC and damage states were rejected, and older takes remain compatible. Ability inputs and NPC damage states sharing a durable player revision are now cross-checked, with a count in the studio. A two-traveler attack-then-ability journey rejected a separately consistent but mismatched player state; older takes remain compatible. Intervening revisions and other transaction kinds are not reconstructed. Travelers on floating supports are not yet linked. Run npm run dev:watch, open the printed private editor and use Keep shared movement to record the encounter. Long takes, navigating respawn combinations and intervening unrecorded mutations remain open. The two-traveler recording covered deposit, withdrawal, altered inventory and unrelated shared state, and older-take compatibility. The updated summary was visually reviewed with representative text; the full studio transfer journey remains for qualification. Database commit and unrelated transaction steps are not replayed. Transfers involving authored cross-place body membership or poses requiring relocated spawned-body validation remain recorded observations. It is not a full-room replay: ordinary portal and return transitions are recorded as boundaries between verified movement segments. Eligible travel and return decisions rerun the authority’s gateway reach, behavior, sensor and item requirements and chosen arrival; successful saved poses and revisions are compared with the receipt. Arrival collision checks, full SQL transactions and poses requiring relocated body membership are not replayed. A two-traveler round trip verified accepted and declined travel and rejected altered arrivals and receipts. Accepted travel and return now also record the resulting room state; replay verifies that only the room revision changed and includes those transitions in the reconstructed room history. A two-traveler round trip reconstructed both revisions, rejected an altered room result and replayed an older take without recorded room results. Full transaction replay and mixed travel/creator histories remain to qualify. Gameplay-enabled travel and return proofs additionally reconstruct saved gameplay transitions and link player revisions, with a count in the studio. The round trip checked both transitions, altered gameplay rejection and older-take compatibility. A focused rule fixture covers cancellation of a channel on travel and recovery on return after defeat; those paths still need live-room qualification. The summary was visually reviewed with representative text. A take that cannot reproduce its final native state is rejected. At least one participant must be connected at the start. Participants can join, leave and reconnect under the same identity. Each uninterrupted segment has its own checkpoint and host-frame interval; timeline markers and world playback show the gaps. A focused live-room and browser journey verified a guest leaving, reconnecting and replacing their connection from another tab; altered or overlapping segments were rejected. Ordinary portal travel and return-to-entry can continue a take, with place markers and automatic following. A two-traveler live-room and browser journey verified a round trip, including the demo with its creator program active. World playback uses the game’s traveler rig, derives its poses from verified motor states and shows supported equipped items. It also retains authored patrol characters and their recorded poses through forward and backward scrubbing. Persistent trusted rooms currently reject patrol worlds, so this currently applies to compatible imported recordings, not takes made through the shared recording demo. A focused simulation fixture and browser world-view fixture passed and were visually reviewed. The scene budget can limit long recordings; patrols beyond the 32-actor render limit are omitted with a note. Long recordings, patrol conversations and device performance remain to qualify. A two-traveler recording verified equipping, stowing and backward scrubbing with a visible lantern; unsupported attachment models are identified in the view. A two-traveler browser journey confirmed walking and join/reconnect playback; jumping, swimming, seated and ragdoll poses still need visual qualification. A result download was canceled during a slow editor run and a subsequent studio load timed out; the download URL now remains available for a minute, but the complete editor journey must be rerun. Playback projects recorded host-owned authored bodies, spawned rigid bodies and shared platforms onto the traveler’s reconstructed scene without modifying the verified movement state. A focused stone-and-lift fixture and browser world-view fixture verified the displayed poses; long real recordings and other configurations still need qualification. A focused body projection check and the authored-cargo and editor/replay browser journeys passed. Temporary admission pressure is retried for up to 15 seconds before showing an error; persistent overload and admission load still need qualification. Linked action and creator-response states are projected at their recorded frame using a separate simulation, including a final action with no later movement tick. A two-traveler pickup/equip/stow browser journey, a final-action fixture and a saved creator-job result at its recorded frame passed. The studio projects event-driven changes throughout a segment, including beyond 256 events. Same-frame shared updates are now combined for world projection: the last state at that frame is displayed, while the original recorded events remain in the take. The timeline groups same-frame room observations into a counted moment. A 400-update fixture verified the final state and a later frame without a gap, and the resulting world and timeline were visually reviewed in a browser. Intermediate changes within one frame are not individually visible; events across many distinct frames can still reach the projection budget. A burst of more than 256 changes between movement ticks is bounded; earlier history remains available, a visible note marks the gap, and event projection resumes after the next tick if the shared 30-second projection budget is not exhausted. A focused simulation fixture with a reduced burst limit checks continued projection and burst recovery. Event projection now forks the current verified simulation using its compiled world instead of recompiling it each time; a focused fixture checked checkpoint equality, isolation and scene changes. In a local three-fork comparison, the prior checkpoint path took 5.2 seconds and the new path 1.9 seconds; this is not a general performance guarantee. Playback offers ½×, 1×, 2× and 4× speeds. If scene projection reaches its size limit, the studio keeps the last available scene and labels world changes as paused while traveler movement continues. A focused browser fixture checked speed and fallback behavior, and the controls were visually reviewed; real long takes and mobile layout remain to qualify. The 30-second scene projection budget remains, and long takes, other world configurations and device performance still need qualification. At the size limit, later frames retain the last reconstructed scene with a notice while traveler movement continues. Forward playback applies changes incrementally; backward scrubbing reconstructs the selected frame. Focused fixtures cover both limits; long takes and other creator-response types need qualification. Recorded authored ragdoll body poses also drive physical skin projection in replay without changing verified simulation. A focused joint fixture and existing physical-skin tests passed; a browser world-view fixture was visually reviewed before and after the recorded body-pose change. Real shared ragdoll takes, other poses and bodies changing between recorded ticks remain to review. Spawned rigid cargo crossings preserve rider recordings across alignment and place handoff boundaries. A two-rider round trip with a creator job passed on both physics backends; the replay was visually reviewed and rejects a changed destination checkpoint. Accepted cargo crossings also rerun the production native preparation from the ledger’s saved checkpoint and reconstruct each committed rider pose and revision against the transaction receipt; altered results are rejected. The replay reports the number of cargo preparations checked. Accepted cargo crossings also record their resulting shared state and reconstruct the room revision when other shared fields are unchanged. Two-rider round trips on both physics backends and an authored handoff joined the room history, and an altered room revision was rejected. Older cargo takes without a recorded result remain supported but were not rerun in this check. SQL atomicity, transaction eligibility, clearance and alignment transitions are not reexecuted. A focused Rapier live-room and browser journey also verified authored linked cargo with two riders and a nearby observer, after both an early freeze refusal and a destination preparation refusal. The timeline records these declined attempts and their reasons. Disconnects during handoff, other authored-body configurations, and creator response markers with mid-take arrivals and reconnects need broader qualification. To try spawned cargo, run npm run dev:passage, open its printed private editor, raise the stones, have riders step aboard the middle stone, start Keep shared movement, and use the golden gate in each direction. This demo uses .data/stone-passage.5; earlier saves are preserved. The room retains completed takes on its persistent authoring volume, with at most eight takes, eight distinct travelers per take, up to 32 segments per traveler, 16,384 total traveler ticks and a 15 MiB hard capture budget. The recorder automatically begins finishing around 16,320 ticks, 12 MiB or 1,000 actions, and releases travelers after sealing before verification. Actual duration depends on traveler count and state size; large linked response recordings and abrupt unusually large events can still exceed the final combined size limit. The editor displays current use. Creator-program takes also finish early near response event, byte or job-result limits, and the editor shows the creator-event count. A live recording with an artificially near-full result budget sealed and replayed; large bursts and many pending jobs remain to qualify. A focused two-traveler room test verified automatic completion and resumed movement, and a 4,100-tick take replayed beyond the former limit. The usage controls were visually reviewed. A take interrupted before verification is listed as incomplete after restart. Files include traveler identifiers, nearby traveler names and shared item ownership, private inventory revisions, and private ability state including resources and cooldowns; new takes sample saved inventory revisions and gameplay state at each movement-segment start and end, and replay checks matching revisions against recorded actions and NPC events. Creator-room, travel, NPC-combat and join/reconnect recordings passed; an inconsistent same-revision inventory was rejected and older takes remain compatible. The summary was visually reviewed with representative data. These are durable snapshots, not reexecution of every player transaction. New boundaries also include owner-visible keepsakes, with same-revision consistency checks; server-only award audit data is excluded. A shared combat recording captured an earned keepsake, a conflicting same-revision fixture was rejected, and the panel was visually reviewed with representative data. Expand Saved traveler snapshots in the studio to inspect the selected traveler’s inventory, keepsakes and resources and jump to a boundary. The snapshots are not continuous state, and downloaded room replay results include this private data. A creator-room recording verified timeline delivery; a representative browser fixture checked traveler switching and navigation and was visually reviewed. The exact interval between saved boundaries and unrecorded player transactions remain to qualify. Only the workspace owner can capture or download recordings. Back up the authoring volume along with the room database. Complete dynamic scene reconstruction, synchronized authoritative action replay, and broader restart and performance checks remain to do.

A focused two-traveler live-room test checked access, recorded movement, restart retention, interrupted takes, accepted and declined action resolutions, a chest deposit, withdrawal and stale retry, tampered transfer and chest identity rejection, and exact movement replay. The existing shared chest commits regression hit the room-busy admission guard twice in this environment, before the test reached transfers; rerun it during qualification. A replaced owner was fenced from modifying the saved takes. A browser journey recorded, downloaded and verified a walk in the replay studio, including a verified lantern interaction, and the editor and replay controls were visually reviewed. A combined server and browser journey verified movement plus a creator response and saved job result, including retry while a job was pending and recovery of an interrupted take. A two-traveler browser journey exercised the shared frame map, action marker, playback and scrubbing; the resulting map was visually reviewed. A creator-job test covered response marker ordering, a missing-marker rejection and a saved result without another external execution. New takes link each observed creator-response batch to the public program state; replay compares the reconstructed state with the recorded shared state and the next traveler input when available. Older takes still replay without this comparison. New takes also require one shared state per room revision across movement, interaction and cargo decision inputs, creator responses and room events; the studio reports reused revision links. Two-traveler NPC and chest journeys rejected conflicting but independently valid state and decision inputs, older takes remained compatible, and combat, creator, chest and two-backend cargo takes passed. Unrecorded transitions, full synchronized authoritative action replay and native sensor marker coverage remain for qualification.

#Hosted response recording and export

npm run dev:record starts a separate creator-job room on port 5197, with its own PostgreSQL directory at .data/recording-lantern.1. Open its printed private editor URL and expand Keep a response replay under Shared room. Name the capture, choose Start recording, then join the room in two browser profiles. Touch the lantern and wait for its saved response. Return to the editor, choose Finish recording, then Download recording. In Open replay studio, choose that JSON file and select Replay recording. The recording remains available through host restart until its owner removes it.

The hosted-response-jobs.1 format captures the hosted response runtime, separately from the existing world-response-jobs.1 player simulation recording. Its baseline contains the accepted world, engine/release identity, portable program manifest, private native component snapshot and behavior tick. Ordered admitted interactions, idle admissions and host steps commit their input, before/after checkpoint hashes and saved job results in the same SQL transaction as the state change. Rolled-back interactions leave no event. Export verifies a contiguous journal and replays every native step before returning a file. Browser replay independently does the same without loading an external executor and compares the exact final native response checkpoint. A successful result covers this program runtime; movement, inventory, combat, physics and an entire room's network traffic are outside this format.

Only workspace owners can list, capture, export or remove these recordings. Files include private response state, actor identifiers and job requests/results. The normal shared-state stream still exposes no private response state. Pending jobs must finish before the recording can be completed; callers can retry Finish. Incomplete event chains, missing outcomes, changed programs and mismatched native states cannot export a successful recording. Finishing a capture does not stop the room. The host allows one active capture and eight retained recordings per room, with at most 4096 admissions, 256 job results and 16 MiB. Reaching a budget marks the capture incomplete and leaves gameplay running. Download a completed recording before using Remove recording to free a retention slot.

Control schema migration 12 adds the recording header/event tables and includes them in the backup catalog. Existing retained engines/databases are preserved; they do not automatically acquire the new schema or UI. Use the new dedicated demo or a deliberately provisioned schema-12 database. Live program Apply asks the owner to finish a running capture first. Native operator modules/systems and sensor inputs use the pinned adapters described below; unsupported programs reject at capture start.

Review later: process kills at capture admission/stop/export boundaries, crash and lease takeover during an external job, maximum-size/time-budget captures, repeated capture cleanup, backup restore with populated recordings, slow/revoked owner sessions, routed Coolify deployment and cross-device browser qualification. Full room/movement recording, additional operator adapters and final art remain separate unfinished work; this feature does not close every roadmap replay gate.

Acceptance record: the focused PostgreSQL journey passes against the real schema, including rollback leaving no capture event, pending-job stop rejection, exact replay without a second external execution and rejection of missing results/journal rows. The real two-browser journey captures a shared response, restarts the host, downloads the retained recording and imports it into the browser studio: the native checkpoint matches, one saved result is consumed, zero external executions occur and the worker is released. Recording controls and the completed replay were visually reviewed. Type/import/generated checks, client/retained-engine builds and the isolated dev:record health/shutdown smoke pass. Existing bundle-size warnings remain; broader checks listed above are deferred, not passed.

#Native operator and sensor recordings

Run npm run dev:record-native for The Remembering Garden on port 5198. It uses .data/remembering-garden.1 and prints its private editor URL. In the editor, start a recording under Keep a response replay. Join the room in two browser profiles, touch the lantern once and wait for its shared light. Walk to the golden threshold to the right of arrival and choose Visit the quiet garden. Step onto and off the golden sensor circle; the garden light responds for both travelers. Finish the recording, download it and import it in the replay studio. These are the same saved authoring, shared room and replay controls used by portable recordings.

The hosted-native-responses.1 profile adds an exact installed-program manifest: operator ID/revision, grants, private bindings, module/component/job contracts and native systems. Statically bundled adapters support the listening-lantern operator, public-lantern component versions 1/2 and creator responses with sensor bindings. Files cannot select import paths or provide executable code. An absent adapter or changed revision/grant/program rejects. New operator plugins need an explicitly bundled adapter; the replay API accepts a trusted adapter resolver for that purpose. Every restored runtime replaces external job execution with a throwing stub and consumes saved outcomes. Native systems run in the host's scheduler order.

Sensor geometry remains host-authoritative. Capture records the admitted, sorted occupancy flags, not client-provided on/off messages. Replay derives the same enter/exit events from the saved private occupancy cursor and those inputs. Sensor responses, interactions and program steps share one durable behavior tick and checkpoint chain. Their native state and recording event commit in the same room transaction; failed commits leave neither behind. Unchanged occupancy adds no input. Missing or altered sensor admissions cannot match the target checkpoint. Recordings retain the original program baseline and remain usable after host restart.

This is response-program replay, including native systems and sensor events. It does not re-simulate the geometry/motion that produced occupancy, replay player movement, inventory or combat, or support dynamically spawned plugin entities yet. Native adapter availability is tied to the installed build; unknown historical executable revisions require their retained adapter. Existing limits and owner-only privacy rules apply. No database migration is added beyond schema 12.

Review later: long mixed sensor/job traces, grouped body/traveler occupancy under host takeover, job failure/cancellation capture, parked native modules, public v2 migration captures, maximum-budget export and cancellation, populated backup restore, old-engine/new-adapter compatibility, routed Coolify and cross-device qualification. Whole-room capture, dynamic plugin entity lifecycle and the final character, environment and arrival art pass remain unfinished. Deferred checks are not passed.

Acceptance record: two real PostgreSQL journeys pass: mixed native-system/job/ sensor capture with atomic rollback, duplicate-occupancy suppression, missing-input and adapter-revision rejection, and public native components with no jobs. The existing portable PostgreSQL capture check also passes. Both browser profiles pass capture, shared presentation, host restart, download and imported replay; the native journey includes sensor enter/exit for two travelers and matches its final checkpoint with one saved job result and zero external executions. Eleven existing sensor checks pass. Type/import/generated checks, client/retained-engine builds and the isolated launcher health/shutdown smoke pass. The garden and replay result were visually reviewed. The garden is a functional reference, not approved final environment or character art.

#Visual behavior graphs (F70)

World format 73 adds Editor → Behavior graphs. Choose a static, detached response object, add event/variable/condition/action nodes, and connect an output to another node. Drag node titles to arrange the graph. The inspector also exposes each connection as a select control. Persistent memories define typed number, boolean or text defaults. The active-finish switch is lit.

The first profile supports touch, spawn and connected-area events; variable Set, Add and Toggle; typed equality/order conditions; and Activate, Deactivate, Toggle or boolean-driven finish actions. The active finish unlocks author-selected pickups, conversations or gateways. Area events supply occupied, entry count and exit count; touch events supply actor and action. Event values are checked against the event that reaches the node. Graphs support 32 nodes, 12 memories and bounded acyclic connections, including branches and shared downstream nodes.

Preview compiles the saved behavior-graph.1 data into the existing restricted script contract inside a graph-response.1 response package. The package retains the graph/positions and checks the generated source, state schema and defaults against it. Existing capability checks, command/instruction budgets, transactional fault handling and private shared-room state apply. Material views and unlocks use the ordinary room projection; area changes use the existing admitted sensor event path. Both local and shared-room progress recover through their existing behavior saves/checkpoints.

The graph, package, object binding and sensor links stage as one saved content revision with ordinary saved Undo/Redo. Save changes, then publish a playtest to try it together. Editing a graph creates a new content-addressed module and starts its memories from the authored defaults, including when editing its layout. Unused graph packages are removed automatically. The initial save profile uses whole-content conflict handling so it cannot overwrite a concurrent saved edit.

Focused delivery: tests/behavior-graphs.test.ts passes a saved source/undo, three-touch shared branch/unlock, retained room-state restore, local save restore and area entry/exit journey. Type/boundary/wire checks pass. A browser check used the actual node connection and preview controls and saved all five starter nodes without page errors. The milestone screenshot was visually reviewed. The integration also fixes a demonstrated sprite-schema import cycle and retains stationary action changes in the normal durable save.

Deferred review: finer graph edit merging, preserving compatible memories across graph revisions, layout-only state preservation, a larger action palette, long graphs, mobile input, cross-browser/device regression, live revision stress and performance qualification. These remain outside the fixed feature counter.