A production stack frame names a source file nobody on the team wrote — how do you trace it back?

A stack frame pointing at a file nobody on the team wrote feels like a wall. It is not — it is one indirection, and the work is to invert it in three steps: whose output is this, which input produced this line, and where does the defect actually live. ## Step one: whose output is this? Open the file. A well-behaved generator puts a marker at the top saying the file is derived, which generator emitted it, and what it was derived from. If the header is missing, the directory usually answers it — emitted code should live in a tree that holds nothing hand-written. If neither answers it, that is the first defect to fix, because every future trace pays the same tax. ## Step two: from a line to an input Three things get you from the emitted line back to something a person wrote, in descending order of reliability: 1. **A provenance comment on or near the emitted construct**, naming the declaration or description element it came from. This is the strongest signal and it costs the generator one comment per emitted member. 2. **A naming convention** — an emitted type or member whose name is derived mechanically from the input's name. Reliable until two inputs mangle to the same name. 3. **Re-deriving and reading.** Run the generator over the current inputs, open the emitted file, and read the shape around the reported line. This always works and is the slowest. An emitted line is usually the *symptom* of a decision the generator made much earlier — a branch in the template chosen because some property of the input was or was not present. So the question to carry back is not only "which input" but "which property of that input made the template emit this branch". ## Step three: stepping through it Reading is often enough; stepping is sometimes necessary. Two conditions have to hold, and teams routinely discover them only in an incident: - **The emitted source must be available to the debugger**, at the path the compiled artifact records. If output is deleted after the build, or emitted into a path that no longer exists on the machine doing the debugging, the debugger has line numbers and nothing to show against them. - **The compiled artifact must have kept line information** for the emitted file, and those lines must correspond to the file the debugger is showing — which they do not if the file was re-derived after the artifact was built, from different inputs. Note the phase: the generator ran **during the build**. At run time nothing is generating anything; only the emitted source and the artifact built from it remain. Where a toolchain can map emitted lines back to the template that produced them, that mapping is another build-time product that must be shipped with the artifact to be useful. ## Where the defect actually lives | Where it lives | How it shows | Where the fix goes | |---|---|---| | The input description | Output faithfully encodes something wrong or missing | The declaration or description; the output is only reporting it | | The template or generator | The same wrong shape appears in every emitted file of that kind | The template, then re-derive everything | | The contract the output implements | Emitted code is internally fine but violates what callers assume | The contract, and usually the template that encodes it | | The consumer | Output is correct; the caller passes something it never promised | The caller | The ownership answer that interviewers listen for is that **machine-written output is never the owner**. "The generator produced it, so it is the generator team's bug" is as wrong as "it is in our repository, so it is ours": ownership follows the input or the template, whichever caused it. ## Making the next trace cheap The organisational half matters more than the debugging half. Emit provenance comments unconditionally. Keep emitted source available in the same artifact archive as everything else the build produced. Make the generator's identity and its input revision visible somewhere a responder can read without reconstructing the build. Each of those is minutes of work at emission time and removes the worst part of an incident — the period where the responder does not yet know who wrote the code they are looking at.