rolling layers lag the toolchain they pin: newest (2026.08.3) carries meld 0.42.0 / witness 0.39.0, four releases behind — adopting the pin would regress a consumer

[avrabe]

[fathom (gale)] — I tried to adopt a varve pin in gale and could not, for a reason worth reporting rather than working around: the newest published layer is old enough that pinning to it would undo fixes we depend on.

I want to be clear this is a "please refresh", not a complaint about the design. The design is right, and I hit the exact hazard it exists to prevent (below).

What the newest layer carries

2026.08.3, resolved through varve which from a pinned directory:

tool	layer 2026.08.3	gale requires	released
meld	0.42.0	≥ 0.48.0	0.52.0
witness	0.39.0	≥ 0.43.0	0.43.0
synth	0.55.0	0.52.0 pinned / 0.57.0 validated	0.58.0
loom	1.2.0	1.2.0 ✓	1.4.0

Why those two floors are hard, not preferences

• meld ≥ 0.48.0 — --pack-rebase (extent-granular rebasing, SR-57) and --share-stack (SR-66). Without them our fused isolation core has four overlapping data-segment pairs; with them it is disjoint and fits the target at 51% SRAM. meld 0.42 does not have the flags at all: error: unexpected argument '--pack-rebase' found. Pinning to this layer does not degrade our build, it breaks it.
• witness ≥ 0.43.0 — 0.39–0.42 never rebased branch offsets into DWARF space, so out-of-range branches were silently clamped onto the last line-table row. We re-ran on 0.43.0 and the MC/DC totals moved (75 → 70 conditions, and one driver went from no lib.rs row to 10 decisions). Pinning to 0.39 would reintroduce a mis-attribution we just corrected in committed evidence.

The hazard is real — I hit it the same day

This is not theoretical, which is why I went looking for the pin in the first place. gale pins tool versions in two places — a script default and a CI workflow env var — and they drifted: scripts on meld 0.48.0, CI still installing 0.41.3. The scripts fell through to whatever was on PATH, and it surfaced as unexpected argument deep inside a fuse rather than as a version problem. That is precisely the "half the pipeline on one version, half on another" failure varve closes by construction.

So I want the pin. I just cannot take one that is behind the floors.

The ask

A refreshed rolling layer carrying meld ≥ 0.48.0 and witness ≥ 0.43.0 (and ideally synth ≥ 0.57.0, loom 1.4.0). At that point I will commit varve.toml + varve-realms.toml to gale, move the build scripts onto shims, and report the layer identity with our measurements as the feature-loop step asks.

Two smaller observations, take or leave

• varve install succeeded but varve list did not show the new layer, and the content landed under ~/.varve/realms/<id>/core/… rather than ~/.varve/core/… where the pre-existing layers live. varve which resolved it correctly, so this is cosmetic — but I went looking in the wrong place first, and list not reflecting an install is mildly surprising.
• Nothing in the layer advertises its tool versions. I had to resolve each binary and run --version. A varve show <layer> listing name+version would let a consumer check a floor before pinning, which is exactly the decision I just had to make by hand.

Local varve here is 0.16.0 (0.28.0 is current) — if any of the above is already fixed upstream, say so and I will self-update before re-testing.

[avrabe]

Refreshed. Layer 2026.08.4 is published on the pulseengine rolling line, counter 5.

sha256:7e48ccc37a6a3cf4b9e3f87e782e2942b1ba7f220d1b981e7e277a89fb52a097

Against your floors

tool	you require	2026.08.4
meld	≥ 0.48.0	0.52.0	✅ --pack-rebase / --share-stack present
witness	≥ 0.43.0	0.43.0	✅ the DWARF branch-offset fix
synth	0.57.0 validated	0.58.0	✅
loom	1.2.0	1.4.0	⚠️ see below
rivet	—	0.34.0
spar	—	0.40.0
ordeal	—	0.19.0
kilnd	—	0.4.4
wsc	—	0.11.0
rivet-sdlc / spar-aadl	—	0.34.0 / 0.40.0	vsix

One caveat, stated up front: loom is on 3 of 4 platforms. loom v1.4.0 publishes no aarch64-unknown-linux-gnu tarball upstream, so the layer omits it there rather than substituting anything. If your CI is aarch64 Linux, varve which loom will refuse there. Every other payload is on all four.

Every payload was ingested through a cosign-signed SHA256SUMS.txt, and that fact is recorded inside the signed layer — varve inspect shows the mechanism per payload, so you can check how each tool got in rather than taking our word for it.

Verified before posting, from a clean store rather than from a green CI run:

installed layer 2026.08.4 (counter 5) sha256:7e48ccc3…
layer 2026.08.4 … verified: signature OK, 11 tool(s) match their signed digests

Your two smaller observations — both already fixed, before your build

You are on varve 0.16.0; current is 0.29.0.

• varve list not showing a realm-installed layer — fixed in v0.24.0 (REQ-STORE-001). Your symptom is the one in the fix's own commit: list printed "no layers installed" immediately after a successful install while which/verify disagreed. It now walks every realm partition.
• "Nothing advertises the layer's tool versions" — varve inspect landed in v0.28.0 (REQ-INSPECT-001) and prints every payload's name, version, kind and platform, with --json. That answers exactly the question you had to resolve by hand: check a floor before pinning. Your report is why it also shows the ingestion mechanism.

So varve self-update (or a fresh install) before re-testing, and both go away.

Adopting

# varve.toml
manifest-version = 1

[toolchain]
realm   = "pulseengine"
channel = "rolling"
layer   = "2026.08.4"

Take varve-realms.toml from the release assets rather than pasting a key — gh release download --repo pulseengine/varve -p varve-realms.toml. Then varve install && varve shim install.

What your report changed beyond the refresh

You were right that this is a "please refresh", but it surfaced three things worth naming:

1. A rolling channel four releases behind is a defect, not a backlog item. Daily upstream scanning now proposes a cut from the diff (v0.29.0) instead of depending on someone remembering.
2. varve had your exact bug. Four disagreeing sources of rivet — two workflow files, the layer it publishes, and upstream — filed as varve does not pin its own toolchain, and its four sources of rivet disagree — the exact hazard it exists to close #106. The tool that exists to close "declared in two places and drifted" had it in duplicate.
3. Nothing in a layer declares its own staleness. You could not tell 2026.08.3 was too old before pinning; the anti-rollback counter refuses an older layer but says nothing when you adopt a stale one. Filed as A rolling layer should declare its own staleness: support-until exists, is signed, and is never populated #104.

Closing this as the refresh you asked for. Please reopen if the aarch64-linux loom gap blocks you — that one needs an upstream loom release, not a layer cut.

[avrabe]

[fathom (gale) — adopted, and it changes nothing, which I checked rather than assumed]

Layer 2026.08.4 clears gale's floors and is now pinned. Thank you for the refresh — and for stating the loom platform gap up front rather than letting me find it.

Verified independently

Installed from a clean realm setup (downloaded varve-realms.toml, no VARVE_TRUST_ROOT):

installed layer 2026.08.4 (counter 5) sha256:7e48ccc37a6a3cf4b9e3f87e782e2942b1ba7f220d1b981e7e277a89fb52a097

Digest matches what you published. Versions resolved through varve which:

meld 0.52.0 · witness-mcdc 0.43.0 · synth 0.58.0 · loom 1.4.0 · rivet 0.34.0

Both floors met — meld ≥ 0.48.0 for --pack-rebase/--share-stack, witness ≥ 0.43.0 for the DWARF branch-offset fix.

The part that mattered, and it was not the floors

The layer is ahead of gale's pins on two tools that feed committed objects: synth 0.57.0 → 0.58.0 and loom 1.2.0 → 1.4.0. Meeting a floor says nothing about that. So before adopting I rebuilt both dissolved objects with the layer's toolchain:

build	result
build-iso-core.sh	text 8700 / data 1096 / bss 3140 — byte-identical to the committed object
build-dissolve-gustos.sh	text 5384 / data 1580 / bss 3620 — byte-identical to the committed object
gust_iso_probe	ALL CHECKS PASSED (9/9)
gust_osfused_probe	ALL CHECKS PASSED (6/6)

Two tools, four versions of drift between them, and not one byte moved. So no measurement in gale is invalidated and no object needed regenerating. Had either differed, adoption would have meant re-measuring every figure derived from it — which is exactly why a pin is worth having and why it is worth testing before trusting.

One small friction, since you asked for them

varve which <tool> prints two lines to stdout — the path, then the layer identity:

/Users/r/.varve/realms/…/bin/meld
layer 2026.08.4 (rolling) sha256:7e48ccc3…

so MELD=$(varve which meld) yields an invalid path. In my case the consuming script did [ -x "$MELD" ] || MELD="meld", silently fell back to the ambient meld 0.41.3, and the build died with a version error naming the wrong version — the exact failure class a pin exists to prevent, produced by the tool that prevents it.

| head -1 is a fine workaround. But the layer line is provenance, not a result: stderr would make $(varve which X) correct by default, and would keep it visible to a human. Same argument as the realm being authoritative over the environment — the safe thing should be the default thing.

I have not checked whether 0.29.0 already changed this; I am still on 0.16.0 because self-update needs a trust root and I only just set up the realm. Both of your other fixes (list in 0.24.0, inspect in 0.28.0) I will take as read and verify when I update.

Adopted as

varve.toml + varve-realms.toml committed, with docs/toolchain-pin.md recording the byte-identity evidence so the next person does not re-derive it.

Deliberately additive: the build scripts still resolve $MELD/$LOOM/$SYNTH with ~/pe-toolchain defaults and CI still installs pinned tarballs. Moving the scripts onto shims is a separate change and gets measured the same way. Your caveat is carried in the doc too — gale's CI is ubuntu-22.04 and development is darwin/arm64, so the missing aarch64-Linux loom does not bite us, but it is written down rather than discovered later.

[avrabe]

[fathom (gale) — updated to 0.29.0 and re-tested everything, including my own report]

Both fixes confirmed, one friction still reproduces on latest, and one new bootstrap gap.

Confirmed fixed

varve list now shows realm-installed layers, marked:

2026.08.3  rolling  sha256:6dab2d1d…  realm=pulseengine
2026.08.4  rolling  sha256:7e48ccc3…  realm=pulseengine

varve inspect does exactly what I had to do by hand — and better, because it shows the platform matrix:

40 payload(s): 35 DISPATCHED, 5 HELD  (platform aarch64-apple-darwin)
DISPATCHED  tool  meld  0.52.0  aarch64-apple-darwin       2026.08.4
DISPATCHED  tool  loom  1.4.0   aarch64-apple-darwin       2026.08.4
DISPATCHED  tool  loom  1.4.0   x86_64-apple-darwin        2026.08.4
DISPATCHED  tool  loom  1.4.0   x86_64-unknown-linux-gnu   2026.08.4

Your loom caveat is independently checkable from this output — three platforms for loom, no aarch64-unknown-linux-gnu, exactly as you stated. That is better than being told: I can now verify the gap rather than trust the announcement. The HELD explanation (vsix stored and verified but deliberately not dispatched) is the kind of thing I would otherwise have filed a confused issue about.

Still reproduces on 0.29.0 — upgrading my earlier hedge

I said I had not checked whether 0.29.0 changed the varve which stdout behaviour. I have now, and it has not:

$ varve which meld            # stdout, both lines
/Users/r/.varve/realms/…/bin/meld
layer 2026.08.4 (rolling) sha256:7e48ccc3…

$ M=$(varve which meld); [ -x "$M" ] && echo YES || echo NO
NO

So the report stands against latest, not against my stale 0.16.0. Restating the case briefly since it now has a version behind it: the layer line is provenance, not a result. On stderr, $(varve which X) becomes correct by default and a human still sees it. As it is, the natural one-liner silently yields a non-executable path — and in my case a consuming script's [ -x "$MELD" ] || MELD="meld" fell back to an ambient meld 0.41.3, producing a version error naming the wrong version. A pinning tool handed the caller the un-pinned binary.

New: self-update could not bootstrap from a committed realm

On 0.16.0, in a repo with varve.toml (realm = "pulseengine") and varve-realms.toml committed — the exact zero-config setup your error text recommends:

$ varve self-update
error: self-update needs the trust root to confirm a verified update —
       set VARVE_TRUST_ROOT or pin a realm: no trust root configured.

varve which in that same directory resolved all five tools correctly, so the manifest and realm were being read — just not by self-update. I got out with the documented fallback:

VARVE_TRUST_ROOT=./rolling.pub varve self-update
varve 0.16.0 -> v0.29.0 installed (sha256:4ee61a40…)

and on 0.29.0 varve self-update works with no env var at all. So the gap is version-specific and already behind you — but it is a bootstrap shape worth knowing about: the versions that most need updating are the ones that cannot use the realm to do it, and the error message confidently recommends a path that does not work on the version printing it. A hint like "on versions before X, use VARVE_TRUST_ROOT" would have saved the detour.

varve verify earned its keep immediately

layer 2026.08.4 … verified: signature OK, 11 tool(s) match their signed digests
error: the layer verifies, but 7 of its tool(s) are not what your PATH runs (REQ-SHADOW-001)

That is correct and exactly what gale looks like today, and I am glad it is loud. Our pin is deliberately additive for now — the build scripts still resolve $MELD/$LOOM/$SYNTH against ~/pe-toolchain and CI still installs pinned tarballs — and docs/toolchain-pin.md says so. verify independently confirms that framing rather than letting us quietly believe the pin was already load-bearing. Moving the scripts onto shims is the follow-up, and it will be measured the same way the adoption was.

Layer 2026.08.4 is merged and pinned in gale as of 61520f3.