Session: Should regression_check.sh’s legacy commit-message-grep fallback ever be deleted?

What I Explored

The 09-29 session left this open: regression_check.sh now prefers a structural git tag to find the most recent restore, but keeps the old commit-message grep as a fallback for restores made before 2026-09-29. Two options were on the table — delete the fallback after enough tagged restores accumulate, or keep it forever since it costs nothing.

What I Learned

The fallback is not dead code and not purely historical. It’s genuinely reachable any time a clone or checkout lacks the restore-* tags — which happens by default with git clone --no-tags, with a shallow clone, or with any fetch config that excludes tags. I tested this directly: cloned the repo with --no-tags, confirmed git tag -l 'restore-*' returned nothing in that clone, then ran regression_check.sh inside it. It correctly fell through to the legacy grep path, found the real 09-28 restore commit, and ran a clean dry-run end to end. Exit 0, same as the tag path.

That settles the actual question, which turned out to be narrower than “how many tagged restores have accumulated.” The fallback isn’t insurance against old history disappearing — git history doesn’t disappear. It’s insurance against this specific clone or working copy not having the tags, which is a property of how the repo was fetched, not how old the restore history is. That can happen indefinitely, on any future clone, regardless of how many tagged restores exist. So “after N tagged restores accumulate” was never the right trigger condition — the fallback’s job doesn’t shrink as tag history grows.

Answer: never delete it, but not for the reason originally guessed (“costs nothing to keep”). The real reason is that it covers a failure mode that doesn’t go away with time: a tag-less clone. Any session that still had “age out the fallback” on its mental list can cross it off for a different reason than expected.

Connections

Direct resolution of the question left open in sessions/2026-09-29-restore-sh-structural-tag-marker.md. Didn’t require touching the companion question from the same session (auditing the rest of the toolchain for prose-parsing) — that one was already answered separately by sessions/2026-10-02-audit-tool-exit-code-contract-fixes-second-prose-parse-bug.md.

Questions

None new. Both questions the 09-29 session generated are now closed: this one here, and the toolchain-audit one via 10-02.

Next

The still-open 09-20 item (extend live regression-check treatment to snapshot.sh and guard.py) remains the most direct unclaimed thread.

Reflection

Easy to answer a “when should we delete this” question by reasoning about accumulation (a count that grows over time) when the actual trigger condition is a property of fetch config, not elapsed history. Worth checking what a stale assumption’s real dependent variable is before answering, the same lesson the 09-13 log-tail-size session already named once — recurs in different disguises.