build.nix accepted `features` as a parameter but discarded it, never
placing it into the derivation's passthru. The NixOS boot.kernelPackages
apply function calls kernel.override() on every evaluation, re-running
build.nix from scratch; any features added via overrideAttrs were
silently lost, causing assertions like hardware.graphics.enable32Bit
(which checks kernel.features.ia32Emulation) to always fail for
linuxManualConfig-based kernels.
Change `features ? null` to `features ? {}` and add it to passthru so
it survives override() call chains.
`bot.js` already pulls reviews via GraphQL for the approval-count
labels. Move that fetch above the `handleMerge` call, add `commit
{ oid }` to the query, and pass the result through. `handleMerge` no
longer issues its own `listReviews` REST call.
While here, the `approvals` set is now derived from the same reviews
data. Two upsides:
- A reviewer who approved and was later dismissed no longer counts
towards the approval check; their review now surfaces with state
DISMISSED instead of leaving a stale `reviewed` event behind.
- `events` is no longer needed by `runChecklist` (it was only feeding
the approvals filter); the parameter is dropped from both call
sites. `handleMerge` still uses `events` for tracking the latest
push and merge-command comments.
Also drop the redundant `user` truthy checks (and the stale "some
users have been deleted" comment) in `runChecklist`. The GraphQL
query uses `author { ... on User { login id } }` and bot.js then
filters via `r.user?.login`, so by the time reviews reach
`runChecklist` every entry already has a populated `user`. Verified
by querying real PRs: bots surface as `{__typename: "Bot"}` (no
`login`/`id`, filtered out by bot.js), and deleted accounts surface
as the "ghost" user (login `"ghost"`, id `10137`), which passes the
filter but matches no committer - harmless for both checks.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
The previous tip ("Sometimes GitHub gets stuck after enabling Auto
Merge") didn't explain why nothing happens immediately after the bot's
"Enabled Auto Merge" reply, leaving maintainers unsure whether to wait
or intervene. Spell out that Auto Merge waits for required CI before
queueing, that a later CI failure leaves the PR un-queued until it is
fixed, and link to GitHub's documentation; keep the existing "leave
another approval" workaround for the rare cases where Auto Merge stalls
after CI completes.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
MithicSpirit