Smarter filtering for non-package dependency claims

[theDakshJaitly]

Problem

The claim extractor (src/drift/claims.ts) treats every **bold** word in stack/tech sections as a dependency claim. This produces false positives for things that are clearly not package names: multi-word phrases ("REST API"), all-caps acronyms ("AWS"), descriptive labels ("Frontend", "Backend", "Database Layer").

Where to look

• src/drift/claims.ts — the strong node visitor (~line 105)
• src/drift/checkers/dependency.ts — where claims are checked

What to do

Add heuristics to filter out claims that aren't real package names before they reach the dependency checker. Ideas:

• Skip multi-word phrases that don't look like scoped packages
• Skip all-caps words (likely acronyms, not packages)
• Skip common architectural/descriptive terms

This is complementary to expanding KNOWN_RUNTIMES — that's a blocklist approach, this is pattern-based filtering.

Acceptance criteria

• Fewer false positive DEPENDENCY_MISSING warnings on real-world READMEs
• Real package names still get checked correctly
• Add test cases

[teneko]

Is it maybe worth it to consider to shift to structured output instead of relying on extracting business facts out of semantic intended stack/sections of markdown? (I hope I got it right to assume, that the stack/sections are part of a markdown file)

[theDakshJaitly]

Hey, thanks for the suggestion! We thought about structured output but it goes against what mex is trying to do. The whole point is that it works with your existing README without any extra setup or config files. Asking users to maintain a separate structured file adds friction we want to avoid.

The better path here is just making the heuristics smarter so we filter out the obvious non-package names (acronyms, multi-word phrases, generic labels) while still catching real dependencies. That way it stays zero-config.