feat(tui): add Projects tab with per-project token breakdown

[CubityFirst]

Summary

Adds a new Projects tab so you can see token & cost usage per project, and drill into any project for its day-by-day, per-model breakdown.

Tab order is now: Overview · Stats · Models · Projects · Audit (number keys 1–5).

• Projects tab — a selectable list of projects sorted by cost, each with tokens / cost / a usage bar. Labels are shown as parent/folder (e.g. Scripts/toktrack).
• Drill-down — Enter on a project opens its daily/weekly/monthly view (reusing the existing source-detail view); Enter on a day opens the existing per-model breakdown popup. Esc returns to the Projects tab.

Which CLIs are covered

Per-project attribution needs a working directory in the session data. Each below was verified against live local data:

• Claude Code — ✅ per-line cwd.
• Codex — ✅ cwd on turn_context.payload (with workspace_roots), and sometimes on session_meta.
• OpenCode — ✅ session.directory (joined via session_id); falls back gracefully on older schemas without the column.
• PI Agent — ✅ cwd on the leading session line.
• Gemini CLI — ✅ cwd from a .project_root sidecar next to the session's chats/ dir (the chat log itself carries only a hashed projectHash).
• Qwen Code — ❌ not supported. Qwen does record a cwd, but v0.18.3 changed both its storage layout (~/.qwen/projects/<cwd>/chats/…, no longer ~/.qwen/tmp/*/chats/session-*.jsonl) and its token format (usage now lives in type:"system" / ui_telemetry qwen-code.api_response events, not the Gemini-style {"type":"gemini","tokens":{…}} blocks). toktrack's Gemini-based Qwen parser therefore ingests zero usage for this version — a pre-existing breakage independent of this PR. Once Qwen ingestion is fixed (separate change), per-project would come almost for free since the cwd is present.

Usage from any source without a project is grouped under a single (no project) entry.

How it works

• types — UsageEntry gains an optional project; DailySummary gains a nested projects: HashMap<String, ProjectUsage> (token totals + cost + count + a per-model map) so the breakdown is stored, not recomputed.
• parsers — claude.rs reads the per-line cwd; codex.rs reads turn_context/session_meta cwd; pi_agent.rs reads the session-line cwd; opencode.rs joins session.directory; gemini.rs resolves the .project_root sidecar. Sources without a project set project: None.
• aggregator — daily() populates the per-project / per-model breakdown; merged through weekly() / monthly() / merge_by_date(). New helpers: by_project_from_daily() (the list) and project_daily_summaries() (explodes summaries into per-project daily series for the drill-down).
• cache — CACHE_VERSION 13 → 14. A version mismatch keeps existing history (no wipe) and triggers a full reparse that backfills projects for every day whose raw files still exist, then caches it (surviving the CLI's 30-day deletion). The warm path now also checks the version per source (is_version_current), so a stale source cache is re-parsed even when other sources are current — previously such a source was never backfilled. Days already cache-only before upgrading keep an empty projects map (raw cwd gone), which is unavoidable.

Testing

• cargo fmt --all -- --check, cargo clippy --all-targets --all-features -- -D warnings, and cargo test all pass.
• New tests cover: cwd → project extraction for Claude Code, Codex, OpenCode, PI Agent, and Gemini (plus no-cwd → None paths); per-project/per-model aggregation; weekly rollup; explode-into-per-project-summaries; the stale-version-source backfill fix; the Projects widget rendering; and the tab navigation + drill-down interaction. Tests use synthetic placeholder paths (no machine-specific paths).
• Smoke-tested against real local data for Claude Code, Codex, OpenCode, PI Agent, and Gemini — cache rebuilt to v14 with days populated per project (nested per-model usage), each attributed to the correct working directory.

https://claude.ai/code/session_015Hunjgo5bjbvCfbtCeXMUq

[mag123c]

Really solid PR — thanks for this. The graceful fallbacks across every parser, the history-preserving cache migration, and the reuse of SourceDetailView for the drill-down all fit the codebase well. Tests pass and clippy is clean locally. Requesting changes on one item (#1), the rest are non-blocking.

1. (blocking) daily/weekly/monthly --json now leaks raw absolute paths
DailySummary.projects is serialized without skip_serializing_if, so the JSON CLI output gains a new projects key containing raw working-directory paths (which often include the OS username). This is both an output-schema change and a privacy surprise for anyone piping/sharing JSON. The shareable report receipt is correctly unaffected, so let's keep --json consistent with that:

#[serde(default, skip_serializing_if = "HashMap::is_empty")]
pub projects: HashMap<String, ProjectUsage>,

(or, if exposing it is intentional, let's document it.)

2. (docs) README / empty-state copy omit Gemini
The README bullet lists per-project support as "Claude Code, Codex, OpenCode, and PI Agent", and the empty-state hint says "usage from Claude Code populates this view" — but the code (and your PR description) also support Gemini via the .project_root sidecar. Could you align the copy?

3. (nit, UX) display-label collisions
project_display_name shows only the last two segments, so ~/a/x/proj and ~/b/x/proj both render as x/proj. The keys stay distinct so the data is correct — just visually ambiguous. Not a blocker; maybe show the full path on the selected row later.

Heads-up (not a change request): bumping CACHE_VERSION 13→14 makes every source stale on first run after upgrade, triggering a one-time full reparse for all users. That's expected given the new field and history is preserved — just flagging it.

CI hasn't run here (looks like it's pending approval for a first-time contributor). Given the Windows path handling in project_display_name and the OpenCode SQLite JOIN, it'd be good to get the 3-OS matrix green before merge.

[CubityFirst]

Thanks for the thorough review! Addressed #1 (blocking) in ea08855.

One thing worth flagging: skip_serializing_if = "HashMap::is_empty" alone wasn't enough — daily/weekly/monthly --json serialize summaries that have populated projects for recent/backfilled days, so the raw paths would still leak (I confirmed ~141 path lines in daily --json before the fix). So I did both:

• Added the skip_serializing_if attribute (drops the key when empty).
• The --json handlers now redact_project_paths(...) (clear the map) before serializing.

Net result: daily/weekly/monthly --json carry no projects key at all (verified: 0), consistent with the report receipt — while the per-project data is still persisted in the local cache and shown in the TUI. Added tests for the skip-when-empty serialization, the non-empty round-trip the cache relies on, and the CLI redaction.

#2 (docs) is addressed in 5967220 — added Gemini to the README per-project bullet and made the empty-state hint generic ("supported CLIs") so it won't drift again.

On #3 (display-label collisions): I don't think this can be meaningfully addressed without a consensus on the desired behavior first — specifically how much of the path to show (full path always? full path only on the selected row? a middle-ellipsized form?), or whether it should be user-configurable. The keys are already distinct so the data is correct; it's purely a display-policy decision. Happy to implement whichever direction you'd prefer.

[mag123c]

LGTM 🎉 Thanks for the quick turnaround on the review.

• chore(ci): bump actions/upload-artifact from 4 to 6 #1 (JSON path leak) — resolved well, and more robustly than my suggestion: skip_serializing_if keeps the key out for empty days, and redact_project_paths strips populated maps from --json, while the cache still round-trips non-empty maps. Verified the --json surface carries no project keys.
• chore(ci): bump actions/download-artifact from 4 to 7 #2 (docs) — README + empty-state copy now include Gemini.

I pushed one follow-up commit to keep the localized docs in sync for this release: README.ko.md and npm/README.md now describe the Projects tab / per-project breakdown (and the npm Multi-CLI list regained the missing Qwen Code entry). This matters because our release-please flow auto-publishes to npm on merge, and docs:-only PRs don't cut a release — so the localized/npm READMEs had to ride along in this PR.

CI is green across macOS/Linux/Windows — merging.

And honestly — thank you for the idea itself. I hadn't pictured a per-project view, and now I get to use a whole new TUI tab on my own usage. Genuinely great contribution. 🙏✨