Repository navigation
三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564
Description
Problem
三個「名字分類」的判定寫入面都不留 judgement：
| 面 | 寫的是什麼判定 | 留記錄？ |
|---|---|---|
person authorize-names --apply（#81） |
「這個名字是此人的對外形」 | ✗（Commands.swift 只有 --apply，無 judgement） |
venue update-venue --add-variant（#471） |
「這個名字是本刊的異寫」 | ✗ |
venue update-venue --authorize（#554） |
「這個名字是本刊的對外形」 | ✗ |
同一個 updateVenue 裡的 paginated（#406）卻要 judgement＋rests-on、寫一筆 ProvenanceReference。two-kinds-of-edits 對 AI 編輯欄的義務是「留 verdict／judgement，必附理由，可回溯、可逆轉」——三個面都是 AI 編輯（判定型），三個都沒做到這一格。
Type
feature
Expected
一次裁三面，不在各張 issue 各說各話：
- 留不留。若裁「不留」，
two-kinds-of-edits三列各註明「不留 judgement 是有記錄的裁決」（venue 的 authorized 只有 bootstrap 寫得到——479/479 筆是 [names[0]]，而合併會單向降級它 #554 R2 已先對authorize那列這樣寫，等本張改）。 - 留什麼形狀。store 驗證層已收
venue.references(field: authorized, value: X)與field: names（Provenance.swift），但空 rests-on 的 judgement 走不進——authorized不在firstOrderRulingFields（只有 resolution verdict 欄位對＋authors）。要裁：authorized／variant進不進firstOrderRulingFields（一階裁決、允許空 rests-on），還是同paginated要求證據 digest。 - 確認既有值也要留。venue 的 authorized 只有 bootstrap 寫得到——479/479 筆是 [names[0]]，而合併會單向降級它 #554 verify DA 席實測：對既有 authorized 呼叫
--authorize同名 → 報告空、檔案 byte-level 無 diff。470/470 筆 authorized 都是 bootstrap 的[names[0]]，一輪查證對它們最可能的結論就是「bootstrap 選對了」——而那個結論今天零寫入零記錄。
Actual
後果在 #553 的合併端：authorizedDemotedByMerging 對被併者的 authorized 只提醒不擋，理由是「今天不承載判定」。#554 之後面有了，但因為不留記錄，合併端仍然分不出「人確認過的 names[0]」與「機械 names[0]」——issue 自提的量測 authorized != [names[0]] 對「已確認」永遠回 0。
#554 R2 把 DivergenceResolve.swift 那格的重開觸發條件改成綁本張：本張裁「留」且落地後，合併端對「有 judgement 的 authorized」升成拒絕條件、對機械值維持提醒。
Impact
- 2026-09-11 實測：venue 485 筆、有 authorized 470、
== [names[0]]470/470；person authorized 由authorize-names批次策展寫入，同樣無記錄 - 與 venue 的 authorized 只能替換不能撤回——回不到誠實的未判定狀態（#500 clear_paginated／#418 demote 的同一格） #559（撤回面——撤回本身也是判定，若留記錄一併留）同族；與 bootstrap-venues 仍替人判定 authorized——每次建檔寫 [names[0]]，程式做了 two-kinds-of-edits 說該留給人的事 #563（bootstrap 該不該寫機械值）互為前後：bootstrap 不寫，「確認」才有意義
Source: surfaced during /idd-verify #554 follow-up triage (Step 5b) — 第 4 列＋第 2 列的裁決重開，使用者 2026-09-12 拍板「開 follow-up 一次裁三面」；verify report：#554 (comment)
Current Status
Phase: verified（b42 verify R7：HIGH 0、MEDIUM 0；### Blocking 的使用者裁決待處理）
Last updated: 2026-10-20 by idd-update
Blocking
- 使用者裁決：附了
--judgement而沒有名字進出 authorized 時整批拒絕（比 2026-10-05 裁決 2、3 嚴），維持拒絕，還是改成放行並回報「理由沒有寫進任何記錄」？（裁決後維持現狀，或改update-person的拒絕與 CLI／MCP 說明） - 使用者裁決：issue Expected 3（確認既有的值留記錄）對 person 不再成立，要另給 person 一個確認面，還是把 Expected 3 對 person 標成不適用？（裁決後開實作，或改 issue 的 Expected）
- 使用者裁決：報告的 attested 截在 20 個、以最後一項文字說出省略數、讀取面全列，維持，還是另加回應鍵、或讀取面也截？（裁決後改
nameSegmentFieldsDict與 MCP 說明，或維持） - 使用者裁決：
akashic-verify-person、akashic-promote-literals叫 agent 整份讀回names再寫、沒提醒要保留authorized，要不要補一行提醒？（裁決後改兩支 skill 文字，或維持） - 使用者確認（b39 的讀法）：合併只在「被併者自己不一致」時拒絕，而倖存者已有同一個矛盾時不擋——「同一個矛盾」我讀成同（分割, 名字）而且同方向；「會不會把記錄搬進倖存者」以（分割, 名字）為單位算，所以被併者會搬這個名字的某幾筆、而它不一致的最後一筆因倖存者已有而不搬時，照樣拒絕。b40 的 devil's advocate 實測：載入時就會隔離錨不到 names 的記錄，而方向等於成員資格，所以「同方向」這一條在任何載入得了的 store 上都不改變結果，要確認的實際上只剩第二個讀法。這兩個讀法對嗎？（對就維持；不對就改
heldTailContradictions與doomedTailConflicts） - 使用者裁決（b40）：兩筆攣生都持有同一個矛盾（例如名字仍在 authorized、最後一筆是撤回）時，合併照裁決放行，但仍會重搬被併者較早的記錄，倖存者的最後一筆因此被翻成「指定」。要改成被豁免的（分割, 名字）不重搬（行為改動），還是維持並把文件寫成實情？（b41 先把文件與測試寫成實情；裁決後才動行為）
- 使用者裁決（b40）：organization
remove_names的 MCP 報告在名字層級省略時新增detailsTruncated／detailsListed兩個回應鍵（沿用 venue 家族既有的鍵）。這在 2026-10-05「不新增回應鍵」的範圍之外嗎？（在範圍外就維持；在範圍內就改成不新增鍵的揭露方式） - 使用者裁決（b40 INFO 22）：在攣生豁免的範圍內，合併後倖存者的最後一筆由被併者 key 的字典序決定——同樣的歷史換個 key 拼法，倖存者原有的矛盾可能被保留，也可能被「修好」（是否拒絕不受 key 影響）。要維持（並把文件寫成實情），還是改成與 key 無關的結果？（裁決後動合併的搬運順序，或維持）
- 使用者裁決（b42）：帶時間的名字、variant 欄矛盾時，合併拒絕訊息說「工具面沒有出口、只能手改」。名字只有一段時其實有一條工具路徑（先用
--edit-name-segment清掉時間、走三步、再補回時間），多段同名沿革時才走不通。要把訊息收窄成「沒有直接的工具出口」並寫出那條路徑，還是維持只建議手改？（裁決後改tailConflictExits的訊息、store-format §3.5 與 spec delta，或維持）
Commits
faa4c055docs: 名字分類判定記錄的 Spectra change（proposal／design／specs／tasks）(三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)282dff7afeat: 名字分類的判定面一律留判定記錄，store format 22 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)924fc8b4docs: 名字分類判定記錄的 changelog、負對照與測試收緊 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)d567cae3docs: 整合 三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564 與 organization 的 authorized 零寫入面——13 筆全空，doctor 報得出來卻修不了 #557 R1：changelog 改成 organization 沒有撤回腿、row 78、tools/list 重量 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)c979c4f1feat: 名字分類的修正輪——去重只比最後一筆、person 的 names 要理由、已撤回的名字可連同記錄刪、一次至多 200 個名字 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)69ac4ea6test: 修正輪的新擲出站點與輸出逐一具名豁免、byteExactKey 站點清單補兩個檔 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)4f301e3dfix: 合併搬名字分類記錄按位置接、尾端與分類矛盾就拒絕，person 記錄要錨定得到 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)e1ac28b5fix: person 改正對外形拼寫回到一步，刪名字的拒絕說出走得通的出口 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)9af49326fix: person 的對外形不在替換裡消失、只替進出的名字寫記錄、會刪判定記錄的 CLI 移除腿過閘、合併搬記錄以原始倖存者為基準 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)03b9e10bdocs: 零實例表新列整合改號 90–91 → 95–96 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)0071c0affix: 名字分類修正輪四——報告裡的 attested 有上限、update-person 對兩筆不同 person 共用 key 拒絕、MCP 屬性說明改成實話、合併的結論不取決於 key 拼法 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)a3aeaf32fix: 名字分類修正輪五——合併的被併者自己不一致收窄、organization 刪名字報告的總量有上限、update-person 乾跑跑 writeEntry／rename 在 entities 佈局下留下 legacy 拷貝，自己造出同 id 的重複（sister concern from #627） #631 前置 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)a5ff5093fix: 名字分類修正輪六——帶時間的名字的合併出口說只能手改、update-person 乾跑跑整條寫入前置、organization 刪名字報告有位元組預算 (三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564)7ba4d695chore: b41 整合——plugin 殼 0.13.5 的摘要重記- tag idd-564-verified
Activity
fix: authorize 換下來的名字留在 names 未標、同書寫系統兩名一次送整批拒絕 (#554)
fix: venue 名字內容的不變式住在 store 邊界——Venue.validate 逐條驗、所有寫入者存 canonical (#…
kiki830621 commentedon Sep 30, 2026
Decision（2026-10-01，使用者）
裁決：名字分類的判定面一律留 judgement 記錄。涵蓋五個面：person
authorize-names、venue--add-variant、venue--authorize，以及同日裁決新增的 org--authorize（#557）與 venue--unauthorize（#559）。references（field: authorized或variant），必附理由，證據 digest 可空。代價（使用者看過）：需要升 store format，舊 binary 讀不到這種記錄。
Phase：待實作。排在 #557／#559／#563 落地之後。
feat: update-venue 加 --unauthorize，把名字移出 authorized、留在 names (#559)
feat: 新增 update-organization 與 akashic_update_organization，organizati…
fix: unauthorize 報告帶原 index 與顯示名變化，撤回再指定不是精確逆操作 (#559)
fix: bootstrap-venues 說明空 authorized 的後續，合併提醒不再對空的倖存者說對外形不變 (#563)
docs: 名字分類判定記錄的 Spectra change（proposal／design／specs／tasks）(#564)
feat: 名字分類的判定面一律留判定記錄，store format 22 (#564)
docs: 名字分類判定記錄的 changelog、負對照與測試收緊 (#564)
docs: 整合 #564 與 #557 R1：changelog 改成 organization 沒有撤回腿、row 78、tools/…
docs: akashic_import_zotero 的說明縮短，整合後 tools/list 回到預算內 (#611)
test: tools/list 位元組預算調到 60,000，按需說明另開 #713 (#578)
kiki830621 commentedon Oct 2, 2026
Decision（2026-10-02，使用者）：R1 verify 提出的四件
R1 verify（b26 F1／F2，2026-10-01）發現四件不屬於程式錯誤、要裁決的事。使用者四件都選建議方案：
update-person的fields.names整組替換時，可以改 authorized／variant，不附理由、不留記錄--judgement（MCPjudgement），並比照 venue 寫指定／撤回記錄。person 從此有單筆的名字分類面--authorize時打錯字的名字（或 authorize-names 採用的錯拼法）沒有工具能修venueReferenceCarry--add-variant帶上千個名字，會把同一句理由複製成上千筆記錄（實測 1,500 筆撐到 6 MB），沒有工具能移除這四件與同輪的程式錯誤（撤回後用同一句理由再指定時記錄被去重丟掉、合併時位元組去重早於分類檢查、開頭是組合字元的理由）一起在修正輪處理。
7 remaining items
kiki830621 commentedon Oct 4, 2026
Decision（2026-10-05，使用者）：b33 verify 之後的五件
fields.names整份替換，把沒有分類記錄的對外名稱移出（例如改正拼錯的對外名稱）update-person／update-organization的--remove-name要不要過目標 store 確認閘remove_names要不要保留另：合法的「指定 → 撤回 → 指定」歷史被 #582 的重複 reference 掃描誤報（b33 X1），屬程式缺陷，下一輪修正處理。
kiki830621 commentedon Oct 4, 2026
Verify R1–R3（2026-10-01～10-04）：R3 HIGH 0、MEDIUM 14，進修正輪
三輪都是六席交叉驗證（四個 Claude lens、devil's advocate、Codex 跨模型）。R1 由同一棵樹上的兩批驗證組成，其中一批只有一則 #564 的 LOW。表中是 findings 的原始筆數（INFO 不列），標題沒有 issue 編號的 finding 依內容歸屬（R2 的兩則 MEDIUM 與九則 LOW、R3 的兩則 LOW 屬這一類）；下面把同一件事被多席提出的合併成一條，括號是席數。
c979c4f1、69ac4ea64f301e3d、e1ac28b5R1 的 MEDIUM
使用者 2026-10-02 對其中四件事選了建議方案（#564 的 Decision 留言），修正輪與 R1 的程式錯誤一起落地。
update-person的fields.names全量替換能不附理由、不留記錄地改 authorized，是第六個名字分類面（codex、requirements、logic、devil's advocate 列為 MEDIUM，security 在 LOW，共 5 席；requirements 席用真 binary 重現：authorize-names之後替換把名字從 authorized 移到 variant，rc=0、零記錄，先前那筆「指定」留著過期）。devil's advocate 校正：三個名字分類的判定面都不留 judgement——authorize-names／add_variant／authorize 一次裁；#553 合併端能否把 authorized 升成拒絕條件繫於此 #564 的 Decision 只列五個面，不算需求沒覆蓋，降為文件問題，但mcp-cli-parity那句「person 的單筆名字分類面不存在」為假——裁決：替換讓名字進或出 authorized 時--judgement必填，比照 venue 寫指定、確認、撤回；替換拿掉有記錄的名字、或讓對外形整個離開 names，具名拒絕並指出口；mcp-cli-parity那句劃掉（c979c4f1）。--authorize打錯字的名字、person 在authorize-names之後要改的拼法，記錄錨定 names 而且刪不掉，拒絕訊息沒給出口（logic、regression、devil's advocate，3 席；devil's advocate 校正：venue 側的訊息有給出口，只有 person 側沒有）——裁決：最後一筆記錄是「撤回」的名字連同記錄一起刪，venue 擴充--edit-name-segment的 remove，organization 與 person 各多一條--remove-name '<名字>=<理由>'（MCPremove_names），理由必填、只進報告，檔案要先 commit 乾淨；最後一筆不是撤回的拒絕，出口是先撤回再刪（c979c4f1）。authorize-names（理由不同）之後合併被拒，而訊息建議的「先把記錄搬到倖存者」沒有任何工具做得到（regression、devil's advocate，2 席，真 binary 重現）——裁決：分類一致時被併者的名字分類記錄逐位元組搬到倖存者（personReferenceCarry，比照 venue 的venueReferenceCarry），preview 與實跑同一份referencesCarried，不一致時拒絕並指出口（c979c4f1）。judgementsRecorded: 0，記錄以撤回結尾而名字已是 authorized（logic 席，真 binary 重現；同一個缺陷在 organization 的 authorized 零寫入面——13 筆全空，doctor 報得出來卻修不了 #557、venue 的 authorized 只能替換不能撤回——回不到誠實的未判定狀態（#500 clear_paginated／#418 demote 的同一格） #559 的 R2 另有三席提）——改成只比同一個名字、同一個分割的最後一筆（c979c4f1）。venueReferenceCarry的位元組早退排在分類一致性檢查之前：兩邊各持一筆位元組相同的「variant 指定：R」，倖存者之後把名字抬進 authorized 又撤回，被併者的 variant 分類被合併安靜地拿掉（codex 席）——分類檢查移到前面，preview 與實跑都拒絕（c979c4f1）。String.hasPrefix在 Character 上比、與全形冒號併成同一個字，前綴比不上；帶--rests-on時寫成一筆一般 reference，--remove-reference刪得掉、合併端看不見，回報卻說寫了記錄（security 席，真 binary 重現；devil's advocate 校正：只有帶--rests-on時才安靜變成一般 reference）——parse改在 scalar 上比，入口另以NameClassificationRecord.reasonIssue拒收開頭是組合符號、格式或不可見字元、或沒有任何字母數字的理由（c979c4f1）。--add-variant帶 1,500 個名字，理由 4,000 字元，回judgementsRecorded: 1500，venue 檔 6,167,788 位元組）——名字分類的寫入面一次至多 200 個名字（venue 三條腿合計、organizationauthorize、personfields.names兩個分割合計、remove_names），超過整批拒絕、零寫入（c979c4f1）。resolve-people／resolve-venues／resolve-organizations的undecided、drop_venue（4,096 位元組、一次 200 條）、repoint、update_venue的unauthorize、remove_reference，CLI help 補上同樣缺的；真 binary 量tools/list一行 57,213 位元組，預算 60,000（c979c4f1、69ac4ea6）。R1 的 LOW 另處理：
authorize-names --apply沒寫任何名字時不再印「已寫入」、resolve-divergence --dry-run印出referencesCarried、update-venue報告多variantConfirmed、名字分類附著檢查的名字集合在迴圈外建一次、#600 的 authorize campaign的殘句改成按需判定。R2 的 MEDIUM
--remove-name叫人「把它從 authorized 移到 variant」，做不到）——被併者的記錄按它自己的順序逐筆接到倖存者後面，每一筆只與那個名字那個分割此刻的最後一筆比位元組（新的NameClassificationRecord.appendCollecting，與寫入面同一個規則）；合併後倖存者上若有名字的最後一筆與它的分類矛盾，而那是這次合併帶進來的，preview 與實跑都拒絕（wouldContradictClassificationTail）；刪名字閘的出口改成「先把它指定回去再撤回」；規則寫進docs/store-format.md§3.5 與 Spectra change（4f301e3d）。docs/store-format.md改成那條路與它的代價（--authorize抬出 variant、--unauthorize，兩次附理由、commit、再 remove；同書寫系統原本的對外形會被換下），akashic-verify-venue補一段「標錯異寫沒有單獨的撤回腿」（e1ac28b5）。personReferenceCarry不查記錄的名字在不在合併後的 names，被併者的「Foo Bar」（雙空白）遇到倖存者的「Foo Bar」不會併入，記錄卻被搬，實跑在寫入閘以「value 不是這筆記錄的名字」失敗——記錄的名字要在合併後倖存者的 names 裡，否則歸lost，由fieldsLostByMerging在 preview 與實跑同時以wouldLoseFields拒絕；分類的相等改看 canonical（4f301e3d）。--remove-name（regression 席）——離開 authorized 也離開 names、沒有任何名字分類記錄的名字放行，理由照樣必填、寫在進入的名字上，離開的名字列在回應的authorizedRemovedWithoutRecord；有記錄的名字被整份替換拿掉仍拒絕（e1ac28b5）。e1ac28b5）。R2 的 LOW 另有十六條，主要的處置：「同一句理由連送兩次是 no-op」的說明改成實話（指定之後的第一次重送寫一筆確認）、理由開頭的檢查改以性質判（Emoji_Modifier 與 SpacingMark 的 Lo 也拒收）、刪名字的記錄刪除改成線性、person 的
remove_names不刪到零個名字、organization 的remove_names報告多segments、合併預覽印出每筆記錄的 statement。未改、交給使用者的：只動 variant 的 person 名字替換不必附理由的讀法、附理由的替換對仍在 authorized 的每個名字寫確認、--remove-name要不要過目標 store 確認閘、organization 刪名字面的範圍。R3 的 MEDIUM
fields.names把沒有記錄的 authorized 名字整個拿掉，R2 新放行的路徑）有三個缺口（codex、requirements ×2、logic、regression、devil's advocate，共六則，5 席）：理由沒有存進 store 也沒有回報——沒有名字進入或留下時judgementsRecorded: 0，authorizedRemovedWithoutRecord只列名字，理由連「只進報告」那一層都沒有；另有名字留下時，理由被寫成對不相干名字的「確認」（例：刪「Latin Name」的理由寫在王小明的確認記錄上）；這條路不經 format 22 的寫入閘，也不要求 person 檔已 commit，與 changelog 的「format < 22 行為不放寬」相反（真 binary，format 18 的 store 上成功，doctor隨後印no authorized name: 1 person，要回復 authorized 又被閘擋下）；fields.names {"authorized":[],"variant":[]}還能把 person 清到沒有名字。live store 的 4,571 個 person 的 authorized 全是無記錄的，所以這條新放行的路徑就是fields.names對現有資料唯一生效的行為。建議的方向：把理由回進authorizedRemovedWithoutRecord（每項 {name, reason}）、要求檔案已 commit 乾淨（同remove_names）、更正 changelog 與 design 的說法。validate印兩則「重複的 reference」，而且沒有工具面可處理；regression 另量到：兩邊都走過同一個批次流程的一般攣生，修正輪之前搬 0 筆，現在搬 2 筆、resolve-divergence回報「2 筆」。三路攣生翻倍兩次。建議：被併者某個名字的整段歷史已是倖存者歷史的相同尾段時跳過。validate的重複 reference 掃描（非 verdict reference 的位元組變體重複（paginated／identifier retrieval 只差 NFC／NFD）沒有任何掃描面 #582）把合法的追加式分類歷史當重複，處置「留一筆」會弄壞尾端（logic、regression，2 席，真 binary 重現）：「指定 R → 撤回 S → 指定 R」是 §3.5 與新 spec 定義的合法歷史，掃描報「同一個動作做了兩次」，處置寫「確認說的是同一件事後留一筆（目前沒有工具面，手改 YAML）」；刪掉第三筆，尾端回到撤回而名字仍 authorized，正是wouldContradictClassificationTail拒絕合併、nameRemovalRefusal稱為不一致的狀態。R2 的合併修正自己產出的正確結果也會觸發這個永久 warning；doctor、MCP 的duplicateReferences計數與 App 側欄計數都因此非零，零實例表第 35 列寫「應恆為 0」。建議：掃描略過名字分類記錄，或改成位置感知、只報相鄰位元組相同的記錄。--remove-name都通過），所以不是做不到，而是出口句沒說要交換、交換會讓另一個對外形多一對撤回與指定；同一個出口句也寫在remove-name的拒絕裡，同樣不完整。venue 的訊息有寫這個代價，person 的沒有。field: variant最後一筆是指定或確認」這一半無效，因為--authorize對不在 variant 的名字只寫 authorized 欄位的記錄；正確的出口是先--add-variant、再--authorize、再--unauthorize。validate對這兩種狀態都全綠，沒有掃描面能先看到。before看不到這個矛盾，合併被拒；B 先於 A 處理則通過，結果取決於順序。建議：先記下原本倖存者的矛盾集合，搬完全部再比差集。appendCollecting是 O(搬的筆數 × 全部 references)（security 席，真 binary 量測）：每筆都倒著掃整份 references 並做 parse 與 canonical，兩個 person 各有 N 個互異名字、每個名字一筆撤回時，N=500 用 1.71 秒、1,000 用 5.72 秒、2,000 用 23.4 秒、4,000 用 89 秒（debug build，平方成長；同一個名字交替 8,001 筆只要 2.0 秒）；dry-run 經 preflight 與 preview 各算一次，實跑再算。update_person的名字替換每次可寫 200 筆記錄，所以不只手改 store 才有。這一處是修正輪新引入的退步（先前整份歷史的位元組集合是 O(R)）。建議：一次建好「名字加分割 → 最後一筆」的索引，每接一筆更新。進下一輪修正（2026-10-05 開始）。
逐則處置見 changelog：
changelog/2026-10-02-name-classification-correction.md、changelog/2026-10-04-b30-h1-fixes-564.md。fix: person 的對外形不在替換裡消失、只替進出的名字寫記錄、會刪判定記錄的 CLI 移除腿過閘、合併搬記錄以原始倖存者為基準 (#…
docs: 零實例表新列整合改號 90–91 → 95–96 (#564)
kiki830621 commentedon Oct 5, 2026
Decision（2026-10-05，使用者）：b34 修正輪留下的三項
remove_names回應的segments少列時分不出空段或截斷，要不要加區分的回應鍵update-venue --edit-name-segment一條腿兩種動作，裁決表只能記一格（實際只閘 remove）kiki830621 commentedon Oct 9, 2026
Verify R4（2026-10-05）：HIGH 0、MEDIUM 4，進修正輪
R4 是六席交叉驗證（四個 Claude lens、devil's advocate、Codex 跨模型），驗的是 R3 的修正
9af49326（03b9e10b只改零實例表的列號）。表中是 findings 的原始筆數（INFO 不列），標題沒有 issue 編號的 finding 依內容歸屬（兩則 MEDIUM、七則 LOW 屬這一類）；下面把同一件事被多席提出的合併成一條，括號是席數。R3 的 MEDIUM 怎麼修的
R3 的 14 條 MEDIUM 與使用者 2026-10-05 的五點裁決（#564 的 Decision 留言）一起處理。
fields.names整份替換：對外形不得整個離開 names，有沒有記錄都一樣；移出 authorized 的名字要留在 variant 並附--judgement寫一筆「撤回」。只替進出 authorized 的名字寫記錄，留下沒動的不寫確認，替換不會把 person 刪到沒有名字。這是裁決 1、2、3，authorizedRemovedWithoutRecord隨之退場。update-person、update-organization的--remove-name，update-venue的--remove-issn、--remove-reference、--edit-name-segment（帶remove）一律過目標 store 確認閘，update-venue改成逐腿裁決；MCP 面照既有政策不閘。裁決 5 保留 organization 的remove_names，沒有動。使用者 2026-10-05 第二批裁決對修正輪留下的三項：維持「對外形整個離開一律拒絕」、organization
remove_names少列segments時不加回應鍵、--edit-name-segment維持一條腿並在裁決表註明只閘 remove。三項都不改程式，文件還沒跟上（見 LOW）。R4 的 MEDIUM
remove_names回應仍受 store 內容控制、沒有上限（codex、logic，2 席列為 MEDIUM；devil's advocate 在 LOW 校正為偏高）。b34 只把segments截在 20 段（segmentsListedCap），共用的nameSegmentFieldsDict對每段的attested仍整列迴送；logic 席用真 binary 造一個名字、一段、20,000 個 attested，update-organization --remove-name單次輸出 460,506 位元組，devil's advocate 造 60,000 個得 1,380,503 位元組。零實例表第 96 列自己寫「段數與每段的 attested 項數都不封頂」，修了一半；MCP 面沒有位元組預算，直接進 LLM context。devil's advocate 的校正：live store 的 organization 與 venue 名字段 attested 最大為 0，要手造；那個函式是 venue 的edit_name_segment與讀取面共用、不是 b34 引入；使用者 2026-10-05 第二批裁決「不加回應鍵」只涵蓋segments少列。update-person --fields（names 加 judgement）對重複 person key 不查「無法唯一定位」（security 席，1 席；devil's advocate 在 LOW 校正為偏高）。真 binary 手造兩筆 key 同為dup的 person，validate報 error，--remove-name整批拒絕，但--fields的 names 替換附--judgement成功、judgementsRecorded: 1，指定記錄落在載入順序任選的那一檔。devil's advocate 校正：--fields {"note":"x"}同樣寫進任選的檔，是updatePerson的 fields 路徑整體缺這項檢查，不是名字分類專屬、b34 沒碰，歸 venue／organization 的重複 key 沒有任何檢查：export-bib 會崩潰（uniqueKeysWithValues），其他面安靜地選一筆 #669、venue／organization 的 key 重複時，以 key 定位的寫入面仍安靜地寫進第一筆 #670 那一族。akashic_update_person的 inputSchema 屬性judgement還寫「動到 authorized 時必填；仍是對外形的寫確認」（devil's advocate，1 席）。工具的 description 已改成「只替進出的名字寫指定／撤回」，真 binary 的tools/list（58,949 位元組）回的屬性說明卻沒改；照屬性說明呼叫，對沒動的名字附理由，會被「沒有讓任何名字進出 authorized」擋下（CLI 重現：rc=1、零寫入）。CLI help、store-format §3.5、design 都改了，只有這個機器可讀的契約漏了，也沒有測試守屬性文字；改一句位元組持平，在約 1,050 位元組的餘裕內。進下一輪修正（2026-10-09 開始）。
逐則處置見 changelog：
changelog/2026-10-05-b34-k1-fixes-564.md（R3 的處置）。fix: 名字分類修正輪四——報告裡的 attested 有上限、update-person 對兩筆不同 person 共用 key 拒絕…
kiki830621 commentedon Oct 14, 2026
Verify R5（2026-10-15）：HIGH 0、MEDIUM 3，進修正輪
R5 是六席交叉驗證（四個 Claude lens、devil's advocate、Codex 跨模型），驗的是 R4 的修正
0071c0af（b37 修正輪，2026-10-10 推上 mainf2a321e4）。六席都完成：第一次啟動（2026-10-10）撞到帳號用量上限，2026-10-12 與 2026-10-14 續跑。表中是 findings 的原始筆數（INFO 不列）；下面把同一件事被多席提出的合併成一條，括號是席數。Codex 這一席沒有提出 finding。R4 的 MEDIUM 怎麼修的
b36 的 4 個 MEDIUM（其中兩則經 devil's advocate 校正為 LOW），
0071c0af的處置：remove_names與 venueedit_name_segment的報告把每段 attested 截在 20 個，最後一項用文字說出省略數（不新增回應鍵），讀取面全列；真 binary 單段 20,000 個觀測點的回應從 460,506 位元組降到 1,095。update-person --fields遇到兩筆不同 person 共用同一個 key 時拒絕（乾跑同），先前寫進先載入的那一筆。akashic_update_person的judgement屬性說明改成「名字進出 authorized 時必填，否則拒收」，新測試走真 binary 的tools/list。使用者 2026-10-05 對修正輪三的三項裁決已照辦；changelog 另留五項待使用者回答的事，這一輪補進
### Blocking（見下）。R5 的 MEDIUM
doomedTailConflicts看的是候選佇列，不是carryCollecting真的搬進去的記錄，也沒套用倖存者那邊的old.contains(g)豁免。重現一：倖存者與被併者逐位元組持有同一個矛盾（名字在 variant、最後一筆是「指定」），b37 前合併通過，現在 dry-run 拒絕，訊息一邊寫「倖存者合併前就有的矛盾不擋」，一邊說矛盾是被併者「帶來」的。重現二：倖存者完全一致、被併者只是它歷史的前綴，合併什麼都不搬，base 通過、現在拒絕，訊息的「合併後最後一筆是「指定」」為假。重現三：照拒絕訊息的出口做（對被併者把名字移進再移回 authorized，附兩筆為了過守衛編的--judgement），合併後倖存者的 references 多出 4 筆永久歷史。另外，openspec 同一條 Requirement 的兩個 SHALL 在這兩個形狀上結論相反；NameClassificationMergeOrderTests的被併者 fixture 由.withdraw改成.confirm，剛好避開原本鎖住這個形狀的案例；changelog 的「交給使用者」第 3 點只描述了「先前一致的記錄排在後面就放行」那一種變嚴。方向：把檢查限縮在真的會搬進去的記錄，或對倖存者原始歷史已持有位元組相同記錄的群組豁免（不能綁處理順序）。remove_names的回應總量仍無上限（devil's advocate 列為 MEDIUM；security 在 LOW 提同一件事，共 2 席）。b37 只封了每段的 attested；一個名字最多 20 段、一次最多 200 個名字，兩個維度都不封頂。devil's advocate 造 200 個已撤回的名字、各 20 段（帶 300 字元的 source、note），MCP 單次回應 3,011,093 位元組；security 造 200 名 × 21 段 × 21 個 attested，4,699,784 位元組（org 檔 3.7 MB，低於 4 MiB 的 warning 門檻）。venue 的edit_name_segment有detailLimit（超過 20 項只列名稱、動作、理由，以detailsTruncated揭露），org 沒有對應物；repo 其他進 LLM context 的列表都受candidateByteBudget（48 KiB）約束。單段 60,000 個觀測點的形狀確實達標（CLI 1,095、MCP 1,293 位元組）。值得記的 LOW
update-person --fields --dry-run對 legacy 同 id 拷貝說wouldChange，實跑拒絕（requirements、logic；devil's advocate 校正：base 的 binary 對同一個 store 同樣回wouldChange，不是這個 diff 引入，新 guard 是淨改善）。judgement屬性說明「必填，否則拒收」讀起來像「沒附就拒」，真正新增的限制是「沒有名字進出卻附了就拒」（logic、regression）；測試只釘三個詞各出現一次。--add-variant都被 store 擋下；authorized 方向照做三步後還要第四步才通過（requirements、devil's advocate）。tools/list是 59,173／60,000 位元組。待使用者裁決
已裁決（使用者 2026-10-15）：合併時「被併者自己不一致就拒絕」收窄：只在被併者真的會把記錄搬進倖存者、且原始倖存者沒有同一個矛盾時才拒絕。下一輪恢復被改掉的測試資料，補上 twin 與「什麼都不搬」兩種情形的測試，拒絕訊息另寫被併者自己矛盾時的措辭。
仍待裁決的四項：issue 的
### Blocking原本只有「下一輪 verify」（devil's advocate LOW），現在各自列進 Blocking。--judgement而沒有名字進出 authorized 時整批拒絕（比 2026-10-05 裁決 2、3 嚴）：維持拒絕，還是改成放行並回報「理由沒有寫進任何記錄」？akashic-verify-person、akashic-promote-literals叫 agent 整份讀回names再寫，沒提醒要保留authorized：要不要補一行提醒？進下一輪修正。
逐則處置見 changelog：
changelog/2026-10-09-b37-n1-fixes-564.md（R4 的處置）。kiki830621 commentedon Oct 14, 2026
Decision（2026-10-15，使用者）：「被併者自己不一致就拒絕」收窄
b38 verify（R5）有兩席獨立實測：b37 新加的「被併者自己的分類紀錄不一致就拒絕合併」也會擋下兩種合併。一種是被併者什麼都不搬的合併，另一種是被併者只重複了倖存者原本就有的矛盾。這和同一條 Requirement 的「倖存者合併前就有的矛盾不擋」互相衝突。原本鎖住這個情形的測試，資料被改掉了。
doomedTailConflicts判的是被併者自己的記錄尾端，沒有看這次是否真的搬了記錄，也沒有看倖存者原本是否已有同一個矛盾fix: 名字分類修正輪五——合併的被併者自己不一致收窄、organization 刪名字報告的總量有上限、update-person 乾跑跑
chore: b39 整合——plugin 殼摘要重記（同一批的 #709、#692／#700、#564 改了 plugin/）
kiki830621 commentedon Oct 18, 2026
Verify R6（2026-10-19）：HIGH 0、MEDIUM 1，進修正輪
R6 是六席交叉驗證（四個 Claude lens、devil's advocate、Codex 跨模型），驗的是 R5 的修正
a3aeaf32（b39 修正輪，2026-10-18 推上 main04131a49）。六席都完成。表中是 findings 的原始筆數（INFO 不列）。a3aeaf32R5 的 MEDIUM 怎麼修的
照使用者 2026-10-15 的收窄裁決：被併者自己的名字分類記錄與分類不一致時，只有在「被併者單獨併進原始倖存者會把那個（分割, 名字）的記錄搬進去」而且「原始倖存者沒有同一個矛盾」時才拒絕；organization
remove_names的 MCP 報告合計至多 20 段，以detailsTruncated／detailsListed揭露；update-person的乾跑跑 #631 的前置，legacy 同 id 拷貝在乾跑與實跑以同一句拒絕。devil's advocate 逐字比對了整合時移植到 PR #736 字串結構上的拒絕訊息，與 b39 分支相同。R6 的 MEDIUM
--unauthorize會寫入，第二步--add-variant卻會被「異寫不得帶時間」的不變式拒絕，名字卡在中間。修正輪先以真 binary 重現再修。值得記的 LOW
remove_names的 MCP 報告只限段數不限位元組（security、devil's advocate）：20 段之內，控制字元逃脫後實測 141–326 KB；「小於 48 KiB」只對測試用的那份 fixture 成立。update-person的乾跑只補了 writeEntry／rename 在 entities 佈局下留下 legacy 拷貝，自己造出同 id 的重複（sister concern from #627） #631 前置（logic、regression，真 binary）：寫出位元組上限（寫入路徑的 2 倍寬限讓一次寫入就能產出讀不回來的檔——judge／refute 理由無上限、預警擋不住單步跳躍 #648）仍是乾跑回wouldChange、實跑被拒。docs/rulings/zero-instance-guards.md第 96、98 列與「各列共通」段自相矛盾；docs/rulings/mcp-cli-parity.mdCLI-only 表的resolve-divergence列沒有 b39 的重新確認；spec delta 沒有寫出程式的收緊。待使用者裁決
### Blocking原有的四項不動。b39 讀法確認那一項補上 devil's advocate 的實測（兩種讀法在真實 store 上給出同一個答案）。另新增兩項：攣生豁免下合併重搬較早記錄要不要改成不重搬（行為改動）；名字層級的省略新增detailsTruncated／detailsListed兩個回應鍵，是否在 2026-10-05「不新增回應鍵」的範圍之外。進下一輪修正。
fix: 名字分類修正輪六——帶時間的名字的合併出口說只能手改、update-person 乾跑跑整條寫入前置、organization …
chore: b41 整合——plugin 殼 0.13.5 的摘要重記（同一批的 #709、#700／#692、#564 改了 plug…
kiki830621 commentedon Oct 19, 2026
Verify R7（2026-10-20）：HIGH 0、MEDIUM 0，verified
R7 用六席交叉驗證 R6 的修正
a5ff5093（b41 修正輪，2026-10-19 推上 main7ba4d695）：四個 Claude lens、devil's advocate、Codex 跨模型，六席都完成。表中是 findings 的原始筆數，不含 INFO。a3aeaf32a5ff5093R6 的 MEDIUM 怎麼修的
狀況：名字段帶時間欄位，variant 欄不在 variant、卻以指定或確認結尾。這時合併的拒絕訊息一開頭就說明工具面的步驟走不通，只能手改，並寫出要改什麼。舊的三步出口不再給，因為第一步寫入之後，第二步一定被拒。
devil's advocate 用真 binary 照新訊息手改，之後合併通過。
值得記的 LOW（都不擋 verified）
--edit-name-segment清掉時間，做完三步，最後補回時間。update_person的dry_run說明過度承諾（requirements、logic、regression、devil's advocate 四席）：blockedBy*鍵回報，而 tools/list 完全沒有提到這些鍵。akashic_update_venue.edit_name_segment有同形的回應放大（requirements、regression、devil's advocate 三席實測 221–401 KB）：b41 的 changelog 寫「可另案」，但沒有 issue 號。追蹤開在 akashic_update_venue 的 edit_name_segment／remove_reference 回應沒有位元組上限：控制字元逃脫後實測 22–40 萬位元組（#564 follow-up） #739。--unauthorize／--add-variant。blockedBy*只回第一道之後的那一道（regression，真 binary）：format 9 加上巢狀 names 時，乾跑報 format 22 閘，實跑卻停在 format 10 閘，兩邊給的補救步驟不同。這個 store 狀態很罕見。待使用者裁決
### Blocking原有的裁決項不動。新增一項：上面那句「工具面沒有出口」要收窄成「沒有直接的工具出口」，還是保留「只建議手改」？這牽涉工具路徑要不要先改寫時間資料。HIGH 與 MEDIUM 都是 0，標為 verified。LOW 不擋，但其中三則（dry_run 說明、出口用詞、spec delta）若之後有修正輪會一起處理。關閉 issue 前，先處理
### Blocking裡的裁決項，再跑/idd-close。