v10.5.2 — Documented
assembly was missing from the skill. It wasn't — the file has carried it since v10.4.0, in all three copies — but it was in the protocol index and the Tool Reference table and nowhere else, and those are not the parts of the document anyone reads to learn what a tool is for.
Chasing that turned up something older and larger.
The skill had no section on verification
SKILL.md is organised by verb-family: Reading, Writing, Updating, Completing, Interconnection, Lifecycle & Maintenance. Each section explains when to reach for something and why — the reasoning that a one-line table row cannot carry.
assembly and claim appeared in none of them. And consistency(), which has shipped since V9, had no prose section either.
So the two capabilities that check whether the brain is right were the two with no home in a document organised around what the brain does. The gap was structural, not an oversight about one tool.
Verification — consistency + claim
A new section, framed on the distinction that makes them siblings:
consistency() asks whether the brain agrees with itself. The same fact recorded differently in several notes, where every copy reads as authoritative. Run it after correcting anything that could be written down in more than one place — revising one note leaves its siblings silently wrong.
claim() asks whether the brain still agrees with the world. An assertion that was true when written and may not be now. maintain(deep=true) surfaces the lapsed, the never-verified and the broken, which turns "is the brain stale" into a query rather than something caught by luck.
The section also records why BrainLLM never executes a claim's check, which was previously only a code comment: note content is data, not instructions, and a recipe that ran itself would be an injection surface pointed at the user's machine, reachable by anything able to write a note. The tool owns the register and the schedule; the agent runs the check and reports back.
assembly in Reading, against brain()
Placed beside the tool it is most often confused with, with the distinction stated plainly: assembly is awareness, brain is inventory. Titles and shape, sized to be read — versus ids, kinds, statuses, parents and dates, for auditing or locating one note.
Reaching for the inventory when the question was awareness is the actual mistake, and it costs several times the tokens to answer worse.
Two process lessons, recorded
A new tool must reach the skill's prose, not just its index. The release checklist said "update the skill package", and that was done every time — three copies, both zips, every release — while the documentation stayed incomplete. A checklist item that can be satisfied without achieving its purpose is the same defect as a warning nobody reads.
A skill edit never reaches the session that makes it. The skill is read into context at session start, so the session doing the editing keeps working from the version it booted with. Write for the next session; do not expect to use what you just documented.
190 tests, tsc --noEmit clean, build clean. No code changes — documentation only.