Function is_code_fence 

pub fn is_code_fence(line: &str) -> bool

Whether line opens or closes a fenced code block — a run of three or more backticks or tildes, after leading whitespace.

The delimiter is CommonMark’s; the indentation deliberately is not

CommonMark allows at most three spaces of indentation before a fence at a block’s content column, and this accepts any amount. That is not laxness, it is the limit of a per-line predicate: four spaces at the top level open an indented code block, and the same four inside a list item open a perfectly ordinary fence. Checked against pulldown-cmark: a four-space-indented backtick fence is Indented on its own and Fenced under - item, so the bound is relative to a container this function is never told about. A fixed limit of three would therefore break fences this repository already has: see crates/rto-render/tests/fixtures/okf-upstream/acme_retail/skills/run-on-bq.md, where a json fence sits four spaces deep inside a list.

Callers that need the real rule need a document scan, which is markdown_links’ “One line” note all over again. Raised in review on #806 as an overstated claim, and it was one.

Three scanners in this workspace do not use even the delimiter half

rto_render::docs recognises both delimiters. rto_spec’s ADR, blueprint, site-page and lat.md scanners each carry their own trim_start().starts_with("```"), which recognises only backticks — noted at the ADR one as a known narrowing. So a ~~~-fenced example is code to the renderer and prose to the gate, and a [[…]] inside one is a link the gate resolves and the site renders literally.

That divergence is not closed here, because closing it changes what the gate counts and this rule’s introduction is not the change that should decide it: no document in this repository fences with ~~~ today, so unifying them moves nothing now and would move the count the first time somebody wrote one. It is written down here instead of staying an accident of five copies.