observability: the structured logger exists but nothing uses it (237 console.* calls, 0 importers)

Corrected 2026-08-17. This issue originally said no structured logging existed and one should be built. That was wrong — I checked for pino/winston/bunyan dependencies, found none, and concluded there was no logger. There is one.

What actually exists

packages/outpost/shared/src/monitoring/logger.ts — a structured JSON logger shipped in PR #21 (Phase 4D, "Deploy + Monitoring"). One JSON object per line, with timestamp, level, service, message, plus metadata. Five levels, level filtering, an injectable writer for tests. It has its own test file.

It is exported from packages/outpost/shared/src/monitoring/index.ts.

The actual problem

Nothing imports it. Zero call sites outside the module and its own tests. Meanwhile there are 237 console.* calls in non-test source across apps/ and packages/.

So the work is not "build a logger" — it is "adopt the logger that was built." That is a much smaller and much better-defined task, and it is the reason production logs are still unstructured despite Phase 4D being marked complete.

Related: AlertManager has the same shape

packages/outpost/shared/src/monitoring/alerts.ts exports AlertManager and createAlertManager. Referenced only by its own module, the barrel export, and its test file — never instantiated anywhere in a running service. Noted as dead code in the Build Plan's own confidence-design section ("it's dead code today, never instantiated outside its own test file"). Tracked alongside the Sentry stub in #196.

Fix

1. Bind a logger per service at each entry point (apps/worker, the three bots, apps/github-app, apps/web).
2. Replace console.* incrementally, starting with the worker and the job handlers, where the structure actually buys correlation — jobId, ticketId, job type.
3. Decide whether AlertManager gets wired to a real sink or deleted. A monitoring module that no service uses is worse than none, because it reads as covered.

The general lesson worth recording: Phase 4D shipped the capability and never the adoption, and every status doc since has counted it as done.

Start with packages/outpost/shared/src/monitoring/logger.ts, its test file, and the export in monitoring/index.ts to understand the existing capability. Then inspect the entry points under apps/worker, the three bots, apps/github-app, and apps/web, beginning with the worker job handlers. Done means relevant console.* calls are adopted incrementally with service and job metadata, and AlertManager's wiring or removal is decided.