SPEC-134 phase 3, minus the validation rail. The feature exists after WORK-592; this is the part that gets it used.
Two pieces, both small:
Tracking started Sep 22 — check back for trends.
0fb6810Marking every snippet would make --check permanently noisy and train everyone to ignore it. Authors mark the references whose prose makes specific claims about the code beside them.
The selection is the work here, not the stamping — refrakt snippet review <page> does the mechanical part. Reading a page and deciding whether its paragraphs actually assert something about the slice is what this item is for.
The natural starting set is the pages WORK-590 migrated, since those are the invocations someone has just looked at closely — but migration and marking are different claims and must stay different commits.
SPEC-134 phase 3 lists the editor validation rail alongside these two. That rail is WORK-395's, which is unmilestoned and outside this milestone. Stale markers reach their audience through the dev-server diagnostics WORK-575 shipped and through --check; the rail is an improvement on that, not a prerequisite for it.
reviewed when inserting a snippet, file-ref or expand--check runs clean across site/content after the marking passStamp-on-insert reuses WORK-592's stamping path rather than recomputing a hash in the editor package — the normalization must not have two implementations.
For the marking pass, work page by page and write down why each page was or was not marked. That record is what stops the next person marking everything.
If --check is noisy immediately after this lands, the remedy is unmarking pages, not loosening normalization. A marker that fires on a page whose prose did not actually depend on the slice is a selection error, and normalization is the wrong place to fix it.