README.md

@@ -621,14 +621,15 @@ its bare default; either restores the bug.
 **Accepted cost: a body edit on an already-non-draft PR now triggers a real
 run.** Gitea populates no `changes` field for a title-or-body edit, unlike
 GitHub, so the workflow cannot tell the edit that un-drafts a PR from an
-ordinary body PATCH — a closing-reference fix-up, say. That trade is worse
-here than in the sibling repos that made it first: this job installs two Rust
-toolchains and runs suites that drive a real Cargo against real scratch
-workspaces, with `timeout-minutes: 20`, on a runner shared across four repos
-on two capacity slots. It is bounded, though: the workflow's `concurrency:`
-block groups `pull_request` runs on `github.ref` with `cancel-in-progress:
-true`, so a burst of edits collapses to one run rather than N. A still-draft
-PR pays nothing extra — the `if:` guard skips those exactly as before.
+ordinary body PATCH — a closing-reference fix-up, say. The price is around
+**90 seconds** of a runner shared across four repos on two capacity slots: the
+last twelve non-skipped runs of this job, `run_started_at` to `updated_at` off
+the Actions API, are 83 s median over 77–106 s. `timeout-minutes: 20` is a
+ceiling for a hung suite, not a duration. It is also bounded: the workflow's
+`concurrency:` block groups `pull_request` runs on `github.ref` with
+`cancel-in-progress: true`, so a burst of edits collapses to one run rather
+than N. A still-draft PR pays nothing extra — the `if:` guard skips those
+exactly as before.
 
 The evidence for `edited` comes from `daniel/emowheel`, which hit the identical
 bug, shipped the identical wrong fix, and corrected it in commit `08da820` (see