Project stage 2: Build the React client

Outcome

You will complete and integrate Stage 2 of Delivery Board. The accepted client will render a typed work-item collection through focused React components, update in-memory state through explicit actions, represent page and filter state in stable URLs, preserve usable keyboard focus, and protect eight important behavior contracts with automated tests.

The existing feature/react-components branch contains the four lesson commits. This assignment turns that guided branch into a reviewed product stage: adapt the fixture, expand the test portfolio, perform a complete accessibility and browser pass, document evidence and limits, respond to review, merge the accepted branch, and verify the result from a fresh clone.

What you will practice

Integrate typed components, local state, derived values, routes, URL search state, and effects into one coherent React client.
Preserve semantic HTML, accessible names, live feedback, focus behavior, responsive layout, and browser navigation as technical requirements.
Select automated tests from user-visible contracts and plausible regressions at focused component and routed-client boundaries.
Distinguish evidence from type checking, linting, automated tests, production building, and real-browser verification.
Review a multi-commit feature branch, give specific feedback, evaluate a response, and integrate the accepted result without rewriting unexplained history.
Document source responsibilities, test coverage, browser evidence, limits, and the server-stage handoff for another contributor.

What is new and what is reused

New: A Stage 2 product contract, five-record fixture adaptation, an eight-case automated test portfolio, docs/stage-2-verification.md, a complete client review, feedback-response evidence, reviewed integration into main, and a fresh-clone Stage 2 baseline.
Reused: The private Delivery Board repository, feature/react-components, four React lesson commits, WorkItem, typed props, React state, immutable updates, derived counts, URL filters, React Router declarative mode, focus management, Vitest, jsdom, Testing Library, Sass, README, production preview, GitHub pull requests, and the Stage 1 team workflow.

Starting point

Before you start

Project stage 1 is accepted on the private repository remote main branch.
The completed component, state, routing, and testing lessons exist as separate commits on feature/react-components.
The feature branch is clean and passes npm test, typecheck, lint, build, and its current browser checks.
The repository README contains the Stage 1 setup and recovery path.
One branch author and a different reviewer are available. An individual route uses the teacher as reviewer.
Use fictional work-item content only. Do not add private student, staff, customer, or credential data.
No starter download or second application repository is required.

Current state: The lesson branch contains a working React client, but it still uses the guided three-item fixture and six-test baseline. The complete stage has not received independent data variation, product-level browser evidence, review, feedback response, integration, or fresh-clone verification.
First action: Open the Delivery Board repository, run git fetch origin, git status, and git log --oneline origin/main..HEAD, then record the branch author, reviewer, current head commit, and first active checkpoint in docs/stage-2-verification.md.
First checkpoint: The verification document identifies the branch, tested commit, roles, eight required contracts, current automated result, and the exact next product change without modifying main.
Help trigger: Open the assistance beside the current checkpoint or ask for help if the branch base is unclear, an existing lesson commit is missing, two contributors plan to edit the same branch at once, the product and test expectations disagree, a route works only through links, keyboard focus becomes unclear, a test fails for an unrelated setup reason, review feedback lacks a verifiable outcome, or integration would require a force push.

Requirements

The required assignment is complete when every applicable criterion below is met.

Deliverables and product boundary

Continue the existing private Delivery Board repository. Do not create a second product repository or copy the project into a new Git history.
Deliver the accepted Stage 2 client on remote main through one reviewed feature/react-components pull request.
Keep the component, state, routing, and testing lesson outcomes as separate focused commits. Add focused assignment commits for fixture adaptation, test expansion, documentation, and review responses when those changes are required.
Update README.md and add docs/stage-2-verification.md with current source, test, browser, review, limit, and handoff evidence.
Keep node_modules, dist, coverage output, temporary screenshots, credentials, and private reflections outside Git.

Typed React architecture

Keep WorkStatus limited to planned, active, or done and keep WorkItem fields for id, title, description, status, and labels.
Submit at least five fictional work items. Use a unique stable string ID for every item and unique label text within each item.
Represent all three statuses and make one status occur exactly once so its filtered result can become empty after one valid action.
Keep the trusted internal fixture in its data module and satisfy WorkItem[] without any, an assertion, or a non-null assertion.
Keep App as the nearest shared owner of the current work-item collection and status-update operation.
Keep WorkItemList responsible for the collection result and WorkItemCard responsible for one item and its actions.
Keep route views in focused page modules and keep shared status labels or guards in one suitable utility module.
Do not duplicate current items, selected URL filter, visible items, counts, or current route in competing state values.
Do not mutate an existing item, labels array, state array, prop object, or prop array.

Required interaction and URL behavior

Render a board at /, a status guide at /guide, a dynamic detail view at /work-items/:itemId, and a recovery view for every unmatched client path.
Use Link and NavLink for internal navigation. Expose the current Board or Status guide destination and keep the root link from matching every path.
Provide a native labeled status filter for All statuses, Planned, Active, and Done.
Store the selected filter in the status search parameter. A copied or reloaded valid URL must reproduce the same selection and visible collection.
Treat every search value as runtime input. An unsupported status must show visible recovery text and fall back to All statuses without an assertion or crash.
Give every card one native button that names both the next action and the selected work item.
Cycle status from planned to active, active to done, and done to planned through one typed application callback.
Derive the visible collection, displayed counts, status labels, next action, and empty result from current source state.
Keep an updated item current when the user navigates to its detail route during the same mounted client session.
Reloading restores the internal fixture because server persistence begins in Stage 3.
An unknown work-item ID must show Work item not found and a route back to the board. An unmatched path must show Page not found and a recovery route.
Client path navigation must update document.title and move focus to the new page h1. A search-only filter change must keep focus on the filter control.

Accessibility and responsive correctness

Keep one stable main element and one page h1 for every route result. Use semantic sections, lists, articles, description lists, navigation, buttons, links, labels, and headings for their native roles.
Expose work-item ID, status, description, labels, counts, empty results, unsupported-filter recovery, and action feedback as visible text.
Use one live status region for action feedback. Do not move focus to routine live text when the activated card remains available.
When a filtered action removes the focused card, move focus to stable feedback and keep a visible focus indicator.
Keep every required action operable with pointer, Tab, Shift+Tab, Enter, and Space as appropriate for its native element.
Do not communicate status, current route, warning state, or action availability through color alone.
Meet WCAG AA text contrast and preserve visible focus in the selected design.
Keep required content usable at 320 CSS pixels and 200 percent browser zoom without clipped text, overlapping controls, or horizontal page scrolling.
Respect prefers-reduced-motion for any optional motion. No motion is required.

Automated tests and quality evidence

Keep Vitest, jsdom, React Testing Library, jest-dom, and user-event as development dependencies with deterministic test and optional test:watch scripts.
Keep one explicit test setup file with DOM matchers, rendered-tree cleanup, and reset of shared document state.
Provide at least eight automated tests. Each test must name one user-visible scenario and one result.
Cover these eight contracts: empty collection; valid URL filter; status transition; filtered-card focus recovery; unsupported filter recovery; updated state on a detail route; unknown item ID; and route title, heading focus, and current navigation.
Use roles, accessible names, labels, visible text, and current values before a test ID or lower-level DOM relationship.
Do not test React Hook state, component instances, CSS class names, private call order, or a mock-only implementation detail.
Use a controlled one-value mutation to prove one selected test detects a plausible defect. Restore the correct source before final verification.
Make npm test, npm run typecheck, npm run lint, and npm run build pass from a clean install.
Run the production-preview browser matrix because jsdom does not prove CSS layout, zoom, real History behavior, direct server routes, or complete accessibility.

Collaboration, documentation, and delivery

Assign one branch author, one reviewer, and one integration owner. The author and reviewer must be different people.
Use the teacher as reviewer for an approved individual route. Do not create another account or simulate review.
The pull request must state the outcome, scope, commit sequence, automated evidence, browser evidence, known limits, and requested review focus.
The reviewer must inspect and run the branch, then record at least one specific product-behavior observation and one source-or-test observation.
When no defect is found, the reviewer must state the exact path and relationship that passed. Do not invent a defect to satisfy review evidence.
The author must respond to every review item with a focused change or an evidence-based explanation and repeat the affected verification.
Update the feature branch from remote main through an ordinary merge when it is behind. Do not force push through an unexplained history difference.
Merge only after approval and passing final checks. Preserve the focused lesson commits with a merge commit when the repository supports it.
After integration, every contributor must pull remote main, install the committed dependencies, repeat the complete checks, and finish on clean synchronized main.
Keep private personal reflection in Teams, not in the shared repository.

Design freedom

Choose the fictional work-item titles, descriptions, labels, and initial status distribution within the required data boundaries.
Choose the color palette, typeface stack, spacing, borders, surface treatment, and card layout within the accessibility and responsive requirements.
Choose whether the reviewer runs the branch in a separate clone or an existing clean working copy.
Choose the exact additional assertions inside the eight required scenarios when they test the named user outcome.
Choose which contributor acts as integration owner.

Out of scope for Stage 2

Do not add an Express server, API request, runtime schema library, database, authentication, account, role, or server deployment.
Do not add localStorage, IndexedDB, service-worker persistence, or another persistence layer to avoid the Stage 3 API boundary.
Do not add a global state library, CSS framework, component library, data-router mode, React Router framework mode, server-side rendering, or static-site generation.
Do not require a coverage percentage, continuous-integration service, end-to-end runner, visual-regression service, or public deployment.
Do not require an iOS or Android build, Capacitor, native plugin, app-store account, emulator, or physical mobile device yet.
Do not include optional extension work in the required estimate, definition of done, or assessment result.

Definition of done

Stage 2 is complete when every applicable requirement above is met and all of these results are true:

feature/react-components contains focused component, state, routing, test, adaptation, and documentation history based on accepted Stage 1 main;
five or more typed fictional records render through the required component and page boundaries;
every required action, filter, route, search value, recovery state, title, live message, and focus transition produces its documented result;
eight or more meaningful behavior tests pass, and one controlled mutation proves the selected test can fail for the intended reason;
typecheck, lint, test, and build pass from the committed dependency graph;
the production preview passes direct routes, reload, browser history, pointer, keyboard, focus, 320-pixel, 200%-zoom, contrast, wrapping, overflow, and Console checks;
README and docs/stage-2-verification.md state the tested commit, environment, contracts, evidence, limits, and next server-stage boundary;
a different person has reviewed the complete branch and recorded product plus source-or-test evidence;
every review item has an author response and an affected-path retest;
the approved branch is merged, remote and local main contain the Stage 2 result, and every normal working tree is clean;
a fresh clone passes install, automated checks, production build, and the named browser smoke path without a source edit; and
the Teams submission contains the repository, pull request, final commit, role, verification, and reflection evidence described below.

Checkpoint 1: Establish the reviewable branch state

Only the branch author edits feature/react-components. The reviewer works from a separate working copy or waits for a published review state. Do not alternate uncoordinated writes to the same branch.

In the branch-author working copy, inspect the current relationship:

git status
git branch --show-current
git fetch origin
git log --oneline origin/main..HEAD
git log --oneline HEAD..origin/main

Continue only when:

the working tree is clean;
the current branch is feature/react-components;
the component, state, routing, and test commits appear after the Stage 1 base; and
the final command either prints nothing or shows understood accepted changes that must be integrated.

If remote main contains accepted work that the branch lacks, merge it before product adaptation:

git merge --no-edit origin/main

If Git stops with a conflict, use git status, decide the final source from the Stage 2 contract, remove every conflict marker, and run the affected checks. If the correct result is unclear, use git merge --abort and ask the relevant contributor before retrying.

Do not rebase or force push a branch that another contributor is already reviewing unless the team explicitly agrees to replace its published history.

Create the verification owner

Create docs/stage-2-verification.md with this starting structure:

# Stage 2 verification: React client

## Ownership and tested state

- Branch author:
- Reviewer:
- Integration owner:
- Feature branch: feature/react-components
- Current feature commit:
- Stage 1 base commit:
- Node and npm versions:
- Test data: Fictional work items only

## Product contracts

| ID | User-visible contract | Plausible regression | Evidence state |
| --- | --- | --- | --- |
| CLIENT-01 | Empty collection shows a specific result | An empty list or blank region renders | Not verified |

Add CLIENT-02 through CLIENT-08 before implementation review.

## Automated evidence

- Command:
- Test files:
- Result:
- Controlled mutation:

## Browser evidence

Add the required route and viewport matrix.

## Review and responses

Add each specific review observation, author response, and focused retest.

## Limits and Stage 3 handoff

State what remains in memory and what the Express API must own next.

Fill in all eight contract rows from the requirements. Record the current commit and command result before adapting source. Keep evidence states such as Not verified, Pass, Issue, or Blocked tied to named conditions.

Check

The branch history has the intended Stage 1 base and four lesson outcomes.
The roles have different named owners where required.
The verification file names all eight contracts and their plausible regressions.
The baseline test and source commands have current results.
No change has reached main.

Assistance for Checkpoint 1

Assistance 1 — Identify the branch and owners

Use git branch –show-current, git status, and git log –oneline origin/main..HEAD. Name the person who can push the branch, the person who will review it, and the person who will merge after approval.

Assistance 2 — Compare the branch with current main

git log –oneline HEAD..origin/main lists remote-main commits missing from the current branch. An empty result means the feature already contains that history. A non-empty result requires an understood integration before review.

Assistance 3 — Build the eight-row contract map

Add rows for empty collection → valid URL filter → status transition → filtered focus recovery → unsupported filter → updated detail state → unknown item ID → route title, heading focus, and current navigation. Name one wrong result each row should detect.

Checkpoint: The complete client branch has an evidence contract

What now works: The feature history and roles are known, current main is integrated when required, eight user-visible contracts have plausible regressions, and the baseline commands have recorded states.
Files changed: docs/stage-2-verification.md, Local and remote Git history
What remains: Adapt the guided fixture and verify that the React architecture supports varied records without changing its core data model.
Next action: Open src/data/sample-work-items.ts and design five fictional records that meet the required identity and status distribution.
If it does not work: Return to the last clean feature commit, compare main and feature history again, and restore the eight-row contract table before editing product source.

Checkpoint 2: Adapt the typed collection and client behavior

Replace the guided three-record fixture with at least five fictional work items. Keep the existing type and source boundary. The submitted collection must:

use unique stable IDs;
include every supported status;
include one status exactly once;
use unique labels inside each record;
contain text long enough to check wrapping; and
contain no personal or confidential data.

Update test expectations that deliberately depend on the fixture. Do not change a correct product expectation to copy an accidental implementation result.

Run the client and verify these source relationships:

App initializes one WorkItem[] state value from the trusted fixture.
The board derives filtered items and counts from current items plus the URL filter.
WorkItemList maps stable IDs and owns the empty result.
WorkItemCard receives one item and reports a typed ID and next status.
The state handler replaces only the matching record with map and object spread.
Route pages receive the smallest inputs they need.
No page or component stores a second collection or copied count.

Verify every state transition

At /, activate one card in each starting status:

Starting status	Required next status	Required next action label
Planned	Active	Mark done
Active	Done	Return to planned
Done	Planned	Start work

The button’s accessible name must also include the selected item title. Confirm that the clicked button keeps focus when its card remains visible.

Filter to the status that occurs once. Activate that card so it leaves the result. Confirm that:

the URL search parameter remains the same;
the card leaves the rendered collection;
the empty result names the selected status;
the live message names the changed item and new status; and
focus moves to the live message.

Verify URL and route ownership

Use these direct route shapes with the adapted IDs:

/
/?status=planned
/?status=unsupported
/guide
/work-items/ONE-REAL-FIXTURE-ID
/work-items/UNKNOWN-ID
/does-not-exist

Confirm the matching page, heading, title, current navigation, visible recovery, and return route. Update a card before opening its detail route and confirm the detail page reads the current in-memory status. Reload and confirm that the trusted fixture returns.

Check

Run the current automated and source checks:

npm test
npm run typecheck
npm run lint
npm run build

Record changed fixture-dependent assertions and the restored result in the verification document.

Assistance for Checkpoint 2

Assistance 1 — Locate each source responsibility

Fixture content belongs in src/data. The reusable shape belongs in src/types. Current collection state stays in App. Collection output stays in WorkItemList. One item and its action stay in WorkItemCard. Route-specific output stays in src/pages.

Assistance 2 — Trace one status action

Follow button activation → card callback with ID and next status → list callback forwarding → board callback for feedback and focus → App callback → functional state update → derived collection and counts → rendered result. Stop at the first missing or duplicated relationship.

Assistance 3 — Verify behavior by state lifetime

Check fixture data at module load → current items in App state → path and filter in router state → transient feedback in BoardPage state. Update one value at a time and confirm that each value survives only for its documented lifetime.

Checkpoint: The client works with independently adapted data

What now works: Five or more typed records render through focused components, all status transitions work, URL filters and routes match current data, derived output stays synchronized, and both focus outcomes are intentional.
Files changed: src/data/sample-work-items.ts, src/App.tsx, src/components, src/pages, src/utils, Related fixture-dependent tests
What remains: Expand the guided six-test baseline into the required eight-contract portfolio and prove that one selected test detects a plausible defect.
Next action: Open docs/stage-2-verification.md and choose the two required contracts that do not yet have automated evidence.
If it does not work: Restore the last passing fixture, trace one action from event to rendered result, then reapply one data variation and update only expectations owned by that variation.

Checkpoint 3: Complete the eight-contract test portfolio

Map each required contract to one automated case. A test can make several related assertions, but its name must state one scenario and one outcome.

Use this minimum portfolio:

ID	Required scenario	Required evidence
CLIENT-01	Empty collection	Specific empty text and no empty semantic list
CLIENT-02	Valid status search value	Selected filter, matching cards, excluded card, and correct derived counts
CLIENT-03	Status action at the board	New visible status, next accessible action, retained focus, and live feedback
CLIENT-04	Only card leaves a filtered result	Card absent, empty text visible, live feedback current, and feedback focused
CLIENT-05	Unsupported status search value	All statuses fallback, visible recovery, complete collection, and stable counts
CLIENT-06	Updated item opened through its detail link	Current changed status, matching ID and title, route heading focus, and back route
CLIENT-07	Unknown item ID	Work item not found, requested ID, no crash, and recovery link
CLIENT-08	Navigation to Status guide	Heading, document title, heading focus, and `aria-current="page"`

Keep the focused empty test at WorkItemList. Render the real App with MemoryRouter for the integrated route and state cases. Use within when several cards contain controls with the same visible wording.

For every case, record in docs/stage-2-verification.md:

test file and test name;
starting route or component props;
action when present;
expected user-visible result;
plausible wrong implementation; and
final status.

Prove one test is sensitive

Choose one safe, reversible value such as:

planned: "done" in the next-status map;
an incorrect fallback filter;
the wrong document-title suffix; or
the wrong missing-item heading.

Change only that value. Run only the named test and confirm it fails because the wrong user result appears. Record the expected failure, restore the source immediately, and run the complete suite.

Do not leave a deliberate defect, .only, .skip, stale snapshot, debug log, or changed fixture after the sensitivity check.

Check

npm test
npm run typecheck
npm run lint
npm run build
git diff --check

The final evidence must show at least eight passed tests and no skipped or failing required case. Type checking must include the test source; Vitest execution alone does not type-check it.

Assistance for Checkpoint 3

Assistance 1 — Find the two missing test contracts

Compare the six guided tests with CLIENT-01 through CLIENT-08. The common missing cases are unsupported-filter recovery and state remaining current after navigation to a detail route.

Assistance 2 — Operate through the public interface

Arrange a route with MemoryRouter, find controls through roles and names, create userEvent.setup() inside the test, await the action, and assert visible output or focus. Do not call a state handler or router Hook directly.

Assistance 3 — Build the state-to-detail test

Render at the board → locate one item article by its heading → activate its status button → open that same article’s detail link → find the detail h1 → assert the updated visible status and heading focus → activate Back to the board and confirm the route result.

Checkpoint: Eight user contracts have executable regression evidence

What now works: The test plan maps all eight required scenarios to meaningful cases, the complete suite passes, one controlled mutation fails the intended case, and the correct source and full gate are restored.
Files changed: src/App.test.tsx, src/components/WorkItemList.test.tsx, src/test/setup.ts, vite.config.ts, docs/stage-2-verification.md
What remains: Run the checks that require a real browser, record their conditions, and update the project handoff before review.
Next action: Build the client, start the production preview, and open the direct-route matrix in a current browser.
If it does not work: Run one test by exact file and name, read the first assertion and accessible DOM output, repair that one contract, then rerun the complete suite before browser work.

Checkpoint 4: Verify the built client in a real browser

Build and start the production preview:

npm run build
npm run preview

Use the exact URL Vite reports. Record the browser name and version, operating system, tested commit, and date.

Direct-route matrix

Open every route in a new tab or through a fresh address-bar entry. Do not reach all routes only through client links.

Route	Required direct-load result
`/`	Complete board and unfiltered collection
`/?status=<valid-status>`	Matching select value, collection, counts, and URL
`/?status=unsupported`	Visible recovery plus All statuses fallback
`/guide`	Status guide heading and definitions
`/work-items/<known-id>`	Matching current fixture detail
`/work-items/<unknown-id>`	Work item not found and board route
`/does-not-exist`	Page not found and board route

For each route, confirm HTTP or preview success, one page h1, expected title, reload behavior, no application Console error, and a usable route back when required.

Interaction and keyboard matrix

Tab through primary navigation, filter, every visible action, and every detail link.
Confirm a visible focus indicator at each stop.
Use Enter on links. Use the select with its native arrow-key and Enter or Space behavior. Use both Enter and Space on status buttons.
Confirm that a status action at / keeps focus on the updated button.
Confirm that a status action in the single-item filter moves focus to current feedback.
Confirm that client path navigation focuses the route h1 and changes the title.
Confirm that a filter-only change leaves focus on the select.
Use browser Back and Forward across paths and at least three filter selections.

Responsive and visual matrix

Check at least:

a normal desktop width;
320 CSS pixels;
200% browser zoom;
the longest title, description, label, URL ID, and recovery text;
primary navigation wrapping;
card and control wrapping;
contrast for text, borders that convey state, focus indicators, active navigation, and warnings;
reduced motion when optional motion exists; and
horizontal page overflow.

Record Pass, Issue, or Blocked for each matrix row. A blocked row names the missing browser, device, permission, or condition. Do not convert a blocked result into a pass.

Stop the preview with Ctrl+C after the checks.

Update the durable handoff

Update README with:

current Stage 2 behavior and route table;
component, state, page, utility, and test-file responsibilities;
all npm commands;
automated scenario summary;
production-preview procedure;
jsdom and static-host route-fallback limits;
current in-memory reload boundary; and
Stage 3 handoff: Express will own runtime validation, API routes, and persistence decisions.

Complete docs/stage-2-verification.md with the tested commit, matrices, automated result, controlled mutation, issues, retests, and current limits.

Assistance for Checkpoint 4

Assistance 1 — Separate automated and browser evidence

Put Vitest results under Automated evidence. Put the named browser, direct routes, keyboard path, focus results, viewport, zoom, overflow, and Console results under Browser evidence. Do not combine them into one generic passed statement.

Assistance 2 — Inspect the first browser disagreement

Record the exact route, viewport, trigger, expected result, actual result, focus target, and first Console message. Repeat the same path once before changing source.

Assistance 3 — Verify the client by boundary

Check server direct load → router match → page heading and title → URL input validation → current App state → rendered collection → interaction feedback and focus → responsive CSS → Console. Repair the earliest boundary that explains the result.

Checkpoint: The production client has named browser evidence

What now works: Every direct route, required interaction, focus transition, keyboard path, viewport, zoom state, wrapping boundary, and Console result has current evidence tied to one commit and environment.
Files changed: README.md, docs/stage-2-verification.md, Production build and preview evidence
What remains: Publish the complete branch, conduct independent review, respond to findings, integrate the accepted result, and verify remote main from a fresh clone.
Next action: Inspect the final branch diff and commit history, then push feature/react-components and open or update its pull request.
If it does not work: Return to the last passing automated result, reproduce one browser path with exact conditions, and update the evidence state before requesting review.

Checkpoint 5: Review and integrate the complete client

The branch author reviews the complete change before publication:

git status --short
git diff
git fetch origin
git log --oneline origin/main..HEAD
npm test
npm run typecheck
npm run lint
npm run build
git push -u origin feature/react-components
git status

Commit any uncommitted assignment work in focused units before the push. Example outcomes are:

feat: adapt Delivery Board sample work
test: cover client recovery paths
docs: record Stage 2 verification

Do not use an example message when it does not describe the actual staged diff. Inspect each staged unit first.

Open the Stage 2 pull request

Open a pull request from feature/react-components into main. Keep it as a draft until the author completes every pre-review check.

The description must contain:

Outcome: the complete Stage 2 user capability;
Scope: components, state, URL and routes, focus, tests, responsive behavior, and documentation;
Commit sequence: the focused outcome represented by each branch commit;
Automated evidence: exact commands and result counts;
Browser evidence: browser, version, operating system, direct routes, keyboard, focus, 320-pixel, zoom, overflow, and Console results;
Known limits: in-memory reload, jsdom, static-host fallback, and excluded server responsibilities;
Review focus: state ownership, runtime URL narrowing, semantic structure, focus changes, test sensitivity, and fixture-dependent expectations; and
Evidence locations: README and docs/stage-2-verification.md.

Conduct independent review

The reviewer fetches the published branch in a clean working copy. In a new clone, create a local tracking branch from the remote feature branch:

git fetch origin
git switch --track origin/feature/react-components

If the local review copy already has that branch, update it instead:

git switch feature/react-components
git pull --ff-only

Then install and verify the exact published branch:

npm ci
npm test
npm run typecheck
npm run lint
npm run build
npm run preview

The reviewer performs at least:

one status action at / and one inside the single-item filter;
one valid and one unsupported search URL;
one updated item detail and one unknown item detail;
path navigation plus Back and Forward;
keyboard and focus checks;
a 320-pixel or 200%-zoom check;
inspection of one state ownership path; and
inspection of one test’s ability to detect its named regression.

Record at least two specific observations in the pull request:

one product-behavior observation with route, action, expected result, and actual result; and
one source-or-test observation with the relationship inspected and its consequence.

If both observations pass, state the evidence that passed. Review does not require an invented defect.

Respond to every review item

For each question or change request, the branch author:

reproduces or inspects the stated condition;
records whether the observation is confirmed;
makes the smallest required change or explains why the current result meets the contract;
runs the focused test or browser path;
reruns the complete automated gate when source changed;
commits and pushes a focused response when required; and
replies with the result and evidence.

Update docs/stage-2-verification.md with the observation, decision, change, and retest. The reviewer approves only after the required result and documentation agree.

Integrate current main before merge

If GitHub reports that the branch is behind or conflicted, the branch author uses the documented collaboration workflow:

git status
git fetch origin
git log --oneline HEAD..origin/main
git merge --no-edit origin/main
npm test
npm run typecheck
npm run lint
npm run build
git push

Resolve conflicts from the final product contract. Abort the uncommitted merge when the intended combined result is unknown. Do not force push through an unexplained difference.

Merge and synchronize

After approval and final green evidence, the integration owner merges the pull request. Preserve the branch commits with Create a merge commit when that option is available. Delete the remote feature branch only after GitHub confirms the merge.

Every contributor then runs:

git switch main
git pull --ff-only
git status
git rev-parse HEAD
git rev-parse origin/main
npm install
npm test
npm run typecheck
npm run lint
npm run build

Confirm that local main and remote main identify the same Stage 2 result and that every working tree is clean.

Verify from a fresh clone

Clone into a separate empty folder outside every current repository:

git clone REPOSITORY-URL delivery-board-stage-2-check
cd delivery-board-stage-2-check
npm ci
npm test
npm run typecheck
npm run lint
npm run build
npm run preview

Run the board, one valid filtered URL, one known detail route, one unknown route, and one status action. Stop the preview and record the full remote main commit in the verification document and Teams submission.

Assistance for Checkpoint 5

Assistance 1 — Prepare a reviewable pull request

Make the branch clean, list its commits, run all automated checks, record current browser evidence, push the branch, and put outcome, evidence, limits, and review focus in the pull-request description.

Assistance 2 — Turn a review observation into an action

Separate observation → consequence → requested or chosen change → focused verification. Confirm the observation before editing. Reply with evidence even when the correct response is to keep the current implementation.

Assistance 3 — Close the stage without losing history

Approval → compare with remote main → integrate main when required → repeat checks → push → merge commit → confirm GitHub merge → delete only the merged branch → pull main in every working copy → fresh clone → repeat checks → record final commit.

Checkpoint: The reviewed React client is the recoverable main baseline

What now works: Independent review covers product and test behavior, every finding has a response, the approved commit sequence reaches remote main, all working copies are synchronized, and a fresh clone reproduces the verified client.
Files changed: Private GitHub pull request, README.md, docs/stage-2-verification.md, Remote and local main history, Teams submission evidence
What remains: Complete the self-check, submit the required links and reflection, and keep the clean main baseline for the Express server lesson.
Next action: Copy the repository URL, merged pull-request URL, final remote main commit, verification summary, and role evidence into the Teams submission.
If it does not work: Compare GitHub merge state, remote main, local main, installed lockfile, automated gate, and fresh-clone result before creating any server branch.

Self-check

Complete these checks against the required result.

Confirm that the work continued in the existing private Delivery Board repository and did not create a second product history.
Confirm that feature/react-components began from accepted Stage 1 main and preserves separate component, state, routing, and testing outcomes.
Confirm that the branch author, reviewer, and integration owner are named and that the author and reviewer are different people.
Point to at least five fictional work items with unique IDs, all three statuses, one single-item status, and unique labels within each item.
Confirm that WorkItem and WorkStatus remain precise and that internal fixtures use no any, assertion, or non-null assertion.
Point to App, WorkItemList, WorkItemCard, each page module, the shared utility, and test setup and state what each owns.
Confirm that one current collection exists in state and that visible items, counts, labels, next actions, and empty text are derived.
Inspect the status update and confirm it uses a functional setter, map, object spread, stable ID, and no mutation.
Activate planned, active, and done actions and confirm each next status, next action, live message, and retained focus.
Use the single-item filter, activate its card, and confirm stable URL, removed card, empty result, current live message, and feedback focus.
Copy and reload every valid filter and confirm the URL, select, collection, and counts agree.
Open an unsupported filter and confirm visible recovery, All statuses, complete collection, stable counts, and no assertion or crash.
Use Board and Status guide links plus Back and Forward and confirm current navigation, titles, headings, and focus.
Open every known item detail after a current-session status change and confirm the current matching data.
Open an unknown item ID and an unmatched path and confirm distinct recovery headings and routes back to the board.
Confirm that path navigation focuses a route h1 while filter-only navigation keeps focus on the select.
Confirm one main and one page h1 per route plus semantic navigation, controls, collections, cards, facts, labels, and feedback.
Use pointer, Tab, Shift+Tab, Enter, and Space and confirm complete operation plus visible focus.
Verify contrast, no color-only meaning, 320 CSS pixels, 200 percent zoom, long-text wrapping, navigation wrapping, and no horizontal page overflow.
Map CLIENT-01 through CLIENT-08 to test names, starting states, outcomes, plausible regressions, and final statuses.
Confirm that tests use roles, names, labels, visible text, values, and focus rather than Hook state, classes, instances, or private call order.
Run the controlled one-value mutation, confirm one focused meaningful failure, restore the source, and confirm no test modifier or debug artifact remains.
Run npm test, typecheck, lint, build, and git diff --check from the committed dependency graph.
Read README and docs/stage-2-verification.md and confirm commands, responsibilities, scenarios, environment, browser matrix, limits, tested commit, and Stage 3 handoff are current.
Open the pull request and confirm outcome, scope, commit sequence, automated evidence, browser evidence, known limits, review focus, and evidence locations.
Confirm that review contains one specific product observation and one source-or-test observation without an invented defect.
Confirm that every review item has an author decision, focused verification, and complete rerun when source changed.
Confirm that the approved pull request is merged with focused history preserved and that every contributor has clean synchronized main.
Run the fresh-clone install, test, typecheck, lint, build, and browser smoke path without editing source.
Confirm that the Teams submission identifies the repository, merged pull request, final remote main commit, contributors, roles, evidence, and private individual reflection.

Assessment

The Stage 2 review uses observable evidence from the required path:

Area	Weight	Evidence
React architecture and state	25%	Precise types, focused components, one state owner, immutable updates, derived values, varied fixtures, and no duplicated state
Routes, URL state, and interaction	20%	Static and dynamic routes, runtime search validation, navigation, current detail data, recovery, titles, feedback, and intentional focus
Automated tests and quality gates	20%	Eight meaningful contracts, accessible queries, test isolation, controlled sensitivity proof, typecheck, lint, and build
Accessibility and responsive behavior	15%	Semantics, names, keyboard operation, focus visibility, live feedback, contrast, 320 pixels, zoom, wrapping, overflow, and real-browser evidence
Collaboration and feedback	10%	Focused history, complete pull request, independent review, product and source-or-test observations, responses, approval, and safe integration
Documentation and delivery	10%	Accurate README, Stage 2 verification record, limits, fresh-clone recovery, final commit, submission evidence, and server-stage handoff

Optional extensions do not affect whether the required assignment is complete. Assessment uses the stable definition of done above.

Assignment-wide assistance

Checkpoint sections provide orientation, targeted hints, and ordered subgoals. Open the deeper support below when a partial structure or complete reference route will help you resume.

Assistance 4 — Review a partial Stage 2 audit structure

Use this file map to locate missing ownership. It is not a second architecture.

src/
  App.tsx                              current collection and shared update
  App.test.tsx                         routed client behavior
  components/
    WorkItemCard.tsx                   one item and next action
    WorkItemList.tsx                   collection and empty result
    WorkItemList.test.tsx              focused empty contract
  data/sample-work-items.ts            trusted fictional fixture
  pages/
    BoardPage.tsx                      URL filter, derived view, feedback, focus
    StatusGuidePage.tsx                status definitions
    WorkItemDetailsPage.tsx            dynamic ID lookup and recovery
    NotFoundPage.tsx                   unmatched-path recovery
  test/setup.ts                        matchers and test reset
  types/work-item.ts                   shared work-item model
  utils/work-status.ts                 shared status labels or guards
docs/stage-2-verification.md            evidence and handoff
README.md                               contributor recovery path

Use this ordered audit when a blank review page is the barrier:

Verify fixture and type boundaries.
Verify component inputs and one-way data flow.
Trace all three status transitions.
Trace valid and invalid search state.
Trace known, unknown, and unmatched routes.
Verify both interaction-focus outcomes and route-heading focus.
Map all eight automated contracts.
Run the real-browser matrices.
Reconcile README and the verification document.
Publish for independent review.

Use one active step. Record other ideas under a Later heading without expanding the required scope.

Assistance 5 — Review the complete guided Stage 2 reference routeExample solution

The four lessons contain a complete guided reference baseline. Use the finished source blocks and verification sections in this order:

Build typed React components — model, fixture collection, component props, list identity, empty result, semantics, and responsive card layout.
Manage events and interface state in React — callback path, state ownership, immutable replacement, derived filters and counts, live feedback, and filtered focus recovery.
Build routes and URL state with React Router — route table, MemoryRouter-compatible App boundary, URL search narrowing, detail recovery, current navigation, title, heading focus, and direct-load checks.
Test application behavior with Vitest — dependency setup, jsdom boundary, empty and routed tests, semantic queries, sensitivity check, browser limits, and README handoff.

A complete required Stage 2 result has these relationships:

trusted WorkItem[] fixture
  → App WorkItem[] state
  → Routes selects one page
  → BoardPage derives URL-filtered items and counts
  → WorkItemList maps stable item IDs
  → WorkItemCard reports item ID plus next WorkStatus
  → BoardPage records feedback and decides focus recovery
  → App replaces the matching record immutably
  → React renders current state
  → tests check selected user-visible contracts
  → production preview checks the real browser boundary

The assignment-specific work remains required even when you use the reference source:

adapt the fixture to at least five records;
update fixture-owned expectations;
add CLIENT-05 and CLIENT-06 when they are not already covered;
complete the controlled sensitivity proof;
complete the real-browser matrices;
update README and docs/stage-2-verification.md;
obtain independent review and respond to it;
merge and synchronize main; and
verify a fresh clone.

Reference use does not replace the review or evidence. If the reference and current branch disagree, test the product contract and installed package versions before copying a line.

Optional Stage 2 extensions

The required assignment is complete when it meets the definition of done and passes the self-check. These routes do not affect completion or assessment. Use a separate reviewed branch and commit for each selected extension.

Add combined search and sort URL state

Add validated q and sort search parameters while preserving the existing status parameter. Define defaults by removing default keys, preserve unrelated keys when one control changes, and test combined copy, reload, Back, Forward, and unsupported values.

Add a client-only create form

Add a labeled form that creates an in-memory work item with a generated stable ID. Validate empty and whitespace-only fields, show visible error and success feedback, manage focus, and add behavior tests. Document that reload still restores the fixture.

Replace the status transition with a reducer

Move the collection transition into a typed reducer only when the new action model makes the state change easier to test and explain. Compare the reducer with the current functional setter and record the tradeoff. Do not add a global store.

Add one real-browser automated path

Use a current supported browser test runner for CLIENT-04 or CLIENT-06 against the built application. Keep the jsdom suite and explain which browser-specific risk the new test covers. Do not expand to every route without another identified risk.

Add route-aware breadcrumbs

Add semantic breadcrumbs on guide, detail, missing-item, and not-found pages. Keep the current page as text with aria-current="page", use links for ancestors, and test names, navigation, focus, and narrow wrapping.

Submission

Submission destination: Teams.

Submit one Teams message per pair. Include the private repository URL, merged Stage 2 pull-request URL, final verified remote main commit ID, path to docs/stage-2-verification.md, automated test count and result, named browser and browser-check summary, known limits, and the branch author, reviewer, and integration owner. Grant the teacher repository access before submission.

Each contributor also submits a separate 200–300 word reflection in Teams. Name one React or test responsibility you owned, one specific review observation you gave, one review item you received and how you evaluated it, one current strength, one skill you want to practice during the Express stage, and one example of how the TypeScript client concepts would transfer to a PHP project. Keep individual reflections out of the shared repository. Submit by the deadline agreed with your teacher.

Safe stopping point

Stop only at a working boundary: after the evidence contract is committed, after the adapted client and eight tests pass, after browser evidence is recorded, after a review response is pushed, or after the approved pull request is merged and every contributor has pulled main.

Before you stop, add this resume note to docs/stage-2-verification.md or the active pull request:

What works: Latest passing automated command and visible browser result.
Current branch and commit: Exact branch name and full or short commit ID.
Active contract: CLIENT ID and expected result.
Review state: Draft, ready, changes requested, approved, or merged.
What remains: Next unmet requirement, failed check, or unreviewed relationship.
Next action: One command, file edit, browser path, test, or review response.
Required setup: Project folder, installed dependencies, preview state, browser route, account, and reviewer availability.

Do not stop with a deliberate mutation, .only, .skip, unresolved merge, active production preview, unexplained uncommitted file, or ambiguous test failure. The clean accepted Stage 2 main becomes the starting state for the Express server lesson.