You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Graduate only the supported CLI + GitHub Action + disposable QEMU/KVM validation boundary to stable v0.4.0. The API/UI demo, runtime loading, agent, registry, SaaS, Firecracker, and virtme-ng remain experimental and explicitly out of scope.
This issue is the audit trail and checklist. Manual runs are shakeouts only and do not count as scheduled graduation campaigns. The earlier Yusuf-dependent review contract was superseded by the solo-maintainer design merged in #114; historical comments remain below as audit history.
Solo-maintainer release controls
main requires strict status checks, admin enforcement, conversation resolution, and blocks force-pushes/deletion, with zero required human approvals
production-release has no human reviewers, a 15-minute wait timer, no admin bypass, and an exact v* deployment policy
Active immutable v* tag ruleset blocks update/deletion and has no bypass actors
Tag workflow can only build, attest, sign, and stage a private draft
Separate workflow_dispatch promotion must run on the exact tag and re-verify the candidate run ID, full commit, digest, typed confirmation, draft assets, checksums, attestations, Sigstore signatures, image version, and release channel
Live scripts/check-production-environment.sh passes in solo-maintainer mode
Immutable annotated v0.4.0-rc.3 tag resolves to cba1e09537f2e05e4ba7278efdb5c2d044d1889b
Candidate run 30552866250 passed release quality, amd64/ARM64 build, native ARM64 execution, positive VM validation, classified-negative VM validation, multiarch image/version verification, signing, provenance, SBOM, and evidence attestation
Candidate evidence binds run 30552866250, attempt 1, the exact tag/commit, prerelease channel, and image digest sha256:842ebbc5746dcfcf98823407a762bdf379e24beb8ea20941ff77f9a74a1a2ac6
Exact-input promotion run 30553637272 waited 15 minutes, re-verified all bindings, and succeeded
GitHub release is a public prerelease with ten verified assets
GHCR RC tag is amd64+arm64 at the evidence digest; stable 0.4 was not created and latest stayed at sha256:4858cedde87681b1af4876bb8c869c7c1df0f5721764448a47042fe616e65102
Pre-campaign operational work
Deploy RC3 to the public demo at bpfcompat.kernelguard.net while keeping it visibly Technical Preview and outside the production claim
Verify public /livez, /readyz, HTTPS/security headers, KVM, watchdog, runtime-execute disabled, exact version/commit/checksum, and retained rollback binary
Execute and record a deliberate release-promotion rollback drill using immutable before/after image digests, exact operator, commands, elapsed recovery, signature/provenance/version verification, and [bpfcompat-rollback-drill:v1]
Exercise and record the promotion incident path, proving an invalid deployment remains fail-closed
Four scheduled campaigns
Only schedule events from .github/workflows/latest-kernel-compatibility.yml count. Each must be unique, chronological, 6–8 days apart, complete within 120 minutes, have target p95 <= 12 minutes, and contain zero infra_error targets.
Campaign 1 — scheduled run 30790938510 on 2026-08-03
Campaign 2 — Monday 2026-08-10 03:21 UTC
Campaign 3 — Monday 2026-08-17 03:21 UTC
Campaign 4 — Monday 2026-08-24 03:21 UTC
For every run, record the workflow URL, artifact name, commit SHA, start time, report SHA-256, target status summary, infrastructure-error count, p95 target duration, and total workflow duration. Any supported-boundary behavior change after the window starts requires a new RC and restarts the window; documentation/release-tooling-only changes do not.
Independent ecosystem and consumer evidence
Capture the first successful scheduled Falco run after falcosecurity/libs@f6fed8e / falcosecurity/libs#3061
Verify the Falco artifact hash and expanded RHEL-family profile coverage
Run clean-install, source-build, Action, container, and external-consumer canaries against RC3
Verify 24-hour and 72-hour post-publication canaries; investigate every failure before graduation
Post-v0.4 ecosystem follow-up (not a v0.4 gate)
Confirmed adoption is a 1.0 ecosystem-readiness goal, not a technical prerequisite for the supported v0.4 boundary and not a substitute for its evidence.
Invite at least two controlled pilot evaluations through the adopter issue form without claiming adoption or endorsement
Record any confirmed public pilot only with explicit listing permission in ADOPTERS.md
Stable-release gate
Download the four campaign artifacts, expanded Falco artifact, candidate evidence, rollback note, incident note, and canary evidence into one private evidence directory
Build readiness/input.json with exact relative paths and SHA-256 values plus the solo operator confirmation marker
Run scripts/production-readiness-report.sh readiness/input.json readiness/bpfcompat-0.4.0-readiness.md without the test-only attestation bypass
Commit docs/releases/bpfcompat-0.4.0-readiness.{md,json} in the final release PR
Set stable_version: 0.4.0, release_version: 0.4.0, and release_channel: stable
Tag only the reviewed merge commit, complete the exact-input wait-gated promotion, and publish
Verify release assets, signatures, SBOM, provenance, image aliases, installer defaults, Action consumption, and stable canaries at 24h and 72h
Earliest defensible stable release: 2026-08-24/25, only if every gate passes and the campaign window is not reset.
Objective
Graduate only the supported CLI + GitHub Action + disposable QEMU/KVM validation boundary to stable
v0.4.0. The API/UI demo, runtime loading, agent, registry, SaaS, Firecracker, and virtme-ng remain experimental and explicitly out of scope.This issue is the audit trail and checklist. Manual runs are shakeouts only and do not count as scheduled graduation campaigns. The earlier Yusuf-dependent review contract was superseded by the solo-maintainer design merged in #114; historical comments remain below as audit history.
Solo-maintainer release controls
mainrequires strict status checks, admin enforcement, conversation resolution, and blocks force-pushes/deletion, with zero required human approvalsproduction-releasehas no human reviewers, a 15-minute wait timer, no admin bypass, and an exactv*deployment policyv*tag ruleset blocks update/deletion and has no bypass actorsworkflow_dispatchpromotion must run on the exact tag and re-verify the candidate run ID, full commit, digest, typed confirmation, draft assets, checksums, attestations, Sigstore signatures, image version, and release channelscripts/check-production-environment.shpasses insolo-maintainermodeactions/attest-sbomwrapper migrated to pinnedactions/attestin ci: migrate SBOM attestations to actions/attest #116; all 10 PR checks and post-merge workflows passedRelease candidate
v0.4.0-rc.3tag resolves tocba1e09537f2e05e4ba7278efdb5c2d044d1889b30552866250, attempt1, the exact tag/commit, prerelease channel, and image digestsha256:842ebbc5746dcfcf98823407a762bdf379e24beb8ea20941ff77f9a74a1a2ac60.4was not created andlateststayed atsha256:4858cedde87681b1af4876bb8c869c7c1df0f5721764448a47042fe616e65102Pre-campaign operational work
bpfcompat.kernelguard.netwhile keeping it visibly Technical Preview and outside the production claim/livez,/readyz, HTTPS/security headers, KVM, watchdog, runtime-execute disabled, exact version/commit/checksum, and retained rollback binary[bpfcompat-rollback-drill:v1]Four scheduled campaigns
Only
scheduleevents from.github/workflows/latest-kernel-compatibility.ymlcount. Each must be unique, chronological, 6–8 days apart, complete within 120 minutes, have target p95 <= 12 minutes, and contain zeroinfra_errortargets.For every run, record the workflow URL, artifact name, commit SHA, start time, report SHA-256, target status summary, infrastructure-error count, p95 target duration, and total workflow duration. Any supported-boundary behavior change after the window starts requires a new RC and restarts the window; documentation/release-tooling-only changes do not.
Independent ecosystem and consumer evidence
falcosecurity/libs@f6fed8e/ falcosecurity/libs#3061Post-v0.4 ecosystem follow-up (not a v0.4 gate)
Confirmed adoption is a 1.0 ecosystem-readiness goal, not a technical prerequisite for the supported v0.4 boundary and not a substitute for its evidence.
ADOPTERS.mdStable-release gate
readiness/input.jsonwith exact relative paths and SHA-256 values plus the solo operator confirmation markerscripts/production-readiness-report.sh readiness/input.json readiness/bpfcompat-0.4.0-readiness.mdwithout the test-only attestation bypassdocs/releases/bpfcompat-0.4.0-readiness.{md,json}in the final release PRstable_version: 0.4.0,release_version: 0.4.0, andrelease_channel: stableEarliest defensible stable release: 2026-08-24/25, only if every gate passes and the campaign window is not reset.