Repository navigation
Ration the banners, and say nothing while nobody is looking - #66
Merged
Merged
Conversation
A watched port an agent kept restarting produced a banner per change, each with its own sound and its own entry in Notification Center, and macOS holds everything posted while the screen is locked: an hour of restarts arrived in one pile at unlock, with an alarm per banner. Every banner now passes a gate: one per port per minute, at most three in half a minute before the rest are counted instead, and only the first of a burst makes a sound. Each carries an identifier for its port and kind, so a new one replaces the last rather than joining it. While the screen is locked or the display is asleep nothing is posted at all. The changes are counted, and one silent summary follows when the screen comes back. The guard keeps working throughout; only the telling waits. Refusals go through the same gate: ten agents refused in a minute is one story, not ten interruptions. Also: a free-port test asked the kernel and so depended on what happened to be listening on the machine running it, which a dev server on :3002 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reported from a real session: an agent left running restarted a server over
and over, the display went to sleep, and at unlock every queued banner
arrived at once, each with the interrupt sound.
Three things were wrong.
flapping every two seconds meant a banner every two seconds.
Notifier.sendused a fresh UUID as theidentifier, so nothing ever replaced anything: forty changes left forty
entries in Notification Center.
posted behind a locked screen and delivers the queue at unlock.
Now: one banner per port per minute, at most three in half a minute before
the rest become a summary, one sound per burst, and an identifier per port
and kind so a new banner replaces the last. While the screen is locked or
the display is asleep nothing is posted at all: changes are counted, and one
silent summary ("12 changes on :3000, :5173 and 2 more") arrives on return.
The guard still kills, still records History, still refuses agents while you
are away; only the telling waits.
Refusal banners use the same gate.
Testing
386 unit tests, 0 failures, including six for the gate: a port flapping every
two seconds for a minute yields one banner; only the first of a burst makes a
sound; "freed" and "taken" are separate news; nothing posts while away and
the summary counts what happened, in the order it happened, once.
One unrelated test fix:
testFreePortSkipsOtherPeoplesLeasesprobed thekernel, so it depended on what was listening on the machine running it (a dev
server on :3002 failed it). It now tests the choosing logic, as its
neighbours do.
🤖 Generated with Claude Code