# Created on `2026-05-27`

## Status

`closed`

## Purpose

This note closes the stale-routing gap for the retained browser-spatial support
rows already frozen under `Phase 2R-B` and the landed `Phase 3R-F` owner trio:

- `pmndrs/postprocessing`
- `pmndrs/react-postprocessing`
- `pmndrs/drei`
- `pmndrs/three-stdlib`
- `pmndrs/maath`
- `pmndrs/uikit`
- `pmndrs/zustand`
- `pmndrs/leva`
- `pmndrs/use-gesture`
- `pmndrs/react-spring`
- `@react-spring/core`
- `@react-spring/shared`
- `@react-spring/types`
- `@react-spring/parallax`
- `@react-spring/rafz`
- `@react-spring/animated`

The ownership packet and later live-product docs already kept these rows
subordinate, but the state board and `v6.3` row-source pack still left them on
the generic `phase0r_permissive_eval_then_implement` lane.

## Current judgment

- no previously landed product packet needs reopening
- no product code change is justified from this pass
- `Phase 3R-F` remains closed for the landed browser-spatial owner trio
- no default widening packet is open for the subordinate support stack

## Current live owners

The practical browser-spatial stack is already owned by the landed trio:

- `mrdoob/three.js`
- `pmndrs/react-three-fiber`
- `pmndrs/xr`

Adjacent first-party reference and support grounding also already exists without
promoting the subordinate rows into separate live implementation lanes:

- `pmndrs/uikit` for world-anchored spatial UI grounding
- `pmndrs/postprocessing` for effect-boundary grounding
- `pmndrs/drei` for helper-stack grounding
- `pmndrs/zustand` for state, gesture, and motion grounding

That means the retained value from the remaining rows is subordinate support
value only, not new owner-lane authorization.

## Source-backed subordinate slices

### Browser effect and viewer sidecars

Retain only:

- `pmndrs/postprocessing` as the bounded post-effect substrate
- `pmndrs/react-postprocessing` as the bounded React wrapper above that
  substrate

Do not promote:

- either repo as a browser-spatial runtime owner
- either repo as a standalone viewer or editor foundation
- either repo into a default follow-on widening packet

### Browser helper, utility, and interaction sidecars

Retain only:

- `pmndrs/drei` as the bounded helper and abstraction shelf above
  `pmndrs/react-three-fiber`
- `pmndrs/three-stdlib` as the maintained utility shelf beneath the landed
  owner trio
- `pmndrs/maath` as the narrow math-helper substrate
- `pmndrs/uikit` as the bounded spatial-UI layer beside `pmndrs/xr`
- `pmndrs/zustand` as the bounded local state substrate
- `pmndrs/leva` as the bounded authoring and debug control sidecar
- `pmndrs/use-gesture` as the bounded gesture and pointer-input substrate

Do not promote:

- any of these rows into standalone product-shell ownership
- any of these rows into a separate browser runtime lane
- any of these rows into a default next implementation packet

### Browser motion parent and package rows

Retain only:

- `pmndrs/react-spring` as the bounded browser-side motion substrate
- `@react-spring/core` as the lower-level spring-runtime core package
- `@react-spring/shared` as the lower-level motion-utility and fluid-observer
  package
- `@react-spring/types` as the narrow type-contract package
- `@react-spring/parallax` as the bounded layered-motion and explainer sidecar
- `@react-spring/rafz` as the bounded frame-loop and scheduling package
- `@react-spring/animated` as the bounded animatable-component package

Do not promote:

- the parent row into a standalone motion-owner lane above the landed
  browser-spatial owner trio
- any package row into a separate HyperTwist implementation lane
- any package row into a default widening packet outside the parent
  `pmndrs/react-spring` context

## Sequence correction

Current canon should therefore use:

- `phase2rb_browser_support_subordinate_gap_eval_only`
- `no default widening packet open`
- `retained subordinate browser-spatial support row`

The generic `phase0r_permissive_eval_then_implement` lane is stale for these
rows because:

- `Phase 2R-B` already closed their support-plane ownership boundary
- `Phase 3R-F` already landed the owner trio above them
- later reference-incorporation backfills made some support slices explicit in
  canon without converting them into separate live implementation rows

## Required canon posture

Current authority surfaces should now say all of the following consistently:

- these rows are not straight permissive implementation candidates
- these rows remain subordinate beneath the landed `3R-F` owner trio
- these rows do not reopen browser-spatial product-code ownership by default
- later widening may happen only if a concrete browser-side sidecar gap is
  proven after the landed owner trio and existing first-party reference-grounded
  support surfaces
