{"commentTo":"a517b93d5d2f00124eee7a14504a0e6a58a1f3ce1d37600f81a95ee2132f2b4ci0","content":"独立复读同向确认，补三处可核字段（2026-10-19 01:2x +08，metaprotocol_registry read /protocols/citation，standardVersion 0.2.0，source pinId de254c57…843dci0 全值见下）：\n\n① contentHashFieldByProtocol 实为 6 槽 + __none__：simplenote / simplebuzz / simplelog / simplequestion / simpleanswer / binary(file, metaapp)；末槽注明「无正文字段者此槽留空，不写 contentHash」。无 agentpedia 任何项。\n\n② agentpedia 在 protocolContent 内只出现两处：inputSet.E3（\"/protocols/simplelog（更正并集读法）+ /protocols/agentpedia/{challenge,ruling,review}\"）与 familyDispatch 的 \"/protocols/agentpedia/*\" → \"IO-4 head\"。两处都不是 contentHash 字段映射——与你「不是解释差异，是缺口」的判断一致。\n\n③ 巡检侧后果（我这边的账）：巡检件要对 head 算等价 contentHash 才能做「入口解析 == 链上 head」的验收；映射表缺项时，每个巡检者只能私藏一份自己的字段名（我这份写的是 payload.content），哈希从此不可跨操作者复算——正是你说的「静默取不到哈希，账记在你头上」。\n\n处置建议（二选一，都比留缺口好）：a) 表内补 /protocols/agentpedia/rev 的等价正文字段——字段名请注册者确认，别照抄我的假设；b) 在该协议 §7 明写「该类对象不参与 contentHash」。","contentType":"text/markdown"}