Repository navigation
release: plan, publish and verify la-stack v0.5.3 #333
Description
Summary
Deliver la-stack v0.5.3 through five implementation PR groups, a completed performance investigation (group 6), and one dedicated release-preparation PR, followed by publication and registry verification. This issue owns the complete release boundary; #326 remains the narrower benchmark/shared-tooling readiness tracker.
Implementation may proceed on the maintainer-authorized exact development pin; actual release preparation requires verified published tooling. The current bounded integration uses research-repo-tools cd8594f658b5bf3ade063a685834565cc62e0cb3 in PR #339, building on merged PR #335. This issue now owns all remaining v0.2.7 publication, normal-package adoption and release-revision revalidation criteria transferred from #320, #323, #324, #325, #326, #330 and #338. #320, #322, #323, #324 and #325 closed through merged #335; #339 owns automatic closure of the remaining implementation work in #326, #330 and #338. Merge does not establish published-package adoption or release readiness.
#331 investigation handoff — 2026-11-09
#331 is complete as an investigation with no demonstrated upstream performance defect and no justified code fix. See the findings and durable evidence, including the reduced-4D/code-generation study and 80 controlled whole-5D executions / 2,400 validated raw samples. The fresh whole-5D confirmation gives paired changes of -1.04% (95% interval [-1.90%, -0.17%]) with the layout variable absent and -0.33% ([-0.88%, +0.23%]) with 256-space padding. These local diagnostic estimates are not release-wide speedup claims. No fix commit or supplying-fix release exists to identify.
The maintainer accepted closing the investigation and keeping remaining release validation here. This supersedes the former #331 publication checkbox and the assumption that group 6 must produce an optimization PR. The original historical experiment is not exactly reconstructed; its dirty source/raw artifacts were unavailable. No production code, tolerances, scientific assertions or supported cases were changed.
The following remain outstanding under this release issue, not #331:
- Final scientific/native validation: preserve supported success, provisional rank/full-shape admission, typed errors, exact rational certificates, interval enclosure/fallback, and complete SoS ordering/budgets. Record the required final
just ci, native Linux/macOS/Windows, default/exact, package and real-consumer evidence bound to the final release/adoption revision. Diagnostic preflights and static Windows targeting do not establish these results. - Release performance evidence: acquire/retain the eligible final-source campaign under the accepted workload policy, with matched inputs/features/commands, identities, raw samples and honest uncertainty. Cover affected 2D–5D consumer behavior and preserve LP/SoS coverage and 6D–8D checks where admitted shapes require them. Keep the perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331 exploratory archives under their original identities; do not relabel them as final release evidence or claim the historical gains have been revalidated.
- Publication and consumers: complete the existing v0.5.3 release gates below, including exact tag/commit, original signed CI/package and acquisition identities, non-yanked crates.io artifact/checksum, and fresh normal Cargo consumers with default/
exactfeatures. These obligations no longer keep perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331 open. - Downstream handoff: provide the actual verified published release and evidence to perf: Adopt the published la-stack fix for realization-validation overhead delaunay#680. No perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331-specific performance fix is promised. Full downstream adoption remains separate from supplier publication.
If final validation establishes a new concrete regression, record a bounded defect and its evidence here and link the appropriate fix issue; do not treat this investigation's closure as proof of release readiness.
Tooling adoption handoff — 2026-11-07
The maintainer requested that completed implementation issues close automatically when their implementation PR merges, without waiting for research-repo-tools v0.2.7. #335 therefore carries Closes references for #320, #322, #323, #324 and #325; these issues must not be closed manually before merge. This handoff supersedes earlier publication-only closure requirements in the affected issues; it does not waive any scientific, native, provenance or release guarantee.
| Origin | Implementation status and remaining owner |
|---|---|
| #320 — availability | Implementation and bounded local validation complete in #335; final published-contract/pin/native adoption checks below. |
| #324 — budgets/progress | Implementation and bounded local validation complete in #335; released interface and consumer revalidation below. |
| #325 — checkpoint/resume | Successful schema-6 suite-pair recovery implemented and locally validated in #335; released recovery-contract revalidation below. |
| #323 — one acquisition | Candidate/report/README/archive reuse and approval-boundary integration implemented and locally validated in #335; released-contract/native/final-release evidence below. |
| #326 — workstream readiness | Remains open for implementation merge/CI reconciliation and the remaining guide/workflow readiness handoff, including #330. It is no longer held open solely for published tooling. |
| #330 — common release flow | Remains open for command/guide parity, the canonical release-benchmarks dispatch and automatic draft preparation. Its supplying-version and final published-pin verification gates move here; functional work is not marked complete. |
Implementation evidence: #335 at a2debb424426b75a97e8a56a061b70985f53d950, the workload review, and the candidate review. Full local macOS just ci passed with 367 Python and 1,143 Rust tests, default/exact doctests and owning native/static checks. Real-source discovery and correctness gates covered 1,419 cases per phase; the bounded end-to-end rehearsal used synthetic timing samples. PR review, required CI and merge remain tracked by #335; no actual campaign, registry publication or final-main release evidence is claimed.
Transferred release gates — all still outstanding
- Published supplier: verify the exact supplying research-repo-tools release (target v0.2.7), upstream release verification, non-yanked PyPI wheel/sdist identities and digests, and a fresh normal install. The release must contain the public contracts and fixes exercised by development pin
cd8594f658b5bf3ade063a685834565cc62e0cb3, including Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189's committed-output binding and the fixes tracked in feat: support committed benchmark evidence and release summaries research-repo-tools#190, fix(performance): report rejected correctness gates as failed research-repo-tools#191, fix(performance): resolve suite publication dependency labels from observation provenance research-repo-tools#196, fix(performance): enforce active suite minimum releases during preparation research-repo-tools#197, fix(deps): preserve exact Git development pins during normal Python updates research-repo-tools#200, Support safe suite-level resume within schema-6 trial schedules research-repo-tools#203 and Define candidate reuse for README outputs that are historical compiler inputs research-repo-tools#204, plus validation parallelism, managed Cargo compilation caching and authenticated draft preparation/receipt retrieval from research-repo-tools PR #207 and PR #209. A merged commit, closed issue or GitHub tag alone does not establish this. - Normal consumer resolution: replace the development pin in the manifest, lock and every isolated recipe/workflow invocation with the exact verified published version. Prove consistent normal resolution without editable, sibling, Git/path overrides or copied private/generic validators. Re-run
just updateand verify the resolved tools. A Git pin is permitted for development rehearsal only. - Adopt shared benchmark workload availability across API revisions #320/Adopt shared benchmark budgets, progress, and remaining-time reporting #324 revalidation: exercise older/exact-boundary/later baseline availability, supported-target failures, all 1,403 library cases and 16 peer cases where eligible, 149 new-API cases, honest baseline-peer/current ratios, independent inventories, totals/progress/unknown ETA/non-TTY/failure handling, and report/README retries without measurement against the released package.
- Adopt validated benchmark checkpoint and resume without mixing incompatible evidence #325 revalidation: repeat bounded successful interruption/resume against the released package, retaining eligible complete suite pairs and their original bytes, reacquiring only the eligible incomplete pair, rejecting incompatible identities/sessions/partial evidence, preserving prior outputs and enforcing final independent completeness. Record the supported schema/trial/session boundary; a fresh restart or safe rejection alone is insufficient.
- Adopt one verified benchmark acquisition for release reports and artifacts #323/Align release guide and commands with research-repo-tools evidence-reuse flow #330 revalidation: repeat the installed-package candidate → report/README/committed outputs → final commit → read-only verification → archive/attachment/publication retry handoff, including README compiler-input exclusions, original-source assertions, immutable ownership, explicit CI renewal, full acceptance digest and approval-time identity checks. Keep acquisition/build/test failure sentinels on inspection/retry paths and complete Align release guide and commands with research-repo-tools evidence-reuse flow #330's common-command/automatic-draft integration first.
- Review and integrate v0.2.7 validation parallelism and Cargo build caching #338 validation-speed acceptance: validate the final published-package integration on the native platforms and record matched cold-cache/warm-cache managed-install timings with equivalent validator coverage and workloads. Distinguish queue, setup, execution, critical-path elapsed time and aggregate runner usage, record cache hit state and remaining bottlenecks, and make no speedup claim from unmatched cache states. These are release validation obligations, not reasons to keep the delivered implementation issue open.
- Native adoption evidence: record the final published-pin adoption commit, required consumer checks, actual Linux/macOS/Windows and default/exact results, real-source independent discovery and correctness gates, workflow/configuration/docs checks, and any required Astra follow-up for a changed contract. Local macOS validation, target-specific type checking and upstream fixtures do not substitute for these native results.
- Actual release handoff: after all source/harness/dependency/policy/version changes are final, retain one authorized complete real acquisition, its reports/README/archive and original provenance; verify exact merged-main signed CI/package evidence before tagging and preserve the selected evidence through attachment, publication and approval. Record the source/run/attempt/artifact IDs and digests under the release completion boundary below.
#326/#330/#338 implementation handoff — 2026-11-08
#335 merged as 7c3a3625220773369c089e64e568a979abc0bb7f with successful native Linux/macOS/Windows, Cargo packaging and static checks; #326's six prerequisites (#320 through #325) are closed. #339 completes the remaining command/guide and automatic-draft integration, validation graph and managed Cargo cache wiring on the authorized exact development pin. It closes #326, #330 and #338 on merge, subject to required PR checks and review.
This release issue retains final native release validation, the authenticated hosted retained-evidence handoff, matched cold/warm timing evidence, verified supplier publication and normal published-package adoption. No unperformed validation is marked complete. A fresh PyPI metadata check on 2026-11-08 reports 0.2.6 as latest and no 0.2.7 release; the development pin is permitted only for implementation/rehearsal, not release readiness.
Historical planning state — 2026-11-05
Verified on 2026-11-05, against la-stack main ab3b8a0f0381e239b5c89f69664584e6a0c5c217:
- la-stack is 0.5.2 and pins research-repo-tools 0.2.4, including isolated release/workflow invocations.
- research-repo-tools 0.2.6 has non-yanked wheel and sdist distributions on PyPI; its publication tracker #185 is closed. It supplies the Semgrep fix and earlier availability, progress, recovery and candidate-reuse APIs.
- Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189 is open. PyPI currently reports 0.2.6 as latest; 0.2.7 is not yet published. Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189 owns the validated generated-evidence extension and readable
release-evidencesummary. - All twelve existing v0.5.3 milestone issues remain in scope: Remove the Semgrep environment override after research-repo-tools v0.2.5 adoption #317, Adopt shared benchmark workload availability across API revisions #320, Make routine CI validate benchmarks without automatic full timing runs #321, Review release benchmark combinations while preserving public scientific coverage #322, Adopt one verified benchmark acquisition for release reports and artifacts #323, Adopt shared benchmark budgets, progress, and remaining-time reporting #324, Adopt validated benchmark checkpoint and resume without mixing incompatible evidence #325, release: coordinate v0.5.3 benchmark efficiency and shared-tooling adoption #326, Add runnable examples for column selection, interval solves, and exact rational dots #327, Link interval and rounding rustdoc to scientific references and enclosure proofs #328, Align release guide and commands with research-repo-tools evidence-reuse flow #330, perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331.
- The older 0.2.5 targets in adoption issues and Adopt one verified benchmark acquisition for release reports and artifacts #323's 0.2.6 sufficiency statement predate the committed-JSON evidence decision. This tracker records the updated delivery plan: 0.2.6 is enough to start groups 1–3; the selected storage/release contract in group 4 needs Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189 in a verified published version.
The candidate group list in #326 is workstream history. The consolidated groups below govern implementation scope, with the 2026-11-07 handoff above governing publication-only acceptance ownership.
Proposed Changes
PR groups and model selection
All numbered groups are owned by acgetchell/la-stack. Group numbers identify review boundaries, not a requirement to serialize all development.
| Group | Issues | Scope and completion boundary | Model | Start / prerequisite |
|---|---|---|---|---|
| 1. Shared-tool upgrade and routine CI | #317, #321 | Pin 0.2.6 normally, synchronize lock and every isolated package invocation, remove the Semgrep override, and make full timing explicit. Preserve automatic correctness, benchmark compilation/input/configuration gates, status checks and release evidence. Completes both issues after consumer/native verification. | Sol; Astra only if evidence or scientific eligibility is changed. | Start now. #317's supplying fixes are published; #321 needs no upstream change. |
| 2. Benchmark coverage, availability and budgets | #320, #322, #324 | Produce one reviewed workload policy, replace historical API exclusions with supported availability declarations, and integrate counts/progress/ETA. Preserve complete current coverage and honest unavailable cells. Completes implementation after real-revision/local native integration; #335 owns required PR CI/merge and this issue owns final published-pin adoption. | Astra for scientific coverage decisions; Sol for settled declarations and wiring. | Implementation is in #335 using the authorized exact development pin. Published-pin adoption is tracked here. |
| 3. Validated checkpoint/resume | #325 | Adopt the public recovery boundary, preserve accepted original bytes and provenance, resume only eligible missing work, and prove final completeness. Completes #325 only with usable successful recovery, not merely safe rejection or fresh restart. | Sol for the settled upstream contract; Astra if trial/session/comparability decisions remain unresolved. | Implementation and successful schema-6 recovery are in #335 on the authorized development pin. Final published-package revalidation belongs here. |
| 4. Canonical release flow and one acquisition | #323, #330 | Integrate public acgetchell/research-repo-tools#189; preserve committed generated evidence; compose benchmark and CI/package verification in just release-evidence; align guide/commands and automated draft/archive flow. #323 implementation is in #335; #330 retains unfinished command/draft alignment. This issue owns published pin/lock/invocation updates and final adoption evidence. |
Astra leads the bounded source/storage/approval trust review; Sol implements settled CLI/docs/workflow wiring. | Functional integration may proceed on the authorized exact development pin with the accepted inventory/recovery contract. This issue retains the verified 0.2.7 publication and normal-package release gate. |
| 5. Runnable examples and scientific documentation | #327, #328 | Add column/interval examples, extend exact rational dots, and connect interval/rounding rustdoc to the existing proofs and references. Completes both issues without changing settled numerical contracts. | Sol; Astra only for a newly discovered proof or mathematical-contract question. | Start now, independently of the tooling upgrade. Merge before measurement identity capture. |
| 6. Delaunay realization performance | #331 | Completed investigation: reduced 4D, generated-code comparison and controlled whole-5D confirmation found no demonstrated upstream defect warranting a code fix. Evidence. No optimization PR or fix release is required by this disposition; remaining release validation belongs here. | Attribution review complete for this scope; escalate any newly established scientific defect separately. | Investigation complete. Final release-policy measurements and native/scientific validation remain pending in this issue. |
| 7. Release preparation, publication and verification | This issue, following completed implementation/investigation handoffs | Prepare release/v0.5.3 after substantive work; set version/citation/locks, generate changelog, acquire once, promote reports, merge, verify original evidence, tag/draft, publish, and verify the registry artifact plus clean consumers. This issue closes only at the final boundary below. |
Sol follows the accepted release procedure; Astra only for a new scientific/trust discrepancy. | Readiness and all pre-acquisition changes accepted; acgetchell/research-repo-tools#189 published and la-stack integration verified. Publication remains maintainer-approved release work. |
Why these boundaries: combine changes sharing policy, configuration and validation, while keeping scientific workload selection, recovery, publication trust and numerical optimization independently reviewable. Do not create a separate PR for every issue. #331's completed investigation found no demonstrated upstream or consumer defect warranting a fix, so group 6 requires no implementation PR. Its remaining release checks are retained here; downstream published-package adoption stays in delaunay#680. Any newly established regression needs a concrete issue and evidence.
Stack and dependency direction
Recommended merge order for overlapping tooling/configuration files is group 1 → group 2 → group 3 → group 4. This is an integration order, not a claim that progress is a technical prerequisite for resume. Group 5 was independent of the now-completed group 6 investigation. All source, examples, harness, dependency, policy and release-metadata changes must land in the candidate state before acquisition.
Native dependencies distinguish completion blockers from permission to begin independent work:
- Existing upstream implementation/publication prerequisites for Remove the Semgrep environment override after research-repo-tools v0.2.5 adoption #317/Adopt shared benchmark workload availability across API revisions #320/Adopt shared benchmark budgets, progress, and remaining-time reporting #324/Adopt validated benchmark checkpoint and resume without mixing incompatible evidence #325 are closed; do not add Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189 as a blocker to those issues.
- Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189 → Adopt one verified benchmark acquisition for release reports and artifacts #323 and Align release guide and commands with research-repo-tools evidence-reuse flow #330 records the new shared implementation prerequisite. Keep the separate published-version gate below: closing Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189 does not prove that 0.2.7 is available.
- Existing Adopt shared benchmark workload availability across API revisions #320–Adopt validated benchmark checkpoint and resume without mixing incompatible evidence #325 → release: coordinate v0.5.3 benchmark efficiency and shared-tooling adoption #326 dependencies remain; release: coordinate v0.5.3 benchmark efficiency and shared-tooling adoption #326 closes at verified implementation/workstream readiness. Publication-only acceptance is owned here, not by the completed implementation issues.
- Remove the Semgrep environment override after research-repo-tools v0.2.5 adoption #317, release: coordinate v0.5.3 benchmark efficiency and shared-tooling adoption #326, Add runnable examples for column selection, interval solves, and exact rational dots #327, Link interval and rounding rustdoc to scientific references and enclosure proofs #328, Align release guide and commands with research-repo-tools evidence-reuse flow #330 and perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331 → this release issue cover release completion. The release: coordinate v0.5.3 benchmark efficiency and shared-tooling adoption #326 edge includes its six workstream blockers transitively.
- perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331 closes at completed investigation. Its existing dependency edge records that satisfied prerequisite; final scientific/native validation, acquisition and publication are owned here. There is no requirement to hold or reopen perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331 for release-only acceptance.
What remains before release adoption of research-repo-tools 0.2.7?
The actual published distribution must satisfy the exercised contracts and all transferred gates above. Implementation may proceed before publication on the authorized development pin. A version number alone is not acceptance.
| State / owner | Required evidence | Current status |
|---|---|---|
| Implemented — upstream contracts and local consumer integration | Accepted scientific/architecture records and bounded installed-package regressions. | Upstream implementation prerequisites are closed; consumer implementation is in open PR #335 at the recorded development pin. Required PR CI/merge remain separate. |
| Published — acgetchell/research-repo-tools#189 supplying release; evidence recorded here | Exact 0.2.7 wheel/sdist, non-yanked PyPI records/digests, normal fresh resolution/install, and upstream release verification. A GitHub tag/release alone is insufficient. | Pending. |
| Pinned — this issue, covering #320/#323/#324/#325/#326/#330 | Exact normal dependency and lock resolution; all isolated workflow/recipe invocations agree; no editable, sibling, Git/path override or copied generic verifier. | Release adoption pending; #335 uses an explicitly authorized development Git pin. |
| Verified — this issue, with #326 implementation readiness and #330 remaining flow alignment | Released-package consumer checks, actual committed-evidence layout, final-commit binding, workflow/CLI tests, native checks and scientific guarantees pass for the adoption revision. | Local development-pin rehearsal passed; released-package/native/final-release verification remains pending. |
Group 1 is complete. Integrate the verified published version under this release tracker after development-pin rehearsals establish suitability. Do not hold completed implementation issues open solely for publication.
If the published contract does not meet the committed layout or reveals another gap, file/link the exact upstream defect and its consumer follow-up here; retain the release gate and any genuinely incomplete functional issue. A rollback to two acquisitions or moving evidence out of Git without a new maintainer decision does not satisfy this plan.
Evidence and storage decisions for group 4
- Keep JSON release attestations and the committed
docs/performance-runs/layout. No new storage service, raw-evidence migration or historical rewrite is part of this release. - Permit only independently verified generated outputs from the selected acquisition, including content-addressed run directories and consistent index/latest files. Match the acquisition identity and exact bytes through the published Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189 contract; never allow arbitrary JSON or a blanket directory exemption. Historical run bytes remain immutable.
- Keep original measured source/host/session/tool/harness/workload identity distinct from the final reviewed release commit. The final-commit acceptance/attestation belongs in retained release evidence/assets, avoiding a self-referential committed attestation.
- Step 1 acquires once. The declared baseline/current/peer plan can contain multiple scientifically justified trials; “once” does not mean silently reducing it to one trial. Reports, README and release archive derive from that acquisition.
- Step 2 verifies before tag creation/push.
just release-evidenceverifies eligible original main CI/package evidence and the selected benchmark evidence. It must not acquire, rebuild, rerun tests or silently repair stale evidence. - Show a readable verified summary: release/version and full commit, original CI run/attempt, native/feature/package coverage, benchmark acquisition identity, integrity/signature status, and any rejection. Human review uses this summary, release notes and scientific reports; there is no routine line-by-line JSON attestation review. Preserve JSON/output-file/
GITHUB_OUTPUTand failure contracts. - Freeze selected evidence and approval inputs; revalidate the same selection after approval. Preserve required findings/SARIF gates, protected environments, credentials/OIDC separation, archive/draft/tag integrity and immutable publication.
- Make
docs/RELEASING.mdfollow the published research-repo-tools guide's common steps and commands, isolating Cargo/scientific specifics. Resolve command arguments, pre-tag ordering and automated draft creation consistently in Align release guide and commands with research-repo-tools evidence-reuse flow #330. Native Cargo non-building repackaging is a distinct supported operation; do not claim byte-identical retained Cargo archives without proof.
Benefits
Routine CI stops paying for automatic full timing; release publication reuses applicable evidence already established. Work can begin while acgetchell/research-repo-tools#189 is developed. These are expected reductions in duplicate work, not measured elapsed-time or speedup claims. Investigation/review, native CI and actual acquisition costs remain unknown until recorded.
Implementation Notes
Required tests and evidence
These are planned acceptance gates, not results from filing this issue. Follow CONTRIBUTING's validation workflow, the justfile, benchmarking guide and updated release guide. Use just check while iterating; compose relevant focused validators once for final non-core changes. Core Rust/public behavior and the final release require the documented just ci pass.
| Owner | Required behavior/evidence | Canonical checks |
|---|---|---|
| Group 1 — #317/#321 | Production and fixture Semgrep use the same locked Python 3.15 environment; scanner errors propagate; PR/main events never sample; explicit timing still works; automatic correctness/input/compile/status/report gates remain. Verify every exact package pin. | just python-ci, just semgrep, just semgrep-test, just lint-config, affected shell/docs checks, just test-bench-inputs, just bench-compile; package-upgrade validation follows contributor guidance, including just ci. |
| Group 2 — #320/#322/#324 | Test baseline releases before, at and after API availability (0.5.0/0.5.1 versus 0.5.2+); supported-target compile failure must fail; current-only APIs stay required; no fabricated ratio. Real baseline/current default/exact discovery agrees with the independent inventory and progress totals. Cover unknown ETA, non-TTY output and early failure. README retries never measure. Astra approves any removed mandatory cases; retain full diagnostic catalog and comprehensive correctness. | just python-ci, just test-bench-inputs, just bench-compile, native discovery for both real revisions; relevant config/docs checks. |
| Group 3 — #325 | Bounded fixtures interrupt at supported boundaries, preserve accepted raw bytes, resume only eligible work and enforce final completeness. Reject changed source/harness/plan/sampling, partial samples, incompatible sessions and duplicate ownership. Verify the supported schema-6 suite-pair recovery boundary exercised in #335: preserve accepted completed pairs and reacquire the eligible interrupted pair, without claiming arbitrary partial-sample reuse. Record trial/session eligibility and revalidate it against the released package. | Focused installed-package consumer tests via just python-ci, native/input checks for affected wiring and docs. Generic crash/atomicity/concurrency engine regressions remain upstream. |
| Group 4 — #323/#330 | One bounded end-to-end fixture: acquire → promote committed run/index/report outputs → final reviewed commit → verify → derive archive → retry attachment/publication inspection. Failure sentinels prove Step 2 and retries never invoke acquisition/build/test. Reject tampered raw bytes, unauthorized/new paths, changed historical runs/indexes, relevant source/lock/config/tool/harness changes, invalid commit bindings, stale/missing/ambiguous CI attempts, artifact replacement and changed approval selection. Summary success appears only after verification; absent required evidence is not “pass.” | just python-ci, just lint-config, applicable shell checks, just markdown-fix, just markdown-ci, just doc-check; real Linux/macOS/Windows integration and signed main evidence remain separate gates. |
| Group 5 — #327/#328 | Independently known example values and exact typed failures; default/exact feature separation; rendered proof/reference links and stable anchors. Rust comments and examples are captured inputs, so finish before acquisition. | just examples, formatting/lints, just test-doc, just test-doc-exact, just doc-check, just markdown-fix, just markdown-ci. No timing campaign solely for documentation. |
| Group 6 — #331 | Completed attribution with durable source/harness/raw evidence; no production change or justified kernel/API fix. Preserve the explicit historical-reconstruction and host/layout limits. | Diagnostic preflights, raw-sample/identity validation and analysis checks passed. Final release just ci, broad LP/SoS/shape coverage, native checks and final-source measurements remain in this issue's handoff above. |
| Release — this issue | Final source and package checks; original main-push Linux/macOS/Windows run/attempt and required default/exact packaging evidence; one complete accepted acquisition; archive/approval gates; published registry checksum and fresh consumers. | Updated guide's version/publish checks, final just ci, Step 1 package verification as required, Step 2 just release-evidence, just release-publish, then just release-verify v0.5.3 and clean Cargo default/exact resolution. Step 2 consumes prior evidence rather than repeating those builds/tests. |
Shared tooling owns comprehensive generic regressions and installed wheel/sdist coverage. la-stack owns actual published-package wiring, scientific oracles and supported native/platform/feature evidence. Do not delete local guarantees merely because upstream has similarly named tests. Apply the required Python portability skill before Python/CI/test edits; run spelling checks after edits (markdown-ci includes them).
Release completion boundary
- Record the exact published research-repo-tools version containing the gate-progress fix from acgetchell/research-repo-tools#191, implemented by #192, so consumers can adopt it through normal pin/lock resolution. This release criterion is owned here; it does not keep the completed upstream implementation issue open.
- Groups 1–5 satisfy all mapped issue acceptance; release: coordinate v0.5.3 benchmark efficiency and shared-tooling adoption #326 records benchmark/shared-tooling readiness. Group 6 has the accepted, evidenced no-fix investigation disposition in perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331; no separate optimization PR is required. No requested capability is silently deferred.
- Support committed benchmark evidence and readable release-evidence summaries research-repo-tools#189's supplying release is implemented, merged, published, normally pinned, then verified in la-stack, with links for each state. Upstream fixtures alone do not establish adoption.
- All acquisition-relevant source/examples/harness/config/dependencies and prospective 0.5.3 metadata are finalized before measurement. Generate
CHANGELOG.mdthrough its owner; never hand-edit it. - The dedicated release PR retains complete scientific evidence and generated reports from one declared acquisition. Preserve historical releases/evidence under their original identities.
- Required final validation and exact merged-main CI/package evidence are recorded by revision, run/attempt and artifact ID/digest. Step 2 verifies the final commit and selected acquisition before tag/push; stale or incomplete evidence blocks publication without hidden reruns.
- The reviewed draft, notes, archive and JSON attestations are verified through the canonical flow. Live Trusted Publishing/environment/permission settings and approval-time evidence are checked. Follow the release guide for explicit recovery; no blind upload retries or tag movement.
- Publish v0.5.3 and verify the non-yanked crates.io artifact and checksum, stable GitHub release and required durable assets. Record the exact tag/commit, acquisition, original CI, publishing run and registry evidence here or in the linked release PR.
- Fresh normal Cargo consumers resolve exactly la-stack 0.5.3 and check both default and
exactfeatures. Resolve this tracker's remaining release acceptance and close this capstone; perf: Recover Delaunay realization performance after 0.5.2 kernel adoption #331 is already complete as an investigation. A merged PR, tag or GitHub release alone is not completion.
Downstream stack and publication cutoff
| Owner / issues | Relationship to this release |
|---|---|
| acgetchell/research-repo-tools#189 | Supplies group 4 after verified PyPI publication. Its release must not wait for real la-stack, Delaunay, MCMC or CDT adoption. |
| delaunay#680 | Owns downstream adoption of the actual verified published la-stack release. #331 identified no fix commit or supplying-fix release. Full downstream adoption is not a blocker for publishing la-stack; required pre-publication scientific/consumer validation remains in this release issue. |
| delaunay#690, #693 | Own Delaunay's benchmark reuse and common release-flow adoption from the shared tools. Separate consumer work; not la-stack publication blockers. |
| markov-chain-monte-carlo#223, #220 | Own MCMC's benchmark reuse and common release-flow adoption. Separate consumer work. |
| causal-triangulations#322, #321 | Own CDT's benchmark reuse and common release-flow adoption. Separate consumer work. |
Publish once the bounded la-stack scope and its required upstream, scientific, native and release gates pass. Do not hold this supplier release for other repositories' complete migrations/releases. Excluded scope: #123's expanded const generics, blanket sampling/warmup cuts, a new benchmark engine/storage platform, historical evidence rewriting, and unrelated API/toolchain work.
If remaining release validation exposes an unresolved architectural/scientific gap, record a bounded decision here and link the appropriate defect issue: evidence, remaining acceptance and the choices to retain scope or explicitly defer with maintainer approval. Do not count a safe failure/fallback as successful delivery.
This issue authorizes no Git mutation, long benchmark campaign, CI dispatch, tag or publication by itself. Next implementation work: merge #335 subject to its required review/CI, finish #330's remaining common-command/automatic-draft alignment, and continue the remaining implementation groups. Published-tooling adoption and the actual release remain tracked here.
Activity
docs: assign release validation to the release tracker
acgetchell commentedon Nov 9, 2026
#331 handoff recorded in the issue body above. The completed investigation and attached evidence found no demonstrated upstream defect warranting a code fix. Its closure does not depend on publication, and no fix commit or supplying-fix release is claimed.
This tracker retains the outstanding final scientific/native/default/exact/package checks, eligible final-source performance evidence, signed CI/package provenance, v0.5.3 registry verification and fresh normal Cargo consumers. None of those release gates is marked complete by the diagnostic. Downstream adoption remains separate in acgetchell/delaunay#680.