# 1.0.0 Release Test Matrix The release test matrix is the minimum validation surface for a production `1.0.0` candidate. It is intentionally explicit so release readiness can attach reviewable evidence instead of relying on conversational sign-off. Detailed release-blocking and extended E2E batteries are defined in [End-to-End Test Batteries](e2e-test-batteries.md). This matrix lists the current release commands; the battery catalog defines the required growth path for installed CLI, temporary workspaces, runtime delegation, browser, recovery, security, and provider-backed coverage. ## Command ```bash npm run release:matrix -- --json ``` Use the JSON output as the release-manager checklist and attach the final execution summary as release test matrix evidence before running: ```bash orchestra release check --json ``` ## Tag And Publish Ownership For normal releases, the release commit contains the version bump and CI owns tag creation. Do not create or push release tags locally. Push the committed version bump to `main`; the `Create release tag` workflow validates that the tag equals `v`, creates the annotated tag, creates the GitHub Release, and triggers `publish-npm.yml`. If the remote tag already exists, do not move it. Use the next patch or prerelease version unless an explicit break-glass release decision documents why manual intervention is required. The npm publish workflow supports two authentication modes: - `auth_mode=token`: requires `NPM_TOKEN` from an npm account with read-write access to `@jterrats/open-orchestra` and CI publish permission that can bypass 2FA. - `auth_mode=trusted`: uses npm Trusted Publishing/OIDC. Configure the package in npm with organization/user `jterratsdev`, repository `open-orchestra`, workflow filename `publish-npm.yml`, and no environment before running this mode. A `404 Not Found` response on `PUT https://registry.npmjs.org/@jterrats%2fopen-orchestra` for an existing scoped package usually means the token is missing, was generated by a user that is not a package maintainer, or lacks publish permission for the scope. `EOTP` means the token is accepted but cannot bypass 2FA for CI publishing; use a granular token with bypass 2FA enabled or switch to Trusted Publishing. The workflow validates `npm whoami` and scoped package access before token-based publishing so permission failures are visible without exposing the token. If the preflight fails at `npm whoami` with `E401 Unauthorized`, regenerate `NPM_TOKEN` from the npm maintainer account and store the raw token value as a GitHub Actions secret. ## Required Environments - `ubuntu-latest` with Node `>=22` and npm. - `macos-latest` with Node `>=22` and npm. - `windows-latest` with Node `>=22` and npm. ## Required Flows | Flow | Command | Evidence | | ---------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Source quality gate | `npm run precommit` | lint, typecheck, secret scan, security audit, build, unit tests, workflow validation | | Secret scanning gate | `npm run secret-scan` | Gitleaks scan with `.gitleaks.toml` when the binary is installed; lightweight fallback for offline local development | | Duplicate-code gate | `npm run duplicates` | jscpd duplicate-code report with generated/runtime outputs excluded and collection-standards follow-up for duplicated domain lists | | Task split guard | `node --test test/task-split-assessment.test.js` | PO/BA functional oversize, Architect technical complexity, routine small-task non-blocking behavior, and markdown evidence rendering | | Sonar quality gate | GitHub Actions: `Sonar` or local SonarQube import | conditional quality gate for duplication, bugs, code smells, maintainability, coverage readiness, and security hotspots when a Sonar provider is configured | | Browser E2E | `npm run test:e2e` | Playwright checks map scenario acceptance criteria to visible UI state, API persistence, artifact attachment, responsive layout, and recovery behavior | | Installed package init | `npm run test:e2e:init` | Installed CLI checks map scenario acceptance criteria to stdout, stderr, exit code, filesystem state, JSON contracts, evidence records, and release-readiness outcomes | | Runtime manual queue | `npm run test:e2e:runtime` | Temporary-workspace runtime checks prove manual spawn requests queue under delegate pressure and expose queued artifacts through runtime sessions | | Public site build | `npm run site:build` | production site build | | Release readiness | `orchestra release check --json` | `releaseReadiness` and `gaReadiness` report | | Package contents | `npm run package:validate` | package file list includes bin, dist, web console, site assets, docs, rules, skills, metadata, and changelog | | Performance budgets | `npm run performance:bench -- --json` | CLI and web API timings on a synthetic large workspace | ## Network Policy The default release matrix is offline-friendly. Provider and tracker tests that need network access must honor `SKIP_NETWORK_TESTS` and report skipped status instead of failing offline CI. Sonar is conditional because it requires a configured provider and token. SonarCloud automatic runs should be intentionally enabled with `SONAR_CLOUD_ENABLED=true`; private or large repositories can use local or self-hosted SonarQube instead. When configured, a failing Sonar quality gate blocks release on new-code quality after findings are triaged as fix-required, accepted risk, false positive, tool limitation, or deferred debt. When unavailable or offline, release evidence must state that Sonar was skipped and attach the local quality gates that ran instead. The duplicate-code gate is local and CI-friendly after dependencies are installed. When it reports copied domain lists, command matrices, providers, roles, statuses, fixtures, selectors, or validators, remediation should use the `collection-standards` skill and extract a typed source of truth.