feat/discovery

prevKeysRef not reset when `enabled` goes false — spurious toast on re-enable

apps/platform/src/components/discovery/DescubreMenu.tsx:90

When `enabled` is false the effect's early-return at L90 skips the `prevKeysRef.current = current` update. So the ref holds the last enabled-session's keys. If `enabled` later flips true with a changed item set (e.g. orgId changes, PostHog flag briefly toggles), `left = prev − current` can be non-empty and fires a spurious 'next step' toast — even though the user didn't complete anything. Fix: `if (!enabled) { prevKeysRef.current = null; return; }` so the guard resets the ref when going dark, making the next enable behave like a fresh mount.

eslint-disable suppresses toast/t/router from deps — stable in practice, undocumented

apps/platform/src/components/discovery/DescubreMenu.tsx:114

toast, t, and router are used inside the effect but omitted from [itemsKey, enabled]. They are stable refs in practice (useToast/useTranslations/useRouter all memoise their returns). The suppression comment gives no indication of this assumption, so a future reader or upgrade could miss a stale-closure regression silently.

Multi-line comment blocks violate 'one short line max'

apps/platform/src/components/discovery/DescubreMenu.tsx:81

CLAUDE.md: 'Never write multi-line comment blocks — one short line max.' The 5-line block at L81-85 in DescubreMenu.tsx and the 5-line block at L22-25 in QueryProvider.tsx both violate this. Each could be a single sentence: '// toast the next step when a gap item is retired — skip initial load' and '// any mutation may change the gap — blanket-invalidate instead of per-hook tracking'.

Toast-trigger logic (prev-key tracking) has no unit test

apps/platform/src/components/discovery/DescubreMenu.tsx:89

The prevKeysRef + itemsKey effect has three non-obvious edge cases — toast on departure, skip on first load, skip on spurious enabled-flip — none of which are exercised by the existing integration tests (which validate gap computation, not the toast trigger). A React Testing Library test rendering with items=[a,b] → [b] would cover the core path and the fix for finding #1 above.

prevKeysRef typed as string[] — could be SpotlightFeatureKey[] to avoid cast

apps/platform/src/components/discovery/DescubreMenu.tsx:87

useRef<readonly string[] | null> forces the `as readonly string[]` widening cast at L95 (because Array<SpotlightFeatureKey>.includes(string) doesn't type-check). Typing the ref as useRef<readonly SpotlightFeatureKey[] | null>(null) keeps the union type end-to-end and removes the cast. Minor type hygiene.

itemsKey join(',') fragile if SpotlightFeatureKey ever contains a comma

apps/platform/src/components/discovery/DescubreMenu.tsx:88

keys.join(',') is unambiguous today (catalog keys are simple identifiers). A future key with a comma would produce hash collisions. Safer sentinel: keys.join('|'). Low practical risk — the catalog is controlled — but worth noting for future key additions.