Route Three.js WebGPU/TSL Work

Route for Three.js r185 with WebGPURenderer from three/webgpu, TSL from three/tsl, and node materials. The installed package and initialized renderer are the source of truth for APIs, backend, attachment limits, and timing support.

Route in four steps

1. Fix the contract

Record the installed revision and initialized backend. Then state:

• the primary observable and whether its contract is metric, identity,

physically plausible, or perceptual;

• the authoritative input, units, coordinate frame, scale, topology, time

behavior, target views, and interaction;

• each applicable deployment target and checkable bound for error, latency,

frame time, and peak live memory;

• the reproducible seed, input trace, or camera path required by any comparison

or replay.

Treat missing authoritative inputs as explicit gaps. Canonical claims require an initialized WebGPU backend. Route compatibility teaching only when the user explicitly asks how to apply a fallback.

When the route claims frame time, latency, peak live memory, adaptive quality, or sustained performance, read [composed-route-performance.md](references/composed-route-performance.md) before freezing those bounds.

Complete when: the requested result, source of truth, and every applicable target and acceptance bound are explicit and mutually consistent.

2. Select causal owners

Find the earliest missing cause: data/topology, geometry, field, material, illumination, transport volume, motion, camera/projection, or image transform. When more than one viable mechanism remains, compare the least-complex candidates and name the evidence that rejects each losing candidate. Assign one primary owner to the earliest missing cause, then add only skills that own a requested cause, required input, or verification method.

When LOD, tessellation, impostors, field bands, or simulation extent depend on screen error, read [projected-error-contract.md](references/projected-error-contract.md) before choosing the representation.

Complete when: every requested observable has one owner or an explicit gap, and every selected skill owns at least one necessary item.

3. Close handoffs and presentation ownership

When selected systems exchange physical state, events, or GPU resources, read [cross-system-handoffs.md](references/cross-system-handoffs.md) and close every applicable row before implementation.

Name every producer, consumer, version, execution order, lifetime, and invalidation rule. Allocate depth, normal, velocity, identifiers, histories, or MRT attachments only for named consumers. Reuse one scene render when the shared RenderPipeline already exposes the required signals.

Assign one final-output owner per presentation target. Choose exactly one output conversion:

• scene-linear outputNode with outputColorTransform = true; or
• explicit renderOutput(...) with outputColorTransform = false.

Set renderPipeline.needsUpdate = true after changing outputNode or outputColorTransform. Key temporal state by semantic signal, view, encoding, resolution, jitter, cadence, and reset policy.

Complete when: every cross-system edge closes every applicable handoff row, every allocated resource has a consumer, and each target has one tone-map/output path.

4. Prove the composed route

Verify the no-post or minimum-mechanism baseline first, then inspect the field, geometry, material, depth, velocity, history, and output diagnostics that prove the selected causes. Use mutation or disable controls where a plausible image could hide a disconnected mechanism. Measure the full composition on the target matrix and classify unavailable evidence as unmeasurable.

Read [router-recipes.md](references/router-recipes.md) only when a listed multi-system workload matches the request; adapt its ownership pattern rather than treating it as a preset. Add $threejs-visual-validation whenever a route makes quantitative, temporal, adaptive, compute, or sustained-performance claims.

Complete when: every acceptance bound has direct evidence from the composed route, or the unsupported claim is narrowed and reported.

Installed-skill boundary

Intersect the destination map with the skills actually installed. Report missing owners; keep their requested causes outside the implementation until an owner is supplied.

Destination map

Explicit gaps

Keep these owners outside the public skill set unless the project supplies one:

Route result

Return a compact result shaped like this; include only fields the request uses:

route:
  backend: { required: WebGPU, installedRevision: "", actualBackend: "" }
  contract: { observable: "", truth: "", units: "", frame: "", bounds: [] }
  primaryOwner: ""
  selected: []
  deferred: []
  gaps: []
  handoffs: []
  resources: []
  passes: []
  output: { owner: "", toneMap: "", conversion: "" }
  verification: []
  status: provisional | proven | blocked | unmeasurable

selected is minimal; deferred names a condition that would make each skill necessary. Every handoff closes the applicable quantity/units, frame, time, authority/version, validity/error, ordering, lifetime, and reset rows in [cross-system-handoffs.md](references/cross-system-handoffs.md). Every resource names its format, physical extent, lifetime, and consumers. verification tests the selected cause rather than image plausibility alone.

Routing is complete when every requested observable or constraint has exactly one owning skill or an explicit gap; every selected skill owns at least one item; every cross-skill dependency closes every applicable handoff row; and every verification point tests the selected cause.