# Signal Application workspace pilot

23 September 2026 · Signal v0.6 · reference only

- Local: http://127.0.0.1:5191/design-system.html?pilot=application
- Hosted: https://haya-design-review.pages.dev/design-system?pilot=application
- Phone: add `&chrome=0` to hide review controls.

Open application now connects My work and candidate profiles to this workspace. All eight fictional applications have their own identity, role and stage path. The default is Jordan Nwosu’s Product designer application. Unknown application IDs show a missing-record state rather than another person’s record.

## Review tasks

1. From My work, open Jordan’s application. Read the three interview scorecards. Open and close a scorecard with the keyboard; focus returns to its Read button.
2. Select Screening under Inspect stage, then Offer. Completed-stage evidence is read-only; planned stages have no evidence or available decisions. Return to Interview.
3. Move to References. Submit an empty or whitespace-only reason to check validation, then enter a reason and confirm. The current stage and activity change. References starts with no evidence, so another advance is unavailable.
4. Reset the sample, then choose Missing evidence in the review controls. The execution scorecard is outstanding and advancement is disabled. Request missing evidence with a note; the activity records the simulated request but the scorecard stays pending. No message is sent.
5. Try Reject application or Withdraw application. Cancel preserves the record and returns focus to the trigger. Confirm requires a reason and closes the local workflow. View activity shows the outcome and reason. Reset sample restores the original record.
6. From Candidates, open Amara’s profile and each of her two applications. Her Senior product designer application is at Portfolio review; Design systems lead is at Screening. The role selector switches between them. Back to candidates restores her selected role. Nina’s return link restores page two.
7. From My work, open Daniel’s Offer application. Review the fictional acceptance evidence, then simulate Record hire. Offer remains the final stage; no extra stage is created.
8. Check Request error, Loading and Permission denied. Retry returns focus to Reset sample. Unavailable states hide the application details and decision controls.
9. On a phone, use Next step to focus and reveal the decision panel. Check both themes and densities, including evidence sheets and decision dialogs.

## Composition and behaviour

The workspace uses the approved Signal tokens, Commissioner type scale, shared Panel/PipelinePath, Avatar, Badge, Lucide icons, Base UI Select/Tabs/Sheet/Dialog and existing buttons/fields. No new dependency, primitive or palette is introduced. The main column contains evidence and activity; the 350px decision panel sits alongside it at 1100px and above, and follows the evidence below that width. A narrow-screen shortcut reaches the panel with focus and scroll. Compact density reduces evidence and activity spacing.

Actions run synchronously in component state. Confirmed outcomes and reasons appear in an activity trail, with a simulation label and one live announcement. After confirmation, focus returns to the updated decision heading; after cancellation it returns to the original action. Evidence sheets return focus to their Read button. Later stages do not acquire invented evidence when the reviewer advances.

Navigation preserves the entry path (`design-system.html` locally, or the extensionless hosted path), the hidden-chrome preference and the originating application/candidate. Returning restores the selected record, including a candidate on page two. Search and filter settings are not restored. Simulations reset when leaving or reloading; this pilot does not simulate persistent saves, save failures, message delivery or multi-user changes.

## Implementation boundary

| Concern | Source |
| --- | --- |
| Reference composition and local decisions | `src/design-system/reference/ApplicationPilot.tsx` |
| Stage-specific fictional evidence and application lookup | `src/design-system/reference/application-data.ts` |
| Shared fictional identities and paths | `src/design-system/reference/candidates-data.ts` |
| Reference layout | `src/design-system/reference/application-pilot.css` |
| Pilot navigation | `src/design-system/reference/pilot-navigation.ts` |

Production application lifecycle/evidence contracts informed the vocabulary. This is not an implementation of the backend’s eligibility or permission rules. Evidence requirements, history and readiness are explicit review fixtures; production integration must use server lifecycle states, evidence, blockers and permissions. No API requests, generated clients, backend implementation, production routes or production deployment changed. `MyWorkView` accepts an optional initial selection for the reference return journey; the production controller retains its existing default.

## Verification

Automated cases cover application identity, separate roles, unknown IDs, evidence-sheet focus, required reasons, advancing without fabricated evidence, missing evidence follow-ups, read-only stages, reject/withdraw/reset, final-stage hire, retry/permission/loading states and structural accessibility. Existing My work and Candidates tests also cover the connected navigation and restored selection.

All 44 frontend test files and 173 tests pass. Design-system and application builds, production-authority validation and the production bundle fence pass. A direct bundle scan also confirms the application review fixtures are absent from the app build. The reference retains its existing bundle-size warning (about 596 kB before gzip).

Browser evidence and build/test logs are in `output/signal-application/`. Desktop and narrow layouts, light/comfortable and dark/compact, modal focus, navigation and activity were exercised in a real browser. Automated accessibility checks do not substitute for a screen-reader session. Real-backend acceptance and recruiter usability sessions remain separate work.

## 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.