observabilitylisted

# observability — voidcorp craftsman edition Production debugging starts where observability ended. If you cannot see what happened, you cannot fix it; if you can only guess, you fix the symptom and the bug recurs. This skill codifies what to log, what to trace, what to measure — and just as critically, what NEVER to log (PII, secrets). **Attribution**: see `.source`. Foundation: pino + OpenTelemetry semantic conventions + Charity Majors "Observability Engineering" + Sentry best practices + Sridharan three pillars. --- ## Structured logs only ```typescript // banned console.log('user ' + userId + ' did ' + action); logger.info(`user ${userId} did ${action}`); // allowed logger.info({ userId, action, durationMs }, 'user_action'); ``` Structured logs are queryable. String-interpolated logs are searchable at best. The companion hook `no-console-log-grep` blocks `console.log` / `console.error` / `console.warn` in business code. ### Use `@repo/core/logger` (pino) Provided by `pack-monorepo`. Business code imports `logger`, not pino directly — the adapter pattern lets us swap the backend later without business-code edits. ```typescript import { logger } from '@repo/core/logger'; logger.info({ userId, orderId }, 'checkout_started'); logger.error({ err, orderId }, 'payment_failed'); ``` ### Levels (standard set, no custom levels) | Level | When | |---|---| | `fatal` | Unrecoverable — process must exit | | `error` | Operation failed; user impact | | `warn` | Unexpected b