Fix Stellar Evolution Accelerator crashing on complete 修复恒星演化加速器完成演化后崩溃的问题

[PopSlime]

Fixes #4684

[Gugle2308]

⚠️ Dangerous command requires approval:

curl -sL "https://api.github.com/repos/Anvil-Dev/AnvilCraft/issues/4684" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('body','')[:3000])" 2>/dev/null || curl -sL "https://api.git...

Reason: Security scan — [HIGH] Pipe to interpreter: curl | python3: Command pipes output from 'curl' directly to interpreter 'python3'. Downloaded content will be executed without inspection.
Safer: tirith run https://api.github.com/repos/Anvil-Dev/AnvilCraft/issues/4684 — or: vet https://api.github.com/repos/Anvil-Dev/AnvilCraft/issues/4684 (https://getvet.sh); 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]

崩溃日志直接命中修复行（update 上的 NPE，行号 449 即完整后置空后的解引用行）——修复精确命中根因。

关于 PR 标题：Fix Stellar Evolution Accelerator crashing on complete（无中文）已准确，无需 gh pr edit。

---

代码审查摘要 — PR #4687

操作: opened
范围: 1 个文件 (1 Java, 0 新增, 0 删除) / 17 行 diff

🎯 修复验证（对照 issue #4684 崩溃日志）

mclo.gs 日志确认崩溃根因正是修复的这行：

NullPointerException: Cannot invoke "StellarEvolutionState.update(long, StellarTrack)"
because "this.evolutionState" is null
    at AcceleratorHandler.serverTick(AcceleratorHandler.java:449)

serverTick 中 completeEvolution() → finishAccelerator() 会把 evolutionState 与 evolutionTrack 全部置 null（本文件 707-708 行），随后同一 tick 的第 449 行仍无条件调用 evolutionState.update(...) → NPE。这正是恒星演化状态机重构（#4667）的终局清理后同 tick 解引用已知模式。

🔴 关键问题

无。修复正确且完整：

• else 分支正确 — 完成路径 completeEvolution → markTerminalApplied + finishAccelerator 重置内部状态为 0，无需再 update()；未完成路径正常推进并同步。
• shouldTriggerShock 在同 tick 前置调用安全 — 其内部（含 triggerEventShock）均有 evolutionState == null 守卫，且只在未完成时触发，不会先置空。
• 置空后不会"复活" — ensureState() 仅在 pendingLegacyTag != null 时重建状态；而 finishAccelerator 已将 pendingLegacyTag = null，后续 tick 的 ensureState 直接 return，evolutionState 保持 null → 下一 tick 在 serverTick 第 415 行 if (evolutionState == null || evolutionTrack == null) return; 提前退出，不会二次进入完成路径。

⚠️ 警告

• AcceleratorHandler.java:449 — completeEvolution() 在 if 内完成后，update() 与后续 syncToClient 被 else 包住。注意 completeEvolution 自身末尾已调用 syncToClient(be)，else 分支不会导致完成那 tick 漏同步（旧代码的 update 在 complete 后即便执行也会因 isComplete() 短路返回 false，gameTime % 20 == 0 才会触发一次 sync，而 complete 已 sync 过）——行为正确，无回归。

💡 建议（非阻塞）

• 可考虑在 serverTick 开头（现有 if (evolutionState == null...) return; 之后）把这段改成结构化守卫，例如在完成分支后加 return; 替代 else 包裹——两种写法均正确，当前 else 风格与"先判 complete 再 update"的线性语义略有错位，但可读性无碍。
• 追溯同类模式：同文件 onClear（819 行附近）与 loadAdditional/readUpdateTag 也置空 evolutionState，但均在非 tick 路径且调用方均有判空，无同类 NPE 风险。update() 内部对 isComplete() 有短路，若未来在别处复用完成路径，建议同样警惕"置空后同方法继续解引用"。

🟢 看起来不错

• 改动最小化（17 行中仅 3 行有效变更），精准针对崩溃日志第 449 行。
• finishAccelerator 重置后 pendingLegacyTag = null 防止状态机意外重建，修复无副作用。
• 与 issue [Bug] 锻星砧恒星演化爆炸动画结束后会崩溃 #4684 的复现（爆炸动画结束后、snapshot.2230）时间线吻合——该版本正处于 Refactor stellar acceleration‑evolution and add Void Planet dimension重做恒星加速演化系统并新增虚空星球维度以供开发者测试 #4667 重构落地期。

📋 声称验证表

声称	状态	对应证据
修复恒星演化加速器完成演化后崩溃	✅	else 包裹避免置空后同 tick 解引用 NPE；崩溃日志行号精确命中

结论: APPROVE — 修复精确命中 issue #4684 崩溃根因（完成演化后 evolutionState 置空，同 tick update() 解引用 NPE），else 分支 + finishAccelerator 清空 pendingLegacyTag 保证后续 tick 提前返回，无回归、无残留 NPE 路径。修复建议合并。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'state-machine-phase-rollover-review' (1 replacement).

[Gugle2308]

⚠️ Dangerous command requires approval:

cd /opt/data/workspace/AnvilCraft && git rev-parse --abbrev-ref HEAD 2>/dev/null; git remote -v | head -2; python3 -c "
import json
d=json.load(open('/tmp/issue4684.json'))
print('TITLE:', d.get('titl...

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 #4687

操作: synchronize
范围: 1 个文件（1 Java） / 17 行 diff
声明: Fixes #4684（恒星演化加速器完成演化爆炸动画结束后崩溃）

🔍 崩溃日志对账（修复行 == 崩溃行）

issue #4684 标题「锻星砧恒星演化爆炸动画结束后会崩溃」，日志 mclo.gs/4jdBczV 中提取到：

Cannot invoke "StellarEvolutionState.update(long, StellarTrack)"
because "this.evolutionState" is null
    at AcceleratorHandler.java:449   （出现 3 次）

对照目标分支 dev/1.21/1.6 的 AcceleratorHandler.java 源码（PR 未合并，FETCH_HEAD 即修复前状态）：

447:  if (evolutionState.isComplete() && !evolutionState.terminalApplied()) {
448:      completeEvolution(be);        // → finishAccelerator() 内部 evolutionState = null
449:  }                                 // ← 崩溃栈帧行号完全吻合
450:  boolean phaseChanged = evolutionState.update(...)  // 同 tick 解引用已置空字段 → NPE

修复行与崩溃行精确对应，修复方向正确：completeEvolution（PISN 解体分支与白矮星/中子星/黑洞残骸分支内部均调用 finishAccelerator 将 evolutionState = null）之后，同方法下一行立即解引用 evolutionState.update()。PR 用 else 包裹后两行，完成 tick 不再触碰已置空的状态机。

✅ 防「复活」三连核查（修复完整性）

1. 状态重建源已清空 — finishAccelerator()（line 701-711）同时置空 evolutionState、evolutionTrack、pendingLegacyTag，ensureState() 无旧标记可重建状态机，「演化复活」路径不存在 ✅
2. 下一 tick 入口判空提前退出 — serverTick 开头 line 415 if (evolutionState == null || evolutionTrack == null) return;，且 syncLegacyView 内部对 null 状态安全归零 ✅
3. 完成路径内部已同步客户端 — completeEvolution 两个分支（完全解体 / 残骸生成）末尾均调用 syncToClient(be)；else 包裹后完成 tick 虽跳过 gameTime % 20L 心跳同步，但已被内部同步覆盖，不丢完成 tick 的客户端状态 ✅

💡 建议（非阻塞）

• AcceleratorHandler.java — else 分支内 update() 后 syncToClient 的调用由 if (phaseChanged || gameTime % 20L == 0L) 守卫；完成 tick 若恰好落在非 20 tick 边界，原本会少一次心跳同步——因 completeEvolution 已同步且后续 tick 直接 return，无实际影响，可忽略。
• 遗留（非本次范围，提醒后续触达该状态机的 PR） — StellarEvolutionState.update() 阶段循环中仍存在同索引前驱/后继模式：phaseIndex++ 后 currentNode 与 previousNode 均取 get(phaseIndex)，导致 startsNewEvent 恒 false、事件窗口初始化分支为死代码（事件剖面连续阶段如 event_prelude → event_collapse 不会被识别为新窗口）。Fix Stellar Evolution Accelerator crashing on complete 修复恒星演化加速器完成演化后崩溃的问题 #4687 仅修崩溃，未覆盖此逻辑缺陷。

🟢 看起来不错

• 最小修复（17 行单文件），精准命中崩溃行，无过度设计
• 修复形状符合「置空成员后同方法后续行不得再解引用」的铁律
• 标题「Fix Stellar Evolution Accelerator crashing on complete 修复恒星演化加速器完成演化后崩溃的问题」英文+中文格式规范、语义准确，无需修改

结论: APPROVE — NPE 根因明确（completeEvolution 置空 evolutionState 后同 tick 解引用），else 包裹修复正确且完整；防复活三连（重建源清空、入口判空、内部同步）全部通过，无残留崩溃路径。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'state-machine-phase-rollover-review' (1 replacement).

[Gugle2308]

修复完整验证完毕。整理验证结果：

崩溃日志核对（mclo.gs/4jdBczV）：Cannot invoke "StellarEvolutionState.update(long, StellarTrack)" because "this.evolutionState" is null at AcceleratorHandler.java:449 —— 与修复前源码 449 行 evolutionState.update(...) 完全吻合。

防复活三连核对：

1. finishAccelerator（701-717 行）清空 evolutionState/evolutionTrack/pendingLegacyTag（709 行）→ ensureState（778 行 if (pendingLegacyTag == null) return;）不会重建状态机 ✅
2. serverTick 在 ensureState 之后有 if (evolutionState == null || evolutionTrack == null) return; 提前退出 ✅
3. completeEvolution 所有分支（PISN 解体 618 行 / 残骸路径 630 行）内部均已 syncToClient，else 包裹不会丢失完成 tick 的客户端同步 ✅

代码审查摘要 — PR #4687

操作: synchronize
范围: 1 个文件 (1 Java) / 17 行 diff
修复: AcceleratorHandler.serverTick — 完成演化后崩溃 (Fixes #4684)

🔴 关键

无。

⚠️ 警告

无。

💡 建议

• AcceleratorHandler.serverTick — 修复形状正确（if (isComplete && !terminalApplied) { completeEvolution } else { update }）。可选改进：完成分支与 update 分支之间没有共享逻辑，if/else 已是最小且清晰的写法，无需进一步重构。

🟢 看起来不错

• 崩溃点定位准确：issue 日志 mclo.gs/4jdBczV 的 NPE 栈帧 AcceleratorHandler.java:449（evolutionState.update() 解引用已置空的 evolutionState）与修复行完全一致——崩溃正是 completeEvolution(be) 内部 finishAccelerator 将 evolutionState = null 后，同 tick 下一行继续调 update() 所致。
• 防「复活」完整：finishAccelerator 已同步清空状态重建源 pendingLegacyTag（709 行），ensureState（778 行）不会在后续 tick 用旧数据重建状态机；serverTick 在 ensureState 后已有 evolutionState == null 提前 return；完成路径内部（PISN 解体分支 618 行、残骸分支 630 行）均已 syncToClient，客户端不会漏掉完成同步。
• 修复为纯控制流变更，无行为副作用；completeEvolution 自身也有 if (evolutionState == null) return; 防御。

结论: APPROVE — 17 行单点修复，崩溃根因与修复行经日志双向验证吻合，防复活三连（重建源清空 / 下一 tick 提前退出 / 完成同步不丢）全部满足。

---

由 Hermes Agent 审查

备注：PR 标题 "Fix Stellar Evolution Accelerator crashing on complete" 已能准确描述本次修复（修复崩溃、Fixes #4684），无需修改。

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'state-machine-phase-rollover-review' (1 replacement). · Patched references/anvilcraft-stellar-evolution-npe.md in skill 'minecraft-modding' (1 replacement). · Patched SKILL.md in skill 'minecraft-modding' (1 replacement).

[Gugle2308]

PR #4687 的操作是 closed，按审查约束第 1 条：「如果操作是 closed 或 labeled，stop here，不要发布评论」。

因此本次不下载 diff、不执行审查、不输出审查意见，直接结束。