Project stage 1: Prepare the application workspace

Outcome

You will create Stage 1 of Delivery Board, the continuing Module 3.1 application. The result is a private shared repository with a verified React and TypeScript workspace, a bounded Sass layer, one typed sample work item, a static accessible page, two reviewed branches, and documentation that another contributor can use.

Later stages will add reusable React components, interface state, routes, automated tests, an Express API, and a Capacitor target. Stage 1 establishes the recovery point those changes will build on.

What you will practice

Create and explain a repeatable React, TypeScript, Vite, npm, and Sass project workflow.
Model one internal work item with precise TypeScript types and no unverified assertion.
Keep source, dependencies, generated output, and external data responsibilities separate.
Use semantic HTML, responsive CSS, and visible text to make the static baseline accessible.
Coordinate two focused branches through review and integrate them into a clean shared main.
Document setup, project decisions, checks, limits, contribution roles, and the next stage.

What is new and what is reused

New: The continuing Delivery Board repository, team ownership of two setup branches, a separated types and data structure, a Stage 1 definition of done, and a durable baseline for the later course stages.
Reused: JavaScript-to-TypeScript concepts, the official Vite react-ts template, Node.js and npm, the explicit typecheck command, Sass variables and mixins, responsive and accessible design, private GitHub repositories, focused commits, pull-request review, and synchronized main.

Starting point

Before you start

The completed JavaScript-to-TypeScript, Vite workflow, and team version-control lessons.
VS Code, Node.js 24 LTS, npm, Git, a current browser, and working GitHub authentication.
A parent folder for Module 3.1 assignments. It must not be inside m3-workflow-lab or another Git repository.
A pair with separate Git identities and working copies, or an agreed individual route with the teacher as reviewer.
No starter download is required. Create this project from the official Vite template.

Current state: The m3-workflow-lab proves the selected tools and branch workflow, but the continuing assessed Delivery Board repository does not exist.
First action: Create a short shared note with the two contributor names, repository owner, Branch A author, Branch B author, reviewer for each branch, and the exact parent folder where delivery-board will be created.
First checkpoint: Every role has one named owner, both contributors can sign in to GitHub, and the chosen parent folder is outside every existing repository.
Help trigger: Open the assistance beside the active checkpoint or ask for help if a role has no owner, the repository root is unclear, an account or credential prompt is unexpected, a package command cannot find package.json, a generated folder appears in Git, two people need to edit the same file at the same time, a review request is unclear, or a required check still fails after the matching recovery step.

Requirements

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

Required product and source

Create one application named Delivery Board in a folder and npm package named delivery-board.
Use the official Vite react-ts template with React, TypeScript, and the generated Vite React plugin configuration.
Keep the project-owned source in src/App.tsx, src/main.tsx, src/styles.scss, src/types/work-item.ts, and src/data/sample-work-item.ts.
Define WorkStatus as planned, active, or done and define one WorkItem with id, title, description, status, and labels.
Render one internal sample work item. The sample is trusted source data in this stage and must satisfy WorkItem without any or a type assertion.
Set the document title to Delivery Board and remove every unused generated demonstration import and asset.

Toolchain and generated output

Use Node.js 24 LTS and npm. Record the checked versions in README.md.
Add a typecheck npm script that runs tsc -b and keep the generated dev, build, lint, and preview scripts.
Install sass as a development dependency and import one SCSS entry file from src/main.tsx.
Use at least two purposeful Sass variables and one mixin. Keep runtime theme values in CSS custom properties only if you add a runtime theme.
Make npm run typecheck, npm run lint, and npm run build pass from clean source.
Treat node_modules and dist as generated folders. Do not edit or commit them.

Accessibility and responsive behavior

Use one main element, one page h1, and a section with a descriptive h2 for the sample work item.
Expose the work-item identifier, status, and labels as visible text. Do not communicate status through color alone.
Render the labels as a semantic list and give each rendered list item a stable key.
Keep text contrast at WCAG AA level and keep long text able to wrap.
Keep the complete page usable without horizontal page scrolling at 320 CSS pixels and at 200 percent browser zoom.
Do not add motion, custom controls, or ARIA that native semantic HTML does not need in this static stage.

Team Git and review

Use one private GitHub repository named delivery-board and grant access only to the contributors and teacher who need it.
Commit the verified generated baseline to main before feature work. Exclude dependencies, builds, secrets, and unrelated files.
Complete Branch A on chore/sass-baseline and Branch B on feature/work-item-model. Branch B starts only after the accepted Branch A result reaches main.
Each pair contributor authors one pull request and reviews the other. An individual author uses the teacher as reviewer for both pull requests.
Each pull request states its outcome, verification, and review focus. Each review records at least one specific test observation or inline code comment.
The author responds to feedback with a change or an evidence-based explanation, then the reviewer records the final decision.
Integrate accepted work into main without force push. Finish with remote and local main synchronized and every working tree clean.

Documentation and evidence

README.md states the product purpose, current static behavior, file responsibilities, setup commands, npm scripts, Sass boundary, type model, test procedure, known limits, and Stage 2 continuation point.
README.md lists branch ownership and reviewer roles without private personal information beyond the contributor names used for course work.
Record the final verified commit ID and the two merged pull-request links in README.md.
Keep review, check, and branch evidence available in the private GitHub repository.

Design freedom

Choose the color palette, typeface stack, spacing values, border treatment, and label presentation within the accessibility requirements.
Choose the exact sample work-item text and labels. Keep the data fictional and suitable for a small software-delivery team.
Choose which pair contributor owns Branch A and Branch B. Keep the required branch names so review evidence has a consistent location.

Out of scope for Stage 1

Do not add component props, editable state, event handlers, routing, automated tests, an API, persistence, a database, authentication, deployment, or Capacitor yet.
Do not add a state-management library, CSS framework, component library, schema library, Docker setup, or continuous-integration service to the required path.
Do not copy the hidden .git folder from m3-workflow-lab or another project.
Do not submit node_modules, dist, credentials, private data, or a generated archive as the source repository.

Definition of done

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

a fresh clone can run npm ci, npm run typecheck, npm run lint, and npm run build without a source change;
the development and production-preview pages show the same sample work item and required semantics;
the page passes the narrow-width, zoom, contrast, wrapping, and Console checks;
both required pull requests are merged with author, reviewer, check, and response evidence;
README.md lets another contributor start the project and identifies what Stage 2 will add;
the final verified commit is on remote main and every contributor has pulled it;
git status reports a clean working tree for every contributor; and
the submission contains the repository, pull-request, commit, and individual reflection evidence described below.

Checkpoint 1: Create and publish the generated baseline

Only the repository owner performs project creation. The second contributor waits for the remote baseline, then clones it. This avoids two unrelated initial histories.

From the agreed parent folder, create the application:

npm create vite@latest delivery-board -- --template react-ts
cd delivery-board
npm install
npm install --save-dev sass

Open package.json. Add "typecheck": "tsc -b" after dev and before build in the scripts object. Keep the other generated scripts.

Run the generated baseline:

npm run typecheck
npm run lint
npm run build
npm run dev

Open the reported development URL and confirm that the generated page loads without a Console error. Stop the development server with Ctrl+C after the check.

Initialize the private repository boundary:

git init -b main
git check-ignore -v node_modules/
git check-ignore -v dist/
git status --short
git add --all
git diff --cached --stat
git diff --cached
git commit -m "chore: create Delivery Board workspace"
git status

Before the commit, remove any staged generated folder, secret, unrelated file, or copied Git history. The staged diff can contain current Vite demonstration files; Branch A and Branch B will replace them.

Create an empty private GitHub repository named delivery-board, connect it as origin, and push main:

git remote add origin https://github.com/OWNER-USERNAME/delivery-board.git
git push -u origin main

Invite the other contributor and the teacher through the repository access settings. After the invitation is accepted, the second contributor clones and verifies the baseline:

git clone https://github.com/OWNER-USERNAME/delivery-board.git
cd delivery-board
npm ci
npm run typecheck
npm run lint
npm run build
git status

Check

Both working copies show the same initial commit on main.
Both check sequences pass.
node_modules and dist remain absent from GitHub.
The repository is private and only intended accounts have access.
The second working tree is clean after npm ci and the checks.

Assistance for Checkpoint 1

Assistance 1 — Identify the one owner of project creation

Use the role note from the starting point. One person creates delivery-board, its initial Git history, and the empty GitHub remote. The other contributor joins by cloning after the first push.

Assistance 2 — Separate package source from generated folders

package.json and package-lock.json belong in Git. node_modules can be recreated with npm ci, and dist can be recreated with npm run build. Use git check-ignore -v before the first commit.

Assistance 3 — Follow the baseline subgoals in order

Verify Node and the parent folder → scaffold once → install packages → add typecheck → run all checks → initialize Git → inspect the staged boundary → commit → create an empty private remote → push → grant access → clone → verify the clone.

Checkpoint: The team shares one safe generated baseline

What now works: The private delivery-board repository contains one verified Vite React TypeScript baseline, both contributors can build it, and generated or private content remains outside Git.
Files changed: package.json, package-lock.json, .gitignore, Generated Vite source and configuration
What remains: Replace the generated visual layer through the reviewed Sass baseline branch.
Next action: The Branch A author synchronizes main and creates chore/sass-baseline.
If it does not work: Compare the repository root, current branch, remote URL, ignored folders, latest commit, and three npm check results before branch work.

Checkpoint 2: Review and integrate the Sass baseline

The Branch A author works from synchronized main:

git switch main
git pull --ff-only
git switch -c chore/sass-baseline

Complete these source changes:

Rename src/index.css to src/styles.scss.
Update src/main.tsx to import ./styles.scss.
Remove the generated CSS and asset imports from src/App.tsx.
Delete only generated files that no remaining source or index.html reference uses.
Set the index.html document title to Delivery Board.
Replace the generated application with a temporary semantic shell that contains main, a page h1, and text that identifies Stage 1 workspace.
Add the responsive Sass foundation.

The Sass foundation must include:

at least two named spacing or layout variables;
one mixin for a repeated surface or focus treatment;
box-sizing: border-box;
readable foreground and background colors;
a bounded content width;
wrapping for long text;
no page overflow at 320 CSS pixels; and
one narrow-width adjustment that keeps all content visible.

Run the complete verification:

npm run typecheck
npm run lint
npm run build
npm run preview

Check the production preview at the normal width, 320 CSS pixels, and 200% zoom. Inspect the Console. Stop the preview after verification.

Commit and publish the branch:

git status --short
git diff
git add index.html src/App.tsx src/main.tsx src/styles.scss
git add --update src
git diff --cached
git commit -m "feat: add Sass application baseline"
git push -u origin chore/sass-baseline
git status

git add --update src stages modifications and deletions for source paths that Git already tracks. The preceding exact command stages the new styles.scss file. Inspect the staged diff to confirm that the renamed stylesheet and only the intended generated-file deletions are present.

Open a pull request into main. The description must include:

the static shell outcome;
typecheck, lint, build, and preview evidence;
normal-width, 320-pixel, 200%-zoom, and Console results; and
a request to review the stylesheet import, unused files, Sass boundary, wrapping, and overflow behavior.

The Branch B author reviews the diff and preview evidence. Record at least one specific observation. If no required change is found, state which behavior and source relationship you tested before approval. The Branch A author responds to each question or request.

Merge only after approval. Delete the remote branch, then both contributors synchronize local main and rerun the checks.

Check

Remote main contains the accepted Sass baseline.
main.tsx imports styles.scss and no source imports a deleted generated file.
The preview meets the static semantics, contrast, wrapping, width, zoom, and Console requirements.
The pull request records author, reviewer, verification, review observation, author response, and final decision.

Assistance for Checkpoint 2

Assistance 1 — Locate the generated visual layer

Inspect stylesheet and image imports in src/main.tsx, src/App.tsx, and index.html. Keep a file until no remaining source or HTML reference uses it.

Assistance 2 — Keep Sass focused on build-time reuse

Use variables for stable spacing or width values and one mixin for a related group of declarations. Keep semantic structure in App.tsx and responsive behavior in the SCSS. Vite needs the sass package, not a separate Sass plugin.

Assistance 3 — Review the branch by behavior and source relationship

Check import path → Sass compilation → generated CSS → browser layout. Then check source cleanup → build → Network and Console results. Review the narrow layout and zoom before approving the diff.

Checkpoint: The reviewed Sass baseline is on main

What now works: The generated demonstration is replaced by a semantic Delivery Board shell, Sass compiles through Vite, responsive checks pass, and the first reviewed branch is integrated.
Files changed: index.html, src/App.tsx, src/main.tsx, src/styles.scss, Pull-request history
What remains: Add the separated TypeScript model, internal fixture, and complete static work-item page through Branch B.
Next action: The Branch B author pulls the accepted main and creates feature/work-item-model.
If it does not work: Restore synchronized main, inspect every remaining import, run the three checks, and verify the production preview before another branch begins.

Checkpoint 3: Review and integrate the typed work-item model

The Branch B author begins only after Branch A is merged:

git switch main
git pull --ff-only
npm ci
npm run typecheck
npm run lint
npm run build
git switch -c feature/work-item-model

Create these responsibilities:

File	Required responsibility
`src/types/work-item.ts`	Export `WorkStatus` and `WorkItem` only
`src/data/sample-work-item.ts`	Import `WorkItem` as a type and export one fictional `sampleWorkItem`
`src/App.tsx`	Import the sample, render the static page, and keep formatting behavior near its use
`src/styles.scss`	Style the new semantic work-item structure without hiding required text

The required type model is:

WorkStatus: "planned" | "active" | "done";
id: string;
title: string;
description: string;
status: WorkStatus; and
labels: array of strings.

Use a fictional ID such as WI-001. Do not use any, as WorkItem, a non-null assertion, or runtime JSON parsing for this internal source fixture. A normal type annotation on sampleWorkItem must prove that the fixture matches the model.

Render:

Delivery Board as the page h1;
one short product description;
a section with an h2 that uses the sample title;
the full sample description;
the ID and status as labeled visible text;
the labels in a ul; and
a visible label-count sentence with correct zero, singular, and plural wording.

The initial fixture contains at least two unique labels. Deliberately test zero, one, and two labels, then restore the submitted fixture to two or more labels.

Run the source and browser checks:

npm run typecheck
npm run lint
npm run build
npm run preview

At the production preview, verify semantics, all visible fields, zero/one/two label wording, 320 CSS pixels, 200% zoom, text wrapping, and the Console. Restore the final fixture before you stop the preview.

Commit and publish the focused source change:

git status --short
git diff
git add src/App.tsx src/styles.scss src/types/work-item.ts src/data/sample-work-item.ts
git diff --cached
git commit -m "feat: add typed work item baseline"
git push -u origin feature/work-item-model
git status

Open a pull request into main. Request review of:

the model precision and type-only import;
the fixture-to-model relationship;
semantic heading, description-list, and label-list structure;
zero, one, and multiple label wording;
stable list keys;
narrow-width, zoom, wrapping, contrast, and Console evidence; and
scope: no Stage 2 interaction, routing, API, or test framework.

The Branch A author reviews the diff and performs at least one deliberate data variation. Record a specific observation or inline comment and the evidence. The Branch B author replies, updates the same branch when required, reruns all checks, and pushes the response. The reviewer records the final decision.

Merge the accepted pull request, delete the remote branch, and synchronize both local main branches.

Check

Both working copies show the same typed static page from main.
Zero labels renders 0 labels, one label renders 1 label, and the restored fixture renders the correct plural result.
Type checking rejects an unsupported status during a deliberate test and passes after restoration.
Both PRs now record both contributors as an author and reviewer across the stage.

Assistance for Checkpoint 3

Assistance 1 — Separate model, fixture, and rendering files

Put reusable type declarations in src/types, the trusted internal sample in src/data, and JSX rendering in App.tsx. Import the model with import type because the alias does not exist at runtime.

Assistance 2 — Derive the label output from one source

Read sampleWorkItem.labels.length for the count and map the same labels array into list items. The count sentence and visible list should not use separate copied values.

Assistance 3 — Build the typed page by functional subgoal

Define and deliberately break the model → restore a valid fixture → render heading and description → render labeled ID and status → render labels with stable keys → format zero, singular, and plural counts → verify semantics → verify responsive behavior → run the complete command sequence.

Checkpoint: The typed static Delivery Board baseline is on main

What now works: The accepted model, fixture, semantic rendering, label behavior, responsive styles, and review evidence are integrated into synchronized main.
Files changed: src/types/work-item.ts, src/data/sample-work-item.ts, src/App.tsx, src/styles.scss, Pull-request history
What remains: Document the complete recovery path, perform final clone verification, record the final commit, and submit the Stage 1 evidence.
Next action: Choose one contributor to draft README.md on a documentation branch and the other to review it.
If it does not work: Return to synchronized main, confirm the four file responsibilities, restore the valid fixture, and repair the first failed type, lint, build, or browser check.

Checkpoint 4: Document and verify the handoff

Create a short documentation branch from synchronized main:

git switch main
git pull --ff-only
git switch -c docs/stage-1-handoff

Update README.md with these sections:

Product: Delivery Board, intended user, and current static result.
Stage 1 scope: What exists and what remains out of scope.
Requirements: Node.js 24 LTS and npm.
Setup: Clone, npm ci, and development-server commands.
Scripts: What dev, typecheck, lint, build, and preview verify.
Source responsibilities: The five required source files and generated-output boundary.
Type model: WorkStatus, WorkItem, internal fixture trust, and the future need for runtime validation at API boundaries.
Sass boundary: Which values and patterns Sass resolves before the browser receives CSS.
Manual verification: Semantics, labels, zero/one/many wording, narrow width, zoom, contrast, wrapping, Network, and Console.
Team workflow: Branch A and Branch B author/reviewer roles and both merged pull-request links.
Known limits: Static fixture, no state, no routes, no tests, no server, and no persistence.
Stage 2: Typed components, state, routes, and behavior tests.

Review and merge the README change through the same branch workflow. This third documentation pull request can be authored by either contributor, but the other person reviews it.

After merge, both contributors update main and run the full verification. Then one contributor performs a fresh-clone test in a separate folder. Do not copy the existing node_modules or .git folder.

git clone https://github.com/OWNER-USERNAME/delivery-board.git delivery-board-verification
cd delivery-board-verification
npm ci
npm run typecheck
npm run lint
npm run build
npm run preview

Verify the production page, stop the preview, and record the result in the merged README through a final documentation commit if the result was not already known. The temporary verification clone is evidence, not a second project repository.

In the normal working copy, record the final commit ID after every required change reaches main:

git switch main
git pull --ff-only
git status
git rev-parse --short HEAD
git log --oneline --decorate --graph -10

Add that commit ID to README.md only if the documentation workflow can do so without creating a self-referential claim. A practical alternative is to record the verified commit ID in the Teams submission and state in README that the current merged main is the Stage 1 baseline.

Check

A contributor who starts from a fresh clone can install, check, build, preview, and understand the project from README.md.
The README does not contain credentials, private reflections, or claims that were not tested.
The final commit on GitHub matches the submitted commit ID.
Every normal working copy is on clean synchronized main.

Assistance for Checkpoint 4

Assistance 1 — Write README for the next contributor

Start with the exact commands and current behavior that a new contributor needs. Describe Stage 1 as it exists. Keep future ideas in the Stage 2 or known-limits sections.

Assistance 2 — Avoid a self-referential commit ID

A commit cannot contain its own final hash because changing README creates another commit. Record the externally verified final hash in Teams, or state in README that the merged main branch is the baseline and link the merged pull requests there.

Assistance 3 — Perform the handoff in one order

Merge documentation → update both normal working copies → create a separate fresh clone → run npm ci → run checks and build → preview and inspect → stop the server → record the final remote main hash → confirm every normal working tree is clean.

Checkpoint: Stage 1 is reproducible from the private remote

What now works: README documents the verified source and workflow, a fresh clone passes every required command and browser check, and the submitted commit identifies the remote Stage 1 baseline.
Files changed: README.md, Private GitHub repository, Merged pull-request history, Teams submission evidence
What remains: Complete the final self-check and submit the repository, pull-request, commit, and reflection evidence.
Next action: Run every self-check item against the fresh-clone result and the normal synchronized working copies.
If it does not work: Use README from top to bottom in the verification clone. The first missing command, file responsibility, or observed result is the next documentation or source repair.

Self-check

Complete these checks against the required result.

Confirm that delivery-board is a private repository and that only intended contributors and the teacher have access.
Confirm that package.json contains dev, typecheck, build, lint, and preview scripts and declares sass as a development dependency.
Confirm that package-lock.json is committed while node_modules and dist are ignored and absent from GitHub.
Run npm ci, npm run typecheck, npm run lint, and npm run build in a fresh clone without editing source.
Confirm that index.html uses the Delivery Board document title and no source imports an unused generated demonstration asset.
Point to the separate type, fixture, rendering, entry, and style files and state what each file owns.
Change the fixture status to an unsupported value, confirm that typecheck fails, restore the supported value, and confirm that typecheck passes.
Test zero, one, and at least two labels and confirm the visible count wording and list remain synchronized.
Inspect the page structure and confirm one main, one page h1, one descriptive work-item h2, labeled ID and status text, and a semantic label list.
Verify the production preview at 320 CSS pixels and 200 percent zoom with no horizontal page scrolling or clipped required content.
Confirm sufficient text contrast, long-text wrapping, and no red application error in the Console.
Open the Sass and model pull requests and confirm their outcome, checks, review focus, test observation or inline comment, author response, final review, and merge state.
Confirm that both pair contributors authored and reviewed required work, or that the approved individual route contains teacher reviews.
Read README from a fresh clone and confirm that setup, scripts, files, model, Sass, tests, limits, workflow, and Stage 2 are accurate.
Confirm that the submitted commit is the current remote main result and that every normal working copy is on clean synchronized main.

Assessment

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

Area	Weight	Evidence
Toolchain and reproducibility	25%	Fresh clone, lockfile, scripts, Sass dependency, passing typecheck/lint/build, and production preview
Type model and source boundaries	20%	Precise model, type-only import, typed fixture, separated files, no `any` or assertion, and correct derived label output
Team Git and feedback	25%	Safe baseline, two required branches, focused commits, authored and reviewed PRs, feedback responses, integration, and clean synchronized `main`
Accessibility and responsive correctness	15%	Semantics, visible status, label list, contrast, wrapping, 320-pixel behavior, 200% zoom, and Console result
Documentation and delivery evidence	15%	Accurate README, known limits, fresh-clone instructions, PR links, final commit, submission evidence, and bounded reflection

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

Assignment-wide assistance

The checkpoint sections contain orientation, targeted hints, and ordered subgoals. Open the deeper assistance below when a code skeleton or complete reference baseline will help you resume.

Assistance 4 — Review a partial Stage 1 source skeleton

Use this skeleton to establish file boundaries. Complete the rendering and styles against the visible requirements.

export type WorkStatus = "planned" | "active" | "done";

export type WorkItem = {
  id: string;
  title: string;
  description: string;
  status: WorkStatus;
  labels: string[];
};

import type { WorkItem } from "../types/work-item";

export const sampleWorkItem: WorkItem = {
  id: "WI-001",
  title: "Prepare the accessible navigation review",
  description: "Confirm the keyboard path, current-page state, and narrow layout before integration.",
  status: "planned",
  labels: ["frontend", "accessibility"],
};

import { sampleWorkItem } from "./data/sample-work-item";

function formatLabelCount(count: number): string {
  return `${count} ${count === 1 ? "label" : "labels"}`;
}

function App() {
  return (
    <main className="app-shell">
      {/* Add the product header. */}
      {/* Add one labeled work-item section. */}
      {/* Render the labels array as a list. */}
      <p>{formatLabelCount(sampleWorkItem.labels.length)}</p>
    </main>
  );
}

export default App;

Assistance 5 — Review one complete Stage 1 reference baselineExample solution

This reference completes the project-owned source after the official Vite template and required package commands are in place. Your design can differ while meeting the same requirements.

export type WorkStatus = "planned" | "active" | "done";

export type WorkItem = {
  id: string;
  title: string;
  description: string;
  status: WorkStatus;
  labels: string[];
};

import type { WorkItem } from "../types/work-item";

export const sampleWorkItem: WorkItem = {
  id: "WI-001",
  title: "Prepare the accessible navigation review",
  description: "Confirm the keyboard path, current-page state, and narrow layout before integration.",
  status: "planned",
  labels: ["frontend", "accessibility"],
};

import { sampleWorkItem } from "./data/sample-work-item";

function formatLabelCount(count: number): string {
  return `${count} ${count === 1 ? "label" : "labels"}`;
}

function App() {
  return (
    <main className="app-shell">
      <header className="product-header">
        <p className="eyebrow">Module 3.1 project</p>
        <h1>Delivery Board</h1>
        <p>Review one typed work item before the interactive client is added.</p>
      </header>

      <section className="work-item" aria-labelledby="sample-work-item-heading">
        <h2 id="sample-work-item-heading">{sampleWorkItem.title}</h2>
        <p>{sampleWorkItem.description}</p>

        <dl className="work-item-facts">
          <div>
            <dt>Identifier</dt>
            <dd>
              <code>{sampleWorkItem.id}</code>
            </dd>
          </div>
          <div>
            <dt>Status</dt>
            <dd>{sampleWorkItem.status}</dd>
          </div>
        </dl>

        <h3>Labels</h3>
        <ul className="label-list">
          {sampleWorkItem.labels.map((label) => (
            <li key={label}>{label}</li>
          ))}
        </ul>
        <p>{formatLabelCount(sampleWorkItem.labels.length)} total.</p>
      </section>
    </main>
  );
}

export default App;

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import App from "./App";
import "./styles.scss";

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <App />
  </StrictMode>,
);

The generated Vite entry uses a non-null assertion for its fixed #root element. That assertion is permitted only at this template-controlled boundary because index.html provides the element. Do not use assertions to bypass the WorkItem model or external-data validation.

$space-unit: 0.25rem;
$space-4: $space-unit * 4;
$space-6: $space-unit * 6;
$space-8: $space-unit * 8;
$content-width: 52rem;
$surface-radius: 0.75rem;

@mixin surface {
  border: 1px solid #b8c8bf;
  border-radius: $surface-radius;
  background: #ffffff;
  box-shadow: 0 0.25rem 1rem rgb(23 33 28 / 10%);
}

:root {
  font-family: Inter, system-ui, sans-serif;
  color: #17211c;
  background: #f2f6f3;
  font-synthesis: none;
  text-rendering: optimizeLegibility;
}

* {
  box-sizing: border-box;
}

body {
  min-width: 20rem;
  min-height: 100vh;
  margin: 0;
}

.app-shell {
  width: min(calc(100% - 2rem), $content-width);
  margin: $space-8 auto;
}

.product-header,
.work-item {
  @include surface;

  padding: $space-8;
}

.work-item {
  margin-block-start: $space-6;
}

.eyebrow {
  margin-block: 0 $space-4;
  color: #1c6243;
  font-weight: 700;
  letter-spacing: 0.04em;
  text-transform: uppercase;
}

h1,
h2,
p,
dd,
code,
li {
  overflow-wrap: anywhere;
}

h1,
h2 {
  margin-block-start: 0;
}

.work-item-facts {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 10rem), 1fr));
  gap: $space-4;
}

.work-item-facts div {
  border-inline-start: 0.25rem solid #1c6243;
  padding-inline-start: $space-4;
}

.work-item-facts dt {
  font-weight: 700;
}

.work-item-facts dd {
  margin: 0.25rem 0 0;
}

.label-list {
  display: flex;
  flex-wrap: wrap;
  gap: 0.5rem;
  padding: 0;
  list-style: none;
}

.label-list li {
  border: 1px solid #1c6243;
  border-radius: 999px;
  padding: 0.25rem 0.75rem;
  color: #174d37;
  background: #e6f2eb;
}

@media (max-width: 30rem) {
  .app-shell {
    margin-block: $space-4;
  }

  .product-header,
  .work-item {
    padding: $space-4;
  }
}

Set the existing index.html title to:

<title>Delivery Board</title>

Keep the generated Vite and TypeScript configuration. Add the typecheck script, keep the generated scripts, install sass, remove unused demonstration files, then verify:

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

Test zero, one, and two labels by changing only the fixture array, then restore the submitted fixture. Inspect the final diff and complete the required review workflow rather than copying the reference directly to main.

Optional Stage 1 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 new reviewed branch for each selected extension.

Validate a JSON fixture at runtime

Move a second fictional work item into a JSON string, assign the parsed value to unknown, and validate it before rendering. Keep the internal typed fixture as the required baseline. Test one valid and two invalid structures.

Model blocked work precisely

Add a discriminated union that requires blockReason only for a blocked work item. Render the reason as visible text and prove that TypeScript rejects a blocked item without the required reason.

Split Sass into modules

Move variables and the mixin into a Sass partial loaded with @use. Keep the generated CSS behavior equivalent and document the source boundary in README.md.

Add a pull-request template

Add a repository pull-request template that exposes outcome, verification, review focus, accessibility evidence, and scope. Review it through its own pull request and confirm that it appears in a new draft.

Compare a second toolchain

Create a temporary comparison note for one valid alternative such as plain CSS instead of Sass or another front-end build tool instead of Vite. Compare responsibilities, migration cost, and curriculum fit. Do not replace the required stack in the continuing project.

Safe stopping point

Stop only at a working boundary: after the generated baseline is pushed, after an approved pull request is merged and both contributors have pulled main, or after the final fresh-clone verification.

Before you stop, record this resume note in the shared work note or current pull request:

What works: The latest passing command and visible browser result.
Current branch: The exact branch name and owner.
Review state: Draft, ready, changes requested, approved, or merged.
What remains: The next unmet requirement or failed check.
Next action: One command, file edit, test, or review response.
Required setup: Project folder, server state, account, and reviewer availability.

Do not leave a deliberate type error, invalid fixture, unresolved conflict, active production preview, or ambiguous uncommitted change as the resume state.