RQ-71-MUSL (#1349): ship a static musl Linux asset, prove it builds on every PR — and correct a release doc that has been false since v0.58 by avrabe · Pull Request #1357 · pulseengine/synth

avrabe · 2026-09-23T04:22:41Z

Both refuting commands were re-run first, and both confirmed the premise

The v0.70.0 asset, the moment it published — if the floor had already dropped,
the runner image moved and the premise needed re-measuring. It had not:

$ file synth
ELF 64-bit LSB pie executable, dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2
$ strings -a synth | grep -oE 'GLIBC_[0-9.]+' | sort -V | tail -1
GLIBC_2.39

grep -n musl .github/workflows/*.yml — one hit, in fuzz-smoke.yml, and it
is there to force the GNU target because cargo-fuzz defaults to musl. So no musl
release target existed: this is the larger of the two lanes the plan distinguished
(adding a target, not publishing one already built).

2.39 excludes Ubuntu 22.04 (2.35), Debian 12 (2.36), RHEL 9 / AL2023 (2.34),
Ubuntu 20.04 (2.31) and Alpine entirely. These feed the varve pulseengine rolling
layer, and a layer's portability is the MAXIMUM floor across its payloads — one
payload sets it for everything pinned beside it.

What ships

x86_64-unknown-linux-musl, statically linked — no loader and no glibc floor at
all, rather than a lower one. Additive: the gnu assets keep their names, their
consumers and their attestation path, so nothing that works today changes. No cross
container needed (the workspace has no build.rs and no [build-dependencies]).

The part that isn't plumbing

release.yml runs only on a tag push, so a target added there is unverified
until the tag — and editing the release workflow between an RC and its tag is
exactly the unreviewed late change this process exists to prevent. (v0.70 shipped
the 2.39 floor rather than make one.)

So a per-PR job, musl-portable-asset, builds the same target with the same
feature set and runs the issue's own two acceptance commands on the result:
statically linked, no interpreter, zero GLIBC_ symbols. The release.yml
entry is verified by construction, not on the day it matters.

With a potency control, because "is static" and "has no GLIBC_ symbols" are
assertions that could pass on anything: the same job builds the gnu target on
the same runner and asserts those checks fail there. If they ever pass on both,
the musl check proves nothing and the job says so.

The job is deliberately not a required context — a required name that has never
run deadlocks merges.

A false doc statement found on the way

docs/release-process.md said the verify feature is "not enabled" in release
builds and that enabling it "remains a deliberate follow-up decision".

That decision was taken in v0.58 — RQ-58-SHIPVERIFY (#1000, PR #1002) put
--features verify on both the native and cross build lines. The sentence had
been false for thirteen releases. Measured on the shipped v0.70.0 asset: 20
ordeal strings present, zero occurrences of the degraded-path message — so
synth verify works in a released binary. Corrected in place, with the correction
stated rather than silently overwritten.

Nobody would have found this from the workflow alone; it surfaced because this lane
had to read what the release actually builds.

Residual, named rather than implied

arm64 Linux is still glibc-floored. Only the x86_64 musl asset is published;
aarch64-unknown-linux-musl needs the cross path and its own measurement, and is
not claimed here.

Gates

claim_check ✅ · status_evidence ✅ · oracle_wiring ✅ · artifact_citation ✅
· check_version_pins ✅

Refs #1349

… every PR RQ-71-MUSL (#1349). Both refuting commands were re-run first and BOTH confirmed the premise: * the v0.70.0 x86_64 asset, downloaded and measured with the issue's own two commands — dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, max of 17 GLIBC_ symbols = GLIBC_2.39. The runner image did not move under us; * `grep musl .github/workflows/*.yml` — one hit, in fuzz-smoke.yml, and it is there to FORCE the GNU target. No musl release target existed. 2.39 excludes Ubuntu 22.04, Debian 12, RHEL 9, Amazon Linux 2023, Ubuntu 20.04 and Alpine entirely. These feed the varve `pulseengine` rolling layer, whose portability is the MAXIMUM floor across its payloads — one payload sets it for everything pinned beside it. `x86_64-unknown-linux-musl`, statically linked: no loader, no glibc floor at all rather than a lower one. ADDITIVE — the gnu assets keep their names, consumers and attestation path, so nothing that works today changes. THE PART THAT IS NOT PLUMBING. release.yml runs only on a TAG PUSH, so a target added there is unverified until the tag, and editing the release workflow between an RC and its tag is the unreviewed late change this process exists to prevent. So a per-PR job (`musl-portable-asset`) builds the same target with the same feature set and runs the issue's two acceptance commands on the result: statically linked, no interpreter, ZERO GLIBC_ symbols. WITH A POTENCY CONTROL, because those assertions could pass on anything: the same job builds the GNU target on the same runner and asserts they FAIL there. A FALSE DOC STATEMENT FOUND ON THE WAY, corrected in place. `docs/release-process.md` said the `verify` feature is "not" enabled in release builds and that enabling it "remains a deliberate follow-up decision". It was taken in v0.58 (RQ-58-SHIPVERIFY #1000/#1002, which put `--features verify` on both build lines), so the sentence had been false for thirteen releases. Measured on the shipped v0.70.0 asset: 20 `ordeal` strings, ZERO occurrences of the degraded-path message. RESIDUAL, NAMED: arm64 Linux is still glibc-floored. Only the x86_64 musl asset is published; aarch64-unknown-linux-musl needs the cross path and its own measurement, and is not claimed. Refs #1349

…elease notes RQ-70-RIVETNOTES (#1337) shipped `release_notes_from_rivet.py` in v0.70 to derive the CHANGELOG's artifact section instead of re-typing it. Its modified-artifact path had never run. `rivet diff` reports `added` and `removed` as bare id STRINGS but `modified` as `{"id": ..., "changes": [...]}`. The renderer f-stringed the entry directly, so running it for THIS release printed: - *(modified)* **{'changes': ['field changed: issue-scope'], 'id': 'RQ-70-NPA'}** straight into the notes. v0.71 is the first release to modify a PRIOR release's artifact — RQ-71-ISSUESCOPE applies `issue-scope: outlives` to RQ-70-NPA and RQ-70-FALCONCORPUS — so the defect shipped behind a code path nothing reached. Same shape as the four gates v0.70 found that could not fail, one layer out: a renderer arm that could not render. Found by running the derivation against a SIMULATION of the merged tree before cutting, rather than discovering it in the CHANGELOG. The `changes` list is kept rather than dropped — "which field moved on a shipped artifact" is what a reader of a release note actually needs, and it is why a modified entry is richer than an added one: - *(modified)* **RQ-70-FALCONCORPUS** — field changed: issue-scope - *(modified)* **RQ-70-NPA** — field changed: issue-scope Refs #1337

…uash subject MEASURED at the #1356 merge, which reddened main. `gh pr merge --squash` uses the PR TITLE as the subject only when the branch has MORE THAN ONE commit; with exactly one it uses THAT COMMIT'S subject. #1356 had one commit, so main landed feat(issuescope): let an artifact say its ISSUE outlives its delivery ... (#1356) while the four-check ritual's CHECK4 had simulated the PR title "RQ-71-ISSUESCOPE (#1250): ...". The gate passed on a tree that was never created, and main went red on R10 — a delivery-shaped commit attributable to no artifact. Exactly v0.70's squash-simulation lesson, one level deeper: it is not enough to simulate a squash, the simulated SUBJECT has to be the one that will actually land. Two fixes, and only the second is durable: * RQ-71-ISSUESCOPE `landed:` now names PR #1356, and RQ-71-MUSL names #1357. R10 accepts EITHER an artifact id / issue number in the subject OR an artifact whose `landed:` names the PR. Naming the PR makes attribution independent of whatever subject GitHub chooses — the general fix, applied here to both. * the merge ritual now passes `gh pr merge --subject "<pr title> (#N)"`, so the simulated tree and the real one agree BY CONSTRUCTION rather than by a prediction of GitHub's default. Never simulate one subject and merge another. Refs #1250, #1349

…ner pool Two corrections to RQ-71-MUSL, one from the v0.71 cold review and one from the maintainer. Both are recorded in the artifact rather than quietly applied. 1. THE GATE COULD NOT PASS — the class this release keeps finding, this time built by me. The acceptance step asserted file "$BIN" | grep -q 'statically linked' rustc's musl target NEVER produces that string. Its spec sets `crt-static-default` AND `static-position-independent-executables`, so the link is `-static-pie` and `file` reports "static-pie linked". The gate would have REFUSED A CORRECT ARTIFACT — and `create-release` has `needs: [build-binaries]`, so that is not one missing archive, it is NO RELEASE AT ALL. A gate that cannot pass, in the workflow that publishes the release, in the lane whose entire point is that the asset is checkable. The fix is not a better string. `file`'s wording is a presentation detail of a tool this repo does not control; the PROPERTY is "asks no loader to run it", which is exactly "no PT_INTERP program header". `scripts/elf_static_check.py` reads it from the ELF with nothing beyond the stdlib, and was validated BOTH ways before being wired: the real published v0.70.0 gnu asset -> PT_INTERP=1, GLIBC_ x17, rc=1 a synthesised static-pie shape -> PT_INTERP=0, GLIBC_ x0, rc=0 The potency control was widened with it: the gnu leg now runs the SAME check and must FAIL it, so BOTH assertions have a negative control. Previously the gnu block never asserted a loader was present, so the musl `interpreter` assertion had none. 2. THE RUNNER POOL — raised by the maintainer while this very PR sat queued. I put the job on `ubuntu-latest` by copying the surrounding convention without thinking about capacity. Measured: 56 of ci.yml's 67 jobs target `ubuntu-latest` and only 8 use self-hosted, which is exactly what RQ-61-CICAP identified as THE bottleneck — runs queue for hours beside idle machines because the constraint is the GitHub-hosted quota, not the fleet. Adding another ubuntu-latest job makes that worse for every other lane. Now `[self-hosted, linux, x64, rust-cpu]`. The apt step is conditional and non-fatal: whether rust's bundled musl crt and `rust-lld` make `musl-tools` unnecessary for a pure-Rust workspace is UNVERIFIED here — it cannot be checked on this macOS host (no musl std, no nightly for `--print target-spec-json`) — so it is not asserted either way, and the build step is left to answer it loudly. Refs #1349

…ot asserted The v0.71 prose-truth cold review found three defects in this lane. The first is the one that matters, because it broke the predecessor's own done-when. RQ-71-ARCHMODEL claimed "THE COUNT IS THE CHAIN, WALKED" while citing `grep -rln ARCHMODEL artifacts/` — a FILENAME grep, not a chain walk — and the artifact carried NO `carried-from` field, so the chain ran v0.63..v0.70 and stopped short of it. RQ-70-ARCHMODEL's done-when reads, verbatim: "the carried-from chain is extended rather than an ordinal asserted". Asserting the ordinal is exactly what the predecessor forbade, and this artifact's TITLE asserted it. That is the v0.70 lesson failing in the direction it warned about: written from the predecessor's SHAPE rather than its CORRECTION. Fixed in the FIELD, not the prose: `carried-from: RQ-70-ARCHMODEL`. The chain now walks mechanically to the v0.63 head: RQ-71 -> RQ-70 -> RQ-69 -> RQ-68 -> RQ-67 -> RQ-66 -> RQ-65 -> RQ-64 -> RQ-63 chain length 9 The count of nine was right all along; the method claimed for it was not, which is the harder defect to see — and the only reason it survived is that the wrong method produced the right answer. Also corrected, both re-derived: * the grep's exception list named TWO of four. v0.62's RQ-62-LOOPCONFORM, v0.68's RQ-68-STATUSGATE and v0.70's RQ-70-DONEWHEN all mention ARCHMODEL without being one; the `_release.yaml` hits from v0.64 on are plan prose. * RQ-71-PAGELIB said "all five call sites" while its own enumeration lists 2088-2089, 3975-3976 and 4209-4210 — SIX calls at THREE sites, the two refusals always invoked as a pair. A sentence contradicted by the numbers inside it. * `_release.yaml` said "fifth consecutive N/A" against the artifact's ninth. The artifact is the authority and now derives its count; the plan line is corrected rather than left to contradict it. Verified after the edits: `loop_conformance_check v0.71.0` still reports step 1-2 NA-FILED naming RQ-71-ARCHMODEL (the tags are untouched and remain load-bearing), claim_check 75/75, status_evidence clean but for main's inherited #1356 R10 which PR #1357 fixes. Refs #1136, #1339

The v0.71 prose-truth cold review checked this number and it is wrong in both readings. Re-derived on the downloaded v0.70.0 x86_64 asset: case-sensitive b"ordeal" -> 19 case-insensitive -> 21 "20" is neither. The figure appeared twice — in RQ-71-MUSL and in the docs/release-process.md paragraph this lane corrected — so it is fixed in both, with the counting method stated so the next reader can reproduce it rather than guess which convention produced the number. The load-bearing half of that sentence is unaffected and was independently re-verified: ZERO occurrences of the degraded-path message, which is what shows `synth verify` genuinely works in a released binary and that the doc claiming `--features verify` is off had been false since v0.58. Refs #1349

codecov · 2026-09-23T06:46:27Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

…ot asserted The v0.71 prose-truth cold review found three defects in this lane. The first is the one that matters, because it broke the predecessor's own done-when. RQ-71-ARCHMODEL claimed "THE COUNT IS THE CHAIN, WALKED" while citing `grep -rln ARCHMODEL artifacts/` — a FILENAME grep, not a chain walk — and the artifact carried NO `carried-from` field, so the chain ran v0.63..v0.70 and stopped short of it. RQ-70-ARCHMODEL's done-when reads, verbatim: "the carried-from chain is extended rather than an ordinal asserted". Asserting the ordinal is exactly what the predecessor forbade, and this artifact's TITLE asserted it. That is the v0.70 lesson failing in the direction it warned about: written from the predecessor's SHAPE rather than its CORRECTION. Fixed in the FIELD, not the prose: `carried-from: RQ-70-ARCHMODEL`. The chain now walks mechanically to the v0.63 head: RQ-71 -> RQ-70 -> RQ-69 -> RQ-68 -> RQ-67 -> RQ-66 -> RQ-65 -> RQ-64 -> RQ-63 chain length 9 The count of nine was right all along; the method claimed for it was not, which is the harder defect to see — and the only reason it survived is that the wrong method produced the right answer. Also corrected, both re-derived: * the grep's exception list named TWO of four. v0.62's RQ-62-LOOPCONFORM, v0.68's RQ-68-STATUSGATE and v0.70's RQ-70-DONEWHEN all mention ARCHMODEL without being one; the `_release.yaml` hits from v0.64 on are plan prose. * RQ-71-PAGELIB said "all five call sites" while its own enumeration lists 2088-2089, 3975-3976 and 4209-4210 — SIX calls at THREE sites, the two refusals always invoked as a pair. A sentence contradicted by the numbers inside it. * `_release.yaml` said "fifth consecutive N/A" against the artifact's ninth. The artifact is the authority and now derives its count; the plan line is corrected rather than left to contradict it. Verified after the edits: `loop_conformance_check v0.71.0` still reports step 1-2 NA-FILED naming RQ-71-ARCHMODEL (the tags are untouched and remain load-bearing), claim_check 75/75, status_evidence clean but for main's inherited #1356 R10 which PR #1357 fixes. Refs #1136, #1339

…ts re-measured at the cut — and gale's answer on #1145 settles PAGELIB the other way (#1358) * docs(carried): re-verify both carried artifacts AT THE CUT — and gale's answer settles PAGELIB RQ-71-PAGELIB (#1339) + RQ-71-ARCHMODEL (#1136). Both were carried on the condition that they be RE-MEASURED at the v0.71 cut rather than restated. PAGELIB — the measurement holds, and the CONSULTATION IS ANSWERED. Re-verified 2026-09-23: both definitions and all five call sites of `refuse_custom_page_size`/`refuse_shared_memory` are still in synth-cli (main.rs 3701/3749, called at 2088-9, 3975-6, 4209-10); synth-core's wasm_decoder still only DECODES (`page_size_log2` at 67, assigned at 1141) and its comment still points at the CLI. But the plan said CONSULT #1145 BEFORE SCOPING, and gale answered there on 2026-09-22 — not "not yet" but "do not do this": "Does gale call synth-core as a library? NO — CLI only ... the published- library gap is real but gale is not standing in it." "Refused or honoured? HONOURED — and please do not spend the effort on relocating the refusal. Refusing in the library closes a door gale wants open. The CLI refusal you shipped is exactly right as an interim." So the deferral changes KIND: v0.70 deferred because the shape was unknown; v0.71 defers because the only known downstream consumer asked for the opposite and gave the reason. Shipping the planned fix would have repeated v0.68's error of scoping a refusal against a need nobody had. What would re-open it is named: a synth-core library consumer that is NOT gale. ARCHMODEL — spar#445 RE-VERIFIED at the cut with the date recorded: OPEN, created 2026-09-03, LAST UPDATED 2026-09-03, checked 2026-09-23 — untouched for twenty days. The chain is WALKED, not recalled: `grep -rln ARCHMODEL artifacts/` gives one ARCHMODEL artifact for each of v0.63..v0.71 — NINE consecutive releases. And the sentence that keeps coming back is NOT restated. "Release artifacts only exist from v0.63" is FALSE — measured on this tree, release-v0.56.yaml through release-v0.60.yaml exist as files and release-v0.61/ onward as directories. The chain starts at v0.63 because that is when ARCHMODEL was first FILED. It was retracted in RQ-69-ARCHMODEL and came back in RQ-70-ARCHMODEL; the refutation is restated here WITH the command that produces it, because a retraction living only in last release's prose is one copy-paste from being un-retracted. Tags checked against the gate's actual predicate rather than inherited: loop_conformance_check reports the steps-1-2 slot NA-FILED naming RQ-71-ARCHMODEL (#1136). Refs #1339, #1136 * docs(carried): cold-review corrections — the chain is now EXTENDED, not asserted The v0.71 prose-truth cold review found three defects in this lane. The first is the one that matters, because it broke the predecessor's own done-when. RQ-71-ARCHMODEL claimed "THE COUNT IS THE CHAIN, WALKED" while citing `grep -rln ARCHMODEL artifacts/` — a FILENAME grep, not a chain walk — and the artifact carried NO `carried-from` field, so the chain ran v0.63..v0.70 and stopped short of it. RQ-70-ARCHMODEL's done-when reads, verbatim: "the carried-from chain is extended rather than an ordinal asserted". Asserting the ordinal is exactly what the predecessor forbade, and this artifact's TITLE asserted it. That is the v0.70 lesson failing in the direction it warned about: written from the predecessor's SHAPE rather than its CORRECTION. Fixed in the FIELD, not the prose: `carried-from: RQ-70-ARCHMODEL`. The chain now walks mechanically to the v0.63 head: RQ-71 -> RQ-70 -> RQ-69 -> RQ-68 -> RQ-67 -> RQ-66 -> RQ-65 -> RQ-64 -> RQ-63 chain length 9 The count of nine was right all along; the method claimed for it was not, which is the harder defect to see — and the only reason it survived is that the wrong method produced the right answer. Also corrected, both re-derived: * the grep's exception list named TWO of four. v0.62's RQ-62-LOOPCONFORM, v0.68's RQ-68-STATUSGATE and v0.70's RQ-70-DONEWHEN all mention ARCHMODEL without being one; the `_release.yaml` hits from v0.64 on are plan prose. * RQ-71-PAGELIB said "all five call sites" while its own enumeration lists 2088-2089, 3975-3976 and 4209-4210 — SIX calls at THREE sites, the two refusals always invoked as a pair. A sentence contradicted by the numbers inside it. * `_release.yaml` said "fifth consecutive N/A" against the artifact's ninth. The artifact is the authority and now derives its count; the plan line is corrected rather than left to contradict it. Verified after the edits: `loop_conformance_check v0.71.0` still reports step 1-2 NA-FILED naming RQ-71-ARCHMODEL (the tags are untouched and remain load-bearing), claim_check 75/75, status_evidence clean but for main's inherited #1356 R10 which PR #1357 fixes. Refs #1136, #1339 * fix(#1339,#1136): record the increment in `landed:` so R4 can see a DEFERRAL CHECK4's squash simulation refused this merge, correctly: FAIL R4 RQ-71-PAGELIB: delivery commit on main (RQ-71-PAGELIB (#1339) + RQ-71-ARCHMODEL (#1136) / PR #1358) but status is `proposed` and `landed:` does not acknowledge it — flip the status or record the increment R4 reads the PR TITLE, which names both artifacts, as a delivery claim. It is not one: both are DEFERRALS. `_acknowledge` accepts either a claiming status or a `landed:` containing the PR number GitHub appends (`prs[-1]` = 1358), and neither artifact had a `landed:` at all. Flipping the status would be a lie — nothing was delivered. So the increment is RECORDED instead, which is the other branch R4 offers and the honest one: PAGELIB NOT LANDED as a fix. The refusal stays CLI-only and, per gale on #1145, must NOT move into synth-core. What landed is the re-verification at the cut and the consultation gale's answer settled — so the deferral changed KIND rather than repeating. ARCHMODEL NOT LANDED as a fix. spar#445 is still OPEN. What landed is the state re-verified with the date recorded, and `carried-from: RQ-70-ARCHMODEL` added so the chain is WALKED rather than an ordinal asserted — which RQ-70-ARCHMODEL's done-when required and this artifact had failed to do. R11 is satisfied because both carry `disposition: deferred`; its objection is to a `landed:` beside a non-claiming status with NO disposition. Refs #1339, #1136

avrabe added 2 commits September 23, 2026 06:41

avrabe force-pushed the feat/musl-1349 branch from 9c0b1a2 to dc52f42 Compare September 23, 2026 04:41

avrabe added 2 commits September 23, 2026 06:43

avrabe merged commit f22a328 into main Sep 23, 2026
70 checks passed

avrabe deleted the feat/musl-1349 branch September 23, 2026 07:42

Navigation Menu

RQ-71-MUSL (#1349): ship a static musl Linux asset, prove it builds on every PR — and correct a release doc that has been false since v0.58 - #1357

RQ-71-MUSL (#1349): ship a static musl Linux asset, prove it builds on every PR — and correct a release doc that has been false since v0.58#1357
avrabe merged 5 commits into
mainfrom
feat/musl-1349

avrabe commented Sep 23, 2026

Uh oh!

codecov Bot commented Sep 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

avrabe commented Sep 23, 2026

Both refuting commands were re-run first, and both confirmed the premise

What ships

The part that isn't plumbing

A false doc statement found on the way

Residual, named rather than implied

Gates

Uh oh!

codecov Bot commented Sep 23, 2026

Codecov Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant