PRD: Spotlight (⌘K command palette)

TL;DR

We're adding Spotlight, a ⌘K / Ctrl+K command palette to the organization dashboard: an admin presses the shortcut, a search box opens over the page, and as they type they see grouped results. v1 is a launcher — jump to any page, run quick actions (create community, create event, etc.), and see recents — all fed by a single registry so destinations and actions can be added, changed, or removed in one place and stay in sync. It is permission-aware (mirrors the dashboard's existing role gating), multilingual and RTL (English + Hebrew today), and fully keyboard-operable across operating systems. v2 (designed here, deferred) adds live entity search for communities, members, events and reports. The palette is delivered as a new, reusable design-system component.

---

1. Problem & Context

The organization dashboard has grown into a wide, deep product: a dozen top-level areas (Home, Users, Hubs, Events, Calendar, Marketing, Discounts, Facility Management, Payments, Notification Center, AI, Settings) with many second-level pages beneath them — Payments alone holds Refunds, Bank Withdrawals, By User, By Event, and By Budget Line. Reaching a specific page means scanning the sidebar, expanding the right group, and clicking in, every time. There is no fast way to jump straight to a destination, and no single place to trigger common actions (create a community, create an event, start a newsletter); today those actions live as buttons scattered across individual pages.

Search today is per table (for example, filtering the users table). That is useful inside a page, but there is no global "type what you want and go" entry point. Admins who know exactly where they are headed still pay the full navigation cost, and newer or occasional admins struggle to discover where a capability lives at all. The dashboard is also used in Hebrew (RTL) as well as English, so any new entry point has to work in both from day one.

Supporting signal (Product to confirm from data we already have): navigation-depth / sidebar-usage analytics, and any onboarding or support feedback about "where do I find X." This PRD does not invent a number; the qualitative problem above stands on the real structure of the product.

2. Goals & Success Metrics

• Goal: give dashboard admins a single, keyboard-first way to get anywhere and do the common things, lowering the navigation cost of a deep product and making capabilities discoverable, without changing the existing information architecture.

Proposed targets to confirm (starting points for Product, not measured baselines):

• Metric 1 — Adoption: ≥ 40% of weekly-active dashboard admins use Spotlight at least once in a week, within 60 days of general availability. (target to confirm)
• Metric 2 — Repeat reliance: among Spotlight users, ≥ 20% of in-dashboard navigations are initiated through Spotlight (rather than the sidebar), within 60 days. (target to confirm)
• Metric 3 — Efficiency: for Spotlight users, reaching a second-level page collapses from "scan sidebar → expand group → click" to "shortcut → type → Enter" (instrumented as time-to-navigate or click-count to a chosen target). (target to confirm)
• Metric 4 — Action reach: ≥ 25% of the seed quick actions are triggered via Spotlight at least once in the first 30 days, confirming the action layer is used, not just navigation. (target to confirm)
• Non-goals: not replacing the sidebar or changing the information architecture; not a global content/search engine in v1 (no entity-record search until v2); not an analytics surface (Spotlight launches things, it does not display data).

3. Scope

In scope (v1)

• Spotlight as a new, reusable design-system component, deployed in organization-dashboard.
• Open via the OS-appropriate shortcut (⌘K on macOS, Ctrl+K on Windows/Linux) or by clicking the dashboard header search affordance; close via Esc, the "esc" control, or a backdrop click.
• Grouped results: Recent, Quick actions, and Pages (destinations drawn from the dashboard's navigation), with optional scope chips (All · Pages · Actions · …) to narrow.
• Quick actions seed set drawn from real features (create community, create event, create coupon / membership, new newsletter, new notification template, create calendar, manage permissions, run sync).
• Recents surfaced when the box is empty.
• Full keyboard operability: ↑/↓ move within a group, Tab / Shift+Tab move between groups, Enter selects, Esc closes; works across keyboard layouts.
• Permission-aware results: only destinations and actions the viewer's role may reach are shown, matching the dashboard's existing role gating.
• Multilingual + RTL: English and Hebrew, with a full RTL layout pass.
• All states: default / recents, typing, loading, results, empty, error, success confirmation, and the no-permission case.
• The registry (single source of Spotlight entries) and its reachability capabilities (§8.2).

Out of scope (v1)

• The consumer app and any non-dashboard surface (the component is reusable, but only the dashboard is wired up in v1).
• Live search for entity records (a specific community, member, event, or report) — see Deferred.
• Parameterized / inline action execution (for example "create event named X" parsed from the query); actions open their existing flow.
• AI / semantic or fuzzy ranking beyond straightforward matching.
• Per-user customization (pinned favorites, custom shortcuts, reordering).
• Replacing or restructuring the sidebar.

Deferred to vNext (v2)

• Live entity search across communities, members, events, reports, and hubs, with results sourced from one shared search; the UI home for this is already designed in the reference, and it carries the v2 capability noted in §8.2.
• Possible follow-ons (not committed): pinned / favorite actions, parameterized actions, and cross-surface reuse (for example the support tool or partner portal).

4. User Stories

• As a dashboard admin, I want to press one shortcut and jump to any page, so that I stop hunting through the sidebar.
• As a dashboard admin, I want to run common actions (create a community, event, coupon, newsletter) from the same box, so that I don't have to navigate to the right page first.
• As an occasional or new admin, I want to type what I'm looking for in plain words and see where it lives, so that I can find capabilities I don't know the location of.
• As a returning admin, I want my recent destinations offered first, so that repeat tasks are one keystroke away.
• As a keyboard-first user, I want to move, select, and dismiss entirely from the keyboard, so that I never reach for the mouse.
• As a Hebrew-speaking admin, I want the palette to read right to left in Hebrew, so that it feels native.
• As an admin with a limited role, I want to see only what I'm allowed to reach, so that I'm not shown destinations or actions I can't use.
• As the system, I want to present destinations and actions from a single shared registry, so that what Spotlight offers stays in sync as pages and actions are added, changed, or retired.
• As the system, I want to filter entries by the viewer's role before showing them, so that permission rules stay consistent with the rest of the dashboard.

5. Functional Requirements

MUST = P0 (required for launch); SHOULD = P1/P2 (preferred). Behavior and outcome only.

#	Requirement (behavior / outcome)	Priority	UI ref (§7)
FR-01	The system MUST open Spotlight when the user presses the OS-appropriate shortcut (⌘K on macOS, Ctrl+K on Windows/Linux) from anywhere in the dashboard.	P0	Spotlight container
FR-02	The system MUST also open Spotlight when the user activates the dashboard header search affordance.	P0	Spotlight container
FR-03	The system MUST close Spotlight on Esc, on the "esc" control, and on a backdrop click, returning focus to the previously focused element.	P0	§7.3
FR-04	While open, the system MUST keep input focus in the search field so the user can type immediately.	P0	Search field
FR-05	The system MUST present results grouped (Recent, Quick actions, Pages), each group with a header.	P0	Group header / rows
FR-06	As the user types, the system MUST filter and update results live, without a separate submit.	P0	§7.3
FR-07	The system MUST support keyboard navigation: ↑/↓ move within a group, Tab / Shift+Tab move between groups, Enter selects the highlighted entry.	P0	§6
FR-08	Selecting a page entry MUST navigate to that page; selecting an action entry MUST start that action's existing flow.	P0	§6
FR-09	The system MUST show only entries the current viewer's role is permitted to reach, matching the dashboard's existing role gating.	P0	No-permission note / §8
FR-10	The system MUST draw all entries from the shared registry (§8.2) and MUST NOT hard-code destinations or actions in the palette.	P0	§8.2
FR-11	Page destinations MUST be sourced from the dashboard's navigation, so the palette reflects the real information architecture.	P0	Result rows
FR-12	The system MUST render correctly in English and Hebrew, including a full right-to-left layout in Hebrew.	P0	§7.5
FR-13	The system MUST implement every state in §7.3 (default/recents, typing, loading, results, empty, error, success, no-permission).	P0	§7.3
FR-14	The keyboard-hint footer MUST show the OS-appropriate trigger glyph and the navigation keys.	P0	Keyboard-hint footer
FR-15	When the search box is empty, the system MUST surface recent destinations and actions.	P0	Result rows / §7.3
FR-16	The system SHOULD offer scope chips (All, Pages, Actions, plus the v2 entity scopes) to narrow to one group. (confirmed in v1 scope)	P1	Scope chips
FR-17	The system SHOULD emit the analytics events in §8.1 for opens, searches, selections, actions, no-results, and closes.	P1	§8.1
FR-18	The system SHOULD show a brief success confirmation after an action runs or a page opens, using the dashboard's existing snackbar.	P1	§7.3
FR-19	The system SHOULD remember recent selections across sessions for the signed-in user (persistence scope, see §10).	P2	§10
FR-20	The system SHOULD remain operable across keyboard layouts and input methods (the shortcut works regardless of layout).	P1	§6

6. User Flows & States

Happy path — open, find, go

1. From any dashboard page, the admin presses ⌘K (or Ctrl+K), or clicks the header search. The page dims and the Spotlight panel opens with focus in the search field; recent destinations show by default.
2. The admin types a few characters (for example "ref"). Results filter live, grouped, with the first entry highlighted.
3. The admin moves the highlight with ↑/↓ (within a group) or Tab / Shift+Tab (between groups).
4. The admin presses Enter (or clicks a row). A page entry navigates the dashboard there; an action entry starts that action's existing flow.
5. The panel closes, focus returns to the page, and a brief confirmation appears.

Edge cases & error states

Scenario	Expected behavior
No matches for the typed text	Empty state with a short message and a nudge to try another word (copy in §7.4). The panel stays open and the field keeps focus.
Viewer's role can't reach matching entries	Restricted entries are not shown; if filtering empties the visible set, the no-permission note explains why (copy in §7.4).
Results take a moment to resolve	Loading state with skeleton rows; the field stays focused and typing is not blocked.
A selected action fails to start	An error confirmation appears with a "Try again" affordance; no silent failure (copy in §7.4).
The registry can't be loaded	Error state with a short message and "Try again"; Spotlight does not present a stale or partial list as if complete (copy in §7.4).
Hebrew / RTL	The whole panel mirrors: search icon side, text alignment, group headers, row layout, and the keyboard-hint footer all read right to left.
Repeated open / close	Reopening restores an empty query with recents; the previous highlight is not retained between opens.

---

7. UI & Design Handoff

7.1 Design Reference

• Source of truth: the interactive design reference, served at /prds/spotlight-86caf9trm.design-ref.html (a self-contained HTML prototype — the preferred handoff format for Claude Code: it reads markup, class names, copy, and states directly). It renders every state plus an RTL/Hebrew pass, a role switcher that demonstrates permission filtering, and a toggle that surfaces the design-system mapping (data-ds / token annotations).
• Direction & locale: dashboard is bilingual EN/HE; Hebrew is RTL and is a shipped requirement, not hypothetical.

7.2 UI Composition — the deterministic core

Spotlight itself is a new design-system component (itemized in §7.2.a). It is composed only from existing catalog primitives plus its own internal structure (grouped, keyboard-navigable result list; group headers; keyboard-hint footer). Every region below names the real component(s) it reuses and the palette.ts tokens it uses. Component names below were checked against the design-system source (src/), not only the catalog.

Screen / area	Components (from COMPONENTS.md, source-verified)	Tokens (palette.ts)	Notes
Spotlight container (the panel)	Spotlight (NEW — see §7.2.a), composed on Modal + Overlay	ui.backgroundPaper, ui.shadowMedium, ui.borderDefault, ui.backgroundOverlay	Top-center panel over a dimmed page; focus-trapped. Opens on ⌘K (macOS) / Ctrl+K (Windows/Linux). Backdrop click and Esc close it.
Search field	Search, SearchIcon	ui.borderDefault, ui.textPrimary (text), ui.textLightGrey (placeholder)	Leading search icon; flips to trailing under RTL. Localized placeholder. The input keeps focus throughout (type-ahead).
Scope chips (optional filter row)	Chip	ui.filterBackground, ui.filterSelected, ui.textGrey	All · Pages · Actions (and the v2 entity scopes). Selected chip uses filterSelected. Lets the admin narrow to one group.
Group header	Typography	ui.textLightGrey	Small uppercase label per group (Recent, Quick actions, Pages…). Deferred entity groups carry a "v2" marker.
Result row — page / action (+ path or context subtext)	Typography (label + subtext), inside the Spotlight row	ui.textPrimary (label), ui.textLightGrey (path/context), primary.leadColor (quick-action icon accent)	A page row shows its location as secondary text (e.g. "Payments › Refunds"); an action row shows its area. Row layout is part of the new component.
Row — selected / hover	Spotlight row states (NEW)	ui.backgroundSelected, ui.borderSelected (selected), ui.backgroundHover (hover)	Selected row is filled with a leading accent bar; hover is the lighter wash.
Keyboard-hint footer	Typography + Spotlight key hints (NEW)	ui.backgroundGrey, ui.borderDefault, ui.textGrey	OS-aware trigger glyph (⌘K vs Ctrl K). Shows: ↑↓ navigate (within a group), Tab/Shift+Tab (between groups), Enter (select), Esc (close).
Loading	Skeleton	ui.backgroundGrey, ui.backgroundLightGrey	Shimmer rows while results resolve.
Empty	Typography	ui.textLightGrey	"No results" + a one-line nudge to try another term. Copy in §7.4.
Error	Typography, Button	semantic.error (message), ui.info (action)	Short message + a "Try again" Button. Copy in §7.4.
Success confirmation	reuses the dashboard's existing snackbar pattern (useSnack) — not a new element	primary.leadBlack, primary.leadWhite, semantic.success	After an action runs / a page opens, a brief confirmation. Copy in §7.4.
No-permission note	Typography	ui.filterBackground, ui.info	When role filtering removes results, an unobtrusive line explains why.
(v2, deferred) Entity result rows — Communities / Members / Events / Reports / Hubs	intended reuse: Avatar / AvatarWithText, UserRolesBadges, EventDateIndicator, Typography	userRole.*	Not built in v1. Named here so the UI has a home and the component is sized for it; exact composition is confirmed when v2 is specced.

New or changed components/tokens? The only new design-system item is Spotlight itself. It is itemized — together with every primitive it reuses — in §7.2.a below. No one-off is planned in organization-dashboard; the palette is a shared component.

7.2.a Design-system deltas

The only new design-system item this feature introduces is Spotlight. Everything else is reused as-is. This table is the complete account of what each named component needs; only non-reuse rows become design-system tasks, built in @bewith-dev/design-system before the feature is wired into organization-dashboard.

Target (component / region)	Delta type	Description (what / why)	DS task
Spotlight	component	New reusable command-palette component: a focus-trapped overlay panel with a search field, a grouped, keyboard-navigable result list, group headers, an OS-aware keyboard-hint footer, and per-row layout for destinations and actions. Renders an externally supplied set of entries (the registry, see §8.2), so it carries no hard-coded destinations or actions and is reusable across admin surfaces (dashboard first).	/add-component Spotlight component
Modal	reuse	Panel shell (the floating container).	none — @bewith-dev/design-system
Overlay	reuse	Dimmed backdrop / scrim; backdrop click closes the palette.	none — @bewith-dev/design-system
Search (+ SearchIcon)	reuse	The query input and its leading icon.	none — @bewith-dev/design-system
Chip	reuse	Scope filter chips (All · Pages · Actions · …).	none — @bewith-dev/design-system
Typography	reuse	Group headers, row labels, path / context subtext, and empty / error / no-permission copy.	none — @bewith-dev/design-system
Skeleton	reuse	Shimmer rows in the loading state.	none — @bewith-dev/design-system
Button	reuse	"Try again" action in the error state.	none — @bewith-dev/design-system
Avatar / AvatarWithText, UserRolesBadges, EventDateIndicator	reuse	(v2, deferred) Entity result rows (members, events). Reused when v2 is built; no v1 task.	none — @bewith-dev/design-system

Notes:

• Spotlight's internal parts — the grouped result list, group headers, the result-row layout, and the keyboard-hint footer — are part of the Spotlight component, not separate deltas.
• The success confirmation reuses the dashboard's existing snackbar (useSnack), which is app-level, not a design-system component, so it is intentionally not a row here.
• No variant is requested on any existing component: Spotlight composes them as-is.

7.3 States to implement (per screen)

All of these are demonstrated in the design reference and selectable from its State control:

• Default / idle — empty query, recents shown.
• Loading / skeleton — shimmer rows while results resolve.
• Empty — no matches; short message + a nudge to try another word.
• Error — registry could not load, or an action failed to start; message text + "Try again".
• Success — brief confirmation after a navigate or run (the dashboard's snackbar).
• Disabled — entries the viewer cannot reach are not shown (rather than greyed); the no-permission note appears when role filtering empties the visible set. Spotlight has no globally disabled state; it is either open or closed.
• Selected / active — the highlighted row (filled, leading accent bar) and the selected scope chip.

7.4 Copy — exact, as text

Destination and action labels reuse the dashboard's existing translation keys (the same strings as the sidebar and the page buttons), so they are already localized in English and Hebrew and are not re-authored here. The strings below are the Spotlight-specific chrome. No em-dashes in any customer-facing string. The Hebrew is proposed and must be confirmed by a native speaker (see §10, Open Question 1).

Element	English	Hebrew (proposed, to confirm)
Search placeholder	"Search pages and actions"	"חיפוש דפים ופעולות"
Group header (Recent)	"Recent"	"אחרונים"
Group header (Quick actions)	"Quick actions"	"פעולות מהירות"
Group header (Pages)	"Pages"	"דפים"
Scope chip (All)	"All"	"הכול"
Scope chip (Pages)	"Pages"	"דפים"
Scope chip (Actions)	"Actions"	"פעולות"
Empty state title	"No results"	"אין תוצאות"
Empty state hint	"Try a different word."	"נסו מילה אחרת."
Error message	"Something went wrong. Please try again."	"משהו השתבש. נסו שוב."
Error retry button	"Try again"	"נסו שוב"
Success (page opened)	"Opened {page}."	"{page} נפתח."
Success (action started)	"Started {action}."	"{action} הופעל."
No-permission note	"Some results are hidden by your permissions."	"חלק מהתוצאות מוסתרות בהתאם להרשאות שלך."
Footer hint (navigate)	"Up and down to move"	"מעלה ומטה למעבר"
Footer hint (switch groups)	"Tab to switch groups"	"Tab למעבר בין קבוצות"
Footer hint (select)	"Enter to open"	"Enter לפתיחה"
Footer hint (close)	"Esc to close"	"Esc לסגירה"

7.5 Design System Authority

• Pixel-perfect is not required; behavior and states are. The design reference (design-ref.html) is authoritative for layout and states (the exact customer-facing copy is canonical in §7.4); styling uses existing @bewith-dev/design-system components and palette.ts tokens, never bespoke values.
• Direction & locale: the dashboard is bilingual. English is LTR; Hebrew is RTL, and Spotlight implements a full RTL mirror in Hebrew (icon side, text alignment, row and footer layout).
• Responsive: desktop-first (the dashboard is a desktop admin surface). The panel is centered with a max width, caps its height, and scrolls results internally; on narrower widths it shrinks to fit with the same behavior. No separate mobile palette in v1.

8. Constraints & Non-Functional Requirements

Product/business inputs (the WHAT), not the technical solution.

• Permissions / roles: Spotlight respects the dashboard's existing role model (RoleTypeEnum: SUPER_ADMIN, ORGANIZATION_ADMIN, COMMUNITY_ADMIN, HUB_LEADER, SCANNER, EVENT_LEADER, FINANCIAL_ADMIN, TECH_ADMIN). A viewer sees only the destinations and actions their role may reach; the same gating that hides a sidebar item hides its Spotlight entry.
• Feature flag: ship behind a flag (proposed name spotlight), default off, flipped by BeWith (platform-controlled), enabling staged rollout. (Flag name and owner to confirm with R&D — see §10.)
• Performance (user-visible): the palette opens effectively instantly on the shortcut (target under ~100 ms), and results update as the user types with no perceptible lag (target under ~100 ms for the launcher's page/action set). These are user-visible targets, not implementation budgets.
• Accessibility: full keyboard operation (open, move within and between groups, select, close); a focus trap while open and focus return to the prior element on close; screen-reader semantics for a search-and-list pattern (an accessible name for the field, the list and its groups announced, the active option communicated); a visible focus/selection indicator; respects the reduced-motion preference for the open and skeleton animations.
• Localization / direction: English and Hebrew today; Hebrew is RTL. All Spotlight chrome and states localize; destination/action labels reuse existing translation keys.
• Depends on existing systems: the dashboard's navigation and role model (for page destinations and gating); the Spotlight registry and its reachability capabilities (§8.2); the dashboard's existing snackbar (useSnack) for the success confirmation.

8.1 Analytics events (Law 2 — Observability)

The events the platform must fire, with their business meaning. To protect privacy, the searched text itself is not logged — only non-identifying metadata (such as result counts). R&D names the technical payload in the Design Doc.

Event (business name)	When it fires	Why we measure it	Measured dimension
spotlight_opened	The palette is opened (shortcut or header)	Adoption and habit formation (Metric 1)	users
spotlight_searched	The user types a query (debounced); raw text not logged	Whether search is used, and whether it returns results	users (+ has-results / result-count metadata)
spotlight_result_selected	The user selects an entry	Which result types drive value: page vs action vs recent (Metric 2)	users (+ entry-type metadata)
spotlight_action_run	A quick action is started from Spotlight	Action-layer reach (Metric 4)	users, calls
spotlight_no_results	A query yields no visible results	Gaps in coverage or discoverability	users
spotlight_closed	The palette is dismissed	Abandonment vs completion	users

8.2 API-accessible capabilities (Law 1 — API-First)

Business-logic capabilities that must be programmatically reachable, not UI-only. These name what must be reachable; R&D designs the technical surface in the Design Doc (no endpoints, methods, or schemas here).

Capability	Why it needs API access
Read the Spotlight registry — the single, canonical set of Spotlight entries (destinations and quick actions) with their labels, grouping, icon, and visibility rules.	So every surface consumes one shared source instead of re-declaring its own list. This is what keeps Spotlight in sync: the palette, and any other admin surface or tool, read the same registry. It also lets us audit and analyze what is exposed.
Register, update, and retire a Spotlight entry — add a new destination or action, change one, or remove one.	So the set is kept current from one place and is not UI-only: new pages and actions can self-register as they ship, and retired ones drop out everywhere at once. This is the mechanism behind "add / update / remove and stay synced."
Resolve the entries visible to a given viewer — the subset of the registry a specific role is permitted to reach.	So permission-aware filtering is computed once, consistently, and every consumer shows only what the viewer can access — matching the dashboard's existing role gating and never leaking a restricted destination or action.
(SR-1, standing requirement — merged automatically) The feature is programmatically reachable (headless).	BeWith is consumed as a platform; the capabilities above must be reachable headlessly, not UI-only, so customers and integrations can build on them. Merged from the governed standing-requirements list; not restated by the author.

v2 (deferred): live entity search adds one capability when specced — cross-entity search over communities, members, events and reports must be reachable, so results come from one shared search rather than per-table UI. Not part of v1.

8.3 Activation config (Law 3 — Self-Serve Activation)

Not applicable. Spotlight has no customer-facing activation surface: it is an internal admin-tool capability of the dashboard, enabled by the platform feature flag in §8 rather than configured per customer by the activation agent. (The contract allows skipping §8.3 when there is no customer-facing toggle.) Revisit if a per-customer enable, branding, or scope option is ever wanted.

9. Acceptance Criteria

• Given any dashboard page, when the user presses the OS shortcut, then Spotlight opens with focus in the search field and recents shown. (FR-01, FR-04, FR-15)
• Given Spotlight is open, when the user activates the header search instead, then the same palette opens. (FR-02)
• Given Spotlight is open, when the user presses Esc, clicks the "esc" control, or clicks the backdrop, then it closes and focus returns to the prior element. (FR-03)
• Given results are shown, when the user presses ↑/↓, then the highlight moves within the current group; when the user presses Tab / Shift+Tab, then it moves between groups. (FR-07)
• Given a page entry is highlighted, when the user presses Enter, then the dashboard navigates there; given an action entry, then that action's flow starts. (FR-08)
• Given a viewer with a limited role, when results are shown, then only entries that role may reach appear, and none that it may not. (FR-09)
• Given the palette is open, when results render, then every entry came from the shared registry and none is hard-coded. (FR-10, FR-11)
• Given Hebrew is selected, when Spotlight opens, then the entire panel renders right to left. (FR-12)
• Given each state in §7.3, when it is triggered, then the prototype's copy and layout for that state are shown. (FR-13)
• Given any tracked action, when it occurs, then the corresponding §8.1 event fires without logging the raw query. (FR-17)
• Given the feature flag is off, when a user presses the shortcut, then Spotlight does not open; given it is on, then it does. (§8 feature flag)
• All dashboard UI renders correctly in RTL.
• Analytics events from §8.1 fire for all tracked actions.
• The feature is gated behind the feature flag from §8.

10. Open Questions

None of the below blocks a P0, so the PRD is structurally finalizable. (The PRD cannot reach ready-for-rd while any "Blocks P0?" = Yes.)

#	Question	Owner	Blocks P0?	Resolution
1	Confirm or correct the Hebrew copy in §7.4 (native-speaker review). Strings are drafted, so this is review, not authoring.	Product (Hebrew reviewer)	No	pending — confirm at finalize
2	Recents persistence scope: per signed-in user (across devices), per device / browser, or per session only? Affects FR-19.	Product	No	pending
3	Confirm the v1 seed quick-action list (the set in §3 is proposed).	Product	No	pending
4	Confirm the §2 metric targets (currently starting points).	Product	No	pending
5	Shortcut discoverability: add a one-time onboarding hint / persistent affordance so users learn ⌘K, or rely on the header search hint alone?	Product + Design	No	pending
6	Confirm the feature-flag name and who flips it (proposed spotlight, BeWith-controlled).	Product + R&D	No	pending

11. Out of Scope / Future

• vNext (v2): live entity search across communities, members, events, reports, and hubs, sourced from one shared search (the UI home is already designed; capability noted in §8.2).
• Pinned / favorite actions and per-user reordering.
• Parameterized actions (for example "create event named X" parsed from the query).
• Cross-surface reuse of the Spotlight component beyond the dashboard (for example the support tool or partner portal).
• Semantic / AI-ranked results.