Site-wide content search — high-level pointers (local fallback)

patrat tells you where a phrase or pattern appears across a site. The detailed, current copy-scoping and site-search standards — how to write a safe regex rule, when a literal find is enough, how to hand a match list to the write lane — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• A match is a lead, not a defect. patrat never fails a run — treat every hit as a page to review before editing, not a problem to fix on sight.
• Scope before you edit. Read every match’s surrounding sentence first; the same phrase can be a fact in one page and a stray mention in another.
• Prefer --find over --rules for a literal phrase — a name, a town, a decommissioned product. Reach for a regex rule only when the pattern genuinely varies (spacing, punctuation, plurals).
• Test a new regex on one page first. JS RegExp has sharp edges (backtracking, unescaped metacharacters); a bad rule can silently match nothing or far too much.
• A page that can’t be fetched is not a clean page. It is listed with its error and excluded from the match count — don’t read a fetch failure as “no mentions.”
• JS-rendered content is invisible to the search. patrat reads the delivered HTML; a phrase injected client-side needs --shots (or a rendering check) to confirm it’s actually gone or present.
• Hand the match list to the write lane, don’t edit from memory. cinccino, sigilyph and slowking do the actual edits — patrat’s job ends at a scoped, page-by-page list.
• Re-run after the edit. The fastest confirmation that a site-wide copy change actually landed everywhere is the same search coming back empty.

Full playbook → the team wiki’s copy-scoping & site-search standards.