[teknium1]

Summary

hermes -w now reaches the prompt in ~1.8s instead of ~14s.

Root cause: _prune_stale_worktrees runs synchronously before the banner and shells out to git several times per candidate worktree. On a repo with dozens of accumulated worktrees it accounted for 18.5s of a 20.6s cold start (11.6s on warm repeats) — while reaping nothing, because most aged trees hold real work and are permanently unreapable.

Root cause detail

Profiled on a 44-worktree checkout (24 aged candidates):

  0.34s  import cli
 18.51s  _prune_stale_worktrees        <<<< 90% of startup
  0.51s  _resolve_worktree_base        (git fetch origin main)
  1.13s  _setup_worktree               (git worktree add)

Inside the prune, the git cherry patch-equivalence probe dominated — 9.4s of 11.5s across 24 trees, because it diff-hashes every commit in the range against origin/HEAD. It is also pure repeat waste: a tree preserved because it holds unpushed work is re-probed on every launch, forever, always reaching the same verdict. On this repo 19 of 24 aged trees came back unpushed/dirty, so ~11s per launch bought zero reaps.

Changes

• cli.py — _prune_stale_worktrees split into three phases: a stat-only age filter, a parallel read-only classification phase (thread pool bounded to min(8, cpu_count, len(candidates))), and a serial mutation phase. Only reads are concurrent; unlock / worktree remove / branch -D stay ordered, so removal order and log output are unchanged. A pool construction failure falls back to serial rather than blocking startup.
• cli.py — _worktree_commits_all_merged_upstream accepts an optional cache dict and memoizes verdicts keyed on the exact (base_sha, head_sha, max_ahead) range they were computed from. Because that key is the complete input to the git call, a cache hit is identical to recomputation by construction: if either ref moves, the key changes and real git runs again.
• cli.py — new _load_worktree_merge_cache / _save_worktree_merge_cache / _worktree_merge_cache_path, persisting to $HERMES_HOME/cache/worktree_merge_verdicts.json (profile-aware via get_hermes_home()). Atomic write, bounded to 1000 entries, and a corrupt or hand-edited cache degrades to recomputation instead of feeding a bad verdict into a delete decision.
• tests/cli/test_worktree.py — 8 new tests across TestMergeVerdictCache and TestPruneParallelEquivalence.

No config knob, no new env var, no behavior flag — the fast path is the only path.

Validation

Measured on a real 44-worktree repo (24 aged candidates):

	Before	After
_prune_stale_worktrees	11.5s	2.05s cold / 0.42s warm
hermes -w to banner	13.9s	1.79s
worktrees preserved	44	44

Verdict equivalence was checked directly against the live repo: all 24 real-tree verdicts are identical across serial, cold-cache, and warm-cache runs ({'unpushed': 19, 'dirty': 5}). Every work-preservation guard still fires — dirty, unpushed, and live-locked trees all survive.

Tests: 75/75 in tests/cli/test_worktree.py (67 pre-existing + 8 new), including all 19 real-logic lock/dirty/unpushed safety contracts.

Sabotage-verified. The new cache tests were proven to actually fail without the fix: replacing the exact-sha key with a naive path-only key makes test_new_commit_invalidates_cached_verdict and test_cached_tree_with_new_work_is_still_preserved fail by deleting a worktree that had gained unmerged work — precisely the data-loss case the exact-sha key prevents.

Concurrent git worktree add / remove / status were separately confirmed safe under a thread pool before relying on parallelism.

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on e759365}

all good!