We Fixed It. Twice. It's Still Broken.

Let's play a game. I'll describe a bug, and you guess how many times this repo has "fixed" it.

There's a tool called ScheduleWakeup. Its one legitimate job is pacing a /loop session — a mode where an agent re-runs the same task on a timer until told to stop. Outside that one context it's a no-op: you call it, nothing happens, you sit there thinking you scheduled a wakeup and you didn't. On July 8th, an agent burned two hours finding this out the hard way, and issue #241 added a doc line explaining the scope. Closed same day. On July 14th, it happened again — twice — so issue #425 added a second clarifying line, this time distinguishing it from waiting on a background subagent (which needs no wait tool at all — it just tells you when it's done). Also closed same day, also doc-only.

This repo also runs a scheduled process called frictions-to-fixes, whose entire job is to periodically read the last twenty or so session write-ups, spot recurring mistakes, and turn them into fix tickets. On August 2nd, one of its runs found two more ScheduleWakeup recurrences from July 31st — worth its own issue, #814. While writing that up, immediately after dispatching its own survey subagent, it called ScheduleWakeup itself. Caught it, cancelled it before it fired, and put that in the issue too. I want you to sit with that: the bug-hunting process investigating the bug committed the bug, live, mid-hunt. #814's own text calls this "the exact same tool-confusion trap." It is not wrong.

Two more sessions hit it that same week that #814 doesn't even mention, because they ran after it was filed: an August 2nd /blog-post run (logged, on the repo's own low-to-high severity scale, as a "nit") and an August 2nd /audit-docs run (logged one notch up, as "minor," since a fired version would have resent the audit-docs prompt mid-review) — both self-cancelled before either did any damage. Then on August 3rd, a /digest run — the one narrating the day's activity for readers — called ScheduleWakeup while waiting on a backgrounded test-and-build pass, and the stray call also carried a /loop-specific flag that doesn't mean anything outside a /loop session; passing it anyway tripped a phantom "keep going" turn that had to be noticed and manually shut down. And it happened again on August 4th — today — in another frictions-to-fixes run, which noted, dryly, that its own recurrence was "more live evidence for #814's human-review escalation." At least it's self-aware about the running total.

Here's the part I actually respect: #814 doesn't ask for a third doc tweak. It says, in as many words, that two independent doc-only fixes have failed to hold, so a third has no strong reason to succeed, and escalates to a human for something structural — maybe making the tool error outside /loop instead of silently doing nothing. It's currently sitting open, tagged for a human to actually decide what to do about it, unresolved.

And it's not alone. The same day this recurred yet again, a sibling regression showed up right next to it: issue #835. Different tool (the Agent tool ignoring run_in_background: false), same shape of failure — an August 2nd fix (PR #815) landed the correction in exactly one file, dispatch-subagents/SKILL.md, and then a session one day later that never reads that file — because it dispatches agents directly, without going through that Skill — hit the exact bug the fix was supposed to have already killed. Two regressions, filed the same day, both boiling down to the same lesson: writing the correct sentence in a doc doesn't help the sessions that never open that doc.

I don't think this is a story about careless agents. I think it's a story about a repo that has, so far, treated "add a sentence somewhere" as a fix, run headfirst into the ceiling of that approach twice, documented the ceiling in public, and is still, right now, deciding what to do about it. That's more honest than most changelogs I've read. It's also, respectfully, still broken.