v1.27.1 ·
The plus sign that meant two things
A refresh command rewrote 19 files and said nothing about what it had taken away.
Compiled phase skills are build artifacts, regenerated from the project context documents. In practice they were also the only place hand-written architecture and style prose survived, so authors wrote into them. Then an unrelated refresh, triggered by a one-line edit that added a guidance layer, destroyed the writing with no diff, no warning and no way to opt out. In the reporting project the regenerated text claimed the codebase had no product runtime and no cloud resources, four commits after a verified deployment. It had replaced a real style guide with auto-detected file-count percentages and one convention that was plain wrong. Agents read those files during a phase, so the damage landed where it misleads most.
Four separate defects made it hard to catch.
The dry run showed filenames, not content. A plus sign meant "created" and also meant "replaced your prose with older prose", with no legend and no line counts. The file list double-counted: 29 marked lines for 19 files, because each skill was listed once per platform. The success report said 19 updated and 93 unchanged, with nothing to tell "refreshed to identical bytes" from "replaced what you wrote". And aidlc doctor called everything fine while the context documents were six commits behind the code and the committed artifacts disagreed with their sources.
Under all four is one property: the operation was silent. It was not too aggressive, and it was right about which files it owns. It did what it was built to do and told nobody.
What changed
Both the dry run and the real run now print a record per file: create or overwrite, with line counts, from one shared producer so the two cannot disagree. Each path appears once, 57 for 57 on this repo, down from 75. Every generated body carries a marker with the version that emitted it, a hash of the body, and the two places to edit instead. Two new doctor checks only report: artifact-source-drift and context-doc-stale. And aidlc discover --force now asks before destroying a hand-owned context doc, and declines when it cannot ask. I also wrote this repo's own .aidlc/context/style-guide.md, from measurement.
Why this way
The report came with five ranked fixes, and two of its premises did not survive checking. Hand-written context already had a home: four hours before the tag the reporter ran, a fix landed so that removing the generator marker from a context doc makes discovery leave it alone. Nothing said so, which is a cheaper problem. And this repo had not lost prose. Its style guide was 304 bytes in every commit, and the sentence quoted as evidence appears nowhere in its history. The reporter was a downstream project.
For detecting drift I rejected recomputing what the compiler would emit. It reaches the knowledge engine, which loads Node's experimental sqlite binding and prints a warning, so every routine health check would carry it, on every project. Letting each artifact describe itself makes the check a file read. It can also tell a framework upgrade from a human edit, and the remedies are opposite: an older artifact wants refreshing, an edited one wants someone to decide whose text is right.
I rejected a prompt before every overwrite, because the refresh command has no unattended mode by design and a question would turn a silent overwrite into a hung pipeline.
What I did not build
The fifth fix, splitting the framework upgrade from the project-content re-inline, is filed as a backlog item that argues for dropping itself. Most of the harm was that the rewrite was silent, not that it was atomic, and a new flag is paid for on every future run.