batch 2026-08-21 status: where the import batch stopped and what picks up

[CarlAllenn]

Defect

Not a defect — a status record. Carl closed the 2026-08-21 import batch at ~22:15 in finish-line mode ("file and leave, no new fixes unless blocking"). This issue is the pickup point. The orchestrator's memory file batch-2026-08-21-handoff.md has the lane-level detail; release-lab#250 is the batch ledger.

Decided build

State at close.

repo	state
canon	v1.59.0 (f0694b0). Today: v1.58.6 → v1.59.0. #804/#814, #816/#818, #821/#822, #826/#827, #830/#831, #809/#817
release-lab	full width restored, pinned v1.58.11 (#258); oci-only cell v0.28.0 published (#253 proven); v0.28.1 full-width Release PR #261 merged, publish running
monumental-archive	#262 merged (d9611af) — belt adopted, first green gate since import (needed canon #830 atlas-token + compose repin, MA#267). MA#263 = owners' record, OPEN
edtf	pinned v1.58.11; v1.3.1 BURNED (draft = record) on #833 — see below. v1.3.0 also burned (#816). edtf#172 = owners' record, OPEN
iiif-server	v0.2.2 published; #133 merged (audit validates the published image)
ma-db	PR 1 merged; PR 2 DEFERRED by Carl (Dockerfile repin to the org edtf-postgres image, ma-db#5)

The one blocker for edtf v1.3.2 — #833. build-rust-crate.yml emits no sbom-plan-* artifact while slsa/assert-policy.json declares rust-crate owes a sbom-cargo- document (owedFrom: 1.42.0); the release SBOM assertion correctly refuses. This was foreseeable by reading (Carl's challenge, measured by the edtf lane): the obligation is a literal table in the policy, the emitters are a grep over the builders, and the set difference has had exactly one inconsistent row for the 40 releases since v1.42.0. Nothing about it needed a runner or a real repo. Decided build (in #833): a belt lint asserting every class with a planned: true prefix has a builder emitting a matching plan — deterministic, two files, belongs in ci — plus the one-workflow fix. Release-path: canon fix → canon release → edtf bump → v1.3.2. Everything else in v1.3.1 worked: 58/59 jobs, all ten pgrx cells across pg14–18 × 2 arches, repro legs matched, upgrade path derived from 1.2.3 past the burned 1.3.0 and proven live.

Deferred, filed, not built (batch next week): #813 (pgrx compiles + tests in the gate, belt-provisioned postgres; Carl ruled "into the belt, correct by construction"; lab-pg exclusion dies with it), #820 (MSRV check lost on import → lint:msrv in the belt; needs a ruling between rustup-at-run-time and a second pinned toolchain), #825 (dead-end ≠ burned in pg-upgrade-path; release path should WRITE the installable set), #803/stele#252 (private member reads as unseen — every consumer level red, canon self-level red), #784, MA#264/#265/#266/#267, ma-db PR 2.

Rulings made today that bind the batch (all dated in the issues): no lab leg for release-path fixes when the only consumer is the proof (120-minute runs are a human cost); checks a repo lost on import go INTO THE BELT, never back as repo-local tasks; a recorded loss is not conformance — diff the old required checks against the belt before calling an import done; record issues (#172, #263, iiif#123) are the owners' to close.

Four-defect family worth naming (edtf lane): a release path that assumes "the previous release was ours and succeeded" is proven only by a real adopted repository — #762, #780, #792 needed an imported history, and #816 needed an actually-failed release. #833 is NOT in that family: it is a declaration-without-producer that a lint catches, and the first framing that put it there was retracted the same evening.

Canon consequence

None by itself. Close this when #833 ships and edtf v1.3.2 publishes, or fold it into the next batch's ledger.

Done when

• the rust-crate class declares a planned SBOM obligation with no producer: emit the plan and lint the declaration/producer join #833 fixed, released, edtf v1.3.2 published (class spread complete)
• lab v0.28.1 publish confirmed green (feat: verify the evidence the vsa summarises #253 second Done-when)
• the deferred list above triaged into a batch

Sequencing

Pickup order: #833 first (it is the only thing between the org and a published edtf). Refs release-lab#250.

[CarlAllenn]

Batch pickup executed (2026-08-24): #833 closed and production-proven on edtf v1.3.2 (see its closing comment — producer + join lint through the real commit point). Canon releases v1.60.0 and v1.61.0 cut and published tonight; edtf pin bumped via Renovate. Remaining before this record closes: edtf's registry arrival (crates + npm), burned at v1.3.2 by the canon-side #907 defect (measured: crates.io policy-blocks the UA-less token exchange; npm leg under measurement) — completes on edtf's first release after #907's fix rides the next canon pin. release-lab v0.28.1's publish was green 2026-08-21 (run 32531281696).

[CarlAllenn]

Registry progress (2026-08-24 03:2x): npm arrival complete — @monumental-archive/edtf-wasm@1.3.2 is live (registry dist-tags.latest = 1.3.2), published by trusted publishing on the SCOPED package after the publisher config landed there (the #907 npm epilogue: the config had been on the unscoped pre-import twin). crates leg at v1.3.2 remains unreachable by construction (tag pins canon v1.60.0, pre-UA-fix) — completes at edtf's next release on canon ≥ v1.61.1, which carries #910's exchange header. v1.61.1 cut; its self-publish is running.

[CarlAllenn]

Batch close-out, 2026-08-24 ~03:40. Where this record stands tonight and what picks up:

DONE: #833 closed and production-proven (producer + join lint through edtf v1.3.2's real commit point). Canon v1.60.0, v1.61.0, v1.61.1 cut and published. edtf v1.3.2: GitHub release + full evidence published; npm arrived (@monumental-archive/edtf-wasm@1.3.2 live via trusted publishing on the scoped package). The epoch-7 handover (#891) landed atomically. All 14 triage lanes plus the measured-fallout wave (#857, #860, #863, #864, #867, #868, #880-family, #892, #899, #905, #907, #911) merged.

REMAINING before this record closes: edtf's crates arrival. The pin bump (edtf#199) is RED on lint:gate-surface — the #813 invariant working as designed; it lands after edtf#198 (66-finding backlog) + edtf#197 + the pre-measured conversion commit, then v1.3.3 publishes crates via the #910 UA fix. That is the next window's first edtf lane.

Also open with owners: #862 (next attributed audit run names the real 403 endpoint), #884/#896/#904 queued sealed, release-lab#265, MA#290, stele#268/#269.

[CarlAllenn]

Pickup-map correction to the close-out above (2026-08-24 ~03:50): #854 and #899 are now CLOSED (all bullets met and verified live; their residual legs ride already-tracked work). The precise open set this record's successor inherits:

• One event closes three issues: edtf v1.3.3 — after edtf#198 (backlog) + edtf#197 + the conversion commit turn edtf#199's lint:gate-surface red green — is the closing measurement for the crates.io token exchange sends no user-agent and dies as a policy 403: name the org in every registry curl #907 (both registries green), aqua resolves wasm-pack macos-arm64 to the x86_64 asset, so the pinned attestation is the wrong architecture #811 (consumer locks regenerated), and this record.
• AUDIT_TOKEN cannot list the org's repos, so the settings-drift leg dies on one unattributed 403 #862: closes itself on the next attributed audit.yml run naming the failing endpoint + grant (no owner action known to be needed; earlier token theories are dead on the thread).
• Queued, sealed, unstarted: four consumers explain the release path's contents grant with an API call that never happens #884, the extension's SQL surface snapshot runs nowhere: the third check the import dropped #896, nothing detects a lock that has stopped agreeing with its registry: mise lock is not asserted idempotent #904; release-lab#265; MA#290; stele#268/feat: carry the VSA SHOULDs in the source VSA via one shared assembler #269 (stele batch's).
• Everything else open is pre-batch (imports import edtf: transfer, conform, delete the private toolchain — the maximal class spread comes home #669–import monumental-archive-ledger: the anchor comes home before its first checkpoint #673, watches, maintain-the-release-pr failed once on a transient 403 that reads as a permissions fact #633-family) and untouched by this batch's obligations.