feat(sql): extend the table scanner with DDL verbs and the Access IN clause

[ardelperal]

What changed

Task T15 of the VBA node-discovery plan. The shared SQL table scanner — the one module every SQL path in the project uses — gained two things:

1. CREATE TABLE / ALTER TABLE / DROP TABLE. All three targets are captured and carry access: 'write'; creating, reshaping or dropping a table are all mutations of it, so "who writes to table X" now reports them. The two-word keywords are normalized to a single interior space so clause stays a stable enum value.

2. The Access IN "<path>" clause. The operand is an external database file, not a table, so it gets its own scanner rather than being folded into the table rows. It emits a file-kind node keyed on the normalized path (lowercase, forward slashes, collapsed/trimmed separators, UNC prefix preserved) with metadata: { external: true, backendPath }, plus a references edge tagged synthesizedBy: 'vba-external-backend'. No new NodeKind.

   The node is keyed via a synthetic file path (same trick the TempVars sweep uses) and every one of its fields derives from the normalized path alone — no line, no column, no per-caller language — so all three emitters produce a byte-identical node and the same backend named from two different queries converges on ONE node. Per-site position lives on the edge.

   Only a quoted operand matches, which is what separates the external-backend clause from the IN (1,2) value-list operator without writing a parser. The empty operand of the ODBC/dBASE connect-string form (IN "" [ODBC;DSN=x]) names a DSN, not a file we can key on, and is dropped — silent beats wrong. A first alternative also handles the VBA doubled-quote shape (… IN ""C:\x.accdb"""), which is how a SQL literal built in VBA source reaches the scanner.

All three consumers were wired up, since a change to this module is a change to all three: the in-code SQL sweep (vba/sql-wrapper.ts via a new context helper), the form RecordSource/RowSource bindings, and the saved-query extractor.

The risk: the reserved-word reject list

SQL_RESERVED_TABLE_TOKENS is the project's main defence against emitting WHERE as a table name, and adding new capturing clauses is exactly the change that could weaken it. It is untouched, and is now regression-tested explicitly rather than incidentally:

• its exact contents are pinned (all 21 tokens, no more and no fewer — the test fails if one is ever removed);
• every token is swept against every capturing clause, including the three new DDL verbs and their schema-qualified forms;
• the original issue fix(vba): SQL_TABLE_RE captures reserved words as table names in concatenated SQL #203 reproduction cases are re-asserted at zero captures.

CREATE TABLE ? (…) / DROP TABLE ? — the ?-sentinel shape a dropped concat operand produces — capture nothing.

Testing

• New file __tests__/sql-clause-coverage.test.ts: 78 tests, all green. Covers DDL verbs, the reject-list regression sweep, path normalization, the IN scanner (double/single/doubled quotes, value-list operator, empty operand, dedup), the node builder, and all three consumers end-to-end — including the acceptance criterion that the same external path named from two different queries converges on one file node.
• npx tsc --noEmit: clean.
• npx vitest run (full suite, after npm run build): 3273 passed, 21 failed. Those 21 are pre-existing and environmental, not caused by this change — I verified it by reverting the source changes and re-running the same four files, which produced the identical 21 failures (worktree-detection 15, npm-sdk 2, multi-repo-workspace 2, extraction 2 — all Windows EPERM temp-dir cleanup in afterEach, plus two npm-bundle packaging tests). None of them assert extraction behaviour.

Acceptance criteria I could NOT verify

• "sqlTablesReferenced rises; no reserved word appears among the new names." I did not run the T0 coverage probe against a real Access project — no .accdb-backed corpus was available in this environment. The direction is guaranteed by construction (only new captures are added; no existing capture path was narrowed) and the reserved-word half is covered by the sweep above, but the actual before/after number is not measured here.

🤖 Generated with Claude Code

https://claude.ai/code/session_019gmKKUq1ng5ESk6Qhxu77d