chrome-extension: convert the classic-content-script rule to a check (content-script-module-syntax)

[missingbulb]

Fulfils the prose-to-checks sweep dispatched in #572 (a task dispatch, so no auto-close).

What was swept

packs/ and .claudinite/local/packs/ — every pack's RULES.md and the SKILL.mds beside them — read against the check-the-world question from engine/checks/DESIGN.md: does the rule constrain a static signature in the repo artifact? Dedupe was against the live rule catalog (packRules, 65 rules before this change).

Most of what's left in the prose backlog is correctly prose: runtime browser divergence (web-speech, node's jsdom rules), in-flight judgment (spec-driven-product, basics, research-project), deployment-time platform behaviour (aws-sam), and the python pack's own header says its residue is "architecture judgment that has no false-positive-free static signature". One rule stood out as always-testable and unconverted.

The prose converted

packs/chrome-extension/RULES.md:

A registered or static content script runs as a classic script — it can't be an ES module. chrome.scripting.registerContentScripts and static content_scripts inject their files as classic scripts (there is no type: 'module' mode…), so a top-level import in one throws Uncaught SyntaxError: Cannot use import statement outside a module — in the host page's console, not the extension's…

The manifest names the injected files, and a static import/export in one is a static signature in the source. The failure mode is exactly what a check is for: the script silently never runs, and the SyntaxError lands in a console the extension developer isn't looking at.

The check: content-script-module-syntax (blocking)

packs/chrome-extension/content-script-module-syntax.mjs, registered in that pack's pack.mjs. Blocking because it is a defect, not a direction — the content script does not run at all.

Parsed, not grepped (the skill's rule — grepping ^import across an extension would flag the whole codebase, since module syntax is correct everywhere except this one injection surface):

• The judged file set comes from the manifest — the paths a content_scripts entry's js array names, resolved against the extension root — plus the js string literals on a chrome.scripting.registerContentScripts(...) call. A module the content script dynamically imports is never in that set.
• Comments stripped and string/template literal contents blanked before judging, so prose describing the trap and a code string a script builds to inject elsewhere can't fire it.
• Dynamic import(...) — the documented remedy — and import.meta are excluded by construction: the match requires a specifier or a binding right after the keyword, never an opening paren.
• Self-gates to [] when the repo carries no manifest.json declaring manifest_version.

The finding's fix carries the remedy the prose teaches: register a tiny classic loader whose only statement is import(chrome.runtime.getURL('…')), then list that module and its transitive import graph under web_accessible_resources.

The proving fixture (see-it-fail)

packs-tests/chrome-extension/content-script-module-syntax.test.mjs — 7 tests. Neutering run() to return [] turns all three violating fixtures red and leaves the four guards green, which is the see-it-fail evidence:

static import in a manifest-declared content script	red when neutered (also asserts the imported lib.js itself stays quiet)
top-level export default	red when neutered
a file declared via registerContentScripts	red when neutered
the classic dynamic-import loader + import.meta	quiet (FP guard)
module syntax only in a comment / a template literal	quiet (FP guard)
the module service worker and a page script	quiet (FP guard)
a repo with no extension manifest	quiet (FP guard)

Deletion test — the paragraph STAYS

Applied per the skill, and it discriminates rather than deletes here. The finding's why carries the rule and the host-page-console diagnostic; its fix carries the classic-loader remedy. But the paragraph also carries a second rule the check does not enforce — listing the module's whole transitive import graph under web_accessible_resources gated to the target origins, and having a test walk that graph so a newly added import can't fall out of the list. A paragraph carrying more than the check is not redundant, so it is not trimmed.

Surface

Bounded to the conversion: the new rule module, its pack.mjs line, its fixture test, the pack README's enforcement row, and the corpus tally in packs/README.md (65 → 66, which packs-tests/catalog-tally.test.mjs guards).

Green before opening

• node --test $(git ls-files '*.test.mjs') → 1008 pass, 0 fail (1001 before, +7 new).
• node engine/checks/check_the_world.mjs → exit 0, 0 blocking, 9 advisory — all pre-existing file-placement advisories in engine/, none touched by this change.

---

Generated by Claude Code