No CLI clears a --verified stamp

docir update <id> --verified stamps today. Nothing un-stamped it.

A stamp applied by mistake — during a sweep, or on a document that was re-read rather than answered — was permanent short of hand-editing the file, which the CLI otherwise forbids and docir check then reports as a hand-edit.

What was observed¶

Reported against 0.23.0 on a corpus carrying two documents whose verified: line asserted a review nobody had done. They were reported to their owners through a side script, because docir itself had no way to take the claim back.

Why it matters¶

Thesis 2 says the CLI is the only write path, and that is what guarantees frontmatter consistency. A field the CLI can only set and never unset forces exactly the hand-edit the tool exists to prevent — and then flags it. Every other optional field already has its clearing spelling: --set-owner "", --set-code "", --set-isolated "", --set-tags "".

verified had none, because it is a flag rather than a value: --verified takes no argument, so there was no empty string to pass.

Resolution¶

docir update <id> --clear-verified erases the stamp (adr-f4e6ade4afd0). It records no revocation date and grants no review window: the document ages from created again, exactly where one nobody ever verified sits, so a stamp taken back on an overdue document puts it straight back on the review queue.

That is the half worth stating, because the other withdrawal behaves differently on purpose. An edit to a verified document also withdraws the verification, and that one does restart the cadence — something true stopped being true. A stamp nobody earned was never true, and gets nothing.

The flag is refused when no verification is standing, so it cannot manufacture review state on a document nobody vouched for.