Remove the cache epoch

[max-sixty]

Removes CACHE_EPOCH and the machinery around it, added in #4181.

Time-sensitive: 0.79.0 is merged to main but not tagged and not on crates.io, so the epoch has never reached a user. Landing this before the tag means it never ships.

What it was protecting

Two corner cases in 0.78.0 made wt remove delete an unmerged branch without -D, each needing two conditions at once. Reproduced against the v0.78.0 binary:

• diff.relative set and the command run from a subdirectory the branch's changes sat entirely outside. Run from the repository root with the same config, 0.78.0 correctly retains the branch.
• submodule.<name>.ignore set (git config or .gitmodules) and a submodule bump as the branch's only change.

In both, 0.78.0 reports ✓ Removed branch feature (no added changes on main, ⊂) and 0.79.0 retains it. #4146 fixed how the answer is computed, but 0.78.0 cached its wrong answer keyed on the branch and target tips with no expiry, so the fix can't reach an entry already on disk.

Why it goes

The epoch fires at most once per repository, on the first command after upgrading, and pays off only for a user who hit one of those corner cases and has a live cached key and then removes that branch. Against that it carried a stamp file, a tree wipe, a global mutex on every cache read and write, a documented hole when two versions share a repository, and a failure path where an undeletable directory left the reader with exactly the entries the wipe existed to discard.

So nothing replaces it: a repository that hit one of the corner cases under 0.78.0 keeps that cached answer after upgrading, exactly as it would have kept it on 0.78.0. wt config state cache clear drops it for anyone who asks. The changelog entry describes both corner cases and stays descriptive — it names no remediation.

No new negative behavior

0.78.0 and 0.79.0 read any entry already on disk identically — across v0.78.0..HEAD the key functions, the kind set, the consumers of both integration probes, and check_integration's priority order are all unchanged, and no cached struct changed shape. They diverge only on a cache miss, where 0.79.0 is right and 0.78.0 was wrong. So 0.79.0 without the epoch is a strict improvement on 0.78.0, and at worst a tie.

Also

• Release skill: two rules. A correctness or data-loss entry states the conditions the bug needed, joined with "and", established by reproducing against the previous release rather than read off the diff — without that, an entry like this one reads as though it fired for everyone. And entries describe: imperative guidance only for a material issue that affects a sizable share of users, which is rare.
• src/summary.rs: keeps the caveat that the summary cache hashes the diff while the prompt sits downstream of that hash, which previously lived only in the docstring this removes.
• CLAUDE.md: records that not versioning the cache is the decision, and that a generator change says in its PR what the old answers get wrong.

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

🤖 Generated with Claude Code

[worktrunk-bot]

Not approving this one: per .claude/skills/running-tend/references/review-pr.md § "Data-Loss Surface: Hold for Human Review", a diff that loosens a check gating wt remove's branch deletion isn't the bot's to approve. Against main as it stands, this is what stops a has-added-changes: false entry an earlier release computed wrong from reaching check_integration, so for a user with one of those two settings and a live key the next wt remove <branch> deletes unmerged work without -D. The description's reasoning and its timing both hold — v0.78.0 is still the newest tag — but trading automatic remediation for a changelog line on a branch-deletion bug is your call, not the bot's.

The rest takes the changelog route as given, and is about whether that line reaches the people it's for.

The self-check misses .gitmodules. It gates on "if either setting is in your git config", but PlumbingDiff's doc comment in src/git/diff.rs says plumbing diffs "still honor submodule.<name>.ignore, from repository config or .gitmodules" — and .gitmodules is where that setting usually lives, committed and shared. Someone whose repo sets ignore = dirty there checks git config, finds nothing, skips the clear, and keeps the entry.

The clear is per repository. handle_cache_clear opens Repository::current(), so "once" is once per repository — and diff.relative is typically a ~/.gitconfig setting, so the affected user has it in all of them.

The inline suggestion fixes both by splitting the remediation into its own bullet. That also pulls the main entry back toward the changelog's own ceiling: the remediation took it from 78 words to 118, against the 80 the release skill allows a headline entry, and this section is re-drafted and verified at tag time — a trailing clause is the most trimmable place for the one instruction affected users need.

The summary-cache caveat leaves with the code. UNVERSIONED_KINDS' doc comment was the only record that summary keys on the diff hash while SUMMARY_TEMPLATE and llm::prepare_diff's filtering sit downstream of that hash — so rewording the prompt leaves finished branches holding the old prompt's summary, and closing it means hashing the rendered prompt rather than the diff. src/summary.rs's "Layout and invalidation" section doesn't carry that ("Content-addressed filename … No TTL, no separate staleness check"), and the new CLAUDE.md paragraph scopes the question to sha_cache's kinds, which excludes summary. Say the word and I'll move those two sentences into src/summary.rs.

[worktrunk-bot]

b0ee1511 leaves no user-facing remediation anywhere. The case for deleting CACHE_EPOCH was that the changelog would carry the instruction instead — it's the PR description's argument, and it was CLAUDE.md's wording until this commit ("so the remediation goes in the changelog instead"). That commit removes the changelog clause and redirects the obligation to the PR description, which nobody upgrading from 0.78.0 reads. Step 12 of the release skill is explicit that release.yaml builds the GitHub release notes from the tree at the tag, so CHANGELOG.md is the channel to the affected user, and the PR description is not a channel at all.

So the chain is now: automatic invalidation gone, and the one line that told an affected user to run wt config state cache clear gone with it. A 0.78.0 user with diff.relative in ~/.gitconfig and a live has-added-changes: false entry upgrades, sees a note that the bug is fixed, and the next wt remove <branch> still deletes an unmerged branch without -D. One of the two has to stay. The changelog suggestion restores the clause with the per-repository qualifier 7967eb79 had — handle_cache_clear opens Repository::current() and sha_cache::clear_all sweeps only that repository's .git/wt/cache/, while diff.relative is normally set once in ~/.gitconfig — and adds the missing "as" in the submodule clause.

The new release-skill rule is the durable half, and as written it reaches further than this entry. CHANGELOG.md already instructs, in each of the three releases before this one: "Pi users re-run it to get a Pi extension" (0.78.0), "Re-run wt config plugins opencode install to pick it up" (0.77.0), "Nushell's wrapper is a static file, so rerun wt config shell install to pick this up" (0.76.0). Each of those is a static artifact the upgrade can't rewrite for the user, which is the same shape as a cache entry it can't recompute. A blanket "leave out remediation steps" makes those entries retroactively wrong and suppresses the next one. The suggestion narrows it to what looks like the real target — reasoning and advice out, a required action in one clause kept.

Verdict stays withheld for the reason in the first review.