feat/discovery

Stale observer element if anchor re-mounts while anchorRect remains non-null

apps/platform/src/components/discovery/FeatureSpotlight.tsx:284

Dependency `[anchorRect !== null]` means the effect only re-runs on null↔non-null transitions. If `anchorRef.current` changes to a different DOM node while `anchorRect` stays non-null (anchor re-mounts due to key change, etc.), the ResizeObserver keeps watching the old `el`. The `update` callback reads `anchorRef.current` fresh so position updates are correct, but the observer fires only for the stale element. Edge case for a one-shot coachmark, but worth noting.

Arrow math simplification is algebraically correct

apps/platform/src/components/discovery/FeatureSpotlight.tsx:321

`anchorCenter - left` is identical to the previous `anchorRect.left + anchorRect.width/2 - left` since `anchorCenter := anchorRect.left + anchorRect.width/2`. Clean simplification, no correctness issue.

Variable name inconsistency: outer `el` and inner `node` both alias anchorRef.current

apps/platform/src/components/discovery/FeatureSpotlight.tsx:276

The effect captures `anchorRef.current` into `el` at setup time (used for `observer.observe(el)`) and then re-reads it as `node` inside the `update` closure. Both refer to the same ref — the dual naming adds confusion and leaves a subtle stale-observer edge: if the anchor element ever re-mounts while `anchorRect` stays non-null the observer watches the old `el` while `update` reads the new `node`. Simplify by using one name (`el`) throughout: `const el = anchorRef.current` at the top, then `if (el && el.isConnected)` in `update` (fresh-ref-read not needed here since the observer fires while the element is connected).

No unit test for the recentered position math

apps/platform/src/components/discovery/FeatureSpotlight.tsx:291

The `position` useMemo is pure arithmetic that could be extracted and unit-tested in isolation (anchor rect + viewport dimensions → {left, arrowLeft, …}). The prior bug was exactly this kind of formula error (~101px displacement). A test would guard against regression. Not blocking — the fix is live-confirmed and E2E covers the outcome — but the gap is real.

`observer.observe(document.body)` fires on every global layout change

apps/platform/src/components/discovery/FeatureSpotlight.tsx:285

Observing `document.body` fires `update()` (getBoundingClientRect read + setAnchorRect state write) on any layout change anywhere on the page — infinite scroll, toasts, sidebar collapse, etc. For the coachmark's short visible window this is harmless, but it deviates from minimal-observer-scope. The stated motivation (contratos table column reflow) is fully covered by `observer.observe(el)` on the anchor itself — when its column header resizes, the anchor's own bounding box changes. Dropping `observer.observe(document.body)` and keeping only `observer.observe(el)` should be sufficient. Also: `window.addEventListener('resize', update)` is now redundant since a viewport resize changes body dimensions and would trigger via the body observer (if kept); conversely, if body is dropped the window resize listener should stay.

`window.resize` listener may be redundant if body observer is retained

apps/platform/src/components/discovery/FeatureSpotlight.tsx:281

A viewport resize changes `document.body` dimensions, so if body is observed via ResizeObserver the `window.addEventListener('resize', update)` fires a duplicate update. If the body observer is dropped (see medium finding above), the resize listener is load-bearing and must stay.