Final project: Deliver and present cross-platform web software

Course: Level 3.1 · Web Development
Module: Cross-platform development
Required-path effort: 12–16 hours across two practical days
Submission: Teams plus individual presentation rehearsal
Assignment type: Pair delivery; individual assessment rehearsal

Estimate assumptions: This provisional estimate assumes that accepted Stage 3 is on remote main, both cross-platform lessons are complete on a clean feature/cross-platform branch, required Android tooling works, and a teammate or teacher can review before the protected individual rehearsal. It includes contract mapping, one independent runtime-information feature, automated tests, complete web and Android regression, one controlled sensitivity proof, documentation, review, integration, fresh-clone and fresh-sync recovery, a handoff archive, two timed oral rehearsals, support use, debugging, and re-entry. The teacher controls the official assessment schedule, permitted support, brief, delivery rules, oral format, and deadline. Optional extensions are not included. Optional extensions are not included.

Outcome

You will complete, review, integrate, recover, and present Stage 4 of Delivery Board. The final repository will contain one TypeScript product with two verified runtime results:

a browser client connected to the validated local Express API; and
an installed Android application with a visible fictional, memory-only demonstration mode.

You will add one independent feature that explains the current platform and data boundary inside the product. You will then verify the complete work from TypeScript and React through Express, HTTP, Vite, Sass, Vitest, Capacitor, Android, Git, documentation, and presentation evidence.

This is a capstone project and assessment rehearsal. The Module 3.1 curriculum uses a two-day practical software task and a 30-minute oral examination, including grading time. Your teacher’s official task, timing, support rules, and submission instructions take precedence over this practice route.

What you will practice

Complete one typed application across React, Express, browser, and Android contexts without hiding different runtime boundaries.
Apply a front-end framework, develop and test an API, consume that API, and implement a design for more than one platform.
Use TypeScript, Sass, Vite, automated tests, Git, review, and documentation as one recoverable development workflow.
Research one small current platform API, constrain its responsibility, and explain the result to a user.
Distinguish automated, direct HTTP, browser, copied-build, native-build, installed-runtime, and presentation evidence.
Give and receive constructive feedback without inventing defects or weakening an accepted contract.
Plan and deliver a bounded result within a two-day deadline while keeping a useful resume state.
Present technical decisions, evidence, limitations, recovery, and personal learning in a clear oral route.

What is new and what is reused

New: Stage 4 contract map, RuntimeInfo boundary, visible platform-and-data explanation, focused unit and component tests, one controlled sensitivity proof, complete Level 3.1 evidence index, final cross-platform review, accepted integration, fresh-clone and fresh-Android-sync recovery, handoff archive, timed presentation route, and individual reflection.
Reused: The private Delivery Board repository, accepted Stage 3 main, feature/cross-platform, cross-platform design and Capacitor lesson commits, React components and routes, WorkItemsApi, Express API, runtime validation, API and demo modes, Sass, safe areas, semantic controls, Vitest, Testing Library, Supertest, Android project, Gradle wrapper, browser and native matrices, README, pull-request workflow, focused commits, and fictional-data boundary.

Starting point

Before you start

Accepted Stage 3 exists on synchronized remote main in the existing private Delivery Board repository.
The cross-platform design and Capacitor packaging lessons exist as separate passing commits on feature/cross-platform.
Normal web mode uses the Express API. Android mode uses a copied fictional in-memory adapter and shows its reset boundary.
Tests, typecheck, lint, normal build, Android build, direct API checks, browser matrices, and required Android evidence pass at the lesson baseline.
The Android project is tracked source. Copied web assets, build output, local SDK paths, caches, credentials, and signing material remain untracked.
One branch author and a different reviewer are available. An approved individual route uses the teacher as reviewer.
Use fictional records only. Do not add personal data, real school information, private client data, credentials, secrets, or device identifiers.
The teacher has stated the Stage 4 deadline, review window, presentation rehearsal slot, and official-assessment distinction.

Current state: The guided cross-platform branch can build browser and Android results, but the product does not yet explain both platform and data mode as one visible runtime contract. Stage 4 evidence, independent test proof, final review, integration, recovery archive, presentation route, and reflection are incomplete.
First action: Open the Delivery Board repository and run git fetch origin, git status, git log --oneline origin/main..HEAD, and the complete automated gate. Then create docs/final-delivery.md and record the base, branch, current lesson commits, deadline, roles, first checkpoint, and latest passing evidence.
First checkpoint: The final-delivery document maps every required technical and professional learning goal to one product result and one evidence source, names the two-day schedule and roles, and identifies only the runtime-information feature as active product work.
Help trigger: Open the assistance beside the active checkpoint or ask for help if the branch is not based on accepted Stage 3 main, a lesson commit is missing, the official brief conflicts with this practice route, the feature requires user-agent sniffing or a new plugin, runtime information disagrees with actual behavior, API and demo modes become coupled, a browser result is being used as Android proof, generated native output enters Git, the reviewer is asked to invent a defect, the two-day deadline cannot contain the remaining required path, or the presentation claims unsupported deployment, persistence, iOS, security, or device evidence.

Requirements

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

Repository and delivery boundary

Continue the existing private Delivery Board repository and feature/cross-platform branch. Do not create a replacement product history.
Preserve the cross-platform design and Capacitor packaging lesson results as separate commits. Add focused commits for runtime information, tests or evidence, and review responses when required.
Deliver the reviewed Stage 4 result to remote main through one pull request. The branch author and reviewer must be different people.
Use the teacher as reviewer for an approved individual route. Do not create a second account or simulate independent review.
Add docs/final-delivery.md and update README.md and docs/cross-platform-design.md so contracts, commands, evidence, limits, and recovery agree.
Keep node_modules, dist, coverage, copied Android web assets, Gradle output, local.properties, IDE caches, screenshots with private context, credentials, keystores, and signing values outside Git.

Independent platform-and-data explanation

Add one typed RuntimeInfo value with platform and dataMode fields. Platform is web, android, or unverified; dataMode is api or demo.
Read the platform once at startup through Capacitor.getPlatform(). Do not inspect the user-agent string, viewport width, touch support, or CSS to infer the operating platform.
Derive dataMode from the already validated RuntimeMode. Do not inspect a URL, adapter function name, or visible label to guess the data owner.
Pass RuntimeInfo through the existing startup and App dependency boundary instead of importing Capacitor inside a presentational component.
Show a persistent Runtime information section on list and detail routes before controls that change a work item.
Browser API mode must state Web browser, Express API, server process memory, and reset on Express restart.
Android demo mode must state Android app, fictional demonstration data, app process memory, and reset on reload or process termination.
An unverified platform must use that exact cautious meaning and must not claim iOS support.
The explanation must use visible text and programmatic structure. Meaning cannot depend only on color, icon, position, hover, or a tooltip.
The new section must wrap at 320 CSS pixels, Android portrait and landscape, 200 percent web zoom, WebView zoom, and Android large font without fixed-height clipping.

Existing React and API contracts

Keep typed components, explicit props, stable keys, controlled filters, immutable state updates, derived values, routed list and detail results, direct-route recovery, and not-found behavior.
Keep loading, populated, empty, initial failure, retry, update pending, update success, and update failure distinct and accessible.
Keep the Express application and listener split, copied in-memory store, validated route parameters, query, and bodies, stable JSON errors, no-store responses, and disabled X-Powered-By header.
Keep every successful response body untrusted until the client validates its exact envelope, record fields, values, labels, and identities.
Keep relative /api requests in normal web mode and keep the Vite proxy as the only local Express host owner.
Keep Android demonstration operations network-free, copied, immutable, abort-aware, visibly labeled, and reset by a new runtime instance.
Do not weaken an existing API, client, accessibility, test, or security boundary to simplify the final explanation.

Automated and sensitivity evidence

Keep every accepted API, adapter, component, route, and runtime-mode test from Stages 2 and 3.
Add focused tests for web, Android, and unverified platform mapping without depending on the machine that runs Vitest.
Add component tests for the exact web API and Android demo explanations and confirm that each remains visible on list and detail routes.
Confirm that invalid VITE_DATA_MODE still stops startup with the bounded configuration error.
Run one controlled mutation that swaps the Android data-owner text to Express API or hides its reset text. Prove that the selected component test fails for the intended reason.
Restore the mutation immediately. The final branch contains no deliberate defect, .only, .skip, stale debug output, test-order dependency, or unexplained snapshot.
Make npm test, npm run typecheck, npm run lint, npm run build, and npm run build:android pass from the committed dependency graph.

Web and Android runtime evidence

Verify the Express API directly before using the browser client. Record health, collection, filtered collection, one detail, one valid update, one invalid input, and one unknown route.
Verify normal development and built-preview web results with Express running. The runtime section must identify the browser and Express API and must not show Android demonstration claims.
Verify stopped-API load and retry plus stopped-API update failure without losing the last accepted state.
Verify the normal web result with keyboard, visible focus, direct routes, Back and Forward, 320 CSS pixels, 200 percent zoom, reduced motion, long content, no horizontal page overflow, and clean Console.
Build Android mode immediately before Capacitor sync. Record the Vite build, Capacitor sync, Gradle build, install, launch, and inspected WebView as separate evidence.
Launch the installed Android app after Vite and Express are stopped. It must identify Android and demonstration data, list fictional records, update one status, and make no API request.
Verify Android portrait, landscape, system bars, safe areas, touch targets, zoom, large font, routes, in-app Back, system Back, background, resume, termination reset, Console, and Network.
Name the emulator or authorized device and Android, API, and WebView versions. Do not describe emulator evidence as physical-device proof.
A blocked native environment must name the missing condition and owner. It is honest evidence, but it does not complete the required Android result unless the teacher approves alternative assessment evidence.

Accessibility and presentation quality

Keep one stable main element, one page h1 for every route result, logical headings, native controls, persistent labels, descriptive links, and useful status or alert semantics.
Keep required interactions operable with pointer, touch, Tab, Shift+Tab, Enter, Space, native select keys, in-app Back, and Android system Back where each input applies.
Preserve intentional focus for route entry, retry, successful updates, filtered-card removal, and failed updates.
Keep WCAG AA text contrast, visible focus, text-based state, reduced-motion equivalence, wrapping, and access to every control.
The runtime information must state the data lifetime in direct language and must not imply persistence, synchronization, offline behavior, deployment, or authentication.

Collaboration, feedback, and recovery

Name the branch author, reviewer, integration owner, evidence owner, and presentation rehearsal partner. One person can hold more than one role except author and reviewer.
The pull request must state the Stage 4 outcome, runtime-information contract, commit sequence, automated evidence, web evidence, Android evidence, current limits, and requested review focus.
The reviewer must record one runtime-information observation, one web or API observation, one Android observation, and one source-or-test observation.
When no defect is found, record the exact condition and relationship that passed. Do not invent a defect to satisfy feedback.
Respond to every review item with a focused change or an evidence-based decision and repeat affected checks.
Merge only after approval and current passing evidence. Synchronize every working copy through an ordinary pull without rewriting accepted history.
Verify npm ci, complete automated checks, normal web runtime, Android rebuild and sync, and selected native smoke results from a fresh clone or approved second clean working copy.
Create one handoff archive from the verified commit without Git metadata, dependencies, generated output, local configuration, credentials, device details, or unrelated work.

Presentation and reflection

Prepare an eight-to-ten-minute opening demonstration that leaves time for questions inside a 30-minute oral assessment including grading time. Follow a different local time if the teacher specifies one.
Demonstrate one complete user path, one React state decision, one Express validation contract, one test that protects behavior, one cross-platform difference, one Android result, and one recovery route.
Explain why this course uses JavaScript and TypeScript across React, Express, and Capacitor, what TypeScript changes and does not change, and how the server responsibilities transfer to PHP.
Present one constructive feedback example, the decision it caused or confirmed, and the repeated evidence.
State one current technical strength, one skill or interest you want to develop, one question you researched, and one limit you would address next.
Prepare a fallback route with screenshots, command output, and exact commit IDs. The fallback supports a failed live tool but does not replace required prior runtime evidence.
Complete two timed rehearsals. After each rehearsal, record duration, missing evidence, unclear terms, one change, and the next rehearsal start state.

Design freedom

Choose the final fictional demonstration records, product wording around the fixed data boundaries, Runtime information layout, and token-based visual treatment.
Choose the internal file and function names for platform mapping when their ownership remains clear and tests target the public result.
Choose the division of delivery roles, review method, evidence-file organization, and presentation examples.
Choose one evidence-based visual refinement after the required behavior passes. Do not add a new feature to fill remaining time.

Out of scope

Do not add a database, ORM, account, authentication, authorization, secret, payment, file upload, notification, camera, location, or production service.
Do not add a public API deployment, unrestricted CORS, development-host server URL, cleartext exception, or network allowlist for the Android demo.
Do not add iOS, Xcode, a second native platform, release signing, store delivery, production analytics, or a physical-device requirement.
Do not add PHP as a second implementation. Explain transferable responsibilities without maintaining duplicate servers.
Do not add a state library, query cache, runtime-schema dependency, UI framework, Docker, continuous integration, coverage target, or end-to-end framework to the required path.
Do not include optional extension work in the required estimate, completion decision, or assessment evidence.

Definition of done

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

feature/cross-platform contains the two lesson commits plus focused assignment, test, evidence, and review-response history based on accepted Stage 3 main;
the user-visible runtime information accurately distinguishes web API, Android demo, and unverified platform results without guessing from layout or user agent;
all accepted API and client contracts plus the new mapping and visible-explanation tests pass, and the controlled sensitivity mutation proves one selected test fails for the intended reason;
normal and Android builds pass, the normal client reaches the Express API, and the installed Android app uses copied demonstration data without a development server or API request;
direct HTTP, browser, WebView, Android, accessibility, orientation, lifecycle, Back, Console, Network, and reset evidence identify exact contexts and commits;
README, cross-platform design record, and final-delivery record agree about build modes, commands, evidence, ownership, data lifetime, PHP transfer, limits, and clean-clone recovery;
independent review covers product, web or API, Android, and source or tests, and every observation has a response;
the reviewed branch reaches remote main, every contributor synchronizes, and a clean recovery workspace reproduces the required source and build chain;
the handoff archive represents the verified commit without excluded files;
two timed individual rehearsals cover the required opening route, fallback, technical decisions, feedback, reflection, and limitations; and
the Teams submission identifies one final remote commit and one coherent evidence chain.

Project route

Complete one verified phase before opening the next:

Phase	Work	Exit result
1. Contract	Baseline, curriculum map, two-day schedule, roles, evidence index, active feature	Approved scope and one active implementation checkpoint
2. Explain	Typed runtime information, visible web and Android text, focused tests	Accurate explanation across list and detail routes
3. Prove	Automated gate, sensitivity check, direct API, browser, Android, accessibility	One identified commit with complete runtime evidence
4. Integrate	Review, responses, merge, synchronization, clean recovery, archive	Recoverable remote main and delivery artifact
5. Present	Opening route, fallback, questions, reflection, two rehearsals	Individual presentation evidence ready for the agreed deadline

At each exit, write what works, what remains, the exact next action, the latest passing commit, and the process or device state. Move optional ideas to Later.

Phase 1: Define the final delivery contract

Synchronize remote knowledge without changing the feature branch:

git fetch origin
git status
git branch --show-current
git log --oneline --decorate --graph --max-count=20
git log --oneline origin/main..HEAD
npm ci
npm test
npm run typecheck
npm run lint
npm run build
npm run build:android

Stop and record the first exact failure if this baseline does not pass. Do not repair a Stage 3 API defect or a missing lesson commit while calling it runtime-information work.

Create docs/final-delivery.md with these sections:

# Final delivery evidence

## Identity and schedule
## Roles and review window
## Starting branch and commits
## Curriculum and evidence map
## Runtime information contract
## Automated evidence
## Direct API evidence
## Browser evidence
## Android and WebView evidence
## Accessibility evidence
## Sensitivity proof
## Review and responses
## Integration and recovery
## Presentation route and fallback
## Current limits
## Resume state

Map the curriculum to observable evidence

Complete this table with paths, commands, interactions, and evidence IDs:

Learning goal	Product result	Required evidence
Understand and use a front-end framework	React components, props, state, events, routes, effects, and focused tests	one traced user path plus source and test location
Develop and test an API	Express routes, runtime validation, store, errors, and Supertest contracts	one valid and one invalid direct request plus tests
Use a simple API	validated relative client requests and accepted server representations	Network result plus adapter and interface evidence
Implement a design for more than one platform	responsive browser result and installed Android WebView result	separate browser and Android matrices
Use version control	focused branches, review, responses, merge, synchronization, recovery	Git graph, pull request, final commit, clean clone
Use a preprocessor efficiently	bounded Sass ownership and reusable tokens or structure	source relationship and build result
Take part in teamwork and feedback	named ownership and specific review observations	review record and response
Find, adapt to, and share knowledge	current platform API research and clear runtime explanation	official source, implementation decision, oral explanation
Deliver, document, and communicate	two-day plan, accurate handoff, archive, and rehearsals	schedule, docs, archive manifest, timed route
Reflect on skills and interests	one evidence-based strength, challenge, interest, and next question	private individual reflection and oral answer

An evidence location must identify a result. “See repository” or “tested manually” is not enough.

Protect the two-day scope

Write a schedule against the teacher’s actual practical hours. Use this shape:

Boundary	Target	Protected result
Day 1 start	first 45–60 minutes	baseline, contract map, roles, exact feature tests
Day 1 middle	before the midpoint	platform mapping and visible web result
Day 1 end	agreed checkpoint	Android text, focused tests, sensitivity proof, clean commit
Day 2 start	first checkpoint	complete automated gate and current evidence target
Day 2 middle	protected review boundary	web, API, Android, accessibility evidence complete
Day 2 final work block	before hand-in buffer	review responses, docs, final regression, archive candidate
Protected buffer	teacher-agreed final period	no new feature; recovery, submission, and presentation index only

Include setup, Android build time, support, debugging, review, re-entry, and submission. When an active requirement threatens the protected buffer, reduce presentation styling or optional evidence decoration. Do not remove a product contract, test, accessibility check, or native requirement without teacher approval.

Write the runtime-information contract before source

Define these values:

Platform input	Visible platform	Meaning
`web`	Web browser	Capacitor reports the web platform
`android`	Android app	Capacitor reports the generated Android platform
any other value	Unverified platform	the current course has no verified support claim for that value

Data mode	Visible source	Lifetime
`api`	Express API	server process memory; resets when Express restarts
`demo`	Fictional demonstration data	application process memory; resets on reload or process termination

Keep platform and data mode as separate facts. The browser can render demo mode during build verification. A future Android deployment could use an API. Do not encode one fact by assuming the other.

Check

Confirm the accepted base, lesson commits, exact deadline, protected buffer, role ownership, evidence IDs, official source for Capacitor.getPlatform(), and two independent runtime dimensions before editing product code.

Assistance for Phase 1

Assistance 1 — Identify the only new product behavior

The required new behavior is a visible section that names the current Capacitor platform, selected data source, and reset boundary. Existing list, detail, filter, update, API, and packaging behavior remains protected.

Assistance 2 — Separate a platform from a data source

Ask two questions: “What container reports this runtime?” and “Which adapter owns the records?” The answers can change independently. Model two fields instead of one combined label.

Assistance 3 — Build the Day 1 start state in order

Fetch and inspect → run the baseline gate → create final-delivery headings → record deadline and roles → map each learning goal → write platform and data tables → list focused tests → open the runtime module.

Checkpoint: Stage 4 has a two-day contract and one active feature

What now works: The branch and lesson baseline pass, roles and deadline are known, each curriculum goal maps to observable evidence, platform and data source remain separate, and only the runtime-information feature is active.
Files changed: docs/final-delivery.md, README.md, Git history and remote main
What remains: Implement the typed runtime boundary, visible explanation, and focused tests without changing existing product contracts.
Next action: Create src/runtime/runtime-info.ts with the platform mapper and RuntimeInfo type, then write its three mapping tests before changing App.
If it does not work: If scope is unclear, return to the two small tables and remove every idea that does not change or prove their visible result.

Phase 2: Add the runtime information

Create the typed boundary:

import type { RuntimeMode } from './runtime-mode';

export type AppPlatform = 'web' | 'android' | 'unverified';

export type RuntimeInfo = {
  platform: AppPlatform;
  dataMode: RuntimeMode;
};

export function mapCapacitorPlatform(value: string): AppPlatform {
  if (value === 'web' || value === 'android') {
    return value;
  }

  return 'unverified';
}

The course does not generate or verify iOS. Mapping every other string to unverified preserves that boundary. Do not throw for an unknown platform because the product can still explain that the platform has not been verified.

Add focused mapping tests:

import { describe, expect, it } from 'vitest';

import { mapCapacitorPlatform } from './runtime-info';

describe('mapCapacitorPlatform', () => {
  it('keeps the verified web platform', () => {
    expect(mapCapacitorPlatform('web')).toBe('web');
  });

  it('keeps the verified Android platform', () => {
    expect(mapCapacitorPlatform('android')).toBe('android');
  });

  it('does not create an unsupported platform claim', () => {
    expect(mapCapacitorPlatform('ios')).toBe('unverified');
    expect(mapCapacitorPlatform('desktop-shell')).toBe('unverified');
  });
});

Read the platform at the startup boundary

Extend the existing runtime factory:

import { Capacitor } from '@capacitor/core';

import { mapCapacitorPlatform, type RuntimeInfo } from './runtime-info';

export type RuntimeSelection = {
  mode: RuntimeMode;
  api: WorkItemsApi;
  info: RuntimeInfo;
};

export function createRuntime(
  value: unknown = import.meta.env.VITE_DATA_MODE,
  platformValue: string = Capacitor.getPlatform(),
): RuntimeSelection {
  const mode = parseRuntimeMode(value);

  return {
    mode,
    api: mode === 'demo' ? createDemoWorkItemsApi() : workItemsApi,
    info: {
      platform: mapCapacitorPlatform(platformValue),
      dataMode: mode,
    },
  };
}

The optional platformValue input keeps unit tests deterministic. Product startup uses the current Capacitor result. Tests pass explicit strings instead of mocking a machine or global runtime.

Pass runtime.info into App from main.tsx. Replace the prior standalone runtimeMode App prop with runtimeInfo, and use runtimeInfo.dataMode for the existing demonstration notice. This gives App one data-mode source. Keep the validated parser, notice behavior, and lesson tests. The runtime factory can keep its mode field if another startup responsibility still uses it.

Add a default web API value only if existing focused App tests need a concise default:

type AppProps = {
  api?: WorkItemsApi;
  runtimeInfo?: RuntimeInfo;
};

const defaultRuntimeInfo: RuntimeInfo = {
  platform: 'web',
  dataMode: 'api',
};

Do not call Capacitor.getPlatform() from App or a presentational component. The startup boundary owns runtime selection; components own rendering.

Render one visible explanation

Create a component that derives text from the two fields:

import type { RuntimeInfo } from '../runtime/runtime-info';

type RuntimeInformationProps = {
  info: RuntimeInfo;
};

const platformLabels = {
  web: 'Web browser',
  android: 'Android app',
  unverified: 'Unverified platform',
} as const;

export function RuntimeInformation({ info }: RuntimeInformationProps) {
  const usesApi = info.dataMode === 'api';

  return (
    <section
      className="runtime-information"
      aria-labelledby="runtime-information-title"
    >
      <h2 id="runtime-information-title">Runtime information</h2>
      <dl>
        <div>
          <dt>Platform</dt>
          <dd>{platformLabels[info.platform]}</dd>
        </div>
        <div>
          <dt>Data source</dt>
          <dd>{usesApi ? 'Express API' : 'Fictional demonstration data'}</dd>
        </div>
        <div>
          <dt>Data lifetime</dt>
          <dd>
            {usesApi
              ? 'Server process memory. Data resets when Express restarts.'
              : 'Application process memory. Data resets on reload or process termination.'}
          </dd>
        </div>
      </dl>
    </section>
  );
}

Use the existing demonstration notice as part of this section or keep both pieces adjacent. Do not present two conflicting reset statements. If you consolidate them, preserve the lesson tests that distinguish demo and API modes.

Render the section from the shared App shell so it remains present on list and detail routes. Keep it before the work-item controls and after the product introduction.

Use existing Sass tokens. A suitable ownership pattern is:

.runtime-information {
  display: grid;
  gap: var(--space-3);
  padding: var(--space-4);
  border: 1px solid var(--color-border-strong);
  border-radius: var(--radius-medium);
  background: var(--color-surface-raised);
  overflow-wrap: anywhere;

  h2,
  dl,
  dd {
    margin: 0;
  }

  dl {
    display: grid;
    gap: var(--space-3);
  }

  dt {
    font-weight: 700;
  }
}

Use token names that exist in the project. Do not create a second general design system for one section.

Test visible meaning

Add exact component contracts:

it('explains the web API boundary', () => {
  render(
    <RuntimeInformation info={{ platform: 'web', dataMode: 'api' }} />,
  );

  expect(screen.getByText('Web browser')).toBeVisible();
  expect(screen.getByText('Express API')).toBeVisible();
  expect(screen.getByText(/resets when Express restarts/i)).toBeVisible();
});

it('explains the Android demonstration boundary', () => {
  render(
    <RuntimeInformation info={{ platform: 'android', dataMode: 'demo' }} />,
  );

  expect(screen.getByText('Android app')).toBeVisible();
  expect(screen.getByText('Fictional demonstration data')).toBeVisible();
  expect(screen.getByText(/reload or process termination/i)).toBeVisible();
});

it('keeps an unsupported platform unverified', () => {
  render(
    <RuntimeInformation info={{ platform: 'unverified', dataMode: 'demo' }} />,
  );

  expect(screen.getByText('Unverified platform')).toBeVisible();
  expect(screen.queryByText(/iOS app/i)).not.toBeInTheDocument();
});

Add routed App tests that open one list URL and one detail URL and find the section in each result. Keep the API dependency injected so no test requires a live process.

Run the controlled sensitivity proof

After the focused and complete suites pass:

change the Android demo data-source text to Express API or remove the process-reset sentence;
run only the relevant component test;
confirm that it fails on the exact changed contract;
record the command, expected failure, actual failure, and tested commit in docs/final-delivery.md;
restore the source immediately;
rerun the focused test and complete suite; and
inspect the diff to prove the mutation is absent.

Do not weaken the assertion after it catches the defect.

Check

Open list and detail routes in both injected test modes. Confirm the platform, source, and lifetime terms; heading and description relationships; wrapping; no duplicate conflict; and unchanged work-item behavior.

Assistance for Phase 2

Assistance 1 — Locate the four owners

runtime-info.ts maps platform input, create-runtime.ts selects startup facts, App passes the value, and RuntimeInformation.tsx renders meaning. Keep Capacitor out of the presentational component.

Assistance 2 — Use two independent questions in every failure

If text is wrong, inspect platform mapping and data-mode parsing separately. A correct Android label cannot prove the demo adapter, and a correct demo label cannot prove Android.

Assistance 3 — Build the feature through passing slices

Map and test platform → add RuntimeInfo to the factory → inject a known value in tests → render the semantic section → test web text → test Android text → test unverified text → render on both routes → add Sass → run the sensitivity proof.

Checkpoint: The product explains its current runtime boundary

What now works: Startup reads and maps the Capacitor platform once, RuntimeInfo keeps platform and data mode separate, list and detail routes show accurate source and reset text, focused tests cover verified and unverified results, and the sensitivity proof detects a false Android data claim.
Files changed: src/runtime/runtime-info.ts, src/runtime/runtime-info.test.ts, src/runtime/create-runtime.ts, src/main.tsx, src/App.tsx, src/components/RuntimeInformation.tsx, src/components/RuntimeInformation.test.tsx, src/styles/_app.scss, docs/final-delivery.md
What remains: Prove the complete API, browser, Android, accessibility, and recovery result against one identified commit.
Next action: Commit the passing runtime-information feature, record its commit ID, then run the complete automated gate before starting any process.
If it does not work: Return to the last clean feature commit, run the focused mapping and component tests, and trace input platform plus validated mode to visible text before changing layout.

Phase 3: Prove one complete product commit

Create a focused feature commit after the new behavior and tests pass. Then record its ID:

git status
git diff --check
npm test
npm run typecheck
npm run lint
npm run build
npm run build:android
git rev-parse HEAD

If a documentation-only commit follows, record both source and evidence commit IDs. Do not let later source changes keep the old runtime evidence label.

Verify the API directly

Start Express in its own terminal. Record method, URL, request body when present, expected result, actual status, response shape or error code, relevant headers, and commit for:

health;
complete work-item collection;
one valid status filter;
one invalid or repeated status filter;
one known item;
one unknown item;
one valid status update;
one invalid status update;
malformed JSON; and
one unknown API route.

Confirm that a server restart restores the seed. Stop only the server process you started after all web API evidence is complete.

Verify normal browser mode

Run both process pairs:

Pair	API process	Client process	Purpose
Development	normal Express development command	normal Vite development command	source maps and day-to-day behavior
Built preview	normal Express production-like command	Vite preview after normal build	built browser asset behavior

For each pair, verify:

Runtime information says Web browser, Express API, and reset on Express restart;
the Network request uses relative /api and reaches the intended local Express target;
cold load, populated list, empty response where controlled, filter, detail, direct detail entry, not-found route, valid update, and accepted server representation;
stopped-API initial failure followed by retry without page reload;
stopped-API update failure with retained accepted state and useful focus;
Back and Forward synchronization;
pointer and complete keyboard route;
320-by-568 portrait browser viewport and 568-by-320 landscape browser viewport;
200 percent browser zoom and long uninterrupted text;
light and dark themes if supported;
reduced-motion preference;
no horizontal page overflow, clipped focus, color-only meaning, unexpected Console output, or unknown request; and
the exact browser, version, viewport, mode, URL, and commit.

Do not run the Android build before this built-preview evidence. Each Vite build replaces dist.

Verify Android build and installed runtime

After normal web evidence is recorded:

npm run cap:sync:android
npx cap run android --list
npm run cap:run:android

The sync script must build Android mode before copying. Record each layer:

Layer	Evidence
TypeScript and Vite Android build	passing command and demo-mode bundle input
Capacitor sync	copied `dist` source, Android target, plugin update output
Gradle build	debug build result and native project commit
Install and launch	named target, API version, installed application start
WebView render	Android label, demo source, record list, routes, update
WebView diagnostics	inspected WebView version, Console, Network

Stop Vite and Express. Relaunch the installed application from the Android launcher. Verify:

Runtime information says Android app, Fictional demonstration data, and reset on reload or process termination;
at least six fictional records render with expected statuses and long-content cases;
no /api, loopback, private host, or development-machine request occurs;
one status change persists through route navigation in the same running instance;
reload or process termination restores the committed demonstration seed;
list, known detail, unknown route, filter, pending state, confirmed update, and feedback remain available;
portrait and landscape keep system bars, safe areas, content, focus, and actions accessible;
WebView zoom and Android large-font settings preserve content and controls;
touch targets, TalkBack or available accessibility inspection, headings, names, status text, and non-color meaning are usable;
in-app Back and Android system Back follow the recorded route and root policy;
Home and resume behavior is recorded without promising process survival; and
Console and Network have no unexplained error or request.

If you use an emulator, state emulator. If you use an authorized physical device, state physical device. Do not generalize one result to every Android version or hardware class.

Reconcile source, generated output, and evidence

Run after native evidence:

git status --short
git diff --check
git check-ignore -v dist android/local.properties
git ls-files android
npm test
npm run typecheck
npm run lint
npm run build

The final normal build changes generated dist from Android mode back to API mode. That is expected. Source and documentation must remain the only intentional changes.

Update the three durable documents:

README: quick start, process roles, scripts, runtime modes, API and Android routes, test commands, data lifetime, recovery, and limits;
docs/cross-platform-design.md: final browser and Android matrices, actual contexts, known issues, and evidence commit; and
docs/final-delivery.md: curriculum map, sensitivity proof, complete evidence index, review-ready state, and next action.

Assistance for Phase 3

Assistance 1 — Identify the current evidence layer

Name one layer before debugging: automated source, direct API, browser development, browser preview, Android Vite build, Capacitor sync, Gradle build, install, WebView render, or interaction. Use evidence from that layer first.

Assistance 2 — Separate a stale Android result from a product defect

Compare source commit → Android Vite build time → sync output → Gradle build → installed app version → WebView content. Rebuild and sync before editing React when the installed text comes from an older bundle.

Assistance 3 — Run evidence in dependency order

Automated gate → direct API → development browser pair → normal build and preview pair → Android build and sync → native build and install → WebView diagnostics → orientation and accessibility → lifecycle and reset → final source gate → documents.

Checkpoint: One identified commit has complete web and Android evidence

What now works: Automated checks and sensitivity proof pass, direct API and both browser pairs verify API mode, the installed Android app verifies demonstration mode without development servers, accessibility and lifecycle checks are recorded, and all durable documents identify exact contexts and limits.
Files changed: README.md, docs/cross-platform-design.md, docs/final-delivery.md, Automated output, API evidence, Browser evidence, Android and WebView evidence
What remains: Obtain independent review, integrate the accepted branch, reproduce it from a clean workspace, create the handoff archive, and prepare the individual oral route.
Next action: Stop all project processes, inspect the complete diff and Git status, push the clean branch, and open the Stage 4 pull request with the evidence index and requested review focus.
If it does not work: Return to the earliest failing layer, reproduce one exact condition, repair one owner, repeat the affected contract and dependent evidence, and update the evidence commit before review.

Phase 4: Review, integrate, and recover Stage 4

Review the branch before publishing it:

git status
git diff --check
git diff --stat origin/main...HEAD
git log --oneline origin/main..HEAD
npm test
npm run typecheck
npm run lint
npm run build
git push

Use the repository’s normal pull-request route. Do not rewrite accepted history or force push through an unexplained conflict.

Open the Stage 4 pull request

The description must include:

visible Stage 4 outcome;
accepted Stage 3 base and cross-platform lesson commits;
platform and data-mode contract;
new source and test ownership;
complete focused commit sequence;
automated test counts and gate results;
direct API evidence summary;
development and preview browser evidence summary;
Android target, build, install, WebView, accessibility, Back, lifecycle, and reset summary;
sensitivity proof;
generated-file and data boundaries;
current limits and blocked rows;
recovery commands and final evidence-document path; and
four requested review observations.

Request review of these relationships:

runtime platform and data mode produce accurate visible text;
normal web mode still reaches the validated Express API;
installed Android mode uses copied demonstration data without a development server; and
tests, source ownership, generated-file policy, and documentation agree.

Conduct independent review

The reviewer checks out the branch in a clean working copy or uses an approved existing clean clone. The reviewer records condition, action, expected result, actual result, evidence, consequence, and conclusion for:

one list or detail runtime-information result;
one direct API or browser API result;
one Android installed-runtime result; and
one source or test relationship.

A review observation can confirm a correct result. For example:

On the named Android emulator with Vite and Express stopped, Runtime information identified the Android app and fictional demonstration data. Changing one status produced no Network request, and terminating and relaunching restored the seed. This supports the packaged memory boundary; no defect was found.

Do not write “looks good” without the condition and relationship. Do not invent an issue when the required result passes.

Respond to feedback

For each observation, record:

what the reviewer observed;
whether you reproduced it;
the contract and consequence;
the chosen change or reason to keep the result;
the focused check repeated; and
the dependent regression repeated when source changed.

Use a separate focused commit for a source repair. A documentation correction can use its own documentation commit. Update the pull request and evidence commit IDs.

Integrate safely

Before merge, inspect whether remote main moved:

git fetch origin
git log --oneline HEAD..origin/main
git log --oneline origin/main..HEAD

When main contains new accepted work, merge current remote main into the feature branch through the repository’s ordinary workflow. Resolve one file at a time, run the complete gate, repeat affected browser and Android checks, push, and obtain renewed approval.

After approval, the integration owner merges the pull request with focused history preserved. Every contributor synchronizes:

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

Verify clean recovery

Use a new empty folder outside all existing working copies:

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

Then prove both operation routes:

start Express and the normal Vite development or preview client;
verify direct health, web Runtime information, collection, one detail, and one update;
stop those processes;
run npm run cap:sync:android from the clean clone;
build and install the Android debug app or open the generated project in Android Studio;
relaunch it without development servers;
verify Android Runtime information, fictional data, one route, one update, and reset; and
confirm that source remains clean and local generated files remain ignored.

If Android Studio creates local.properties, that is expected local configuration. It must remain untracked.

Create the handoff archive

Create the archive from the verified remote main commit, not from an uncommitted working directory. Include tracked source, tests, native source, README, and documentation. Exclude:

.git/ and pull-request metadata;
node_modules/, dist/, coverage, copied web assets, Gradle outputs, and caches;
local.properties, editor settings with personal paths, emulator state, logs, and screenshots with unrelated context;
environment files that contain anything other than the approved public Android mode value;
secrets, credentials, certificates, keystores, signing values, tokens, personal data, or device identifiers; and
unrelated projects or individual reflection.

Record the archive name, source commit, creation command or method, manifest check, and extraction smoke result in docs/final-delivery.md.

Check

Compare the merged remote commit, every synchronized local main, clean recovery clone, extracted archive, README, and evidence records. They must identify the same source and limits.

Assistance for Phase 4

Assistance 1 — Make the branch reviewable before asking for review

Stop processes, make status clean, list commits, run the full gate, update evidence IDs, push, and place the four requested observations plus exact recovery route in the pull request.

Assistance 2 — Turn one observation into a decision

Write condition → expected contract → observed result → consequence → reproduce → change or keep → focused check → dependent regression. A correct relationship can end with “keep.”

Assistance 3 — Close the shared delivery in order

Independent observations → author responses → current-main comparison → merge main if needed → full gate and affected runtime checks → renewed approval → merge → synchronize all contributors → clean-clone web proof → clean-sync Android proof → archive and extract.

Checkpoint: The reviewed final product is recoverable from remote main

What now works: Four specific review observations have responses, approved focused history reaches remote main, all contributors are synchronized, a clean clone reproduces web and Android routes, and the handoff archive matches the verified commit without excluded files.
Files changed: Merged Stage 4 pull request, Remote and local main history, README.md, docs/final-delivery.md, Fresh recovery workspace, Handoff archive
What remains: Prepare and rehearse the individual oral route, complete the private reflection, run the final self-check, and submit one coherent evidence index.
Next action: Create an eight-to-ten-minute opening outline that begins with the product outcome and uses the final remote commit and fallback evidence.
If it does not work: Compare pull-request state, remote main, local main, lockfile install, generated ownership, web route, Android sync and install, and archive manifest before changing source after merge.

Phase 5: Prepare the individual oral route

The curriculum’s oral examination lasts 30 minutes including grading time. That does not mean a 30-minute uninterrupted presentation. Prepare an eight-to-ten-minute opening unless the teacher gives another limit. The remaining time supports questions, discussion, and grading.

Build the opening route

Use this order:

Time	Section	Required evidence
0:00–0:45	Outcome and scope	user, product outcome, web result, Android result, final commit
0:45–2:00	Complete user path	list, route, status update, feedback, and current runtime information
2:00–3:15	React and TypeScript	one prop or state boundary, one JS/TS distinction, one tested result
3:15–4:30	Express and API	one request, runtime validation, status and JSON response, PHP transfer
4:30–5:45	Test and failure evidence	one automated contract, sensitivity proof, one recovered failure
5:45–7:00	Cross-platform result	shared React source, build modes, Capacitor sync, installed Android evidence
7:00–8:00	Git and feedback	focused history, one reviewer observation, decision, repeated evidence
8:00–9:00	Recovery and limits	clean clone, generated ownership, data lifetime, unsupported claims
9:00–10:00	Reflection and next step	strength, challenge, interest, researched question, next learning goal

Use fewer examples when the teacher sets a shorter opening. Do not speed through every file.

Explain JavaScript, TypeScript, and PHP clearly

Prepare a concise comparison:

JavaScript is the runtime language used by the browser and Node in this project.
TypeScript adds static type syntax and checking during development, then emits JavaScript for runtime.
TypeScript cannot validate unknown HTTP, form, file, or storage data by itself. Runtime parsers still protect those boundaries.
PHP is a valid server-side alternative. It can receive requests, route paths, validate input, call application logic, choose status codes, and return JSON.
This course keeps TypeScript on both client and server so you can reuse the JavaScript model while learning the transferable server responsibilities.
The choice is about the course learning path, not a claim that PHP is inferior.

Use one code relationship from your final commit to support each relevant statement.

Prepare question routes

Be ready to answer:

Why use React instead of manual DOM rendering here?
Which values are source state, server state, URL state, derived state, and request state?
What does TypeScript prove, and where is runtime validation still required?
Why does the API return its selected status and representation?
How would the same HTTP contract look in a PHP application?
Why are relative API paths correct for web development but insufficient for this packaged Android boundary?
What does Capacitor build and what does Vite build?
Why are Android native files source while copied web assets and Gradle output are generated?
What can the browser matrix prove, and what requires an installed Android target?
Which test caught the controlled false data claim?
What feedback did you give and receive, and how did it affect the result?
Which skill or type of work currently interests you, and what evidence informs that reflection?
What would you change first if the product required persistence, public deployment, authentication, or iOS?

State when a question exceeds the evidence. A precise limitation is stronger than an invented answer.

Build a fallback route

Prepare a small indexed evidence set:

repository and final remote commit;
Git graph and pull-request result;
automated gate output;
one direct API success and one validation failure;
normal browser list and detail with Runtime information;
Android portrait and landscape results;
WebView Console and Network result;
Back, lifecycle, and reset notes;
review observation and response;
clean-clone recovery result; and
archive manifest.

The fallback helps if a server, emulator, Android Studio, browser, network connection, or display connection fails during the presentation. It does not replace the prior required runtime checks.

Rehearse twice

For each rehearsal, record:

start and end time;
exact commit and evidence set;
whether the opening fit its limit;
which product path or command failed;
which term or boundary was unclear;
one section to cut, move, or clarify;
one question answered with evidence;
fallback time; and
the exact next rehearsal start state.

Use the first rehearsal to find missing evidence. Use the second to verify the revised route. Do not redesign the product between rehearsals unless a required defect is confirmed.

Complete the private reflection

Write 300–450 words in Teams or the teacher’s approved private system. Keep it out of the shared repository. Include:

one technical area you owned;
one team behavior you contributed;
one constructive observation you gave;
one observation you received and how you evaluated it;
one failure or interruption and the recovery evidence that helped;
one current strength supported by a specific result;
one challenge or support route that matters for future work;
one web-development area that interests you and why;
one question you researched; and
one next learning goal.

Reflection is not a confession or a personality score. Use work evidence and specific decisions.

Assistance for Phase 5

Assistance 1 — Start with the visible result

Say who the application serves, what the user can do, why there are two runtime results, and which commit you are showing. Then demonstrate one path before explaining architecture.

Assistance 2 — Reduce an opening that exceeds ten minutes

Keep one example for React, one for API validation, one for testing, one for Android, one for feedback, and one for recovery. Move file tours, full matrices, and optional research to questions.

Assistance 3 — Build a route that survives tool failure

Outcome → live user path or screenshots → one source relationship → one test → one direct API record → one Android record → Git and feedback → recovery and limits → reflection. Keep exact evidence IDs beside the outline.

Checkpoint: The individual presentation route is timed and evidence-backed

What now works: Two rehearsals fit the agreed opening time, every technical claim points to final evidence, JavaScript, TypeScript, PHP, React, Express, Capacitor, and generated ownership are explained accurately, a fallback route is ready, and the private reflection uses work evidence.
Files changed: Presentation outline, Fallback evidence index, Two rehearsal records, Private individual reflection, docs/final-delivery.md
What remains: Complete the self-check and submit the final shared and individual evidence before the agreed deadline.
Next action: Compare every self-check item with the final remote commit, merged review, recovery workspace, archive, presentation index, and Teams message.
If it does not work: If the route is incomplete, keep the product unchanged and repair the smallest missing evidence link, term definition, fallback item, or timing transition.

Self-check

Complete these checks against the required result.

Confirm that Stage 4 continued the existing private Delivery Board history from accepted Stage 3 main.
Confirm that the cross-platform design and Capacitor lesson outcomes remain separate focused commits.
Name the branch author, reviewer, integration owner, evidence owner, and rehearsal partner, and confirm that author and reviewer differ.
Point to the teacher-provided deadline, practical-day schedule, protected buffer, first checkpoint, help trigger, and done signal.
Map every technical, personal, and work-capacity learning goal to one observable product or evidence result.
Point to RuntimeInfo and explain why platform and data mode are independent fields.
Confirm that Capacitor.getPlatform runs at startup and no user-agent, viewport, touch, or CSS test guesses the platform.
Confirm that web and Android map to verified values and every other platform remains unverified.
Confirm that api and demo modes come from the validated configuration parser rather than visible text or adapter names.
Open list and detail routes in web API mode and confirm Web browser, Express API, and Express-restart lifetime text.
Open list and detail routes in Android demo mode and confirm Android app, fictional demonstration data, and reload-or-process-termination text.
Confirm that the runtime section uses a heading and description structure, visible text, wrapping, and no color-only meaning.
Run platform mapping, runtime factory, runtime component, and routed App tests with deterministic injected values.
Run the controlled false Android data-owner or missing-reset mutation, observe the intended focused failure, restore source, and rerun the suite.
Confirm that no deliberate mutation, .only, .skip, stale debug output, test dependency, or unexplained snapshot remains.
Run all client and API tests, typecheck, lint, normal build, Android build, and git diff --check from committed dependencies.
Request the complete direct API matrix and confirm routes, validation, status, JSON, headers, and restart reset.
Run normal development and built-preview process pairs and confirm accurate runtime text plus the complete client journey.
Stop Express before load and during update and confirm retry, retained accepted state, feedback, and focus.
Verify browser keyboard use, direct routes, Back and Forward, 320 pixels, 200 percent zoom, long content, reduced motion, contrast, wrapping, overflow, and Console.
Build Android mode immediately before Capacitor sync and distinguish Vite build, sync, Gradle build, install, launch, and WebView evidence.
Launch the installed Android app with Vite and Express stopped and confirm no API or development-host request.
Verify Android list, detail, filter, update, feedback, in-app Back, system Back, portrait, landscape, system bars, safe areas, touch, zoom, and large font.
Verify Android background, resume, reload, termination, relaunch, Console, Network, and demonstration reset boundaries.
Name the actual Android target, API, and WebView versions and distinguish emulator from physical-device evidence.
Confirm that native source and Gradle wrapper are tracked while copied assets, build output, local SDK paths, caches, and signing material are excluded.
Read README, cross-platform-design.md, and final-delivery.md and confirm commands, evidence, data lifetime, PHP transfer, limits, commits, and recovery agree.
Confirm that the pull request states outcome, contracts, history, automated, API, browser, Android, sensitivity, limit, and recovery evidence.
Confirm that review records one runtime-information, one web or API, one Android, and one source-or-test observation without an invented defect.
Confirm that every review observation has a response and affected checks were repeated after source changes.
Confirm that the approved Stage 4 branch reached remote main with focused history and every contributor synchronized cleanly.
Run npm ci and complete web and Android recovery from a new clean workspace without a source edit.
Inspect the extracted handoff archive and confirm that it matches the verified commit and contains none of the excluded files.
Complete two timed opening rehearsals with the final commit, fallback route, technical decisions, evidence, limits, and questions.
Explain JavaScript, TypeScript, and PHP without claiming that static types replace runtime validation or that one server language is universally better.
Present one specific feedback relationship, one recovery route, one supported limitation, one technical strength, and one next learning goal.
Confirm that the shared Teams message and private individual reflection use the required locations and contain no secret or personal product data.

Assessment evidence

The capstone review uses observable evidence from the stable required path:

Area	Weight	Evidence
React, TypeScript, and front-end structure	20%	component, state, event, route, prop, runtime-information, Sass, accessibility, and focused test relationships
API development and consumption	20%	Express architecture, runtime validation, HTTP contracts, Supertest, client response validation, direct and browser evidence, PHP transfer
Cross-platform design and Android delivery	20%	responsive contract, safe areas, build modes, Capacitor config, generated ownership, sync, install, WebView, Back, lifecycle, reset, and native evidence
Testing and quality evidence	15%	deterministic portfolios, sensitivity proof, automated gate, failure recovery, browser matrix, Android matrix, Console, Network, and exact commits
Version control, teamwork, and recovery	10%	focused history, roles, specific feedback, responses, approval, merge, synchronization, clean clone, and archive
Documentation and oral communication	15%	accurate handoff, curriculum map, evidence index, stack rationale, timed route, fallback, limitations, reflection, and questions

Optional extensions do not affect required completion or the assessment result. The teacher applies the Danish 7-point grading scale to the official assessment and can adapt evidence weighting to the official brief.

Assignment-wide assistance

Checkpoint assistance supports the current phase. Use these deeper routes when several owners or evidence layers are unclear.

Assistance 4 — Review a partial final-delivery responsibility map

src/runtime/runtime-mode.ts               validates public data mode
src/runtime/runtime-info.ts               maps verified platform names
src/runtime/create-runtime.ts             selects API, mode, and platform once
src/api/work-items-api.ts                 validates HTTP responses
src/api/demo-work-items-api.ts            owns copied process-memory records
src/components/RuntimeInformation.tsx     renders platform, source, and lifetime
src/App.tsx                               composes shared shell and route state
server/app.ts                             owns Express configuration and routes
server/store/                             owns copied server-process records
capacitor.config.ts                       owns native package and WebView behavior
android/                                  owns tracked Android source and wrapper
docs/cross-platform-design.md             owns browser and native design evidence
docs/final-delivery.md                    owns complete curriculum and delivery index
README.md                                 owns contributor operation and recovery

Use this recovery order:

restore a clean identified source commit;
run the smallest focused test;
run all automated source checks;
verify the API directly;
verify normal browser mode;
build Android mode and sync;
verify native build and installation;
inspect the WebView;
verify interaction and accessibility;
reconcile docs, review, recovery, archive, and presentation evidence.

Keep one active failure. Record unrelated ideas under Later.

Assistance 5 — Review the complete guided Level 3.1 routeExample solution

Use the accepted lesson and project-stage outcomes as the complete guided baseline:

Move from JavaScript to TypeScript — runtime versus static checks and stack rationale.
Set up React, TypeScript, Vite, and Sass — reproducible workspace and bounded preprocessor.
Work with version control in a team — roles, review, integration, and recovery.
Build typed React components — component and prop boundaries.
Manage React state — source, derived, URL, and request state.
Build routes with React Router — URL ownership and navigation.
Test a React application — focused tests and sensitivity proof.
Run TypeScript with Node and Express — runtime and process boundary.
Develop and test a JSON API — runtime validation, HTTP, store, errors, and Supertest.
Connect React to the API — untrusted response parsing and explicit request states.
Design for web and mobile contexts — platform contract, responsive evidence, safe areas, and packaged data decision.
Package and test with Capacitor — demo adapter, Android project, sync, installation, WebView, Back, lifecycle, and generated ownership.

The assignment-specific work remains required:

map the full curriculum to final evidence;
add and test Runtime information;
complete the sensitivity proof;
run the complete API, browser, and Android evidence routes;
obtain independent review and respond;
integrate and recover remote main;
create and inspect the handoff archive; and
complete two individual presentation rehearsals and private reflection.

The guided route does not supply finished project source or observed evidence. Use the final repository, installed tools, current official references, and actual results.

Optional final-project extensions

Complete the required result, final review, and safe commit before starting an extension on a separate branch. Extensions do not improve required completion.

Add an observed lifecycle indicator

Use the App plugin’s appStateChange event to display active or backgrounded process state. Remove the listener during cleanup, preserve the memory boundary, and test through an injected adapter. Do not claim that a process will always survive backgrounding.

Verify one authorized physical Android device

Install the accepted debug build on an approved physical device. Record the device class without a private identifier, Android and WebView versions, touch, zoom, large font, orientation, Back, lifecycle, performance, Console, and Network. Keep emulator and physical-device evidence separate.

Design a real HTTPS API route for Android

Write an architecture decision for an approved public HTTPS host, environment configuration, CORS, authentication and authorization needs, secrets, storage, availability, telemetry, failure behavior, operations, and data protection. Do not deploy or embed a development computer address without authorization.

Add one real-browser automated critical path

Automate the web list-to-detail-to-status route or stopped-API retry against built assets. State the browser regression it protects, keep existing Vitest and Supertest ownership, and document process setup and artifact cleanup.

Compare one Express route with PHP pseudocode

Write a short technical comparison that maps request method and path, input validation, application call, status code, JSON response, error boundary, and isolated test setup. Keep it as pseudocode or an isolated research artifact; do not maintain a second production server.

Current official references

Check current sources when installed tools or APIs differ from the lesson baseline:

Capacitor core runtime definitions — current getPlatform() contract
Capacitor 8 configuration — WebView and platform configuration
Capacitor Android guide — generated project and Android workflow
Capacitor development workflow — build, sync, and native testing order
Capacitor App plugin — Back and lifecycle behavior
Capacitor System Bars — system bars and Android inset fallback

Submission

Submission destination: Teams plus individual presentation rehearsal.

Submit one Teams message per pair. Include the private repository URL, merged Stage 4 pull-request URL, final verified remote main commit ID, path to docs/final-delivery.md, automated test counts and gate result, direct API summary, named browser summary, named Android target and WebView summary, sensitivity proof, four review observations and responses, clean-recovery result, handoff archive name, current limits, and contributor roles. Grant the teacher repository access before submission.

Each student submits a separate private 300–450 word reflection and a link or attachment for the individual presentation outline, fallback evidence index, and two rehearsal records. Keep individual reflection out of the shared repository. Submit through the teacher-approved system by the agreed deadline. The teacher’s official assessment instructions replace this practice submission when they differ.

Safe stopping point

Stop only at one of these recoverable boundaries:

final-delivery contract and two-day plan are committed;
platform mapping and focused tests pass;
visible runtime information passes on list and detail routes;
complete automated gate and sensitivity proof pass;
direct API and browser evidence is recorded and project processes are stopped;
Android evidence is recorded and the emulator or device state is known;
review response is pushed with affected checks repeated;
approved Stage 4 is merged and every contributor has synchronized;
clean recovery and archive inspection pass; or
one timed rehearsal is recorded with the next start state.

Before stopping, record:

What works: latest passing product, check, and evidence layer;
Branch and commit: exact branch plus current and evidence commit IDs;
Active requirement: one contract or evidence ID;
Process state: Express, Vite, preview, Android Studio, emulator or device, and exact stop action;
Review state: local, draft, ready, changes requested, approved, merged, or synchronized;
What remains: next unmet required result;
Next action: one command, file, route, test, review response, archive check, or rehearsal section;
Required setup: folder, dependencies, terminals, URLs, Android target, browser, permission, reviewer, and deadline; and
Safe rollback: last passing commit and generated outputs that can be rebuilt.

Do not stop with a controlled mutation, .only, .skip, unresolved merge, running project process you own, stale unsynced Android evidence, unexplained uncommitted source, archive containing excluded files, or presentation evidence that identifies another commit. The safe final state is clean synchronized main, a reproducible archive, stopped project processes, and a timed individual route that points to the accepted evidence.