#1490 extension quality scorer misreads a template-literal import specifier in generated code as an unresolvable bare import, hard-erroring the whole extension as UNSCORABLE

Summary

The server-side extension-quality scorer's static import scanner scans string content inside template literals (i.e. runtime-generated code) as if it were the extension's own static import statements, and reads a ${...} interpolation placeholder as a literal bare import specifier. This makes the scorer hard-error the entire extension as UNSCORABLE even though the extension has no real bare imports and is otherwise fully compliant.

Reproduction

Run the scorer against @magistr/jscad-cad:

swamp extension quality jscad-cad/manifest.yaml --repo-dir <workspace-root> --json

It exits 1 and emits (on stderr, empty stdout):

{ "error": "Extension uses bare import specifiers that cannot be resolved by the server-side scorer: \"${pkg}\". Use explicit npm: or jsr: prefixes in your source files (e.g., \"npm:package@version\")." }

No score is produced at all.

Root cause

In jscad-cad/extensions/models/jscad/script_evaluator.ts (~lines 66-68) the extension builds an eval script as a template literal and writes it to a temp .mjs for a subprocess:

return `
import * as modeling from "npm:@jscad/modeling@2.12.0";
import * as serializer from "${pkg}";
...
`;

pkg is computed at runtime (serializerPackage(format), e.g. npm:@jscad/stl-serializer@...), so the generated import is a valid npm: specifier. But the scorer scans the .ts source text and treats the two import lines that live inside the backtick string as if they were real static imports of the module. The first (npm:@jscad/modeling@2.12.0) has an explicit prefix so it passes; the second is "${pkg}", and the scanner reads ${pkg} as a bare specifier it cannot resolve, then hard-errors the whole extension.

So the scanner is (a) treating template-literal string content (generated code, not the extension's own module graph) as static imports, and (b) not recognizing a specifier containing ${...} as a runtime-interpolated, non-static specifier.

Impact

Any extension that legitimately generates code containing an import with a computed / template-literal specifier — a common, safe codegen pattern — is falsely reported UNSCORABLE, forced to carry a baselinePercentage: 0 UNSCORABLE ratchet, and effectively drops off the quality gate. @magistr/jscad-cad is a real, fully-tested extension (101 tests across five suites) penalized purely by this false positive; it cannot reach a genuine score without deleting a correct runtime pattern.

Expected

The import scanner should either:

1. Parse imports via the JS/TS AST and only consider genuine static import ... from "<string-literal>" statements in the extension's own module graph — NOT string content inside template literals / generated code; and/or
2. Recognize a specifier that is a template literal / contains ${...} as a runtime-computed specifier out of scope for static bare-import resolution, and skip it (or warn) rather than hard-erroring the whole extension.

At minimum, a specifier string containing ${ should be ignored by the bare-import check rather than treated as a literal bare package name.

Notes

• Trigger extension: @magistr/jscad-cad, extensions/models/jscad/script_evaluator.ts:68.
• Found during a broad @magistr extension-quality effort; jscad-cad currently ships a seanime-style UNSCORABLE baselinePercentage: 0 ratchet solely because of this.
• Related but distinct from the earlier report where swamp extension quality exits 1 while still emitting a complete score — this one emits no score at all (hard error, empty stdout).