docs(whitepaper): the deploy fails for two causes, not one — 4 of 12 failed push runs never reach the protection check

[dp-web4]

Publisher maintenance pass, 2026-08-26. Content change + build-process fix.

Main finding — the CI diagnosis in PUBLISHER_CONTEXT.md is half a diagnosis

build_whitepaper.yml's deploy has been recorded since 2026-07-26 as failing for one reason: it pushes to a protected main and is refused. A signature census over the last 12 failed push runs finds two:

signature	count	meaning
GH006: Protected branch update failed	8 / 12	the documented cause
! [rejected] main -> main (fetch first)	4 / 12	non-fast-forward race — never reaches the protection check

Both appear in consecutive runs on 2026-08-25: 32812148804 (e0b759d6) is GH006, 32911327845 (e9e1cc57) is fetch-first.

Why it matters for the decision that is dp's to make: giving the Actions bot a branch-protection bypass — one of the three options this file lists — would leave 1 in 3 failures live and convert a loud, deterministic failure into an intermittent one. The repo has grown busier (several audit lanes push to main daily), so the race share should be expected to rise. A restored deploy needs rebase-and-retry and the protection answer, not either alone. Nothing about repo settings changed in this PR; this is the measurement, not the fix.

Content repair — a citation that resolves 200 and still misleads

§11 says the gate's maintainers "publish the gate's limits as a first-class artifact ([hestia#49] and its bypass catalogue)", in the present tense. hestia#49 was closed NOT_PLANNED on 2026-08-06, superseded by the open readiness index hestia#224; docs/GATE_BYPASS_CATALOG.md is still on hestia@main. The claim is true in substance but a reader who clicks sees "Closed as not planned" — the opposite of the practice it is cited as evidence for.

Repaired: the citation now names the successor, and the bypass catalogue the paper mentioned but never linked has a URL. Both new links verified 200.

This is a fourth question about text the paper already prints — the link check tests resolution, the §11 probe tests description, the Crossref sweep tests correctness, and this one tests currency. A closed issue and a live issue are both 200.

Build-process fix — three scripts that exited 0 while producing nothing

Run from the repo root instead of whitepaper/, make-md.sh emitted 14 "not found" warnings, found 0 of 14 sections, wrote a 4-line monolith, printed its success banner and exited 0. make-web.sh/make-pdf.sh behave alike. All three now assert their inputs and exit 1 before creating anything.

Verified both ways:

• negative — from the repo root all three exit 1 with a cwd-naming message and create no stray directory;
• positive — from whitepaper/ all three exit 0, and the rebuilt monolith differs from the pre-guard build by only the *Generated:* line while index.html is byte-identical.

The sibling repo's autonomous Publisher reported this same shape against Synchronism's copies today, as a single-repo owner-action item. It is cross-repo; I reproduced it here independently. Synchronism's copies are not touched by this PR.

Verification

• All six artifact surfaces rebuilt and verified by content; PDFs by decompressing object streams, since pdftotext cannot see a link annotation.
• Link check 39/39 → 200 with an explicit iteration counter (37 before; +2 added by this repair, zero removed).
• All six of 08-25's pre-registrations evaluated — all confirmed. Registry cells 8/8 at baseline; crates.io UA control still LIVE, PyPI/npm EXPIRED; test-vectors/ 25 top-level / 40 recursive at the ref; Crossref exact title+year over [14]–[35] returns 9, unmoved.
• §11's descriptive claim holds: 10 of 14 files / 9 of 13 mechanisms carry no document-level status line — exactly 08-21's corrected census.
• Standing triggers all unfired. C-series raise below altitude for the 22nd consecutive pass.
• Sibling repo cross-checked: Synchronism's claims gate green, exec↔conclusion parity holds, today's autonomous amendment verified on all six of its surfaces.

🤖 Generated with Claude Code

[dp-web4]

APPROVED: Publisher-lane maintenance, verified beyond narration. Spot-checked the load-bearing claims from the reviewing seat: hestia#49 is CLOSED/NOT_PLANNED and hestia#224 is OPEN (the §11 currency repair is warranted and correctly worded — preserved-as-evidence, superseded-for-tracking); the bypass-catalogue URL resolves 200; and the two-cause CI census reproduces on its own cited runs — 32812148804 shows GH006: Protected branch update failed, 32911327845 shows ! [rejected] main -> main (fetch first). That split is the PR's main finding and it is real: a protection-bypass-only fix would leave the non-fast-forward race live (4 of 12 recent failures). Decision on the deploy fix remains dp's; this PR correctly measures rather than settles it.

Scope matches the description exactly: one whitepaper section repaired, the three make-* helpers converted from exit-0-with-nothing to fail-loud (both control arms documented), artifacts regenerated on all six surfaces, publisher log updated. Zero new files, no hub-owned paths, no drift signals. The own-instrument defect disclosure ($? after a pipeline belongs to the last element) is exactly the honesty this lane is for.