editor: in-world selection UI across wall / door / window / stair

[sudhir9297]

What does this PR do?

Two related themes ship together on this branch:

1. In-world selection UI parity across wall / door / window / stair. Every selectable structure node now has a 3D handle set (side arrows, height arrow where it makes sense, endpoint / corner pickers) plus a ground action menu (move / duplicate / delete) that lives under the level group instead of the screen-space HTML floating menu. Curved and spiral stairs get rise / width / inner-radius / sweep arrows on the stair node itself, since they don't have segment children.

2. Registry-driven floorplan handles + move overlay across all structure nodes. Wall, door, window, fence, column, shelf, elevator, roof-segment, slab, ceiling, and stair now publish their 2D affordances (resize / rotate arrows, brace spread, rotation gizmo with curved arrow, live overrides during drag, tap-action descriptor) through the registry, replacing per-node ad-hoc 2D code. The floor-plan mover adopts the 3D junction planner for walls, axis-locks wall move to the wall normal, commits at the last pointermove (not pointerup), and the 3D mover publishes to useLiveNodeOverrides so 2D ⇄ 3D edits stop racing.

Other polish along the way: door wall-hit placement, building bbox pinned to cursor during move, wall corner billboard + perpendicular grid snap, dropping 45° angle snap from wall + fence drafts (Shift now = fine step), level naming helper, ambient floorplan render during building moves, fence / stair move fixes, and wall auto-ceiling sync.

How to test

1. bun dev and load any scene with at least one wall, door, window, and straight + curved stair.
2. Wall — click a wall, drag the side arrows to retarget the wall under the cursor, drag the height arrow to change height, drag an endpoint to move it (linked-wall junctions should re-mitre). Corner pickers should billboard toward the camera; perpendicular grid snap should engage when dragging near grid lines.
3. Door / Window — select one, drag the 3D side arrows to resize width, drag the height arrow, click the ground move icon and drop it on another wall. Press R to flip side, E to toggle open/closed (door only). Door placement should snap onto the wall under the cursor.
4. Stair (straight) — select a segment: side arrows resize width, length arrow extends the run, height arrow changes the rise. Ground menu duplicates / deletes the segment. Repeat on the parent stair to see the parent ground menu (move / duplicate / delete) — duplicate should preserve the chain orientation.
5. Stair (curved / spiral) — change stairType to curved in the panel: the rise / width / inner-radius / sweep arrows appear. Hover the width arrow → a thin indigo ring traces the outer edge at handle height. Hover the inner-radius arrow → the same ring appears just inside the inner edge. Drag each arrow and confirm the geometry tracks the cursor, with the opposite edge pinned for inner-radius drags.
6. Floor plan — registry handles. In the 2D panel, select a column / shelf / elevator / fence / roof segment / slab / ceiling / stair: each should show its own resize and rotate arrows (curved-arrow rotation gizmo where applicable). Dragging should preview live via useLiveNodeOverrides; releasing should commit cleanly with no snap-back.
7. Floor plan — wall / door / window move. Drag walls, wall endpoints, doors, and windows in the 2D panel. Walls should axis-lock to their normal; commit should match the 3D view with no snap-back on release.
8. Drafting. Draft a new wall and a new fence — neither should snap to 45°. Hold Shift for fine step.
9. Building move. Move a building — the bbox center should pin to the cursor, and the floorplan should render ambient under the move.
10. bun run check-types should pass.

Screenshots / screen recording

To be added in a follow-up comment.

Checklist

• I've tested this locally with `bun dev`
• My code follows the existing code style (run `bun check` to verify)
• I've updated relevant documentation (if applicable)
• This PR targets the `main` branch

[Aymericr]

This is a large, well-structured PR. The new NodeDefinition.handles descriptor system, FloorplanMoveTarget commit hook, floorplanScope, and EditorApi inversion-of-control interface are all clean additions to core. The node-package work (stair arc-resize handles, door/fence/elevator/column/shelf/roof-segment/slab/ceiling floorplan affordances) is consistently placed in packages/nodes/src/<kind>/ — no legacy-location regressions found. Package dependency arrows are respected: core stays Three.js-free, viewer doesn't reach into editor.

One blocker needs fixing before merge. A handful of suggestions to consider.

---

🔴 BLOCKER (1)

packages/editor/src/components/editor-2d/renderers/floorplan-registry-layer.tsx — three new node.type dispatches in a framework editor component.

// Line ~265
const isOpeningPlacementActive =
  movingNode?.type === 'door' ||
  movingNode?.type === 'window'
  // …

// Line ~300
if (node.type === 'wall') {
  const wallOverride = liveOverrides.get(id)
  if (wallOverride && …) effectiveNode = { …node, …wallOverride } as AnyNode
}
const contextNodes =
  node.type === 'wall' && liveOverrides.size > 0
    ? mergeWallOverridesIntoNodes(nodes, liveOverrides)
    : nodes

Rule: wiki/architecture/node-definitions.md → "Any new case 'door'|'wall'|… in a framework package is a blocker — the behaviour belongs on the kind's NodeDefinition."

Fix for the wall override branching: add def.floorplanSiblingOverrides?: (nodeId, liveOverrides, nodes) => Record<string, AnyNode> (or a boolean def.mergesLiveSiblingOverrides) to NodeDefinition; floorplan-registry-layer calls it when present instead of checking node.type. WallDefinition supplies the mergeWallOverridesIntoNodes implementation; every other kind returns the raw nodes unchanged.

Fix for isOpeningPlacementActive: add capabilities.wallOpeningPlacement: true to doorDefinition and windowDefinition; read it via nodeRegistry.get(movingNode.type)?.capabilities?.wallOpeningPlacement instead of the === 'door' || === 'window' check.

---

🟡 SUGGESTIONS (4)

1. handleDragging in useViewer
(packages/viewer/src/store/use-viewer.ts + selection-manager.tsx + use-node-events.ts)

State is set exclusively by packages/editor's NodeArrowHandles. The pattern mirrors cameraDragging (also editor-set) and is the correct IoC direction, but "handleDragging" is leaked editor vocabulary in the viewer public store. Rename to something more generic — inputDragging or externalDragging — so it reads as "the host is mid-drag" rather than "handles (an editor concept) are being dragged." The comment in use-node-events.ts already says cameraDragging and handleDragging are siblings conceptually; the name should reflect that symmetry.

2. Per-kind resize state in useEditor (12 new fields)
(packages/editor/src/store/use-editor.tsx)

resizingWallHeight, resizingDoorHeight, resizingDoorWidth, resizingWindowHeight, resizingWindowWidth, resizingStairSegmentWidth … (8 more). These exist so measurement overlays know which dimension is being dragged. The generic HandleDescriptor already knows what's active; a single field like activeHandleDrag: { nodeId: AnyNodeId; label: string } | null would serve the same purpose without N per-kind states, and it would automatically cover kinds added in future PRs.

3. engageEndpointMove kind dispatch in editor-api.ts
(packages/editor/src/lib/editor-api.ts:26)

if (node.type === 'wall') { editor.setMovingWallEndpoint(…) }
else if (node.type === 'fence') { editor.setMovingFenceEndpoint(…) }

This if/else if will need to grow for each new endpoint-move kind. Consider either (a) unifying movingWallEndpoint / movingFenceEndpoint into a single movingEndpoint: { node; endpoint }, or (b) routing via NodeDefinition (a capabilities.endpointMove capability provides the store setter). The bridge is small now but sets a precedent.

4. movingNode?.type === 'building' in floorplan-panel.tsx
(packages/editor/src/components/editor/floorplan-panel.tsx)

Minor and arguably acceptable — building is a structural container, not a "kind" in the node-kind sense. But if the building-move scope eventually needs to vary by container type, the same capability approach above applies.

---

🔵 NITS (2)

Naming: wall utilities reused for fence/stair

getWallGridStep, isWallLongEnough, snapPointToGrid are exported from @pascal-app/editor's wall-drafting module and imported by fence/floorplan-move.ts and stair/floorplan-move.ts. These are generic segment utilities that happen to live under wall-specific names. Rename to getSegmentGridStep, isSegmentLongEnough (or relocate to core) so they're legible to future kind authors without the "am I supposed to use the wall version?" confusion.

Wall note in wall/definition.ts

// Height arrow + side-move arrows + corner pickers all live in the legacy
// `wall-move-side-handles.tsx` component. The registry handle path didn't
// render correctly for walls specifically; revisit once that's diagnosed.

No action needed, but a tracking issue would help so the diagnosis doesn't go cold.

---

Verdict: needs changes before merge. 1 blocker (3 lines in one file), 4 suggestions. The two node.type === 'wall' guards and the === 'door' || === 'window' check in floorplan-registry-layer.tsx are the only changes blocking merge; everything else is solid.