add-observability

To add structured logging to integration boundaries, enumerate outbound and inbound sites like HTTP routes, webhook handlers, spawned processes, and MCP tool calls, replacing silent catches with leveled, typed log events that preserve existing swallow semantics.

Boundary instrumentation for production observability is the practice of adding leveled, structured logging to control and data transfer points where modules interact via HTTP, IPC, queues, or file writes, ensuring failures emit greppable evidence for debugging.

You add observability without breaking error swallowing semantics by applying guarded instrumentation that logs the caught error at the boundary while strictly preserving the original catch behavior of the silent failure block.

The observability approach works with your existing project logger by discovering and conforming to its API, or it offers a zero-dependency console-based fallback, using pino optionally only if explicitly approved.

You verify structured logging actually emits at runtime by confirming the instrumented paths and stable event names exist, then triggering the boundary to ensure at least one path produces the expected event logs before completing the task.

You need to instrument boundaries for spawned processes and env injection when control or data leaves the module silently, preventing future debugging speculation by ensuring failures in child process execution or environment variable injection produce structured log evidence.