# Signal Candidates pilot

23 September 2026 · Signal v0.5 · reference only

- Local: http://127.0.0.1:5191/design-system.html?pilot=candidates
- Hosted: https://haya-design-review.pages.dev/design-system?pilot=candidates
- Phone without review controls: add `&chrome=0`.
- List view: add `&view=list`. Paths is the default.

The Candidates pilot extends the approved Signal components without migrating the real Candidates route. It uses fictional records, no authentication, no backend requests and no mutations. My work and Candidates now link to each other in the review navigation. Other destinations and imports explain the existing workflow handoff.

## What to try

1. Select Amara Okafor. Switch between Paths and List; her selection should remain. In the preview, switch between her two applications. Open candidate to inspect both paths together.
2. Filter Role to Frontend engineer, then enable Assigned to me. Two people become one: Tara Ahmed. Search for a non-matching name and clear the controls to recover.
3. Open Talent pool. Seyi Adewale has no applications and no resume; the interface does not invent a stage. Open the profile to inspect the empty states.
4. Move to the second page. Seyi and Nina Mensah are records 7–8. Applying a filter returns to page one.
5. On a phone, select Tara from either layout. Focus and scroll move to her name. Back to candidates returns to the selected row.
6. Open Amara's profile, then an application. In v0.6 this opens the Application workspace pilot. Back to candidates restores Amara and the selected application. Closing the profile without navigating still returns focus to Open candidate.
7. Try Loading, Empty, Request error, Permission denied and Limited scope in the review controls. Enter on Retry candidates should restore focus to Refresh. Limited scope contains four candidates assigned to the current reviewer.

## Model and interaction decisions

- The directory counts people, not applications: eight candidates and eight applications across seven people. Amara has two applications; Seyi has none. Six people appear on page one.
- A row shows the role matching the role filter, or its first application when no role is selected. Additional applications are indicated beside the role and remain available in the preview and profile. Candidate ownership is distinct from application stage.
- Overdue and role filters must match the same application. Search covers the person's name, email, location, headline and application roles. All filtering, page slicing and totals in this pilot are reference-only operations on the complete fictional set.
- Stage completion and overdue flags are explicit sample data. Never infer actual completion from the current stage's position when migrating this interface.
- Paths/List retains selection and shares one preview. Desktop selection stays on the record and announces the updated person. Explicit phone selection moves to the heading and offers a return control.
- The profile uses the shared Sheet. In v0.6 its application links open the connected Application pilot. Import remains a workflow explanation; stored-resume metadata is shown without a fake download.
- The established Signal provider owns theme and density across both pilots and their overlays. No new tokens or dependencies were added. Compact rows remain content-driven and may grow for long names or paths.

## Implementation boundary

| Concern | Source |
| --- | --- |
| Reference composition, local interaction state and profile | `src/design-system/reference/CandidatesPilot.tsx` |
| Fictional people, application relationships and path states | `src/design-system/reference/candidates-data.ts` |
| Reference-only layout | `src/design-system/reference/candidates-pilot.css` |
| Navigation between review pilots | `src/design-system/reference/pilot-navigation.ts` |
| Shared controls and visual rules | `src/components/ui/`, `src/design-system/` |

The real candidate directory returns person records without application histories. Candidate workspace and application lifecycle contracts provide those relationships through separate endpoints. This reference does not implement a production fetching strategy or assume that directory pagination can be derived from application pagination. That integration remains a separate task. Existing app routes, API clients, permissions and backend implementation are unchanged.

## Verification

Eight targeted cases cover unique-person counts and layout selection, combined filters/zero results, pagination/talent pool, nested overlay focus, retry/permission/scope states, phone focus/return, and structural accessibility in each layout. The full frontend suite has 43 passing files and 159 passing tests. Design-system and application builds, production-authority checks and the bundle fence pass.

Browser checks cover Paths at 1440, 1024, 768 and 375px in light/comfortable and dark/compact; List at desktop, tablet and phone; search, pagination, limited scope, retry focus, profile/application handoffs and phone selection. Page width matches viewport width. At tablet and phone widths the wide table scrolls within its named container.

Evidence is in `output/signal-candidates/`. The reference still produces the existing bundle-size warning (about 575kB before gzip). Screen-reader speech, real backend integration and human recruiter usability are not claimed by these checks.

## v0.7 connected role review

The [Requisitions pilot](signal-requisitions-pilot.md) uses stable role IDs shared by these fixtures. Entering from a role preserves its ID and selected stage through the candidate/application return journey. The candidate directory initially filters to that role; application workspaces also provide View requisition for their own role.