-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Che Cheng edited this page Sep 11, 2026
·
1 revision
Welcome to the Akashic-Library wiki!
2026-10
- 2026-10-01 Zotero 匯入新建的條目與另一筆共用 DOI 時照建，並記一筆歧異提名（#611）
- 2026-10-01 akashic-verify-venue 的第 4 源改照 web-access.md 經 safari-browser 讀（#692）
- 2026-10-01
akashic-verify-venue加「對外形」步驟：查證確立正式刊名時指定或確認authorized，按需判定（#566） - 2026-10-01 venue 的
authorized有了撤回面：update-venue --unauthorize（#559） - 2026-10-01 organization 的
authorized有了寫入面：update-organization（#557） - 2026-10-01 公開 repo 的工作樹不再帶私有識別資訊（#693）
- 2026-10-01 #700 R1 verify 之後：四個點名的鍵有情境、鍵名比對收緊、
file add進 parity 表 - 2026-10-01 名字分類的判定面一律留判定記錄；store format 22（#564）
- 2026-10-01 同一筆記錄兩份並存時以 entities/ 那份為準：index、匯出、App，以及這一對改報 warning（#709）
- 2026-10-01 migrated-guard-control 改看 harness 的執行紀錄判定負控（#707）
- 2026-10-01 取全文只用導航、存檔交給人、每站每天 10 次嘗試（#613）
- 2026-10-01
bootstrap-venues建檔不再寫authorized（#563） - 2026-10-01 #703 R2 verify 之後：放上位址不覆寫、位址上的東西只有一個分類、重複附件跟著最終結果、訊號清暫存
- 2026-10-01 App 的寫入留下 legacy 拷貝時算成功，另以側欄提示列出要清的檔（#708）
2026-09
- 2026-09-30 import-zotero 的「已覆寫／已拿掉」清單只記寫進去的那一筆（#702）
- 2026-09-30 trigger-coverage 看得見宣告範圍裡不受保護的檔；census-parity 涵蓋整個 Sources/（#690）
- 2026-09-30 sources/ 單份上限 256 MB、SHA-256 與複製逐塊、補存時比對既有 blob（#703）
- 2026-09-30 S2 節流在鎖內保證兩次放行的間隔（#701）
- 2026-09-30 import-zotero 的 residualFields 說的是「讀到的」（#704）
- 2026-09-30 pre-push 改跑被推送的工作樹自己的 hook（#697）
- 2026-09-30 工具描述守衛往下一層看封閉的巢狀路徑表；每條寫入腿都要有 payload 情境（#700）
- 2026-09-30 tracked 檔不再寫死個人家目錄的絕對路徑（#688）
- 2026-09-30 migrated-guard-control 改看負控的實體；official-validate 補上負控（#689）
- 2026-09-30 寫了、但搬移後的 legacy 拷貝沒刪掉的那一筆，各寫入者統一記在成功那一側（#705）
- 2026-09-30 守衛稽核的 R2 verify 修正（#689、#690）
- 2026-09-30 enrich 的來源欄位走 #674 的 retrieval 形狀檢查；references 空陣列兩面都拒絕（#695）
- 2026-09-30 #705、#695 的 R1 verify 修正
- 2026-09-30 #703 R1 verify 之後：記憶體真的有界、新連結不連判不出來的存檔、放上位址的退路、殘留暫存檔可見
- 2026-09-30 GitHub Actions 釘到 commit SHA（#706）
- 2026-09-30 已知缺口清單的 issue 號不收
#0；零實例列的自證 grep 改LC_ALL=C（#710） - 2026-09-29 同一個 Zotero 來源被多筆 entry 宣稱時，匯入不猜、doctor 報出來（#610）
- 2026-09-29 活著的 Zotero 來源有了移除面；沒記 library_id 的附加來源出聲；多筆宣稱的來源復原時 orphan 標記照清（#680、#679、#682）
- 2026-09-29 Zotero 匯入：附加來源的比對先於 legacy 裸 key，且裸 key 的「已被其他 library 持有」看附加來源（#607）
- 2026-09-29「只有 hash 不同」改看 Zotero 的同步狀態、主來源也分出這一格；MCP 匯入報告的清單加上限（#608、#694、#696）
- 2026-09-29 附加來源的變動報告分開「內容變了」與「只有 hash 不同」；Zotero 附件複製進
sources/（#608、#606） - 2026-09-29 #593 與 #599 的 R2 驗證修正
- 2026-09-29 venue 的 ISSN 帶得了角色、venue 的 references 有寫入面（#587）
- 2026-09-29 venue 名字段的編輯面：時間欄位、source、note 與刪段（#675）
- 2026-09-29 venue 合併的名字併入：整段搬、只有原本的 variant 才標 variant（#565）
- 2026-09-29 — 歧異記錄的 venue 候選不再被報成懸空（#699）
- 2026-09-29 工具描述對回應鍵的守衛擴到全部工具（#672）、Zotero 匯入與 App 提示的殘項（#684）
- 2026-09-29 既有 skill 的網頁取得指令遷移到 safari-browser（#634）
- 2026-09-29 sink 守衛的豁免改成逐運算式，與擲出站點守衛共用一份規則（#584）
- 2026-09-29 references 寫入面的契約對齊、App 的可回溯性 wrapper 搬進 StoreIO（#674、#683）
- 2026-09-29 venue 的 references 與 work 的副本宣告，都刪得掉、（venue 的）也讀得出了（#673、#677）
- 2026-09-29 附加來源被刪除之後，doctor 與 App 裁決台都看得到、也處理得了（#609）
- 2026-09-29
migrate-venue-variants退場（#567） - 2026-09-29 library 有了機器可讀的成員性質，掛錯目錄在寫入時就不寫（#642）
- 2026-09-29 #642 的驗證 R1：依據不明確、改名同批遷移、set-kind 是整值替換
- 2026-09-29 守衛與普查的 shell／Python 移植成 Swift（#629 第一塊）
- 2026-09-29 取全文、Crossref 比對與摘要轉換的腳本變成
akashic子命令（#629 第二塊） - 2026-09-29 存進 store 的全文連得回條目了（#614）
- 2026-09-29 錯的
fields值刪得掉了（#544） - 2026-09-29 C2c（#654）與 #578 的 R1 驗證修正
- 2026-09-29 batch10 第二批驗證（C2a、C2b）的修正（#575、#641、#648、#581）
- 2026-09-29 batch11 整合：format 21、關係邊表第四次補列、零實例表第 43–47 列
- 2026-09-29 #629 兩塊的 R1 驗證修正（58 則）
- 2026-09-29 b13f 驗證 R1：移除面的報告會在 index 重建失敗時遺失、再匯入的提示寫成無條件、合併拒絕訊息指向會拒絕它的面（#680、#673、#677、#679、#682）
- 2026-09-29 #584／#634 驗證 R1 修正
- 2026-09-29 b11c 驗證 R1：#544 的因果句是假的、#614 的閘漏了兩格、#595 的插值沒有編碼（#544、#614、#595）
- 2026-09-29 b11b（#607、#610、#609）R1 驗證修正：legacy 的重複也是宣稱、宣稱者只有一份定義、裁決台三個動作同一條守衛
- 2026-09-29 B11a 驗證 R1 的修正：venue 合併的名字併入、venue references 寫入面與合併的耦合（#565、#567、#587）
- 2026-09-29 只被觀測到的隸屬，讀取面不再說「曾隸屬」（#663）
- 2026-09-28 寫入不再寫出讀不回來的檔；judge／refute 的理由有上限（#648）
- 2026-09-28 每一個 CLI 寫入面都要有閘的裁決；
--drop-author與 Zotero 匯入過閘（#658） - 2026-09-28 兩批 R1 驗證的修正（#669、#670、#586、#572）
- 2026-09-28 venue 名字的 canonical 形有修復面了（#575）
- 2026-09-28 多餘的 venue 邊刪得掉了（#572）
- 2026-09-28 un-split 刪拆分記錄之前，確認 git 裡真的有副本（#659）
- 2026-09-28 export-tables 多一張 publication_doi 表（#657）
- 2026-09-28 被截掉的 validate 明細有出口了：單筆完整明細（#581）
- 2026-09-28 load.sql 逐層回填上級機構，三層以上的機構鏈載得進 DuckDB（#667）
- 2026-09-28 MCP 工具描述精簡、
tools/list設位元組預算（#578） - 2026-09-28 寫不進去的記錄在 load 時就標出來，多檔寫入者不再寫到一半才被拒（#641）
- 2026-09-28
fields.<鍵>的來源 reference 補上 store format 17 的寫入閘（#668） - 2026-09-28 enrich 補進去的日期記得出處；作者不記，並說出為什麼（#655）
- 2026-09-28 空內容的 digest 不得被引用；服務層的 argv 檢查回到用法錯誤（#654）
- 2026-09-28 venue／organization 的重複 key 以 error 出聲，讀取端不再因重複 key 崩潰（#669）
- 2026-09-28 venue／organization 的 key 重複時，以 key 定位的寫入面不再猜寫進哪一筆（#670）
- 2026-09-28 歧異記錄可以放棄了（#586）
- 2026-09-28 #647／#569 的 R4 verify 修正（本批最後一輪）
- 2026-09-28 #569／#647 的 R3 verify 修正
- 2026-09-28 #569／#647／#588 的 R2 verify 修正
- 2026-09-28 #569／#647／#570／#588 的 R1 verify 修正
- 2026-09-27
zero-instance-guards第 21 列重量（#571） - 2026-09-27
WritingSystem以 Unicode 名稱判定拉丁字母（#568） - 2026-09-27 venue 名字內容的不變式寫進 spec（#570）
- 2026-09-27 repoint／demote 刪判定記錄之前要求 git 裡有副本；CLI 全列被刪的判定（#573）
- 2026-09-27
researcher_timeline加affiliation_kind（#651） - 2026-09-27
researcher表的現職隸屬分得開三態（#656） - 2026-09-27 輸出閘從列舉改成性質（#569）
- 2026-09-27 resolve-organizations 的逐篇判定（#647）
- 2026-09-27 多個 DOI 的匯出：第一個進 DOI，其餘進 addendum（#543）
- 2026-09-27
matchingKey在 scalar 上收斂空白（#574） - 2026-09-27 掛錯刊的 ISSN 拿得掉了，也看得見（#588）
- 2026-09-27 不可逆的命令要指名目標 store（#653、#650）
- 2026-09-27
rewritingProvenance的 venue 路徑有了行為測試（#590） - 2026-09-27 store 的 git 呼叫釘死
/usr/bin/git（#585） - 2026-09-27 enrich 的來源行不再把計畫說成已發生（#542）
- 2026-09-27 非判定 reference 的重複看得見了（#582）
- 2026-09-27 建檔回報 DOI 命中、bootstrap 第 1 步照實寫、散文守衛逐根跑（#637、#638、#644）
- 2026-09-27 回到預設建置系統：外部探針兩種佈局都認得，拔掉 native 釘子（#577）
- 2026-09-27 隸屬與上級機構的懸空 key 會出聲（#660）
- 2026-09-27 #660／#661／#582 R1 驗證的處置
- 2026-09-27 #543／#585／#573／#653／#650／#637／#638／#644／#577 的 R2 verify 修正
- 2026-09-27 #543／#585／#573／#653 的 R1 verify 修正
- 2026-09-27 只被觀測到的隸屬不再被讀成「已退休」或「進行中」（#661）
- 2026-09-26 store-source 拒收 0 byte 的內容（#546）
- 2026-09-26 MCP 的畸形清單／物件參數整個呼叫拒絕（#561）
- 2026-09-26 識別碼只收 ASCII 數字（#589）
- 2026-09-26 export-tables 分得出團體作者（#596）；resolve-people 列表模式的篩選（#597）
- 2026-09-26 錯誤訊息裡的清單有筆數上限（#562）
- 2026-09-26 #298 的目標確認閘：判準寫成「篩選式寫入」，
resolve-organizations --reject補進去（#580） - 2026-09-26 懸空的團體作者與 venue 邊出聲（#579、#652）
- 2026-09-26 CLI 分開「命令列打錯了」與「命令列對、環境不對」（#549）
- 查過未決的記錄、逐篇判定與 apply 並存（#619、#636；change
resolution-verdict-states） - 2026-09-25 — org-undecided-leg（#643）
- 2026-09-25 person／organization 的記錄檔預算預警（#645）
- 查證 skill 的「判不出來」出口改寫、取全文 skill 審查（#612、#613、#616、#618）
- 一筆記錄可帶多個 Zotero 來源，store format 18（#605）
- venue 終於有攣生合併的路，而擋住它的不是我第一次說的那個東西（#553）
- venue 的
authorized有了判定型寫入面——而它不是 append，這是端到端測出來的（#554） - organization 的攣生合併：裁決「暫不做」，與把那個裁決寫對（#555）
- venue／org 的建檔面終於會問「庫裡是不是已經有了」——而缺口早就發生過（#548）
- periodical 的 ISSN 覆蓋率 10%：裁決按需補，而「怎麼補」被 verify 改寫了一次（#556）
- 閘只護著記錄、沒護著被併實體——而開發時撞到的正是記錄那一半（#558）
- 「兩邊都還沒有記錄」的異寫看得見了，author 域的 literal 因此收斂（#547 #552）
- verdict 相等的單一定義，以及它解開的四張（#470 #486 #467 #469 #483）
- venue variant 家族：寫入面、severity、降級指示、顯示名回退（#471 #472 #473 #474 #475）
- un-split 與 work 欄位的來源：兩張 follow-up 的值域裁決（#513 #517）
- rename／verdict 的報告面：把安靜的東西變成看得見的（#496 #490 #495 #498 #494 #488 #497 #492）
paginated判定可以撤回，翻轉的每一筆各自帶值（#500）- 守衛基礎設施：
rawFile讀不到即中止、workflowrun:的腳本要存在（#527 #526） - 收攏留存者政策，與受保護清單的棘輪（#468 #522）
- 作者位的移除、以及「缺頁碼」其實是三個族群（#457 #449）
- 受保護集合的收錄判準：從手維護清單改成「會紅的檢查 ＋ 顯式條目」（#518，follow-up from #516 verify）
- 三個 hardening 缺口：
--out穿透 symlink、全鏈無大小上限、--library解析鏈與 README 分岔（#519，follow-up from #516 verify） - 守衛引用已刪除的檔：四個實例、三種嚴重度（#521，sister bug from #518）
- split-author 的判定持久化到 work 側：拆分記錄、format 16、孤兒 verdict 偵測（#450，Spectra change
split-verdict-historical-reference） - 階段 B 摘要存檔的出口：NDJSON →
[Proposal]腳本＋148 列實跑（#516） - generic add-only 補值：一份政策、Zotero 版降為 adapter、citekey／DOI 定位（#458，Spectra change
generic-add-only-enrich） - venue 的 verdict 數逼近 decode 預算時出聲（#499，裁決：候選 3）
- divergence 的 rests-on 必須是 digest——decode 與寫入閘補上
isValidDigest（#507） - CLI doctor 改讀
StoreHealth——第四條讀取路徑收斂（#504） - App 側欄「記錄」Section——per-record warning 終於在 App 上看得到（#487）
- verdict holder 遷移網格：四個具名缺口補齊，矩陣 12／12（#463）
- 死 verdict 進
StoreHealth（#464） - 本機缺承重存檔進
StoreHealth（#453） - 2026-09-03 · #455 批次 create 的 service 面：一次 load、一次 rebuild
- App 面的改名不再丟掉遷移報告（#465）
- venue
variant分割的 verify 修正（#422 verify R1） - venue 的 verdict 跟著 citekey 走（#460）
- merge 側 verdict 收攏與排列無關（#461）
2026-08
- venue.paginated 的判定面：「本刊用不用頁碼」從此有格子可判、有證據可查
- 收分隔符，不收拆好的名字
- venues 與 thesis 補上三個讀取面——而守衛在 pre-push 擋下過我一次
- 一個欄位在說謊，而它的兩個用途要分開
Author有三態，只有兩態接得起來- 最弱的那一列補掉一格——動手的理由是「只差一個參數」，不是「等到了實例」
- 只推 tag 時跳過驗證——省的不是時間，是
--no-verify的養成 - 一個從來沒有真的檢查過任何一列的守衛
- 一行註解只說了它那行做的一半，而說對的那半讀起來完全合理
- 最後兩支 harness 遷完：生成腳本自我驗證抓到兩個會靜默的抽取缺陷
- 換一個白名單不是修好，是把邊界挪了一格
- 第九輪：訊息說保留就要真的保留
- 第八輪：一個宣稱的真值取決於它被寫下的那一刻
- 第七輪：借了 tokenizer，沒借它的紀律
- 第五輪：我宣稱「恢復舊行為」的那句話只對一半的輸入成立
- 第四輪收尾：三個「跟隨上游」的方向，以及一個負控找到的空守衛
- 一個在自己的 issue 開著的期間又漂了一版的數字
- 三次 push 失敗、三個被推翻的假設，根因是兩行
- 守衛從跑兩遍變成跑一遍，而代價寫在註解裡
- 第一支守衛改用 Swift：遷移紀律暴露了一個既有的分岔
- 第三輪 verify 的 6 個 HIGH：修完 4 個，其中一個推翻了我自己的裁決
- 第三輪 verify 收尾：最後兩條，以及一個「看起來像唯一讀檔點」的旁路
- 驗收條件只問「有沒有多」——#394 的 6-AI verify 第一批修復
- 寫進磁碟 ≠ 看得見——venue 讀取面的兩個缺口（#394 verify）
- 「不猜」被實作成「靜默丟」，以及 pre-flight 只查了六分之二
- 兩席終於跑起來，第一件事就是找到我一小時前種下的資料損失
- 模型記錄了「有幾個」，卻沒記錄「憑什麼是幾個」——#394 收尾四項
- 剝掉可以，靜默不行——括號註記的可見性（#394 verify）
- 乾跑先抓到我自己的 bug——
migrate-identifiers（#394 §8） - ISBN-10 → ISBN-13 是正規化，不是基數（#394）
- 識別碼有型別了，但還沒有落點——#394 的前三節落地，後六節沒有
- 識別碼真的落地了：讀取→raw、寫入→normalized，以及三個不在清單上的發現（#394 §4）
- 識別碼能說出自己從哪來了——以及三個「守衛比我先想到」的時刻（#394 §5–§6）
- 一句話變成一支守衛：#407 的 169 個 commit，以及它在自己身上找到的東西
- 三筆頁碼缺陷，其中兩筆完全不會出聲——以及一次「issue 的假設本身是錯的」
- 一整夜的批次：五張 issue 關閉、一個 skill、六個識別碼型別，以及五次我自己弄錯（#383–#396）
- 身分是判定出來的——一條規則、一張被撤回的 issue、一條新的寫入路徑（#383 #386 #388 #389）
- 作者位的團體 literal、守衛的隱式-return 盲區、APA7 下限批 C（#378 #381 #340）
- APA7 下限的一輪（#359 #340 #267 #269 #302 #355 #357）
- nest-names-and-reissue-person-ids（#227 + #241，store format 10）