编辑原语：hashline 锚点是否比 Pi 原生 edit 更值得做成 OpenPI 机制？

[tt-a1i]

一句话问题：稳定 4-char hashline 锚点（拒绝 stale、禁止 fuzzy）是否比继续让模型用 Pi 原生 edit 更值得做成 OpenPI 机制？

这不是 commit 计划，也不是 Adopt。倾向 Discuss。本轮未安装、未运行下列包。不提议新安装器。Pi 继续拥有 install / update / uninstall。普通 edit 仍由 Pi 拥有。

为什么目录里这个机制看起来有趣

冻结身份（last-seen 2026-09-08）：

包	版本 / 日期	来源
pi-hashline-edit-pro	npm 4.1.0（2026-09-08）	https://www.npmjs.com/package/pi-hashline-edit-pro · https://github.com/YuGiMob/pi-hashline-edit-pro
pi-readseek	npm 0.9.16（2026-08-31）	https://www.npmjs.com/package/pi-readseek · https://gitlab.com/jarkkojs/readseek
@agimon-ai/doompi-hashline	npm 0.0.1-alpha.38（2026-09-08）	https://www.npmjs.com/package/@agimon-ai/doompi-hashline · https://github.com/AgiFlow/doompi

公开声明：read / replace / insert / grep 绑在短 hash 锚点上；锚点过期则拒绝，不做模糊匹配。这是编辑原语，不是第二套 agent 运行时。和「模型自己算行号然后 edit 错位」是同一失败模式的另一种证据。

和 OpenPI 已有能力的重叠

OpenPI 不拥有普通 edit / write；那是 Pi 原语。OpenPI 有 fd / rg、file-mutation TUI 投影、#165（Preview-first 结构化改写研究）。Hashline 若做成 OpenPI 工具，会与 Pi edit 并列，带来第二套编辑权威和 child 分类义务。

六问（AGENTS.md）

1. 哪条 Pi seam？ 普通 edit / write 已由 Pi 拥有。OpenPI 最多加强反馈，不应另建编辑控制面。
2. 模型判断还是运行时不变量？ 「这块该不该改」是模型判断；「锚点过期必须拒绝」是运行时不变量。后者可以很小。
3. 正交机制还是工作流？ 锚点拒绝是正交原语。若做成「hashline IDE」就是工作流。
4. 更强模型会不会直接用 Pi 原语？ 很可能会。更强模型更少错位 edit。这是 model-leverage 测试：机制价值应随模型变强而上升，而不是只修弱模型的行号错误。
5. 成功 / 失败证据？ 拒绝 stale 必须留下「锚点失效、未写入」；成功必须是精确 span。不能从 TUI 高亮推断已写入。
6. 权限如何停和清？ 新模型可见工具必须写入 CHILD_EXCLUDED_TOOL_NAMES 或 CHILD_SAFE_PACKAGE_TOOL_NAMES。写路径默认更像 parent-only 或与 Pi edit 同级的 child-safe，但未分类 = 拒绝。取消后不得把过期锚点重放成写入。

结论倾向

Discuss，不是 Adopt。 先回答「比原生 edit 多出来的失败类是否还存在」；若只对弱模型有用，就停在社区包。不 merge 上述包。

关联：#165、#299、#314、#300。研究记录：docs/research/PI_COMMUNITY_PLUGIN_SURVEY_2026-09-08.md。

[tt-a1i]

源码实验（只读克隆，未 pi install、未运行）：docs/research/EXPERIMENT_HASHLINE_EDIT_2026-09-09.md 目前在工作区 checkout a9b40f0 上，尚未进该 commit。

结论：Learn-from，不是 Pilot tool，不是 Adopt。 默认怀疑。

核实过的要点：

• Pi 0.84.1 / 0.85.1 的 edit 在精确匹配失败后走 normalizeForFuzzyMatch（行尾空白、智能引号、破折号、特殊空格）。Prompt 仍写 must match exactly。OpenPI 只包 TUI；child 已经有这份原生 edit。
• pi-hashline-edit-pro 4.1.0 的 4-char 锚点是 session 分配 ID，不是行内容哈希。[E_STALE_ANCHOR] / [E_RANGE_STALE] 成立，锚点不 relocation；同一次 replace 仍会剥前缀、对调区间、边界去重。它会关掉 Pi edit。
• 「hashline」不是一个协议：readseek 是 LINE: + 24-bit xxh32；DoomPi 是 8-char 精确字节 file tag + 3 字母去空白 FNV；RimuruW 0.8.3 有 textHint fuzzy 和 3-way merge；georgebashi 0.3.0 会在 ±20 行 auto-relocate。
• 拒绝 stale 是 runtime 不变量；先 read 再按锚点编辑、禁用原生 edit、持久 SQLite/Zig 是规定工作流和第二权威。更强模型更会用唯一 oldText + 失败后重读。

若以后要动编辑安全，更小的正交点是让 Pi fuzzy 可观察或提供 exact-only，而不是再注册一套 replace/insert。结构化批量改写继续停在 #165 / #510。不安装、不 merge 上述包。

[tt-a1i]

源码深读（只读克隆，未 pi install、未运行）：docs/research/EXPERIMENT_EDIT_GUARD_2026-09-09.md 目前在工作区 checkout a9b40f0 上，尚未进该 commit。对照 Pi v0.84.1=53fa77c 与 HEAD 6160683，以及 @lucascardozo/pi-edit-guard 0.15.0 / b4a5bf6。

这是矛盾 4 的匹配顺序钉死，不是 hashline 替代实现，也不是批准 silent indent。HASHLINE 已有评论仍然成立。

今天 OpenPI 没有第三步 indent rewrite。原生 edit 顺序是：

1. exact = 剥 BOM、LF 之后的 indexOf 子串（不是行首锚定）。少缩进的 oldText 常常因此直接命中，文件里多出来的前导空白留在结果里；成功句与真 exact 相同。
2. exact miss 之后才是 Pi fuzzy：NFKC、行尾空白、智能引号、破折号、特殊空格。不去前导空白，不改 tab，没有 indent rewrite。 0.84.1 与 0.85.1 这段合同相同。
3. usedFuzzyMatch 只活在 applyEditsToNormalizedContent 内部。成功文案永远是 Successfully replaced N block(s)；失败文案永远写 must match exactly（即使已经试过 fuzzy）。details.{diff,patch,firstChangedLine} 进 Session，但 OpenAI / Anthropic / Google 的 provider 变换只送 content（后两者另送 isError）。把旗只打进 details 对模型不可见。

pi-edit-guard 0.15.0 不是上述第 3 步。它在 native execute 之前用 tool_call 改 event.input：行首字面 → 剥前导空白的 unique-drift 静默改 oldText/newText → 它自己的 Levenshtein「fuzzy」（默认 ≥0.90）则 block，不写入。它的 fuzzy ≠ Pi 的 fuzzy。成功路径模型仍只看到 native 成功句。Child 已经有 Pi edit；全局装 guard 会被 child 加载（本树只滤 intercom）。

最小正交点仍然是：在已有 edit 的成功/失败 content 里写 usedFuzzyMatch，或给 createEditToolDefinition 一个 fail-closed exact-only。不是新工具，不是 /openpi-setup 新字段，不是装 guard。#165 / #510 继续分开。