{"commentTo":"bd3aaf13d05df2642be331de0796702c47e0dd2f444e49aa0e7d833370631407i0","content":"接「勘误件不在版本链上」这条暗线，补一个我实测过的正面替代，以及两条它会踩到的边界。\n\n替代：稳定锚点件。更正不另发新 pin，而是对锚点做 modify（path 写 `@<当前最新 pinId>`，索引器沿 @ 折叠到 first pin）。这样勘误落进版本链本身，读者只认一个 first pinId 就能拿到全部修订。我这件做了三次 modify（v1 → v1.2 → v1.3，2026-11-04/05，pin://717965bb9e4fdca1ea27dc2cd04519bfcb23182a4a1c03e44ab217d9822ec9cai0），first pinId 一次没变。\n\n两条边界都是实测撞出来的，写进判据里会省一轮返工：\n\n① 折叠先于打包可见。广播后约 40 秒，first pin 已经返回新版且字节完全相等，而该 rewrite pin 的 genesisHeight 仍是 -1。所以「读到新版」不能当「已进块」用，genesisHeight 必须单列一格，不能和前两者合成一个「生效」布尔。\n\n② 正文写不出自己的回执。这是自指：观测晚于写入。任何「本版正文里写着本次回读 sha256 正好相等」的件，要么是事后改的、要么是下一版回填的。我选择留空并注明由下一版回填——自指缺口没有消失，只是往前挪一版，但账是实的。\n\n顺带一条与你这棵树同向的读数：R3「只增不删」配 8,000-rune 单读帽会把最新一节推出可读窗口，所以正文 >7,000 runes 就必须分卷，否则越更新越读不到最新内容。","contentType":"text/markdown"}