CI 失败原因是 dashboard i18n 键缺失（TS2345），这是 PR #1418 原有的问题，与本次内存修复无关。

本次修复仅涉及：

• src/tools/jobs.ts（JobRegistry 自清理）
• src/memory/runtime.ts（AppendOnlyLog 检测报告）
• src/telemetry/stats.ts（SessionStats 滚动窗口）
• src/cli/ui/state/reducer.ts（卡片状态裁剪）

本地验证：npm run lint ✅ | npm run typecheck ✅

dashboard i18n 问题需要单独修复（补充缺失的翻译键到 dashboard/src/i18n/en.ts）。

Thanks @Bernardxu123 — direction's right, AppendOnlyLog and SessionStats both land where we want.

One real bug + one knob to tighten in JobRegistry before this is good to merge:

Bug — lastCleanupAt = Date.now() in the field initializer means the first 30s of process lifetime is a dead zone where maybeCleanup short-circuits. That's exactly the YOLO burst window where a session fires off npm run dev + a tail + a few one-shots inside the first few seconds; none of them get cleaned up. Initialize to 0 so the first call always runs.

Knob — MAX_COMPLETED_JOBS = 50 is generous: each retained entry still holds the 64KB output buffer + ChildProcess ref, so the bound is ~3.2MB pinned even when the cleanup does fire. Bring this down to 10–20 — list_jobs doesn't need 50 historical entries for the model to make decisions.

Optional but tidier — once the cap drops to a small N, you can drop the 30s time throttle entirely and just gate on count inside settleClosed. The work is O(jobs.size) with N=20, that's nothing.

Fix the init bug at minimum and I'll merge.

PR 描述已更新，详细说明了：

1. JobRegistry 自清理：保留最近 50 个已完成任务，超时 30 秒自动清理
2. AppendOnlyLog 折叠触发：在 ContextManager.decideAfterUsage() 中检查 log 长度，超过 500 条触发现有 fold 机制（复用已有压缩逻辑）
3. SessionStats 滚动窗口：保留最近 200 轮，旧轮次的 cost 聚合到 carryover
4. state.cards：现有 elideOldCardContent 机制已足够，无需额外处理

本地验证：lint ✅ | typecheck ✅ | test ✅

Thanks for the update — the memory-leak direction is right (AppendOnlyLog + SessionStats look good), but the branch picked up a problem since the last review and the JobRegistry blockers I flagged earlier aren't addressed yet. Three things before I can merge:

1. Branch silently reverts #1582 (the recently-merged session-switch fix)

This PR forked before #1582 was merged. The branch independently added the switching: boolean field and the if (tab.aborter) tab.switching = true; setters at the two handlers — but never added the consumer in runTurn's finally that actually reads the flag. The merged form of #1582 has:

} finally {
  tab.aborter = null;
  if (!tab.switching) {
    // ... emit $turn_complete, emitSessions, emitBalance, $plan_cleared, QQ
  }
  tab.switching = false;
}

The PR's finally block has none of that. The 3-way merge produces a clean tree (no conflict markers), but the semantic result is the switching flag gets set and never read — i.e. #1217 comes back. gh pr diff 1605 against current main shows the if (!tab.switching) block being removed.

Fix: git fetch origin main && git rebase origin/main, then drop the duplicate desktop.ts changes from this PR entirely (they're already in main via #1582).

2. lastCleanupAt = Date.now() (still not changed)

Same as the last round — the field initializer means the first 30s of process lifetime short-circuits every maybeCleanup call. Initialize to 0 so the first call always runs.

3. MAX_COMPLETED_JOBS = 50 (still not changed)

Each retained completed job pins the 64KB output buffer + ChildProcess ref. 50 × 64KB ≈ 3.2MB held even when cleanup does fire. The model doesn't need 50 historical entries from list_jobs to make decisions. Drop this to 10 or 20.

Optional follow-up once #3 is in: with a small cap, the 30s throttle stops earning its keep — gate the cleanup on count inside settleClosed and drop CLEANUP_INTERVAL_MS + lastCleanupAt entirely. The sweep is O(jobs.size) and at N=20 that's free.

Push a rebase + the two-line fix in jobs.ts and this is ready.

Applied all your feedback in a clean branch (fix/memory-leaks-v2 → PR #1620):

1. ✅ Rebased on latest main — no duplicate desktop.ts changes
2. ✅ \lastCleanupAt\ initialized to \

Bumping this with urgency — the branch has drifted further since the last review and now silently reverts four PRs that landed in main in the last hour. Do not merge this as-is.

git diff origin/main..HEAD --stat against current main: 33 files, +122 / −779 lines. The deletions are not yours — they're recent merges your branch hasn't picked up. Net effect of merging this PR right now:

GH still says mergeStateStatus: CLEAN because git's 3-way merge doesn't see text conflicts — your branch's absence of those lines is interpreted as deletion against main's additions. Semantically this is a disaster.

Example: the diff shows your branch removing ShortcutsHelpModal.tsx:29 ({ keys: "Alt+S", descKey: "shortcutsHelp.descAltS" }), which was added by #1572 about 90 minutes ago.

What you need to do:

1. git fetch origin main && git rebase origin/main
   • Drop your own desktop.ts switching-flag changes during rebase — fix(desktop): prevent stale events from corrupting UI after session switch #1582 already shipped a complete version of that fix, including the consumer in runTurn's finally which your branch never had.
2. The two jobs.ts blockers from my earlier review are still unaddressed:
   • private lastCleanupAt = Date.now(); → = 0; (otherwise the first 30s of process lifetime short-circuits every cleanup)
   • MAX_COMPLETED_JOBS = 50 → 10 or 20 (50 × 64KB output buffer is ~3.2MB pinned even after cleanup runs)
3. Once rebased, the PR diff should only contain the actual memory-leak work — JobRegistry cleanup, the AppendOnlyLog fold trigger in ContextManager.decideAfterUsage, and the SessionStats rolling window. That's it.

Heads up — main is moving fast this week; if the rebase takes more than a few hours, you'll likely need a second one. Push when ready and I'll review the diff again.

Closing this in favor of #1620, which carries the JobRegistry portion in a clean form.

Why I'm closing rather than waiting for a rebase: in its current state this branch silently reverts four merges that landed today (#1572, #1582, #1612, #1614) plus several older ones. mergeStateStatus: CLEAN is misleading here — git's 3-way merge sees the missing lines on this branch as deletions against main's additions, so a single careless "Squash and merge" click would undo about 650 lines of recent work. Keeping it open as-is is a footgun.

The other two pieces of the original proposal still look good and are worth landing — please open them as separate PRs against current main:

1. AppendOnlyLog fold trigger — the log.length > MAX_LOG_ENTRIES_FOR_FOLD branch in ContextManager.decideAfterUsage, plus the MAX_LOG_ENTRIES_FOR_FOLD = 500 constant. Reuses the existing fold path, low risk.
2. SessionStats rolling window — the MAX_TURNS = 200 cap in src/telemetry/stats.ts with cost / cache / turn-count carryover aggregation.

Each one ≤ 20 lines and orthogonal to the other, so two small PRs are easier to review than a combined one.

Thanks for sticking with this — splitting it up is the right shape.