feat(scaffold): post-mount readouts + yaw on the post's axis (not world-vertical)

[bradleypmartin]

Surfaced from #285 (PR for #270 round 3) headset smoke (Brad, 2026-06-01). Stub-only — direction TBD; capturing while fresh.

What headset smoke surfaced

#285 extruded the readout back-plate to a depth slab (final 14mm) which got the panel reading reasonably as a solid screen turning rather than a flat decal sliding. Two things still in the way of full presence:

1. Uniform-color slab masks the depth cue at typical pancake viewing distance. "Takes getting into VR to see the depth." (Pre-tracked under feat(scaffold): display-mock visual-language pass on plinth-mounted readouts (post-#252) #270's bezel / rim-glow candidate list — that issue stays the parent for screen-surface chrome.)
2. Yaw axis still reads as detached from the plinth. The readout group yaws around a world-vertical Y through its own center — so even with depth, it reads as a free-floating monitor that happens to be near the plinth, not as something physically mounted to the plinth. Brad (paraphrased):

Instead of rotating the screen around a strict world- or math-z axis, would it be possible to 'attach' it via a post in the plane of the 'drafting board' part of the plinth (where the controls are), and then rotate it on the axis of the post?

Direction (open)

Not pre-committing to a shape. The general idea has two coupled pieces:

• Render a physical post / stem / arm rooted on the plinth's drafting-board working surface, terminating at the readout's mount point. Kills any residual "floating in front of the plinth" read (the parent feat(staging): control plinth hosting interactive UI (sub-epic) #225 §3.5 v3 escape-ladder concern, but addressed by mounting rather than by counter-rotating to surface-tilt).
• Yaw the readout around the post's axis rather than around world-vertical. Since the drafting board tilts ~20° forward toward the user (PLINTH_TILT_DEFAULT = 20° * π/180), a post perpendicular to the working surface tilts ~20° forward too. Yaw on that axis means the readout's face tracks lateral viewer motion with a slight nodding-toward-them quality — closer to the natural angle a viewer holds their head when looking down at a desk-height plinth than world-vertical-yaw is.

Open questions to surface at plan-doc / roundtable time:

• Post visual vocabulary. Thin metal stem? Stubby pylon? Same body color family as the plinth (PLINTH_BASE_COLOR_RGB) or a distinct accent? Should the post itself have any chrome (segmenting, base flange) that reads as "this is mounting hardware"?
• Mount-point geometry on the readout. Pin at the center-back of the slab? Off-center to suggest gimbal-style articulation? Centered on the slab's bottom edge (more "monitor on a stand" reading)?
• Yaw range. Free 360° (matches current behavior — readout always faces user, never reads its own back), or capped to e.g. ±90° from a forward-facing rest pose (more "physical articulation, can be pointed away from you" semiotic)? Capping breaks readability if user walks behind the plinth — probably wrong call for the cluster's audition-context posture; flag for plan-doc.
• Post anchor point on the drafting surface. Per-scene tunable, or scaffold-default behind the readout's footprint?
• Single-scene first or all-four together. The four readout sizes differ (READOUT_PANEL_HALF_WIDTH_* per scene); the post-mount calibration is per-scene-aware. Likely start in one scene (quadrics is the template per feat(staging): control plinth hosting interactive UI (sub-epic) #225's locked pattern) then cluster-sweep.

Composition with adjacent work

• feat(scaffold): display-mock visual-language pass on plinth-mounted readouts (post-#252) #270 (display-mock chrome — bezel / rim glow / etc.). Independent dial; composes orthogonally. Chrome works on the screen face; post works on the mount.
• feat(scaffold): production-value pass on the WorldAxes math-frame indicator (stub) #257 (WorldAxes production-value pass). Sibling concern — both are "PR1-smoke surfaced this is stale" plinth-era visual upgrades that need a production-value pass. Distinct primitives though.
• feat(staging): pancake-vs-VR plinth calibration sweep (#225 E1.4e) #253 (pancake-vs-VR plinth calibration sweep). Post-mount calibration likely shows up there once primitive exists; possibly extends READOUT_* slot tunables to include post anchor + length.
• Parent feat(staging): control plinth hosting interactive UI (sub-epic) #225 §3.5 v3 escape ladder. This is in that family but proposes a different end-state: yaw-on-tilted-axis rather than lock-to-surface-tilt-entirely. Worth re-reading §3.5 v3 at plan-doc time to make sure the framing carries.

Code anchors

• Current yaw implementation: src/scaffold/ui/PanelReadout.ts faceCamera — group.rotation.set(0, Math.atan2(dx, dz), 0) (world-vertical Y).
• Plinth working surface + tilt: src/scaffold/staging/Plinth.ts — PLINTH_TILT_DEFAULT = (20 * Math.PI) / 180, 'surface' slot orientation already tilts children with the working face.
• Per-scene plinth slot for the readout: src/exhibits/quadrics/index.ts (and the three sibling exhibits) — slot localXYZ + orientation: 'surface' / 'world' are the inheritance hooks the post-mount design will likely extend.

Refs

• Surfaced by: feat(scaffold): extrude readout back-plate to a depth slab (#270) #285 (PR for feat(scaffold): display-mock visual-language pass on plinth-mounted readouts (post-#252) #270 round 3) — third smoke verdict on the depth slab.
• Parent: feat(staging): control plinth hosting interactive UI (sub-epic) #225 (control plinth sub-epic). Plan doc: _private/plans/225-control-plinth.md §3.5 v3.
• Sister "plinth-era visual upgrade" issues: feat(scaffold): display-mock visual-language pass on plinth-mounted readouts (post-#252) #270 (screen chrome — orthogonal), feat(scaffold): production-value pass on the WorldAxes math-frame indicator (stub) #257 (WorldAxes production-value).
• v1.0 staging epic: feat(staging): production-quality environmental presence (v1.0 epic) #221.

[bradleypmartin]

Closing as won't-do-in-this-exact-manner after spending some cycles in PR #287 (now closed).

What we tried

Plan doc went through v1 → roundtable HOLD (4 convergent HIGHs on broken rotation math) → v2 architectural rewrite (two-slot: post in its own 'surface'-oriented slot, panel preserves today's world-Y faceCamera) → second-Sonnet PROCEED → v3 → implementation merged to a feature branch.

In-headset smoke surfaced that the actual plinth geometry doesn't match the "near-horizontal drafting table with mostly-vertical post" mental model the plan assumed: the working surface is actually nearly vertical (~70° from horizontal, since the slot-frame tilt parameter measures deviation from vertical, not from horizontal), so the surface normal — and therefore the post — extends nearly horizontally into the scene rather than rising up from the desk.

Combined with the "post yawing rigidly with the panel" tradeoff we accepted in v2 (the post visibly rotates with the panel as it tracks the camera, reading as articulation rather than mounting hardware), the visual gain didn't justify the complexity.

What's next

Filed as a follow-up: pivot to a STATIC post + remove faceCamera from the readouts entirely across all cluster scenes. This is the third domino in the surface-locked vocabulary thread (after #278 thumb glyphs and #280 per-slider value labels) — completes the move to a single static-locked posture for everything plinth-mounted.

Plan doc at _private/plans/286-readout-post-mount.md preserved as the historical record of what was attempted; the new issue will get its own plan doc when picked up.