Quality and Security Harness

voiage treats repository automation as a release surface. The local harness and GitHub workflows therefore validate both Python behavior and the controls that protect changes, dependencies, and published artifacts.

Local gates

Run the complete gate before opening or updating a pull request:

uv run python scripts/repo_harness.py
tox

The harness tox environment checks that workflows declare explicit permissions, external actions are pinned to immutable commits, required security workflows exist, and repository governance files are present. The full tox environment additionally runs linting, type checking, docs, contract validation, the supported Python matrix, and the coverage threshold.

For dependency-only changes, also run uvx --from pip-audit pip-audit --local --progress-spinner off and pnpm audit --prod from docs/astro-site.

Dependency and experimental-feature policy

The supported Python 3.12–3.14 range tracks compatible stable dependencies and commits uv.lock for reproducibility. Before dependency or runtime changes, run uv lock --upgrade and python scripts/dependency_frontier.py . --strict.

Apache Arrow/Parquet is the canonical public tabular interchange; JSON Lines is an explicit human-debug format. Experimental serializers, JAX, NumPyro, accelerators, and distributed runtimes remain behind named extras and require round-trip, numerical-equivalence, provenance, and CPU-reference evidence before promotion. Python free-threading remains an observation lane rather than a release or performance claim.

GitHub gates

The hosted repository runs CodeQL, OpenSSF Scorecard, Dependency Review, and Zizmor. Workflows also enforce SHA-pinned actions, least-privilege permissions, disabled credential persistence on security-sensitive checkouts, and release artifact provenance attestations. The release workflow also publishes the signed SLSA bundle as a .intoto.jsonl release asset so independent tools can discover provenance without privileged access to GitHub’s attestation store.

The protected main ruleset requires pull requests, resolved review threads, successful required checks, signed commits, and linear history. The required approval count is zero for the single-maintainer operating model; CODEOWNERS still routes review responsibility without creating an impossible independent approval gate. Hosted settings must be verified through the GitHub API because they are not represented by files in the checkout.

OpenSSF’s aggregate Scorecard is interpreted check by check. Independent human review and multi-organisation contributor diversity are useful signals, but a single-maintainer project cannot manufacture either signal. The repository therefore retains zero required approvals while requiring the complete automated matrix, signed commits, current branches, resolved threads, and immutable releases. Those deliberate exceptions should not be bypassed with bot approvals, alternate accounts, synthetic contributors, or placeholder releases.

Owner and organization gates

Some controls cannot be configured from this repository alone:

• organization-wide Actions policies, runner groups, and required workflows;
• billing- or plan-dependent secret-scanning validity checks;
• enterprise security policy and outside-collaborator restrictions;
• environment reviewers and production deployment approvals.

These remain administrator-owned follow-up gates and must not be represented as locally complete merely because repository workflows pass.