Layer 2026.09.1: meld 0.53.0, synth 0.61.0, and varve-producer in the layer

[avrabe]

tool	2026.09.0	2026.09.1
meld	0.52.0	0.53.0
synth	0.60.0	0.61.0
varve-producer	—	0.32.0 (new)
rivet, spar, witness, ordeal, loom, wsc, kilnd	—	unchanged, all current

The assembler now rides in the layer

A layers repository gets a pinned, signature-verified assembler instead of fetching one ad hoc — REQ-PRODUCERGET-001 taken a step further than a documented download. After this, obtaining the assembler is varve install plus a pin, and its bytes are covered by the realm root like every other payload.

Bootstrapping is not circular: the deposit downloads the released archive exactly as it does for every other tool. The first assembler comes from the release; after that a layers repo pins the one varve signed.

The entry needs both optional fields, because the producer is the one payload whose repo, binary and asset name all differ:

pulseengine/varve:v0.32.0:varve-producer:varve-producer-v%V-%T.tar.gz

v%V reconstructs the tag from the bare version rather than repeating it, so bumping is one edit and the template cannot drift out of step.

Checked before proposing, not after depositing

• All three tools clear rung 1 of the ingest ladder — each release publishes a cosign-signed SHA256SUMS.txt with its bundle, and varve's own sums carry all four producer archives.
• Every asset template still describes its release. varve-producer assets — the v0.32.0 binary from the signed release, not a local build — matches all four platforms for meld, synth and the producer.
• The negative control matters for the producer entry. Its default template would be varve-v0.32.0-%T.tar.gz, which selects varve's own archive — whose binary is named varve and would fail extraction. Getting the template wrong fails loudly rather than depositing the wrong bytes.

That check exists because a mistyped %V template once dropped a tool from a published layer while the run went green with four notices.

Deposit inputs

layer 2026.09.1, counter 2 — read out of the registry by tools/next-layer-id.sh, not typed. A layer id once published is spent; varve has neither revocation nor rotation.

What this deposit exercises for the first time

Three things shipped in v0.32.0 that have never run in a signing job:

1. publish-check refusing a republish, running before any blob is written.
2. The per-layer concurrency group, so two dispatches cannot both push.
3. sign-status refusing a status document with no support window — making 2026.09.1 the first layer varve has ever published that states one. Every layer to date reports "no stated support window", because the field shipped in v0.5.0 and nothing ever set it.

Because of (3) this can now fail in a new way: if the support-window derivation is wrong, sign-status refuses rather than signs. That is the correct direction to fail, and it is untested in a real run — so worth watching rather than firing and forgetting.

After merge

Dispatch Deposit layer with layer=2026.09.1, counter=2. I have not dispatched anything: the deposit signs with the realm's provisional root, and that is yours to trigger. I will watch the run and verify the published layer from the outside afterwards — including that the producer inside it runs and reports varve-producer 0.32.0.