Fix blueprint attachments 修复蓝图附着实体

[WhereisFff]

fix(building): 修复磁化节点同步与蓝图附着实体放置

• fixed [Bug] 26.1 蓝图扫描仪无法扫描磁化节点，建筑杖无法放置含磁化节点或炼药锅输出口的蓝图 #5144

[Gugle2308]

⚠️ Dangerous command requires approval:

cd /tmp && curl -s --max-time 40 "https://piston-meta.mojang.com/mc/game/version_manifest_v2.json" -o vm.json; grep -o '"id":"26\.1\.2"[^}]*' vm.json | head -2; python3 -c 1 2>/dev/null; URL=$(grep -o...

Reason: script execution via -e/-c flag

Reply /approve to execute, /approve session to approve this pattern for the session, /approve always to approve permanently, or /deny to cancel.

[Gugle2308]

⚠️ Dangerous command requires approval:

cd /opt/data/workspace/AnvilCraft && rm -rf /tmp/base5150 && mkdir -p /tmp/base5150 && git archive rv5150base src/main/java | tar -x -C /tmp/base5150 && ls /tmp/base5150/src/main/java/dev/dubhe/anvilc...

Reason: Security scan — [MEDIUM] Archive extraction to sensitive path: Archive command 'tar' extracts to a potentially sensitive location

Reply /approve to execute, /approve session to approve this pattern for the session, /approve always to approve permanently, or /deny to cancel.

[Gugle2308]

⚠️ Dangerous command requires approval:

cd /opt/data/workspace/AnvilCraft && mkdir -p /tmp/b5150t && git archive rv5150base src/main/java | tar -x -C /tmp/b5150t && ls /tmp/b5150t/src/main/java/dev/dubhe/anvilcraft/building/ | head -30

Reason: Security scan — [MEDIUM] Archive extraction to sensitive path: Archive command 'tar' extracts to a potentially sensitive location

Reply /approve to execute, /approve session to approve this pattern for the session, /approve always to approve permanently, or /deny to cancel.

[Gugle2308]

代码审查摘要 — PR #5150

操作: opened（"state":"DRAFT" — 该 PR 当前仍是 Draft，故本次按 comment 级别给出结论）
范围: 2 个文件 / 52 行 diff（2 hunk，0 新增文件，0 删除文件，全部 Java）
完整性校验: patch-diff.githubusercontent.com 与 API Accept: application/vnd.github.v3.diff 两个端点产物 md5 完全一致（12d6f1ae0a66bba35b87ccc5c2690f3d，52 行 / 3003 字节），无静默截断；无 No newline at end of file、无行尾空白。
关联: fixed #5144（issue 现为 OPEN）

---

🟢 结论先说：未发现阻塞性问题，两处改动都精准命中 #5144 的两个症状

issue #5144 的两个症状我都做了根因对账，本次改动各自对应其一：

issue 症状	根因	本 PR 对应改动
扫描仪扫描磁化节点报 文件操作失败：Missing magnetized node support	客户端实体 blockState 从来没被同步过	MagnetizedNodeEntity.setSupport() + onSyncedDataUpdated()
建筑杖无法放置含磁化节点/炼药锅输出口的蓝图	BuildingRodService 一直在读旧版键名	"BlockPos"→"block_pos"、"CauldronPos"→"cauldron_pos"

根因链（可复核）：

1. 扫描那条：StructureScannerScreen:1053（客户端）→ StructureSaveUtil.buildSnapshot 客户端分支（非 ServerLevel 走 captureEntities()）→ StructureScannerBlockEntity.captureEntities():480 抓的是客户端实体 → ScannerDiskNormalizer.normalize:62 → BuildingEntityTransform.nodeSupport:160 读 entry.nbt().getCompound("block_state")，取 Name 去比对支撑方块。改动前 DATA_BLOCK_STATE 在 defineSynchedData(:28/:100) 里定义过但从未 set 过，客户端字段恒为 AIR → Name="" → 落到 :172 throw IllegalArgumentException("Missing magnetized node support")，正是 issue 里那句报错（对应 lang screen.anvilcraft.structure_scanner.file_failed）。修复后客户端能拿到真实 state，链路打通 ✅
2. 放置那条：BuildingRodService:388 先 BuildingEntityTransform.transform(entry, placement)，transform() 会把旧键规范化（rename BlockPos→block_pos、CauldronPos→cauldron_pos，并无条件写回 world-space 的 block_pos(:36-38)/cauldron_pos(:71)），而 :410/:417 传给 adapter.plan(..., transformed)、adapter 返回 transformed.copy()（MagnetizedNodeBuildAdapter:35、DynamicBuildingEntities.Outlet:191）——所以 plan.entityNbt() 里只可能是新键。旧代码用 .orElseThrow() 读 "BlockPos" → 抛 NoSuchElementException；注意 blueprints() 的 catch (ConstructionBlueprintException | IllegalArgumentException)(:245) 接不住 NoSuchElementException，所以旧行为是未捕获异常，而不是优雅的 invalid_structure。
   → 26.1 移植时实体 NBT 键改成了 snake_case（1.21 线 dev/1.21/1.6 的 MagnetizedNodeEntity 写的是 "BlockPos"，所以 1.21 的 BuildingRodService 用旧键是对的），移植时漏改了这一处，本 PR 补齐 ✅

---

🔬 关键 API 语义核对（离线字节码取证，非猜测）

改动引入 @Override public void onSyncedDataUpdated(EntityDataAccessor<?> key)，我针对 MC 26.1.2 真实客户端 jar（piston-data client.jar，sha1 4e618f09…，该版本类名未混淆）用纯 Python 常量池解析核对：

net/minecraft/world/entity/Entity:
  method onSyncedDataUpdated (Ljava/util/List;)V                                   public
  method onSyncedDataUpdated (Lnet/minecraft/network/syncher/EntityDataAccessor;)V public   ← 存在，@Override 可编译 ✅

net/minecraft/network/syncher/SynchedEntityData:
  set(EntityDataAccessor;Object;)V  -> set(EntityDataAccessor;Object;Z)V
  set(EntityDataAccessor;Object;Z)V -> DataItem.getValue()/setValue()/setDirty(),
                                       SyncedDataHolder.onSyncedDataUpdated(EntityDataAccessor)   ← 同侧回调 ✅
  assignValues(List)                -> SyncedDataHolder.onSyncedDataUpdated(List)
                                     + …onSyncedDataUpdated(EntityDataAccessor) + DataItem.getAccessor()  ← 收包侧 ✅

这是本次改动最值得确认的一点：SynchedEntityData.set() 在调用侧（服务端）也会回调 onSyncedDataUpdated(EntityDataAccessor)。因此 setSupport() 只写 entityData 不会让服务端字段变成 ZERO/AIR（否则 tick() 的 getBlockState(this.blockPos) + discard() 会在世界原点误判并立刻销毁实体）。客户端经 assignValues 同样双回调。两侧镜像字段都成立 ✅

同时确认与 1.21 上游一致（dev/1.21/1.6 的 MagnetizedNodeEntity 已有同样的 setSupport+onSyncedDataUpdated）——这是一次移植缺口的补齐，不是新发明，语义风险低。

---

💡 建议（非阻塞）

• BuildingRodService.java:430 — 同级三个消费点都做了新/旧键双读兜底：MagnetizedNodeBuildAdapter:34（.or(() -> read("BlockPos"))）、BuildingEntityTransform.nodeSupport:161、CauldronOutletEntity:337-343（cauldron_pos/CauldronPos）。这里仍是裸 .orElseThrow()，正确性当前完全依赖「transform() 一定先跑且一定规范化」这一隐式不变量。建议对齐成 read("block_pos").or(() -> read("BlockPos")).orElseThrow()，把不变量局部化，避免将来某条路径传入未 transform 的 tag 时再回归（1.21 时代蓝图文件的兼容性也一并兜住）。
• MagnetizedNodeEntity.java:31-32 — 改动后 blockPos（public）/blockState 变成同步数据的镜像字段，但没有写入口保护。任何未来代码直接 node.blockPos = … 都会静默与服务端/客户端脱同步——这正是 [Bug] 26.1 蓝图扫描仪无法扫描磁化节点，建筑杖无法放置含磁化节点或炼药锅输出口的蓝图 #5144 的同一类 bug。可考虑改成 entityData-backed 访问器（本仓库既有范式：CauldronOutletEntity.getCauldronPos()/setCauldronPos()），或至少降为 private + getter。
• readAdditionalSaveData（:117-118） .orElse(this.blockPos) / .orElse(this.blockState) 用「当前字段」当默认值：在现有调用路径（EntityType.create → 二参构造器 → load）下与 1.21 上游的显式 BlockPos.ZERO / AIR 等价，仅可读性上略隐式，可选优化。
• MagnetizedNodeEntity.java:112 该行长度恰好 140，而 style.xml LineLength max=140（>140 才违规）。当前 CI 能过，但零余量，后续加一个字符就红；顺手折行更稳。（NeedBraces 已设 allowSingleLineStatement=true，单行 if 不违规 ✅；无新增 import；src/main 无未使用符号。）

---

🟢 看起来不错

• 改动极小且范围干净：仅 2 处，无夹带、无格式化噪音、无资源/生成文件污染（grep -c "new file mode|deleted file mode" = 0）。
• 键名与 BuildingEntityTransform.transform() 的写出口径严格一致（world-space、snake_case），并且 transform() 的 legacy rename 让 1.21 时代生成的蓝图文件继续可放置，兼容性没有回退。
• 客户端 tick() 的物品吸附 AABB 现在用真实支撑坐标（此前客户端恒为 (0,0,0)），客户端预测与服务端行为由不一致变为一致。
• 补齐了 1.21↔26.1 的移植差异，避免两条线行为分叉。

📋 声称验证表

PR 声称	状态	证据
修复磁化节点同步	✅	setSupport/onSyncedDataUpdated；字节码证实 set() 双端回调；解释并修复 issue 的扫描症状
修复蓝图附着实体放置（磁化节点 / 炼药锅输出口）	✅	键名改为 block_pos/cauldron_pos，与 transform() 输出一致；消除未捕获 NoSuchElementException
fixed #5144	✅	issue 两个症状各有对应改动，详见上表

🧪 验证建议（本仓库无 src/test 源集，建议走实机/CI）

验证项	步骤	优先级
编译 + 门禁	./gradlew compileJava、style_check.yml（AGENTS.md 要求）	🔴
扫描症状	放磁化节点 → 结构扫描仪扫描 → 不应再出现 Missing magnetized node support	🔴
放置症状	含磁化节点 + 炼药锅输出口的蓝图 → 建筑杖放置 → 实体正确附着（非 origin/非 AIR）	🔴
同步/重载	世界重载 + 玩家重登后，客户端节点仍能正确扫描（验证 readAdditionalSaveData→entityData→spawn 包链路）	🟡
旧蓝图兼容	放置 1.21 线生成的（BlockPos/CauldronPos 旧键）蓝图文件	🟡
服务器逻辑	节点附近有掉落物、支撑方块被破坏 → 节点正常吸附/销毁（防止 blockPos 脱同步回归）	🟡

---

结论: COMMENT（倾向 APPROVE） — 改动精准、最小、与我核到的根因完全吻合，未发现阻塞性问题；因 PR 仍为 Draft，建议补上编译/in-game 验证后再转 Ready。若 gh 认证可用，标题建议改为更贴合内容的 Fix magnetized node sync and blueprint attachment placement 修复磁化节点同步与蓝图附着实体放置（本次 gh auth status 显示 token 失效，故未自动修改标题）。

---

由 Hermes Agent 审查

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'offline-pr-evidence-verification' (1 replacement).

[Gugle2308]

已核实。不发布审查评论 —— 按规则 1 停止。

核实证据（权威来源，非页面推测）：

• GET api.github.com/repos/Anvil-Dev/AnvilCraft/pulls/5150 → "state": "closed"、"merged": true、"merged_at": "2026-10-03T04:48:24Z"、"merge_commit_sha": "1a17b1db91fe4c6ad89a5d7f377e712921af46a6"、"commits": 1（squash）
• 事件头 PR #5150 closed ⟶ action = closed
• ⚠️ 附注：GitHub PR 页面 HTML 的 data-status="pullOpened" 在此例中是误导性的（页面上 >Open< 来自被引用的 issue [Bug] 26.1 蓝图扫描仪无法扫描磁化节点，建筑杖无法放置含磁化节点或炼药锅输出口的蓝图 #5144 fixed #5144 的状态渲染，正是 skill 里警告过的混淆点）；API 的 merged: true 才是真相。

按约束执行结果：

• 规则 1（closed/labeled → stop，不发评论）生效 —— 这是 skill 主文档第 7 节、references/webhook-pr-review-quickstart.md 步骤 1 与验证清单三处一致的硬规则。PR 已由维护者 squash 合入 dev/26.1/1.6，任何审查意见（无论 REQUEST_CHANGES 还是 APPROVE）都已无动作意义，只会成为噪音。
• 未执行 gh pr review / gh pr comment / 任何 POST（避免重复评论）。
• 未导出 GITHUB_TOKEN、未 source .env；全程匿名 curl 公开端点。
• 未执行 gh pr edit --title（PR 已合并，改标题无必要）。

(仅供操作者参考，非投递内容) 本次未产出审查文本。如需对该修复做 post-merge 观察（diff 仅 2 文件 / 52 行：BuildingRodService.java 的 NBT key 修正 "BlockPos"→"block_pos" / "CauldronPos"→"cauldron_pos"，以及 MagnetizedNodeEntity.java 改用 entityData 承载 block_pos/block_state + 新增 onSyncedDataUpdated 回写字段），可在后续非 closed 事件或改为手动触发时再跑一轮。

[Gugle2308]

💾 Self-improvement review: Patched references/merged-state-and-ci-verification.md in skill 'github-webhook-pr-review' (1 replacement).

[Gugle2308]

⚠️ Dangerous command requires approval:

cd /tmp && python3 -c "
import json
c = json.load(open('/tmp/pr5150c.json'))
b = c[-1]['body']
print(len(b))
print(b[3000:])
" 2>/dev/null || python3 /opt/data/workspace/pr5150_meta.py 2>&1 | sed -n '...

Reason: script execution via -e/-c flag

Reply /approve to execute, /approve session to approve this pattern for the session, /approve always to approve permanently, or /deny to cancel.

[Gugle2308]

代码审查 — PR #5150 Fix blueprint attachments 修复蓝图附着实体

⚠️ 本 PR 已合并：data-status="pullMerged"，squash commit 1a17b1db9 fix(building): 修复磁化节点同步与蓝图附着实体放置 (#5150)，即当前 dev/26.1/1.6 tip。已用 git diff <head> <merged-tip> -- <2 文件> 核对为空 ⇒ 本评论审查的对象与最终落库内容完全一致。以下为 post-merge 观察，不再有「合并前请修复」类动作项。

操作: ready_for_review（投递时已合并） · 范围: 2 个文件（2 Java，+16 −5，52 行 patch）· 与 merge-base diff 行数一致，未截断

---

🔎 两条因果链已逐一取证（修复方向正确）

① 扫描仪症状 ← 客户端 NBT 捕获不完整（sync 半边）

StructureScannerScreen 预览构建走的是客户端分支：StructureSaveUtil.buildSnapshot(clientBE, …) 中 blockEntity.getLevel() instanceof ServerLevel 为 false ⇒ 落到 blockEntity.captureEntities()（StructureScannerBlockEntity:480）⇒ 在 ClientLevel 上用 BlueprintCapture.captureEntity() 序列化客户端实体。旧实现里 MagnetizedNodeEntity.blockPos/blockState 是普通字段且未参与同步，客户端恒为 BlockPos.ZERO / AIR ⇒ 节点 NBT 的 block_state 是 air ⇒ ScannerDiskNormalizer.normalize → BuildingEntityTransform.nodeSupport 按 Name 找候选恒不匹配 ⇒ throw new IllegalArgumentException("Missing magnetized node support at …") ⇒ 被 StructureScannerScreen:1107 的 catch (IllegalArgumentException) 接住并显示为 screen.anvilcraft.structure_scanner.file_failed = 「文件操作失败：Missing magnetized node support」 —— 与 #5144 原文逐字一致。

同步修复在两侧都成立（本机 26.1.2 客户端类字节码核对）：SynchedEntityData.set(accessor,value,force) 内是 if (force || ObjectUtils.notEqual(value, item.getValue())) { item.setValue(value); this.entity.onSyncedDataUpdated(accessor); … }，没有任何 client 侧守卫；assignValues(List) 同时回调 onSyncedDataUpdated(EntityDataAccessor) 与 (List) 两个重载。所以构造器/readAdditionalSaveData 走 setSupport 后，服务端字段也会被回填（不会出现「改了 setSupport 反而服务端丢字段」的回归），客户端 spawn 时的非默认值同步也会回填。

② 建筑杖放置症状 ← key 与 transform 的写入键不一致（key 半边）

BuildingEntityTransform.transform 对节点/输出口执行 rename(tag,"BlockPos","block_pos") / rename(tag,"CauldronPos","cauldron_pos")（rename 会 remove 旧键），并显式 tag.store("block_pos"/"cauldron_pos", …)。因此 plan.entityNbt()（= transform → adapter.plan → sanitize 之后的 NBT）中旧驼峰键已被删除 ⇒ 旧代码 read("BlockPos") 恒空 ⇒ 无参 orElseThrow() 抛 NoSuchElementException。而 blueprints() 的 catch 只有 catch (ConstructionBlueprintException | IllegalArgumentException)（BuildingRodService:245）⇒ 异常逃逸出包处理。改成 block_pos/cauldron_pos 后与 transform 的写入键一致 ✅。

---

💡 建议（follow-up，非本 PR 阻塞）

1. orElseThrow() 建议带消息的 IAE。 这一行正在被改，正好顺手把「键缺失」从逃逸异常降级为既有提示：orElseThrow(() -> new IllegalArgumentException("Missing magnetized node support"))。当前无参形态抛的是 NoSuchElementException，不是 IllegalArgumentException，不会被 blueprints() 的 catch 接住（现状不可达：节点/输出口两个分支的 transform 都保证写入该键，且 MagnetizedNodeBuildAdapter.plan 已用 or(() -> read("BlockPos")) 前置兜底），但一旦将来出现绕过 transform 的路径，症状会是刷屏/掉线而不是 invalid_structure。
2. 形态对齐建议：CauldronOutletEntity 是「全程 entityData」的参考实现（getCauldronPos/getAttachedDirection/getCauldronState 读写均走 entityData，客户端 NBT 天然完整）。本 PR 给节点选了「影子字段 + onSyncedDataUpdated 回填」的最小改法，功能等价；但 public BlockPos blockPos 仍可被外部直接赋值而静默绕过同步（当前唯一外部读取方 MagnetUtil:102 是只读）。若愿意，可把字段删掉、让 addInitialSaveData/tick 直接 entityData.get(...)，与 outlet 完全同形，彻底杜绝二次漂移。
3. 同类风险清单（未逐项核实，仅提示自查）：客户端扫描预览的 captureEntities() 依赖「序列化所需字段在客户端可用」。AnimateAscendingBlockEntity.addAdditionalSaveData 写的是普通字段 this.blockState，SlidingBlockEntity 写 this.time/this.section/this.moveDirection —— 若这些字段不参与同步，客户端预览捕获到的 NBT 同样会退化为默认值（表现为预览错位/旁边报错）。建议另开 issue 清点，不必在本 PR 处理。

🟢 已核对为正确/安全的点

• 键名修复与 rename+store 的写入键严格一致；全仓 grep "BlockPos"|"CauldronPos" 后仅剩 MagnetizedNodeBuildAdapter、CauldronOutletEntity、BuildingEntityTransform 的旧档兜底（均带 .or(...)），无残留错误读取路径。
• readAdditionalSaveData 改走 setSupport(...) 后不存在状态错位：orElse(this.blockPos/blockState) 的初值与 entityData 初值同为 BlockPos.ZERO/AIR；而 notEqual 短路只会在「值相同」时发生，此时字段与 entityData 本来就一致。
• 服务端 tick() 的 discard() 判据、AABB 吸附区、MagnetUtil 的「二次右键移除同支撑节点」（entity.blockPos.equals(pos)）仍读字段，两条写入路径（构造器 / load）都会经 entityData.set 触发回调，未引入回归。
• 本 PR 不涉及文案/资源/生成文件，无需 lang 四层同步。

🧪 回归验证建议（已合并，供后续）

场景	期望
世界放磁化节点（支撑=整方块 / 半砖各一次）→ 打开扫描仪预览	不再报「文件操作失败: Missing magnetized node support」，节点在预览中位置正确（验证客户端 NBT 捕获）
断开重连后再开扫描仪预览	仍正常（验证走同步而非仅本地构造路径）
建筑杖放置含磁化节点与含炼药锅输出口的蓝磁盘（生存 / 创造）	能放置、附着位置正确、材料账目与撤销回收正常
同支撑上二次右键移除节点	正常移除（验证服务端字段同步回调真的生效）
legacy 旧档（只有 BlockPos/CauldronPos 驼峰键）导入 → 扫描/放置	经 transform 迁移后行为与新版一致

结论: COMMENT / 无阻塞项（已合并）。 两半修复的因果链均经代码 + 字节码双向取证，与 #5144 的两个症状精确对应；上面 3 条仅为 post-merge 加固建议。PR 标题（Fix blueprint attachments 修复蓝图附着实体）已足够准确，且已合并，未做 gh pr edit（另：本会话 gh auth status 报 token invalid，按规程不导出凭据、不改标题）。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'building-rod-blueprint-review' (1 replacement).

[Gugle2308]

PR #5150 已合并 — 本轮为重复投递的 post-merge 说明

⚠️ 首要事实（权威来源，非页面推测）：GET api.github.com/repos/Anvil-Dev/AnvilCraft/pulls/5150 → "state":"closed"、"merged":true、"merged_at":"2026-10-03T04:48:24Z"、"merge_commit_sha":"1a17b1db9…"、merged_by: PigeonNian，commits:1（squash）。已核对本地 dev/26.1/1.6 现 tip = 1a17b1db9 fix(building): 修复磁化节点同步与蓝图附着实体放置 (#5150)；git diff rvhead5150 rvbase261 -- <本 PR 两个文件> 为空 ⇒ 审查对象（head 33678f6a）与最终落库内容逐字一致。不再给出"请修复后合并"类动作项。

本 PR 已于合并前由本 webhook 审查过（04:45Z 评论即该审查全文）：head sha 与 diff md5 与本轮完全相同（12d6f1ae0a66bba35b87ccc5c2690f3d，52 行 / 3003 字节），故不重复发布全篇结论。以下只列本轮新增/复核项。

---

✅ 本轮复核（与既有结论一致）

• 键名修复正确：BuildingEntityTransform.transform:28-34 已把 BlockPos/BlockState/CauldronPos/CauldronState/AttachedDirection 重命名为 snake_case，且对 node/outlet 无条件写回 block_pos:36-38 / cauldron_pos:71；plan.entityNbt() 全部来自该 transformed（MagnetizedNodeBuildAdapter:35、DynamicBuildingEntities.Outlet.plan:191）⇒ 旧代码读 "BlockPos"/"CauldronPos" + orElseThrow() 必然抛 NoSuchElementException。新键读法正确，且无需 legacy 回退。
• onSyncedDataUpdated(EntityDataAccessor) 两侧回调可用：26.1 客户端 jar 字节码 SynchedEntityData.set(accessor,value,force) → SyncedDataHolder.onSyncedDataUpdated(EntityDataAccessor)（同侧回调），Entity 亦声明该重载 ⇒ setSupport 在服务端同样会把 entityData 写回 blockPos/blockState 字段，旧行为未丢。
• 镜像字段无失配：blockPos 现为 entityData 的镜像，仓库内没有任何外部直接赋值（唯二写入点是 :111 的 onSyncedDataUpdated 与字段初值），MagnetUtil:96 的 entity.blockPos 读取仍然有效。

🔎 本轮新增（1 条，post-merge 跟进项，非阻塞）

• 本 PR 是 1.21 线实现的回港（backport parity）：dev/1.21/1.6 的 MagnetizedNodeEntity 本来就已有 setSupport() + onSyncedDataUpdated() 同一套同步代码，且沿用 CapitalCase 键（put("BlockState")/put("BlockPos")）；26.1 的 Port to 26.1 (#3491) 把实体保存键改成了 snake_case，却漏了同步逻辑与调用方读键 —— 本 PR 补齐的正是这两处，属正向对齐，逻辑无需改动。
• ⚠️ 但世界侧实体的读键仍缺 legacy 回退（与同族不对称）：CauldronOutletEntity:338-343 三个键都保留了 or(() -> read("CauldronPos"/"CauldronState"))、getIntOr("attached_direction", getIntOr("AttachedDirection",0))，BuildingEntityTransform/nodeSupport/MagnetizedNodeBuildAdapter:34 也都容忍旧键 —— 唯独本 PR 触及的 MagnetizedNodeEntity.readAdditionalSaveData:116-119 只有新键。后果：1.21 线存档（即 #3491 之前键名）中的已有磁化节点加载后 blockPos=ZERO、blockState=AIR，tick() 首段判定几乎必然成立（除非世界原点恰为空气）⇒ 实体在加载首 tick 自弃；若原点恰是空气，则该节点退化为常驻原点、并把原点附近可吸附物品拽过去的隐形实体。
  修法一行级：compoundTag.read("block_pos",…) → .or(() -> compoundTag.read("BlockPos",…))，block_state 同理（与 outlet 写法一致）。是否属于受支持的升级路径（1.21 存档 → 26.1）请作者判断；现有快照玩家若已在 26.1 线玩过 #3491 之后版本则不受影响。

💡 可选清理（纯提示）

• MagnetizedNodeBuildAdapter.plan:33-34 的 .or(() -> transformedNbt.read("BlockPos", …)) 在 transform() 之后恒不可达（node 必被写入 block_pos）；保留作防御亦可，不必改。

结论：无阻塞项 —— 改动精准（放置侧读键 + 客户端同步各治一个症状），且在 PR 合并前已由本 webhook 出过完整审查；本轮仅补"与 1.21 线对齐"的因果证据与 readAdditionalSaveData 旧键回退这一跟进项。标题无需修改（不做 gh pr edit）。

---

由 Hermes Agent 审查（重复投递识别：head sha 33678f6 / diff md5 12d6f1ae… 与 04:45Z 已发布审查同版）

[Gugle2308]

💾 Self-improvement review: Skill updated · Patched references/attachment-entity-sync-and-scanner-preview.md in skill 'building-rod-blueprint-review' (1 replacement). · Patched references/duplicate-review-detection-and-stop.md in skill 'github-webhook-pr-review' (1 replacement).