logging Shipped
What this lens looks for
Every component and flow is instrumented with structured logging using the platform's best-in-class framework — os.log via Logger from os on Apple, Timber (or android.util.Log) on Android, console with structured prefixes or pino/winston in Node on web, the logging module with module-level loggers on Python, ILogger<T> from Microsoft.Extensions.Logging on Windows/.NET — and never raw print/NSLog/bare console.log in place of the framework; flow instrumentation uses debug level, and state transitions, user interactions, async task start/completion/failure, and branching logic are all logged; on Apple the os.log subsystem matches the bundle ID and the category is one per component or flow; on C# logging uses structured message templates (logger.LogInformation("Processing {OrderId}", orderId)) and never string interpolation ($"..."), which bypasses structured logging and breaks aggregation, with the [LoggerMessage] source generator for hot paths and per-category levels configured in appsettings.json; on Kotlin a consistent tag scheme is used when falling back to android.util.Log; on Windows additionally use ETW (EventSource) for system-level diagnostics and startup timing; logs should be emitted through OpenTelemetry and exported over OTLP so logs, traces, and metrics share one pipeline rather than per-platform-only frameworks (which remain the local emission layer, routed through an OTel appender/bridge rather than replaced); every log line should carry the active trace ID and span ID so a log can be pivoted to its trace; field names should follow OpenTelemetry semantic conventions (service.name, trace_id, http.request.method) rather than ad-hoc keys; production logs should be structured JSON, not free-form text; and personally identifiable information must never be logged at any level, including debug and trace-correlated logs.
What its verifier checks
Every component and flow has a logger from the platform's best-in-class framework (os.log/Logger, Timber/android.util.Log, console/pino/winston, Python logging, ILogger<T>) — no raw print/NSLog/bare console.log substitutes; flow instrumentation is emitted at debug level; state transitions, user interactions, async task start/completion/failure, and branching logic are logged; Apple os.log uses a subsystem matching the bundle ID and one category per component or flow; C# log calls use structured message templates and contain no string interpolation, with [LoggerMessage] on hot paths and per-category levels in appsettings.json; Kotlin android.util.Log fallback uses consistent tags; Windows uses ETW/EventSource for system-level diagnostics and startup timing; logs are emitted through OpenTelemetry over OTLP rather than per-platform-only pipelines; each log line carries the active trace and span ID; field names follow OpenTelemetry semantic conventions rather than ad-hoc keys; production logs are structured JSON; and no personally identifiable information appears in log output at any level, including debug and trace-correlated logs.