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:
ab57f069762a8045c53a2d40fe65Marking 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 or a file-refexpand — WORK-591 does not accept reviewed there, because expand resolves no slice to hash--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.
Completed: 2026-09-24
Branch: claude/v0-37-0-review-vqpl41 PR: refrakt-md/refrakt#649 (batched with WORK-591 and WORK-592)
packages/editor/src/stamp-on-insert.ts (new), wired into the editor's PUT handler so a page is stamped as it is saved.site/content.site/content/runes/snippet.md, including the selection rule.packages/editor/test/stamp-on-insert.test.ts — 10 tests.{% snippet %} is dropped in it has no path=, so there is no slice to hash. The first point the invocation names a real region is the write.--check would fire on everything the editor touched. Pinned by a test comparing against formatMarker(hashSlice(...)) directly.Exactly one reference is marked, and the reason is the finding rather than a shortfall.
Almost every live snippet in site/content demonstrates the rune that quotes it: the prose says "here is what lines= does", not "this code means X", so a change to the quoted file does not make the sentence false. Marking them would make --check permanently noisy and train everyone to ignore it, which is exactly D8's warning.
Marked:
runes/file-ref.md:67 — symbol="SiteConfig", where the drawer content is the subject of the sentence around it.Deliberately not marked:
runes/snippet.md — demonstrations of the rune, including several that slice mid-construct precisely to show what line addressing does.runes/codegroup.md, runes/drawer.md, runes/file-ref.md:24,72 — the same, for their own runes.index.md:8 — path=$file.path, self-referential and not statically resolvable.releases.md:842 — whole-file embed of a changelog.refrakt snippet review <page> stamped two; one was removed by hand. The second was a file-ref at package.json, which changes on every dependency bump and would fire constantly while certifying nothing. The tool was right to stamp it — it stamps unmarked invocations on the page it is given, and deciding which deserve a marker is a human's job. That is what this item is for.
The pages that would most benefit are the guides, and they do not quote code at all — which is WORK-595's observation, and the reason that item exists.
refrakt snippet review --check runs clean across site/content, exit 0.