Final project: Build and present a small website

Outcome

Plan, build, verify, document, and present an original four-page website. The finished delivery will combine semantic HTML, reusable responsive CSS, a deliberate visual system, prepared raster and vector assets, basic search information, a complete quality report, reader-focused documentation, and a short evidence-based presentation.

This is the larger Level 1 project. The required result is fixed, but you choose one content brief, write the content, make the design decisions, and decide how the page system represents the subject.

What you will practice

Turn a brief into a bounded website purpose, content inventory, and linked page system.
Integrate semantic HTML, reusable CSS, responsive layout, visual design, and web-ready assets.
Apply basic page-level search information without making unsupported outcome claims.
Validate and test a multi-page product, repair confirmed issues, and preserve retest evidence.
Document and present the product with accurate claims, known limits, and a recovery route.
Maintain a clear project history and create the submitted archive from the verified Git commit.

Why this project matters

A complete web product is more than a rendered page. It begins with a brief, connects content through a usable structure, survives different browser conditions, records the evidence behind quality claims, and gives another person a reliable route into the work.

What is new and what is reused

New: Owning one multi-session product from a blank project folder through delivery and presentation.
Reused: Workspace setup, semantic HTML, page navigation, the cascade, custom properties, reusable classes, Flexbox or Grid, media queries, visual hierarchy, responsive raster images, SVG, alternative text, page titles and summaries, validation, test reports, README documentation, and product presentation.

Starting point

Before you start

Your completed Level 1 lessons and practice assignments as references. Do not modify those reference copies while you build the final project.
VS Code, Git, a GitHub account, a current browser, and access to the Nu Html Checker used in the quality lesson.
An image editor that can crop, resize, and export WebP.
One public-safe source image that you created or have verified permission to reuse.
A Teams assignment destination and deadline supplied by your teacher.

Current state: The course exercises contain working patterns and evidence methods. The independent final-website folder, repository, approved brief, page content, source files, tests, documentation, and presentation route do not yet exist.
First action: Create an empty folder named final-website, open it in VS Code, run git init -b main, create project-brief.md, and copy the selected brief title plus the intended visitor into that file.
First checkpoint: project-brief.md defines the bounded project, and the first commit appears in the separate private final-website repository on GitHub.
Help trigger: Open the assistance for the current checkpoint or ask for help if the brief cannot fit four pages, an asset lacks verified permission, page navigation breaks, a layout test has no reproducible condition, validation output is unclear, a quality claim lacks evidence, or the presentation cannot return to a known starting state.

Final project route

Complete one verified phase before opening the next

1
DefineBrief, visitor, purpose, content inventory, and page route
Exit evidenceApproved project brief
2
StructureFour linked semantic HTML pages with complete content
Exit evidenceUnstyled routes work
3
DesignShared CSS system, responsive layout, raster set, and SVG
Exit evidenceWide and narrow views work
4
VerifyValidation, manual tests, repairs, retests, and limits
Exit evidenceTest report is complete
5
DocumentRun instructions, structure, decisions, evidence, and credits
Exit evidenceFresh-reader route works
6
PresentProduct route, two decisions, quality boundary, and fallback
Exit evidenceTimed rehearsal passes

Each exit result preserves a working state and gives the next session one clear starting point. Return to the last passing phase when a later change breaks the site.

Requirements

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

Required delivery files

final-website contains project-brief.md, index.html, work.html, about.html, contact.html, styles.css, source-images, assets/images, assets/graphics, test-report.md, README.md, presentation-plan.md, and presentation-fallback.
The complete project is submitted as final-website.zip. The archive opens to one final-website folder instead of a loose collection of files.
Every required local asset, source note, test record, and presentation fallback is inside the submitted folder.

Version control and GitHub

final-website is a dedicated Git repository on main with its own private GitHub repository connected as origin.
The history contains the six required phase commits, plus focused repair commits when testing changes a previously recorded state.
Each commit contains only the intended saved project state. No secret, credential, unrelated file, or earlier project .git folder enters the repository.
Before archive creation, the working tree is clean and the GitHub main branch contains the latest verified commit.
final-website.zip is generated from the verified HEAD commit, so the archive excludes .git and uncommitted files.

Page content and behavior

The four page roles are Home, Work, About, and Contact. Each page has unique content that supports the selected brief.
A consistent primary navigation links all four pages with correct relative paths and identifies the current page visually and in markup.
The Home page routes the visitor to Work. Work contains at least three distinct entries and one descriptive next route. About explains the subject or organization. Contact provides a safe contact or action route.
Every page can be opened directly, all local links stay inside the project unless clearly labeled as external, and browser Back and Forward remain usable.

Semantic HTML and accessibility

Every HTML file declares HTML, sets lang="en", includes UTF-8 character encoding and the viewport setting, and uses a unique page title.
Each page uses header, nav, main, and footer for matching roles, has one h1, and follows a logical heading hierarchy.
Repeated work entries use suitable semantic grouping such as article elements and descriptive headings.
Link text identifies its destination or action. External-link behavior is stated when it differs from normal same-tab navigation.
All required routes and controls work with the keyboard, focus remains visible, and no required action depends on hover, color, or pointer input alone.
Informative images have context-appropriate alternative text. Decorative duplication uses an empty alt value.

CSS, layout, and visual system

All four pages load one shared styles.css file. The site does not copy a separate stylesheet for each page.
CSS custom properties define repeated color, spacing, type, border, and width roles. Reusable classes style repeated components.
The layout uses Flexbox or Grid for at least one real alignment or distribution task and includes at least one content-driven media query.
Visual hierarchy, proximity, alignment, repetition, contrast, and whitespace support a clear reading order.
Required content remains available without clipping, overlap, or unintended horizontal page scroll at about 320 CSS pixels and 200% browser zoom.
Text, links, controls, boundaries, and focus indicators have sufficient contrast in every state used by the site.

Images and graphics

source-images contains one unchanged raster source with verified permission and source information.
assets/images contains matching 480-pixel and 960-pixel WebP candidates derived from one intentional crop.
At least one img element uses src, srcset, sizes, width, height, and context-appropriate alternative text.
assets/graphics contains one original SVG with a viewBox, standalone title and description, at least three authored vector elements, and no script or external resource.
Raster and vector assets preserve their aspect ratios, remain useful at narrow and wide sizes, and do not delay or displace required content through missing intrinsic dimensions.

Basic search information

Each page has a unique, accurate title element and a unique meta description that summarizes that page for a potential visitor.
The visible h1, opening summary, section headings, file name, internal link labels, and image text agree with the page purpose.
The site contains no repeated keyword list, hidden search text, false claim, or promise of crawling, indexing, traffic, or ranking.

Quality evidence and documentation

test-report.md records environment, scope, test cases, expected and actual results, status, issue reproduction, repairs, retests, regression checks, final summary, and known limits.
Every HTML page has a validation result, and styles.css has a VS Code diagnostic result. Each reported message is fixed or classified with a reason.
README.md lets a new reader understand the result, open it, find important files, review at least three technical decisions, inspect test evidence and limits, and identify reused work plus licenses.
A fresh-reader test confirms that the README route reaches the expected result without spoken setup.

Presentation

presentation-plan.md defines the audience, purpose, 5–7 minute route, one complete product route, two technical decisions, test evidence, known limits, current result, and next useful change.
presentation-fallback contains current local evidence for the product route, two decision views, and selected quality evidence.
Two rehearsals record timing, readability, transitions, one deliberate recovery route, changes, and retest results.
The delivered presentation fits 5–7 minutes before questions and does not expose private or unrelated information.

Design and content freedom

Choose one supplied brief, write original public-safe content, select the visual direction, choose Flexbox or Grid where either fits, and decide where the two required asset types support the page hierarchy.
You can adapt page display labels when the four roles, file names, links, documentation, and test routes remain unambiguous.

Out of scope

The required site does not need JavaScript, a framework, package manager, build tool, backend, database, login, form submission, CMS, hosting, analytics, custom font, or public domain.
The final project does not require work from an optional extension or a claim of complete accessibility, production readiness, security, performance, or browser support.
Do not add a feature that prevents completion of the required four-page delivery.

Definition of done

The final project is complete when every applicable requirement is met, every self-check route passes in the submitted copy, the required history and latest verified commit are on the private GitHub repository, final-website.zip contains that same committed result, and the 5–7 minute presentation uses the same product state and evidence recorded in the submitted files.

Optional extensions do not change this completion line or the assessment of the required result.

Create the project folder and repository

Create final-website as a new empty folder inside your Level 1 projects folder. Do not copy an earlier project folder or its hidden .git directory. Open final-website as the workspace root in VS Code, then run:

git init -b main
git status

Expected result: Git reports branch main, no commits, and no tracked files. Keep this terminal in final-website throughout the project.

Choose one project brief

Choose one brief. You can propose another brief to your teacher when it fits the same four-page scope and technical requirements.

Brief A: Web work portfolio

Visitor: A teacher, collaborator, or placement contact reviewing current web-development work.
Purpose: Present selected work, the decisions behind it, and a safe next contact route.
Work entries: Three course or fictional projects with distinct purposes and results.

Brief B: Fictional local service

Visitor: A person comparing whether a fictional service meets a stated need.
Purpose: Explain the service, show three examples or service areas, describe the people or approach, and provide a safe next route.
Work entries: Three fictional cases or service examples. Do not present them as real clients.

Brief C: Public information guide

Visitor: A person looking for clear information about a fictional event, study resource, or community activity.
Purpose: Orient the visitor, organize three useful topics, explain who maintains the guide, and provide a safe information route.
Work entries: Three topics, sessions, or resources. You can display the page label as Topics or Program while the file remains work.html.

Phase 1: Define the project and stop planning at the brief

Create this initial structure:

Directoryfinal-website/
- Directoryassets/
  - Directorygraphics/
    …
  - Directoryimages/
    …
- Directorypresentation-fallback/
  - …
- Directorysource-images/
  - …
- about.html
- contact.html
- index.html
- project-brief.md
- README.md
- styles.css
- test-report.md
- work.html
- presentation-plan.md

Add this content to project-brief.md:

# Final website brief

## Context

- Selected brief:
- Intended visitor:
- Website purpose:
- Primary visitor route: Home → Work → Contact
- Required duration and submission destination:

## Page inventory

| File | Page role | Visitor question | Required content | Main next route |
| --- | --- | --- | --- | --- |
| index.html | Home | | | work.html |
| work.html | Work | | Three entries | contact.html |
| about.html | About | | | contact.html |
| contact.html | Contact | | Safe contact or action | index.html |

## Visual direction

- First point of attention:
- Color roles:
- Type roles:
- Repeated component:
- Raster image role:
- SVG role:

## First implementation checkpoint

All four unstyled HTML pages open directly and link to each other.

## Later

[Record ideas that are outside the active checkpoint.]

Write enough content to make the next action clear. Do not design a full page in the planning file.

Record and publish the project brief

After the plan passes its check, create the first commit:

git status
git diff
git add .
git diff --staged --stat
git commit -m "Define final website brief"

Create an empty private GitHub repository named final-website. Do not add a README, .gitignore, or license on GitHub. Copy its HTTPS URL, then connect and push the project:

git remote add origin https://github.com/YOUR-USERNAME/final-website.git
git push -u origin main

Run git remote -v and reload GitHub. Confirm that origin points to the new final-website repository and that the brief commit is visible.

Check

The plan defines one visitor, one purpose, four page roles, one primary route, required content, two asset roles, and the first implementation checkpoint. No required page depends on an optional feature.

Assistance for Phase 1

Assistance 1 — Choose the brief with the clearest content route

Complete this sentence for each candidate: “A visitor arrives to…, reviews…, and continues to…”. Choose the brief whose route fits Home, Work, About, and Contact without adding another page.

Assistance 2 — Separate product scope from Later ideas

Keep a feature in the required plan only when it directly supports one listed requirement. Put animation, live forms, filters, themes, extra pages, hosting, and JavaScript behavior in Later until the required project passes.

Checkpoint: The brief is ready for implementation

What now works: project-brief.md defines a bounded four-page product, and the brief commit is on the separate private final-website repository.
Files changed: final-website/project-brief.md
What remains: Build the complete unstyled semantic page system and verify every relative link.
Next action: Open index.html and add the required document metadata, page regions, main heading, opening summary, and four-item primary navigation.
If it does not work: If the plan requires a fifth page or untaught feature, return to the selected brief and move that item to Later before coding.

Record each completed phase with Git

Run the phase check before you commit. Use these exact messages for the required history:

Completed working state	Required commit message
Phase 1: brief and scope	`Define final website brief`
Phase 2: semantic page system	`Build semantic page system`
Phase 3: visual system and assets	`Add responsive visual system and assets`
Phase 4: validation and tests	`Record website verification`
Phase 5: README and fresh-reader test	`Document final website`
Phase 6: presentation plan and fallback	`Prepare final website presentation`

For Phases 2–6, save the complete working state and run:

git status
git diff
git add .
git diff --staged
git commit -m "PHASE MESSAGE"
git push

Replace the placeholder with the matching message from the table. Inspect every staged file before you commit. If a test repair changes a phase that you already committed, make a separate focused repair commit with a message such as Fix narrow navigation overflow, rerun the affected tests, and push the result.

Phase 2: Build the complete semantic page system

Build one page completely before copying the repeated shell. Start with index.html.

Every page needs:

the document declaration and html lang="en";
UTF-8 character encoding;
the responsive viewport setting;
a unique title;
a unique meta name="description";
the shared stylesheet link;
header, primary nav, main, and footer;
one h1 and a page-specific opening summary; and
links to all four pages.

Use this metadata pattern and replace the page-specific text:

<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta
  name="description"
  content="A specific summary of this page for a potential visitor."
>
<title>Page name | Site name</title>
<link rel="stylesheet" href="styles.css">

Mark the current navigation link with aria-current="page". Use the same link order on every page.

Complete the required page content:

Home: Purpose, opening summary, main image position, short route preview, and descriptive Work link.
Work: Opening summary, three article entries with headings and descriptions, and a next route.
About: Opening summary, subject or organization explanation, approach or current focus, and Contact link.
Contact: Opening summary, public-safe contact or action route, expected next step, and Home return link.

Check

Open each HTML file directly in the browser. Use every navigation and content link. Confirm that the browser tab title, URL file, visible h1, opening summary, and current-page marker all agree.

Assistance for Phase 2

Assistance 2 — Trace a page link that opens the wrong route

Compare the href with the target file name character by character. Check capitalization and extension. Then inspect the current-page marker on the destination; only the matching link should use aria-current="page".

Assistance 3 — Build the page system in a stable order

Complete and test the Home document shell. Copy the shell to the other three files. Change page-specific metadata, h1, opening summary, main content, and current-page marker in each copy. Test all four routes after the content is complete.

Checkpoint: The unstyled four-page route works

What now works: All four semantic HTML pages open directly, contain complete distinct content, share one navigation order, identify the current page, and follow correct relative links.
Files changed: final-website/index.html, final-website/work.html, final-website/about.html, final-website/contact.html
What remains: Build the shared visual system, responsive layout, raster candidates, and original SVG.
Next action: Open styles.css and define the shared color, spacing, type, border, and content-width custom properties.
If it does not work: Return to the last page that passed, repair one relative path or document-structure issue, and retest the same route before styling.

This is a safe stopping point. Record the first shared CSS role you will define when you resume.

Phase 3: Build the visual system and assets

Work from shared roles before page exceptions.

Define CSS custom properties for the repeated visual roles in :root.
Set readable global body, link, image, heading, and focus behavior.
Create the main content width and page spacing system.
Style the repeated header, primary navigation, content sections, work entries, and footer with reusable classes.
Use Flexbox or Grid for a real alignment or distribution task.
Add a content-driven media query where the layout needs more available width, not at a device-brand width.
Prepare the unchanged raster source as matching 480- and 960-pixel WebP candidates.
Create the original SVG and verify it directly in the browser.
Integrate both asset types with intrinsic dimensions and context-appropriate text alternatives.
Test wide, narrow, zoom, keyboard, and contrast conditions before adding page-specific polish.

Record the asset source, reuse terms, crop, dimensions, file sizes, compression, and modifications in README.md or a temporary section in project-brief.md. Move the final facts into the README during Phase 5.

Check

All four pages share one coherent visual system. The layout changes without losing required content. The browser requests a WebP candidate. The SVG stays sharp. At about 320 CSS pixels and 200% zoom, no required content clips, overlaps, or creates unintended horizontal page scroll.

Assistance for Phase 3

Assistance 1 — Choose the first shared visual roles

Start with page canvas, text, muted text, primary action, border, focus, content width, and three spacing values. Apply the roles to the body and one repeated component before adding another value.

Assistance 2 — Identify whether the current problem is asset or layout state

Open the asset file directly. If it fails there, repair the file or export. If it works directly but not on the page, inspect the relative path and HTML attributes. If it appears but overflows, inspect the containing block and flexible-image CSS.

Assistance 3 — Use one active visual checkpoint

Complete global roles, then navigation, then one work entry, then repeat the component, then responsive behavior, then assets. Run a narrow and keyboard check after each working component instead of postponing every test.

Checkpoint: The responsive visual product works

What now works: The four pages share reusable CSS, a deliberate hierarchy, responsive layout, visible focus, prepared WebP candidates, and an original SVG that work in the named wide, narrow, and zoom conditions.
Files changed: final-website/styles.css, final-website/assets/, final-website/source-images/, final-website/*.html
What remains: Validate and test the complete product, repair confirmed issues, and record retest evidence.
Next action: Create test-report.md and record the browser, operating system, wide viewport, narrow viewport, zoom condition, and test scope.
If it does not work: Restore the last passing component or viewport state, reproduce one failure, and change one likely cause before retesting that same condition.

Phase 4: Validate, test, repair, and retest

Build the test plan before you change a confirmed issue.

Include these test groups in test-report.md:

Validate each of the four HTML files.
Review styles.css in the VS Code Problems panel and classify every CSS message.
Load each page directly from a closed tab.
Check page titles, meta descriptions, one h1, and heading order.
Follow every navigation, content, contact, image, and external link.
Use browser Back and Forward.
Inspect raster requests, image dimensions, visible quality, and text alternatives.
Use every route with the keyboard and confirm current-page and focus states.
Test about 320 CSS pixels without browser zoom.
Test 200% browser zoom from the normal desktop condition.
Run a content and privacy review.
After each repair, rerun the failing test and related regression checks.

Use stable statuses: Not run, Pass, Issue, Blocked, and Accepted limitation.

Check

Every planned test has an actual result and status. Every HTML validation or CSS diagnostic message is fixed or classified with a reason. Every repaired issue has a passing retest and related regression evidence. The final summary states the tested result and known limits without implying broader coverage.

Assistance for Phase 4

Assistance 2 — Turn a broad concern into one test case

Name one condition, action, expected result, and actual result. For example: “At about 320 CSS pixels, open Work and inspect all three entries. Expected: text and links remain available without horizontal page scroll.” Decide status only after recording the actual result.

Assistance 3 — Repair one reproducible issue without losing the baseline

Record reproduction steps, save the current passing state, change one likely cause, rerun the same test, and then rerun related wide, narrow, keyboard, and link checks. Do not mark the issue closed before the evidence passes.

Checkpoint: The required quality claims have evidence

What now works: The final HTML validation, CSS diagnostic review, and manual test plan are complete, confirmed issues have repair and retest records, regression checks pass, and known limits are explicit.
Files changed: final-website/test-report.md, final-website/*.html, final-website/styles.css
What remains: Write the README and prove that a fresh reader can open and inspect the submitted project.
Next action: Open README.md and write the project title, intended visitor, purpose, and current verified result.
If it does not work: Return to the first test with an Issue, Blocked, or unsupported Pass status and resolve that evidence gap before adding polish.

Phase 5: Document the verified product

Write README.md from the current project and test evidence. Include:

overview, intended visitor, and current result;
prerequisites, open steps, and expected browser result;
a short project structure;
at least three technical decisions with product reasons and evidence locations;
verification summary linked to test-report.md;
known limitations and work outside scope;
source, creator or publisher, direct source URL, license or permission, and modifications for reused work; and
no private data, secret values, local account names, unsupported claims, or absolute local paths.

Run a fresh-reader test from a closed browser and collapsed editor folders. Follow only the README. Revise the first unstated step, incorrect result, missing path, or unsupported claim. Record the retest result.

Check

A new reader can identify the product, open all four pages, locate content, styles, assets, source material, and tests, compare three claims with evidence, and identify reuse terms without spoken setup.

Assistance for Phase 5

Assistance 2 — Narrow an unsupported project claim

Replace a broad statement such as “works on every device” with the actual tested browser, viewport, zoom, keyboard, validation, and link conditions from test-report.md.

Assistance 3 — Test the README from a fresh-reader position

Close the site, start at the README title, follow the open instructions, use the file map, inspect three evidence claims, and open every credit link. Revise the first point where you use memory instead of written information.

Checkpoint: The submitted folder explains itself

What now works: README.md gives an accurate route through the product, source, evidence, limits, and reuse terms, and the fresh-reader retest reaches the expected result.
Files changed: final-website/README.md, final-website/test-report.md
What remains: Prepare, rehearse, and deliver the evidence-based product presentation.
Next action: Open presentation-plan.md and write the audience, purpose, 5–7 minute limit, product result, and five-part presentation route.
If it does not work: If the README needs spoken context, add that information at the first relevant step and repeat only the affected reader route.

Phase 6: Prepare and deliver the presentation

Use the route from the presentation lesson:

State the product, intended visitor, and task.
Demonstrate one complete route from Home through Work to Contact.
Explain two technical decisions with readable source or interface evidence.
Report tested conditions, a specific result, any repair evidence, and known limits.
Close with the current result and one useful next change.

Store current local fallback evidence in presentation-fallback. Prepare at least:

the Home starting state;
the completed route result;
one narrow-layout state;
two readable decision excerpts; and
the selected quality evidence.

Complete one content-and-timing rehearsal and one technical-and-recovery rehearsal. Record actual timing, unclear transitions, unreadable evidence, unsupported claims, the recovery route, changes, and retest results in presentation-plan.md.

Check

The complete route lasts 5–7 minutes before questions. Essential evidence is readable. Important visual state changes are described aloud. A deliberate live-product failure can move to the local fallback without exposing private material or changing the evidence boundary.

Assistance for Phase 6

Assistance 2 — Reduce a presentation that exceeds seven minutes

Keep one product route, two decisions, one quality result, known limits, and one next change. Remove implementation history, secondary features, and detailed syntax from the timed route.

Assistance 3 — Connect each spoken claim to one prepared view

Write the claim, name the exact running state, source excerpt, or test record that supports it, and prepare that view. Narrow or remove any claim that has no matching evidence.

Checkpoint: The final delivery and presentation agree

What now works: The timed presentation uses the submitted product state, readable evidence, accurate quality boundaries, and a tested local fallback route.
Files changed: final-website/presentation-plan.md, final-website/presentation-fallback/
What remains: Run the final self-check, create final-website.zip, inspect the archive, and submit the required files to Teams.
Next action: Start the self-check from the exact copy that you will compress and submit.
If it does not work: If the presentation or archive differs from the verified product, return to the submitted folder as the source of truth and regenerate the affected evidence.

Create the submission archive from the verified commit

Complete the Phase 6 commit and push first. Then run these commands from the final-website workspace root:

git status
git log -1 --oneline
git push
git archive --format=zip --output=../final-website.zip --prefix=final-website/ HEAD

Continue only when git status reports a clean working tree and GitHub shows the same latest commit. git archive includes the tracked files from HEAD. It excludes the hidden .git directory, uncommitted changes, and unrelated files outside the repository.

If final-website.zip already exists, move the older archive to a clearly named backup location before you run git archive. Do not submit an archive when you cannot identify the commit that produced it.

Open final-website.zip. Confirm that it opens to one final-website folder and contains every required file. Run the required page, README, asset, and evidence checks from the extracted archive before submission.

Assessment evidence

The teacher evaluates the required result against these evidence groups:

Brief and content: The product fits the selected visitor, purpose, four-page scope, and primary route.
HTML and navigation: The semantic page system, metadata, headings, links, current-page state, and keyboard route work.
CSS and visual design: The shared system, responsive layout, contrast, focus, repetition, and hierarchy support the content.
Assets: The source record, responsive WebP set, original SVG, text alternatives, and browser behavior meet the stated roles.
Quality and documentation: Validation, test cases, repairs, retests, limits, README route, credits, and fresh-reader evidence are complete and accurate.
Presentation and delivery: The submitted archive is complete, and the timed presentation connects the product to readable technical and quality evidence.
Version control: The dedicated repository records the required working phases, the local and private GitHub states agree, and the submitted archive comes from the verified commit.

The Level 1 final result is completed or not completed against the required technical and professional goals. Optional extensions are not part of this decision.

Self-check

Complete these checks against the required result.

Open project-brief.md and confirm that the final product still matches the selected visitor, purpose, four page roles, primary route, content inventory, and required scope.
Extract or open the exact submission copy. Load all four pages directly and follow every navigation, content, contact, and external link with the keyboard and browser history.
Inspect every page source. Confirm required document metadata, unique titles and descriptions, semantic regions, one h1, logical headings, accurate current-page markup, and one shared stylesheet.
Test a wide viewport, about 320 CSS pixels, and 200% zoom. Confirm that required content, navigation, images, focus, and text remain available without clipping, overlap, distortion, or unintended horizontal page scroll.
Inspect the unchanged raster source, both WebP candidates, the responsive img attributes, browser image request, SVG source, direct SVG render, and context-appropriate text alternatives.
Compare every Pass in test-report.md with an actual result. Confirm that HTML validation messages, CSS diagnostics, issues, repairs, retests, regression checks, summary, and known limits are complete.
Follow README.md from a closed browser. Confirm that a reader can run, inspect, evaluate, and correctly reuse the project without private information or unsupported claims.
Deliver the planned product route with a timer. Confirm the 5–7 minute result, readable decision evidence, accurate quality boundary, described visual states, and working fallback.
Run git log --oneline and identify the six required phase commits plus any focused repair commits.
Run git status and confirm that the working tree is clean. Confirm that the private GitHub repository shows the same latest commit as the local log.
Open final-website.zip and confirm that it contains one complete final-website folder with every required file and no unrelated, private, temporary, or missing material.

Assignment-wide assistance

Use the checkpoint assistance first. Open this shared structure when the project folders or repeated page shell are the active barrier.

Assistance 4 — Review a partial project and page shell

Use the required file tree from Phase 1. Start each HTML file from this shell, then replace every bracketed field and add the required page-specific content:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="description" content="[Unique page summary]">
    <title>[Page name] | [Site name]</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <header class="site-header">
      <a class="site-name" href="index.html">[Site name]</a>
      <nav aria-label="Primary navigation">
        <ul class="nav-list">
          <li><a href="index.html">Home</a></li>
          <li><a href="work.html">Work</a></li>
          <li><a href="about.html">About</a></li>
          <li><a href="contact.html">Contact</a></li>
        </ul>
      </nav>
    </header>

    <main>
      <h1>[Unique page heading]</h1>
      <p>[Page-specific opening summary]</p>
      <!-- Add the required semantic page content here. -->
    </main>

    <footer>
      <p>[Accurate closing information]</p>
    </footer>
  </body>
</html>

Add aria-current="page" to the one navigation link that represents each file. Do not leave brackets, the instructional comment, or copied page-specific metadata in the final source.

Optional extensions

The required final project is complete when it meets every requirement, passes the self-check, and is ready for the stated submission and presentation. The routes below do not affect completion. Choose any route that provides a useful challenge.

Add a fifth detail page. Build one complete Work detail route with page-specific metadata, navigation context, responsive checks, validation, README changes, and presentation-boundary updates.
Add art direction with picture. Prepare a distinct narrow crop when the wide crop loses essential information. Document source selection, media conditions, fallback behavior, network evidence, and text alternatives.
Add a second tested theme. Create a user-controlled or system-controlled dark color scheme with role tokens, visible focus, sufficient contrast, no flash of hidden content, and complete wide, narrow, zoom, and asset tests.
Compare Grid and Flexbox for one component. Implement both approaches in separate non-submitted copies, test the same content and viewport conditions, then document which approach better communicates the component relationship and why.
Prepare a deployment readiness report. Identify the additional work for HTTPS hosting, redirects, canonical URLs, crawl controls, sitemap, server responses, privacy, security, real performance measurement, and monitoring. Do not present the local report as a production deployment.

Safe stopping point

At the end of every work session, add or update this block in project-brief.md:

## Resume here

- Last passing phase and evidence:
- What works now:
- What remains in the required path:
- Exact next action:
- Required file, browser, viewport, or tool state:
- Next test and expected result:
- Later ideas not active now:

Keep one active checkpoint. When you resume, reproduce the last passing result before you continue to the exact next action.