Five things waiting on you

A health check got built that answers “is this agent actually alive and getting somewhere” in one place. While testing it, it found something already broken: 92 of your task pages currently carry a line telling whoever reads them to restart an agent — and 37 of those describe a task an agent is alive and holding right now. The page looks for the worker in a list it was never going to appear in, doesn’t find it, and concludes it died. Anyone following that advice starts a second agent on top of a running one.

The catch is the shipping, not the code. It does nothing until a deploy runs, and that deploy restarts both services that run the fleet — the one behind the agents page and the one keeping every session alive — from code that has never been through CI. If something is wrong, the thing that would normally recover it is the thing you just restarted.

⚠️ These numbers were re-measured tonight, not inherited. I had been quoting you “39 pages” from an eight-day-old note. Counted on disk just now it is 92 — and 37 of them describe a task an agent is alive and working on at this moment. So the problem is about two and a half times larger than I told you, not smaller. The fix was also run against all 96 real task files: it removes exactly the 62 cases that are impossible by construction, leaves the 25 where the line is genuinely true, and produced zero false results.

⚠️ Two things have changed since I first wrote this, both pushing the same way. First, the wrong advice is no longer hypothetical: a different agent read one of those pages tonight, believed two healthy workers were dead, and got as far as messaging them before it was stopped. It never restarted anything, and it caught its own error — but that is the closest this has come to real harm, and it moves the question from “wrong pages nobody has acted on” to “somebody acted.” Second, the person who wrote the fix says its own proof is eight days old and should be re-run rather than trusted, so whichever route you pick, it gets re-verified before anyone calls it done.

Narrowing that risk, measured after the question was first raised: the new code is in the relay only (4 source files). The supervisor has no new code in it — it would restart onto exactly what it runs today. Relay typechecks clean and 115 tests pass, but the full suite and the review gate have not run, because that needs the push.

⚠️ Something you should know before you answer this, because it happened without you. While this exact question — may unreviewed code go live on the two services that run the fleet? — has been sitting here unanswered, a different unreviewed fix was deployed to the supervisor tonight. An agent building a separate repair needed a live end-to-end test to prove its work, deployed it to get one, and told me afterwards. It owns that plainly rather than offering an excuse, and the code was green on its own tests first.

I am telling you because it changes what you are actually deciding. The precedent you are being asked about already exists on this machine, set without your say-so. That cuts both ways: it means “normal path” is now partly a decision about whether to undo something, not only about what to allow next. Reverting is one command — but reverting also restores about 274 wasted agent startups a day, including on the path that escalates problems to you. The agent that did it has said that if your answer is “no”, its fix should come out until it has been reviewed properly, and I would hold it to that.

When a text or email arrives and the system is too busy to answer it, it retries three times and then parks the message in a holding queue. That queue is the last thing standing between a lost message and a recovered one — nothing else redrives it.

Our stress-test cleanup wipes that entire queue, unfiltered, twice per run, from three separate suites, every night, against the hardcoded production queue — with errors swallowed. It has been doing this since at least 1 August. Anything sitting in there when a test runs is simply gone, with no record of what it was.

Ten lines above it in the same file, another cleanup function explicitly protects non-test rows. So the discipline exists in that very file; this function just doesn’t use it. I have not touched the nightly schedule — that isn’t mine to change.

Short version so this card stands alone: the automatic approval check passes only about 4% of the time, and it is holding several pull requests including a security fix. The cause was found this afternoon and it is not what anyone thought. The check looks for a hidden marker in the reviewer’s comment. The reviewer is configured in a mode that only ever edits one running comment — and the tool it must use to do that strips hidden markers out as its very first step. So the marker cannot survive the normal channel. The rare passes are the runs where the reviewer ignored that mode and posted a fresh comment instead, which is why it looks random.

⚠️ Correction to something you may have read from me earlier: I previously said this check had essentially never passed. That was too strong, and I would rather correct it before you decide than after. It passed twice today, unaided — on two different pull requests, one of which merged on it. So the check is intermittent, not dead. That matters, because it means re-running it on a stuck pull request is a real way through, at roughly a 1-in-25 shot each time.

Two things stop that being the answer. A required check that admits a verdict 4% of the time is not a working check, and everything else stuck stays stuck. And of the pull requests actually waiting, two carry a “do not merge” tag that no agent will remove — so winning the re-run lottery would not release them anyway. Only one of the waiting pull requests could be freed that way.

That means the repair is a configuration change, not a rewrite of the checking logic. It is much smaller than feared. It also means a second repository we pointed to as proof this works turns out to lose the marker too — it survives only by keeping a lenient fallback that we deliberately removed.

Here is the part that still needs you. The pull request that fixes the gate is the one kind of pull request the reviewer refuses to run on. It will not review a change to its own configuration file — that is a deliberate anti-tampering control and it is correct. So there is no way to make a green check appear on this fix. That is by construction, and no amount of re-running changes it.

⚠️ New tonight, and it turns the repair from “the tidier option” into “the one that addresses the actual cause”. One agent tried the cheap way — just re-running the check until it happens to work — and we now know what that route was really waiting for. The reviewer is under an explicit instruction to only ever update its one running comment, never post a new one. The approval marker only survives in a new comment. So the cheap route was not waiting for luck with formatting or length; it was waiting for the reviewer to break its own instruction. Checked across 65 reviews on thirteen pull requests: the approval marker has never once appeared in the running comment — only ever in a new post. (An earlier version of this paragraph said the two always go together in both directions; that was too strong, and the agent who first told me it corrected itself before you read this. The direction that matters here holds.)

So the honest version of the cost, without over-reading it: seventeen full reviews were spent on one pull request for nothing, and on the measured rate you would expect around 25 attempts on average before the first success, with no ceiling — you can be forty in and still owed a hit. That is an argument about expense and open-ended waiting, not about that pull request being cursed. Two agents pushed back on me for framing it that way, and they were right: seventeen misses at this rate is roughly a coin-flip outcome and says nothing special about that change. I have stopped the re-running. The repair below removes the conflicting instruction entirely, so the approval has somewhere to go by design rather than by luck.

This is the thing you would otherwise discover after deciding question 3. Fixing the approval checker does not actually release everything waiting on it. Two of the three pull requests also carry a do-not-merge tag, and our standing rule is that no agent removes one. So after the checker is fixed, those two would still sit there.

Here is the honest complication, and I am giving you the side that argues against my own recommendation. The tag on these was almost certainly applied by our own automation, not by you — eleven seconds after the pull request was opened, by tooling that signs in under your account, so the record genuinely cannot tell you apart from an agent. The tag’s own description says “a human or owning operator has an outstanding concern. Never remove someone else’s” — which arguably lets the agent that applied it take it back off. And on one of them you were already asked about that exact tag nine days ago, told the concern behind it was fixed, and said “merge it and deploy now.”

So there is a real case that this needs nothing from you. I am asking anyway, because it costs you one click on a page you are already reading, and the alternative is an agent deciding its own do-not-merge tag no longer applies — which is exactly the reasoning that turns a safety rule into a formality. The operator holding it made that argument to me and then explicitly declined to act on it, which is why I trust the argument and still want your word.

You chose how this should happen: “You hand-pick one resident and watch it end to end — smallest balance, English, online payer, no dispute history.” That is done. The resident is a three-and-a-half-year tenant at Camellia who genuinely owes $1,150 of August rent — re-checked against the live system minutes ago, not from an earlier reading. She has never been contacted by this system in any way, ever. Her portal is active and she has used it for seven of her last twelve rents. No opt-out, no complaint, no dispute, nothing suppressed.

Both things that were blocking are not just merged but running in production and observed doing their job: the balance fix cleared $43,683.70 of debt that residents had already paid, and her contact window is now computed from her own phone number — 8am to 9pm Denver time, and she is inside it.

⚠️ Here is the snag, and it is why this is a question rather than a notification. We cannot send by approving something, because there is nothing approvable left: every one of the 77 queued items, across 48 residents, has gone stale and can no longer be approved. Approvals expire after 48 hours, nothing has been approved since 28 July, and the reminder schedule only comes round every three weeks — so in practice an item is approvable about two days in seven. To send at all, we first have to create a fresh record for her. That writes to the live system. It texts nobody by itself.

I asked for a second opinion and it could not decide: it gave a different answer depending on which order the options were listed. That is not a judgement, so I am not dressing it up as one — but it did establish the stale-queue mechanism above, which neither I nor the operator had.

Three things the operator raised against sending, unprompted, which I am not going to bury: this would be her first ever contact from us in three and a half years and it would be about money she owes — a judgement about tone, not a defect. The message quotes $1,150 (rent) but her portal will show $1,190, because there is a separate $40 charge and the copy deliberately never invents a combined figure. And she is late by her own habit — she usually pays between the 1st and the 14th — but she is never late under the property’s own 25-day grace period, so “flawless payer” would overstate it and “reliable” is accurate.

On timing — this is here to take pressure off, not to add any. It is legal to text her between 8am and 9pm her time, and it is currently late afternoon in Denver. If you answer in the next few hours she could be messaged this evening; if you answer later, the earliest it goes is 8am her time tomorrow. Nothing degrades either way — the balance is re-checked live before anything sends, and it has already been re-read four times today without changing. The operator holding this said it better than I can: a first send squeezed against a closing window is exactly the shape where someone skips a check, and it would rather roll to morning than be rushed. So please take the time you want. If your answer arrives after her evening cut-off, it will simply be carried out in the morning — the authorisation is for a message, not for a moment.