error-tracking — Sentry wired so it does not leak, and so a stack trace names a commit

Adding Sentry is four lines of SDK setup, which is why it is usually done badly. The four failures below were all observed, on this machine, in one session, by an agent working without this skill.

Observed failure	What it cost
Called "get a DSN" a manual human step needing an account	The account existed and the CLI was already authenticated. Error tracking sat switched off for no reason
Wrote a `before_send` scrubber without knowing `EventScrubber` exists and runs by default	Could not say which layer covered what, so could not say whether the code was redundant or load-bearing
Did not know the MCP is OAuth	Would have declared it in the machine's shared gateway, where an OAuth flow cannot complete
Would have set a DSN and stopped	Every issue lands on a release with no commits; suspect-commit attribution never works

The one that actually leaks

Sentry's built-in scrubber matches KEY NAMES. It does not look inside string values. A credential embedded in a URL — inside a message, an exception value, a breadcrumb — passes through untouched.