A code glob nothing is watching is a finding, not a silence

Decision¶

docir check reports code-unwatched: a code: glob that resolves against the working tree and carries neither a code_baseline nor a verified_code digest. A Tier 1 warning, repaired by docir check --fix.

The gap it closes¶

Four findings read a document's globs, and until this one they left a hole between them:

the glob	finding
names nothing	unmatched-code
moved since a verification	code-changed
moved since it was declared	code-drifted
names something, nothing watching it	nothing

The last row is not an edge case. A decision written before the code it decides is the ordinary case the write path deliberately accepts, and it has nothing to fingerprint, so it records no baseline. unmatched-code does fire while the path is absent — and it is a different finding, saying "update the pattern" rather than "the baseline is about to be taken empty". It then stops the moment the file arrives, taking the last signal with it. The file appearing reports nothing. Every later edit reports nothing.

mint_baseline would fill the missing entry, but only on a write, and check never writes.

Why a finding rather than a refusal at stamp time¶

Refusing --verified on a glob that matches nothing was the alternative, and it punishes the correct workflow: writing the decision before the code is the shape the code: field was built to support (A code glob hashes what the repository tracks, not what it builds keeps Tier 0 accepting a pattern that matches nothing for the same reason). It also cannot help the other route in — a document written by a build that minted no baseline at all — because no stamp happens there.

A finding covers both, and it is the only one that reports the transition: the state becomes wrong when the file arrives, which is after every write anyone made.

Why it is repairable when its three siblings are not¶

code-changed, code-drifted and unmatched-code all clear on a judgement — read the document against the code, or decide the pattern is wrong — so check --fix has nothing to read with. This one clears on a fact: a baseline records what the tree held when watching started, and claims nothing about who looked at it. That is the line verified_code is fenced by (A verification records what the code looked like), and minting a baseline does not cross it.

check --fix already carried the repair. What it lacked was a finding to answer — so the repair existed for anyone who ran --fix speculatively, and for nobody else.

Watching starts at the next change, not at the one already missed. The repair therefore reports one action per document rather than running silently: the frontmatter of every governed document moves, and the reader has to see that in the diff.

Why a warning¶

The document is intact, the glob resolves, and the only fault is its own history. An error kind would red-build the first commit of every document written before its baseline could be minted — a correct corpus failing for a reason no commit in front of the reader caused, which is the failure mode every Tier 1 warning here is written to avoid.

Reported per pattern¶

A document carrying two globs, one armed and one not, was already in the queue for the armed one while staying silent on the other. Being in the queue is not evidence that every glob on a document is watched, so the finding names the pattern.

Measured on the reporting corpus: nine documents carried a verified glob with no fingerprint, and eight produced no finding of any kind. The ninth was visible only by accident.

Consequences¶

Every glob in a store is now in exactly one of four states, and each names its own exit. A code glob a repository ignores entirely is still the code it governs depends on this: the globs it un-silences arrive carrying no baseline, and code-unwatched plus check --fix is the recovery path they take.