fix(rules): ARCH-020/glob-scan-dot matches .scan() inside comments and strings

[rhuanbarreto]

Found by an audit that asked, for every agent-memory claim, "would a rule have caught this?" This one is the reverse: memory was recording a defect in one of our own rules.

The bug

ARCH-020/glob-scan-dot greps raw file text:

// .archgate/adrs/ARCH-020-glob-scan-include-dotfiles.rules.ts
const callPattern = /\.scan\(([^)]*)\)/gu;
// ...
content = await ctx.readFile(file);

ctx.readFile() returns the whole source, so the pattern matches .scan( inside comments and string literals, not just real call sites. A comment that merely mentions .scan() — for example one explaining why a call site uses dot: true — is reported as a violation.

The workaround that had accumulated in agent memory was "rephrase comments to avoid the literal .scan() text", i.e. contort the prose to appease the checker. That is the wrong direction: a governance rule should not shape how code is commented.

The fix

ARCH-022 shipped ctx.ast() precisely for this. The rule should walk the tree and inspect real CallExpression nodes whose callee is a .scan member access, rather than regexing text. Comments and strings then cannot match by construction.

ARCH-022-ast-aware-rule-context.rules.ts (ast-guardrail-ordering) is a working example of a rule that parses source via ctx.ast().

Fire-test both directions

Per this repo's rule-authoring practice, verify:

1. A genuine glob.scan({ cwd }) without dot: true still fails.
2. A comment or string containing the literal .scan() no longer fails.

The second is the regression this issue is about, and it is the one a clean-repo run will not prove.

Provenance

Confirmed live at .archgate/adrs/ARCH-020-glob-scan-include-dotfiles.rules.ts:16.