[Polichinel]

What happened

A pipeline run died today:

client_loop: send disconnect: Broken pipe

It was running in an SSH session's foreground, so the drop sent SIGHUP and killed it — after the 37 GB assembly had completed but before the zarr export, leaving grid.npy current and grid.zarr three weeks stale.

Why the guidance didn't prevent it

The rule exists. hetzner_deployment_guide.md:30 says it, with the reason:

# 2. Start tmux (pipeline runs 3-4 hours; SSH will drop without a multiplexer)
tmux new -s deploy

And reports/post_mortems/2026-05-25_deployment_v1221.md has a section headed "tmux saved us from the SSH drop."

server_quickref.md did not have it — and #497, merged three days ago, made the quickref the single operational home and told every other guide "if they disagree, the quickref wins." That consolidation silently demoted a rule the demoted document was the only one carrying.

This is C-343's shape again, inverted: the earlier rounds were about content that was wrong in several places; this is about correct content that existed in exactly one place and was outranked.

Every designed defence held

Worth stating plainly, because the outcome was much better than the cause deserved:

mechanism	behaviour
assemble_grid.py writes grid.npy.tmp, renames at the end	grid.npy was whole — no torn grid, no orphan temp
.exports_required sentinel	recorded the owed export at 16:36
flock -n on fd 200 (refresh_pipeline.sh:182)	released by the kernel on process death; no stale lock, re-run not blocked
check_health.py:168	reports the sentinel as PENDING — assembly ran but exports not yet done

Nothing was corrupted and nothing was silent. The cost was a re-run and a window in which served data lagged the grid. The one residual signal is the C-317 /start heartbeat ping left dangling, which healthchecks.io flags at its ~24h grace timeout — correct behaviour, and now documented in the quickref note.

Changes

Every interactive refresh_pipeline.sh invocation in the guides now opens with tmux new -s pipeline:

• server_quickref.md §"Run the pipeline" — the rule, the dated evidence, detach/reattach, and the detail that actually catches people out: tmux does not change the shell prompt, so only the bottom status bar tells you whether you are inside it. That ambiguity is what made today's re-run unverifiable without a screenshot.
• hetzner_deployment_guide.md §2.1, §4.5, and the rollback section added in docs: writing the deploy tag is not deploying — four more copies said it did (C-343) #497
• server_operations.md summary table and the full-rebuild procedure

Two deliberately left alone, and the reasons matter more than the coverage count:

• Cron invocations (0 0 21 * *) — cron has no controlling terminal and no SIGHUP to receive. Wrapping them in tmux would be cargo cult.
• The ~/.profile wrong-vs-right example in server_operations.md — it exists to teach one thing, and adding tmux would obscure it.

Register

C-343 gets the pattern; no new entry. The failure is loud, every defence worked, and the trigger would be perpetual ("whenever someone runs the pipeline") — which the trigger-quality gate rejects. What is registrable is the lesson about consolidation: a new authority is only safe if it absorbs everything the demoted copies knew, and checking that was not part of the #497 work.

Verified: ruff check . clean · validate_docs.sh PASSED · 48 register-reading and citation tests passed. Docs and register only.

Refs #497, C-343.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EfeuULbPTqrx4qtNki5dy9