feat(log): split -vv output into trace.log + output.log, drop -vvv

[max-sixty]

Motivation

At -vv, raw subprocess bodies were bounded (200 lines / 64 KB) on both stderr and verbose.log, with full output only available by rerunning at -vvv. Large captures (notably git log -p piped into patch-id during wt list) would routinely flood stderr with elision markers and force a second run just to see what was elided.

Change

The verbosity map is now -v (info) and -vv (debug); any -v count above 2 collapses to -vv. Captured subprocess stdout/stderr fan out through two log targets in src/shell_exec.rs:

• SUBPROCESS_TERMINAL_TARGET → bounded preview on stderr, mirrored to .git/wt/logs/trace.log (new, replaces verbose.log)
• SUBPROCESS_FULL_TARGET → uncapped body to .git/wt/logs/output.log (new), never stderr

src/log_files.rs (renamed from src/verbose_log.rs) owns both file sinks behind a LogSink type and a route(target) helper that is the single source of truth for sink selection. src/main.rs's env_logger format closure matches on the Route enum and emits once per sink. Diagnostic reports embed trace.log and reference output.log by path — multi-MB raw bodies would swamp a bug report.

Fallback path

When RUST_LOG=debug is set without -vv, neither sink is active. FULL records drop and the TERMINAL preview reaches stderr as before — preserving the bounded-stderr guarantee. The elision marker phrases its hint based on whether output.log was opened, so users in the fallback path see rerun with -vv for full output rather than a pointer to a file that doesn't exist.

Key files

• src/log_files.rs — new module; LogSink, TRACE, OUTPUT, route.
• src/shell_exec.rs — two pub const targets, log_output emits on both, elision hint switches on OUTPUT_LOG_AVAILABLE.
• src/main.rs — verbosity map + format closure.
• src/diagnostic.rs — template splits inlined trace.log from referenced output.log.
• src/commands/config/state.rs — diagnostic file recognition for the new names.

Testing

• test_vv_splits_full_and_bounded_output — [wt-trace] in trace.log, raw stdout in output.log, no trace records in output.log.
• test_vv_bounded_on_stderr_full_in_output_log — 250-ref packed-refs trip the elision cap; asserts the marker on stderr + trace.log, full content in output.log without elision.
• test_rust_log_debug_fallback_without_vv — no log files created at -v 0 + RUST_LOG=debug; bounded preview reaches stderr.

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

A couple of stale verbose.log references were missed by the rename. Both fall outside the diff hunks, so I can't post them as inline suggestions — happy to push a fix commit if you'd like.

docs/content/faq.md line 120 — the "files Worktrunk creates" table still lists verbose.log as the -vv output. Suggested:

| `.git/wt/logs/trace.log` | Debug log mirroring stderr (commands, `[wt-trace]` records, bounded subprocess previews) | Running with `-vv` |
| `.git/wt/logs/output.log` | Raw uncapped subprocess stdout/stderr bodies | Running with `-vv` |

skills/worktrunk/reference/faq.md:113 is the auto-synced mirror — test_command_pages_and_skill_files_are_in_sync will regenerate it once the source is updated.

tests/integration_tests/diagnostic.rs lines 535–557 — test_v_does_not_write_log_files still asserts on wt_logs.join("verbose.log"). The test passes because that file is never created, but it isn't actually guarding the new paths. Suggested:

/// `-vv` is the threshold for `trace.log`, `output.log`, and `diagnostic.md`.
#[rstest]
fn test_v_does_not_write_log_files(repo: TestRepo) {
    let output = repo.wt_command().args(["list", "-v"]).output().unwrap();
    assert!(output.status.success(), "Command should succeed");

    let wt_logs = repo.root_path().join(".git").join("wt/logs");
    assert!(
        !wt_logs.join("diagnostic.md").exists(),
        "Diagnostic file should NOT be created with just -v"
    );
    for name in ["trace.log", "output.log"] {
        assert!(
            !wt_logs.join(name).exists(),
            "{name} should NOT be created with just -v (requires -vv)"
        );
    }
}

The split itself reads cleanly — log_files::route keeps sink selection in one place, the OUTPUT_LOG_AVAILABLE gate keeps the elision marker honest, and the new tests (test_vv_splits_full_and_bounded_output, test_vv_bounded_on_stderr_full_in_output_log, test_rust_log_debug_fallback_without_vv) cover the three interesting routing cases.

[worktrunk-bot]

CI failed on Windows: test_diagnostic_report_file_format snapshot diff at the new Raw subprocess output section.

60 │ <details>
61 │ <summary>Raw subprocess output</summary>
62 │
63 │-Full captured stdout/stderr is in `_REPO_/.git/wt/logs/output.log` — not inlined because it can be multi-MB.
63 │+Full captured stdout/stderr is in `[REPO_PATH] — not inlined because it can be multi-MB.
64 │ </details>

Cause: in src/diagnostic.rs the new output_log_path is rendered with the OS-native separator (\ on Windows). normalize_report's generic Windows-path regex [A-Z]:[^\s)]+ then greedily eats through the closing backtick and rewrites the whole thing to [REPO_PATH], while the snapshot expects the existing _REPO_/... style for known wt-logs paths.

Per CLAUDE.md ("Path normalization | path_slash::PathExt::to_slash_lossy()"), the cleanest fix is on the production side — render the bug-report path with forward slashes so it's also readable when a Windows user pastes it into an issue:

use path_slash::PathExt as _;

let output_log_path = crate::log_files::OUTPUT
    .path()
    .map(|p| p.to_slash_lossy().into_owned());

That alone makes the snapshot pass on all three platforms; no test change required. (Linux/macOS are already at /, so behavior is unchanged there.)

Happy to push the one-liner if you'd like.

CI failed on Windows — the regex tightening didn't fix the snapshot diff (analysis follows).

[worktrunk-bot]

The Windows snapshot diff isn't actually fixed — test_diagnostic_report_file_format failed again on the Windows runner with the same shape as before:

-Full captured stdout/stderr is in `_REPO_/.git/wt/logs/output.log` — not inlined because it can be multi-MB.
+Full captured stdout/stderr is in `[REPO_PATH]` — not inlined because it can be multi-MB.

The backtick exclusion in the regex closes one hole (the closing backtick is no longer eaten) but doesn't address the underlying mismatch. Walking through what happens on Windows:

1. Production renders the path with backslashes: D:\a\worktrunk\worktrunk\.tmpXXX\repo\.git\wt\logs\output.log.
2. normalize_report runs first and the [A-Z]:[^\s)+`]+branch greedily matches the whole path →[REPO_PATH]`.
3. The insta _REPO_ filter (tests/common/mod.rs:597) then has nothing left to substitute, so the snapshot ends with [REPO_PATH] instead of _REPO_/.git/wt/logs/output.log.

The Unix branch happens to escape this because it requires /repo\. (a literal repo. segment), so the main repo path …/repo/.git/... doesn't match and the insta filter gets first crack at it. The Windows branch has no such anchor.

Two fixes that would actually work:

(a) Render with forward slashes in production (my earlier suggestion, and what CLAUDE.md calls out for path-display normalization):

use path_slash::PathExt as _;

let output_log_path = crate::log_files::OUTPUT
    .path()
    .map(|p| p.to_slash_lossy().into_owned());

at src/diagnostic.rs:166-168. The path becomes D:/a/.../repo/.git/wt/logs/output.log, which matches neither branch of the normalize_report regex (no repo. segment), so the insta _REPO_ filter substitutes it cleanly and the snapshot matches as on Linux/macOS. Bonus: Windows users pasting the path into a bug report get the readable forward-slash form.

(b) Anchor the Windows regex the same way the Unix one is anchored — only match when the path actually contains a repo.<something> segment:

result = regex::Regex::new(r"([A-Z]:[^\s)`]+\\repo\.[^\s)`]+|/[^\s)`]+/repo\.[^\s)`]+)")

(a) is cleaner — it fixes the production-side oddity that motivated the test failure in the first place, rather than just teaching the test to look the other way.

Happy to push (a) if you'd like.