map: standing adversarial corpus category (+ fix a wrong pin it found)

[patchstackdave]

Stacked on #129. Merge that first; this branch carries its commit until then.

Twice now a false-candidate class has reached review instead of being caught by the corpus, and both times for the same reason: the corpus contained the shapes I thought of. Every such class so far came from code that merely resembled a dangerous API — so lookalikes have to be in the corpus on purpose, as a category rather than as one-off regressions.

New kind: 'adversarial' cases, app code constructed to look dangerous:

class	shape
name collisions	import * as helper from './util' + named { fetch, exec } from app code
inferred packages	res.locals.db.query(...) in a file importing pg / supabase
shadowed globals	const send = (fetch) => fetch(req.body.url)
namespace collision	params.id and query.id in one handler
sibling contamination	one real pairing among adjacent sinks + an unused input

It found a wrong pin immediately

Inputs are keyed by field name, and two namespaces can share one:

app.get('/qp/:id', ({ params: p, query: q }, res) => {
  fs.readFileSync(p.id);   // arrives in the path segment
  fs.readFileSync(q.id);   // arrives in the query string
});

Last-write-wins picked whichever read the walker saw last, and that pick decided the coordinate — so this handler compiled path-traversal @ get.id for data arriving in the path. A rule pinned there inspects the wrong place: it never fires on the real payload, while looking like coverage. Reversing the two lines flipped the verdict, which is the tell that no verdict was earned:

query-first → input id = route-param → null      (safe, by luck)
param-first → input id = query       → get.id    → 2 candidates   ← wrong pin

Collisions are now recorded during collection (first-seen source wins, so the record is deterministic) and such an input gets no coordinate, with a reason naming both namespaces. Both orders now refuse identically. This costs the legitimate get.id candidate — a wrong pin costs trust in every candidate, so that trade is not close.

Two properties keep the category honest

• Non-vacuity: each adversarial case must detect a real surface (endpoints + inputs) before its zero-candidate assertion counts. Otherwise a parser bug or a typo'd fixture would read as a security property — the most dangerous way for a test like this to pass.
• No quiet erosion: the five classes are asserted by name, so deleting one fails loudly.

Verification

I confirmed the new fixture fails without the fix (unexpected candidate(s): path-traversal @ get.id), so it is not decorative. Corpus now reports 6 stack + 5 adversarial projects · 9 candidates · 13 refused-with-reason. 881 tests, typecheck clean.

[coderbuds]

Robust input-mapping overhaul with detailed namespace handling and tests

🎯 Quality: 94% Elite · 📦 Size: Large — consider splitting if possible

🛡️ Standards: no pre-flight fit check ran for this change — wire assess-change-fit into your coding agents to catch size before opening.

📈 This month: Your 61st PR — above team average · Averaging Excellent

_{See how your team is trending →}

[patchstackdave]

Confirmed and fixed — same class, one layer up, and the report's diagnosis was exactly right.

Reproduced:

-- /x   z.object({ id }).parse(req.body)  +  fs.readFileSync(req.query.id)
   input id source=json-body -> post.id
   flow  id precise GEN=true path-traversal        <-- pinned to post.id, payload arrives in get.id

Schema fields are inserted first and same-named reads are then skipped, so post.id was the only surviving input while flow analysis was looking at req.query.id.

Both origins now go through one collision pass, and the comparison is by effective namespace rather than source label — that distinction is the substance of the fix, not a detail:

• json-body, form-body, and an Express req.body read are different labels for the same place (post.*) → not a conflict
• post.id vs get.id are the same label shape for different places → conflict

namespaceOf derives that from runtimeCoordinate, so the conflict test can't drift from the addressing rules it polices. Folding the read-vs-read case into the same pass means one mechanism now covers both, and requestMemberAccesses just reports every source it saw per name.

After:

/mismatch  id  -> null | field is read from more than one request namespace (json-body, query)
/agree     doc -> post.doc  → path-traversal candidate   (unchanged)

The corpus case keeps that /agree control deliberately: the goal is to refuse conflicts, not to refuse validated bodies.

Verified both adversarial cases fail with the comparison disabled (5 failures), so neither is decorative. Corpus now 6 stack + 6 adversarial projects · 10 candidates · 14 refused-with-reason. 884 tests, typecheck clean.

Agreed on the longer-term point, and I'd put it more strongly: input identity should be (runtime namespace, full path) — name-keyed grouping is the shared root cause of this and the params.id/query.id case, so both fixes are refusals compensating for a lossy key. I'd rather make identity namespace-qualified than keep adding conflict detection on top of it, and that belongs with the confidence-taxonomy work where Flow.input can change shape at the same time.

[patchstackdave]

/review