Skip to content

Cagematch: can the IWSDK agentic scene composer build a station from a case definition? #577

Description

@gidich

factory_step: room_generate

lane: C

Operator approval, 2026-08-22

"I approve the MCP, please delegate to give it a go in the background"

This unblocks the cloud-backed @meta-quest/metavr MCP (Quest device management + Meta asset
library search), which the research flagged as NOT CHECKED and needing approval. Note the distinction
so nobody conflates them: the IWSDK MCP server itself (iwsdk mcp stdio) is MIT and local and never
required approval — it is part of @iwsdk/core@0.5.3, which we already pin.

Also within D14: the operator amended D2's hold for cagematch exploration of this class.

What the composer is — VERIFIED by the superagent against primary sources

Not a runtime system, not codegen: an agent-operated authoring environment emitting a validated,
hashed, deterministic scene document.

piece what
iwsdk.scene.v1 declarative JSON — units, resources, nodes with transforms + typed components, environment, lights; recursive modular imports; documentHash/runtimeHash SHA-256 identity
managed workspace editor Playwright-managed browser: runtime preview + visual editor, watches scene files, validates, swaps atomically
MCP server iwsdk mcp stdio — small public scene surface: scene_open, scene_render_file, scene_get_state, scene_get_capabilities, scene_select, scene_set_camera, scene_screenshot, scene_set_preview_visibility, scene_measure_image_regions
iwsdk-scene-composer skill ships in the upstream repo's guidance dir — the literal thing behind the marketing name

It passes D9 by documentation, not inference: "the runtime never receives prompts, source images,
annotations, assumptions, or review history."
The agent composes at AUTHORING time; the runtime replays
a frozen artifact. Every render returns source/composed/runtime hashes plus a PNG SHA-256 — the D13
freeze-and-record identity, native to the format.

Version state — we are already current, do not "upgrade" as the slice

@iwsdk/core, xr-input, scene-composition are all 0.5.3 = latest (published 2026-08-11) and our
spike pins exactly those. What shipped since 0.5.3 is an empty set. The one gap is
vite-plugin-dev at 0.5.1 vs 0.5.3 — a small delta (snap settings, draw distance,
bridgeReadyTimeoutMs, a UIKitML preflight module). Bump it only if the evaluation needs it, and say so.

THE QUESTION THIS CAGEMATCH ANSWERS

Can a CASE DEFINITION drive the composer, or does it only take a human prompt?

That is the blueprint-factory question and no upstream doc settles it — the superagent marked it
NOT TESTED. Everything else about IWSDK is already researched; do not re-survey it.

Concretely: take ONE station we already ship — peds_asthma_parent_anxiety_v1, environment
pediatric_urgent_care_bay_v1 — and determine whether its authored fields (environmentId, equipment
list, actor placements) can produce an iwsdk.scene.v1 document via the MCP surface, deterministically
enough that the same case yields the same runtimeHash twice.

Scope — this is a DECISION, not an adoption

  • Work only in apps/arena/ui-xr-iwsdk-spike/** and your evidence dir.
  • Do NOT touch apps/ui-xr/**. The production runtime is raw three.js with no @iwsdk/* dependency
    and a 9,859-line main.ts; migrating it is not this slice and not decided.
  • Do not delete or weaken any existing spike test.
  • No new eslint-disable, @ts-ignore, @ts-expect-error, or OPENCLAW_SKIP_HOOKS.

PRE-STATED NEGATIVE RESULTS — any one closes this card SUCCESSFULLY, no adoption

  1. The MCP surface cannot be driven headlessly from this machine (two failed setup attempts closes it).
  2. A case definition cannot reach the composer without a human authoring step in the middle.
  3. The same case definition produces a different runtimeHash across two runs — non-determinism fails
    D9/D13 regardless of how good the output looks.
  4. Producing a station scene requires touching apps/ui-xr or rewriting the runtime.

A cagematch that can only close by adopting produces an adoption whether or not one is warranted. Record
the negative as a finding; that is a successful close.

Findings storage — superagent ruling, follow it exactly

  • Verdict of record: a tracked file docs/openclinxr/cagematch/findings/iwsdk-scene-composer.md.
  • Heavy artifacts (screenshots, scene JSON, hash dumps) stay under .openclinxr/evidence/<slice>/
    and are referenced by relative path from the finding file.
  • Any artifact a verdict actually rests on gets promoted to tracked explicitly.
  • A licence-ledger row for @meta-quest/metavr if you use it — record what it sends and where.

Standing brief lines

  • If a proof cannot pass as written, OR passes trivially, SAY SO IN YOUR FIRST REPORT at the moment you
    find it, then proceed.
  • If the premise is false, say so immediately and stop. A dead premise is the most valuable return.
  • Commit as soon as you have a defensible finding, before writing your report — reaps are frequent and a
    reaped session cannot be resumed at any age.
  • Report any out-of-scope wrongness you saw and are not fixing: name the object and what it looks like.
  • The orchestrator grades all pixels. Produce renders; do not grade them yourself.

Report with these exact headers, colons included: IN-SCOPE: OUT-OF-SCOPE: CLAIM: NOT TESTED:

done_when

  • run:pnpm iwsdk:verify
  • exists:docs/openclinxr/cagematch/findings/iwsdk-scene-composer.md
  • changed:docs/openclinxr/cagematch/findings/iwsdk-scene-composer.md

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions