v1.13.1 ·
The command that answered from the wrong project
Run a command from the wrong directory and you expect an error. That is not what happened here.
Every command asked the operating system where it was standing and treated the answer as the project root. At the top of the project that is correct. From a package subdirectory, or wherever a background process happened to start, it was wrong, and nothing said so.
Writes created a second project inside the first. aidlc cost record one level down printed "recorded estimated entry", exited zero, and put the numbers in a brand-new tree that no report reads. The capture log said ok next to appended: 0.
Reads were worse, because the wrong answer looked like a measurement. From packages/cli/, aidlc status showed all 25 instances as (remote worktree) at 0% with no cost, and aidlc metrics reported 0 instances, 0 with cost data. Those are zeroes in the same layout as real zeroes, from the command this project tells you to trust for true cost. Two stray trees had sat in this repository for eight days, holding usage nothing could read. I found them by accident.
The report named one line
That line was real, and it was a sample. Twenty places made the same mistake, across eleven pieces of work, because there was no shared answer to which project this is. A search found no helper anywhere. Each author reached for the same convenient thing, and it did work from the root.
The fix is one small module. It walks up from the current directory to the nearest ancestor holding a .aidlc/ directory, and falls back to where you started if there is none, so nothing changes outside a project. It requires a directory, not just any entry of that name, so a stray file cannot resolve a root whose every path join then fails far from the cause. Fifteen command modules and the lifecycle event bus now use it.
Where I stopped
A uniform fix would have been wrong for two places. init creates a project. If it searched upward, running it inside an existing project would reconfigure the parent instead of the directory you asked about. discover describes the code it is pointed at, and resolving upward would overwrite a parent's documentation with a description of the wrong codebase. Both keep the old behaviour and say why in the file. start looked like a third exemption and was not. It reads an existing project and writes into it, so from a subdirectory it had been filing work in the wrong tree. It was not in the report. I found it by asking, for each site, whether the command creates a project or consumes one.
The roadmap resolves the primary checkout on purpose, because an inbox written inside a feature worktree is stranded on that branch until it merges. Instance state and cost belong to the worktree that produced them, so the new rule takes the nearest project. Those look like duplication and are not, and a test pins that.
The part that matters most is a test, not a fix. Twenty repaired sites leave the twenty-first free to reintroduce the bug, as quietly as the first twenty. So one test reads the source text and fails when a new unrouted lookup appears, with the exemptions and their reasons stated in the test.
What I left out
I did not build a repair check for the stray trees. The mechanism that made them is gone, and a permanent gate for a defect that cannot recur is a tax on every future piece of work. I removed the last stray tree here by hand, after copying the entry it held into the instance's record.