# Signal Requisitions pilot

23 September 2026 · Signal v0.7 · reference only

- Local list: http://127.0.0.1:5191/design-system.html?pilot=requisitions
- Hosted list: https://haya-design-review.pages.dev/design-system?pilot=requisitions
- Frontend engineer workspace: add `&requisition=signal-review-role-2`.
- Phone without review controls: add `&chrome=0`.

The Requisitions pilot connects the shared My work, Candidates and Application review screens. It uses the existing eight fictional applications, with stable requisition IDs. Production routes, API clients, permissions and backend implementation are unchanged.

## Review tasks and answer key

1. Inspect the requisitions list. There are nine roles: seven open, one draft and one closed. The open list has six roles on page one and Design systems lead on page two. Search and owner filters apply to the status counts as well as the rows.
2. Search for Frontend. There is one matching requisition with two applications. Filter to Robin Cole and explore Draft and Closed. Search for a non-match, then clear search and filters; focus returns to the search input.
3. Open Frontend engineer. It has two openings and two applications: Tara Ahmed at Screening and Nina Mensah at Interview. Neither is overdue. Select Interview; only Nina remains, while the role totals and other stage counts remain unchanged. Select Offer to inspect a zero-result stage, then Show all applications.
4. Open Nina’s application from Interview, then Back to requisition. The role and stage remain selected, and the application row is highlighted. Repeat via Nina’s candidate profile and Open application, then return through Candidates to the role. The candidate directory initially filters to the originating role, including Nina on page one of that filtered list.
5. Open Amara’s two roles. Senior product designer, enterprise experience is at Portfolio review; Design systems lead is at Screening. Each role has one application. They do not share stage counts merely because the candidate is the same person.
6. Open Product designer and Engineering manager. Each has one overdue application. The latter’s role and application owner are Unassigned. These counts are derived from the shared sample flags.
7. Open Research operations coordinator (Draft) and Customer support lead (Closed). Neither has applications. The closed role stopped hiring before receiving any candidates; it does not imply a successful hire.
8. Edit a hiring brief. A blank summary or missing success criteria focuses the invalid field and shows an associated error. Save sample brief updates the visible brief and returns focus to Edit hiring brief. Cancel/Escape discards unsaved changes. Reset sample restores the original brief.
9. Try Loading, Empty, Request error and Permission denied from the review controls. Empty clears the list, or applications within an open role workspace. Enter on Retry requisitions returns focus to the persistent Reset sample button. Loading and access errors hide the role data and editing controls.
10. Check light/dark, comfortable/compact, and desktop/tablet/phone. Wide tables expose a scroll hint and scroll within their own named container. Stage filters wrap into two rows on phones; the hiring brief follows the applications below 1100px.

## Scope and implementation

| Concern | Source |
| --- | --- |
| List, role workspace, counts, filters and local brief edits | `src/design-system/reference/RequisitionsPilot.tsx` |
| Fictional role definitions and stable IDs | `src/design-system/reference/requisition-data.ts` |
| Shared fictional candidates and applications | `src/design-system/reference/candidates-data.ts` |
| Scoped role layout | `src/design-system/reference/requisitions-pilot.css` |
| Navigation context | `src/design-system/reference/pilot-navigation.ts` and the three existing pilot wrappers |

The UI reuses the actual Signal Table, Tabs, Select, Pagination, Dialog, Textarea, Field, Badge, Avatar, Panel, PageHeading and SearchField. No new primitives, dependencies, palette or motion rules were introduced. Stage tiles are filters over current-stage counts; they do not represent a completed lifecycle or alter the approved Ember treatment of individual application paths.

The complete fixture set supplies counts. A production implementation must use authoritative role, application, pagination and permission data; it must not derive global counts from one API page. The application-to-role relation now uses stable IDs instead of display titles. No new people or applications were added to inflate the examples.

Navigation preserves the role, stage and hidden-chrome preference through candidate/application review. Returning directly from an application also highlights its row. The requisitions list’s search, owner, status and page reset when the list is reopened. Invalid requisition IDs show a missing-record state; stage names not in the selected role fall back to All stages.

Brief edits live only in component state and reset on leaving/reloading. They do not publish a job or change production data. Application decisions remain local to their existing workspace and reset when leaving, so role counts continue to describe the original review records. Requisition creation, approval, status changes, bulk actions, save failures and backend integration are outside this pilot.

## Verification

Targeted tests cover referential integrity, counts, combined filters and pagination, empty stages/roles, URL restoration, candidate/application navigation, required-field errors, simulated brief saving/cancellation/reset, retry focus, unavailable states and structural accessibility.

All 45 frontend test files and 187 tests pass. Both builds, production-authority checks and the production bundle fence pass. A direct scan confirms the new role fixtures and brief-editing code are absent from production assets. The reference retains its existing bundle-size warning (about 616 kB before gzip). Browser geometry checks at 375, 768, 1024 and 1440px pass in light/comfortable and dark/compact on both list and role screens.

Browser evidence and logs are in `output/signal-requisitions/`. These checks cover interaction, rendered layout and shared component behaviour; they do not establish screen-reader speech, recruiter usability or real-backend acceptance.