# Conductor release validation

## Release-critical layers

The release gate uses five complementary layers:

1. Frontend unit and integration tests cover component rendering, visual authoring, JSON diagnostics, request templates, runtime state, actions, bindings, variables, failure recovery, and the deterministic MVP workflows.
2. Backend unit tests cover schema and semantic validation, authentication, encryption, proxy destination/header/redirect/transport/response policy, and safe logging.
3. Backend HTTP integration tests run an isolated server, SQLite database, and controlled upstream to cover health, CRUD, invalid-update atomicity, canonical round trips, all five authentication modes, proxy success/upstream/policy outcomes, history redaction/cleanup, and secret lifecycle.
4. Playwright browser tests exercise the real frontend and backend through Docker Compose using the controlled repository mock server. They cover the workflow launcher, dependent data, dashboard refresh/selection, save, reload, and rerun readiness.
5. The schema matrix, TypeScript checks, production builds, Docker restart/persistence, database backup/restore, and security regression checks prove packaging and operational behavior.

Passing automation does not replace proportional manual acceptance. Human verification remains required for usability, visual state, browser-visible redaction, and the complete six-workflow release checklist.

## Deterministic test environment

The release demo is `examples/project-definitions/valid-release-demo.json`. It uses only `http://mock-api:8787`, supplied by `examples/mock-server/conductor-mock-server.js` through the existing Compose override:

```bash
docker compose -f docker-compose.yml -f docker-compose.manual-test.yml up -d --build
npm run test:e2e
```

The override grants the backend only the exact internal origin `http://mock-api:8787`. The normal Compose definition remains default-deny and contains no internal exception.

## Automated commands

For v1.1.0, run with Node 24 (the production Docker build supplies it):

```bash
cd frontend
npm ci
npx tsc --noEmit
npm test -- --watchAll=false --runInBand
npm run build

cd ../backend
npm ci
npm test

cd ..
npm ci
npm run test:schema
docker compose -f docker-compose.yml -f docker-compose.manual-test.yml up -d --build
npm run test:e2e

docker build -f Dockerfile.production -t conductor:slice8-test .
npm run test:production
shellcheck scripts/production/*.sh scripts/release-image.sh scripts/test-production.sh
```

The backend integration suite binds isolated localhost ports. In restricted command sandboxes it may require explicit permission for local listening sockets.

## Production distribution gate

`npm run test:production` creates a uniquely named disposable Compose project and volume. It proves:

- production startup refuses absent keys;
- the image runs as the non-root `conductor` user with a read-only root filesystem;
- health, root frontend, and a published deep-link refresh are served from one port;
- a live WAL-mode database is backed up using SQLite's online backup facility;
- the archive manifest and checksums validate;
- destructive restore resets ownership/mode, becomes healthy, and recovers a marker record;
- cleanup removes the disposable container, network, volume, environment, and archive.

The v1.1.0 release uses one controlled publication path with immutable version and Git-SHA tags and OCI metadata for `linux/amd64`. The optional workflow can attach SBOM/provenance; do not claim attestations unless the published artifact was verified to contain them. ARM64 is not a supported release architecture. Anonymous source download, anonymous image pull, exact digest capture, and source/OCI-revision correlation are post-publication gates: they cannot be claimed before the final tag and image exist. If Gitea denies anonymous package pulls, the same release image must be published to the documented public fallback registry.

## Manual gate

Manual acceptance begins only after all automated commands, Docker restart and persistence, backup/restore, repository credential scan, and cleanup checks pass. The manual checklist must cover all six workflows in `MVP_SCOPE.md`, including all authentication modes and failure recovery, and record any accepted limitations or defects.

## SLICE11 additions

Run scripts/test-installed-apps.mjs with the compatible Social Scheduler source package. Verify fresh empty discovery, two independent apps, role/CSRF/API restrictions, callback privacy, encrypted connections, update/removal, corrupt-package rejection and restart persistence. The production lifecycle suite additionally deletes then restores installed app assets and recreates the container with its retained volume. Follow [Release publication](RELEASE.md) for exact source/image identity and anonymous download checks. The six original builder workflows have prior product-owner acceptance; SLICE11's new screens receive proportional browser and visual verification. Customer-VM migration is separately gated in SLICE13.