[M6-14] Qualify reproducibility and supply-chain trust

[vicotrbb]

Release 1 source: #1. The master specification is referenced, not modified by this ticket.

Execution signal: ready-for-agent means this issue is implementation-ready once every native GitHub blocker below is closed.

Outcome

Rebuild and independently compare every required payload; validate locked inputs, SPDX/CycloneDX SBOMs, provenance, signatures, checksums, target and compatibility identities, advisory/license/ban policy, secret scans, revocation, security support, offline verification, complete Release Manifest, and refusal of partial or mismatched sets.

Scope and semantic ownership

• Milestone: M6
• Global sequence: 147 / 149
• Semantic owner: Release Engineering
• Highest useful behavior seam: Qualify reproducibility and supply-chain trust
• Affected registered scopes: positron-release, Release Trust and all registered artifact scopes
• Expected project size / estimate: XL / 13
• Completion status rule: An exact cell may become Qualified only when the frozen candidate passes the complete real-target gate and immutable evidence is retained. Any failed, missing, stale, unsupported, inconclusive, or exceptional required cell remains release-blocking.

No weaker document, implementation convenience, partial target, emulator, local diagnostic, or green subset may reinterpret the binding contract.

Native blockers

• [M6-02] Qualify every distribution target #136 — M6-02
• [M6-03] Qualify the Public API and SDK Release Set #137 — M6-03
• [M6-04] Qualify every receiver and producer target #138 — M6-04
• [M6-05] Qualify Logs, Traces, Query, Tail, and Grafana #139 — M6-05
• [M6-06] Qualify identity, tenancy, policy, and governance #140 — M6-06
• [M6-07] Qualify kernel, resources, integrity, time, and maintenance #141 — M6-07
• [M6-08] Qualify security, listeners, keys, and cryptography #142 — M6-08
• [M6-09] Qualify backup, restore, upgrade, configuration, and process #143 — M6-09
• [M6-10] Qualify operations and diagnostics #144 — M6-10
• [M6-11] Qualify every Kubernetes cell #145 — M6-11
• [M6-12] Execute the preregistered performance campaign #146 — M6-12
• [M6-13] Execute the full mixed-workload soak #147 — M6-13

The native blocked-by graph is authoritative for execution order. Do not start implementation while a blocker is open, while an affected scope remains unlawfully scaffold-only, or while a required decision/review is missing.

Binding product and architecture references

• Frozen Positron product contract
• Binding domain language
• Release 1 qualification and M6 milestone contract
• Whole-application module and flow design
• Project contract §3.11 Compatibility and Versioning
• Project contract §3.24 Supply Chain, Signing, and Security Response
• Project contract §3.25 Release 1 Scope and Qualification
• Application Design §4.18 Release Trust
• Application Design §4.19 Qualification Harness
• Application Design §10.4 Qualification surfaces
• Application Design §11 Vertical implementation order

Accepted ADRs

• ADR-0027 — implement the positron application entirely in rust
• ADR-0028 — use one versioned protobuf definition for public apis and sdks
• ADR-0029 — publish six generated sdks as one release set
• ADR-0046 — ship positron as a locally runnable standalone database
• ADR-0047 — make the oci image a primary release blocking artifact
• ADR-0049 — ship an optional same binary kubernetes operator in release 1
• ADR-0050 — make kubernetes compatibility an evidence backed release contract
• ADR-0060 — publish independent compatibility claims in one release manifest
• ADR-0073 — bind every artifact to a reproducible signed security supported release
• ADR-0074 — freeze release 1 through an evidence backed qualification matrix

If implementation would change caller knowledge, semantic ownership, a public or durable format, compatibility, a non-waivable invariant, or Release 1 scope, stop and land the required accepted superseding ADR together with its contract, migration, tests, and gates.

Engineering invariants and gates

• Mandatory engineering invariants: ARC-01, ARC-05, RUST-01, RUST-02, RUST-04, ERR-04, SEC-01, SEC-04, SEC-05, DOC-02, DOC-03, DOC-04, TEST-03, TEST-07, PERF-02, PERF-03, PERF-04
• Authoritative gates: EG-00, EG-ARCH, EG-BUILD, EG-DEPS, EG-DOCS, EG-ERROR, EG-EVIDENCE, EG-POLICY, EG-RUST, EG-SAFETY, EG-SECRETS, EG-SUPPLY, EG-TEST, EG-MATRIX, EG-PERF, EG-SECURITY, EG-SOAK
• Canonical runner: cargo xtask quality
• Policy sources: Engineering standards, Quality gates, Contribution and activation policy, Application scope registry, Artifact scope registry, Allowed dependency graph

Do not weaken, skip, rename, path-filter, delete, reclassify, or silently bypass a gate, target, threshold, owner, test, corpus, fixture, hook, workflow, or evidence field.

Affected Qualification Cells

• Q-BUILD-001
• Q-DIST-001
• Q-DIST-002
• Q-DIST-003
• Q-API-001
• Q-SDK-001
• Q-COMPAT-001
• Q-SUPPLY-001
• Q-SECURITY-001
• Q-PERF-001
• Q-SOAK-001

Each cell remains independently reportable. A passing child cannot hide a failed, unsupported, missing, unresolved, or inconclusive sibling.

Required implementation contract

• Deliver the outcome exactly as stated above, through the named semantic owner and highest useful behavior seam.
• Bind every exact artifact, target, compatibility claim, evidence attempt, SBOM, provenance statement, signature, and registry publication to one Release Manifest identity.
• Refuse partial, mismatched, stale, revoked, unsigned, unreproducible, or unsupported artifact sets.
• Make offline verification, revocation, security support, and compatibility refusals independently testable.
• Keep implementation completion, qualification, publication, and release as separate authorized states.
• If any affected code or artifact scope is still scaffold, activate it atomically with its owner, exact edges, risk gates, test commands, measured coverage/mutation baselines, and required threat model or format/API decision before adding behavior.
• Preserve the registered acyclic dependency graph and keep provider/protocol/distribution types behind their adapters.
• Return closed typed outcomes with safe details, retry class, completion state, and source context. Never use strings for control flow.
• Declare every externally reachable input, work, memory, allocation, copy, I/O, task, queue, cache, lease, retry, and latency bound plus overload behavior.
• Add no dependency without the complete review required by CONTRIBUTING.md.
• Keep generated output generated and prove clean deterministic regeneration.
• Update user/operator compatibility, migration, failure, recovery, and release-note documentation where behavior is visible.

Required tests

• Manifest authentication, checksum, target identity, compatibility identity, revocation, offline trust, and partial/mismatched-set refusal.
• Independent reproducible payload comparison, SBOM/provenance validation, signature verification, secret scan, and registry metadata checks.
• Evidence aggregation proving every required cell and target is independently present and no failed attempt is hidden.
• Include positive, boundary, negative, and adversarial cases at the lowest interface that proves the contract.
• Assert returned outcomes, durable externally readable state, published artifacts, or public behavior—not private fields, helper calls, queue layout, or incidental ordering.
• Keep tests hermetic, deterministic, parallel-safe, bounded, and retain seeds, clocks, entropy, schedules, fault plans, fixtures, and minimized failures.
• A reproducible defect fix begins with a failing regression test and retains the reproducer.
• Run all scope-selected unit, compile-fail, contract, property, integration, end-to-end, compatibility, platform, real-target, fuzz, model, fault, sanitizer, and soak suites that apply.

Evidence and completion

• Run the authoritative cargo xtask quality profile required by the change and retain its exact revision-bound evidence.
• Record exact source revision, artifact digests, target/environment, configuration, fixtures, dataset/workload, fault schedule, toolchain, command, duration, raw measurements, safe logs/metrics, result, owner, and verifier as applicable.
• Retain passing, failing, inconclusive, exceptional, timeout, cancellation, and missing-tool attempts. A later pass must not erase a failure.
• Verify no panic/unwrap/expect, unchecked indexing, ignored result, detached task, unbounded resource, ambient authority, prohibited unsafe code, secret leak, or hidden best-effort path was introduced.
• Verify the working tree and generated artifacts are clean after the authoritative runner.
• Do not close this issue from an ad hoc command, mock-only proof, emulator-only proof, local dirty evidence, or partial Qualification Cell.

Explicit non-goals

• No publication, tag, deployment, or release without separate explicit authorization.
• No umbrella qualification, mutable evidence, or claim derived from a local/dirty diagnostic run.
• No Release 1 Metrics or Profiles implementation.
• No replication, consensus, HA, automatic failover, follower reads, clustering, or live shard split/merge.
• No hidden feature flags, placeholder APIs, empty adapters, speculative modules, or disabled deferred behavior.

Agent handoff checklist

• Re-read the referenced contracts and ADRs before changing code.
• Identify the exact semantic owner, caller-visible seam, durable publication owner, and affected Qualification Cells in the implementation PR.
• Explain the lifecycle and failure boundaries before editing.
• Keep implementation, qualification, publication, deployment, and release as separate states and authorizations.
• Leave an evidence-backed status if blocked; never fabricate Implemented, Qualified, or merge eligibility.