What happens
scripts/lib.mjs:269 matches a list item with:
const item = line.match(/^\s{4}-\s*["']?([^"'\n]+?)["']?\s*$/);
The trailing \s*$ requires the line to end right after the item, so a YAML trailing comment makes the line fail to match — and the item is dropped with no warning.
Repro
import { configLists } from './scripts/lib.mjs';
const yaml = `scope:
include:
- "src/**"
exclude:
- "test/**"
- "src/generated/**" # generated, not ours to explain
`;
console.log(configLists(yaml, 'scope'));
Actual:
{ "include": ["src/**"], "exclude": ["test/**"] }
Expected: exclude also contains src/generated/**.
Why it matters
Trailing comments on list items are ordinary YAML, and wiki.config.yml is explicitly a file humans and LLMs are told to annotate — AGENTS.md calls it "the planning surface for the wiki" and says to keep it accurate. Annotating an entry is exactly what you do when an exclusion needs justifying, and that is the one thing that silently breaks it.
The failure is invisible in both directions: the config reads correctly to a human, and the only symptom is wiki-coverage.mjs reporting files that the config plainly excludes. It cost me a real detour today — a generated Prisma client showing as 16 uncovered source files, with a - "src/generated/**" # … line sitting right there in exclude:.
Suggested fix
Strip an unquoted trailing comment before matching, or make the tail tolerant:
const item = line.match(/^\s{4}-\s*(?:"([^"]*)"|'([^']*)'|([^#\n]*?))\s*(?:#.*)?$/);
A # inside quotes must survive (a glob could legitimately contain one), which is why the quoted alternatives come first. The same tail applies to the inline [a, b] form on the line above, and parsePagePlan's summary:/status: matchers have the same shape and probably the same hole.
Worth a unit test either way — this class of bug is silent by construction.
Version
Reproduced at cfe6ce4; also present in the 0.4.7 scripts vendored into a consuming repo.
What happens
scripts/lib.mjs:269matches a list item with:The trailing
\s*$requires the line to end right after the item, so a YAML trailing comment makes the line fail to match — and the item is dropped with no warning.Repro
Actual:
{ "include": ["src/**"], "exclude": ["test/**"] }Expected:
excludealso containssrc/generated/**.Why it matters
Trailing comments on list items are ordinary YAML, and
wiki.config.ymlis explicitly a file humans and LLMs are told to annotate —AGENTS.mdcalls it "the planning surface for the wiki" and says to keep it accurate. Annotating an entry is exactly what you do when an exclusion needs justifying, and that is the one thing that silently breaks it.The failure is invisible in both directions: the config reads correctly to a human, and the only symptom is
wiki-coverage.mjsreporting files that the config plainly excludes. It cost me a real detour today — a generated Prisma client showing as 16 uncovered source files, with a- "src/generated/**" # …line sitting right there inexclude:.Suggested fix
Strip an unquoted trailing comment before matching, or make the tail tolerant:
A
#inside quotes must survive (a glob could legitimately contain one), which is why the quoted alternatives come first. The same tail applies to the inline[a, b]form on the line above, andparsePagePlan'ssummary:/status:matchers have the same shape and probably the same hole.Worth a unit test either way — this class of bug is silent by construction.
Version
Reproduced at
cfe6ce4; also present in the0.4.7scripts vendored into a consuming repo.