docs(d8): run homebrew-taps' updater one job per cask (S32)

[edbfi]

What changed

S32: homebrew-taps' cask updater runs one job per cask. Before this, publish and push were single jobs looping over every cask, and their timeouts had to cover all the casks together, so six casks was the limit (#47 had to raise both timeouts for a seventh). Now every cask job runs on that cask's own timeout (UPDATE_MINUTES in its config.env, default 20), so adding a cask never touches the workflow.

• design/d8.md:
  • Rule 8 now requires jobs 1–4 to run one cask per job on per-cask timeouts.
  • Rule 12 now requires job 4 to run one cask at a time.
  • A new Verification bullet records the two-probe production test.
• STATE.md: an S32 row, the homebrew-taps repo row, and the freshness line.

The homebrew-taps side:

• #49: per-cask timeouts and the job matrix.
• #50: the workflow switched to one job per cask.
• #51: two probe casks added for the test.
• #52: the probes removed again.

Evidence

• Run A, two probe casks 0.0.1 → 0.0.2 with eight casks in total and no timeout changes:
  • Both publish jobs ran in parallel (20:48:31–40), and the push jobs ran one after the other (20:49:40–54, then 20:49:56–50:03).
  • The pushes went 075ab3c → cb19908 → 0b4bb0e, both deploy-key fast-forwards and both rule suites bypass.
  • Push CI passed on both commits.
• Run B: all eight checks reported no update and nothing after plan ran.
• Run C: with a different UpdaterProbeB-0.0.3.dmg placed on the probe's release first:
  • publish (updater-probe-b) failed with "differs from upstream".
  • updater-probe published, verified and pushed (0b4bb0e → c14cf2a, bypass).
  • probe-b got no verify or push jobs.
• Cleanup: after docs(state): record docrewind's green audit after replacing its vulnerable tooling #52, homebrew-taps' tree equals 2e23e76, there are no probe releases or tags in homebrew-taps or edbfi-ci-playground, and a final six-cask dispatch passed.
• prek run --all-files --hook-stage manual: every hook passes, doc_guard included.

Deviations

• How published finds the successful casks: it lists the succeeded publish (TOKEN) jobs from the jobs API instead of reading a marker artifact. d8.md's Verification requires publish to have no uses: lines, so it can't upload one. homebrew-taps' WorkflowTests pins the job name.

Owner actions

None.

[pullfrog]

ℹ️ No critical issues — one nitpick on unchanged wording.

Reviewed changes — the single commit 2f83f77, covering design/d8.md and STATE.md. doc_guard passes and Last updated (1791838912) matches 2026-10-12T21:01:52Z.

• design/d8.md rule 8 requires jobs 1–4 to run one cask per job on that cask's own timeout, so a failing cask stops no other.
• design/d8.md rule 12 requires job 4 to run one cask at a time.
• design/d8.md Verification gains a [V, 2026-10-12] bullet for the two-probe production test with its three run ids.
• STATE.md gains an S32 row (done) and S32 in the homebrew-taps row with a dated [V] tag. Last updated is bumped.

I can't check the homebrew-taps PRs (#49–#52), the cited runs, or the UPDATE_MINUTES mechanism from this checkout. The rest of the diff is internally consistent: the step row and repo row agree, and no stale "six casks" or timeout wording remains in STATE.md, DECISIONS.md or design/*.md.

Nitpicks

• Rule 9 still says "end the run". It reads "MUST end the run as a logged no-update with jobs 2-4 skipped" (design/d8.md:21). With one cask per job, a qBittorrent no-update ends only that cask's jobs, and the other casks continue. Rule 8 now says a failing cask stops no other, so "the run" is ambiguous. Wording such as "end that cask's jobs as a logged no-update" would fit. The line is unchanged, so I can't anchor an inline comment to it.
• The new Verification bullet mentions a "plan" the Contract never defines. It says a run without updates "skips everything after the plan" (design/d8.md:50). The Contract names only jobs 1–4. The PR body's published job, which lists the succeeded publish (TOKEN) jobs through the jobs API, is not in the Contract or Verification either. Its job-name dependency is recorded only in the PR body and in homebrew-taps' WorkflowTests. Consider one short Contract clause or Verification phrase, so a reader of design/d8.md can tell what "the plan" is.
• "A failing cask stops no other" is verified only for a failing publish. Rule 8 is general, but the evidence (run C) covers only a publish failure. If a cask's push fails, the design doesn't say whether later casks' pushes still run. Narrowing the Verification wording or the rule to what was tested would remove the gap.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using claude-sonnet-5-5 ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — commit 0158d55, the follow-up to my earlier review. doc_guard passes, and Last updated (1791838912) still matches 2026-10-12T21:01:52Z.

• Scoped rule 9's no-update to its cask. design/d8.md:21 now says a qBittorrent no-update ends "that cask's update" with "its jobs 2-4" skipped, so it no longer ends the whole run. This fixes the "end the run" ambiguity I raised.
• Replaced the undefined "plan" in the Verification bullet. design/d8.md:50 now says a run without updates "skips jobs 2-4", which uses the jobs the Contract defines.

My third earlier nit still stands. The "a failing cask stops no other" evidence covers only a failing publish, not a failing push. It is optional.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using claude-sonnet-5-5 ｜ 𝕏}