v1.10.1 ·
A front door for the CLI: bare `aidlc` opens a menu
Type aidlc with nothing after it, and until this release you got an error. Commander printed the help screen to stderr and exited 1. That was a newcomer's first contact with the tool: a failing exit, and a list of 19 commands, some nested three levels deep, with nothing saying which one you run first.
A menu, not a second brain
Bare aidlc now opens a launcher. Twelve commands, grouped by lifecycle stage: set up, health checks, begin new work, resume, inspect, maintain. Arrow keys to move. Every row shows the command it runs, like Begin new work · aidlc start, so the menu teaches the CLI instead of hiding it. aidlc menu opens the same thing by name.
Commands that need nothing run when you pick them. Two need arguments, aidlc review and aidlc knowledge query, and they ask for exactly those. Optional flags are never asked about. aidlc start already has its own template picker, so the menu hands you to it instead of wrapping it in a second one.
The menu knows nothing about your work in progress, on purpose. It could have read the lifecycle state and said "continue cost-tracking at 85%". That would have been nicer for a day. But the question "what should I do next?" already has an answer, in the aidlc skill, and two places answering it would drift apart. This project has paid for "two definitions of one thing, one of them wrong" three times already. So the menu answers "what commands exist" and nothing more.
Scripts see no change. aidlc --help, aidlc bogus and every flag form give the same output, on the same stream, with the same exit code. Only the bare command changed, and only in a real terminal. In CI, a pipe or an agent's subprocess it still prints help and exits 1.
The blog had stopped telling the truth
Two releases had shipped with no post, and nothing said so. publish: false in the blog manifest meant two things: "never" for one patch release, and "not yet" for the other, with a note asking to revisit it. Nobody ever did.
Now a decline has to say which kind it is, never or deferred. A deferral re-checks itself before every release by trying to generate the post, and the release stops if the blocker has cleared. Each manifest entry is also checked against git, so it cannot quietly leave out an instance. That is how the release that shipped the blog generator had ended up with no post about itself. Both missing posts are now on the site.
The release that could not release
The release script deadlocked. Generating a post needs the tag to exist. The manifest stored the tag's date, which cannot be known before tagging. Add the entry first and four tests failed; leave it out and generation failed.
The fix deleted the duplicate instead of reordering around it. The date now comes from the tag, and a stored copy is rejected, so it cannot creep back. The script tags locally first, generates, then folds the post into the release commit. Nothing is pushed until the tests pass, and a failure puts the repository back exactly as it was.