歷史記錄 · 2026-07-21¶
重大重構里程碑¶
2026-07-21 ─ DMCA 權利人訴訟通知路徑補文檔＋反通知流程對齊掃描制（dmca.md §5／DMCA.md §1・§5／pinning README）¶
使用者詢問「權利人提交訴訟通知怎麼做？有專屬頁面與 API？」——盤點發現三處使用者面文檔均未載明此路徑（僅 dmca.md §2 端點表含「hold＝記錄訴訟通知」半句），且 DMCA.md §1 反通知尾段仍停留舊敘事（「維運層重新審查通過→恢復」），未跟上 07-20 定案並已實作的「email 確認成案→通知兩造→14 工作日→每日掃描自動 restore→hold 攔停」模型＝跨檔 drift，一併重寫對齊。補記內容：訴訟通知無專屬頁面／公開 API 屬刻意設計——帶外路徑（法院文件寄 DMCA Agent 信箱）→維運者人工驗核→admin 裁決 hold（記 litigationNoticedAt、每日掃描跳過該案）→訴訟終局人工收尾；理由＝「已提起訴訟」無法機器驗證（證據是法院文件）、未驗證公開端點＝零舉證即可無限期壓住恢復的濫用向量（比灌 notice 更強）、現行方向 fail-safe（無人攔停＝自動恢復護上傳者、攔停必過 Bearer＋decisionLog 稽核）。跨檔：dmca.md §5 新訴訟通知段、DMCA.md §1 反通知段重寫＋§5 補訴訟通知處理 bullet、pinning repo README 部署行為要點補攔停操作指引。
2026-07-21 ─ pinning 檢查點採納模式定案：quorum-follow（輕跟隨）＋治理信任根部署注入（pinning-service.md §7 兩模式化）¶
決策檔：D-20260721-01
pinning 公版實作 T11 e2e 揭露兩個獨立缺口：①治理 trust root 缺失——startLedgerNode 未供給 signer set（帳本 genesis governanceSigners＝空集、vendored core appliers 無 config-update applier＝economyConfig 永停 genesis），checkpoint 提案與遠端採納同閘被擋；已修＝getSignerSet seam＋部署 config GOVERNANCE_SIGNERS 注入（預設空＝fail-closed）。②採納第二道閘——vendored 採納路徑實為「全窗重摺、逐位比對 canonical derived state」的驗證者語意（需全域 registry appliers），pinning 僅有 core appliers→含領域事件的真實窗必被拒；原 spec「derived state 解碼白拿」描述與實碼不符（drift）。裁決（使用者核可 (d) 案）：主 repo 帳本新增一級採納模式旋鈕——full-refold（客戶端驗證者、現行預設）｜quorum-follow（跟隨者：驗多簽 quorum→解碼白拿→自採納 state 讀下一 epoch governanceSigners 鏈式推進信任根；epoch 單調＋prev 鏈接防回滾），pinning 節點切用。理由：逐位重現使 applier 集成為共識關鍵元件＝任何領域 applier 改版即令舊版 pinning 節點採納停擺（社群自架 lockstep 跑步機、對開源運營最糟）；quorum-follow 免 vendor 面膨脹（棄 vendored 全 registry 方案）、信任模型簡單可審（放棄 pinning 端拜占庭偵測——客戶端仍全驗證、爆炸半徑＝垃圾 pin 受配額約束）、且回歸原 spec 跟隨者語意。過渡＝pinning 僅採納純 core 可重現窗（e2e 負向控制釘住、README 記限制）。跨檔：pinning-service.md §7 採納模式節、工作區內部文件（未入 repo）伺服器元件依賴分析 §10.9-13（主 repo 待辦：落地後 pinning re-vendor＋config 切換＋e2e 補領域事件窗案）、pinning repo design doc §5／§16／§17。