v1.33.0 ·
The brake that was only on half the machine
Finishing a piece of work kept creating more of it.
The framework has always capped what an instance learns. The retrospective distills zero to three lessons and calls an empty result valid. It capped nothing about what an instance queues, so closing something reliably grew the backlog. On the first external project, items landed in the inbox at the rate instances closed: 9 on 2026-09-16, 5 on the 19th, 5 on the 20th, 8 on the 21st. Of the 18 in the inbox on 2026-09-23, triage kept 3. Thirteen had no executive summary, so none could be decided from the top of the file. Four were findings about areas an existing item already owned. This repo's own roadmap shows the same shape: 96 items in six weeks.
Two write paths reached the inbox and only one was described. The capture flow in the roadmap skill requires a six-line executive summary. An item an instance writes mid-phase went through one paragraph in the overview skill that required nothing. That asymmetry, not discipline, is why the inbox only grew.
What changed
The six-line summary now binds both paths. Not yet decided. stays a valid value for any label, because an admitted gap beats an invented figure. A missing section is no longer a valid item.
aidlc doctor gets a report-only check that names inbox items with no summary or missing labels, and says which. It writes nothing under any flag and never touches doctor's exit code. The only possible repair is six lines of judgement about someone else's idea, and an invented case reads exactly like a real one. A repair that does nothing would leave the check red on every run, and a permanently red check is one people scroll past. It parses loosely: it finds the heading and looks for each label inside, with no check on order or length. The thing worth catching is an item with no case at all, and flagging a reordered one would teach people to ignore the report.
A retrospective now queues at most two follow-up items, ranked, with zero valid. Anything past that goes into the instance's own record under a heading marking it observed and not queued. Before writing a new item, the agent checks whether an open item already owns the area and appends a dated section to it if so.
The hardest question was how to tell parked work from dropped work, since both moved to the hold directory. The item offered a sixth status directory or a new frontmatter field. A directory would have to be threaded through the status list, the sync configuration, the layout migration, browse, the entry point's counts and the website. A field needs the extension-field mechanism and gives the framework one more thing to validate. I took neither. A history entry may now carry a reason, and a move to hold must supply one, starting parked - or declined - . Status still comes from the directory, so no second copy of status exists. The reason is written as a double-quoted scalar, always, because an unquoted comma or colon ends the entry early and takes the whole item's frontmatter with it. Five of the first 49 items went invisible for up to ten days to the title version of that bug.
Agreed work gated on something that does not exist yet can now be parked with its trigger written down, instead of sitting in the backlog counting as ready. Two of that project's eleven "ready" items were in exactly that state.
What it does not do
Three of the four rules are prose in shipped skills, and nothing at runtime checks they were followed. That was a choice. Tests pin that each instruction is present, so deleting a rule fails the suite even though breaking one does not. I refused an inbox size limit that blocks starting work. It would have been the eighth feature whose whole job is watching the lifecycle, and the previous seven are where five of six recorded bugfixes came from. No counter ships. I will judge it once, by hand, on the named project: at most two items queued per close, none written by an instance without a summary, and an inbox no larger after triage than before.