When it breaks in production at 3am, what does on-call see?

1 · The generated TypeScript is yours to read

Glyph doesn't ship an opaque runtime. It emits ordinary, formatted TypeScript that you commit and deploy like any other TS. So the worst case — an on-call engineer who doesn't know Glyph, at 3am — is still reading plain TypeScript, not a dialect. There's no black box between your source and production.

2 · Source maps back to .glyph

Every emitted .ts ships a standard v3 source map (.ts.map) next to it, with a sourceMappingURL comment and your Glyph source embedded (sourcesContent). Anything that consumes source maps — Chrome DevTools, a Node debugger, an error tracker like Sentry, your bundler — can chain through it and show you the .glyph line, not the generated one.

// ...emitted TypeScript...
//# sourceMappingURL=main.ts.map    // v3 map, .glyph embedded

3 · Build and type errors already point at Glyph

You rarely get to production with a type error, because glyph build runs tsc --strict and maps every tsc error back onto your .glyph source — same caret, the TypeScript error code preserved, pointing at the line you wrote, not the generated .ts. And glyph build --json emits every diagnostic as structured JSON (code, severity, file, 1-based line/col, help) for your CI or tooling to act on.

The honest edge

glyph run's own crash stack still shows .ts line numbers. glyph run executes via tsx, and tsx doesn't chain the source map through its own .ts→.js transform — so an uncaught throw during glyph run reports the generated line. Remapping that stack is a follow-up. It matters for the local run loop; in a real deployment you glyph build to .ts, bundle it with your normal toolchain, and the .ts.map chains as usual — so the production stack you actually page on maps back to .glyph.