Final project: Build, evaluate, and present a web application

Course: Level 2 · Web Construction
Module: Quality, SEO, and analytics
Required-path effort: 18–30 hours
Submission: Teams
Assignment type: Individual final project

Estimate assumptions: This provisional estimate covers the required path across several work sessions, including brief and platform decisions, project and private repository setup, a quality plan and private GitHub Project, semantic HTML, CSS, JavaScript interaction and state, responsive page and component work, accessible motion, feedback, fifteen scripted tests, exploratory testing, repairs and regression, local and authorized public-origin SEO evidence, a controlled teacher-provided analytics test, documentation, archive creation, two presentation rehearsals, support use, debugging, and re-entry. It assumes that you completed the Module 2 lessons and practice projects. Optional extensions are not included. Optional extensions are not included.

Outcome

Build and deliver one original browser application that integrates the source-code competencies from Level 2. The product must respond to user input, render application state, adapt at page and component levels, communicate state with and without motion, and carry a complete chain of quality, technical SEO, controlled analytics, documentation, and presentation evidence.

This is a new assessed product, not another change to the practice task board. You can reuse the technical patterns and test methods you learned, but create a separate brief, folder, repository, interface, content, and evidence set.

The separate CMS capstone remains a second Level 2 artifact. In this final project, you will use that experience to explain why this product is a source-code application instead of combining two different state and recovery models.

What you will practice

Build an original application with semantic HTML, responsive CSS, browser JavaScript, events, state, and rendering.
Use responsive boundaries and accessible motion as part of the interaction contract.
Plan, execute, repair, and document quality work against identified commits.
Separate technical SEO evidence, controlled analytics evidence, and unsupported search or user claims.
Present the product, technical decisions, evidence, limits, and recovery route within an agreed time.

Why this project matters

Professional web work includes more than implementing the visible feature. A developer must define the product boundary, choose a suitable platform, preserve working states, test the actual result, explain external data transfer, and state what the evidence cannot prove. This project assesses that complete delivery chain.

What is new and what is reused

New: An original application brief, a platform decision, an independent implementation, an end-to-end delivery schedule, a feedback decision, and one final evidence presentation.
Reused: The task-board event-state-render model, page and container responsiveness, reduced-motion handling, GitHub quality planning, scripted and exploratory testing, technical SEO audit layers, and controlled analytics training workflow.
Separate evidence: The CMS capstone supports your platform comparison, but its ZIP exports, plugin state, and repository do not enter this application’s source history or submission archive.

Starting point

Before you start

Complete all Level 2 lessons, the two-stage task-board practice project, and the CMS capstone.
Use VS Code, a current browser with developer tools, Git, a private GitHub repository, GitHub Issues, and a private GitHub Project.
Ask your teacher for the delivery deadline, presentation slot, approved GA4 training property, synthetic test window, and cleanup or expiry owner before analytics configuration.
Use fictional public content and synthetic test data. Do not add credentials, personal information, real school data, or production analytics.

Current state: You have completed guided products and quality exercises, but you do not yet have an independent assessed application, delivery plan, verified evidence chain, archive, or final presentation.
First action: Create a folder named level-2-final-application and add project-brief.md, platform-decision.md, and quality-plan.md before you write product code.
First checkpoint: The approved brief, platform decision, private repository, delivery schedule, six quality issues, and first implementation checkpoint identify one bounded product and one next action.
Help trigger: Use the checkpoint assistance or ask for help when the product cannot fit the required record-and-state model, the selected platform decision conflicts with the assignment, the first implementation checkpoint remains larger than one working behavior, or an external SEO or analytics requirement lacks owner approval.

Requirements

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

Product and interaction

Choose one brief below and define one intended user, one product outcome, one primary interaction, and one stable record shape before implementation.
A labeled form validates at least one free-text field and one bounded-choice field. Invalid input changes no application state and provides a specific error and useful focus result.
One JavaScript state object owns a collection of records. A valid submission creates one record with a unique session ID, safe text, a bounded category, and an initial Boolean state.
The complete record collection and one derived summary render from state. HTML-looking input must remain text.
Each record has one native control that changes its Boolean state through event → state update → render and preserves useful keyboard focus.
A polite status output identifies successful creation and state changes without moving focus.
A fresh reload returns the documented initial state. Persistence is not required.

Responsive design and motion

The complete narrow-first application works at 320 CSS pixels and 200% browser zoom without horizontal page scrolling or lost content.
One content-based viewport media query creates a wider page composition without changing logical source or focus order.
One repeated record component adapts through an inline-size container query and can show its narrow layout inside a wide viewport.
Long titles, categories, labels, status text, and controls wrap without clipping, overlap, or fixed-height loss.
One short control transition and one finite user-triggered record-state animation reinforce existing static states.
prefers-reduced-motion: reduce removes the project motion without changing content, state, function, status, focus, or timing of the result.

Semantic HTML and accessibility

Use semantic landmarks, one descriptive main heading, logical heading levels, persistent form labels, native controls, lists for record collections, and real anchors for navigation.
Every required interaction works with the keyboard and has a visible focus indicator in narrow, wide, standard-motion, and reduced-motion conditions.
Validation messages, instructions, and status changes have programmatic relationships that match their visual relationships.
State and meaning do not depend only on color, position, hover, or motion.
Initial HTML contains the product name, purpose, core controls, and useful explanation before JavaScript renders record state.

Technical implementation

Use separate index.html, styles.css, and app.js files with defer and strict mode. Use browser-native HTML, CSS, and JavaScript for the required path.
Use specific element, state, handler, and render names. Keep stable DOM selection and listener registration outside the render function.
Insert free-form user input through textContent or an equivalent safe text API, never innerHTML.
Keep application behavior independent of analytics availability. No core state, validation, rendering, or focus decision can depend on the Google tag.
Do not use a framework, CSS framework, component library, package dependency, generated application code, backend, database, API, or build tool for the required path.
Use one dedicated Git repository and private GitHub remote. Record focused planning, implementation, repair, evidence, and delivery commits.

Quality management and testing

quality-plan.md defines the product, environment, quality-ready target, protected review window, hard deadline, first checkpoint, help trigger, done signal, and resume state.
One private GitHub Project tracks six testable quality issues for baseline, interaction, accessibility and layout, source and Console, technical SEO, and final regression.
interactive-test-report.md defines one reset route and at least fifteen scripted cases with preconditions, actions, expected results, actual results, evidence, and final status.
Run one bounded exploratory charter after the scripted paths. Confirmed defects receive focused issues, repair commits, retests, and affected regression tests.
One feedback record states an observed result, consequence, proposed change, decision, and verification. Do not record personal information about the reviewer.
The final regression runs against one identified full commit after SEO and analytics changes. The private board has no unresolved required item.

Technical SEO

technical-seo-report.md separates local source, rendered DOM, authorized public-origin HTTP, and search-property evidence.
The local audit covers HEAD-01, META-01, HTML-01, LINK-01, ROBOT-01, CANON-01, RENDER-01, and REG-01 with actual evidence.
The saved document has one accurate title, one useful description, valid head content, useful initial meaning, descriptive crawlable links, and no unintended noindex or nofollow instruction.
Do not add a canonical element until one approved preferred public origin exists. Do not use a localhost, preview, placeholder, or invented URL.
The public-origin audit covers PUBLIC-01, HTTP-01, HTTP-02, REDIR-01, CANON-02, ROBOTS-01, MAP-01, and INDEX-01 when authorization and a real origin exist.
When no approved origin or search property exists, mark affected live-only rows Blocked with the missing owner or decision. Do not fabricate a passing deployment or index result.
The report explains what the evidence makes discoverable and what it does not prove about crawling, indexing, display, traffic, or ranking.

Controlled analytics

analytics-measurement-plan.md defines one implementation question, one custom record-created event, its exact successful trigger, allowed bounded parameters, excluded data, expected evidence, owner, test window, and cleanup or expiry route.
Use only the teacher-provided GA4 training property and web data stream. Do not create a personal property or connect a production school property.
Normal use must not create dataLayer, load the Google tag, or send an analytics request.
Test mode requires localhost or 127.0.0.1, analytics_test=1, and the exact approved non-placeholder G- Measurement ID. Enhanced measurement remains disabled for the controlled exercise.
The custom event runs once only after successful validation and one confirmed state mutation. Invalid input, normal mode, reload, and unrelated controls send no custom event.
Do not send record title text, IDs, names, email addresses, page-query values, school details, or other free-form or personal data. Use only a bounded input-length band and a fixed test-context value.
ANA-01 through ANA-04 and EVT-01 through EVT-08 contain source, Network, application, and approved DebugView evidence or an honest teacher-reviewed Blocked result.
Production analytics is not approved or configured by this assignment.

Documentation, presentation, and submission

project-brief.md, platform-decision.md, quality-plan.md, interactive-test-report.md, technical-seo-report.md, analytics-measurement-plan.md, feedback-log.md, and README.md agree with the final source commit.
platform-decision.md compares this source-code application with the completed CMS capstone and explains the selected ownership, interaction, extension, testing, recovery, and data boundaries.
README.md provides the product route, file ownership, event-state-render model, responsive boundaries, motion contract, launch instructions, tests, analytics guard, evidence links, limits, and final commit.
A seven-to-ten-minute presentation demonstrates the user path, one JavaScript decision, one responsive boundary, the reduced-motion result, one repair, SEO and analytics evidence boundaries, and the final verified state.
The final ZIP archive comes from the verified Git commit and contains tracked project and evidence files without .git metadata, credentials, personal data, generated analytics data, or unrelated work.

Design freedom

Choose the brief, product name, fictional content, bounded categories, visual direction, design tokens, page composition, component arrangement, breakpoint values, and finite motion treatment.
Choose the exact function and selector names when they remain specific and consistent.
Choose which confirmed feedback change to accept or reject, provided the decision and verification are evidence-based.

Out of scope

Public deployment, a custom domain, live search-property changes, sitemap submission, indexing requests, production analytics, real visitor collection, and legal consent design are not required.
User accounts, public forms, persistence, drag and drop, multi-user data, real deadlines or people inside application records, CMS integration, and external APIs are not required.
Optional extensions do not improve the required completion status or replace a failed core criterion.

Definition of done

The final project is complete when the required product and evidence apply to one final commit, every locally controlled criterion passes, every external row either passes with approved evidence or has a teacher-reviewed Blocked result, the final archive reproduces the tracked commit, the private board has no unresolved required work, two timed rehearsals pass, and the submitted archive and presentation identify the same verified state.

Choose one final application brief

Each brief uses the same technical depth and synthetic-data boundary. Choose the product whose labels and record states you can explain most clearly.

Brief A: Resource review queue

Build an application for a fictional team that records public learning resources and marks whether each resource has been reviewed. Suggested bounded categories: Article, Video, Documentation, and Tool. Do not add real URLs, author names, account data, or learner information.

Brief B: Event session planner

Build an application for a fictional event team that records proposed sessions and marks whether each session is confirmed. Suggested bounded categories: Talk, Workshop, Discussion, and Break. Do not add real speakers, attendees, contact details, or dates tied to a real event.

Brief C: Content review board

Build an application for a fictional web team that records content items and marks whether each item is approved. Suggested bounded categories: Page, Image, Navigation, and Metadata. Do not add real clients, staff, unpublished business content, or credentials.

All briefs use one required record model:

const record = {
  id: 1,
  title: "Review the public introduction",
  category: "Page",
  completed: false,
};

Rename record, title, or completed when the brief needs a more precise stable term. Preserve the four roles: session identity, free-form display text, bounded category, and Boolean workflow state.

Project route

Complete one verified phase before opening the next:

Phase	Work	Exit result
1. Define	Brief, platform, delivery, repository, issues, and first checkpoint	Approved contract and one active implementation issue
2. Interact	Semantic shell, validation, state, rendering, status, and focus	Complete keyboard-operable core product
3. Adapt	Narrow-first page, responsive component, static states, motion, and reduced motion	Responsive and motion regression passes
4. Evaluate	Feedback, scripted and exploratory tests, repairs, SEO, analytics, and final regression	Board and reports identify one final commit
5. Deliver	README, archive, presentation route, fallback, and rehearsals	Submitted archive and timed evidence presentation

At each exit result, record what works, what remains, the exact next action, and the last passing commit. Do not use planning to postpone the first implementation checkpoint.

Phase 1: Define the product and delivery contract

Create this initial structure:

level-2-final-application/
├── index.html
├── styles.css
├── app.js
├── README.md
├── project-brief.md
├── platform-decision.md
├── quality-plan.md
├── interactive-test-report.md
├── technical-seo-report.md
├── analytics-measurement-plan.md
└── feedback-log.md

Initialize the repository and create a private GitHub repository with the same name. Connect and push one initial commit containing the empty source files and approved planning headings.

Write the brief

In project-brief.md, define:

selected brief, product name, intended user, and user outcome;
the primary create-record path and workflow-state change;
labels, categories, static initial meaning, and documented reset state;
record shape and derived summary;
required narrow, wide, component-host, standard-motion, and reduced-motion results;
fictional-data rule and excluded features;
first implementation checkpoint and done signal;
Later list for ideas outside the required result.

Stop product planning when these items are clear. Move new feature ideas to Later and begin the first working behavior.

Explain the platform decision

In platform-decision.md, compare the final brief with the completed CMS capstone:

Decision area	Source-code application	CMS site	Project consequence
Client interaction and state
Content-editor ownership
Theme and extension ownership
Testing and debug evidence
Recovery and delivery
External data boundary

Conclude why browser HTML, CSS, and JavaScript fit this assessed interaction and analytics-source contract. Do not claim that one platform is universally better.

Create the quality plan and board

Write the quality-ready target, protected review window, and teacher-provided hard deadline in quality-plan.md. Include setup, support, debugging, repair, regression, archive, and rehearsal time.

Create one private GitHub Project and six repository issues:

establish and record the baseline;
test core interaction and state;
test keyboard, focus, responsive layout, zoom, and motion preferences;
inspect saved source, DOM, requests, and Console;
complete technical SEO and controlled analytics evidence;
run final regression and review every delivery artifact.

Give each issue a test condition, expected result, evidence, close condition, blocked route, target date, and quality area. Keep exactly one implementation or quality checkpoint active.

Check

Confirm the product fits the required record model, the private repository contains only fictional planning data, the board contains six testable issues, the schedule protects final review, and one first checkpoint is active.

Assistance for Phase 1

Assistance 1 — Choose the brief with the clearest record and state

For each brief, say one record aloud: title, category, and open or completed state. Choose the route whose labels remain specific without adding dates, accounts, APIs, or real people.

Assistance 2 — Reduce a brief that exceeds the contract

Keep one create path, one Boolean state change, one summary, one page-level breakpoint, one component threshold, and one finite motion effect. Move editing, removal, filters, persistence, APIs, and deployment to Later unless the required core already passes.

Assistance 3 — Build the first project state in order

Approve the brief; write the platform consequence; set the quality-ready target, review window, and hard deadline; create six issues; create and push the repository; activate only the semantic-shell issue; open index.html.

Checkpoint: The final product has one delivery contract

What now works: The brief, platform decision, schedule, private repository, six quality issues, and first checkpoint define one bounded application and one evidence chain.
Files changed: project-brief.md, platform-decision.md, quality-plan.md, initial source and evidence files
What remains: Build the semantic shell and complete event-state-render behavior.
Next action: Open index.html and create the main heading, product explanation, labeled form, summary, record-list region, and status output in source order.
If it does not work: If implementation requires an excluded service or data field, return to the brief and reduce the product before adding code.

Record each verified phase with Git

Use focused commits that preserve the recovery route. Suitable outcomes include:

Define final application delivery contract
Build accessible record creation flow
Render workflow state and summary
Add responsive record components
Add reduced-motion state feedback
Repair keyboard focus after rendering
Document technical SEO evidence
Configure controlled analytics event
Complete final application delivery

Inspect source and evidence diffs before each commit. Push passing checkpoints. Do not combine a product repair with unrelated report cleanup when separate commits would make the retest evidence clearer.

Phase 2: Build the complete interaction

Build the application through functional checkpoints:

The valid HTML shell loads the external CSS and deferred strict-mode JavaScript without an error.
The form prevents reload, rejects empty and whitespace-only text, reports one error, and focuses the free-text field.
A valid submit creates one record in state and renders the complete collection as safe text.
The derived summary remains accurate for zero, one, and several records.
Each native workflow-state control updates the matching object before rendering and restores focus to the changed control.
The polite status output names a created or changed record without becoming the source of persistent state.
A fresh reload returns the documented initial state.

Use at least three synthetic stress records during development: a short title, a multi-line title, and one uninterrupted string. Keep these test values out of the production initial state unless the brief needs fictional examples.

Check

Run this core matrix before responsive work:

ID	Path	Required result
CORE-01	Fresh reload	Documented initial state, accurate summary, no Console error
CORE-02	Empty submit	Specific error, invalid state, focused field, no record
CORE-03	Spaces-only submit	Same invalid result after trimming
CORE-04	Valid submit with Enter	One state record, one rendered record, status, reset, focused field
CORE-05	HTML-looking title	Exact literal text; no created markup
CORE-06	Add several records	Complete state renders; IDs and summary remain accurate
CORE-07	Change second record with Space	Matching object and static state update; focus returns to its control
CORE-08	Reopen the record	Boolean state, decoration, summary, status, and focus return correctly

Update README.md with the current file roles and event-state-render explanation. Commit and push the passing core before layout work.

Assistance for Phase 2

Assistance 1 — Trace one path through the product model

For one valid submit, point to the event, trimmed values, new object, state update, render call, created DOM text, summary, status, reset, and focus result. The first missing link identifies the active checkpoint.

Assistance 2 — Separate persistent state from interface output

The state object owns records. The renderer derives list items and the summary. The live status describes the latest event. Do not read persistent record truth back from rendered text or the status output.

Assistance 3 — Build the interaction without opening later phases

Complete validation first. Then create and store one record. Then render the complete collection and summary. Then add the Boolean state change and focus restoration. Keep responsive CSS, motion, SEO, and analytics inactive until CORE-01 through CORE-08 pass.

Checkpoint: The independent application works

What now works: The complete create and workflow-state paths pass with safe text, accurate state and summary, visible status, keyboard operation, and focus restoration.
Files changed: index.html, styles.css, app.js, README.md
What remains: Adapt the page and record components, then add finite preference-aware motion without changing the interaction contract.
Next action: Open styles.css and make the complete 320 CSS-pixel layout work before writing a media or container query.
If it does not work: If later rendering fails, restore the last passing core commit and retest the first failed CORE row before changing architecture.

Phase 3: Build responsive components and motion-safe feedback

Create these layers in order:

design tokens and complete narrow fallback;
readable type, wrapping, flexible widths, and visible control states;
one viewport media query for page composition;
one inline-size query container and one @container rule for record internals;
static open and completed states;
one short control transition and one finite changed-record keyframe effect;
one reduced-motion override that removes project motion.

Test the record component in a narrow host inside a wide viewport. If it changes only when the viewport crosses a value, the component rule does not yet prove container independence.

Keep motion local, short, user-triggered, finite, and non-flashing. The state update, summary, status, and focus result must complete without waiting for the animation.

Check

Add these cases to the scripted report draft:

ID	Condition	Required result
LAYOUT-01	320 CSS pixels	Complete narrow fallback; no horizontal page scrolling
LAYOUT-02	Below and above page breakpoint	Deliberate composition change; stable source and focus order
LAYOUT-03	Narrow record host in wide viewport	Record keeps narrow component layout
LAYOUT-04	Wide record host	Record uses wider component arrangement
LAYOUT-05	Long and uninterrupted content	Wrapping works; control and content remain available
LAYOUT-06	200% browser zoom	Application reflows without lost content or focus
MOTION-01	Standard preference, state change	Static result updates immediately; local effect runs once
MOTION-02	Reduced-motion preference, same change	Identical content, state, summary, status, and focus; no project motion

Repeat CORE-01, CORE-04, CORE-07, and CORE-08 after the CSS and changed-record JavaScript adjustment.

Assistance for Phase 3

Assistance 2 — Distinguish the two responsive boundaries

The media query decides whether page regions can form a wider composition. The container query decides whether one repeated record has space for a wider internal arrangement. Record the viewport and container widths separately.

Assistance 3 — Add motion after proving the static state

Disable animation and verify the checkbox, state text or decoration, summary, status, and focus. Expose only the changed record. Add one finite keyframe. Emulate reduced motion and remove both transition and keyframe effects while rerunning the same interaction.

Checkpoint: The product adapts with and without motion

What now works: The page and record component respond to their correct boundaries, long content and zoom reflow, and standard and reduced-motion modes provide the same interaction result.
Files changed: index.html, styles.css, app.js, README.md, interactive-test-report.md
What remains: Collect feedback, execute the quality plan, repair confirmed defects, and complete SEO and analytics evidence.
Next action: Open feedback-log.md and ask one peer or teacher to perform the primary keyboard path without coaching.
If it does not work: If the interaction regresses, return to the first failing CORE row before adjusting another breakpoint or effect.

Phase 4: Evaluate the identified product

Record and decide on one feedback item

Ask a peer or teacher to perform the primary path with the keyboard. Record no personal information. In feedback-log.md, write:

observed result;
evidence and environment;
consequence for the user or product;
proposed smallest change;
Accept, Reject, or Need more evidence decision;
reason;
verification or next test.

If accepted, use a focused issue, commit, and retest. A rejected suggestion still needs a product or technical reason.

Execute at least fifteen scripted cases

Create one reset procedure and cover these areas in interactive-test-report.md:

CORE-01 through CORE-08;
LAYOUT-01 through LAYOUT-06;
MOTION-01 and MOTION-02;
saved-source and Console inspection;
at least one path that crosses validation, state, render, focus, and status behavior.

This list exceeds fifteen possible cases. Keep at least fifteen that cover every required area. Each case needs the tested full commit, environment, precondition, action, expected result, actual result, evidence, and status.

After scripted execution, run one bounded exploratory charter for event, state, render, and layout consistency. Limit the charter by named scope and time. Record observations without replacing the scripted results.

Create a focused defect issue only when evidence confirms an unexpected result. Repair one cause, commit it, rerun the failed case and connected paths, then run the full final set later.

Complete the technical SEO evidence

Start technical-seo-report.md by stating whether an authorized public HTTPS origin exists. Run the eight local audit IDs before changing source. Repair specific failures, then rerun the interaction and layout paths affected by the change.

Keep useful product meaning in saved HTML. The rendered list can depend on JavaScript, but the product name, purpose, controls, instructions, and navigation must not disappear when JavaScript is unavailable.

If no approved public origin exists, mark the eight live-only rows Blocked and state the missing origin or owner. Do not add canonical, robots, sitemap, redirect, HTTP, or index evidence for an invented location.

If an approved origin exists, gather real response and file evidence. Do not submit a sitemap, request indexing, change a search property, or alter deployment without owner authorization.

Configure one controlled analytics event

Use the teacher-provided training property only. In analytics-measurement-plan.md, define a custom event such as record_created and state its precise successful trigger. Use only:

input_length_band: one bounded value such as short, medium, or long;
test_context: one fixed value such as level_2_capstone.

The free-form record title and session ID must not reach analytics.

Keep the normal application analytics-free. Reuse the three-gate lesson pattern: local host, analytics_test=1, and approved Measurement ID. Configure the controlled stream with send_page_view: false, debug mode for the test, Google Signals disabled, and ad-personalization signals disabled. Enhanced measurement stays disabled in the teacher’s training stream for this exercise.

Attach the custom event after the confirmed record mutation. Do not attach it to the button click or let it participate in validation, state, rendering, or focus.

Execute ANA-01 through ANA-04 and EVT-01 through EVT-08 with synthetic input. Verify source, application result, Network request, and the correct approved DebugView. Then return to the normal URL and prove the tag and requests are absent.

If the teacher-provided property is unavailable or blocked, preserve the plan and source boundary, mark the external rows Blocked, name the owner, and follow the agreed alternative assessment route. Do not send a test to another property.

Run one final regression

Use the normal URL without analytics_test=1. Reset the application and rerun:

the final selected fifteen scripted cases;
the exploratory charter’s affected path;
every focused defect retest;
all eight local SEO rows;
applicable live SEO rows or their confirmed Blocked state;
ANA-01 normal-mode absence;
standard and reduced-motion paths;
Console and Network checks.

Update every report and close the board only when they name the final commit and current actual results. Do not carry forward a pass from an earlier commit without executing the condition again.

Check

Confirm the board has no unresolved required issue, the reports agree on one final full commit, normal mode makes no analytics request, free-form input never enters analytics evidence, and unsupported search or user claims are absent.

Assistance for Phase 4

Assistance 1 — Identify the active evidence layer

Name the current question: source code, rendered DOM, interaction state, viewport, container, motion preference, local Network request, public HTTP response, search property, or analytics DebugView. Use evidence from that layer and do not substitute a screenshot from another layer.

Assistance 2 — Turn an unexpected result into one reproducible defect

Record environment, tested commit, reset state, exact actions, expected result, actual result, and first conflicting evidence. Create one issue and one initial hypothesis. Do not repair before the result can be repeated.

Assistance 3 — Close quality work in dependency order

Finish core and accessibility cases; repair and retest confirmed defects; finish local SEO; record authorized live or Blocked SEO; verify analytics gates; verify the synthetic event; return to normal mode; run the complete regression; reconcile reports and board.

Checkpoint: One final commit has a complete evidence chain

What now works: Feedback, scripted and exploratory tests, repairs, responsive and motion paths, local and authorized external SEO, controlled analytics, and normal-mode regression agree on one final commit.
Files changed: source files, quality-plan.md, interactive-test-report.md, technical-seo-report.md, analytics-measurement-plan.md, feedback-log.md
What remains: Complete the README, create the archive from the verified commit, rehearse, submit, and present.
Next action: Open README.md and test its launch and verification route from the position of a reader who has only the tracked project files.
If it does not work: If two reports name different source states, stop delivery work, identify the later code change, and rerun affected evidence against one candidate commit.

Phase 5: Deliver the verified product

Complete the README

Write a compact reader route:

product, brief, user, and outcome;
file and evidence inventory;
how to run the normal local application;
core interaction and state model;
page and container responsive boundaries;
static state, motion, and reduced-motion behavior;
reset and test route;
local and public SEO evidence boundary;
analytics normal-mode guard and approved synthetic test boundary;
feedback and repair summary;
final verified commit, known limits, and recovery route.

Test the instructions from a new browser tab and a clean working tree. Do not include a real Measurement ID in a public presentation slide or screenshot. The private source can use the teacher-provided training ID under the stated boundary.

Create the archive from the verified commit

From the repository root, confirm the final state:

git status
git log -1 --oneline
git ls-files

Inspect the tracked list for credentials, personal data, generated analytics exports, unrelated files, and accidental archives. Repair the repository and rerun affected checks if the tracked state is wrong.

Create the archive outside the repository from HEAD:

git archive --format=zip --output=../level-2-final-application.zip HEAD

Open the ZIP. Confirm it contains the source and required evidence, does not contain .git, and matches the final commit. Do not edit files inside the archive. Create a new verified commit and archive if a source change is necessary.

Prepare the seven-to-ten-minute presentation

Use this route:

Product: user, outcome, and platform decision.
Interaction: one valid path and one invalid path.
JavaScript: one event → state update → render decision.
Responsive design: one page boundary and one independent component boundary.
Motion: standard and reduced-motion results for the same state change.
Quality: one confirmed problem, repair, and retest or one evidence-based feedback decision.
SEO: one local signal, public-origin status, and one claim the evidence cannot support.
Analytics: measurement question, successful trigger, excluded data, normal-mode absence, and approved synthetic evidence or Blocked boundary.
Delivery: final commit, archive, known limit, and next technical step.

Prepare a fallback route with a local copy, final archive, screenshots of external evidence that contain no personal data, and the report rows. External dashboards can be unavailable during the presentation.

Run two timed rehearsals. After the first, remove content that does not support the route. After the second, confirm the presentation fits the time and the fallback can replace every external view.

Check

Confirm the archive matches the verified commit, the presentation uses the same product and evidence, the normal app remains analytics-free, the fallback has no sensitive data, and the second rehearsal fits seven to ten minutes.

Assistance for Phase 5

Assistance 2 — Reduce a presentation that exceeds ten minutes

Keep one product path, one JavaScript decision, one responsive boundary pair, one motion comparison, one repair or feedback decision, one SEO boundary, one analytics boundary, and one verified delivery state. Move detailed matrices to questions.

Assistance 3 — Build a presentation that survives external failure

Rehearse from local source first. For each external view, prepare one named report row or privacy-safe screenshot. Practice switching to the fallback without changing the claim or extending the presentation.

Checkpoint: The verified application is ready for assessment

What now works: The tracked commit, opened archive, complete evidence, normal application, fallback route, and timed presentation describe the same bounded product and results.
Files changed: README.md, level-2-final-application.zip outside the repository, final source and evidence files
What remains: Submit the archive through Teams and deliver the presentation at the agreed time.
Next action: Upload level-2-final-application.zip to the stated Teams destination and verify that the uploaded filename and size match the local archive.
If it does not work: If the archive or upload differs from HEAD, do not patch the ZIP; correct the repository, repeat affected checks, create a new archive, and upload the verified file.

Self-check

Complete these checks against the required result.

The final brief names one user, outcome, primary interaction, record model, required states, data boundary, and stable finish line.
platform-decision.md compares source-code and CMS ownership without mixing repositories, exports, or unsupported claims.
The private repository and board preserve focused planning, implementation, repair, evidence, and delivery history.
Empty, whitespace-only, valid, HTML-looking, multiple-record, completion, reopening, summary, status, reset, and focus paths pass.
Free-form input enters the DOM as text and never enters HTML markup, analytics parameters, URLs, or report screenshots.
The complete narrow fallback, page media query, record container query, long-content path, and 200% zoom result pass.
The standard-motion effect is local, finite, and user-triggered; reduced-motion mode preserves the same immediate static result without project motion.
At least fifteen scripted cases, one exploratory charter, feedback evidence, confirmed repair retests, and final regression identify one full commit.
The six required GitHub issues and private board contain no unresolved required work and agree with quality-plan.md.
All eight local technical SEO IDs contain actual evidence and affected interaction paths pass after repairs.
All eight live SEO IDs contain authorized real-origin evidence or an honest Blocked result with the missing owner or decision.
The analytics plan identifies the teacher-owned training boundary, one measurement question, one event, exact trigger, two bounded parameters, exclusions, and cleanup owner.
ANA-01 through ANA-04 and EVT-01 through EVT-08 contain current evidence or a teacher-reviewed Blocked result; normal mode contains no tag or analytics request.
The reports explain what observed counts and search signals can and cannot establish without claiming users, intent, ranking, or production readiness.
README.md can guide a fresh reader through launch, architecture, accessibility, tests, SEO, analytics guard, limits, and recovery.
The final archive was created from the verified HEAD, opens successfully, contains all tracked required files, and contains no .git metadata, secret, personal data, or unrelated work.
The second presentation rehearsal fits seven to ten minutes and the fallback supports every external evidence claim.
The final commit exists on the private remote, git status is clean, and the Teams upload matches the local archive.

Assessment evidence

Area	Evidence
Product and platform judgment	Bounded brief, source-code and CMS comparison, stable state model, meaningful exclusions, and complete user path
JavaScript interaction	Validation, events, state ownership, safe rendering, derived output, status, reset, and focus behavior
Responsive design and animation	Narrow fallback, page and component boundaries, long content, zoom, static states, finite motion, and reduced-motion equivalence
Accessibility	Semantic structure, labels, errors, keyboard operation, visible focus, status relationships, reflow, and non-color state cues
Quality practice	Delivery plan, private board, scripted and exploratory tests, feedback, defects, repairs, retests, regression, and one identified commit
Technical SEO	Valid source, initial meaning, rendered comparison, crawlable links, canonical discipline, real or Blocked live evidence, and bounded claims
Analytics	Question-first plan, approved training ownership, guarded configuration, exact event trigger, data minimization, layered verification, normal-mode absence, and honest limits
Delivery and communication	Git history, README, archive integrity, evidence consistency, known limits, fallback, and timed presentation

The assessment uses the required result. Optional extensions do not raise an incomplete required result to complete and do not lower the value of a complete core project.

Assignment-wide assistance

The final project keeps requirements and test contracts visible but does not provide a complete product solution. The original implementation and technical decisions are part of the assessed work. Checkpoint assistance, lesson references, teacher support, and the partial structure below remain available.

Assistance 4 — Review a partial final-project implementation map

Use this map when several files are open and the next responsibility is unclear:

index.html
  Product identity, initial meaning, semantic regions, labels, controls, links

styles.css
  Tokens, narrow fallback, page media query, record container query,
  static states, finite motion, reduced-motion override

app.js
  DOM contract, state, validation, record creation, state change,
  rendering, focus restoration, status, analytics gates and event call

project-brief.md
  User, outcome, record model, scope, first checkpoint, done signal

platform-decision.md
  Source-code and CMS comparison with project consequence

quality-plan.md and private GitHub Project
  Deadline, risks, active work, blockers, resume state, close condition

interactive-test-report.md
  Reset, scripted cases, exploratory charter, defects, retests, regression

technical-seo-report.md
  Local source and render evidence, live-origin decision, bounded claims

analytics-measurement-plan.md
  Owner, question, event, parameters, exclusions, gates, evidence, limits

feedback-log.md
  Observation, consequence, decision, change, verification

README.md
  Reader route through the verified product and evidence

Choose the file that owns the active checkpoint. Complete one observable behavior or evidence row before switching responsibilities.

Optional final-project extensions

Complete, commit, archive, and rehearse the required project before starting an extension. Create a new branch or post-assessment copy when the extension can destabilize the verified delivery.

Add a filter as application state

Add All, Open, and Complete controls. Store the selected filter in state, derive visible records without changing the complete summary, expose the current filter visually and programmatically, preserve focus after rendering, and add scripted and reduced-motion tests.

Add deliberate record removal

Add a labeled Remove action with a documented focus route for the first, middle, last, and only record. Update state before rendering, report the removed record as safe text, and add regression cases for summary and empty-state return.

Persist synthetic state

Research localStorage and JSON parsing. Define missing, invalid, and older data behavior, provide a visible clear-saved-data control, keep personal information excluded, and test storage disabled or corrupted without losing core interaction.

Add a second-browser evidence set

Repeat the final interaction, responsive, motion, source, and Network matrix in one second current browser. Keep results separate and investigate only the paths that differ.

Prepare a production analytics decision record

Do not deploy or collect data. Write an owner-review document for purpose, legal basis where applicable, consent behavior, notices, allowed fields, access, retention, deletion, vendor settings, testing, incident response, and approval. State which facts remain unresolved.

Optional official references

Google Search technical requirements defines baseline technical eligibility for Google Search.
Google JavaScript SEO basics explains source, rendering, links, and JavaScript-dependent content considerations.
Google canonical URL guidance explains canonical signals and preferred URL selection.
Set up Analytics for a website explains GA4 properties, web data streams, Measurement IDs, and tags.
Set up GA4 events explains custom event commands, names, parameters, and report evidence.
Avoid sending personally identifiable information states the Google Analytics PII data restriction.

Safe stopping point and re-entry

Stop after a passing functional or evidence checkpoint. Commit and push when the state is reviewable. Update the resume section in quality-plan.md before a longer interruption:

## Resume here

- Current phase:
- What works:
- Last passing full commit:
- Active GitHub issue:
- First failing or unfinished test ID:
- External evidence status or owner:
- Exact next action:
- File, function, selector, report row, or dashboard view to open:
- Required browser, preference, or URL mode:

When you return, restore this state and perform the exact next action. Do not reopen optional work while a required issue remains active.