[finding] The empty-generator refusal reads `Failed to load generator "": is not a valid JS file` — a double space, because bundle-require concatenates an empty filepath

[os-litant]

The defect

Once os lint --eval --generator "" refuses (PR #16341 / card #16161), the message it prints reads:

Failed to load generator "":  is not a valid JS file

— with two spaces between the colon and is.

Why

bundle-require composes its own message as FILEPATH + ' is not a valid JS file'. When the filepath is the empty string the concatenation contributes nothing, so the leading space of the upstream fragment lands directly against the space that follows our own : separator. Neither side is wrong on its own; the seam only shows for an empty filepath, which was unreachable before #16341 — the truthiness guard skipped the whole load block, so no message was printed at all.

⇒ This is a defect newly made reachable by a correct fix, not a regression it introduced.

Why it was not fixed at the site

⛔ Deliberately not special-cased in PR #16341, and that reasoning is right and worth preserving: a bespoke message for the empty value is exactly the separate refusal shape that PR documents itself as not inventing. #16161's whole argument is that the empty string should answer through the door an unresolvable path already answers through — inventing a hand-written message for it would have quietly created the second shape the card exists to avoid.

⇒ A message-quality card, not a rider on that diff.

Shape of a fix, for whoever takes it

Not prescribed — but note the choice is real and should be argued, not assumed: trimming our own separator would fix the empty case and leave every non-empty case unchanged, whereas special-casing the empty value re-introduces the branch #16161 refused. Whoever takes this should say which they picked and why.

Provenance and what a taker must re-run

⚠️ Measured by the implementer at head 26bc91fc8e7 during #16161's round. Not independently re-driven by the filing seat. Re-run the refusal and read the bytes rather than inheriting the transcription — a double space is exactly the kind of detail that survives a copy badly.

Dedupe

Run with a known-hit control in the same session.

• Query "double space in refusal message is not a valid JS file bundle-require" → total_count: 0.
• ⭐ That zero alone is worthless, so a control sharing its vocabulary was run: "CLI refusal message has a formatting defect extra whitespace in interpolated text" → 6 hits, nearest neighbour [finding] 8 residual #12081-class soft breaks remain in .claude/agents/os-dev.md — each renders as a stray mid-sentence space in the file every dispatched dev reads #12891 (closed) — "8 residual [finding] The #11106 mechanical re-wrap left 45 soft breaks sitting after an ASCII comma between Chinese clauses — each renders as a stray mid-sentence space #12081-class soft breaks ... each renders as a stray mid-sentence space". Same defect class, different population entirely: that card is about soft breaks in .claude/agents/os-dev.md, an authored markdown file, not about a runtime-composed CLI message.

⇒ The area is reachable, and no duplicate is in it.

⭐ A channel property worth recording: a third control, "Failed to load generator message text quality wording", also returned 0 — even though that exact phrase appears in the body of cards the same search surfaces under other phrasings. A zero from one phrasing of this semantic search is not a zero from the area; only a control sharing the failing query's vocabulary settles it. That is why the #12891-reaching control above, and not the bare zero, is what this dedupe rests on.

Grading

⛔ Filed unlabelled. domain:* and type grading are triage's, not this seat's. The implementer's suggestion, relayed as a suggestion only: finding (cosmetic).

Held on #16161 (comment 5559999365) while the dedupe channel was down; filed now that a positive control fires in the same session.