v0.4.23 release requirements

Status: implementation in progress; no complete runtime approval exists.

scripts/release-requirements.json is the versioned inventory of required proofs. The released v0.4.22 baseline remains required. v0.4.23 adds public contracts, configuration policy, browser/terminal, remote Docker, remote Podman live Console integration, and Core-only bootstrap on rootless Docker and Podman. Counts are derived from the release's selected inventory; a successful baseline alone cannot approve the new release.

Each requirement names its evidence schema, executing jobs and consumer roles. The inventory is read from the exact candidate, not from a mutable default branch. Missing or duplicated definitions fail closed. Coverage and approval receipts bind the requirement digest as well as the candidate and demo pin.

Evidence reuse

Reuse hashes product code, tests, schemas, authentication/policy, build inputs, the requirement inventory and evidence tooling. Workflow job execution inputs include static/reusable call arguments, runner declarations, timeouts, environments, build steps and evidence-generation steps. Only scheduling edges and matrix fan-out are omitted from this comparison. A runner or verifier change therefore requires new evidence even when a job keeps its display name.

Original successful child-job manifests remain immutable and retain their source SHA, demo pin, run, attempt and archive digest. A newer compatible failed, cancelled or artifact-less attempt blocks fallback to older success. Missing proofs remain pending. Source-only checks never substitute for runtime proof.

Publication handoff

For v0.4.23, scripts/release-handoff.py permits only the final changelog, roadmap, release index, release notes and release audit prose to change after validation. Workflow, runtime-image, verifier, build, policy/auth, contract, consumer pin and test changes are execution changes and require revalidation. The release publisher derives its required count from the tag's inventory and re-authenticates the approved evidence origins.

Integration completion boundary

The three Core-only static integration jobs are wired to the candidate-owned pending requirement list. They check public schema/type drift, shared organization configuration/policy resolution, and HTTP/browser-origin/terminal contracts with race detection. Their original JSON test logs and requirement-bound manifests are retained for 90 days. Empty or skipped test selections cannot produce a successful manifest. Their qualification scope is Core source contracts; they do not establish an actual browser/issuer/PTY or remote lifecycle journey.

The remote Docker/Podman and live Console jobs are scheduled; their complete production qualification remains pending. Planning refuses to omit required integration origins. Consumer verification authenticates exact-source push runs, their latest attempts, qualification jobs, artifact archives and production-scope receipts. Partial/test-authority receipts and newer failed attempts prevent approval. Console/Connector source and build pins bind each integration proof to the exact Core and Demo candidate. No v0.4.23 tag is authorized by this document.

Both companion repositories are public. The active pin configuration is docs/releases/v0.4.23.consumer-pins.json, selected by BASEHARBOR_PUBLIC_EVIDENCE_FILE, using baseharbor.consumer-evidence-pins/v1. GitHub Actions supplies its ordinary github.token as GH_TOKEN. The verifier independently requires public repository visibility before reading source, Actions metadata and digest-bound archives. No custom private-evidence secrets are required for this topology. The public access preflight has passed; that access result does not qualify incomplete product journeys.

The gates map binds each required consumer role to its trusted repository, exact commit and .github/workflows/release-integration.yml. Public integration manifests contain consumer_commitments: SHA-256 commitments of those canonical JSON bindings. Credentials and protected runtime payloads are excluded.

Each qualification job is named Integration · <full gate id> and retains a root manifest.json in private-integration-<gate with slashes replaced by hyphens>-<run>-<attempt>. The existing baseharbor.private-integration-evidence/v1 schema and artifact names remain compatible despite public repository visibility. The receipt binds repository, consumer/Core/demo commits, role, gate, workflow run/attempt, job and build digest. It requires successful execution and owned cleanup, explicit production authority, release eligibility and every gate-specific qualification. The trusted producer and complete native Application journeys still need qualification; primitive/read/terminal/provider receipts cannot satisfy this release boundary.

Core installation qualification

The #810 addition requires two explicit runtime proofs: integration/docker/core-bootstrap and integration/podman/core-bootstrap. They verify Core-only setup without a repository, both machine-role defaults, mandatory SQL/Secrets/Identity readiness, stable installation identity on retry, protected credential output and owned cleanup. Their runtime host must actually report rootless mode; source-only tests or skipped acceptance tests cannot approve these requirements. Original JSON test logs are retained for 90 days. The runtime tests retain actual per-service and simultaneous Core memory samples, native image IDs/limits, host memory/swap/PSI, a sampled startup/convergence peak and an idle window stable within 10% for at least 30 seconds. Native runtime memory/cache accounting and observation timestamps are explicit; these are topology-specific observations, not a universal minimum.

This addition does not qualify resource calibration, private consumers or remote application lifecycle. Those proofs remain independently required before release.

Authenticated consumer gate scheduling

The public pre-release workflow schedules all three consumer-dependent gates: integration/docker/remote-target, integration/podman/remote-target and integration/static/live-console. These verification jobs do not start additional runtime runners. They authenticate the trusted producer's exact source, newest push run and attempt, qualification job, archive digest, complete production journey and successful owned cleanup. A source-only or partially qualified receipt fails the gate. Final approval independently authenticates the same origins.

The public pin file and normal workflow token are the active access path. The optional private-repository compatibility path accepts either owner-only BASEHARBOR_PRIVATE_EVIDENCE_FILE or BASEHARBOR_PRIVATE_EVIDENCE_JSON, using baseharbor.private-evidence-pins/v1 and BASEHARBOR_PRIVATE_EVIDENCE_TOKEN. Exactly one configuration source is allowed. Private identifiers and archives remain excluded from public evidence. A failed rerun removes stale successful receipts and retains a safe failure code.

A dedicated Source Preflight checks source and Actions access without granting release approval. The current public configuration also downloads a digest-bound archive to verify actual evidence access. Ordinary source branches do not require private credentials. Complete trusted producer journeys and final source pins remain prerequisites for release.