**TL;DR:** The parser is resolving frames against the wrong source map - usually a stale one from an earlier build or a local-dev map applied to a deployed bundle. Prove the mismatch on one frame, then bind the parser to the map generated from the exact deployed bundle (match by build hash), and rebuild with minification off if the mapping stays unreliable. Refuse any map whose hash doesn't match the bundle being resolved.

```text
agent's stack-trace parser failed on workerd source maps: wrong file mapped
```

## Steps

1. Prove the mismatch: take one stack frame, resolve it, and check whether the mapped file and line actually contain that code. Expected: confirmed wrong - the mapped location doesn't match the failing code.
2. Check provenance: compare the source map's build hash and timestamp against the deployed bundle's. Expected: they match. A stale map from an earlier build is the most common cause.
3. Make sure the parser uses the deployed bundle's map, never a local-dev map. Expected: local-vs-deployed confusion disappears; frames resolve against what actually ran.
4. If the bundle is minified and mapping stays unreliable, rebuild with minification off for the debugged deploy. Expected: frames map cleanly without heroic parsing.
5. Spot-check 2-3 known frames and verify each lands on real code. Expected: all correct. The parser is trusted again.
6. Add the guard: the deploy pipeline stores the bundle hash alongside its source map, and the parser refuses a map whose hash doesn't match the bundle it's resolving. Expected: stale-map mismatches become loud errors instead of silent misattribution.

## Use this when
- workerd stack frames resolve to the wrong file or line
- the mapped location doesn't contain the failing code
- an agent's error attribution keeps pointing at innocent files
- "wrong file mapped" after source-map resolution

## Not for this skill when
- there are no source maps at all - generate and ship them first
- the traces are minified by choice with no maps - unmapped frames are expected
- it's Node.js-style stack parsing - different format, different parser
- the mapping is right but the code is confusing - that's a code problem

## Variant phrasings
- workerd stack trace points at the wrong source file
- source map mismatch on cloudflare workers
- parser mapped the error to an incorrect file
- stack frames resolve to the wrong lines

## Why it happens
workerd reports positions in the deployed bundle, but the source map is a separate artifact that drifts: rebuilt bundles, local vs deployed environments, and minification all change the mapping. A parser that grabs whichever map is handy silently misattributes every frame, and the agent then "fixes" innocent code.

## Edge cases
- Multiple entry points produce multiple maps. Match each frame to its chunk's map.
- Deploys sometimes strip the sourceMappingURL comment. Keep maps in the pipeline, not just in the bundle.
- Eval'd or injected code has no mapping. Expect some frames to stay unresolved and handle that explicitly.
- Minified production with maps is fine; minified production without maps is a choice - document it so nobody files it as a parser bug.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2vP2JJ9vPO6mj8672RMXRg