docs(specs): harden S03 logging spec against LabKit v2 behavior

What

Hardens the S03 logging spec by validating every claim for logging package + config conversion + handler chain built on labkit/v2 v2.13.0 and correcting the spec where it proved wrong or underspecified.

Why

The prior text rested on LabKit behavior that does not exist in v2.13.0 (a ContextHandler/logFields auto-stamping mechanism) and on a config-defaulting flow that labkit/v2/config's Loader.Load cannot support (protovalidate runs atomically inside the load, so a pre-validation defaulter is impossible).

Key corrections

  • Config: level/format move from proto enums (which fail buf-lint ENUM_VALUE_PREFIX and force LEVEL_/FORMAT_ YAML) to string + in: fields with Go-side defaults, matching the existing database.sslmode precedent. success_fraction keeps EXPLICIT presence so unset (default 1.0) is distinguishable from explicit 0.0.
  • Handler chain: no LabKit ContextHandler exists. The service owns the chain (sampler → context-field → base), maps LogConfig into app.Config.Log, and wraps a.Logger().Handler() so version/commit/ build-date survive. The enriched logger is installed as the request-context logger (log.WithLogger).
  • Sampler reads status (fields.HTTPStatusCode), not status_code (a deprecated alias in fields.Deprecated).
  • Wide events: success/error field renamed statusoutcome to avoid the int/string type collision with the canonical HTTP status. Clarified that wide events are INFO and subject to the log.level threshold.
  • Dropped the wide-event CI validator (former AC6) and all validator references: the typed-emitter pattern, the catalog, and code review are the enforcement. A bespoke source-scanning tool is disproportionate for the logging phase and has no tooling precedent in this repo.
Edited by Suleimi Ahmed

Merge request reports

Loading
Loading