Context
Two structured-logging key conventions coexist in this codebase: ev: and event:. Promtail's log pipeline (promtail/promtail-config.yml:59-77) and the Sentry console-forwarder (src/selfhost/sentry.ts:544-601) both only extract/key off a field literally named event. An audit (2026-07-07) found roughly 60 call sites across src/review/*.ts, src/queue/processors.ts, src/db/repositories.ts, and src/services/*.ts using the wrong key — including some on genuine error paths (processors.ts:9828 visual_capture_error, :9867 review_memory_error) and the brand-new linked_issue_label_propagation_filtered line (src/review/linked-issue-label-propagation-fetch.ts:75-83) that was specifically added to make label decisions diagnosable, but is invisible to Loki/Sentry because of this exact bug.
This is a confirmed, mechanical root cause behind "when problems happen, they're a nightmare to debug" — the signals mostly already exist, they just aren't reaching any indexed surface.
Requirements
- Rename every
ev: structured-log key to event: across the ~60 identified call sites (confirmed to be a pure rename — nothing currently reads ev as a query key, so there is no reader-side compatibility concern).
- Add a lint rule or a small custom check script (mirroring the existing
scripts/validate-observability-configs.mjs precedent) that fails CI if a new console.log/console.error/console.warn call uses an ev: key instead of event:, so this can't silently recur.
- Spot-check that lines missing a
level field (e.g. processors.ts:9828, :9867) also get one added where the call is genuinely an error path, so Sentry's level-based forwarding actually fires for them.
Deliverables
- One PR (or a small number of PRs if the diff is large enough to warrant splitting by directory) renaming all ~60 sites.
- A new lint/check step wired into
npm run test:ci (or an existing relevant check) preventing recurrence.
Expected outcome
Every structured log line in the codebase is queryable via Loki's event= label and eligible for Sentry forwarding when it carries level: "error". No behavior change to the application logic itself — purely a logging-key rename plus one new CI guard.
Context
Two structured-logging key conventions coexist in this codebase:
ev:andevent:. Promtail's log pipeline (promtail/promtail-config.yml:59-77) and the Sentry console-forwarder (src/selfhost/sentry.ts:544-601) both only extract/key off a field literally namedevent. An audit (2026-07-07) found roughly 60 call sites acrosssrc/review/*.ts,src/queue/processors.ts,src/db/repositories.ts, andsrc/services/*.tsusing the wrong key — including some on genuine error paths (processors.ts:9828visual_capture_error,:9867review_memory_error) and the brand-newlinked_issue_label_propagation_filteredline (src/review/linked-issue-label-propagation-fetch.ts:75-83) that was specifically added to make label decisions diagnosable, but is invisible to Loki/Sentry because of this exact bug.This is a confirmed, mechanical root cause behind "when problems happen, they're a nightmare to debug" — the signals mostly already exist, they just aren't reaching any indexed surface.
Requirements
ev:structured-log key toevent:across the ~60 identified call sites (confirmed to be a pure rename — nothing currently readsevas a query key, so there is no reader-side compatibility concern).scripts/validate-observability-configs.mjsprecedent) that fails CI if a newconsole.log/console.error/console.warncall uses anev:key instead ofevent:, so this can't silently recur.levelfield (e.g.processors.ts:9828,:9867) also get one added where the call is genuinely an error path, so Sentry's level-based forwarding actually fires for them.Deliverables
npm run test:ci(or an existing relevant check) preventing recurrence.Expected outcome
Every structured log line in the codebase is queryable via Loki's
event=label and eligible for Sentry forwarding when it carrieslevel: "error". No behavior change to the application logic itself — purely a logging-key rename plus one new CI guard.