[M6-13] Execute the full mixed-workload soak

[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

Run the exact candidate for the full preregistered duration under mixed Logs, Traces, query, pagination, tail, maintenance, backup, key operations, provider/network/disk/clock faults, process restart, recovery, and Kubernetes activity, proving every resource/backlog ceiling, availability bound, leak condition, and eventual-progress assertion.

Scope and semantic ownership

• Milestone: M6
• Global sequence: 146 / 149
• Semantic owner: Performance Qualification
• Highest useful behavior seam: Execute the full mixed-workload soak
• Affected registered scopes: qualification target, cell, threshold, evidence, and claim registries
• 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-01] Freeze the exact Release Candidate #135 — M6-01
• [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

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.25 Release 1 Scope and Qualification
• Application Design §4.19 Qualification Harness
• Application Design §10.4 Qualification surfaces
• Application Design §11 Vertical implementation order
• Application Design §14 M0 design inventory

Accepted ADRs

• 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-02, SEC-05, DOC-02, DOC-03, 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-SOAK, EG-RESOURCE, EG-FAULT
• 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-COMPAT-001
• Q-SUPPLY-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.
• Expand every dynamic selector into immutable product, version, platform, architecture, registry, filesystem, StorageClass, producer, and performance-profile identities.
• Track each Qualification Cell independently; aggregate success cannot qualify a failed, unsupported, missing, or unresolved child.
• Keep status truthful: Specified, Implemented, and Qualified are distinct and evidence-bound.
• Retain every passing, failing, inconclusive, and exceptional attempt without replacement.
• 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

• Selector expansion and moving-alias rejection tests.
• Evidence-schema tests binding source, artifacts, target, environment, configuration, command, fixtures, workload, raw measurements, owner, verifier, and result.
• Aggregate-status tests proving one failed or unresolved required child blocks Release 1.
• 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 target is qualified by an emulator, mock, umbrella provider name, moving alias, or evidence from another target.
• No publication or release action without separate explicit authorization.
• 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.