Phase B.8 audit of commits 65abfa2 (Obs-3, span propagation across
spawn boundaries), 8becb1a (audit-trail empty commit for Obs-4/5
absorbed into afbd33d), and d1391b3 (Obs-1/2, drop lumotia_live literal
target). Existing coverage:
* commands::live::tests::no_lumotia_live_literal_target_in_live_rs
pins Obs-1/2 — no literal lumotia_live target survives.
* src-tauri/tests/tracing_appender_smoke.rs::init_tracing_creates_log_file
pins Obs-4/5 — install_subscriber writes to a rolling lumotia.log.
* Obs-3 (span propagation) is not directly tested. Verifying that
`tokio::spawn` / `thread::spawn` children carry the parent span would
require custom subscriber infrastructure; the commit message
acknowledges the 4 instrumented sites as canonical correlation
points + "everything else fans out from them" + "Storage/audio/
hotkey/MCP crates left uninstrumented in this commit — future
sweep". Honour the SAFETY-style annotation; do not chase a synthetic
subscriber test.
One real residual found.
DEFAULT_STDERR_FILTER and DEFAULT_FILE_FILTER in src-tauri/src/lib.rs
both list `lumotia_storage=info` (stderr) / `lumotia_storage=debug`
(file). Operator intent: storage events surface in stderr AND in the
rolling lumotia.log forensic stream that diagnostic-report bundles
attach. The reality: every storage event vanishes.
The storage crate uses `log` crate macros (log::warn! / log::info!),
not tracing. src-tauri/src/lib.rs installs a tracing subscriber but
does NOT install a `tracing-log::LogTracer` bridge, so log-crate events
never reach any tracing layer. There is no other log subscriber wired
either, so the events are silently dropped.
Concrete signals missing from diagnostic reports:
* Migration progress (info, lines 603 + 639 in migrations.rs) —
fires on every schema bump on every first-run after upgrade. Used
to confirm "did the user's migration succeed?".
* Audio-cleanup warnings (warn) from delete_transcript (database.rs
line 369) and purge_deleted_transcripts (line 434) — the two
log lines Rev-3 specifically added so a forensic report could
confirm whether disk cleanup completed cleanly.
Same forensic blindness Obs-4/5 fixed for the rest of the codebase,
just for the storage subset.
Fix:
* crates/storage/Cargo.toml: replace `log = "0.4"` with
`tracing = "0.1"`. Every other crate in the workspace already uses
`tracing = "0.1"`; storage was the outlier.
* Replace the 4 `log::*!(target: "lumotia_storage", …)` calls with
`tracing::*!(target: "lumotia_storage", …)`. Targets unchanged.
* Reformat the two migration log lines as structured tracing events
(version + description fields rather than printf-style positional
interpolation) so they're filterable by EnvFilter directives and
machine-readable in the forensic stream.
No behaviour change to storage call semantics. Pure logging-pipeline
rewire.
Verification:
* cargo test -p lumotia-storage --lib
→ 70/70 pass (unchanged — none of the tests depended on the log
crate).
* cargo fmt --check → clean.
* cargo clippy --workspace --all-targets -- -D warnings → clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Jake
813f024cdb