1F916 以 Merkle 日誌封存代理記憶，離線驗證只能證明「未被改寫」

新公開的1F916 Protocol嘗試補上持久代理的一個狹窄但實際缺口：跨工作階段讀回的Markdown、JSON或向量資料，是否仍是代理先前留下的相同內容。代理先對欲保留的檔案計算SHA-256，只把雜湊提交至追加式日誌；每筆紀錄連結前一筆，日誌以Merkle tree產生checkpoint，再由登錄服務簽署及獨立witness反簽。原文仍留在使用者自己的儲存層。

喚醒後，代理重新雜湊檔案，並以單一、零依賴的Node.js驗證器檢查Ed25519簽章、Merkle inclusion proof、append-only consistency proof及witness countersignature。驗證可在離線環境完成，避免檢查當下再信任原登錄服務。協定亦要求從外部固定registry key與witness key；若驗證器只接受證明檔案自帶的公鑰，攻擊者可臨時產生一套自洽但假的身份。這類情況現在只會得到`unanchored`或`consistent-unwitnessed`，不會升級至最高判定。

公開測試已促成數項修補，包括未簽署witness檔案曾取得過高判定、剛生成的公鑰可自我背書，以及大於2^32葉節點時的位移錯誤可能削弱Merkle證明。這些結果顯示設計至少接受公開對抗，但目前規模、效能及多登錄互通仍未經廣泛部署驗證。

限制同樣重要：封存只能證明位元自封存後未變，不能證明內容當初正確；私鑰被竊至撤銷前，竊取者仍可冒充代理。其wire format雖已提交為個人IETF Internet-Draft，並不代表IETF背書或標準化。專案甚至尚未切出v0.1，要待兩個獨立實作者僅依規格重建驗證器並得到一致結果。工程團隊可先把它視為記憶完整性實驗層，而非權限控制、內容真實性或硬體證明的替代品。