Continue porting some new content and bug fixes to 26.1 继续移植部分新内容和bug修复到26.1

[WhereisFff]

No description provided.

[Copilot]

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

[Gugle2308]

代码审查摘要 — PR #5143

操作： opened（webhook）。状态预检：state: open、draft: false（API）→ 正常审查。
范围： 42 文件（22 Java / 14 新增 / 0 删除）/ 1240 行 diff / +593 −11
类型： 跨版本移植（1.21 dev/1.21/1.6 → 26.1），已逐项与源分支对账
CI： head sha 20f9039 = refs/pull/5143/head（非陈旧），build ✅ + checkstyle ✅ 双绿

---

⚠️ 1. new_cycle 的父进度被改挂到隐藏挑战 no_remnant 之下

26.1 侧代码与生成数据是自洽的（mainLine.next() 插主线 → new_cycle.json 已同步为 no_remnant），但源分支 1.21 存在一处 datagen 漂移：

	26.1（本 PR）	1.21 源分支
代码	mainLine.next() → no_remnant（主线）	industrialLine.next() → no_remnant（主线，同语义）
已提交 new_cycle.json	parent: no_remnant ✅ 与代码一致	parent: the_start ❌ 与代码不一致（陈旧）

AdvancementLineHelper.save() 末尾 this.lineHelper.parent = holder（1.21 与 26.1 同）⇒ 任何插在主线的节点都会重定其后继的 parent。所以：

• 26.1 本 PR 顺带修正了源分支遗留的生成数据漂移（好事）；
• 但副作用是 new_cycle 从 the_start 的直接子节点变成隐藏 challenge 的子节点，影响它在进度树中的结构与可见性判定（新玩家需先完成 no_remnant 才在树上看到它）。
• 其余 5 个新节点（efficiency / cannon_fodder / black_hole / neutron_star / come_at_night）都走了 createBranch()，唯独 no_remnant 走主线。

请确认这是期望行为。 若希望 new_cycle 仍挂在 the_start 下，改为 mainLine.createBranch().next() 并重跑 runData（同时修正 1.21 侧的陈旧 new_cycle.json）。

⚠️ 2. planet_contact 的 tag 覆盖不等价于被替换的 minecraft:fall

从 client-1.21.1.jar 的 data/minecraft/tags/damage_type/* 直接读出：minecraft:fall 同时属于
bypasses_armor、bypasses_shield、damages_helmet、is_fall、no_knockback。
本 PR 只补了 is_fall（DamageTypeTagLoader:46 / is_fall.json），据此：

• 护甲值现在会吸收行星接触伤害（PLANET_CONTACT_DAMAGE = 38.0f，全下界合金可减到 ~7.6）——原 damageSources().fall() 无视护甲；
• 现在会施加击退（fall 在 no_knockback 中）；
• 举盾现在可格挡（bypasses_shield），头盔不再掉耐久（damages_helmet）。

佐证：CfaGravityController 里既有注释写的是 // 38 * 0.52 = 19.76 after Feather Falling IV，而星级接触那条写的是「护甲 + 保护 IV」——说明当时的推算并未把 planet_contact 当作可被护甲减免。建议至少补 bypasses_armor 与 no_knockback（1.21 源分支同样缺失，可两分支一起补）。

⚠️ 3. star_contact 缺 no_knockback

被替换的 minecraft:in_fire 属于 no_knockback（且 ignites_armor_stands / panic_environmental_causes），本 PR 只补了 is_fire。恒星接触（STAR_CONTACT_DAMAGE = 66.0f）现在会产生击退。
注：star_contact 不需要补 bypasses_armor（in_fire 不在其中），这部分处理正确。

💡 建议（非阻塞）

• 移植时丢了两条解释性注释，改名后语义不直观，建议补回：ItemSplitterBlockEntity.dropAt 的 // 显式传 0,0,0：5 参数构造器会自带随机动量与向上初速；PlayerHitEntityMixin 的 /// 行星接触伤害原为原版摔落类型，改用专属类型后仍需在此保持相同表现。
• zh_cn / zh_hk / zh_tw / ja 等未补 6 条进度文案 + 3 条死亡信息（death.attack.anvilcraft.{star,planet,black_hole}_contact）——1.21 源分支同样为空，属既有 Weblate 流程，提一句即可。
• 标题：现标题偏笼统，已尝试 gh pr edit，但本环境 token 已失效（HTTP 401: Bad credentials），无法自动修改。建议：Port celestial contact damage types, six stellar-evolution advancements and the quenched_out sound fix to 26.1 移植星体接触伤害类型、6 个恒星演化进度与淬灭序曲音效修复到 26.1
• 备注：ModAdvancementsHandler:780 的 AdvancementHolder theStart 是未使用局部变量，但 base 分支已存在，非本 PR 引入。

---

📋 移植对账表（1.21 da7e856b → 26.1 20f9039）

移植项	状态	证据
4 个 criterion 类	✅ 逐字一致	仅 advancements.critereon → .criterion（26.1 包名）
AdvancementLineHelper 5 个新 helper	✅ 一致	与 1.21 691-709 行逐字相同
6 个新进度 JSON	✅ 逐字一致	唯一差异：26.1 datagen 不再写 icon.count（仓库级既有漂移）
进度文案 en_us/en_ud	✅ 一致	1.21↔26.1 抽取比对完全相同
TriggerUtil 新方法	✅ 一致	半径 32 / 7 与 1.21 相同；32 与 SUPERNOVA_SHAKE_RADIUS = 32.0f 口径吻合（注释属实）
ModDamageTypes	✅ 一致	三个新 key + 构造参数（0.1F/0.0F/BURNING）与 1.21 相同
damage_type JSON	✅ 与 code 自洽	planet_contact 用默认 HURT 故省略 effects；star_contact 写 burning
black_hole_contact tag 镜像	✅ 完整	精确镜像 lost_in_time 原有 4 个 tag（含 neoforge:is_magic），沿用 Float.MAX_VALUE 秒杀
QuenchedOutMusicHandler	✅ 逐字一致	26.1 与 1.21 文件 diff 为空（含 SoundSource.RECORDS、Attenuation.LINEAR）
quenched_out.ogg	✅ 忠实	48kHz 立体声 192kbps → 48kHz 单声道 240kbps，时长 71.767583s 不变，与 1.21 的 ogg md5 完全相同（c48422e1…）⇒ 位置音效正确性修复
sounds.json attenuation 64	✅	与 ModSoundDefinitionsProvider.attenuationDistance(64)、1.21 一致
BuildingUndoResources ghost 判定	✅ 语义等价	!copy.contains("Ghost") || copy.getBoolean("Ghost") ≡ copy.getBooleanOr("Ghost", true)；DynamicBuildingEntities 正是写 Ghost=true, DropItem=false 的一方
ItemSplitterBlockEntity.dropAt	✅ 一致	while+split 与 1.21 相同；唯一调用点传临时栈 resource.toStack(...)，反复 split 无副作用
OverworldLikeEventListener 两个死亡处理器	✅ 逐字一致	1.21 同写法
CelestialForgingAnvilBlockEntity.onDataPacket	✅ 必要修复	base 缺此覆写（getUpdateTag 已有）；与 1.21 的 onDataPacket 对应，也与 26.1 分支既有 8 处 BE 覆写惯例一致

关键正确性核实（非 26.1 迁移项）

• no_remnant 可达性：MinMaxBounds.Ints.exactly(64)；StellarTerminal.massAnvils codec 为 intRange(0, 64)；stellar_tracks.json 存在 mass_64，其 terminal.kind = "disruption"（= Kind.NONE，无残骸）⇒ 与文案 "forged with 64 mass anvils … leave no remnant" 语义一致且可达成。
• 判据正确：completeEvolution 传 evolutionState.initialMass()，而 StellarEvolutionState 校验 track.definition().massAnvils() == initialMass ⇒ 正是「用多少个质量铁砧锻造」；且 completeEvolution 有 terminalApplied() 幂等守卫，不会重复发奖。
• CODEC 字段序 = JSON 键序：player → mass_anvils → terminal，与 1.21 相同；单键产物（{"terminal": …} / {"mass_anvils": 64}）无从错位（codec 序与字母序同向）。
• cannon_fodder 文案 "inside an Overworld-Like planet" 站得住：PLANETARY_COLLAPSE 伤害只在 OverworldLikeResetManager:104 施加。
• 依赖 tag 的既有逻辑未被换类型打断：EquipmentAbilities:276/278（缓冲靴判 IS_FALL/IS_FIRE）与 ItemEntityMixin:144 在新类型下仍生效 —— 这正是补 is_fall/is_fire 的必要性。
• PlayerHitEntityMixin 追加 source.is(ModDamageTypes.PLANET_CONTACT) 必需（换类型后原 fall 判据会失效）。
• diff 完整性：下载 diff +593/−11 与本地 git diff rvbase5143 rvhead5143 完全一致；10 处 No newline 全部是新增生成 JSON，且与仓库既有生成文件惯例一致（既有 new_cycle.json/bypasses_armor.json 末字节同样无换行）。

🧪 测试建议

被测目标	场景	优先级
TriggerUtil.celestialEvolution / planetDetonation	32 格内/外、7 格边界玩家是否发奖；旁观者语义	🔴
CelestialEvolutionTrigger.matches	mass 63 不发 / 64 发；仅 terminal 条件与仅 mass_anvils 条件各自独立生效	🔴
no_remnant 幂等	重复 tick、重载世界后不重复发奖	🟡
new_cycle	父节点变更后代码 award 路径仍可授予；进度树可见性	🟡
planet_contact / star_contact	无护甲 vs 全护甲伤害值对账；击退有无；盾牌格挡；缓冲靴减免	🟡
ItemSplitterBlockEntity.dropAt	投入 1000 个一格 → 实体拆分数量、总量守恒	🟢
BuildingUndoResources.entity	ghost 光谱铁砧 undo/redo 不产出物品、与 DynamicBuildingEntities 成本对称	🟢

结论：COMMENT — 移植忠实度很高（与 1.21 逐项对账基本逐字一致，CI 双绿，无阻塞项）；需处理的是 ⚠️1 的父节点变更确认（连同 1.21 侧陈旧生成数据）、⚠️2/3 的伤害类型 tag 覆盖缺口，其余为可选改进。

---

由 Hermes Agent 审查

[Gugle2308]

代码审查摘要 — PR #5143

操作: review_requested（PR 仍 open，非 merged；head 20f9039e = refs/pull/5143/head，base 216c5430 = 当前 dev/26.1/1.6）
范围: 42 个文件（22 Java / 14 新增 / 0 删除），1240 行 diff（+593 / −11）
CI: build + checkstyle 两项 check 均 success（因此本轮不报编译/风格/行长/import 顺序类问题）
diff 完整性: 本地 git diff rvbase5143 rvhead5143 与 patch-diff 版本逐文件、逐计数一致（+593/−11，无截断、无 ghost 文件）

这是 4 个源 PR 的 26.1 移植合并：#5129（天体进度+专属伤害类型）、#5131/#5132（演化音效衰减+界面恢复）、#5134（幻灵铁砧虚影撤销）、#5136（物品分配器掉落堆叠上限）。用匿名 curl 取源 PR 差异做了提交级对账（patch-diff 5129/5134/5136 可下载；5131 该端点返回 HTML，改用 1.21 分支 dev/1.21/1.6 的落地状态核对）。

📋 移植完整性对账

源	文件数	对应 26.1 文件	状态
#5129	34	34（AnvilCraftAdvancement → ModAdvancementsHandler，4 个 *Trigger、AdvancementLineHelper、TriggerUtil、ModCriterionTriggers、ModDamageTypes、DamageTypeTagLoader、OverworldLikeEventListener、CfaGravityController、AcceleratorHandler、ExcavatorHandler、PlayerHitEntityMixin、AdvancementLang、OtherLang、17 个生成数据）	✅ 全部覆盖
#5131/#5132	5	QuenchedOutMusicHandler、ModSoundDefinitionsProvider、sounds.json、quenched_out.ogg、CelestialForgingAnvilBlockEntity	⚠️ 见下（缺 handleUpdateTag 侧）
#5134	1	BuildingUndoResources	✅ 逻辑等价
#5136	1	ItemSplitterBlockEntity	✅ 逻辑等价
额外	1	new_cycle.json（26.1 链序需要，见 🟢）	✅ 必要且正确

文件集差集核对：没有源 PR 文件缺失（AnvilCraftAdvancement → ModAdvancementsHandler 是 26.1 侧改名）。

⚠️ 警告

1. CelestialForgingAnvilBlockEntity#onDataPacket（1267 行）在 26.1 上是可证的行为等价空操作，并不能实现提交信息声称的“实时同步入口恢复锻造状态”
   • 26.1 NeoForge 把这两个方法都做成了 IBlockEntityExtension 的 default，且默认体完全相同（从 userdev.jar 的 IBlockEntityExtension.java 读出）：

     default void onDataPacket(Connection net, ValueInput valueInput) { self().loadWithComponents(valueInput); }
     default void handleUpdateTag(ValueInput input)                   { self().loadWithComponents(input); }

   • 26.1 的 CelestialForgingAnvilBlockEntity 没有覆写 handleUpdateTag（全仓只有 StructureScannerBlockEntity 覆写，且是 super.handleUpdateTag(input) 空转），所以 onDataPacket → this.handleUpdateTag(input) 与不写这个覆写走的是同一条 loadWithComponents → loadAdditional。
   • 1.21 侧这次修复是两半：onDataPacket → handleUpdateTag 加上 handleUpdateTag 覆写（searchController.loadSynced(...) + megastructureManager.readUpdateTag(...)；1.21 的 loadAdditional 走的是 loadPersistent(...)，对同步包会命中“没有种子键 ⇒ stop”分支从而清掉正在搜索/锻造的状态）。26.1 只搬了第一半。
   • 而 26.1 侧症状本就不存在：26.1 的 CfaSearchController.load(4 个布尔) 的函数体恰好就是 1.21 的 loadSynced（四个标志 + 清 capturedSeed 字段，无种子分支），且 loadAdditional 调用的就是它；26.1 的 megastructureManager.readUpdateTag / handler.readUpdateTag（含 AcceleratorHandler.readUpdateTag）至今零调用者。基类注释也明写“客户端经 loadAdditional 读取”。
   • 结论/建议（请作者确认）：要么删掉这个覆写（与 SpacetimeSupercomputer/PowerConverter 一样按需走 loadAdditional 即可），要么如果 26.1 侧确实复现了“重开界面丢进度”，那缺的是 26.1 版的 handleUpdateTag(ValueInput) 覆写（把 readUpdateTag 接上），当前这一半不起作用。不属于阻塞项，但提交信息与实际行为不符，容易让后续维护者误判。

💡 建议

• 移植时丢掉的解释性注释建议补回（26.1 与 1.21 逐字相同只除注释）：PlayerHitEntityMixin 的「行星接触伤害原为原版摔落类型，改用专属类型后仍需在此保持相同表现」、ModDamageTypes 的「天体接触伤害沿用被替换的原版伤害表现（恒星=燃烧、行星=摔落），只换死亡提示」、ItemSplitterBlockEntity#dropAt 的「显式传 0,0,0：5 参数构造器会自带随机动量与向上初速」。这三处正是“为什么这么写”的关键。
• zh_cn 未补：3 条 death.attack.anvilcraft.{star_contact,planet_contact,black_hole_contact} 与 6 个新进度的键在 zh_cn.json 中缺失（现为 6 条死亡提示 / 134 条进度）。1.21 侧同样缺失 ⇒ 上游一致，非本 PR 独有；若该文件是人工维护而非等 Weblate，建议一并补上，否则中文玩家会看到英文原文。
• 给 1.21 线的提醒（非本 PR 问题）：1.21 分支的生成物 new_cycle.json 仍是 parent: the_start，而 1.21 的 datagen 代码在 no_remnant 之后接 new_cycle（应为 no_remnant）⇒ 那边存在 datagen ↔ 生成数据漂移；本 PR 的 26.1 侧已正确同步（见 🟢）。

🟢 看起来不错（关键证据）

• 音效听距三件套齐全且与 1.21 逐字节相同：quenched_out.ogg md5 与 1.21 侧一致，channels 2 → 1（48 kHz，时长 71.77s 保持不变、页数 397→74），sounds.json 条目加 attenuation_distance: 64（26.1 生成物与 1.21 完全相同），provider 同步加 .attenuationDistance(64)；SoundSource.MUSIC → RECORDS 只影响音量分类，Attenuation.LINEAR 原本就在 ⇒ 64 格原生线性衰减、字幕听距与音效一致。这是本次修复真正生效的那一半。
• 生成数据与 datagen 代码自洽（重点核查）：efficiency/cannon_fodder/black_hole/neutron_star/come_at_night 五个 createBranch() 节点 parent 全为 the_start；no_remnant 用 mainLine.next()（parent=the_start）；紧随其后的 new_cycle 因 save() 会重定后继 parent 而改为 parent: no_remnant——且 new_cycle.json 确实在 diff 里被同步更新（旧 next()/createBranch() 陷阱已避开）。frame/hidden 与 display(...) 重载一一对应（task 无 frame、hidden=false 不写 hidden）。26.1 全仓生成进度统一不写 "count": 1（base/head 均 0 处，1.21 有 73 处）⇒ 新 JSON 的 icon 形态与 26.1 datagen 惯例一致，不是手写漂移。
• criterion 与 JSON 逐字段对得上：TriggerInstance record 字段序 player → mass_anvils → terminal、键名与生成 JSON 一致；注册 id celestial_evolution / planet_detonation / planetary_collapse_death / star_contact_death 与 6 个 JSON 的 trigger 一一匹配；StellarTerminal.Kind.CODEC 的字符串 black_hole/neutron_star 与条件值一致；与 1.21 版 Trigger 类除包名（criterion vs critereon）外逐字相同。
• 阈值可达性已复核：no_remnant 用 MinMaxBounds.Ints.exactly(64)，initialMass 即轨道 massAnvils（Codec.intRange(41,64)，库强制存在 mass_41..mass_64 共 24 条）；stellar_tracks.json 中只有 mass_64 的 terminal 是 disruption（无残骸），其余为 white_dwarf×14 / neutron_star×3 / black_hole×5 ⇒ massAnvils==64 与该进度的语义精确等价，可达成；black_hole/neutron_star 按 terminal kind 判定同样可达。
• 伤害类型替换的“表现不变”承诺有据：star_contact/planet_contact/black_hole_contact 的注册参数与生成的 damage_type/*.json（effects/scaling/exhaustion）互相对得上；标签覆盖完整（bypasses_armor/resistance/no_knockback/is_magic + is_fire + 新增 is_fall）；旧依赖原版类型的特判都补回了——EquipmentAbilities 的缓冲靴走 DamageTypeTags.IS_FALL（tag 已加）、PlayerHitEntityMixin 显式补 source.is(ModDamageTypes.PLANET_CONTACT)；黑色黑洞类型仍带 lost_in_time 原有的四个 tag。planetary_collapse 只由 OverworldLikeResetManager 施加 ⇒ cannon_fodder 描述里的“inside an Overworld-Like planet”成立。
• 触发点语义：completeEvolution 有 terminalApplied() 幂等守卫 + evolutionTrack == null 早退，重复 tick/保存恢复不会重复发奖；celestialEvolution 的 32 格半径、planetDetonation 的 7 格半径与 1.21 完全相同且有注释说明（对齐震屏半径）；死亡触发只针对当事玩家（不走位置搜索）。
• 另外两处 bug 修复移植等价：ItemSplitterBlockEntity#dropAt 的 while (!stack.isEmpty()) { stack.split(getMaxStackSize()) } 保留 0 动量、setDefaultPickUpDelay()、余数，且唯一调用点传的是 resource.toStack(extracted) 临时栈（无“被 split 后再复用”隐患）；BuildingUndoResources 的 copy.getBooleanOr("Ghost", true) 与 1.21 的 !contains("Ghost") || getBoolean("Ghost") 等价，且与 FallingSpectralBlockEntity 自身的写入键 "Ghost"/加载默认值 true 一致（判定无掉落幻灵铁砧不再返还基础物品）。
• 语言侧：AdvancementLang/OtherLang 新文案与 1.21 逐字相同，en_us/en_ud 生成物的新键也逐字相同。

🧪 测试建议

仓库内这些子系统无单测（不虚构测试文件），建议手动验收：

目标	场景	优先级
CelestialForgingAnvilBlockEntity 同步	锻造/搜索进行中反复开关界面、跨区块重载、重登：client 进度条与 stage 不应丢失；对照 1.21 侧现象确认是否真的需要 handleUpdateTag	🟡
no_remnant 可达性	用 64 质量铁砧天体演化到 disruption 终局 → 发奖；mass_41..63 不发	🔴
black_hole/neutron_star	对应 terminal 轨道完成演化即发奖；white_dwarf 不发	🟡
cannon_fodder/come_at_night	行星崩解致死 / 恒星接触致死发奖；其它死亡源不发	🟡
efficiency	伽马激光打入行星挖掘机（7 格内玩家）发奖	🟡
新伤害类型	被恒星/行星/黑洞接触致死的死亡提示；护甲/抗性/击退/魔法标签行为；摔落保护与缓冲靴对 planet_contact 仍生效	🟡
quenched_out 音效	音量滑块归“唱片/音符盒”分类；64 格内可闻、字幕同步出现	🟢
物品分配器	单目标位置掉落超过堆叠上限时按 maxStackSize 拆分，余数/零动量/拾取延迟保持	🟡

结论: COMMENT（非阻塞） — 移植保真度很高（源 PR 文件零缺失、生成数据与 datagen 自洽、音效 ogg 与 1.21 逐字节一致、CI 双绿），未发现需修复后合并的阻塞项；唯一实质点是 onDataPacket 覆写在 26.1 上可证等价于默认实现、与提交信息声称的修复不符，请作者确认是删除还是补上 26.1 的 handleUpdateTag 侧。

说明：本轮未修改 PR 标题——标题“Continue porting some new content and bug fixes to 26.1 继续移植部分新内容和bug修复到26.1”格式与语义已达要求（英文+中文）；且本机 gh auth status 显示 token 已失效（The token in …/hosts.yml is invalid），按流程不导出 GITHUB_TOKEN 修复，故未执行 gh pr edit。若希望标题更具体，建议：Port celestial advancements, damage types, sound fix and bug fixes to 26.1 移植天体进度、专属伤害类型、音效修复及若干 bug 修复到 26.1。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'advancement-criterion-pr-review' (1 replacement).

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'minecraft-modding' (1 replacement). · Patched SKILL.md in skill 'advancement-criterion-pr-review' (1 replacement). · Patched references/port-form-and-damage-type-swap-audit.md in skill 'advancement-criterion-pr-review' (1 replacement).

[Copilot]

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

[Gugle2308]

PR #5143 触发的 action 是 closed，按约束第 1 条：停止审查，不发布评论。

（已确认状态：该 PR 已被合并，squash 提交 d30d52e，6 commits 进入 dev/26.1/1.6；变更已落库，无需审查动作。）

[Gugle2308]

⚠️ Dangerous command requires approval:

cd /opt/data/workspace/AnvilCraft && git show rvhead5143:src/main/resources/data/anvilcraft/stellar_tracks.json | python3 -c "import sys,json; d=json.load(sys.stdin); print(type(d)); print(json.dumps(...

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]

All evidence gathered. Here is my review (auto-delivered to the PR):

---

代码审查摘要 — PR #5143（第 3 轮 · synchronize 复审）

操作： synchronize（载荷为 review_requested）。状态预检：state: open、merged: false、draft: false。
head 前移： 上两轮审查的 head 为 20f9039e（42 文件），现 head 92e56f4d8 —— 会话间作者又推了 2 个提交（#5141 大红按钮、#5140 仓储端口），范围 42 → 47 文件。
范围： 47 文件（27 Java / 14 新增 / 33 修改 / 0 删除），+717 −42；6 个提交。
CI： head 92e56f4d 的 build ✅ + checkstyle ✅（双绿 ⇒ 本轮不报编译/风格/行长/import 顺序类问题）。
diff 完整性： 本地 git diff rvbase5143 rvhead5143 与 patch-diff 版本逐文件逐计数一致（47 / +717 / −42），API changed_files=47 吻合，无截断、无 ghost。

🔁 与上一轮相比（增量只涉及 5 个文件）

新增提交已归因：git diff --stat 20f9039e 92e56f4d8 = 5 文件 / +74 −31，恰好是 BigRedButtonBlockEntity、BigRedButtonInputListener、BigRedButtonHoldPacket、StoragePortBlock、StorageFluidPortBlock。上轮被标记的文件 blob 全部未变，故上轮结论逐条复验如下：

上轮问题	复验（head 92e56f4d）	证据
⚠️ new_cycle 父进度被改挂到隐藏挑战 no_remnant	❌ 仍未处理（语义确认题）	两侧 blob 未变；26.1 侧 datagen 代码 ↔ 生成数据仍自洽
⚠️ planet_contact tag 覆盖不等价	❌ 仍未处理（并对上轮结论作一处更正，见下）	planet_contact 仍只进 is_fall.json
⚠️ star_contact 缺 no_knockback	❌ 仍未处理	star_contact 仍只进 is_fire.json
⚠️ onDataPacket 在 26.1 等价于默认实现	❌ 仍未处理	blob 未变
🟢 若干（criterion、JSON、ogg、生成数据自洽…）	✅ 仍成立	相关 blob 未变

⚠️ 对上次意见的更正：minecraft:fall 的 tag 集合

上轮（第 1 轮）称 minecraft:fall 同时属于 bypasses_armor、bypasses_shield、damages_helmet、is_fall、no_knockback。本轮用本地 client-1.21.1.jar 的 data/minecraft/tags/damage_type/*.json 逐文件复算，应更正为：

minecraft:fall        -> bypasses_armor, is_fall, no_knockback      (无 damages_helmet)
bypasses_shield       -> ["#minecraft:bypasses_armor", minecraft:falling_anvil, minecraft:falling_stalactite]
damages_helmet        -> [falling_anvil, falling_block, falling_stalactite]
minecraft:in_fire     -> ignites_armor_stands, is_fire, no_knockback, panic_environmental_causes

• damages_helmet 只列三个下落方块类型，fall 不在其中 ⇒ 上轮「建议补 damages_helmet」属误报，撤回。
• bypasses_shield 里含 #minecraft:bypasses_armor（tag 引用）⇒ 只要把 planet_contact 加进 bypasses_armor，bypasses_shield 自动传递覆盖，无需单独补。
• 因此 planet_contact 的真实缺口只有两处：bypasses_armor + no_knockback（DamageTypeTagLoader 里目前只加了 IS_FALL）。后果仍是：38.0f 的行星接触伤害开始被护甲吸收、且开始造成击退（CfaGravityController 既有注释 // 38 * 0.52 = 19.76 after Feather Falling IV 也说明当时并未按"可被护甲减免"推算）。
• star_contact（替换 in_fire）在 no_knockback 上的缺口照旧成立；ignites_armor_stands / panic_environmental_causes 属细节，可选。
• 1.21 源分支同样只补了 is_fall/is_fire ⇒ 两侧一起修即可，不是移植漏搬。

🆕 本轮新增提交审查

A. fix(button) (#5141) — BigRedButtonBlockEntity / BigRedButtonInputListener / BigRedButtonHoldPacket：移植忠实 ✅

• 与上游 1.21 PR Fix big red button targeting and animation 修复大红按钮目标判定与按压动画 #5141 的 diff 逐行等价，仅 4 处为版本适配：level.isClientSide 字段 → isClientSide()；包路径 block.utility.redstone；PacketDistributor → ClientPacketDistributor；Player#canInteractWithBlock → isWithinBlockInteractionRange（26.1 改名，且 base 本来就用后者）。
• press(Player) 改为返回 boolean：唯一旧调用点 BigRedButtonBlock.useWithoutItem:128 忽略返回值 ⇒ 行为不变 ✅。
• 反作弊确有加强：服务端不再对"按钮中心固定点"射线，而是拿客户端上报的 hitLocation 重新 clip() 并校验落点在方块 AABB 内（inflate(1e-5) 正确规避了 AABB.contains 上界半开区间导致的"面命中恰在 x=pos+1 被拒"）。
• holdId / confirmed 握手自洽：release() 先发包、后自增 holdId ⇒ 释放回包必被 id != holdId 丢弃；confirmed 只由服务端回包置位；动画门还额外读客户端 BIG_RED_BUTTON.PRESSED ⇒ 即使 onUse 切换方块时未重置 confirmed，也不会误播动画（✅ 无陈旧状态问题）。
• 双向包 ISensitiveBiPacket（服务端回发同 record 给发起玩家）是仓库既有模式：ControlValveFilterPacket 等 8+ 个 packet 同型，且既有实现已在 handleOnClient 里直接用 Minecraft / 客户端 Screen 类 ⇒ 通用 packet 中 import 并调用客户端类 BigRedButtonInputListener 安全（客户端方法只在客户端侧派发，且法默为惰性解析）。ISensitiveBiPacket / StreamCodecUtil.VEC3 / Util.cast 在 head 树内均有多处既有使用，无编译风险。
• 💡 handleHoldResult(pos, id, accepted) 的第 3 参语义已是"服务端是否受理"，但线上字段仍名为 held（BigRedButtonHoldPacket#held）；建议改名或加一行注释，免得后人把"客户端按住"与"服务端受理"混淆。
• 💡 释放包用 Vec3.ZERO 作哨兵：canPress 只在 held==true 进入，无副作用；建议注释一句。

B. fix(storage-port) (#5140) — StoragePortBlock / StorageFluidPortBlock

• 机械事实：base 为 level instanceof Level realLevel && realLevel.getBlockEntity(pos) instanceof …Port && includeData（includeData 在最后）；head 把 includeData 提到最前 ⇒ 布尔结果不变，唯一差异是 includeData==false 时不再执行 level.getBlockEntity(pos)（跳过 BE/区块访问）。这与提交信息一致。
• 与上游 Fix storage port server-side scanning crash 修复服务端扫描仓储端口时崩溃 #5140 对比：上游是在 getBlockEntity 之前插入 realLevel.isClientSide —— 1.21 的签名没有 includeData，判定用的是客户端专属类 Screen.hasControlDown()，服务端求值会 NoClassDefFoundError，这才是上游那次崩溃的根因。26.1 已把该判定收编成 includeData 参数 ⇒ 本移植用 includeData 前置替代上游的 isClientSide，方向正确且更贴合 26.1 API。26.1 不补 isClientSide 意味着服务端在 includeData==true（玩家带 Ctrl 中键拾取）时仍会写入端口数据 —— 这正是服务端把带数据物品放进背包所必需的，可接受 ✅。
• 仓库惯例佐证（正是本次修复的机制）：StorageBlockEntity.applyPickStorageId（CrateBlock/LargeCrateBlock/ShulkerContainerBlock/HyperdimensionStorageStationBlock 四个方块共用）第一行就是 if (!includeData) return;；LargeFluidTankBlock#getCloneItemStack 同样先 if (!includeData) return stack;。两个端口方块此前是唯一把 includeData 放最后的例外 ⇒ 改动与仓库既有约定对齐 ✅。
• ⚠️（低）建议对齐兄弟惯例再补 hasChunk 守卫：applyPickStorageId 在 getBlockEntity 之前还有 level.hasChunk(x>>4, z>>4)，而本 PR 的两个 override 只前置了 includeData。若 Fix storage port server-side scanning crash 修复服务端扫描仓储端口时崩溃 #5140 的崩溃源于"未加载区块上的 getBlockEntity"（Level.getBlockEntity 会走到 getChunkAt），仅前置 includeData 只能覆盖 includeData==false 的路径；建议按 applyPickStorageId 补一行 realLevel.hasChunk(...)，零行为变化、覆盖 includeData==true 的情形。
• 💡 新增注释「避免服务端拾取或扫描读取客户端按键状态」是 1.21 的成因描述；26.1 侧没有客户端类按键读取，真实收益是"includeData==false 时不再触碰 BE"。建议按 26.1 事实改写，否则后人照注释理解会走偏。

📋 移植对账表（6 提交 → 26.1）

源 PR	对应 26.1 文件	状态
#5129 天体进度 + 专属伤害类型	34（4 个 *Trigger、AdvancementLineHelper、TriggerUtil、ModCriterionTriggers、ModDamageTypes、DamageTypeTagLoader、OverworldLikeEventListener、CfaGravityController、AcceleratorHandler、ExcavatorHandler、PlayerHitEntityMixin、AdvancementLang、OtherLang + 17 生成物）	✅ 覆盖（tag 缺口见上）
#5131/#5132 演化音效 + 界面恢复	5	✅ 音效半已生效；onDataPacket 半在 26.1 等价空操作（上轮 ⚠️ 沿袭）
#5134 幻灵铁砧虚影撤销	1	✅ 等价（blob 未变）
#5136 物品分配器掉落堆叠上限	1	✅ 等价（blob 未变）
#5141 大红按钮遮挡边缘交互与按压动画	3	✅ 逐行等价（本轮新审）
#5140 服务端扫描仓储端口崩溃	2	✅ 机械等价 + ⚠️ 建议补 hasChunk

本轮复核仍成立的关键证据（相关 blob 未变）：4 个 criterion 类与 1.21 逐字一致（仅包名 critereon→criterion）；6 个新进度 JSON 与 1.21 逐字一致（唯一差异是 26.1 datagen 不再写 icon.count）；black_hole_contact 精确镜像 lost_in_time 的 4 个 tag（bypasses_armor/bypasses_resistance/no_knockback/neoforge:is_magic）；quenched_out.ogg 与 1.21 md5 相同。

🧪 测试建议

目标	场景	优先级
大红按钮	底座中心被遮挡但按钮面可见时可按下；按住/松开动画仅在服务端受理后播放；服务端拒绝（潜行/建筑手杖/超距）时无动画；跨维度/开界面自动释放；伪造 hitLocation（界外/NaN）被服务端拒	🔴
仓储端口	服务端扫描/拾取端口不再崩溃；Ctrl 中键拾取仍带缓存/标记/流体；未加载区块上调用不崩	🔴
planet_contact/star_contact	补 tag 后无护甲 vs 全护甲伤害对账、击退有无、缓冲靴减免	🟡
no_remnant / black_hole / neutron_star	64 质量铁砧发奖、mass_41..63 不发；对应 terminal 发奖	🟡

结论: COMMENT（非阻塞）

本轮新增的 2 个提交（#5141、#5140）移植忠实、CI 双绿，未引入阻塞项。沿袭的上轮 4 项 ⚠️ 仍未处理，其中 planet_contact 的 tag 建议按上面的更正后版本修（bypasses_armor + no_knockback，不要再补 damages_helmet）。new_cycle 挂到隐藏挑战下、以及 onDataPacket 在 26.1 是空操作——这两条请作者各给一句确认即可，不必阻塞。

标题： 现标题 Continue porting some new content and bug fixes to 26.1 继续移植部分新内容和bug修复到26.1 已满足「英文 + 中文」约束，故本轮未修改（且本机 gh auth status 显示 token 已失效，按流程不导出凭据修复）。若希望更具体，可选：Port stellar advancements, contact damage types, sound fix and button/storage-port fixes to 26.1 移植天体进度、接触伤害类型、音效修复及按钮/仓储端口修复到 26.1。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched references/port-form-and-damage-type-swap-audit.md in skill 'advancement-criterion-pr-review' (1 replacement). · Patched SKILL.md in skill 'advancement-criterion-pr-review' (1 replacement). · Patched SKILL.md in skill 'anvilcraft-storage-system-review' (1 replacement).

[Gugle2308]

⚠️ Dangerous command requires approval:

cd /opt/data/workspace && ls -la pr5143_*.py | head; echo "=== /tmp/c5143.json? ==="; ls -la /tmp/c5143*.json /tmp/c5143* 2>/dev/null | head; echo "=== unzip? ==="; which unzip jar javap python3; echo...

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 已合并，且合入内容与上一轮已审查的 head 完全一致）。以下是投递到 PR 评论区的内容：

---

代码审查摘要 — PR #5143（synchronize · 事件送达时 PR 已合并）

状态预检（唯一权威判据）： 该 PR 已合并 —— merged_at: 2026-10-03T03:34:22Z，squash 提交 d30d52e80，dev/26.1/1.6 由 216c54300 → d30d52e80（提交信息即 PR 标题）。本次 webhook 载荷的 head 92e56f4d8 是合并前的旧事件，且该 head 已在上一轮（03:38Z）完整审查过；故本轮只做落库核对 + 增量（post-merge）观察，不重复整份审查。

落库核对： git diff 92e56f4d8 d30d52e80 = 空（树完全一致）；git diff 216c54300 d30d52e80 --stat = 47 文件 / +717 −42，与 PR changed_files=47 吻合 ⇒ 合入内容 = 已审查内容，无"合并前修复"环节。

⚠️ 可选后续（非阻塞；已改用 26.1 原生数据复核，比上一轮的 1.21.1 参照更硬）

1. 伤害标签等价性两处缺口（新类型未完全继承被替换的原版类型标签）——26.1 client jar 实测：minecraft:fall ∈ {bypasses_armor, is_fall, no_knockback}，minecraft:in_fire ∈ {is_fire, no_knockback, ignites_armor_stands, panic_environmental_causes}。
   • planet_contact 只补了 is_fall ⇒ 护甲现在会吸收行星接触伤害（38.0 伤 → 全下界合金约 7.6），与 CfaGravityController 自己的注释 // 38 * 0.52 = 19.76 after Feather Falling IV（只计摔落保护、未计护甲系数）不符；同时不再免击退。
   • star_contact 只补了 is_fire，缺 no_knockback（66 * 0.84 * 0.36 的注释与 in_fire 语义一致，护甲/保护生效那一半是对的）。
   • black_hole_contact ✅ 与原 lost_in_time 标签集完全一致，属等价替换。
2. new_cycle 的 parent 由 the_start 变为 no_remnant（datagen 侧 mainLine.next() 所致，生成数据已同步 ⇒ 自洽，且顺带修掉 1.21 侧的陈旧生成物）。副作用是它成为隐藏 challenge 的子节点；若不想动树干，改 mainLine.createBranch().next() 并重跑 runData。
3. CelestialForgingAnvilBlockEntity#onDataPacket（1267 行）确认为半份移植：NeoForge 26.1 IBlockEntityExtension 的默认体（自 nf-src.jar 读出）两个方法完全相同——default void onDataPacket(...) { self().loadWithComponents(valueInput); } / default void handleUpdateTag(ValueInput input) { self().loadWithComponents(input); }；而 26.1 的 CFA 未覆写 handleUpdateTag（全仓仅 StructureScannerBlockEntity 覆写，且是空转）⇒ 该覆写与不写等价。要么删除，要么补上 26.1 版 handleUpdateTag(ValueInput)（接 readUpdateTag）。
4. 移植丢掉 3 处解释性注释（PlayerHitEntityMixin「行星接触伤害原为原版摔落类型…」、ModDamageTypes、ItemSplitterBlockEntity#dropAt「显式传 0,0,0…」）；zh_cn 缺 3 条死亡提示 + 6 个新进度键（1.21 侧同缺，非本 PR 独有）。

🟢 本轮独立复核通过

• 47 文件 / +717 −42，无 ghost、无截断；mass_64 是 stellar_tracks.json 中唯一 terminal=disruption 的轨道 ⇒ no_remnant 的 exactly(64) 与"无残骸"语义精确等价、可达成。
• 6 个新进度 JSON ↔ datagen（parent / frame / hidden / requirements / trigger id / StellarTerminal.Kind.CODEC 取值）逐项对得上；4 个 criterion 类与 1.21 源除包名（criterion vs critereon）外逐字相同。
• 音效三件套与 1.21 逐字节相同（sounds.json 的 attenuation_distance: 64 + provider .attenuationDistance(64) + SoundSource.RECORDS，Attenuation.LINEAR 原本就在）⇒ 64 格线性衰减、字幕听距同步。
• 本轮新增的 5 个文件（大红按钮 Fix big red button targeting and animation 修复大红按钮目标判定与按压动画 #5141、仓储端口 Fix storage port server-side scanning crash 修复服务端扫描仓储端口时崩溃 #5140）与 1.21 逐行等价：仅 API 改名（canInteractWithBlock → isWithinBlockInteractionRange、ClientPacketDistributor、MouseButtonEvent/getKeyEvent）；press 改返回 boolean 的唯一外部调用点 BigRedButtonBlock:128 忽略返回值 ⇒ 源兼容；hit 校验反而更严（AABB±1e-5 + 同方块 raycast）；Storage*PortBlock 仅调整 && 短路顺序 + 注释，语义不变。
• 触发点语义：completeEvolution 有 terminalApplied() 幂等守卫；celestialEvolution 32 格 / planetDetonation 7 格半径与 1.21 完全一致；死亡触发仅针对当事玩家。

🧪 post-merge 建议验收（可选，供后续 PR）

目标	场景
伤害标签	行星/恒星接触伤害在穿护甲 vs 裸装下的差值；受击是否被击退
6 个新进度	mass_64→disruption 发奖、mass_41..63 不发；black_hole/neutron_star 仅对应 terminal 发奖
CFA 同步	锻造/搜索进行中反复开关界面 + 跨区块重载：客户端进度是否丢失（判定是否需要补 handleUpdateTag 侧）
物品分配器	单点掉落超过堆叠上限时按 maxStackSize 拆分，余数留内部、零动量与拾取延迟保持

结论：COMMENT（post-merge，无需动作） — 变更已落库且与上轮审查 head 完全一致，无阻塞项；上述 1–3 项为可选后续。PR 已合并，故未修改标题（标题英文+中文格式已达标；另本机 gh auth status 显示 token 已失效，按流程不导出 GITHUB_TOKEN）。

---

由 Hermes Agent 审查

---

本次执行说明（不随评论投递）

• action=synchronize，非 closed/labeled，故按流程输出审查；但状态预检发现 PR 已于 03:34:22Z 合并（squash d30d52e80），且载荷 head 92e56f4d8 与上一轮已审查的 head 完全相同（git diff 两 ref 为空），因此采用"落库核对 + post-merge 增量"而非重发整份审查。
• 全过程只用 terminal + curl 公开端点（patch-diff、匿名 API、git fetch 到具名 ref），未使用 execute_code，未执行任何 gh pr review/comment，未 source .env / export GITHUB_TOKEN。
• 唯一一次 gh auth status 确认 token 失效（hosts.yml invalid），故跳过 gh pr edit。

[Gugle2308]

💾 Self-improvement review: Patched references/head-sha-freshness-and-prior-review-verification.md in skill 'github-webhook-pr-review' (1 replacement). · Patched references/port-form-and-damage-type-swap-audit.md in skill 'advancement-criterion-pr-review' (1 replacement).