From 074aea31d88701a93bee41100e7bd9223bae8069 Mon Sep 17 00:00:00 2001 From: dan-claude-bot Date: Mon, 20 Jul 2026 17:42:56 +0000 Subject: [PATCH] docs(changelog): record the UNREADABLE rollup fix Its own Fixed entry rather than a line in the refactor above it: the two-axis split is a design change, this is a correctness bug in a different function, and a reader bisecting a false "merge me" wants the second one named. Co-Authored-By: Claude Opus 4.8 --- CHANGELOG.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 434052b..0cc1f89 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -89,6 +89,21 @@ which records not just what changed but what each drill run proved. ### Fixed +- **A failed rollup read no longer reads as "nothing is failing"** — when + `gh pr view` returned nothing, the fallback left the `statusCheckRollup` + *key* absent, and `checks_state` collapsed that into the same `NONE` as a PR + that genuinely has no checks. `NONE` blocks nothing, so a transient API + failure presented as mergeable-by-a-human: the same + unknown-certified-as-green shape as #136, surviving in the one place that + fix never looked. + + `checks_state` now distinguishes the two — `UNREADABLE` for an absent key, + `NONE` for a present-but-empty array — and the sweep leaves an `UNREADABLE` + PR exactly as it is rather than relabelling on facts it did not read. It is + deliberately **not** a blocker: blocking on it would flap the entire board + on one bad API call, and the next tick is fifteen minutes away. Fixtures + 64 → 66. + - **`state:needs-human` no longer appears on PRs a human cannot merge** (#136) — `decide_state()` derived state from three inputs (draft flag, requested reviewers, submitted reviews) and read *nothing* about mergeability or