Stack Trace

When code dies, it leaves a trail of open doors.

The stack trace is that trail: this function called that function called the one that threw. Each line is a frame — a room the program had not left yet. You read from the top until you see your file. The rest is libraries yelling because you fed them garbage.

You do not need every frame. You need the first path under apps/ or packages/. That is the line you open. That is the line you paste.

Not a distributed trace

A trace follows one request across services and times the hops. A stack trace pulls the other way: the pile of calls inside one process at the instant it crashed. One is a map of travel. One is a snapshot of who was still on the line when it dropped.

The diary vs the last page

A log is the running tape. The stack trace is usually one angry entry on that tape — often a type error or a null you promised wasn't there. Don't screenshot the whole wall and ask "why." Open the first line that lives in your repo.

What you hand an agent

This is the most practical page in debug. An agent that sees "it broke" will hallucinate a cause. An agent that sees the full stack — file, line, message — can patch the bug. Paste the whole thing from the terminal. The CLI already printed it. That is the artifact.

At a hackathon, the crash during the demo is the same artifact. Don't narrate. Copy the frames.

What this unlocks

A stack trace is a map of the last second, not a brick wall. The top line that is yours is the door. Walk through that one.