Repository navigation
fix(lib): claim_candidates 在同 refs 分數內改為跨文件輪流抽取 (#60) - #123
Merged
Merged
Conversation
rankClaimCandidates() 過去在 refs 不再具區分度時（本 repo 量測：77% 的母體 refs 為 1）會退化成純 path/line 排序，使單一引用密度高的文件佔滿整個 capped window，其他文件排不進去。改為在同 refs 分數內，依每篇文件自身 claim 在該 refs 值下的行序編號（round-robin ordinal），跨文件輪流抽取， 再以 path、line 兜底；排序仍是全序且與 perFile 輸入順序無關， 「raising the cap only appends」（無 --exclude-ledger 時）這個性質不受影響 （cap-120 前 60 筆 == cap-60 全部，已驗證）。 同步更新： - inventory.mjs 原本「退化為 path/line，另外追蹤在 #60」的註解，改為描述 round-robin 的實際行為。 - judge.md step 3、rubric.md §Mechanical signal → dimension map、 design.md §Open questions 三處重述抽取順序的文字。 - judge.md §Scoped audit 的 --include 使用說明，補上「比對不到任何語料庫 內檔案視為錯誤（#120）」——刻意跟這次一起改，让 judge_hash 只移動一次。 - rubric.md §Version history 新增 2.2.0 條目：累積 ledger coverage 仍可 比較（population、claim_hash 都沒變），但抽取序列不可比較；judge_hash 41cb532f → d856373f。 測試：更新 lib.test.mjs 既有的排序測試說明，新增三個文件交錯抽取、refs 分數優先於 round-robin 序、perFile 輸入順序不影響結果的測試；更新 docgradMeta 的 judge_hash 固定值斷言。全部 354 個測試通過。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rubric.md 本身是 judge_hash 的輸入，寫進字面值會讓 hash 再動一次， 原本引用的 5781e476 已經過時。測試釘住的值更新為 9b641618。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
舊排序占滿前段的是路徑排在前面的文件，不是被大量引用的文件。 測試原本只打亂檔案順序，現在連檔內 claim 順序也反轉，拿掉 group.sort 的變異版本會失敗。judge_hash 隨 rubric.md 措辭改為 0e1f37cc。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #60。2.2.0 計畫的 S3。
改了什麼
rankClaimCandidates()的排序改為：refs 降冪 → 該 claim 在自己文件同 refs 值裡的序數（依行號） → path → line。也就是 refs 相同時跨文件輪流：先拿每份文件的第 1 條，再拿每份的第 2 條。排序仍然是 total、決定性的，而且和perFile的輸入順序無關。沒帶--exclude-ledger時，「調高 cap 只會往後追加」這個性質仍然成立：cap 120 的前 60 條和 cap 60 的 60 條完全相同。同步更新的文件（
judge_hash只在這個 PR 移動一次）judge.mdstep 3、rubric.md§Mechanical signal → dimension map：抽樣順序的描述judge.md§Scoped audit：加一句「--include對不到檔會報錯」（--include 的 pattern 沒對到任何 corpus 檔時，腳本照樣回報全 OK #120，特意放在這個 PR，讓 hash 只動一次）rubric.md§Version history：新增 2.2.0 可比性說明。累積的 ledger 覆蓋率前後仍可比，但抽樣的順序不可比。rubric.md 本身是judge_hash的輸入，所以照 E4b 前例不寫 hash 值，改指向 CHANGELOGdocs/design.md、inventory.mjs的註解指紋
judge_hash：41cb532f → 0e1f37ccmeasure_hashbd0d4a1b、corpus_hash71d1ce84：不變實測（本 repo）
前 60 條候選涵蓋的文件數，改之前和改之後都是 11 份。本 repo 前 60 條全是 refs ≥ 2（refs 2 ×38、3 ×12、4 ×7、5/6/8 各 1），refs:1 的平坦區根本進不了前 60 條，所以這次改動在這裡只影響 refs:2 層內的順序。#60 描述的那種退化，要在 refs:1 占多數的 repo 才會出現，由新增的 3 份文件合成測試直接驗證。
測試
node --test：354/354perFile順序結果不變🤖 Generated with Claude Code