# Signal My work pilot

18 September 2026 · frontend pilot · Signal v0.4

## Review

- Shared sample-data review: https://haya-design-review.pages.dev/design-system?pilot=my-work
- Phone without the review controls: https://haya-design-review.pages.dev/design-system?pilot=my-work&chrome=0
- Recruiter tasks, screenshots and feedback template: https://haya-design-review.pages.dev/my-work-review/
- Local reference: http://127.0.0.1:5175/design-system.html?pilot=my-work
- Actual application route: `/`, with the existing authenticated workspace and operations capability enabled.

The shared review imports `MyWorkView`, the same presentation component used by the app. Its records live only in `src/design-system/reference/MyWorkPilot.tsx`. Navigation in the review opens a destination explanation; the app's links open the existing application and candidate workflows. Only the static reference is published to the design-review site. The app build remains a separate deployment.

## Scope and data boundary

The previous home showed the workload summary and owner-capacity table. Both remain available. My work adds a selectable application queue, current-stage preview, search, overdue/assigned-to-me filters and cursor pagination using the existing operations query endpoint.

| Concern | Implementation |
| --- | --- |
| Home route | `src/routes/_internal/index.tsx` |
| Home shell, workspace selection and existing guards | `src/routes/_internal.tsx` |
| Query orchestration | `src/features/my-work/BackendMyWorkScreen.tsx` |
| Supported filters and cursor ordering | `src/features/my-work/myWorkQuery.ts` |
| Actual screen presentation | `src/features/my-work/MyWorkView.tsx` |
| Feature layout | `src/features/my-work/my-work.css` |
| Shared product shell | `src/design-system/WorkspaceShell.tsx`, `workspace-shell.css` |

The controller uses `backendWorkloadQueryOptions` and `backendOperationsQueryOptions`. The requests are `GET /api/v1/operations/workload` and the read-only `POST /api/v1/operations/query`. The query uses the API's `applications` directory and always requests active records, 25 at a time, using the supported updated-at descending cursor order. Totals and capacity come from the server summary, never from the current page.

Workspace and actor identifiers scope both queries. Changing workspace remounts the controller, clears its filters and cursor position, and uses the existing session/cache invalidation flow. Disabled capability, public session or missing workspace prevents these queries from mounting. Failed or forbidden requests hide cached records rather than presenting them as current.

No backend, generated client, permission contract or mutation workflow is added or changed. Existing navigation destinations remain available in the product header and More menu. Other app screens and the `/workload` route retain their existing implementation.

## Shared design and interaction rules

The screen uses Signal's actual Base UI controls, PageHeading, Panel, RecordRow/RecordRowSelect, PipelinePath, SearchField, EmptyState, Table, Pagination and LiveStatus. Colours, typography, radii, densities and motion remain canonical. No prototype CSS or script is imported into the app.

- Selection keeps keyboard focus on the record button and announces the preview change.
- Search clearing restores focus to its input. Retry returns focus to the stable Refresh button.
- Previous/next controls retain focus when loading or disabled; the caller guards repeated requests.
- A single current pipeline step represents the available data. Full history, scorecards, inferred next decisions and owner display names are not fabricated.
- The owner-capacity table retains the API's workspace IDs for other recruiters. The current actor is labelled You; an empty owner ID is Unassigned.
- The preview moves above the list below 700px. Mobile navigation has the approved right-edge overflow hint. Dense rows may grow when text wraps; 56px is the minimum, not a clipping height.
- Both summary and queue can independently show loading, failure and limited-scope data. Permission-denied states do not offer a misleading retry action.

## Validation

Targeted automated tests cover supported query parameters, capability/session gating, server totals, existing destinations, keyboard selection, cursor navigation/reset, search clearing, retry focus, removal of cached records after a 403, late responses after a workspace change, navigation/dialog focus and semantic accessibility.

Browser checks exercise the sample reference at desktop, tablet and phone widths, both themes and densities, and the actual `/` route with loopback-only HTTP fixtures. These fixtures verify frontend session/workspace wiring, API requests and legacy-CSS coexistence; they are not a live-backend acceptance test. QA artifacts live in `output/signal-my-work/` and are excluded from the published asset directory.

An isolated live-backend pass subsequently found and corrected the query-directory mismatch. Sign-in, workspace switching, application access isolation and API permission checks passed. It also found a rollout blocker: 28 applications exist in the authoritative hiring API while the operations read model reports zero. See [live acceptance evidence](signal-my-work-acceptance.md). No backend implementation was changed, and live queue pagination/selection acceptance remains incomplete until the read model is populated through the normal write path.

Before broader app rollout, resolve that backend finding and repeat the live queue checks, then complete assistive-technology and recruiter sessions. The [recruiter review guide](signal-recruiter-review.md) supplies tasks, a moderator answer key and note-taking structure. Keep the approved accent treatment until that evidence supports a change.