# Local HTTPS production-web regression

Phase 6 milestone 26 adds a repeatable local HTTPS profile for the complete staff browser workflows. It uses the actual standalone production web build, the existing disposable synthetic API/database fixture and a loopback TLS proxy. It does not deploy a server, activate an integration, contact a real SMTP provider, issue a public certificate or exercise a production database.

## Run from the full development checkout

Install the project's existing locked dependencies and local test tools, including OpenSSL and the browser used by Playwright. Stop other test runs using ports 3100/8100. Build first:

```sh
npm run build:web
npm run test:web -- --config playwright.production.config.ts
npm run test:web -- --config playwright.production-delivery.config.ts
npm run test:web -- --config playwright.production-dispatch.config.ts
```

Run the profiles sequentially: each prepares a fresh isolated fixture database. Delivery-report and synthetic-dispatch fixtures remain separate from the baseline mailbox tests. The API runs in its explicit test environment with synthetic integration settings, not production scanner/provider configuration. The web server runs with `NODE_ENV=production`, the normal Secure/HttpOnly/Strict cookies, the fixed HTTPS application origin and the enforced production script policy.

The full checkout includes tests and test runners that are intentionally absent from the server deployment archive. The packaged production application and staging deployment files do not depend on this test TLS proxy.

## Isolation and certificate handling

`scripts/start-browser-production.cjs` creates a private temporary directory, copies the standalone web artifact and assets, and generates a fresh one-day self-signed RSA certificate restricted to `127.0.0.1`. The certificate is not a CA. The key and certificate remain under the ignored `.local/production-browser-*` directory with restrictive permissions. No trust-store modification or public issuance is performed.

The HTTPS proxy listens only on `127.0.0.1:3100`. The standalone process uses an ephemeral loopback HTTP backend port. Proxy headers fix the public host/protocol to the test HTTPS origin, and response bodies/headers—including cookies, CSP and download sandbox policies—pass through unchanged. Existing listeners are not reused or terminated. Startup failures exit; normal shutdown terminates the owned child, closes proxy connections and removes its temporary copy/key/certificate. Forced process kills can leave a private temporary directory for later explicit cleanup.

Certificate-error acceptance is scoped to the Playwright test contexts and readiness request for this disposable endpoint. It does not modify application TLS verification, environment-wide trust or the operating system. A dedicated regression confirms that a fresh strict context rejects the certificate and an explicitly configured context accepts it. An anonymous accepted-TLS context must still receive 401 from protected endpoints.

`tests/support/web-origin.ts` selects only fixed HTTP/HTTPS loopback origins. Default development tests keep HTTP; the production config sets the test HTTPS flag for its workers. Fixture Origin headers, page routes and separate administrator/anonymous contexts use this shared selection. No test flag disables Secure cookies, authorizes cross-origin requests or changes business permissions. The default Playwright matcher selects `.spec.ts` browser files; Node/mobile unit tests keep their separate commands.

## Evidence and limits

The HTTPS-specific tests verify a secure browser context, Secure/HttpOnly/Strict session cookies, authenticated browser and API-helper requests, rejection of an HTTP downgrade in the Origin header, logout invalidation and scoped certificate acceptance. The existing workflow and script-policy suites provide the broader regression evidence; see [VALIDATION.md](VALIDATION.md) for final counts/results.

This validates local production-web behavior over TLS. It does not establish public certificate trust/renewal, actual Caddy behavior, DNS/firewall setup, Linux images, PostgreSQL deployment, scanner acceptance, load/capacity, live delivery, physical-device behavior or staff acceptance. Those remain the separate gates in [RELEASE-READINESS.md](RELEASE-READINESS.md). Keep the existing public PHP website and hosting unchanged.