findable-new-checklisted

# Adding a check to findable-audit `buildChecks().length` is the **only** source of truth for the check count. Everything else — both READMEs, both guides, the CLI help, the web copy, the plugin skill, the Action's Marketplace description — repeats that number by hand. Three gates fail loudly if you get the code wrong; **nothing fails if you forget the copy.** That asymmetry is what this skill exists for. Derive the real numbers from code, never from a previous document: ```bash npm run build --workspaces node -e "const{buildChecks}=require('./packages/cli/dist/checks/index.js');const c=buildChecks();const f={};for(const x of c)f[x.family]=(f[x.family]||0)+1;console.log('total',c.length);console.log(JSON.stringify(f,null,0))" ``` ## 1 · Spec first Write `docs/superpowers/specs/<YYYY-MM-DD>-<slug>.md` before any code. Follow the shape of `2026-07-26-lot5-chunker.md`: inherited constraints, one section per check (sources, thresholds, verdict table), an integration checklist, non-goals. Decide the **verdict policy** here, and justify it against `docs/research/`: - Unambiguous, verifiable defect (broken canonical, blocked crawler, hidden injection payload) → `fail` is allowed. - Content-shaping heuristic (style, phrasing, structure) → **warn max, never fail.** Verified research says effectiveness varies by domain and retrievability beats rewriting; a heuristic that fails a site overstates what we know. - Precondition absent → `skip`. Never `pass` a check that did not