[Dong1017]

What this changes

docs/kv-reclamation-qualification.md tells readers where to read the tooling that #357 removed. It names the bare commit e843b9d3. This names the published v0.1.4 release instead, in the history sentence, the two git show examples and the closing line of the reference table.

Why

A published release tag is a better anchor than a bare SHA: it arrives with a normal clone, it states what it is, and it needs no commit lookup to interpret.

v0.1.4 is the right one to name here:

Property	Check
Resolves to 5c86eb57	git rev-parse v0.1.4
Sole parent of the removal commit 1246348f	git log -1 --format=%p 1246348f → 5c86eb5
Ancestor of main	git merge-base --is-ancestor v0.1.4 main → 0
Holds all nine paths the page and its eleven-file table name	verified per path below

$ for p in tools/qualify_kv_reclamation.py tools/qualify_kv_edit_actor.py \
           tools/qualify_kv_actor_cleanup.py tools/kv_live_job.py \
           src/inferrsi/harness/kv_reclamation.py src/inferrsi/harness/kv_edit_workbench.py \
           tests/fixtures/kv_reclamation/candidate.py tests/fixtures/kv_reclamation/workload.py \
           tests/fixtures/kv_reclamation/reference.py; do
    git cat-file -e v0.1.4:$p && echo "OK  $p"
  done
OK  tools/qualify_kv_reclamation.py
OK  tools/qualify_kv_edit_actor.py
OK  tools/qualify_kv_actor_cleanup.py
OK  tools/kv_live_job.py
OK  src/inferrsi/harness/kv_reclamation.py
OK  src/inferrsi/harness/kv_edit_workbench.py
OK  tests/fixtures/kv_reclamation/candidate.py
OK  tests/fixtures/kv_reclamation/workload.py
OK  tests/fixtures/kv_reclamation/reference.py

This corrects no error on the page

The page says the old snapshot "remains an ancestor of main". That was accurate and still is. The commands it documents work today and are not at risk.

The first version of this PR claimed the opposite, and argued the reference could be lost to task-branch cleanup. Both claims were wrong. They came from measuring in a shallow clone: .git/shallow pinned 01c73521, that truncation boundary reports no parent, so git merge-base returned empty and rev-list --max-parents=0 named the boundary as a root. I read those artifacts as a rewritten history.

zengchuang-hw's review caught it against the GitHub compare API, which reads server-side and is unaffected. After git fetch --unshallow:

$ git merge-base --is-ancestor e843b9d31cb86e1fd12d00890c89798b0bedd1fe upstream/main; echo $?
0
$ git rev-list --count upstream/main
221
$ git log -1 --format='%h %ci %s' $(git rev-list --max-parents=0 upstream/main)
d7af6841 2026-10-07 18:34:36 -0700 chore: initialize repository

221 commits, original root intact, e843b9d3 an ancestor. The force-push on this branch rewrote only the commit message, which had carried the same wrong rationale; the tree is byte-identical to the previously approved a8bc0c0.

Scope

Documentation only, one file, six lines. No evidence bundle is touched — they stay hash-pinned and python -m tools.validate_evidence is unaffected. The per-claim receipt table and the retained-evidence list are outside the diff. No code, test, workflow or label change.

@zengchuang-hw @amy-why-3459 re-requesting review: the diff is unchanged from the one you approved, the rationale is not. Worth confirming the description now matches what the change actually does.

[cursor]

LGTM

PR review verdict — PASS
Reviewed base c38bb4e and head a8bc0c0 (full diff on opened; no prior reviews).

Verified:

• The only change is in docs/kv-reclamation-qualification.md. All three on-page anchors that named e843b9d3 now name v0.1.4: the history sentence and release link (https://github.com/InferMatrixLab/InferRSI/releases/tag/v0.1.4), the two git show examples (tools/qualify_kv_reclamation.py and tests/fixtures/kv_reclamation/candidate.py), and the closing line that the table references resolve at that revision.
• The git show v0.1.4:<path> examples are valid for a tag that peels to a commit, and they match the prose anchor.
• Scope stays on the retirement page. The diff does not edit qualification code, tests, or campaign artifacts.

Not verified here:

• Did not resolve tag v0.1.4 in a clone, so ancestry of base c38bb4e97db3ea4be4059b80376e0925e48c0df4, the "immediately before the removal commit" claim, and git show v0.1.4:<path> for the named files (including the rest of the eleven-file table) were not executed.
• Did not open the GitHub release page or CI.

No blocking defect in the reviewed text.

[amy-why-3459]

LGTM

PR review verdict — PASS
Reviewed base c38bb4e and head a8bc0c0 (full review of a new PR; one file, docs/kv-reclamation-qualification.md).

Verified via the GitHub API:

• Tag v0.1.4 is a lightweight tag on commit 5c86eb57030c4aea50592b66451929c8cee705d6.
• The removal commit 1246348f252dbc7e473efb1752c2d81da15e23f… ("chore: retire the synthetic CPU KV slice tooling") has 5c86eb57 as its sole parent, so "the tagged revision immediately before the removal commit" holds.
• compare v0.1.4...main is ahead by 3, behind by 0, with merge base 5c86eb57, so v0.1.4 is an ancestor of main.
• The recursive tree at v0.1.4 contains all nine paths named on the page and its reference table (tools/qualify_kv_reclamation.py, tools/qualify_kv_edit_actor.py, tools/qualify_kv_actor_cleanup.py, tools/kv_live_job.py, src/inferrsi/harness/kv_reclamation.py, src/inferrsi/harness/kv_edit_workbench.py, tests/fixtures/kv_reclamation/{candidate,workload,reference}.py).
• No e843b9d3 reference remains in the file at head; the retained-evidence list and receipts table are unchanged.
• All six check runs on the head commit passed (full-check 3.10/3.11, installed-package 3.10/3.11, declarations, pr-references).

Not verified: I did not run git show in a local clone or open the release page itself.

[zengchuang-hw]

LGTM

PR review verdict — PASS

Reviewed main at base c38bb4e97db3ea4be4059b80376e0925e48c0df4 and head a8bc0c0d373be3d5e34991238182e4fee2e8b891 in response to Dong1017’s GitHub review request. The single-file documentation change uses a valid release anchor for the retired KV tooling. No blocking finding remains.

• The published v0.1.4 release points to 5c86eb57030c4aea50592b66451929c8cee705d6, the sole parent of the removal commit and an ancestor of the reviewed base. I verified all nine distinct referenced paths in the tagged tree and read both example files from the verified tag commit with git show.
• The diff changes only the retirement page’s historical references and commands. Its receipt table and the retained evidence are outside the diff. This fits the bounded retirement recorded on #357 and #248.
• All five Ready CI jobs and knowledge-model-policy passed on the reviewed head. The policy check reports not applicable. I did not rerun the full suite or the retired campaign locally.

Non-blocking description correction. The original e843b9d3 snapshot is still an ancestor of main and of the tagged commit. I verified that in the GitHub comparison and with local git merge-base --is-ancestor against the tag commit. The old SHA remains reachable through those refs after task-branch cleanup. The updated page is accurate. Please describe the reason for the change as using a published pre-removal release anchor in the PR description and any merge summary.

Codex performed this review under direct delegation from zengchuang-hw, using that connected GitHub account. The delegation covers independent inspection of this PR, reporting findings, and submitting a formal approval on the verified commit when the review and applicable checks pass.

[zengchuang-hw]

Incremental review a8bc0c0 → 0b6dcea, current head 0b6dcea9e1f66d11962b046a50e7509df9baa522. The revised explanation matches the change. GitHub shows that the existing approval remains effective on this head.

本轮已解决 · Resolved

The PR description and commit message now explain that the shallow clone caused the earlier ancestry result. The old snapshot remains an ancestor of main, and the page now uses the published pre-removal release as a clearer reference. The two commits have the same parent and tree, so the reviewed document is byte-identical. Ancestry comparison · Current commit

批准前必做 · Before I can approve

No outstanding items.

非阻塞问题或建议 · Non-blocking

None.

I compared the Git commit records, checked the revised explanation against the ancestry evidence, and verified that all five Ready jobs and knowledge-model-policy passed on this head. I did not rerun the retired campaign.