What problem does it solve? When the same rule is enforced by two hand-copied regexes in different places (migration SQL vs TypeScript source, rate-config side A vs side B), the copies drift and the weaker one becomes an evasion vector — for example, a source scanner that misses INSERT OR REPLACE INTO"events" or schema-qualified main.events while the migration matcher catches both. ## Core Features & Use Cases - Shared matcher fragments: Build the target-matching regex once from shared delimiter, schema, and quote fragments, and have every enforcement surface consume the same builder instead of re-authoring patterns. - Parity testing: Run one evasion probe corpus (abutting quotes, schema-qualified names, bracket and backtick delimiters) through every scanner so divergence fails the test and cannot merge. - Review guidance: Use it when writing identifier/schema/delimiter regexes or reviewing anything under tools/checks/; any new check on a guarded identifier must call the shared builder. - Use Case: While adding a lint rule guarding the append-only tables events, positions, and money_lines, derive both the migration-SQL and TS-source scanners from one guardedTargetMatcher() builder and lock them with a parity test over a shared evasion corpus. ## Quick Start Ask the AI to refactor the duplicated forbidden-replace regexes in tools/checks so both scanners share one matcher builder and add a parity test over a common evasion corpus.
