[M6-16] Independently verify and close Release 1

[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

Independently verify that every required exact target selector is frozen, every registered scope and artifact is implemented, every required Qualification Cell is Qualified for the exact Release Manifest, every passing and failing attempt is retained, every publication matches, and no non-waivable gate, security finding, missing artifact, partial publication, or hidden unsupported target remains.

Scope and semantic ownership

• Milestone: M6
• Global sequence: 149 / 149
• Semantic owner: Release Engineering
• Highest useful behavior seam: Independently verify and close Release 1
• 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-15] Publish one coherent Release Set #149 — M6-15

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
• Q-RX-001
• Q-RX-002
• Q-RX-003
• Q-RX-004
• Q-LOG-001
• Q-TRACE-001
• Q-QUERY-001
• Q-QUERY-002
• Q-TAIL-001
• Q-GRAFANA-001
• Q-AUTH-001
• Q-TENANT-001
• Q-AUDIT-001
• Q-POLICY-001
• Q-SCHEMA-001
• Q-RESOURCE-001
• Q-STORAGE-001
• Q-CATALOG-001
• Q-CRASH-001
• Q-INTEGRITY-001
• Q-TIME-001
• Q-KEY-001
• Q-KEY-002
• Q-CRYPTO-001
• Q-BACKUP-001
• Q-BACKUP-002
• Q-UPGRADE-001
• Q-CONFIG-001
• Q-LISTENER-001
• Q-PROCESS-001
• Q-MAINT-001
• Q-DIAG-001
• Q-DIAG-002
• Q-K8S-001
• Q-K8S-002
• Q-K8S-003
• Q-OPS-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.
• An independent verifier must reproduce the evidence index and artifact/registry identity checks without relying on implementation-team assertions.
• Any failed, unsupported, missing, inconclusive, exceptional, or stale required cell keeps Release 1 incomplete.
• 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.