# Automated two-client recording rehearsal For the procedural building scenario and Chinese presentation script, see [CONSTRUCTION_RECORDING.md](CONSTRUCTION_RECORDING.md). For two independently authored Package builders running in one world, see [MULTI_AGENT_RECORDING.md](MULTI_AGENT_RECORDING.md). From the repository root on Windows (Node 22+): ```powershell node scripts/authoring/record-rehearsal.mjs --bins target/investor-authoring-validation/debug --character-cache target/my-authoring-demo/authoring/characters/meshy-hero --dry-run node scripts/authoring/record-rehearsal.mjs --bins target/investor-authoring-validation/debug --character-cache target/my-authoring-demo/authoring/characters/meshy-hero ``` Replace both example paths with your compiled binaries and completed character cache. Build requirements and the initial character-generation workflow are in [AGENT_AUTHORING_DEMO.md](AGENT_AUTHORING_DEMO.md). The client needs `catalog-v2-process-e2e,retained-presentation-wire-v1`. The runner also requires the existing local Edge dependencies, a trusted mkcert installation and FFmpeg with the libx264 encoder. Use `--ffmpeg C:/path/to/ffmpeg.exe` if it is not on PATH, or explicitly choose `--frames-only` to retain native frame sequences without producing an MP4. Dry-run checks prerequisites and creates no run. The recorder selects `demo-host.mjs --recording-edge`. This bundles the same Edge Worker with the installed esbuild and uses Wrangler's binding adapter plus Miniflare/workerd directly, retaining the migrated D1/R2/DO persistence directory. It avoids the live-reload development proxy, which exited during the initial native recording attempts. No remote service is deployed and no authority, admission, checkpoint or publication rule is bypassed. The automatic sequence is: 1. Create a fresh isolated local host, Edge store, CDN and authoring workspace. 2. Copy and validate the completed character cache; publish character revision 1. 3. Open two visible native observer windows, auto-Deploy, and start both cameras. 4. Once both cameras have staged two seconds, locally generate the revision-2 outpost and ground-pulse Luau source. Save the exact input, seal and upload it through AuthoringRuntime, and wait for authoritative tick activation. 5. After a hydration grace period, use the existing real-player skill probe to cast ground-pulse, producing a terrain hole. Both native windows keep running. 6. Finalize both recordings. Require old/new character digests, presented cast and impact cues, and matching one-brush terrain receipts in native frames. 7. Once both recordings seal, require the server still to report `serving`, save `recording-end-authority.json`, and stop the isolated host. PNG analysis runs offline. Align the common wall-clock interval and encode a 1920×540 side-by-side MP4. Stop only this run's process trees, including on failure or Ctrl+C. Output defaults to a unique ignored `target/recording-...` directory. `result.json` is written only after verification (and successful encoding when enabled). `rehearsal.mp4` is the composite; `left/` and `right/` retain PNGs, reports and native `session.json` manifests. `timeline.jsonl` records generation, publication and cast timestamps. Failures leave `failure.json` and logs for diagnosis. Config and private keys in `host/` are local secrets; share the MP4, not the whole run. Default capture is 120 seconds at 8 actual samples/second; the MP4 uses 30 fps with held frames. This is not a claim of 30 unique rendered samples/second. `--seconds 120 --fps 15` increases capture quality and storage cost. Native capture is bounded to 3,600 slots and 16 GiB raw staging per camera. Allow many gigabytes of disk space; PNG analysis after capture may take several minutes. Gaps and native visual-review verdicts remain in the result instead of being hidden. Do not minimize or close either observer while recording. The recording contains the native game surfaces, not the desktop/console or microphone audio. The windows may overlap on the desktop; each captures its own presented swapchain. Wall-clock alignment does not imply the two clients rendered on the same server tick. Source generation here is deterministic template-based Luau generation, not a new LLM or paid Meshy request. Character generation is reused from the supplied cache. This is the local checkpoint compatibility-world authoring demo, not normal Raid or the remote/native-Codex publication gate. Validation of orchestration helpers: ```powershell node --test scripts/authoring/recording-evidence.test.mjs scripts/authoring/authoring.test.mjs ``` Full acceptance requires running the command with actual binaries, a downloaded cache and FFmpeg, then reviewing `rehearsal.mp4` and `result.json`. ## Executed recording — 2026-09-21 ### Built-in player duel Add `--builtin-duel` to use the engine's built-in player rigs and two different camera angles. A third game connection acts as the attacker: it walks using ordinary player input, aims at the feet of the right native client's player, and activates the newly published ground-pulse skill. Player positions are only read; there are no administrator movement or damage commands. The probe requires the impact to land within 1.5 m horizontally of the target and the target to physically drop by more than 0.2 m. Movement, aim and the subsequent position trace are saved in `host/skill-proof.json`. Both native clients must present the built-in rigs, the cast/impact cues, and matching terrain receipts. Character-package cache arguments are still required because this mode reuses the existing publication fixture; the visible players use the built-in characters. The two windows are independent fixed cameras, not first-person recordings of the attacker and target. Executed evidence: `target/whitepaper-duel-20260921-02/result.json` is verified. The impact was 0.9533 m from the target's feet and its authoritative position dropped 1.7637 m. Both clients presented activation 4 and matching terrain receipts. The 115.342-second composite and the 35-second whitepaper excerpt passed full FFmpeg decoding. Each full capture contains 943 frames with 17 writer-capacity drops after the excerpt interval. Native visual verdicts remain `review`; this is gameplay evidence rather than a rendering acceptance claim. The shareable excerpt, preview, verification and usage note are in this run's `whitepaper/` directory. ### Generated-character recording `target/whitepaper-recording-20260921-07/result.json` reports `verified` after a real two-client run. The 90-second, 8 Hz captures contain 720/719 frames (one right-camera writer-queue drop). The aligned MP4 is 85.25 seconds, 1920×540, 39,119,865 bytes, and passed a complete FFmpeg decode. Both native clients presented revision 2 and activation 5 with matching terrain brush-log receipts. The end-of-recording authority snapshot reports `serving`. The shareable files are in that run's `whitepaper/` directory, including before and after screenshots and a Chinese usage note. Visual analysis remains `review`: the effect/terrain changes trigger pop/exposure detectors, and visual inspection found temporary distant-terrain holes during rebuilding. This is technical demonstration evidence, not a clean rendering acceptance claim. On this workstation, preserved binaries are in `target/whitepaper-recording-binaries`; the task-specific Cargo build cache was cleaned after recording. FFmpeg was found at `C:/Python312/Lib/site-packages/imageio_ffmpeg/binaries/ffmpeg-win-x86_64-v7.1.exe`.