docs: the doctrine that governs the product governs the work too

[firejune]

bun run selftest 568 PASS / 0 FAIL / 0 SKIP / 0 HOLE, exit 0 — unchanged, as a doctrine-only change should leave it.

The contradiction this closes

CLAUDE.md's doctrine section opens on one observation: an agent authoring a rig cannot see it, so a parser's silence has to become a named failure, and "the validator's messages are the UI". Everything in the file follows from an author who has no human beside them.

And then the working habit was to carry decisions to a person for a ruling — conventions, wording, scope. Those two contradict, in the same file. A tool built on the premise that the work happens without someone watching cannot be built by asking someone to watch.

Why the correction is a lens and not a delegation

The obvious reading is "the agent may now decide on the owner's behalf". That reading is wrong and this clause says so, because it keeps the human frame and only moves a signature inside it.

Most questions worth carrying to a person are artifacts of looking at the work through a human organisation, where conventions have owners and "which would you prefer" is a real question. Under this tool's own lens the criterion is never preference:

asked of a person	the question under the lens	survives
which convention do you want?	which reading is derivable	no — only one is
should this caption change?	which claim is measurable	no — only one is
is this scope creep?	does a gate already cover it	no — the tree answers
direction, licence posture, spend, text that speaks as the owner	—	yes

Each of the first three answered itself, and each was asked here at least once. What survives is short and none of it is a convention.

🔒 The sharpest clause is the one about not knowing

A question that survives because the tree cannot answer it is a card or a check, never a question. This is the doctrine's own first move applied one level up: the answer to "an agent cannot see it" was never "ask someone", it was "convert the silence into a named failure".

So "I cannot tell" is not a reason to escalate — it is the exact condition this tool exists to remove, and reaching it means the instrument is missing. That makes the habit a product signal rather than a manners question: if a decision needed a person, the tree was short of a check, and the deliverable is that check.

🚨 And it is not a licence for confidence

A reviewer was doing real work — forcing the argument to be said out loud — and removing one without replacing it makes the tree worse, not faster.

The replacement is adversarial structure below: a brief that says measure it yourself rather than trusting this brief, and report what you rejected comes back having contradicted its own instructions where they were wrong. Two claims in a brief were corrected that way on the day this was written, and neither would have been caught by reading the brief again — one was a stated base commit that was not the base, the other a gate the brief named that did not exist on that base.

📖 Who the writing is for

The reader is an agent with no memory of the conversation that produced the work. So a thing settled in a chat and not written into the tree did not happen. What convinces such a reader is what the gates already produce — a claim with its measurement beside it, and the alternative that was rejected with the reason — which is why commit messages and pull requests here carry the argument rather than a summary of the diff. That is the only channel that survives the session.