Same corpus, different relevance gradient per staffer. Three personas
defined in mcp-server/index.ts STAFFERS roster (Maria/IL, Devon/IN,
Aisha/WI), each with a primary state + secondary cities. Server-side:
/intelligence/chat smart_search accepts a staffer_id body field; when
set, defaults state to the staffer's territory and labels the playbook
context as theirs. The playbook patterns query also defaults its geo
to the staffer's primary city/state, so the recurring-skills/cert
breakdowns reflect what they actually fill, not the global IL prior.
Front-end: a staffer selector dropdown beside the existing state/role
filters. Picking a staffer auto-pins state to their territory, shows
a greeting line, relabels the MEMORY panel as MARIA'S/DEVON'S/AISHA'S
MEMORY, and sends staffer_id to chat for scoping.
Dropdown is populated from /staffers (NOT /api/staffers — the generic
/api/* passthrough sends everything under /api/ to the Rust gateway,
which doesn't own the roster). loadStaffers runs at window-load
independently of loadDay's Promise.all so the dropdown populates even
if simulation/SQL inits error out.
Verified end-to-end via playwright. Same q="forklift operators":
no staffer → 509 workers across MI/OH/IA, MEMORY label
as Devon → 89 IN-only (Fort Wayne, Terre Haute), DEVON'S MEMORY
as Aisha → 16 WI-only (Milwaukee, Madison, Green Bay), AISHA'S MEMORY
As Maria with q="8 production workers near 60607":
tags: headcount: 8 · zip 60607 → Chicago, IL · role: production · city: Chicago
20 workers, MARIA'S MEMORY label, top results in Chicago zips
Closes the demo-side build of A-G from the persona plan:
A. zip → city/state, B. headcount, C. bare-name, D. temporal,
E. late-worker triage, F. contractor anchor, G. per-staffer index.
5f0beffe80