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.

Firefox Unlisted Release Check, 2026-09-15

The later check used the managed HTTPS demo_tutorial on assela@rcmms (32fb3c99b35bcad284bc7b5db0630d95044fddcb), Firefox 153.0, geckodriver 0.37.0, Selenium 4.49.0, and an unsigned temporary installation of extension 0.1.0. This does not establish Mozilla signing or Firefox ESR compatibility.

  • The extension opened ordered Viewer, Editor 1, Reviewer, and Approver tabs in four distinct Firefox cookie stores. Their profile pages showed the matching tutorial_... usernames. Every identity survived reload. Signing out Viewer left the other three authenticated. A second ticket opened the same roles using the same four container IDs, with no duplicate identities.
  • A non-HTTPS origin, denied exact-origin permission, malformed ticket, unknown ticket, exhausted ticket, revoked ticket, and expired ticket each produced the intended safe rejection without partial role tabs. The browser permission request named only demo-tutorial.demo.rcmms.net.
  • A consumed one-time login URL returned 403 on replay after its initial 302 redirect. An unused token returned 403 at the server's three-minute manifest deadline plus 15 seconds. An earlier deadline-plus-two-seconds assertion failed without recording the response status, so near-boundary timing is not established by this check.
  • Extension local storage contained only lastOrigin, and the popup cleared the ticket field after launch. Dokku reported configured and computed nginx access logging as off; the effective nginx configuration contained two access_log off directives. A bounded 31-line app-log scan found no raw token paths, saved ticket codes, or account passwords, and one redacted token marker. This does not establish the contents of any external log store.
  • Owner-accepted residual risk: After a successful Viewer login, Firefox Places contained one token-bearing login URL and one visit. The token had already been consumed in this observed run, so replay failed. If the browser records a URL but does not finish consuming its token, another party with access to that URL could attempt to consume it within its three-minute lifetime. That scenario is inferred from the one-time-token design, not demonstrated here. On 2026-09-15 the owner directed that, if no small safe fix existed, this limitation should be documented and the release should proceed. The narrow history-deletion API would require broad browser-history access; replacing URL-based login with container-scoped POST is a larger server/extension change. No history fix is claimed for version 0.1.0.

Raw tickets, one-time URLs, passwords, and cookies are omitted from this record. These sessions test a visible temporary add-on, not a signed learner package. All test tickets were revoked, expired, or exhausted at the final safe operator check. No reviewer-access ticket or Mozilla submission was made at this check.

Firefox ESR Follow-up, 2026-09-15

The owner installed Firefox ESR 153.3.0 and standalone geckodriver 0.37.1. Visible ESR accepted the same unsigned 0.1.0 ZIP. Four role tabs again showed distinct containers and matching usernames; reload, one-role sign-out, and second-ticket container reuse passed. Malformed, unknown, and exhausted ticket attempts returned safe feedback without partial tabs. Local storage again contained only lastOrigin. Firefox Places counted four token-bearing login visits, so the owner-accepted history limitation also affects ESR. An initial profile probe raced an unfinished login redirect; the repeat waited for navigation and passed. All ESR test tickets were exhausted at the final safe operator check. This remains temporary-add-on evidence, not AMO-signed evidence.

Mozilla unlisted submission, 2026-09-15

A seven-day reviewer ticket (ID c26080ca-32e5-44bf-b957-137c50c20a9b, expires 2026-09-22 20:00 UTC, ten launches) gives Mozilla access to the synthetic HTTPS demo_tutorial. Its raw code is kept in the owner-private workstation ticket store and in reviewer-only AMO approval notes, never here. The notes explain exact-origin permission, four container roles, ticket transmission, and the accepted browser-history limitation.

web-ext sign submitted unlisted version 0.1.0 to AMO version 6488526. Mozilla validated the upload, although the initial two-minute approval wait timed out. Mozilla approved the version at 2026-09-15 20:06:18 UTC; the API now reports file status public. The authenticated XPI download contains Mozilla COSE and RSA signature metadata and has SHA-256 847d0294ce7ba8213455eb48172b33bf0a52e7716122f2fd7d012690b3f50e83. The signed XPI still requires the visible Firefox ESR container check before learner distribution.

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/.