Demo environment acceptance testing

This is developer and release-validation documentation. Routine administration is in Managed demo environments.

Document responsibility

This document is the source of truth for owner-authorized public demo lifecycle, infrastructure, interruption, secret-canary, and release-validation procedures. The broader behavioural model links to this separate acceptance layer from the user journey catalogue without duplicating the commands or evidence requirements below.

Limited client preview readiness

A limited client preview is permitted before full operational-readiness work only as a time-boxed, supervised evaluation using synthetic data. It is not a pilot, production release, capacity claim or commitment to retain entered data. Start with three to five identified participants.

Complete and record these steps before granting access:

  1. Merge the reviewed candidate into development, record the exact commit SHA, and deploy only that commit.
  2. Use an isolated demo database and media directory. Confirm that reset and deletion operations target only the demo. Do not copy production, client, personal, confidential or authoritative data into it.
  3. Validate production-style configuration: DEBUG=False, HTTPS, expected hosts and trusted origins, proxy headers, secure cookies, independent secrets and no development credentials.
  4. Create temporary, attributable, least-privilege viewer, editor, reviewer and approver accounts. Avoid public self-registration and record an access expiry date.
  5. Seed a small, understandable synthetic dataset with prepared examples for the workflows that will be shown. Avoid unusually complex 500-vertex editing scenarios while the recorded precision-performance overruns remain open.
  6. Run deployed smoke acceptance for login/logout, dataset selection and access boundaries, map loading, parcel inspection, draft creation, rejection and correction, review, approval, split/merge and precision editing. Include upload/export only when those functions will be demonstrated. Verify that each role is denied actions outside its authority.
  7. Confirm application and database logs are accessible and contain no secrets. Record restart, account-disable, reset and rollback procedures. Either take a tested backup or state explicitly that the environment is disposable and has no recovery or retention promise.
  8. Give participants evaluation-only instructions covering supported browsers, account assignment, prohibited data, possible resets, known limitations, opening and closing dates, and the feedback/support channel.
  9. Monitor errors and use during the preview. At the agreed end date, disable accounts, preserve the agreed non-sensitive evidence and feedback, and reset or remove the disposable environment.

After saving the JSON output from demo-manager --json status, run the local, non-mutating machine preflight:

ops/demo/demo-preview-preflight demo_client_preview \
  --status-file /private/path/demo-client-preview-status.json \
  --release APPROVED_40_CHARACTER_COMMIT \
  --participants 3 \
  --expires-on YYYY-MM-DD \
  --recovery disposable-no-recovery

Use --recovery tested-backup only when that backup has actually been restored and verified. The preflight reads the captured status and the owner-private local credential bundle. It does not connect to or modify the server, display account secrets, run deployed smoke acceptance, or establish full preview readiness. Its JSON report lists the manual gates that still require recorded evidence.

The real Firefox extension/container procedure below must pass before offering the multi-account launcher. Ordinary supported-browser access does not depend on that launcher acceptance.

If participants need persistent or meaningful data, unsupervised operation, production-capacity assurances or a recovery commitment, do not use this limited preview exception. Complete the operational readiness and recoverability package, including dependency/schema readiness, monitoring, database and media restore, deployment recovery and operator runbooks, before granting that level of access.

Package 2 Firefox Container Checkpoint, 2026-09-07

Outstanding environment acceptance, not a pass. The inspected extension manifest is version 0.1.0 (Manifest V3, minimum Firefox version 140.0). Playwright Firefox 151.0 launches and runs ordinary page journeys, but no real extension/container acceptance was executed. Those sessions and the controlled one-time-login page test do not establish container or cookie-store isolation.

The verified local disposable E2E configuration has LMSTOOL_DEMO=False and DEMO_MULTI_ACCOUNT_LAUNCHER_ENABLED=False. No owner-authorized managed HTTPS demo and short-lived ticket were supplied for this acceptance run. The system firefox --version probe also failed to report a version within its bounded probe, emitting Snap mount-namespace diagnostics; no system repair was attempted. A display is configured, so absence of a display is not asserted as a blocker. The installed Playwright browser is not evidence that the supported visible ESR and extension environment are ready.

Owner-run procedure, using an already authorized disposable managed demo:

  1. Confirm the demo's exact HTTPS origin, enabled launcher flags and safe status; create a short-lived viewer/editor/reviewer/approver ticket using the existing operator workflow. Do not provision or deploy a new demo as part of this package.
  2. Use a supported visible Firefox ESR and record its actual version. Load tools/firefox-demo-launcher/manifest.json through Load Temporary Add-on at about:debugging#/runtime/this-firefox if the documented WSL debugging-port route fails. This is development acceptance, not a signed learner release.
  3. Enter the origin and ticket, approve only that origin, and verify four ordered role tabs. Record the distinct container IDs/cookie-store IDs and intended account names, never cookie values, tickets or token-bearing URLs.
  4. Reload every tab. Switch or sign out one role and confirm that the remaining containers retain their own authenticated identities. Launch a second ticket and confirm matching containers are reused rather than duplicated.
  5. Verify rejected origin permission, malformed/invalid/revoked/expired tickets, consumed one-time-token replay and unused-token expiry after three minutes. Confirm safe feedback, no new unintended authenticated session and no partial launch on failure. Use a separate authorized ticket for each destructive revocation case; reset is a separate owner-controlled lifecycle operation.
  6. Inspect extension storage and safe history/server/operator diagnostics for absent ticket/token/password persistence. Record date, demo identity, browser and extension versions, each result and owner approval here. Retain raw authenticated evidence privately.

Until these steps execute, independent containers, reload/sign-out isolation and the prescribed real-extension failure/expiry cases remain unverified. This explicit blocker does not convert any required browser journey to optional.

Public disposable acceptance server

Acceptance uses a public disposable server because real DNS, Dokku deployment, Let's Encrypt, PostgreSQL/PostGIS, mounted storage, and HTTPS must be exercised. The server must contain no production applications, credentials, data, routes, webhooks, or external-write integrations.

The workstation needs SSH access as a named administrator with passwordless sudo, plus a public key registered with Dokku. The server needs Dokku 0.38.22 or later with equivalent named-storage behavior, PostgreSQL/PostGIS, an empty protected demo_template, a private demo storage root, wildcard public DNS, ports 80/443, and the Dokku Let's Encrypt plugin.

No registry, provisioner, installed helper, server checkout, release mirror, delegated SSH account, or restricted-command sudo rule is used. The named administrator instead has the unrestricted passwordless sudo access documented in the installation guide.

Automated local tests

From the repository root:

/home/assela/python/.venv/bin/python -m unittest discover \
  -s tests/demo/unit -t . -p 'test_*.py'

/home/assela/python/.venv/bin/python -m unittest discover \
  -s tests/demo/integration -t . -p 'test_*.py'

Run the targeted Django tests with the disposable PostGIS test settings described in specs/016-simplify-demo-management/quickstart.md.

Owner-authorized live lifecycle

Use only the reserved canonical name demo_acceptance. Obtain explicit project-owner approval before any live/destructive run. Validate create, all six logins, administrator/workflow separation, two-editor attribution, review and approval, viewer mutation denial, list, status, update, reset rotation, repeated delete, missing-anchor cleanup, conflicting-marker retention, HTTPS, and exact deployed commits using the quickstart.

Interruption matrix

The acceptance-only failpoint mechanism is disabled by default. It activates only when all three conditions hold:

  • DEMO_ACCEPTANCE_APPROVED=yes and the runner's --approved option are present;
  • the exact target is demo_acceptance; and
  • the stage is one of the ten allowlisted post-stage boundaries.

Run from an interactive workstation terminal. Create/reset generate credentials only after local and remote locks succeed, and credentials --show deliberately requires a terminal:

DEMO_ACCEPTANCE_APPROVED=yes \
tests/demo/acceptance/run_interruption_matrix.py \
  --approved \
  --host assela@demo-server.example.org \
  --release APPROVED_40_CHARACTER_COMMIT

For every stage the runner expects create to fail, then performs confirmed deletion twice. After the matrix, create the same name normally to prove reuse. The failpoint selector is non-secret and may be passed to the transient coordinator; application and database secrets must remain absent from argv, environments, output, and journald.

Secret-canary review

Use unique canaries in the instrumented fake tests. Inspect workstation and remote argv/environment snapshots, Git/Dokku output, PostgreSQL diagnostics, application command output, lifecycle text/JSON, and:

ssh assela@demo-server.example.org \
  sudo -n journalctl -t lmstool-demo-manager --since today

No canary or complete credential-bearing URL may occur. Confirm the temporary six-account bundle is absent from remote storage after success and injected failure. Test failures before credential request, after provisioning, before acknowledgement, and after acknowledgement; no failed operation may report healthy or expose a stale bundle.

Record the commands, dates, test counts, retained resources, certificate delays, responsiveness results, and project-owner approval under specs/016-simplify-demo-management/evidence/.