Closes #155. Follow-up to PR 145 (topology-driven log generation), mirroring the metric override pattern from OverrideConfig.Metrics.

What

Scenarios can now modify log output during their activation window via a logs: block under override:

scenarios:
  - name: db-degradation
    at: 2m
    duration: 5m
    override:
      postgres.query:
        error_rate: 15%
        logs:
          add:
            - severity: ERROR
              body: "connection pool exhausted"
              condition: error
              attributes:
                error.type:
                  value: PoolExhaustedError
          disable: true   # optional: mute base logs at this scope

• add: defines extra log records emitted only while the scenario window is active. Entries are full LogConfig definitions: severity, body templates, conditions (error/success/slow), probability, timing anchors (at/delay), and attribute generators all work.
• disable: true mutes the base logs at the override's scope for the duration of the window — both topology log templates and the derived error/slow fallback logs. Combined with add:, this gives replacement semantics.
• Both override scopes work, consistent with metric overrides: service.operation refs scope to one operation; bare service names scope to every span of the service.

Design decisions (per the issue's open questions)

1. Identity for modifying existing definitions: deferred, as suggested. This first iteration supports add: and disable: true only; no name/id field was added to LogConfig. Log-storm simulation is achievable today with disable: true plus an add: entry that copies the base log with a higher probability.
2. Derived-vs-topology switching: adding logs to a service that previously had none switches it to topology logs for the window (suppressing the derived error/slow fallback), and disable mutes the derived logs too — so the suppression rule is now scenario-aware.

Implementation

• LogOverrideConfig (add, disable) on OverrideConfig, validated at config load with the usual contextual messages (each add entry goes through validateLogConfig; an empty logs: block is rejected).
• BuildScenarios resolves added entries to LogDefinitions via the existing resolveLogs (its error-context parameter was generalised to support scenario contexts).
• ResolveOverrides merges across overlapping scenarios: adds accumulate in priority order, disable from any active scenario wins.
• LogObserver implements the existing OverrideObserver interface; the engine's notifyOverrides path needed no changes. Added definitions are pre-built into templates on scenario transitions so the per-span path only does map lookups under an RWMutex, matching MetricObserver.

Testing

• Unit tests for validation, scenario building/merging, and observer behaviour (operation/service scoping, conditions, interpolation, disable semantics, derived-log interaction, override clearing).
• Verified end-to-end with the updated docs/examples/topology-driven-logs.yaml: the added ERROR log appears only inside the window on error spans, the gateway's base logs go quiet during it, and behaviour reverts when the window closes.
• make test and make lint pass.

https://claude.ai/code/session_01L12XgTDZiZMBQU6cMoFLpC

Generated by Claude Code