EPIC: release train 0.69.0 — COMPLETE Qwen usability on pure CUDA (all 0.68.x folded in) #3080

Activity

1. noahgift

   added this to the 0.69.0 milestone on Sep 10, 2026
2. noahgift

   added

   enhancementNew feature or requestNew feature or request

   epicEpic — multi-story umbrellaEpic — multi-story umbrella

   on Sep 10, 2026
3. noahgift commented on Sep 10, 2026

   

   noahgift

   on Sep 10, 2026

   ContributorAuthor

   More actions

   Spec PR: #3087 (branch PMAT-1097-06x-release-schedule, auto-merge armed). The §3 table in this epic's body is the state at origin/main @ 2c584a168; §10 of the spec records the agy /teamwork-preview review.
4. noahgift commented on Sep 12, 2026

   

   noahgift

   on Sep 12, 2026

   ContributorAuthor

   More actions

   Release estimate (orchestrator, 2026-09-12 12:20Z): eligible Wed 2026-09-17 ~16:00 UTC, tag Thu 2026-09-17 evening → Fri 2026-09-18 ~16:00 UTC. By this train the P1 fast set (from ≥20 ledger records) should have cut the gate time; the estimate assumes today's durations until that is measured. Slides one takt per skipped predecessor.

   Basis. docs/specifications/APR-RELEASE-001-train-and-build-kaizen.md (PR #3164): a train becomes eligible 48 h after the previous tag on main and must be runnable by 72 h; any RED step skips the train at that HEAD and the next eligibility is 48 h later. Train duration measured on 0.67 today: queue drain of the open PRs (~1 h per FULL-tier entry on intel), pre-publish dogfood (~1 h, 0.66 precedent), the G3.EX examples sweep (981 targets, ~5 h on a loaded box — the long pole, shrinks when P0/P1/P2 land), assets + preflight (~1 h). The crates.io cascade is attended (spec §3.7): the tag and GitHub release are autonomous, the publish waits for the operator, and its minutes are recorded from 0.67 on.
5. noahgift

   added 2 commits that reference this issue on Sep 13, 2026

   release(0.67): train A — 17 row PRs of the 0.67.0 train in one build …

   ...

   cb829fc

   PMAT-3445: admit the train's own release epic — it is open at every c…

   ...

   b5a09b0
6. noahgift commented on Sep 17, 2026

   

   noahgift

   on Sep 17, 2026

   ContributorAuthor

   More actions

   0.69.0 cut precondition (#3445, merged in #3455). From main @ d79a6875b, at 2026-09-17T15:01:34Z:

   $ bash scripts/check_milestone_cut.sh 0.69.0   # exit 1
   ADMITTED paiml/aprender#3080 issue [enhancement,epic] EPIC: release train 0.69.0 — 06x-release-schedule.md §3 (0.69.0) -- the release epic of this train, closed at 06x section 4 step 8
   RED   milestone 0.69.0 (#6): 22 open item(s) -- no tag until each is closed or carried
   

   Per 06x §4 steps 1 and 4 and APR-RELEASE-001 T-0/T-3, the tag waits until this exits 0. Each of the 22 open item(s) has to be closed or carried: gh issue edit N --milestone 0.70.0 (or gh pr edit) plus a slipped_from: 0.69.0 comment. The script prints the exact command for each item. This epic (#3080) is the one admitted item. The train's autopilot is an untracked per-train copy and does not call the gate on its own. Add bash scripts/check_milestone_cut.sh 0.69.0 || die … as the first line of its tag block (gap tracked in #3454).
7. noahgift

   added a sub-issue on Sep 17, 2026

   • release train: move the release autopilot's tag path into the repo — tag step calls scripts/check_milestone_cut.sh and cannot be reached without it #3459
8. noahgift commented on Sep 20, 2026

   

   noahgift

   on Sep 20, 2026

   ContributorAuthor

   More actions

   0.69.0 triage — 2026-09-20, after 0.68.2 shipped

   0.68.2 is on crates.io (74/74, 07:59:49Z, tag v0.68.2 @ 338f1d49b) and Qwen3.5 is validated on the published artifact: cargo install aprender --version 0.68.2 --features cuda, 0.8B/2B/4B/9B/27B × {CPU, CUDA} on lambda (RTX 4090, sm_89, x86_64) and gx10 (GB10, sm_121, aarch64) — 20/20 cells correct, every GPU arm reporting the real device. #3038 closed on that receipt; 35B stays #3512 (0.71).

   Decision 1 — one train, not two. 0.68.3 is folded into 0.69.

   0.68.3's epic #3519 carries the operator's 2026-09-19 goal ("COMPLETE usability of tool calls, fine-tuning (basic), automation of qwen models on pure CUDA"). 0.69's own scheduled G rows (apr finetune --recipe, 7B QLoRA smoke) are the mechanism that delivers #3519's fine-tuning row. Two trains would bid for the same two GPU hosts to build the same value — muda. #3519 is now the 0.69 headline; its fine-tune receipt rows (#2926, #2924, #2906) come with it. 0.68.3 is empty and should be closed as a milestone.

   Decision 2 — the andon cord comes before the feature.

   Three of our own release gates were measured lying today, during 0.68.2's post-publish run. Until they are fixed, every receipt 0.69 produces is worth less than it looks, so they are first and they are cheap:

   #	defect	why first
   #3543	post-publish dogfood cannot pass — version-unpublished is not phase-aware, and the banner says "pre-release" in a post-publish run	the phase that is supposed to discharge DEFERs can never emit GO
   #3544	a DEFER nothing discharges — no evidence/dogfood/<v>/<host>.json since 0.67.0, three releases owed; the hosts step writes a different file, elsewhere, uncommitted	this IS row 69-A1; fixing it is scope, not overhead
   #2730	cbtop reports PASS / ci_result: green over its own grade F	a gate that reports green over its own red
   #3170	apr-agent --help created a worktree and a branch	any flag is accepted as a task slug
   #3541 #3542	apr run prints no Backend: line on the CPU arm, and no tok/s at all	found validating 0.68.2: the CPU arm cannot be proved, and wall time gets misread as a decode rate. Pair with #3543 — same file, same hour

   Decision 3 — the decode-correctness P0s gate the batching bands, so they are scope, not backlog.

   69-F1/F2 ask for c=4/8 VALID and agg(4) ≥ 3 × dec(1). That cannot be honest while:

   • P0: batched CUDA decode emits garbage for every m>1 — PERF-001's 3.32x aggregate is throughput of garbage tokens #2753 batched CUDA decode emits garbage for every m>1 (P0),
   • cuBLAS decode route diverges at m>=4: coherent but different continuation, so c=4 fails parity while c=2 passes #2770 the cuBLAS decode route diverges at m≥4,
   • cublas_prefill_fp8_gemm reads 16 rows of FP8 scratch where 1 was written: the padded tail is the previous GEMM's activations #2765 cublas_prefill_fp8_gemm reads 16 rows of FP8 scratch where 1 was written (P0).

   These three are the long pole of the train. If they do not land, 69-F is cut — we do not publish a band measured on a path that produces garbage.

   Priority order (Toyota Way: stop the line → make the value → fix the system)

   1. P0 andon — The post-publish dogfood CANNOT pass: version-unpublished is not phase-aware and the banner still says pre-release #3543, Make the host-receipt DEFER fail closed — 0.68.2 discharged it by hand, and the gate's first run fabricated 4 host failures from a missing directory #3544 (=69-A1), cbtop reports status PASS and ci_result green over its own grade F when the profiler returns zero bricks #2730, apr-agent accepts any flag as a task slug — 'apr-agent --help' created a worktree, a branch and a claim lockfile #3170, apr run: the --no-gpu arm prints no Backend: line, so the CPU arm cannot be proved (post-publish 0.68.2) #3541, apr run emits no tok/s — every throughput claim from it is wall time including model load (post-publish 0.68.2) #3542
   2. P0 correctness — P0: batched CUDA decode emits garbage for every m>1 — PERF-001's 3.32x aggregate is throughput of garbage tokens #2753, cuBLAS decode route diverges at m>=4: coherent but different continuation, so c=4 fails parity while c=2 passes #2770, cublas_prefill_fp8_gemm reads 16 rows of FP8 scratch where 1 was written: the padded tail is the previous GEMM's activations #2765 (gates 69-F; if red at the cut, 69-F is cut, not waived)
   3. P1 headline — EPIC: release 0.68.3 — COMPLETE usability of Qwen models on pure CUDA: tool calls, basic fine-tuning, automation — every claim a receipt per (model, host) #3519: tool calls · basic fine-tune (T-0: the four WT receipts: Unsloth QLoRA and apr finetune -m qlora on Qwen2.5-7B-Instruct, both hosts, n=5 interleaved, paired at the highest ladder rung apr completes; first two traini #2926 T-2: apr finetune --max-seq-len honoured or refused with one line and the refusal code on every path; the effective value printed and written to the receipt; the wgpu instruct pipeline  #2924 R-3: T-6 honest training banner: -m lora --gpu-backend cuda refuses or trains on the GPU; the cuBLAS-backward line prints only when a cuBLAS backward ran #2906, = 69-G1/G2) · automation, each with a committed receipt per (model, host) on both GPU hosts
   4. P1 train mechanics — release train: move the release autopilot's tag path into the repo — tag step calls scripts/check_milestone_cut.sh and cannot be reached without it #3459 (tag path into the repo), cascade-publish.sh TIERS is not a dependency order — 47 non-dev violations at v0.68.1; it only works through the drain's retries #3462 (TIERS is not a dependency order — 0.68.2 published from a bundle-local publish-order.txt; the in-tree path still carries the defect), docs(release): APR-RELEASE-001 has no must-carry section on main — land §1.5 (must-carry rows; T-0 waits; > 72 h andon) #3446 (§1.5 must-carry on main)
   5. P2 root cause, one milestone only — PP-QUANT-001 M1: one #[repr(u32)] GgmlType (43 rows: 35 live + 8 Removed) + TRAITS[43] below core/compute/serve — ggml enums 3 → 1 #3430 (PP-QUANT-001 M1: one #[repr(u32)] GgmlType). The rest of PP-QUANT/PP-TENSOR (ARCH: quant-type dispatch is duplicated across ~30 files with no single source of truth — propose a dedicated consolidation release #3418 PP-QUANT-001 M3: regression fixtures — #1749 #1789 #2535 #3341 (+ #3091 reopen) on tiny synthetic GGUFs, observed RED→GREEN #3429 PP-QUANT-001 M2: reconciliation gate — GgmlType vs the vendored ggml.h id list at a pinned sha; exhaustive matches, no _ => #3431 PP-TENSOR-001 T1: typed TensorStorage — a dense consumer cannot receive an MoE placeholder #3433 PP-TENSOR-001 T2: sentinel ban — qtype: 0 + byte_size: 0 may not be constructed; 0 is F32 #3434 EPIC: PP-TENSOR-001 — a tensor that has no bytes is a different type from one that does (MoE / tied-embedding placeholders) #3428) moved to 0.70: they are the right fix for the recurring quant-dispatch defects, but they are not a three-day train.
   6. Standing — DP4A Q4K/Q6K GEMV profile is catastrophic through the Gated DeltaNet recurrence — Qwen3.5 on sm_89 needs the float MWV variant (PMAT-806 class) #3513 (DP4A through the GDN recurrence stays pinned off; the falsifier test is the guard)

   Cut from 0.69 (moved, not dropped)

   → 0.70: #3401 #3204 paiml/infra#1144 #3478 #3161 #3466 #3464 #3418 #3428 #3429 #3431 #3433 #3434 #2853 #2507 #2616 #3531 #3522 #3062

   Schedule note

   0.69's window (§1.1) was 2026-09-17→09-18 and 0.70's opens 09-21; 0.68.2 consumed it as an interrupt release. Either re-date 0.69 in 06x-release-schedule.md or let 0.69 take 0.70's slot — carrying a train with an expired window is how the milestone-cut gate goes vacuous. Recommendation: re-date, don't renumber.
9. noahgift

   changed the title [-]EPIC: release train 0.69.0 — 06x-release-schedule.md §3 (0.69.0)[/-] [+]EPIC: release train 0.69.0 — COMPLETE Qwen usability on pure CUDA (all 0.68.x folded in)[/+] on Sep 20, 2026
10. noahgift

    added

    P0Critical priorityCritical priority

    on Sep 20, 2026
11. noahgift commented on Sep 20, 2026

    

    noahgift

    on Sep 20, 2026

    ContributorAuthor

    More actions

    Fleet & CI prerequisites — from the fleet lane (infra-45), measured this week

    Added to the epic after the rebuild. These are prerequisites to 0.69's GPU work, not parallel nice-to-haves.

    #	Item	Acceptance command	Host
    NEW (gx10 disk)	gx10 at 87% (749G/916G, 121G free) with 220G of CI scratch (targets 113G + cargo-ci 107G); set and enforce a gx10 disk budget before 0.69 GPU work	ssh gx10 'df --output=pcent / | tail -1 | tr -cd 0-9' | awk '$1<80'	gx10
    NEW (gx10 deploy visibility)	bin-aprender on gx10 is a github_release pinned to tag: nightly whose completion check is presence-only — forjar reports converged while serving 0.68.2	forjar drift -f machines/gx10/forjar.yaml --state-dir machines/gx10/state | grep -c 'bin-aprender.*DRIFT'	gx10
    #3540	book-contracts.yml: delete the three rust-cache steps — the last aprender site; the shared-cargo-home guard BLOCKs it from today	bash machines/clean-room/shared-home-guard/check.sh aprender .github/workflows/book-contracts.yml | grep -c VIOLATION	intel
    infra#780	sovereign-ci's per-PR CARGO_TARGET_DIR is written by 4 concurrent jobs on one host; re-key to <run-id>/<job> and teach the reaper the new depth in the same PR	bash machines/intel/sovereign-ci/systemd/reaper/test-ci-targets-depth.sh	intel+gx10+yoga
    infra#781	ephemeral runners lack capabilities host runners have (no ~/.ssh #776, no Lean #781) — declare per-job capability and ask each host, not the Dockerfile	bash machines/clean-room/capability-parity.sh --selftest && bash machines/clean-room/capability-parity.sh	intel+gx10+yoga
    NEW (matrix vacuity)	no aprender job targets mini's labels, yet the dogfood gate demands a mini receipt	bash scripts/check_dogfood_matrix_is_visited.sh	mini

    Why gx10 disk is listed above every GPU row: a full disk there does not fail loudly — it fails as corrupted builds and No such file or directory errors that get filed as flakes. 0.69's GPU work is gx10-shaped. This already cost us once: gx10 hit 100% on 2026-09-19 mid-train.

    Why the tag: nightly row matters for a release epic: if "deployed on the fleet" is to mean anything in 0.69, the declaration needs a version the completion check can compare. Today forjar cannot tell you gx10 is on 0.69.

    Ruling on question 1 (#3544's host matrix) — narrow it, and derive the narrowing

    Decided with the fleet lane, and I'm adopting it:

    • Do not emit a mini.json the train never visited. That converts "we do not test on mini" into a green tick — a receipt for a measurement nobody took. The current red is TRUE; a manufactured green is a lie the gate itself produces, which is this fleet's signature defect.
    • Do not hand-maintain a narrowed list either — a constant list drifts from reality and nobody re-reads it.
    • Derive the matrix from the hosts the train actually visits (the labels its jobs select, read from the workflow). A host with no job targeting it is recorded as an explicit NA{reason, decided_by, date} row — declared absence, not silent absence. When paiml/infra#1144 lands and mini gets a job, mini re-enters automatically because the derivation sees the new job, not because someone remembered.
    • The gate fails if the demanded set and the visited set disagree in either direction: demanded-but-not-visited is today's bug, visited-but-not-demanded is tomorrow's.

    And the more serious half, stated plainly: mini is a scoping error. lambda, intel and gx10 having no receipt across two releases is a gate that has not run. Fix that first; mini is then a footnote.
12. noahgift commented on Sep 20, 2026

    

    noahgift

    on Sep 20, 2026

    ContributorAuthor

    More actions

    Release-assets & installer — from the assets lane (infra-98), measured on the published v0.68.2 assets

    Headline finding, escalated to its own P0: #3545. The published -cuda asset prints backend: cuda unavailable reason=NotCompiled source=not-compiled on a 4090 host. Found by the assets lane; the release lane reproduced it and settled the open branch — the asset does run CUDA (apr run … --gpu → Backend: GPU (CUDA, NVIDIA GeForce RTX 4090) [qwen35 hybrid forward, paiml/aprender#3090], correct output, and the binary carries dp4a_q4k_gemv / tensor_core_q4k_gemm / flash_decoding_chunk which the -cpu asset does not). So devices lies; the build is fine. The first command a new user runs tells them our CUDA support does not exist.

    #	Item	Acceptance	Host
    #3545	apr devices reports NotCompiled on a binary that demonstrably runs CUDA	devices --json | jq -e '.entries[]|select(.kind=="cuda")|.source.kind=="compiled-in"' on a -cuda asset, non-zero on -cpu, plus a RED-turning test	lambda, gx10
    NEW	flavour gate on the artifact alone — no GPU, no model needed	strings apr | grep -q libcuda.so.1 PASSes for -cuda, FAILs for -cpu, and devices --json agrees	any host, incl. yoga
    #2869 / PMAT-994	install.sh does not exist — /releases/latest/download/install.sh 404s and nothing in the tree provides it, yet T-2 asserts install.sh --version v0.N.0 on intel and gx10, and the 0.68.0 note says "install.sh verified on intel/gx10"	curl -fsS .../latest/download/install.sh | head -1, then install.sh --version v0.69.0 on a clean HOME	intel, gx10
    #3544	the receipt schema below, written by the autopilot instead of free-text receipts/<host>.txt	jq -e over the committed file	all
    NEW	PP-066 R-6 says the installer's last line is apr devices — on today's assets that line prints a false cuda … not-compiled	R-6 acceptance must read the devices JSON, not just exit 0	all
    NEW	crates/aprender-serve/models/qwen2-0.5b-q4.gguf is 0 bytes	a fixture model is non-empty and loads, or it is deleted	—

    Adopted: what a CUDA asset gate asserts when the host has no GGUF — two tiers

    • Tier 1 (mandatory everywhere, artifact-only): sonames present/absent by flavour, and devices --json agrees. Cheap, runs on yoga, and would have caught apr devices reports 'cuda unavailable reason=NotCompiled' on a binary that demonstrably runs CUDA — the first screen a user sees is wrong #3545.
    • Tier 2 (only where a GPU and a model exist): one real generate, backend line recorded verbatim.
    • No tiny fixture GGUF for this. A fixture that never exercises a CUDA kernel buys a green that means nothing — and the in-tree candidate is 0 bytes anyway. Every host without a model records Tier 1 plus an explicit unmeasured.

    Adopted: the #3544 receipt schema

    {host, arch, version_tested, date, install_rc} plus the fields that let a later reader falsify the claim rather than take it: provenance ∈ {release-asset, crates.io, local-build} and the exact asset filename; sha256_published and sha256_measured as two fields so a match is visible as a match; the apr devices --json entries array verbatim; generate: {model_sha256, backend_line_verbatim, tokens, wall_ms, output_sane} or generate: null with a reason; driver (nvidia-smi + CUDA runtime) and nproc; and a non-empty unmeasured[] naming what this host could not prove.

    "A receipt from a host with no GPU and an empty unmeasured[] is a lie, and that is the only field that makes yoga's receipt worth committing at all." — assets lane

    install.sh is listed as uncovered. Not "covered by a weak check" — there is nothing to cover. Treat R-6 as the work, not the check.

    ---

    Outside-in — from the downstream consumer (apex-c8), measured against the published crate

    Validation closed: nothing failed. apex pinned aprender-viz 0.68.2 from crates.io — cargo update --precise clean, cargo check/test --workspace rc 0, cargo deny check rc 0, and apex#99 green including publish-sim (offline --network none). The .crate was verified independently of the index (sha256 cbd7448685d7…, matching Cargo.lock's registry checksum). 0.68.2 also closed a real gap: 0.68.1's .crate had no src/breaks.rs at all, which is why apex was carrying a git patch.

    #	Item	Acceptance
    NEW	aprender-viz packages fixtures/breaks/ (manifest.json + generate.py) into the published .crate — 396 KB of test fixtures shipped to every consumer, and nobody downstream runs breaks_golden.rs	tar tzf aprender-viz-<v>.crate | grep -c 'fixtures/breaks/' is 0. Pure packaging, no API change — the cheapest row in the epic
    NEW	the crate name and the lib name differ and nothing says so: the package is aprender-viz, but use aprender_viz::… does not compile — it is use trueno_viz::breaks::extended	cargo doc -p aprender-viz front page and the crates.io README both state it in the first screen
    NEW	a consumer-shaped facade: apex wants to draw a chart and transitively compiles aprender-compute, aprender-quant, aprender-gemm-codegen, aprender-contracts-macros	from a scratch bin depending only on the facade, a program calling extended and panels builds, and cargo tree -e normal shows none of those crates
    NEW	aprender-viz is f32, consumers compute in f64, and the narrowing is undocumented and unguarded	a doc example shows the intended narrowing; DataFrame's docs state the f32 domain and what happens outside it (three review lanes flagged mantissa precision loss, point-order retention, subnormal underflow)
    NEW	Facet/Coord have no runnable example — EV-15 (byte-identical SVG across architectures) and EV-16 (unbranded export) have nothing to build against	one examples/ program: study data → panels → Coord::apply → SVG, compiling against the published crate only

    "The single worst guess I had to make" — the aprender-viz / trueno_viz name split. "Every new consumer will hit this in their first five minutes."

    Caveat recorded by the lane itself: apex#99 is green but deliberately unmerged this session pending an apex-side defect (an EV-2a probe whose crates.io call has no User-Agent → 403, so the probe can never pass). That is apex-side and unrelated to this train; the build and resolve evidence above stands on its own.
13. noahgift commented on Sep 20, 2026

    

    noahgift

    on Sep 20, 2026

    ContributorAuthor

    More actions

    0.68.2 train debt — from the train lane (aprender-bf), measured 2026-09-20

    The train that just shipped still owes two receipts. Both are the release lane's to write, today, and both are listed here so the debt is visible in the milestone Noah's team reviews rather than living in a session.

    #	Item	Acceptance	State
    NEW	T-5 reconcile receipt for v0.68.2 is not written — docs/build-ledger/ on main has 2026-09-16/17/18 and nothing for 09-19/20	test -f docs/build-ledger/2026-09-20/338f1d49b-reconcile.json and every §6 predicate reads 0	OWED — hard gate (operator 2026-09-13); the train has no DONE line without it
    NEW	train ledger record (ledger.py) not written	the row committed	OWED, same close-out batch
    #3544	host receipts	check_multiplatform_dogfood.sh exit 0 against committed receipts	the autopilot's hosts step was running at the time of this report; if it discharges, 0.68.2 becomes the first train since 0.67.0 with host receipts, and #3544 changes shape — from "nobody ever ran it" to "make the DEFER fail closed"
    #3462 + #3459	same fix, not two: in-tree cascade-publish.sh TIERS is not a dependency order (47 non-dev violations), which is why 0.68.2 published from a bundle-local publish-order.txt + publish_strict.sh. #3459 (move the tag path in-tree) is the vehicle; #3462 is the defect	scripts/cascade-publish.sh --order-check exits 0 against the tag	the drain only works through retries — 8 passes today
    #3541 #3542	apr run prints no tok/s and no Backend: line on the CPU arm	already filed from the gx10 measurement	now docketed

    On #3459, the argument in one line: the autopilot (autopilot.sh, publish_strict.sh, t2_preflight.sh, publish-order.txt) is bundle-local and unversioned, and today a stale STOP-FOR-OPERATOR line in it — contradicting the very spec revision it cited — was corrected by hand at 07:30Z in a file no PR has ever reviewed. A release train whose control flow is not in the repo is not reviewable, and the correction proves it.

    Deferrals audit: the only conscious deferrals from 0.68.2 with no ticket were the two rows above plus #3486 (qwen3-8b's optional rung, already ticketed). Nothing else was deferred silently — which is the answer #3544 exists to make routine.
14. 19 remaining items

    Load more
15. noahgift

    closed this as completedon Sep 24, 2026
16. guyernest

    added 13 commits that reference this issue on Sep 29, 2026

    PMAT-3445: no tag while the milestone being cut holds an open item — …

    ...

    d79a687

    PP-LLAMA-001 row 2: the perf002 prefill-path probe, with refusals tha…

    ...

    aff11bd

    roadmap: push the five tickets minted today (they existed only in a w…

    ...

    ddb5a15

    PMAT-3459 part 2: port the tag path into the repo — autopilot.sh + 2,…

    ...

    00e5d2d

    PMAT-3587: fail-fast discards verdicts — the default flips, and skipp…

    ...

    11a1038

    PMAT-3561: the T-0 preflight returned GO when the dogfood crashed — G…

    ...

    e6f77c9

    PMAT-3459: the tag step cannot be reached without a clean milestone —…

    ...

    6a657fc

    PMAT-3567: the shapes gate on the FLEET-PINNED pv, on the runner it e…

    ...

    82c64c6

    paiml#3545: apr devices told every user CUDA was unavailable on a bin…

    ...

    8a6c1af

    PMAT-3459 + PMAT-3460: register the in-repo tag-path ticket (P0, 0.69…

    ...

    888b526

    release(0.69): batch — 15 receipted PRs + fleet-pv andon fix, one CI …

    ...

    a877fa0

    PMAT-3685: apr parity REFUSES (exit 12) a model the CUDA capability g…

    ...

    5f9bd93

    release(0.69.1): batch 1 — 20 receipted rows + 3 combination fixes, o…

    ...

    8c7822f
17. noahgift

    removed a sub-issue on Oct 4, 2026

    • release train: move the release autopilot's tag path into the repo — tag step calls scripts/check_milestone_cut.sh and cannot be reached without it #3459