Release and deploy the 429 fix before the 21 November cron — GATED, do not start without explicit instruction #517

Epic: #512 · Story 6 of 6 · depends on #511, #513, #514, #515 · last

⛔ Gate: do not start this issue without explicit instruction

This is the only story in the epic that is not picked up autonomously when its
dependencies close. Standing rules: never branch from or PR to main unless told; always
confirm before a version bump, a merge to main, a tag, or a deploy. The issue exists so the
work is visible and ordered, not so it can be started.

Why this matters

Everything else in this epic is inert until it is deployed.

• The server runs tag v1.15.0 (.views-deploy-tag, installed wheel
  views_datafactory-1.15.0.dist-info), which contains the 429 defect.
• The next monthly cron is 0 0 21 * * → 21 November 2026.
• The 21 October run aborted on that defect. A fix sitting on development would not have
  saved it, and will not save the next one.

That is the entire argument for this story: a merged fix is not a deployed fix, and the
gap between the two has its own register entry.

The work

Follow docs/guides/server_quickref.md as the authority. It is authoritative because it was
made so deliberately, after the alternative failed repeatedly.

C-343 — "writing the deploy tag is not deploying" — has recurred five times in eight days.
reports/post_mortems/2026-10-20_release_v1150.md is the fifth round, and each round was a
correction to the previous round's blind spot: #497 found four more copies of a one-step claim;
#498 found that ~ after sudo expands as the caller, so six verification commands read the
wrong home; #499 gave the procedure one home and added the tmux rule; #500 found that the
authority established in #499 carried a duration figure nobody had ever measured.

The through-line, recorded at reports/technical_risk_register.md: a consolidation
concentrates error as effectively as it concentrates authority. The practical consequence for
this story: follow the written procedure, do not reconstruct it from memory, and do not
improve it in passing.

Two specifics that bit before and are easy to repeat:

• sudo -u views-deploy commands must source ~/.profile, and ~ after sudo expands as the
  caller — use absolute paths.
• The run takes ~7 hours and SSH will drop. Use tmux
  (docs/guides/hetzner_deployment_guide.md:30).

Acceptance criteria

• Version bumped; development → main via PR; tagged. Each step confirmed first.
• Deployed, and the deployment verified by observation, not assertion:
  .views-deploy-tag and the installed wheel version agree with the new tag.
• A harvest observed running on the new code — this is the step C-343 keeps catching.
  Writing the tag is not deploying; installing the wheel is not running it.
• The 429 path confirmed present in the deployed artifact (e.g. the new constant is
  importable from the installed package on the server, not just present in git).
• A post-mortem added under reports/post_mortems/ per the existing convention
  (YYYY-MM-DD_release_vNNN.md, with the fixed header block and the
  "## The thing to read if you read nothing else" section).
• CI green on main after the merge — not dismissed as pre-existing. We are the sole
  developers of this repo; a red check is ours.

Validation

Per docs/guides/server_quickref.md. The verification block there is itself newly trustworthy:
reports/post_mortems/2026-10-20_release_v1150.md:195-198 records that on 2026-10-16 its first
command died on the ~-expansion defect, so the block added on 2026-10-13 had never once
executed successfully until the v1.15.0 release. Run it and read its output; do not assume it
passed because it printed.

Out of scope

• Any code change. If a defect surfaces during the release, it gets its own issue; the release
  does not grow to absorb it.
• Improving the deployment procedure. If it is wrong again, that is a sixth C-343 round and its
  own issue — not collateral work inside a release.
• Changing the cron schedule or the monitoring grace window.