Skip to content

v1.30.0 ·

The protocol that was already dead

A phase would ask me something without saying why, what my answer blocked, what the repository already said about it, or what happened if I said nothing. I could not decide from that. I could guess, or I could ask for a rephrase, and a question that needs rephrasing is a defect, not a saved token.

That part is a content problem with a content fix. The second failure is the one worth writing about. The framework had a mechanism meant to prevent this, and it had been dead since August.

The protocol said: when you need substantial input, write the question to an inbox directory, put the options as checkboxes and wait. It sat in the overview skill that every session loads. Two commits in this project's history ever used it, and the directory did not exist in the checkout. A dead protocol is worse than a missing one, because it makes the gap invisible. The instructions said structured questions were solved here, and nothing contradicted them.

It died three ways. The trigger was discretionary, "substantial input", which no two readers judge alike. The required content left out what makes a question decidable: what the answer blocks and what the repository already says. And nothing counted an unanswered question, so one could block work with no trace.

It also shared a word with the live roadmap inbox. The bug report that started this work mixed the two up, which suggests one name was wrong.

What changed

The overview skill now carries a question protocol. A question has the decision as one sentence, why it is asked and what it blocks, what the repo already says with a path:line citation, two to four options with their consequences, a marked recommendation, and what happens if I say nothing. The trigger is consequence: ask when different answers would change an artifact, a design decision or scope, and otherwise do not ask. At most five questions stay open at once. Open, not asked in total, so a long negotiation is fine and a pile is not. It is also the only version of the rule a script can check, since an unanswered question is a blank answer tag on disk.

The protocol names no platform tool. How a question reaches me is data, declared per platform and written to .aidlc/resources/questions/rendering.md. Claude Code uses its structured picker. The other five platforms get numbered prose, restarting at 1 for every question, so replying "2" means the second option of the question in front of you. The question file is written either way, as the record of what was asked and decided. Instance questions live beside the instance. A separate location serves cases with no instance, like a constitution update.

Visibility is one count in the entry menu, shown when any question has a blank answer.

Choices

I read AWS's lifecycle and GitHub's Spec Kit first. They disagree on volume: Spec Kit caps at five in total, AWS refuses a cap. I capped open questions instead.

I rejected AWS's habit of asking how I want to answer each time. It spends a turn on something inferable from the question's size. The agent decides, and the file is written in every case, so I can open it when the labels are not enough.

I rejected a stop hook and a phase gate for unanswered questions. A hook works on one of six platforms, and five of six bugfixes in this project came from features that watch the lifecycle. I also rejected a migration for stray files at the old path. The population was zero.

What it does not fix

Implementation reported sixty passing tests covering all twenty criteria. The gate disagreed on nineteen, because every reference used the short form and forty-seven pieces of work here define a criterion numbered one. Eighteen read as untested while tests asserted them, and two really were untested. I did not relax the scanner. A passing suite and a satisfied gate are different claims.