Demo Scripts

Owner(s): CrowdPM team | Last updated: 2026-03-08 | Status: Production

Demo Scripts

Purpose

This page provides presentation-ready demo flows that also function as acceptance checks. The most important principle is that the main demo should be reproducible without requiring physical node hardware.

Demo 1 — Local end-to-end smoke test (recommended core demo)

Goal

Demonstrate that a contributor can run the platform locally, sign in, trigger a seeded device flow, ingest PM2.5 data, and see the results on the map.

Preconditions

• local env files are configured;
• functions/.secret.local exists;
• pnpm dev is running;
• frontend loads successfully;
• tester can sign in with the local auth user.

Steps

1. Open the app at http://localhost:5173.
2. Sign in with the local emulator user.
3. Go to the User Dashboard tab.
4. Click Run Smoke Test.
5. Observe that the UI seeds device-123 and drives the pairing/activation flow.
6. Observe that an access token is minted and a measurement payload is submitted.
7. Switch to or inspect the Map tab.
8. Confirm the map auto-selects the seeded device, renders the resulting path, and exposes time-based playback state.
9. Open the Emulator UI at http://localhost:4000 for backend verification if needed.

Acceptance checks

• app loads locally without manual cloud-only dependencies;
• smoke test completes without a hardware device;
• ingest creates retained raw data and processed records;
• batch metadata is visible;
• map shows the route and timeline-driven playback behavior.

Optional backend verification during the demo

• Storage contains the ingest artifact under the expected ingest path;
• Firestore contains device/batch/measurement records;
• Functions logs show ingest and processing activity.

Demo 2 — API/health sanity check

Goal

Demonstrate that the backend is alive before or during a longer presentation.

Steps

Run from another terminal:

curl http://127.0.0.1:5001/demo-crowdpm/us-central1/crowdpmApi/health

Acceptance checks

• returns { "ok": true };
• confirms the Fastify HTTPS API is available through the emulator.

Demo 3 — Device-emulator-driven ingest follow-up

Goal

Demonstrate that an already-registered device can submit ingest again without re-running the full demo UI flow.

Suggested path

Use the repository’s device-emulator workflow after a successful pairing run.

Example pattern documented in the repo README:

pnpm device:pair -- --mode ingest --device-id <device-id> --key ./emu-key.json --api http://localhost:5001/demo-crowdpm/us-central1/crowdpmApi

Acceptance checks

• existing device credentials can be re-used for follow-up ingest;
• new batch data appears in the backend;
• owner/map views update accordingly.

Demo 4 — Demo-environment presentation

Goal

Demonstrate a hosted version of the platform after code review and successful deployment to the shared demo Firebase project.

Preconditions

• demo deploy completed successfully;
• required runtime secrets are configured;
• Firestore and Storage are provisioned in the demo project;
• the hosted app is reachable.

Suggested presentation sequence

1. Show the hosted landing/app shell.
2. Explain the role separation: public vs owner vs moderator/admin.
3. Walk through either a pre-seeded data view or a controlled ingest path.
4. Show the map, batch visibility, and moderation-aware framing.
5. If relevant, mention the same core flow is reproducible locally with emulators.

Final presentation checklist

Before any graded or stakeholder-facing demo:

• verify branch/commit being shown;
• verify correct Firebase project/environment;
• verify secrets and env values are set;
• verify the smoke test works if it will be used live;
• prepare a fallback path using already-seeded data;
• prepare one short backend sanity command (/health) in case UI troubleshooting is needed.

Common demo failure points

• missing functions/.secret.local locally;
• wrong VITE_API_BASE target;
• wrong Firebase project alias during hosted deployment;
• Firestore or Storage not provisioned in a new demo project;
• outdated docs or stale local state from previous runs.

Demo narrative recommendation

The cleanest short narrative is:

1. secure onboarding;
2. durable ingest;
3. processed/queryable data;
4. moderated/public separation;
5. map-based exploration.

That tells the story of the platform more clearly than focusing only on UI screens.