getagentseal/codeburn

Summary In OpenCode, archiving a session is an organizational action that simply sets a timestamp in the session.time_archived column of ~/.local/share/opencode/opencode.db. All session metadata, messages, parts, and token usages remain fully intact in SQLite. However, Codeburn's discovery query excludes archived sessions (WHERE time_archived IS NULL). Because opencode is treated as a standard non-durable provider, Codeburn interprets the absence of these sessions during discovery as file deletion, evicting them from the session cache (session-cache.v9) and stripping their token usage from historical metrics. Environment Codeburn Version: 0.9.23 Provider: OpenCode (opencode.db) OS: macOS (Apple Silicon) Steps to Reproduce Use OpenCode on any project/worktree to accumulate token spend. Run codeburn overview or codeburn sessions -p all to observe total token usage and cost. In OpenCode, archive the session (or a parent session with child subagents). This sets time_archived in opencode

Ran a systematic multi-agent audit of the codebase tonight and want to record the results so nothing is lost, and so the remaining real candidates get a second set of eyes. Method Every app source line was reviewed in overlapping chunks by a bug-hunting pass, then each finding went through: a skeptical verifier (refute-by-default, given the real code window), then a 2-lens adversarial pass (reproducibility + caller-contract, survive only if neither refutes), then my own manual verification with a mutation-checked test on anything I turned into a fix. Funnel: 553 raw -> 270 triaged -> 121 verify-confirmed -> 103 adversarial-unanimous survivors. Key caveat for reviewers: the flash swarm kept known-false findings through all three automated stages (e.g. it insisted a SELECT DISTINCT ... ORDER BY <non-selected col> crashes SQLite - it does not; I confirmed empirically). Automated confirmation is NOT sufficient here; each survivor needs manual verification before it becomes a fix. That is e

The scoped remainder of #389, whose Lifetime half was fixed by #753 and #759. The CLI dashboard and the macOS menubar both run the adaptive refresh cadence (activity-aware interval, nap-aware backstop); the GNOME extension still refreshes on its original fixed schedule. Bring it to parity: adopt the same interval policy the macOS menubar uses (fast while sessions are active, slow when idle) keep the existing GNOME battery/idle behavior intact document the cadence in the extension README Needs a Linux/GNOME environment to test, which is why it did not move with the rest of #389; contributions welcome, a maintainer can validate behavior descriptions against the macOS implementation.