An error page that tells you the exact line, not a guess

A stack trace through compiled or transpiled code is a familiar kind of unhelpful: the line number is real, but it points at generated output nobody wrote by hand, several steps removed from the source you actually need to look at. Phlo's error pages point at the source instead, because the parser makes that possible by construction.

Why this works at all

The line-based parser (no AST, covered in an earlier post) means line N in a .phlo file maps directly to a known line in the generated PHP. That is not a debugging feature bolted on afterward, it falls directly out of how the compiler works: because there is no complex tokenization step reshuffling structure, the mapping from source line to output line stays simple enough to record and use.

What you actually see

A production error shows a short, quotable 8-character reference id, both on the error page a user sees and in the JSON or async payload a frontend call gets back. The same id is logged to data/errors.json with the real detail: which .phlo file, which line, what the exception was. A user reports the id, a developer greps for it, and the exact failure is right there, no reconstructing "which request, roughly when, probably in that one area" from a vague description.

static errorPage($code, $id, $msg = null) => DOM('<main class="oops"><h1>Something broke.</h1><p>Reference: '.$id.'</p></main>')

The error pipeline is recursion-guarded, too: if the renderer itself or a custom errorPage throws, it falls back to a dependency-free bare page instead of looping into a second failure on top of the first.

Deeper, when you need it

For cases the reference id alone does not explain, trace mode (trace: true in the dev entrypoint) gives request-level tracing: every call to a generated method, prop getter or native helper gets logged with timing and arguments to data/trace/<id>.json, readable from the Phlo Control Center's Trace tab. That is the escalation path, most of the time the file, the line and the reference id are enough to go straight to the fix; trace is there for when the failure is about sequence and timing rather than a single broken line.

The common thread

This is the same design choice that shows up everywhere else on this site: fewer layers between the thing that broke and the person trying to fix it, whether that person is a developer at a terminal or an agent reading the same error programmatically.