[physics515]

What this is

Two lines in DECISIONS.md, one of which is a blocker no agent here can clear, and one of which is a habit worth writing down before it bites again.

1. Needs human: crates.io publication has never happened, and it is a missing secret

publish.yml has been dispatched twice and failed identically both times — run 42301816146 (2026-11-06T22:04Z) and run 42346611064 (2026-11-07T06:21Z), job execute, step Publish:

error: failed to publish weftdb v0.3.1 to registry at https://crates.io

Caused by:
  please provide a non-empty token

publish.yml:123 wires CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}, so the repository secret is unset or empty. Everything up to that step works: the crate packages, weftdb v0.3.1 compiles out of target/package/weftdb-0.3.1, cargo prints Uploading weftdb v0.3.1 and then the token check fails. The v0.3.1 GitHub release is drafted with its five archives and their .sha256 files (run 42342265711, success). So: the tag and the artifacts exist; the registry does not have the crate.

Nothing on this machine can close it — crates.io is also unreachable from here, so a hand cargo publish is not even theoretically available.

The follow-on choice belongs to the owner, and is currently being made by default: publish v0.3.1 after the secret lands, or let 0.3.2 be the first release on the registry. #612 bumps weftdb, weft-server, weft-arrow-store and weft-orchestration to 0.3.2, so silence is the gap. A gap is survivable (nothing pins a 0.3.1 that does not exist), but docs/reference.md tells people to install from the registry, so whichever version goes out first should be checked against that page.

Rejected: making Publish tolerate an empty token so the lane reads green. #610 already taught it the one benign case — a version already published — and an unauthenticated push is not that case.

2. Any gate behind a red gate is an untested gate

scripts/packaging/test-host-install.sh has seven gates, and its ubuntu-latest roll had never got past gate 5: gate 4 stopped it on the bind-address message, then gate 5 stopped it on its own name selection (both fixed on w7/pac-11-ci, PR #596). Gates 6 and 7 — systemd-analyze verify, systemd-sysusers, systemd-tmpfiles, a live user manager — had therefore never executed on any host: the machine the script was developed on skips all four, while the workflow asserts they must not skip on ubuntu-latest.

Gate 6's first execution ever failed in 32 seconds: systemd-analyze verify --root "$DEST" "usr/lib/systemd/system/weft-server.service" answered Unit weft-server.service not found. about a unit gate 1 had just confirmed on disk, because --root resolves an absolute path against the root and a slash-bearing relative path against the current directory. Fixed on #596 by keeping the leading slash and asserting the file exists first, so a missing unit and an unresolvable argument can no longer produce the same message.

The generalisation is the reason for this PR rather than the fix itself: PAC-11 was ticked on main (8c5fea9, #611) while gates 4, 5 and 6 were each in turn the wall. It should be closed again, if at all, on the evidence of a roll that printed all seven ok: lines — not on the evidence that a packaging branch exists.

Verification

Docs only: DECISIONS.md is not compiled or linted, and this branch touches nothing else. DCO signed; every claim above is quoted from a run the reader can open with the id next to it.