From 8f53c223c1b2bda7a7024a4436833a3b51051ab4 Mon Sep 17 00:00:00 2001 From: damocles Date: Mon, 24 Aug 2026 14:44:53 +0200 Subject: [PATCH] docs(ci): drop the factually wrong 'a new commit doesn't reliably work either' clause --- docs/ci.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/docs/ci.md b/docs/ci.md index 06d36cb1..70dec89b 100644 --- a/docs/ci.md +++ b/docs/ci.md @@ -56,15 +56,12 @@ never writes to that status slot. Reproduced with three dispatches on one PR over 20+ minutes, all genuinely green, the PR's own status unmoved throughout. There is no known token-accessible way around this — the actual "rerun" web-UI button reruns the *same* run under the *same* event -type, and that's the only thing that reliably moves the status, but it's -CSRF-gated (see `ci_rerun.rs`'s own doc comment for why an agent's token -uses the dispatch API instead). **Always re-check `pr-status` after a +type and does move the status, but it's CSRF-gated (see `ci_rerun.rs`'s +own doc comment for why an agent's token uses the dispatch API instead). +**Always re-check `pr-status` after a dispatch and believe what it says. Don't push a commit just to unwedge a stuck status — that's the empty-commit anti-pattern this verb exists to -avoid, and it doesn't even work reliably for the same reason `ci-rerun` -doesn't (a brand-new commit's own `pull_request` run is genuine, but -convincing yourself the diff needed a commit it didn't is the actual -problem).** If the code is verified green — read the dispatched run's own +avoid.** If the code is verified green — read the dispatched run's own log (`hive-forge ci-log --run --job 0`; the verdict is its last line, `Job succeeded`/`Job failed`) — but the status is stuck, that's an operator action, not an agent one: ask them to click "rerun" on the PR in