qol-trace-disciplinelisted

# qol trace discipline ## Mandatory question Before implementing, reviewing, or closing any non-trivial qol-tools code change, ask: > is this a potential new qol trace target, or maybe time to enrich this qol trace target with more details? This is not a request to add tracing everywhere. It is a decision point. Record the answer in the work notes, final summary, PR text, or follow-up issue when it affects the delivery. ## When the answer is usually yes - The bug only reproduced through the real app, release build, platform shell, desktop session, daemon, or HTTP/socket route. - The behavior crosses a persistence boundary: config, profile, plugin registry, lockfiles, sync, backups, install markers, autostart, logs, pid files, cache, or temp staging. - The code crosses a process or protocol boundary: tray host, plugin daemon, runtime socket, HTTP API, CLI courier, file manager/browser launch, shell hook, installer, updater. - The feature has ordering, timing, lifecycle, or fallback behavior that unit tests do not show well. - A regression would be expensive to understand from logs alone. - A test can prove final state, but not explain the path taken to get there. ## Trace target guidance Prefer a trace target when the system has a named workflow with multiple observable steps. Good trace targets are: - **Focused**: one user or production workflow, not a whole subsystem. - **Event-shaped**: each line says what happened, with stable identifiers and the reason/decision.