Pull-request acceptance and release process

OBLITERATUS separates contributor feedback, maintainer acceptance, canonical integration, and release certification. A green pull-request check is necessary, but it is not by itself an acceptance or release decision.

The enforced workflows and machine-readable policies remain authoritative. This document explains how maintainers apply them.

Pull-request states

Reviewable: the exact pull-request head is signed, conflict-free, and green in the contributor-facing checks. Relevant behavior has focused coverage and the description identifies tests not run, risk surfaces, and evidence limits.
Accepted: a maintainer audits that immutable head SHA for correctness, research integrity, security, compatibility, documentation, and applicable policy/risk-map changes. New commits invalidate the audit and require the new head to be checked.
Integrated: the accepted head is merged with the repository's configured merge-commit method. Squash and rebase merges are not used. The resulting canonical main commit must have a forge-verified signature, and its post-merge CI must pass before it can become a release candidate.
Release-certified: an exact signed v* tag on a clean canonical commit has passed every required release gate and its emitted source snapshot and evidence have been independently verified.

Maintainers may add test depth or hardening in separately attributable signed commits before acceptance. Thresholds, assertions, required jobs, or risk mappings must never be weakened merely to merge a pull request.

Acceptance criteria

A pull request cannot be accepted while any of these conditions applies:

its reviewed head SHA differs from the current head;
a commit lacks a verifiable signature;
required checks are pending, failing, stale, or attached to another SHA;
relevant behavior has no meaningful test or contract coverage;
review threads, conflicts, unexplained generated files, unrelated changes, or unaddressed trust-boundary risks remain;
research or performance claims exceed the supplied reproducible evidence;
dependency, workflow, policy, documentation, or compatibility effects are not included in the same reviewable change.

The fast pull-request lane is deliberately narrower than the release suite. It establishes review readiness without shifting release-depth work to contributors.

Release candidate preparation

After all accepted work is merged, maintainers:

reconcile the hosted pull-request and issue queues;
prune merged branches and confirm main is clean and synchronized;
verify the canonical merge signatures and post-merge CI results;
run the exhaustive local or hosted readiness suite against the exact candidate;
update the project version and create a new signed annotated version tag.

Tags are immutable audit records. A failed candidate is not moved, deleted, or reused. It remains unpublished, and the corrected candidate receives a new patch version and a new signed tag.

Exact-tag release certification

Pushing a v* tag runs the exhaustive release workflow against the tagged commit:

Python 3.10, 3.11, and 3.12 tests, import/CLI smoke checks, repository and branch coverage floors, critical-file floors, mature CPU-scope policy, and touched-module no-regression comparison;
deterministic order and hash-seed repeats plus the bounded selective mutation score gate;
Windows checkpoint contracts;
lock, workflow, package, secret, vulnerability, license, and supply-chain policy;
creation of exactly one deterministic git archive source ZIP, a digest-bound CycloneDX SBOM, SHA256SUMS, SLSA provenance, and Sigstore bundles.

The package job creates the source ZIP once. Downstream validation and publication must reuse those exact bytes; rebuilding an equivalent archive is not acceptable. OBLITERATUS releases do not publish wheels, source distributions, executables, or compiled libraries.

Conditional evidence and publication

Before publication, maintainers manually run the applicable hosted software gates against the exact tagged commit, including the pinned model/evaluation, disposable network-service, and operator-UI gates. Hardware or credential-bound gates run only when their trusted prerequisites are available. An unselected gate is not positive support evidence, and an approved waiver blocks the associated support claim.

Publication occurs only after:

the complete exact-tag workflow succeeds;
the source ZIP checksum, SBOM binding, archive contents, and repository attestations are independently verified;
applicable conditional evidence is successful and fresh;
a draft release contains only the tested source ZIP and its checksum, SBOM, and attestation evidence, with matching digests.

Publishing triggers the conditional workflow again. That release-event run must also finish successfully and is retained as the final release record.

See Supply-chain policy for artifact verification and Conditional test operations for selection, freshness, runner isolation, and waiver semantics.

5.1 KiB Raw Blame History