tan-surface ledger still names tan 0.5.2 in README.md:187 and cases.sh:10 after the 0.6.0-rc1 renumber

[alpCaner]

Problem

scripts/tan-surface/ states, in the present tense and in two places, that its known-defect ledger is calibrated for tan 0.5.2 — a version that was never released and never will be.

The label was accurate when the harness landed: on 2026-08-09 the tree carried 0.5.2-rc1.dev0 and python/tan/version.py documented ## [0.5.2] — Unreleased as its CHANGELOG home. The release then renumbered 0.5.2 to 0.6.0-rc1 and swept the version files, the CHANGELOG section and npm-shim/package.json — but not the two scripts/tan-surface/ references. Both are still stale on origin/dev and origin/main.

This is a one-word label sweep, but it must touch both sites: a fix confined to the README leaves the stale label in the file the README itself calls the one you edit.

Evidence

Doc side — scripts/tan-surface/README.md:185-189:

## Known-defect ledger

Expectations target **tan 0.5.2** (re-derived against `dev`, 2026-08-08 — see
"Re-derived against dev" below for what moved since 0.5.1). One `xstep`
remains:

Twin occurrence in the case list — scripts/tan-surface/cases.sh:10-13:

# Expectations target tan 0.5.2 (re-derived against `dev` -- run every
# assertion below against the real binary/SDK before trusting an OLDER
# recorded expectation; see the "--version" and command-surface-drift steps
# right below, which exist to catch a case list that fell out of sync). Every

…in the file the README describes as the edit point — scripts/tan-surface/cases.sh:2-3:

# The ordered command surface. THIS is the file you edit when tan grows a
# command or an issue below gets fixed.

Code side — python/tan/version.py:49:

TAN_VERSION = "0.6.0-rc1"

No such tag exists. git tag -l "v0.5*" "v0.6*" at v0.6.0-rc1:

v0.5.0 v0.5.0-rc1 v0.5.0-rc2 v0.5.0-rc3 v0.5.0-rc4 v0.5.1 v0.6.0-rc1

The renumber is documented in release commit e2f5021 ("release: v0.6.0-rc1 (#750)"), verbatim:

The number is 0.6.0, not the 0.5.2 the version files carried: the milestone
being closed is v0.6.0 with 206 closed issues, no v0.5.2 milestone exists, and
the section carries a Removed block (the Rust oracle) -- pre-1.0 SemVer puts a
removal in the minor, not a patch.

Both references survive unchanged on the live branches:

$ git show origin/dev:scripts/tan-surface/README.md | sed -n '187p'
Expectations target **tan 0.5.2** (re-derived against `dev`, 2026-08-08 — see
$ git show origin/dev:scripts/tan-surface/cases.sh | sed -n '10p'
# Expectations target tan 0.5.2 (re-derived against `dev` -- run every
$ git show origin/main:scripts/tan-surface/README.md | sed -n '187p'
Expectations target **tan 0.5.2** (re-derived against `dev`, 2026-08-08 — see
$ git show origin/main:scripts/tan-surface/cases.sh | sed -n '10p'
# Expectations target tan 0.5.2 (re-derived against `dev` -- run every

grep -rn "0\.5\.2" scripts/tan-surface/ returns exactly those two lines and nothing else.

Impact

Low, and bounded — scripts/tan-surface/ is maintainer-only tooling that CI never executes (.github/workflows/getting-started.yml only shellchecks it), it is not in the shipped PyInstaller assets, one xstep remains (#448), and an XPASS announces itself loudly rather than rotting silently.

The cost is that someone running scripts/tan-surface/run.sh against a v0.6.0-rc1 binary has to reconcile a version number that appears in no tag list and no release before they can judge whether the ledger applies. The mitigating context is already in the file — line 187 names the branch and date, ### Re-derived against \dev` (2026-08-08)at :240 repeats it, andcases.sh:10-13` tells the reader to re-run every assertion before trusting an older expectation — so the only thing actually broken is the label.

Suggested fix

Replace tan 0.5.2 with the released binary the ledger is now measured against — or, since the derivation was against a tree rather than a tag, name the tree (`dev` @ <sha>, 2026-08-08). Both sites, one word each:

• scripts/tan-surface/README.md:187
• scripts/tan-surface/cases.sh:10

Add one line noting a re-derivation is due against v0.6.0-rc1.

While in the area, the same renumber left 0.5.2-line references elsewhere, for whoever picks this up: contract/README.md:440 (shipping Python CLI** (\tan 0.5.2-rc1.dev0`) on 2026-08-09), python/scripts/assemble_changelog.py:45, and python/tests/gates/test_version_check_refuses_an_empty_changelog_section.py:13. CHANGELOG.md:4173and:4292 (tan 0.5.2-rc1.dev0`) are correct as historical measurement records and should stay.

Related: #770 (release.yml does not bump the development version after publishing a tag).