CodeQL silently skips serving-cost-meter.mjs entirely: statement-initial import.meta breaks the extractor

Context

@tobiu surfaced this from Settings → Advanced Security → Code scanning, where CodeQL reports 1 warning — Could not process some files due to syntax errors against ai/scripts/benchmark/serving-cost-meter.mjs#L309: "A parse error occurred: Unexpected token."

Surfaced while investigating a separate, adjacent miss: a CodeQL alert sat unread for 7h on an approved PR (#15310) because gh pr checks reports CodeQL — pass while findings are posted as inline review comments. This ticket is the other half — not a finding nobody read, but a file nobody scanned.

Live sweep 2026-07-17T05:0x: latest 20 open issues plus targeted codeql / parse error / import.meta searches. No equivalent issue exists.

The Problem

The file is valid. The scanner is wrong. The consequence is ours: CodeQL does not analyze this file at all.

// serving-cost-meter.mjs:309 — node --check: OK
import.meta.url === `file://${process.argv[1]}` && main().catch(error => {

import.meta in statement-initial position is ambiguous with an import declaration until the parser reaches the .. CodeQL 2.26.0's JavaScript extractor (codeql/javascript-all 2.8.0) fails there; Node parses it without complaint.

A parse failure is not a skipped line — the extractor drops the whole compilation unit. All 312 lines / 14,061 bytes are unscanned, and have been since the file landed:

ba6645acdf  Grace  2026-07-11  feat(ai): serving-cost meter — the measurement instrument
                               for the always-on inference load (#14687) (#15013)

Six days of zero coverage on a file I wrote, reported as a warning nobody reads on a page nobody opens, while the PR check said pass. This is the same class as the alert on #15310 one layer deeper: an instrument reporting confidently about code it never parsed. The scanner cannot tell you it didn't look.

The Architectural Reality

The pattern is the cause, with a clean discriminator across the repo:

One file uses the shape; that one file fails. 226 files use import.meta in every other position and none is flagged. This is not a general import.meta incompatibility — it is specifically the statement-initial position.

The expression-statement cond && main() idiom is what forces import.meta to the front. Hoisting the test to a const removes the ambiguity without touching semantics.

The Fix

Replace the statement-initial expression with a named condition:

const isDirectRun = import.meta.url === `file://${process.argv[1]}`;

if (isDirectRun) {
    main().catch(error => {
        console.error(`[serving-cost-meter] ${error.message}`);
        process.exit(1)
    });
}

Verified: parses under node --check, and rg -c "^\s*import\.meta" on the shape returns 0 — the trigger is gone. Semantics are identical (the comment at :308 — "commander parses only when executed directly — importing the pure helpers above never runs a sample" — still holds, and should be kept).

Not in scope: excluding the file from analysis via a CodeQL config. That would convert a fixable 1-line parser trigger into permanent, sanctioned blindness — the wrong direction for the only file in the repo that has this problem.

Contract Ledger

Decision Record impact

None. A one-line idiom change to restore scanner coverage.

Acceptance Criteria

• serving-cost-meter.mjs contains no statement-initial import.meta (rg -c "^\s*import\.meta" ai/scripts/benchmark/serving-cost-meter.mjs → 0).
• The direct-run guard's behavior is unchanged: executing the script runs main(); importing its helpers does not.
• node --check passes.
• Post-merge on dev: the Code scanning configuration page reports the Could not process some files due to syntax errors warning as cleared, and the CodeQL analysis no longer lists the file as unprocessed. This is the real AC — the local checks above only prove the trigger is gone, not that the extractor recovered. CodeQL runs on push to dev, so the next scan is the oracle.
• A repo-wide guard against reintroduction is considered and explicitly dispositioned (see below), not silently skipped.

Reintroduction guard — decide, don't assume

The 1-vs-226 split says this is rare enough that a lint may be over-machinery, and the file's own author (me) wrote it without noticing. Options to disposition in the PR:

1. Nothing — CodeQL's own warning is the detector, once anyone reads that page. Weak: this ticket exists precisely because nobody did for 6 days.
2. A one-line ESLint/ripgrep guard in the existing lint surface: ^\s*import\.meta is a trivial, zero-false-positive pattern (226 legitimate uses do not match).
3. Fail CI on a CodeQL processing warning — the general form, and strictly better if reachable; it catches every future extractor gap, not just this one.

Option 3 is adjacent to the code-scanning merge-protection ruleset being set up in the same session (code_scanning rule, security_alerts_threshold), but that rule gates alerts, not processing warnings — a file that fails to parse produces no alerts and would sail through it. A scanner that cannot parse a file is indistinguishable from a clean file at every gate we have. That gap is the durable finding here and belongs in whichever option lands.

Out of Scope

• Excluding files from CodeQL analysis.
• The 20 pre-existing open CodeQL alerts on dev (11 high / 9 medium) — separate lanes.
• The ci-security-audit.md skill correction (it currently models the false inference "Ran gh pr checks… CodeQL passes… No deep red flags") — post-release substrate batch.

Retrieval Hint: "codeql parse error import.meta statement-initial extractor serving-cost-meter unprocessed file silent coverage gap"

Authored by @neo-opus-grace (Grace, Claude Opus 4.8). Surfaced by @tobiu.