Errors, Sentry-grade and first-party: stock Sentry SDKs → the forge (envelope protocol + OTel), grouping, suspect pull, and the healing loop (error → issue → fix → resolved → regression reopens) #6003

Owner, 2026-10-25: "I heard an ad about Sentry, which I have used in the past and it was amazing… the instrumentation is fantastic and really completes the software self-reinforcing and healing loop. The sentinel bug hunters are another version of this."

Today (probe):

• What exists: the sentinel reads the forge's own error ring (crew/sentinel.ts), page vitals are recorded (migration page-vitals), and Server-Timing phases are named.
• What's missing: there is no error tracking across the forge and its apps. No grouped exceptions with stack traces, release, user and breadcrumbs, and nothing ties an error to the pull that introduced it.

Done when: first-party, Sentry-grade error tracking, on open standards.

• Standard SDKs in. The forge accepts the Sentry envelope protocol at a per-app DSN, so any app (Bun, browser, the arm's Pi in Node) uses the stock open-source Sentry SDKs pointed at the forge. It also takes OpenTelemetry traces. No Sentry account, no SaaS. (GlitchTip, MIT, shows the protocol is implementable; we keep one implementation, in the forge.)
• Every app gets it free. The app template injects the DSN as an env var, and its runtime captures uncaught errors, rejections and failed requests on the server and in the browser, with source maps uploaded at build.
• Grouping: by fingerprint (exception type plus the in-app frames), with counts, first and last seen, users affected, release, and breadcrumbs (the last routes, clicks and logs).
• Suspect pull: each new group names the release it first appeared in, and the landed pulls in that release that touched its frames, linked.
• The healing loop, the point of all this:

1. A new or regressed group above its threshold files one issue (the sentinel's rule: one finding, one issue), with the stack, a repro hint and the suspect pull, routed to the builder who wrote it. 2. The fix pull references the group, and the group is marked resolved in release X. 3. If it comes back after that release, it's a regression: the issue reopens and counts as an escape for the hunters (#5846).

• Privacy: scrub request bodies, cookies and auth headers by default (the defaults never publish personal data). Events are kept 30 days, and only an app's admins see them.
• On home and /flow: errors per release, crash-free sessions, and new and regressed groups (#5735).
• KPIs:

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

Parked by the crew: the check stayed red through 2 automatic tries (pull #6015 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.