The snapping model (Shift = cycle mode, Alt = force/free, mode-driven reads via
isGridSnapActive/isMagneticSnapActive/isAngleSnapActive, snapProfile-declared
context) lived only in code and the plan; tools.md still preached the legacy
"Shift = bypass snapping". Close the drift so the architecture review refuses
tool changes that revert to the old pattern:
- tools.md: replace the held-Shift-bypass manipulation policy with the unified
mode-driven model + the single snap read path.
- interaction-scope.md: new "Snapping mode & modifiers" section (contexts, read
path, modifiers, the chip-needs-a-scope rule) + a Rules bullet + the
known-legacy MEP movers (migrate-on-touch) incl. the dual-path constraint
(a bespoke mover must not open a `moving` scope — it re-mounts the generic
mover via useMovingNode).
- review-architecture skill: add interaction-scope.md to the reads and a new
"F. Interaction scope, snapping & modifiers" checklist — new shiftKey-bypass,
ungated grid step, missing snapProfile, a new useEditor interaction flag, or a
bespoke mover opening a moving scope are blockers; touching the legacy MEP
movers forces migration.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
