scheduleNotification (#110) sat with the Swift shim for days after the thing blocking it was fixed, because the note describing the blocker was still there and nobody re-read it. I swept for the same shape and found three more.
bridge_mobile_permissions.zig contradicted itself
Its module header already says openSettings "is claimed now". The doc comment three lines above the A block still called it "deliberately absent" and warned against adding it — while A has declared it since bdfa2ae, and routeFor, capability_actions and the handler all serve it.
The header also said the ratchet "keeps counting openSettings as not-yet-migrated". That stopped being true when it was declared; the extraction confirms openSettings is not among the 25. What the ratchet does still count is the payload values requestPermission leaves to the shim — location, photos, contacts, calendar, reminders — so the sentence names those instead.
bridge_mobile_display.zig described a gap I had already closed
It said badge authorization "is not attempted here". requestBadgeAuthorization asks before the badge is written, as of #105. That note was mine, left behind in the very commit that added the ask.
Checked and kept
bgtasks' registerBackgroundTask note is still accurate: BGTaskScheduler.register must run before the app finishes launching, so a page-triggered call is late by construction and raises an uncatchable NSInternalInconsistencyException. Genuinely still blocked, note stays.
Why this is worth a commit
No behaviour changes. But a note describing a limitation the code no longer has reads exactly like one describing a current limitation, and the only way to tell them apart is to re-derive the whole argument from scratch. That cost is measurable here rather than theoretical — it is the reason an action stayed on the shim through several passes that each read the note and believed it.
zig build test: 150/150 steps, 0 failures.