R10 P0: inventory 拆分设计收口与吸收清单验真 - #1893
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughSummary by CodeRabbit
Walkthrough新增 R10 inventory core 重构计划。计划冻结 ChangesInventory Core 重构计划
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/plan-refactor-inventory-core-v1.md`:
- Around line 139-160: 将本节标题从“P0.7 开放问题决议”改为仓库约定的“§N.1
决议”格式；保留两个问题各自的结论、实施方案、边界条件，以及文件:行号和 plan 章节双锚点，并确保章节明确标记为实施前的开放问题收口决议。
- Around line 33-34: 在计划的 P2、P3 及迁移测试中显式绑定
qi_physics::ledger::QiTransfer、qi_release_to_zone 和 qi_excretion：所有真元流动通过
QiTransfer，释放通过 qi_release_to_zone，吸收通过 qi_excretion；冻结 spill、merge、migration
对真元字段的守恒要求，确保不生成、销毁或重置这些字段。
- Around line 90-98: 在 P2/P3/P4 对应机制阶段中补充可直接实现的玩家可感知行为规格，覆盖地面掉落、拾取合并、旋转
footprint、pack feedback 和 client footprint 替换涉及的粒子、音效、HUD、环境效果、动画与
narration，并明确触发条件、表现内容及失败路径；不要仅以 R6/R7 文件所有权代替这些定义。
- Around line 171-176: 更新计划中的 mineral give 路径，要求其通过 InventoryTxn::deliver
处理，而不是直接发送 MineralDropEvent；成功确认必须等待 InventoryDeliveryReceipt，并仅在事务成功（stored 或
spilled）后发送。若该路径确实保留为例外，补充明确的 revision、spill、错误处理及成功确认语义。
- Around line 7-15: 更新文档中的 P0 完成状态及所有相关核验日期，将未来的 2026-08-03 替换为实际完成日期；如果 P0
尚未完成，则将其恢复为未完成标记。同步修正该文档中 Line 111 和 Line 139 的相同日期，确保没有未来日期被用作已完成证据。
- Around line 59-88: 补全 InventoryTxn 契约，明确 request/receipt 的具体字段、staged
inventory 与 InventoryInstanceIdAllocator 的暂存及提交边界；提交成功时先按一致顺序提交库存和
allocator，失败则两者均保持不变。为 pickup_and_merge 明确仅在 inventory commit 成功后删除
DroppedLootRegistry 掉落，并定义重试幂等语义，避免重复创建、扣除或删除；同时保留 deliver、consume_checked 与
pickup_and_merge 的 revision、明细、错误分类及总量守恒要求。
- Around line 22-34: 补齐本文“接入面”及 P1–P4 阶段的可执行契约锚点：为
inventory_snapshot、inventory_event、InventoryEventHandler 和 R6 接缝分别注明实际
schema、client handler、emit/proto symbol、bot 测试路径，并为各阶段列出具体模块路径、类型/函数、测试、Redis
key 或跨仓库契约 symbol；覆盖旋转 footprint、move/merge/spill receipt、instance 与 revision
校验，不能仅引用 server/src/schema/inventory.rs 中的 InventoryEventV1::Moved。
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 7c72de77-86c8-4aee-b89f-ebe5b65402d8
📒 Files selected for processing (2)
docs/plan-refactor-inventory-core-v1.mddocs/plans-skeleton/plan-refactor-inventory-core-v1.md
💤 Files with no reviewable changes (1)
- docs/plans-skeleton/plan-refactor-inventory-core-v1.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (4)
docs/**/*.md
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.md: 新 plan 头部必须写明接入面：进料、出料、复用的共享类型/event/schema、server/agent/client 跨仓库契约，以及对应的worldview.md锚点。
涉及真元、灵气、衰减、逸散、半衰、距离损耗、排斥或吸力的 plan，必须调用qi_physics；新物理常数和公式必须先扩展qi_physics，不得在功能 plan 中重复实现。
所有真元/灵气流动必须遵守守恒律并通过qi_physics::ledger::QiTransfer；释放使用qi_release_to_zone，吸收使用qi_excretion，不得凭空生成或销毁真元。
涉及玩家可感知行为的 plan，必须在对应机制阶段中内联可直接实现的粒子、音效、HUD、环境、动画和 narration 规格；不得将视听内容笼统推迟到独立阶段。纯 server 逻辑 plan 例外。
每份 plan 必须列出开放问题；实施前必须追加§N.1 决议，逐项给出结论、实施方案、边界条件，并以文件:行号和 plan 章节双锚点落地。
scope 大于或等于 4 个 PR 的 plan，必须在末尾包含§10 实施工作流，并按依赖顺序在一个 plan 内序列化多个 PR，不得拆成多个 plan。
涉及 NBT 建筑、worldgen layout 或复杂视觉资产的 TODO，必须完成三轮提交：(round 1/3)、(round 2/3)、(round 3/3)；终轮提交必须包含拼写准确的<PROMISE>担保块。
§10 最末必须包含“单次 consume-plan 全自动到 merge”章节，明确用户提交/consume-plan后即可等待最终归档至docs/finished_plans/。一个 PR 只允许修改一个 plan；
/consume-plan只能追加 Finish Evidence 或执行允许的 plan 归档移动，不得自动修改其他 docs 文件、CLAUDE.md或 worldview 文档。
Files:
docs/plan-refactor-inventory-core-v1.md
docs/plan-*.md
📄 CodeRabbit inference engine (CLAUDE.md)
docs/plan-*.md: Active plan 每个阶段必须写出可核验的模块路径、类型/函数、测试、schema、Redis key 或跨仓库契约 symbol。
plan 归档前必须所有阶段标记为✅ YYYY-MM-DD并补充严格标题为## Finish Evidence的证据章节。
Files:
docs/plan-refactor-inventory-core-v1.md
**/*.{rs,ts,tsx,java,json,md}
📄 CodeRabbit inference engine (CLAUDE.md)
唯一真货币是骨币；矿物是交易筹码，灵石是燃料/衰变物，金银不是货币。
Files:
docs/plan-refactor-inventory-core-v1.md
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: 禁止git stash push后不执行对应git stash pop；不得留下孤儿 WIP stash。
每个逻辑单元使用中文 atomic commit；agent 产生的每个 commit 必须包含真实模型 ID 的Model:trailer。
未经明确确认不得执行 force push、hard reset、amend、交互式 rebase、批量删除/移动文件或依赖版本/生产配置修改；严禁--no-verify、--no-gpg-sign及关闭签名。
PR review 只能通过独立评论/review触发；不得等待 Codex，review 修改后必须重新等待 re-review。
Files:
docs/plan-refactor-inventory-core-v1.md
🪛 LanguageTool
docs/plan-refactor-inventory-core-v1.md
[grammar] ~132-~132: Ensure spelling is correct
Context: ...ersion 分流与反序列化路径；R3 P1 拆分后由稳定 loader 调用。 3. 迁移幂等：新布局不变；旧 5×7/main-pack 形态转换为当前容器布局；所有 item insta...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~181-~181: Ensure spelling is correct
Context: ...int、pack move receipt 落地；公共 S2C 变更服从 R6 文件所有权。 - 按 §P0.6 完成 pre-#249 幂等迁移并接入 R3 hydrat...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🔇 Additional comments (2)
docs/plan-refactor-inventory-core-v1.md (2)
36-53: LGTM!
162-192: 📐 Maintainability & Code Quality确认 P1–P4 的 PR 拆分。
本计划包含四个实施阶段。请确认这些阶段是否对应至少四个 PR。若是，请增加
§10 实施工作流，按依赖顺序序列化多个 PR，并加入“单次 consume-plan 全自动到 merge”章节。As per coding guidelines：scope 大于或等于 4 个 PR 的 plan 必须包含
§10 实施工作流，并明确单次 consume-plan 到最终归档的流程。Source: Coding guidelines
| ### P0.3 冻结满包与网格策略 | ||
|
|
||
| 1. **统一策略：机制结算点/玩家脚下地面掉落，不建个人暂存箱。** craft、alchemy、forge、give、loot 使用同一 delivery fallback；世界坐标和 dimension 由调用者提供。 | ||
| 2. 只有经过完整验证后确认的容量不足可以 spill。unknown template、零数量、无容器、ID 冲突、非法 footprint 等必须返回结构错误并保持源状态不变。 | ||
| 3. 调用者没有真实 `SpillContext` 时 fail closed，返回 `CapacityExceeded`/`MissingSpillContext`；不得用虚构坐标，也不得清 session、扣材料或删除世界掉落。 | ||
| 4. spill 必须携带原 `ItemInstance`；对 minted stack 可按合法最大堆叠拆分，对既有动态实例不得通过重新 mint 丢字段。 | ||
| 5. 所有 attach 都必须先通过 `validate_attach_fits` 并由 `attach_at_location` 提交；删除 `force_attach_item_to_inventory` 的 `(0,0)` 强塞 fallback。全量转移放不下的剩余项进入显式 spill receipt，而不是重叠占格。 | ||
| 6. rotate/move receipt 必须携带变更后的完整 item view 或等价 `grid_w/grid_h + rotated` 事实。R10 定义所需事实，R6 负责公共 S2C schema/emit 接缝，client 以权威新 footprint 替换旧 view。 | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | 🏗️ Heavy lift
把玩家可感知行为规格写入对应机制阶段。
计划定义了地面掉落、拾取合并、旋转 footprint、pack feedback 和 client footprint 替换，但没有粒子、音效、HUD、环境、动画或 narration 规格。请在 P2/P3/P4 的对应机制阶段内写出可直接实现的规格。R6/R7 的文件所有权不能替代这些行为定义。
As per coding guidelines：涉及玩家可感知行为的 plan，必须在对应机制阶段内联粒子、音效、HUD、环境、动画和 narration 规格。
Also applies to: 178-190
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/plan-refactor-inventory-core-v1.md` around lines 90 - 98, 在 P2/P3/P4
对应机制阶段中补充可直接实现的玩家可感知行为规格，覆盖地面掉落、拾取合并、旋转 footprint、pack feedback 和 client
footprint 替换涉及的粒子、音效、HUD、环境效果、动画与 narration，并明确触发条件、表现内容及失败路径；不要仅以 R6/R7
文件所有权代替这些定义。
Source: Coding guidelines
| ### P0.7 开放问题决议（pre-P0 收口，2026-08-03） | ||
|
|
||
| #### #1 满包溢出策略 | ||
|
|
||
| **决议**：选择玩家脚下/机制结算点地面掉落，拒绝个人暂存箱。 | ||
|
|
||
| - 复用现役 `add_item_to_player_inventory_or_ground` 与 `rebuild_and_drop_overflow` 语义，减少第二套持久化、权限、过期与 UI 生命周期。 | ||
| - 地面掉落保留末法争夺风险；通过 dropped id + instance id + world position/dimension receipt 保证可追踪。 | ||
| - 仅容量不足可降级，结构错误 fail closed；无真实世界上下文不得伪造 fallback。 | ||
|
|
||
| **落点**：`server/src/inventory/mod.rs:1839`、`:5016`（依据）；本 plan §P0.2、§P0.3、§P2。 | ||
|
|
||
| #### #2 pre-#249 老布局迁移是否并入 | ||
|
|
||
| **决议**：并入 P3，但在 R3 P1 后实施；R10 提供纯迁移，R3 负责 load/save 编排。 | ||
|
|
||
| **落点**：`server/src/player/state.rs:1372-1433`（依据）；本 plan §P0.6、§P3。 | ||
|
|
||
| 原开放问题全部已在本节收口。原题保留如下以备追溯，**实施时以 §P0.7 决议为准**： | ||
|
|
||
| 1. 满包溢出策略：脚下掉落 vs 个人暂存箱。 | ||
| 2. pre-#249 老存档迁移是否并入本轨 P3。 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
使用规定的 §N.1 决议 章节格式。
当前标题为 ### P0.7 开放问题决议，缺少规定的 §... 决议锚点。请改为仓库约定的 §N.1 决议 形式，并保留每个问题的结论、实施方案、边界条件以及文件:行号和 plan 章节双锚点。
As per coding guidelines：每份 plan 必须列出开放问题；实施前必须追加 §N.1 决议，逐项给出结论、实施方案、边界条件，并以文件:行号和 plan 章节双锚点落地。
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/plan-refactor-inventory-core-v1.md` around lines 139 - 160, 将本节标题从“P0.7
开放问题决议”改为仓库约定的“§N.1 决议”格式；保留两个问题各自的结论、实施方案、边界条件，以及文件:行号和 plan
章节双锚点，并确保章节明确标记为实施前的开放问题收口决议。
Source: Coding guidelines
Central reviewDecision: Validated findings[major] Forge coverage does not close the unresolved hoe instance-visibility contract
The deleted skeleton's observable contract is broader than forge: Root cause: the plan treats one recovered forge instance-visibility path as evidence that the multi-system inventory-instance visibility plan is fully covered, without checking the still-shallow lingtian producer-to-snapshot-to-intent contract. deleting the skeleton and scheduling only the forge test removes regression ownership for a named unresolved contract. [major] Pack feedback acceptance passes on the known snapshot-only baseline
P4 accepts either a typed receipt or an authoritative snapshot for Root cause: the promoted plan weakens the absorbed pack-feedback acceptance contract from a stable per-request success/rejection signal to an [major] P3 has no owner for the required S2C and client receipt wiring
The new authoritative plan assigns R10 only Root cause: the promoted plan describes a cross-track dependency as an ownership note rather than assigning the schema, emitter, client consumer, and contract-test work to a concrete r6 phase and dependency. deleting the original skeleton makes this incomplete plan the canonical implementation route, so the claimed end-to-end fixes have no executable production wiring owner. |
Central reviewDecision: Validated findings[major] Unified spill policy has no bound for durable dropped-loot growth
The plan makes player-foot/settlement-point drops the unified fallback for craft, alchemy, forge, give, and loot (line 91), while the production registry is an unbounded Root cause: the unified ground-drop contract expands the number of production paths that can create entries but defines no lifecycle or resource bound for the global, durable registry. existing pickup is the only normal removal path, so unattended or unreachable drops remain resident and continue inflating full-snapshot work and payload size. [major] P1 test-count gate contradicts the refactor master policy
P1 requires all current inventory tests to be moved and says their count may not decrease (lines 174-176). The governing master plan explicitly overrides the repository-wide saturation rule for refactor tracks: Root cause: the promoted track plan copied a test-count preservation gate without applying the master plan's explicit refactor-track testing policy, leaving contradictory acceptance criteria for p1. [major] Pickup merge contract does not preserve incoming-only attrition semantics
The changed plan absorbs Root cause: the plan records incoming-only attrition only as a summary phrase, but omits the concrete attrition target/quantity or absolute-qi facts from the frozen pickup receipt and omits an incoming-only attrition/ledger assertion from p2 and p4. that leaves the known post-merge consumer contract unresolved and untested. [major] Register the mandatory R6 and R3 work in their owning plans
The newly promoted plan marks R10 P0 complete at line 7, but line 106 makes R6 P0 registration of Root cause: the pr promotes and declares r10 p0 complete while documenting mandatory work owned by r6 and r3 without updating those tracks' canonical plans. this leaves duplicated, inconsistent planning sources: r6/r3 can complete their stated phases without producing the apis/consumer that r10 explicitly gates on, making the cross-track implementation path disconnected. [major] Delivery tests do not pin preservation of existing item instances
The plan freezes a changed observable contract at lines 82-83: delivering an existing Root cause: the acceptance matrix tests merge identity and quantity conservation but omits a positive round-trip test for the newly required existing- |
Central reviewDecision: Validated findings[major] The bounded dropped-loot design leaves direct production writers outside the capacity gate
The new P0 contract declares Root cause: the plan treats delivery/spill flows as the complete write boundary for dropped loot, but [major] R3 P2 consumes an R10 constant before its producer exists
Root cause: the persistence plan consumes a symbol owned and introduced by a later r10 phase without declaring a dependency that delays r3 p2 or assigning the constant to an earlier shared contract. this leaves the required dropped-loot hydration guard disconnected from its stated producer and can force an implementation to invent a duplicate constant or defer the promised guard. [major] Legacy migration has no reachable consumer for conserved overflow
P0.3 requires any spill without a real Root cause: the pure migration boundary omits the world context and durable overflow sink required by the plan's own spill contract, and no production consumer owns completing that handoff. this wrong-layer split makes the required overflow migration behavior unreachable. [major] P2 leaves the new consume transaction contract untested
The plan introduces Root cause: the test plan treats delivery, pickup, and consumption as one generic p2 matrix even though |
Central reviewDecision: Validated findings[major] Durable spill commits are not atomic with source-state removal
The new plan calls Root cause: the frozen dropped-loot api makes capacity reservation atomic only within the in-memory registry and does not define a transaction/outbox protocol that commits the source inventory/session/material state and durable dropped-loot row as one recoverable operation for every production writer. [major] Dropped-loot sync lacks a recipient visibility boundary
The new contract requires the R6 Root cause: the new dropped-loot synchronization contract models paging and revision atomicity but omits the security boundary that filters registry entries per recipient. because the registry aggregates world-wide durable drops and the r6 plan mandates shared snapshot delivery, implementing the contract as written can disclose item identities and world positions across players or dimensions. [major] Assign the rejected move correlation schema to R6
The new R10 acceptance contract requires every rejected pack/move request to return Root cause: the cross-track contract specifies correlation fields for accepted inventory moves but does not assign the corresponding rejected-payload schema, mirror, conversion, emitter, consumer, and contract-test changes to r6, even though r6 exclusively owns that boundary and the current rejection schema lacks those fields. [major] Add pickup placement and failed-commit deletion tests
The new pickup contract requires the dropped entry to be removed only after the inventory commit succeeds, and it explicitly supports both merge and placement-only pickup. However, the listed regression scenarios cover only the same-identity merge case ( Root cause: the test plan does not cover the pickup transaction's atomic boundary between inventory commit and droppedlootregistry deletion, nor the non-merge placement path. the changed contract is broader than the only pickup scenario specified. |
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/plans-skeleton/plan-refactor-qi-ledger-v1.md (1)
21-27: 📐 Maintainability & Code Quality | 🟠 Major | 🏗️ Heavy lift补齐多 PR plan 的 §10 实施工作流。
三个 plan 都明确列出至少 P0-P4/P5 的多阶段实施，但文档末尾没有
§10 实施工作流，也没有“单次 consume-plan 全自动到 merge”章节。
docs/plans-skeleton/plan-refactor-qi-ledger-v1.md#L21-L27：按依赖顺序序列化 P0-P4 对应 PR，并补充最终自动归档到docs/finished_plans/的流程。docs/plans-skeleton/plan-refactor-wire-s2c-v1.md#L19-L26：按依赖顺序序列化 P0-P5 对应 PR，并补充最终自动归档到docs/finished_plans/的流程。docs/plans-skeleton/plan-refactor-persistence-slices-v1.md#L21-L28：按依赖顺序序列化 P0-P5 对应 PR，并补充最终自动归档到docs/finished_plans/的流程。As per coding guidelines：scope 大于或等于 4 个 PR 的 plan，必须在末尾包含
§10 实施工作流，并明确“单次 consume-plan 全自动到 merge”章节。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plans-skeleton/plan-refactor-qi-ledger-v1.md` around lines 21 - 27, 补齐三个计划文档末尾的“§10 实施工作流”：在 docs/plans-skeleton/plan-refactor-qi-ledger-v1.md（21-27）、docs/plans-skeleton/plan-refactor-wire-s2c-v1.md（19-26）和 docs/plans-skeleton/plan-refactor-persistence-slices-v1.md（21-28）分别按阶段依赖序列化对应 P0-P4 或 P0-P5 的 PR，并明确“单次 consume-plan 全自动到 merge”流程及完成后的自动归档到 docs/finished_plans/；仅需补充文档工作流章节，不改变现有阶段内容。Source: Coding guidelines
♻️ Duplicate comments (1)
docs/plan-refactor-inventory-core-v1.md (1)
83-86: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift冻结交付与拾取的重试幂等契约。
InventoryDeliveryReceipt记录了结果实例，但DeliveryRequest未定义 request identity、source revision 或幂等键。模板交付重试可能再次创建ItemInstance，造成重复物品。pickup_and_merge也只记录 dropped id；后文要求按dropped id/source revision重试，但未冻结该字段和冲突规则。请在 P0.2 明确幂等键、提交边界和 replay 行为：相同请求返回原 receipt 且不再次 mutation；相同键但 payload 不同则拒绝，且不 bump revision。
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plan-refactor-inventory-core-v1.md` around lines 83 - 86, 在 P0.2 冻结交付与拾取的幂等契约：为 DeliveryRequest 和 pickup_and_merge 请求定义稳定的 request identity/idempotency key，并明确提交边界及必要的 source revision。规定相同键且 payload 相同直接返回原 InventoryDeliveryReceipt 或 InventoryPickupReceipt、不重复 mutation；相同键但 payload 不同则拒绝且不修改 inventory、不提升 revision，同时明确失败与 replay 时的 receipt 查找和冲突行为。
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/plan-refactor-inventory-core-v1.md`:
- Around line 98-100: 在 docs/plan-refactor-inventory-core-v1.md 的 98-100 行，将 R6
dropped_loot_sync 的每页最多 256 entries 改为引用由 R6 同步接缝定义、拥有、路径和值为 256 的 canonical
DROPPED_LOOT_SYNC_PAGE_SIZE；在同文件 208 行的分片页大小验收中也引用该常量，确保实现与 bot gate 使用同一契约。
In `@docs/plans-skeleton/plan-refactor-persistence-slices-v1.md`:
- Line 27: 为 inventory migration consumer 补充 migration 与 overflow
持久化的原子恢复语义：优先让新 schema 提交与全部 overflow 写入使用同一 durable SQLite
transaction；若跨存储无法实现，则引入 migration ID/schema revision、幂等 upsert
和恢复标记，使崩溃重试既不重复写入 overflow 也不丢失 overflow。为“overflow 写入后/schema 提交前”和“schema
提交后/overflow 写入前”注入崩溃验收场景，并验证恢复结果一致。
- Line 25: 补充 dropped-loot hydration 的明确 load-state 约定：fresh startup
超容量时不得注入任何已加载条目，保留数据库行并让 registry 进入只读/失败状态，拒绝 try_insert、try_insert_batch
及掉落拾取；仅在容量校验成功后注入旧条目并恢复写入。明确恢复写入和清除告警的条件，并加入 fresh startup
超容量断言，覆盖内存状态、数据库保留和写入拒绝行为。
In `@docs/plans-skeleton/plan-refactor-qi-ledger-v1.md`:
- Line 46: 在计划中的 qi_pickup_merge_incoming_only 验收项中补充一次性消费断言：确认
incoming_instance_id 已从 dropped-loot registry 移除并发送空同步，目标 stack
不包含重复物品；随后重放同一拾取请求，验证不会再次扣减真元。
- Line 26: 在 P3 计划条目中补齐 incoming-only attrition 的可执行契约：明确 PickupAttritionBasis 中
incoming_stack_count 的取值口径、incoming_abs_qi_before 的计算公式，并定义实际 attrition
公式及舍入规则、输入边界和稳定 API 的函数签名与模块路径。补充 count=1、count>1、零真元及容量不足的验收样例，确保 merge 后只磨损
incoming 绝对真元并将损耗守恒归还 zone。
In `@docs/plans-skeleton/plan-refactor-wire-s2c-v1.md`:
- Around line 21-23: 在 P2 的 dropped-loot
分片协议说明中补充完整操作语义：定义重发请求的字段与服务端触发重发的条件，并明确客户端超时、重试上限、重复页丢弃、乱序页缓存及旧 revision
丢弃规则；确保仅在同一 revision 的全部分片收齐后原子替换视图，缺页或混 revision 持续保留旧视图并按规则请求重发。
---
Outside diff comments:
In `@docs/plans-skeleton/plan-refactor-qi-ledger-v1.md`:
- Around line 21-27: 补齐三个计划文档末尾的“§10 实施工作流”：在
docs/plans-skeleton/plan-refactor-qi-ledger-v1.md（21-27）、docs/plans-skeleton/plan-refactor-wire-s2c-v1.md（19-26）和
docs/plans-skeleton/plan-refactor-persistence-slices-v1.md（21-28）分别按阶段依赖序列化对应
P0-P4 或 P0-P5 的 PR，并明确“单次 consume-plan 全自动到 merge”流程及完成后的自动归档到
docs/finished_plans/；仅需补充文档工作流章节，不改变现有阶段内容。
---
Duplicate comments:
In `@docs/plan-refactor-inventory-core-v1.md`:
- Around line 83-86: 在 P0.2 冻结交付与拾取的幂等契约：为 DeliveryRequest 和 pickup_and_merge
请求定义稳定的 request identity/idempotency key，并明确提交边界及必要的 source revision。规定相同键且
payload 相同直接返回原 InventoryDeliveryReceipt 或 InventoryPickupReceipt、不重复
mutation；相同键但 payload 不同则拒绝且不修改 inventory、不提升 revision，同时明确失败与 replay 时的 receipt
查找和冲突行为。
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 3624b8de-1200-4dcf-b737-967fcbb2b2cb
📒 Files selected for processing (4)
docs/plan-refactor-inventory-core-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
docs/**/*.md
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.md: 新 plan 头部必须写明接入面：进料、出料、复用的共享类型/event/schema、server/agent/client 跨仓库契约，以及对应的worldview.md锚点。
涉及真元、灵气、衰减、逸散、半衰、距离损耗、排斥或吸力的 plan，必须调用qi_physics；新物理常数和公式必须先扩展qi_physics，不得在功能 plan 中重复实现。
所有真元/灵气流动必须遵守守恒律并通过qi_physics::ledger::QiTransfer；释放使用qi_release_to_zone，吸收使用qi_excretion，不得凭空生成或销毁真元。
涉及玩家可感知行为的 plan，必须在对应机制阶段中内联可直接实现的粒子、音效、HUD、环境、动画和 narration 规格；不得将视听内容笼统推迟到独立阶段。纯 server 逻辑 plan 例外。
每份 plan 必须列出开放问题；实施前必须追加§N.1 决议，逐项给出结论、实施方案、边界条件，并以文件:行号和 plan 章节双锚点落地。
scope 大于或等于 4 个 PR 的 plan，必须在末尾包含§10 实施工作流，并按依赖顺序在一个 plan 内序列化多个 PR，不得拆成多个 plan。
涉及 NBT 建筑、worldgen layout 或复杂视觉资产的 TODO，必须完成三轮提交：(round 1/3)、(round 2/3)、(round 3/3)；终轮提交必须包含拼写准确的<PROMISE>担保块。
§10 最末必须包含“单次 consume-plan 全自动到 merge”章节，明确用户提交/consume-plan后即可等待最终归档至docs/finished_plans/。一个 PR 只允许修改一个 plan；
/consume-plan只能追加 Finish Evidence 或执行允许的 plan 归档移动，不得自动修改其他 docs 文件、CLAUDE.md或 worldview 文档。
Files:
docs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plans-skeleton/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
新建 plan 前必须先阅读
docs/CLAUDE.md；骨架 plan 必须包含主题和 P0/P1 等阶段总览。
Files:
docs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
**/*.{rs,ts,tsx,java,json,md}
📄 CodeRabbit inference engine (CLAUDE.md)
唯一真货币是骨币；矿物是交易筹码，灵石是燃料/衰变物，金银不是货币。
Files:
docs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plan-refactor-inventory-core-v1.md
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: 禁止git stash push后不执行对应git stash pop；不得留下孤儿 WIP stash。
每个逻辑单元使用中文 atomic commit；agent 产生的每个 commit 必须包含真实模型 ID 的Model:trailer。
未经明确确认不得执行 force push、hard reset、amend、交互式 rebase、批量删除/移动文件或依赖版本/生产配置修改；严禁--no-verify、--no-gpg-sign及关闭签名。
PR review 只能通过独立评论/review触发；不得等待 Codex，review 修改后必须重新等待 re-review。
Files:
docs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plan-*.md
📄 CodeRabbit inference engine (CLAUDE.md)
docs/plan-*.md: Active plan 每个阶段必须写出可核验的模块路径、类型/函数、测试、schema、Redis key 或跨仓库契约 symbol。
plan 归档前必须所有阶段标记为✅ YYYY-MM-DD并补充严格标题为## Finish Evidence的证据章节。
Files:
docs/plan-refactor-inventory-core-v1.md
🧠 Learnings (3)
📚 Learning: 2026-07-17T00:31:10.779Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:1-1
Timestamp: 2026-07-17T00:31:10.779Z
Learning: 在审查该仓库 `docs/plans-skeleton/` 下的“docs-only skeleton plan”创建类 PR 时：先核对 `docs/CLAUDE.md` 中“Plan 消费规范”，并逐份查看本计划文档里的“§10 实施工作流”，确认后续实施阶段是否会遵循“每个 PR 只修改一个 plan”，且实施/归档时不会出现跨 plan 的修改。该规则不适用于用户显式指定、共享调研基线且计划之间存在互相交叉引用的 skeleton plan 同批创建 PR；对这类情况应按实际交叉引用关系放宽，确保仍能按独立或约定的序列化方式推进。
Applied to files:
docs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
📚 Learning: 2026-07-17T00:31:13.643Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:81-85
Timestamp: 2026-07-17T00:31:13.643Z
Learning: 审核 docs/plans-skeleton/*.md 下的 skeleton 草案 PR 时：不得要求作者在“§N 开放问题（P0 决策门前需收口）”核查完成之前提前填写对应的“§N.1 决议”。仅当计划进入 active 且 P0 实施前，已由 Explore agent 并行核查代码现状后，才允许追加“§N.1 决议”，且该决议需包含结论、实施方案、边界条件，并使用“文件:行号 + plan 章节”的双锚点格式。
Applied to files:
docs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
📚 Learning: 2026-07-22T02:11:59.191Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1247
File: docs/plans-skeleton/plan-bughunt-animal-air-spawn-gravity-v1.md:0-0
Timestamp: 2026-07-22T02:11:59.191Z
Learning: 在 `docs/plans-skeleton/` 目录下的计划状态行中，若起草日期同时涉及 UTC 与本地日期（例如时区换算后可能跨到不同日期），请在该行中同时标注 UTC 起草日与本地起草日。这样可以避免基于 UTC 的时间基准在 GitHub/CodeRabbit 审查时将本地日期误判为“未来日期”。
Applied to files:
docs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
🪛 LanguageTool
docs/plan-refactor-inventory-core-v1.md
[style] ~24-~24: Consider using the more formal “until”.
Context: ...oe_iron 的 producer→snapshot→equip/held→lingtian_start_till深链仍未覆盖。 -load_player_inventory_from_...
(TILL)
[style] ~128-~128: Consider using the more formal “until”.
Context: ... 0，未验证 hoe_iron 的 snapshot/equip/真实 till 链。P4 必须恢复该深断言后才能归档。 | | `forge-outcome-...
(TILL)
[style] ~206-~206: Consider using the more formal “until”.
Context: ...eipt 与权威 snapshot），再用同一非零 instance id 发 lingtian_start_till，断言真实 lingtian_session/明确业务拒绝回执且请求未因 ...
(TILL)
[style] ~206-~206: Consider using the more formal “until”.
Context: ... mismatch 被拒。只有 producer→snapshot→equip→till 全链通过，才可归档 visibility skeleton。 7. Pytho...
(TILL)
🔇 Additional comments (4)
docs/plan-refactor-inventory-core-v1.md (1)
24-24: LGTM!Also applies to: 128-128, 141-143, 156-157, 178-178, 182-189, 193-193, 203-203, 206-206
docs/plans-skeleton/plan-refactor-persistence-slices-v1.md (1)
53-56: LGTM!Also applies to: 58-61, 63-67
docs/plans-skeleton/plan-refactor-wire-s2c-v1.md (2)
31-31: 🎯 Functional Correctness无需调整。
skeleton行已保留dropped-loot-g-pickup-range-desync（拾取范围下发对齐部分），并有独立 plan 覆盖客户端候选范围门禁与无效请求。
25-25: 🗄️ Data Integrity & Integration无需修改本行。
R6 P4 对应的范围已在
docs/plan-refactor-inventory-core-v1.md的 P4 子批次中同时包含 acceptedInventoryEventV1::Moved和InventoryMoveRejectedV1的 accepted/rejected 双结果契约需求，本行不需要为 rejected receipt 另写“或等价”分支。
| 6. dropped-loot registry 是有界 durable queue，不是无限容器：R10 P1 定义 `MAX_DURABLE_DROPPED_LOOT_ENTRIES` 单一常量（初值 `4096`，测试只引用该常量）以及 `DroppedLootRegistry::try_insert` / `try_insert_batch` 原子容量 API。任何生产写入都必须先通过该 API；单条写入在 mutation 前预留 1 槽，批量写入在首条 mutation 前一次性预留全部槽位，禁止调用方直接操作 `entries.insert`。生产 writer 的穷举清单是：`add_item_to_player_inventory_or_ground`、`rebuild_and_drop_overflow`、`enforce_intrinsic_gate_on_morph_release`、`apply_death_drop_on_revive` 的 TSY/主世界分支、`apply_termination_drop_on_terminate` 的 world-drop fallback 分支、`spawn_template_dropped_loot`、`discard_inventory_item_to_dropped_loot`、`tsy_loot_spawn::spawn_for_layer` 以及该文件内所有 placeable-break/TSY layer event writer；P2/P3 必须逐一迁移，测试 fixture 允许直接构造 registry 但不得代表生产接线。所有 delivery/discard/overflow/death/TSY/placeable-break 路径在 mutation 前按“本事务新增 dropped entry 数”原子预留容量。成功 spill 的 source mutation、registry entry 与 durable dropped-loot row 必须由 R3 persistence transaction/outbox seam 作为同一可恢复提交单元落盘；任一持久化失败或进程重启恢复未完成时，源状态保持可重试且不得出现仅 source 已删或仅 drop 已写的单边状态，重试按 dropped id/source revision 幂等。`len + required > MAX` 时返回 typed `DroppedLootCapacityExceeded { current, required, limit }`，inventory、revision、session、材料、世界掉落与 persistence 均保持不变；禁止逐项插入后才发现超限。启动 hydration 的行数检查由 R3 提供 guard 接缝、由 R10 P1 的常量/API 接入；在 R10 P1 合入前 R3 不得引用该 symbol。超限时必须进入 R3 load-failure guard/只读降级并告警，不能截断、驱逐或覆盖旧行。 | ||
| 7. 正常回收只允许玩家 pickup 或后续显式管理员运维；本 plan 不以 TTL/LRU/按价值驱逐静默销毁稀缺物品。每次 pickup 与 durable delete 同事务释放槽位。R6 的 `dropped_loot_sync` 必须分页/分片，每 payload 至多 `256` entries，携带 `snapshot_revision/page_index/page_count`；client 收齐同 revision 全部分片后原子替换视图，内容变化时不再对每个 client 构建/排序一份无界全量 payload。sync 组装必须先按接收者可见性过滤：至少要求目标玩家与 entry 同 dimension，且 entry 位于该玩家当前授权观察范围（空间距离/zone 由 R6 接入面冻结；owner/private drop 仅 owner 或显式授权管理员可见）；分页、计数、revision 和原子替换均只针对过滤后的 recipient view，禁止把全服 registry 快照直接广播给普通 client。 | ||
| 8. rotate/move receipt 必须携带变更后的完整 item view 或等价 `grid_w/grid_h + rotated` 事实。R10 的 inventory outcome 提供所需事实；R4 在其独占 handler 中把 outcome 交给 emit API；R6 扩展公共 S2C schema/emit 并让 client 以权威新 footprint 替换旧 view。三段任一未完成均不得判 P3/P4 完成。 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
统一 dropped-loot 分片页大小的契约。
P0.3 使用字面量 256，但 P4 使用未定义的 DROPPED_LOOT_SYNC_PAGE_SIZE。这会使 R6 实现与 bot gate 使用不同限制，或使验收无法直接实现。请在 R6 的同步接缝定义该常量、所有者、路径和值，并在两处统一引用。
docs/plan-refactor-inventory-core-v1.md#L98-L100: 将分片上限绑定到 R6 的 canonicalDROPPED_LOOT_SYNC_PAGE_SIZE。docs/plan-refactor-inventory-core-v1.md#L208-L208: 使用同一常量完成分片页大小验收。
📍 Affects 1 file
docs/plan-refactor-inventory-core-v1.md#L98-L100(this comment)docs/plan-refactor-inventory-core-v1.md#L208-L208
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/plan-refactor-inventory-core-v1.md` around lines 98 - 100, 在
docs/plan-refactor-inventory-core-v1.md 的 98-100 行，将 R6 dropped_loot_sync 的每页最多
256 entries 改为引用由 R6 同步接缝定义、拥有、路径和值为 256 的 canonical
DROPPED_LOOT_SYNC_PAGE_SIZE；在同文件 208 行的分片页大小验收中也引用该常量，确保实现与 bot gate 使用同一契约。
Source: Coding guidelines
| 2. `qi_skill_roundtrip`：单招释放前后玩家+zone 总量不变。 | ||
| 3. `qi_death_release`：击杀带真元的 NPC/离屏战死→断言 zone 收到等额释放。 | ||
| 4. `qi_negative_zone`：负灵域内释放/吸收→断言赤字被记账不被 max(0) 抹平。 | ||
| 5. `qi_pickup_merge_incoming_only`：已有 stack 与同 identity dropped item 合并，断言 attrition 只基于 receipt 的 `incoming_abs_qi_before`，既有 stack 原绝对真元不变、目标 stack + zone 总量守恒，且不依赖 consumed dropped instance id 在 inventory 中仍存在。 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
补充 consumed drop 的一次性消费验收。
当前场景只验证真元守恒。它还必须验证 incoming_instance_id 已从 dropped-loot registry 移除，目标 stack 没有重复物品，并且重放同一个拾取请求不会再次扣减真元。
server/src/network/inventory_snapshot_emit.rs:1177-1291 已证明拾取后会移除 registry 条目并发送空同步。请将这些断言加入 qi_pickup_merge_incoming_only。
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/plans-skeleton/plan-refactor-qi-ledger-v1.md` at line 46, 在计划中的
qi_pickup_merge_incoming_only 验收项中补充一次性消费断言：确认 incoming_instance_id 已从
dropped-loot registry 移除并发送空同步，目标 stack 不包含重复物品；随后重放同一拾取请求，验证不会再次扣减真元。
Central reviewDecision: Validated findings[major] Require authoritative dimension authorization in the pickup transaction
The new plan requires recipient filtering only for Root cause: the plan treats recipient-scoped s2c visibility as the dropped-loot trust boundary but omits a mandatory server-authoritative dimension/permission check from [major] Global snapshot reuse contradicts recipient-specific dropped-loot filtering
The changed R6 P1 deliverable requires a dropped-loot snapshot to be sorted/encoded once and reused across target clients. The new canonical R10 contract at Root cause: the wire plan treats dropped-loot synchronization as one globally reusable encoded snapshot, while the inventory plan defines the payload as a recipient-specific projection. encoding occurs before the required per-recipient authorization and visibility boundary is represented. [major] Test spill persistence failure and restart recovery
This changed contract requires source mutation, registry insertion, and durable dropped-loot persistence to form one recoverable unit, with persistence failure and restart recovery preserving retryability and idempotency. Yet the listed P2 bound pin only tests capacity overflow, and Root cause: the plan specifies failure-atomic and idempotent persistence semantics for every normal spill writer without adding regression tests for persistence failure boundaries or interrupted-commit recovery, so one-sided loss and retry duplication remain accepted by the planned suite. [major] Add recipient-visibility tests for dropped-loot sync
The new contract requires Root cause: the plan introduces a recipient-specific authorization boundary for dropped-loot synchronization but omits positive and negative tests for each visibility precondition, leaving a concrete cross-player information disclosure implementation unprotected. |
Central reviewDecision: Validated findings[major] R10 rewrite drops the required named bot acceptance scenarios
The replacement plan defers bot/e2e work to phase D but never defines the required bot scenarios or their Root cause: the plan rewrite replaced the track's executable, named bot acceptance surface with general contract pins, disconnecting phase d from the master plan's required primary acceptance artifacts. [blocker] Pickup commits before its qi attrition transfer
The frozen pickup order explicitly commits the staged inventory revision and durable dropped-loot deletion first, and only then runs Root cause: the plan places r5's item-to-zone qi transfer outside and after the durable pickup commit, while assigning the persistence transaction only the inventory/drop slices. pickup attrition changes both the persisted item and zone/ledger and must be staged and committed atomically with inventory insertion and dropped-row deletion; treating it as post-commit receipt processing creates a crash-recovery partial-application boundary. [major] R3 is gated on R10 phases that no longer exist
The promoted R10 plan defines phases only as Root cause: r10's phase namespace was replaced with a-d without updating cross-plan dependency references that still target the deleted p1/p3 milestones. [major] Demanded pins omit the new deliver validation failures
The new contract explicitly requires Root cause: the p0 plan freezes several new [major] Owner/private authorization has no authoritative fact in dropped-loot entries
The new security contract requires R6 to hide owner/private drops from non-owners and requires R4/R10 to reject unauthorized pickup, but it never defines where a drop's owner identity, privacy mode, or administrator grant is stored or how producers populate those facts. The current canonical Root cause: p0 declares the owner/private trust boundary complete but assigns only filtering and checking responsibilities; it omits the authoritative ownership/privacy data model, producer assignment rules, persistence/migration behavior, and administrator-grant source needed to enforce that boundary. [major] R10 marks P0 complete without the mandatory absorption audit
This line marks P0 complete, but the plan's absorption section only lists eight plan names ( Root cause: the rewrite collapsed the mandatory per-item absorption audit into an unqualified name list and then advanced the phase status, dropping a required p0 acceptance deliverable from the authoritative plan. |
76a754c to
dd58ad3
Compare
Central reviewDecision: Validated findings[major] Gate consumer phases on the R3, R5, and R6 provider phases
The new canonical R10 schedule says Root cause: the canonical plan specifies cross-track contracts but its implementation order is not derived from the phases that produce those contracts. required r3 durability, r6 receipt emission, and r5 attrition providers are scheduled after, or not gated before, the r10/r4 consumers that need them, leaving the production chain impossible to complete at the claimed phases. [major] Owner-only discards can exhaust the global durable-loot capacity
The new plan makes Root cause: the plan introduces a globally shared hard capacity for attacker-influenceable durable drops without any per-principal quota, rate/admission control, reserved capacity, or bounded cleanup mechanism. combining that shared limit with owner-only visibility lets one player monopolize storage that is required by unrelated production paths. |
Central reviewDecision: Validated findings[major] R10 writer migration can start before the atomic commit seam exists
The new R10 plan allows production-writer migration only after the “R3 P3 durable spill/pickup recoverable-commit seam” has merged and orders work as Root cause: the cross-track schedule references the wrong r3 phase and never assigns implementation (rather than merely contract freezing) of the recoverable transaction/outbox seam before r10 migrates production writers. [major] R10 phase checklist contradicts the plan's cross-track ownership and order
The phase table assigns P3 to “纯 migration + R3 durable seam + R6 wire/client + R4 handler” and P4 to “R3 legacy consumer”. However, the same plan later declares those surfaces owned by R3/R4/R6, says R10 must not modify persistence, wire, handlers, or client code, and fixes the order as R3 P3 before R10 P2, R6 P4 and R4 before R10 P3, then R3 P4 afterward (lines 86-94). Following the phase table therefore either makes R10 implement work in three foreign ownership domains or leaves R10 P3/P4 completion dependent on deliverables whose actual phases occur before and after it. The later ownership text does not prevent this because both sections are normative phase definitions in the newly promoted canonical plan. Root cause: the promoted plan retained a single r10 phase checklist that folds cross-track prerequisites and consumers into r10's own p3/p4 deliverables, while the newly added ownership/order section assigns those deliverables to independent r3, r4, and r6 phases. this creates two inconsistent sources of truth for implementation ownership and phase completion. |
There was a problem hiding this comment.
Actionable comments posted: 15
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/plans-skeleton/plan-refactor-c2s-gate-v1.md (1)
19-25: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win补全 skeleton plan 的 §10 实施工作流。
docs/CLAUDE.md规定 scope ≥ 4 PR 的 plan 必须在末尾写§10 实施工作流。这两个 skeleton plan 都分 P0–P4（共 4 个 PR），且docs/plans-skeleton/plan-refactor-c2s-gate-v1.md、docs/plans-skeleton/plan-refactor-qi-ledger-v1.md现有内容只有开放问题，没有§10。在两档文件末尾补充多 PR 依赖顺序、子 agent 配置、CR 等待协议与§10.N 单次 consume-plan 全自动到 merge。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plans-skeleton/plan-refactor-c2s-gate-v1.md` around lines 19 - 25, 在 docs/plans-skeleton/plan-refactor-c2s-gate-v1.md（19-25）和 docs/plans-skeleton/plan-refactor-qi-ledger-v1.md（21-27）末尾补充 §10 实施工作流；为各自 P0–P4 明确多 PR 依赖顺序、子 agent 配置、CR 等待协议，并加入 §10.N 单次 consume-plan 全自动到 merge 流程，保持与 docs/CLAUDE.md 的要求一致。Sources: Coding guidelines, Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/plan-refactor-inventory-core-v1.md`:
- Line 71: Update the documented incoming-only R5 attrition transfer flow to
explicitly use qi_physics::ledger::QiTransfer, qi_release_to_zone, and
qi_excretion, including both placement-only and merge paths. Freeze before/after
ledger assertions and total-quantity conservation checks, and state that no qi
fields may be generated, destroyed, or reset.
- Around line 1-3: Split the changes into separate PRs so each PR modifies only
one plan: retain the R10 active-plan changes in
docs/plan-refactor-inventory-core-v1.md lines 1-3, and move the
persistence-skeleton changes from
docs/plans-skeleton/plan-refactor-persistence-slices-v1.md lines 24-27 into
another PR. If shared research is required, document the explicit exception
rationale and execution order.
- Around line 1-3: 将本次变更限制为单个 plan 文件：从当前 PR 移除对另一个 plan 的修改，并将其拆分到独立
PR；如果确属已批准的共享调研基线例外，则在 PR 说明中明确例外原因及两个变更的执行顺序。
- Around line 123-142: 在文档的 active plan 中补充对应的“§N 开放问题”和“§N.1
决议”章节，逐项记录每个问题的结论、实施方案与边界条件，并为每项提供文件:行号和 plan 章节的双锚点；保留现有 §9 absorption audit 与
§10 deferred-to-implementation-wave 内容，但不要将其作为逐项决议的替代。
- Around line 67-73: 在对应的 pickup、rotate、pack feedback 以及 dropped sync
阶段补充玩家可感知行为规格，涵盖粒子、音效、HUD、环境效果、动画和 narration。为每类反馈明确成功与失败路径的触发条件，并将这些规范写入
P3/P4；保留现有动作回执、snapshot 规则和 bot 场景定义。
- Around line 48-57: 为 DroppedLootRegistry 的 try_insert/try_insert_batch 定义并冻结
typed admission context，至少包含 PlayerId、OwnerOnly/Public、writer 类型、reservation 类型和
transaction id；让 admission 根据这些字段执行玩家配额与系统保留容量规则，并使 batch reservation 在任何 source
mutation 前原子完成，超限返回 {current, required, limit} 且不改变状态或数据库。
- Around line 138-142: 为 docs/plan-refactor-inventory-core-v1.md 的 §10 及
docs/plans-skeleton/plan-refactor-persistence-slices-v1.md
末尾补齐统一的“实施工作流”：按依赖顺序明确 PR 推进、plan ownership，并规定单次 /consume-plan 自动持续推进至最终归档；保留现有
deferred 约束，同时确保两个 scope 达到 4 个以上 PR 的 plan 都包含完整 §10。
- Around line 123-136: 为“吸收边界与 P0 验真”表格中的每个 plan 条目补充可复核的双重证据锚点：对应源文件及精确行号，以及相关
plan 章节；同时覆盖“不吸收”条目或明确其证据位置。仅在所有 live/fixed/invalid 结论都具备这些锚点后，更新 P0
完成声明，保留现有结论与证据描述。
- Line 63: 更新 R3 migration/hydration 及所有 DroppedLootEntry 生产路径（尤其是
rebuild_and_drop_overflow），使缺失 visibility 时按来源 fail closed：仅能确定为公共或系统公开掉落时补
Public，其余旧的玩家脚下 overflow 等来源不得默认公开，并保留 owner 字段原值且不得从请求推断。
In `@docs/plans-skeleton/plan-refactor-c2s-gate-v1.md`:
- Line 40: 更新 gate_cross_dimension 验收场景，先在主世界创建真实 dropped-loot，再从 TSY 维度发起
pickup 请求；断言服务端基于 CurrentDimension 返回维度不一致原因，而非 not_found。补充断言该请求未提交
InventoryTxn、未移除 dropped-loot registry 条目、未改变 inventory 或 Qi，并且未发送 accepted
event。
- Line 23: 扩展 docs/plan-refactor-inventory-core-v1.md 中的授权输入要求，明确 R10
PickupAuthorization 的模块路径、构造函数、字段及其基于 ECS CurrentDimension、权威位置/观察范围和
owner/private permission 的来源；同时在 P0/R6 冻结统一 request_rejected 与拾取专用拒绝回执的结构及 emit
API，确保 handler 先完成授权并将 accepted/rejected outcome 交给 R6，再调用拾取事务。
In `@docs/plans-skeleton/plan-refactor-persistence-slices-v1.md`:
- Around line 24-27: 调整计划中的 canonical sequence，将 `R4 handler/pickup consumer` 排在
`R3 P4 legacy consumer` 之前，即改为 `... → R4 handler/pickup consumer → R3 P4 legacy
consumer →`；同步确保 `R3 P4` 的 inventory migration consumer 作为该顺序中的后置验收项，并保留其对 R4
handler/pickup consumer、R5 P3 和 R6 P4 的依赖关系。
In `@docs/plans-skeleton/plan-refactor-qi-ledger-v1.md`:
- Line 26: 将 P3 批次 B 的 attrition 损耗归还流程绑定到 qi_physics::ledger::QiTransfer
账务路径，并使用 qi_release_to_zone 完成释放；禁止直接写入 Zone.spirit_qi，确保 incoming-only pickup
attrition 的损耗通过 ledger 守恒归还 zone。
In `@docs/plans-skeleton/plan-refactor-wire-s2c-v1.md`:
- Line 25: Update the inventory receipt contract portion of the plan to select
one canonical receipt symbol instead of allowing “InventoryEventV1::Moved or
equivalent.” Define its schema/version, request identity, result revision,
authoritative item view, and rejected-receipt fields, and require the same
contract across server emit, Fabric InventoryEventHandler, Python decoder, and
R4 handler.
- Around line 22-28: 统一 P1 与 R10 对 dropped-loot payload 复用规则的表述：明确先按 canonical
visibility key（dimension/range/owner）投影，再为每个 key 独立排序并编码一次，仅复用于该 key 的
recipients，禁止跨 key 复用未投影或已编码 payload。
---
Outside diff comments:
In `@docs/plans-skeleton/plan-refactor-c2s-gate-v1.md`:
- Around line 19-25: 在 docs/plans-skeleton/plan-refactor-c2s-gate-v1.md（19-25）和
docs/plans-skeleton/plan-refactor-qi-ledger-v1.md（21-27）末尾补充 §10 实施工作流；为各自 P0–P4
明确多 PR 依赖顺序、子 agent 配置、CR 等待协议，并加入 §10.N 单次 consume-plan 全自动到 merge 流程，保持与
docs/CLAUDE.md 的要求一致。
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: d51b5066-193b-427e-9032-60c1a093faca
📒 Files selected for processing (6)
docs/plan-refactor-inventory-core-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-inventory-core-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.md
💤 Files with no reviewable changes (1)
- docs/plans-skeleton/plan-refactor-inventory-core-v1.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
docs/**/*.md
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.md: 新 plan 头部必须写明接入面：进料、出料、复用的共享类型/event/schema、server/agent/client 跨仓库契约，以及对应的worldview.md锚点。
涉及真元、灵气、衰减、逸散、半衰、距离损耗、排斥或吸力的 plan，必须调用qi_physics；新物理常数和公式必须先扩展qi_physics，不得在功能 plan 中重复实现。
所有真元/灵气流动必须遵守守恒律并通过qi_physics::ledger::QiTransfer；释放使用qi_release_to_zone，吸收使用qi_excretion，不得凭空生成或销毁真元。
涉及玩家可感知行为的 plan，必须在对应机制阶段中内联可直接实现的粒子、音效、HUD、环境、动画和 narration 规格；不得将视听内容笼统推迟到独立阶段。纯 server 逻辑 plan 例外。
每份 plan 必须列出开放问题；实施前必须追加§N.1 决议，逐项给出结论、实施方案、边界条件，并以文件:行号和 plan 章节双锚点落地。
scope 大于或等于 4 个 PR 的 plan，必须在末尾包含§10 实施工作流，并按依赖顺序在一个 plan 内序列化多个 PR，不得拆成多个 plan。
涉及 NBT 建筑、worldgen layout 或复杂视觉资产的 TODO，必须完成三轮提交：(round 1/3)、(round 2/3)、(round 3/3)；终轮提交必须包含拼写准确的<PROMISE>担保块。
§10 最末必须包含“单次 consume-plan 全自动到 merge”章节，明确用户提交/consume-plan后即可等待最终归档至docs/finished_plans/。一个 PR 只允许修改一个 plan；
/consume-plan只能追加 Finish Evidence 或执行允许的 plan 归档移动，不得自动修改其他 docs 文件、CLAUDE.md或 worldview 文档。
Files:
docs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plans-skeleton/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
新建 plan 前必须先阅读
docs/CLAUDE.md；骨架 plan 必须包含主题和 P0/P1 等阶段总览。
Files:
docs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
**/*.{rs,ts,tsx,java,json,md}
📄 CodeRabbit inference engine (CLAUDE.md)
唯一真货币是骨币；矿物是交易筹码，灵石是燃料/衰变物，金银不是货币。
Files:
docs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plan-refactor-inventory-core-v1.md
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: 禁止git stash push后不执行对应git stash pop；不得留下孤儿 WIP stash。
每个逻辑单元使用中文 atomic commit；agent 产生的每个 commit 必须包含真实模型 ID 的Model:trailer。
未经明确确认不得执行 force push、hard reset、amend、交互式 rebase、批量删除/移动文件或依赖版本/生产配置修改；严禁--no-verify、--no-gpg-sign及关闭签名。
PR review 只能通过独立评论/review触发；不得等待 Codex，review 修改后必须重新等待 re-review。
Files:
docs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plan-*.md
📄 CodeRabbit inference engine (CLAUDE.md)
docs/plan-*.md: Active plan 每个阶段必须写出可核验的模块路径、类型/函数、测试、schema、Redis key 或跨仓库契约 symbol。
plan 归档前必须所有阶段标记为✅ YYYY-MM-DD并补充严格标题为## Finish Evidence的证据章节。
Files:
docs/plan-refactor-inventory-core-v1.md
🧠 Learnings (3)
📚 Learning: 2026-07-17T00:31:10.779Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:1-1
Timestamp: 2026-07-17T00:31:10.779Z
Learning: 在审查该仓库 `docs/plans-skeleton/` 下的“docs-only skeleton plan”创建类 PR 时：先核对 `docs/CLAUDE.md` 中“Plan 消费规范”，并逐份查看本计划文档里的“§10 实施工作流”，确认后续实施阶段是否会遵循“每个 PR 只修改一个 plan”，且实施/归档时不会出现跨 plan 的修改。该规则不适用于用户显式指定、共享调研基线且计划之间存在互相交叉引用的 skeleton plan 同批创建 PR；对这类情况应按实际交叉引用关系放宽，确保仍能按独立或约定的序列化方式推进。
Applied to files:
docs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
📚 Learning: 2026-07-17T00:31:13.643Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:81-85
Timestamp: 2026-07-17T00:31:13.643Z
Learning: 审核 docs/plans-skeleton/*.md 下的 skeleton 草案 PR 时：不得要求作者在“§N 开放问题（P0 决策门前需收口）”核查完成之前提前填写对应的“§N.1 决议”。仅当计划进入 active 且 P0 实施前，已由 Explore agent 并行核查代码现状后，才允许追加“§N.1 决议”，且该决议需包含结论、实施方案、边界条件，并使用“文件:行号 + plan 章节”的双锚点格式。
Applied to files:
docs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
📚 Learning: 2026-07-22T02:11:59.191Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1247
File: docs/plans-skeleton/plan-bughunt-animal-air-spawn-gravity-v1.md:0-0
Timestamp: 2026-07-22T02:11:59.191Z
Learning: 在 `docs/plans-skeleton/` 目录下的计划状态行中，若起草日期同时涉及 UTC 与本地日期（例如时区换算后可能跨到不同日期），请在该行中同时标注 UTC 起草日与本地起草日。这样可以避免基于 UTC 的时间基准在 GitHub/CodeRabbit 审查时将本地日期误判为“未来日期”。
Applied to files:
docs/plans-skeleton/plan-refactor-qi-ledger-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.md
🔇 Additional comments (4)
docs/plans-skeleton/plan-refactor-wire-s2c-v1.md (3)
21-23: 补全dropped_loot_sync的可执行重发语义。Line 23 仍只定义“缺页/混 revision 保留旧视图并请求/等待重发”。文档没有定义重发请求字段、服务端重发条件、客户端超时、重试上限、重复页丢弃、乱序缓冲或旧
snapshot_revision丢弃规则。当前
scripts/bot/proto_min.py:_dropped_loot_sync也只返回drops，无法验证snapshot_revision/page_index/page_count。请在 plan 和 bot 验收中固定这些规则。该问题与历史 review comment 相同，当前文本仍未提供可执行语义。#!/bin/bash set -euo pipefail sed -n '21,26p' docs/plans-skeleton/plan-refactor-wire-s2c-v1.md rg -n -C 8 \ 'def _dropped_loot_sync|snapshot_revision|page_index|page_count|resend|retry|timeout|stale|monotonic' \ scripts/bot docs --glob '*.py' --glob '*.md'
24-24: LGTM!Also applies to: 33-33
21-26: 📐 Maintainability & Code Quality在 scope 明确前不要假定缺少 §10。
本文档未声明本 plan 拆分为 4+ PR；若拆分为 4+ PR，则需在末尾增加依赖顺序的
§10 实施工作流，并在最后一节写明“单次 consume-plan 全自动到 merge”。docs/plans-skeleton/plan-refactor-qi-ledger-v1.md (1)
46-46: LGTM!
| ## 4. Pickup transaction + authorization | ||
|
|
||
| R4 从 ECS 构造不可由 client 覆盖的 `PickupAuthorization`：player UUID、`CurrentDimension`、authoritative position/observation range、owner/private permission、server-resolved entry、revision/anti-replay fact。txn 重新验证 entry/instance、同维、距离/zone、权限和 freshness；知道 dropped id、曾收到 sync 或跨维相同 XYZ 都不构成授权。 | ||
|
|
||
| 顺序固定：authorize + validate merge/placement/capacity → staged attach/merge 与 incoming-only R5 attrition transfer（item qi → authoritative zone + ledger）→ 同一 durable transaction 原子提交 attrited item、inventory revision、zone balance/ledger 与 dropped delete → receipt。任一步失败或崩溃恢复都不得只应用其中一侧；drop 保留且可按 transaction id 重试。placement-only 与 merge 都必须覆盖。 | ||
|
|
||
| 所有 attach 必须 `validate_attach_fits` 后 `attach_at_location`，删除 `(0,0)` 强塞。move/rotate/pack accepted outcome 含 request id、revision、instance/from/to、权威 item view；rejected outcome 含 reason/instance/from/to。snapshot 仅作状态修正，不是动作级反馈。 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major
把玩家可感知行为规格写入 P3/P4。
当前只定义了动作回执、snapshot 规则和 bot 场景名称。缺少粒子、音效、HUD、环境效果、动画、narration，以及成功和失败路径的触发条件。请把这些规格直接写入对应的 pickup、rotate、pack feedback 和 dropped sync 阶段。
Also applies to: 115-121
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/plan-refactor-inventory-core-v1.md` around lines 67 - 73, 在对应的
pickup、rotate、pack feedback 以及 dropped sync 阶段补充玩家可感知行为规格，涵盖粒子、音效、HUD、环境效果、动画和
narration。为每类反馈明确成功与失败路径的触发条件，并将这些规范写入 P3/P4；保留现有动作回执、snapshot 规则和 bot 场景定义。
Source: Coding guidelines
|
|
||
| R4 从 ECS 构造不可由 client 覆盖的 `PickupAuthorization`：player UUID、`CurrentDimension`、authoritative position/observation range、owner/private permission、server-resolved entry、revision/anti-replay fact。txn 重新验证 entry/instance、同维、距离/zone、权限和 freshness；知道 dropped id、曾收到 sync 或跨维相同 XYZ 都不构成授权。 | ||
|
|
||
| 顺序固定：authorize + validate merge/placement/capacity → staged attach/merge 与 incoming-only R5 attrition transfer（item qi → authoritative zone + ledger）→ 同一 durable transaction 原子提交 attrited item、inventory revision、zone balance/ledger 与 dropped delete → receipt。任一步失败或崩溃恢复都不得只应用其中一侧；drop 保留且可按 transaction id 重试。placement-only 与 merge 都必须覆盖。 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major
显式绑定 qi_physics API。
incoming-only R5 attrition transfer 仍是泛化描述。请明确使用 qi_physics::ledger::QiTransfer、qi_release_to_zone 和 qi_excretion，并冻结 before/after ledger 与总量守恒断言。不得生成、销毁或重置真元字段。
#!/bin/bash
set -euo pipefail
rg -n -C 6 '\b(QiTransfer|qi_release_to_zone|qi_excretion|release_dormant_qi_to_zone)\b' \
server/src docs🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/plan-refactor-inventory-core-v1.md` at line 71, Update the documented
incoming-only R5 attrition transfer flow to explicitly use
qi_physics::ledger::QiTransfer, qi_release_to_zone, and qi_excretion, including
both placement-only and merge paths. Freeze before/after ledger assertions and
total-quantity conservation checks, and state that no qi fields may be
generated, destroyed, or reset.
Source: Coding guidelines
Central reviewDecision: The review could not complete safely. No approval or code finding was inferred from the failed stages.
|
Central reviewDecision: The review could not complete safely. No approval or code finding was inferred from the failed stages.
|
Central reviewDecision: Validated findings[major] Persisted owner/visibility fields have no legacy dropped-loot migration consumer
The new contract requires durable Root cause: the plan adds required persisted dropped-loot fields but does not assign the corresponding existing-row migration/deserialization bridge to any implementation phase or acceptance test. [major] R6 P1 is scheduled before its R10 visibility metadata provider
R6 P1 now requires dropped-loot snapshots to be built and sent in pages, while line 28 requires the builder to project by recipient dimension/range/owner and only reuse pages for an identical visibility key. The authoritative fields enabling that projection are introduced by R10 ( Root cause: the plan assigns recipient-specific dropped-loot sync to an r6 phase that has no dependency on the r10-owned model fields required to implement that sync end to end. [major] Visibility tests omit Public and authorized-admin positive cases
The new contract defines two visibility variants and three relevant authorization outcomes: Root cause: the acceptance matrix does not pin every variant and permission branch of the newly frozen dropped-loot visibility contract. it covers the private owner/non-owner split but omits an explicit |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/plan-refactor-inventory-core-v1.md (2)
27-38: 🗄️ Data Integrity & Integration | 🟠 Major补齐
InventoryTxnrequest 与 allocator 的原子契约。
DeliveryRequest、ConsumeRequest、PickupRequest和PickupAuthorization仍是未展开的类型。计划也没有定义 request id、source revision、数量/实例集合，以及InventoryInstanceIdAllocator的 staged/commit 边界。请冻结这些字段，并要求 allocator 与 inventory 同时提交；任一步失败，两者都必须保持不变。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plan-refactor-inventory-core-v1.md` around lines 27 - 38, 补充并冻结 DeliveryRequest、ConsumeRequest、PickupRequest、PickupAuthorization 的字段契约，至少包含 request id、source revision，以及数量或实例集合等操作所需数据；同时定义 InventoryInstanceIdAllocator 的 staged/commit 边界。要求 deliver、consume_checked、pickup_and_merge 在 staged view 中同时暂存 inventory、revision/session/material/registry 与 allocator 变更，仅在全部校验和持久化成功后共同提交；任一步失败时两者及相关状态均保持不变。
84-94: 📐 Maintainability & Code Quality | 🟠 Major本 PR 违反“一个 PR 只修改一个 plan”。
docs/plan-refactor-inventory-core-v1.md#L84-L94：保留 R10 active plan 修改，并移除本 PR 对其他 plan 的修改。docs/plans-skeleton/plan-refactor-persistence-slices-v1.md#L63-L67：将 R3 skeleton 修改移至独立 PR。docs/plans-skeleton/plan-refactor-wire-s2c-v1.md#L38-L40：将 R6 skeleton 修改移至独立 PR。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plan-refactor-inventory-core-v1.md` around lines 84 - 94, Keep the R10 active-plan changes in docs/plan-refactor-inventory-core-v1.md (lines 84-94), but remove this PR’s edits from docs/plans-skeleton/plan-refactor-persistence-slices-v1.md (lines 63-67) and docs/plans-skeleton/plan-refactor-wire-s2c-v1.md (lines 38-40); those R3 and R6 skeleton updates must move to separate PRs.Source: Coding guidelines
♻️ Duplicate comments (5)
docs/plan-refactor-inventory-core-v1.md (4)
138-142: 📐 Maintainability & Code Quality | 🟠 Major将第 10 节改为规定的
§10 实施工作流。R10 包含 P1–P4，达到至少 4 个 PR 的范围。当前
## 10. Deferred-to-implementation-wave没有按依赖序列化 PR，也没有规定单次/consume-plan自动推进至最终归档docs/finished_plans/。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plan-refactor-inventory-core-v1.md` around lines 138 - 142, 将文档中的“## 10. Deferred-to-implementation-wave”重命名并改写为规定的“§10 实施工作流”，纳入 R10 的 P1–P4 至少四个 PR，按依赖顺序明确各 PR 的实施阶段，并规定单次 `/consume-plan` 需自动推进至最终归档 `docs/finished_plans/`。Source: Coding guidelines
123-136: 📐 Maintainability & Code Quality | 🟠 Major为 absorption audit 每一项补齐双锚点。
表格目前只有 plan 短名和描述，没有对应的源文件:行号及 plan 章节。这样无法独立复核
live/fixed/invalid结论。请为每一行补充精确双锚点，并覆盖不吸收项后再将其作为 P0 证据。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plan-refactor-inventory-core-v1.md` around lines 123 - 136, 更新“吸收边界与 P0 验真”章节中的审计表，为每个吸收项及“不吸收”项补充精确的源文件与行号锚点，以及对应的 plan 章节锚点。确保每行都能独立复核 live/fixed/invalid 结论，并在完成全部条目覆盖后再将该表作为 P0 证据。
48-57: 🗄️ Data Integrity & Integration | 🟠 Major冻结
DroppedLootRegistry的 typed admission context。
try_insert和try_insert_batch只有方法名，没有输入和返回契约。PlayerId、OwnerOnly/Public、writer 类型、reservation 类型和 transaction id 必须进入同一 typed context。否则无法验证玩家 quota、system-reserved capacity，以及 source mutation 前的原子 batch reservation。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plan-refactor-inventory-core-v1.md` around lines 48 - 57, 在 DroppedLootRegistry 的设计中冻结 typed admission context，并让 try_insert 与 try_insert_batch 显式接收该上下文。上下文应统一包含 PlayerId（适用时）、OwnerOnly/Public、writer 类型、reservation 类型及 transaction id；同时明确返回成功或包含 current、required、limit 的超限结果，以支持玩家配额、系统保留容量校验和 source mutation 前的原子批量 reservation。
138-142: 📐 Maintainability & Code Quality | 🟠 Major为所有达到 4 个 PR 范围的 plan 补齐统一的
§10 实施工作流。
docs/plan-refactor-inventory-core-v1.md#L138-L142：将 deferred 说明扩展为按依赖序列化 PR、明确 owner，并规定单次/consume-plan自动归档至docs/finished_plans/。docs/plans-skeleton/plan-refactor-persistence-slices-v1.md#L63-L67：在 skeleton 末尾加入相同的§10 实施工作流。docs/plans-skeleton/plan-refactor-wire-s2c-v1.md#L38-L40：在 skeleton 末尾加入相同的§10 实施工作流。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plan-refactor-inventory-core-v1.md` around lines 138 - 142, 三个达到 4 个 PR 范围的 plan 尚未统一定义 §10 实施工作流。请在 docs/plan-refactor-inventory-core-v1.md（138-142）扩展现有 deferred 说明，并在 docs/plans-skeleton/plan-refactor-persistence-slices-v1.md（63-67）和 docs/plans-skeleton/plan-refactor-wire-s2c-v1.md（38-40）末尾加入相同的 §10 实施工作流，明确按依赖顺序串行化 PR、指定 owner，并规定单次 /consume-plan 后自动归档至 docs/finished_plans/。Source: Coding guidelines
docs/plans-skeleton/plan-refactor-wire-s2c-v1.md (1)
24-25: 🗄️ Data Integrity & Integration | 🟠 Major选定唯一的 inventory receipt symbol。
InventoryEventV1::Moved（或等价 accepted receipt）仍允许多个实现选择不同类型和字段。当前 server producer 已使用InventoryEventV1::Moved（server/src/network/client_request_handler.rs:15748-15783）。请选定一个 canonical versioned symbol，并冻结 request identity、result revision、authoritative item view 和 rejected receipt 字段，供 server、FabricInventoryEventHandler、Python decoder 和 R4 handler 共用。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/plans-skeleton/plan-refactor-wire-s2c-v1.md` around lines 24 - 25, 统一 inventory receipt 的契约符号，选定并固定一个 canonical versioned symbol，优先复用现有 server producer 使用的 InventoryEventV1::Moved。明确并冻结 request identity、result revision、authoritative item view 及 rejected receipt 字段，并让 server、Fabric InventoryEventHandler、Python decoder 与 R4 handler 全部引用该同一契约，移除“或等价 accepted receipt”等多实现表述。
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/plan-refactor-inventory-core-v1.md`:
- Line 82: 统一两份计划文档中的 dropped-loot 迁移与 hydration consumer 规则：仅当来源明确为公共掉落时，缺失
visibility 才补为 Public；玩家 overflow 或其他无法确认来源的记录必须 fail closed，沿用隔离或拒绝路径，不得默认公开。更新
docs/plan-refactor-inventory-core-v1.md 第82行和
docs/plans-skeleton/plan-refactor-persistence-slices-v1.md
第27行，并确保两处使用相同的来源判定逻辑。
---
Outside diff comments:
In `@docs/plan-refactor-inventory-core-v1.md`:
- Around line 27-38: 补充并冻结
DeliveryRequest、ConsumeRequest、PickupRequest、PickupAuthorization 的字段契约，至少包含
request id、source revision，以及数量或实例集合等操作所需数据；同时定义 InventoryInstanceIdAllocator 的
staged/commit 边界。要求 deliver、consume_checked、pickup_and_merge 在 staged view 中同时暂存
inventory、revision/session/material/registry 与 allocator
变更，仅在全部校验和持久化成功后共同提交；任一步失败时两者及相关状态均保持不变。
- Around line 84-94: Keep the R10 active-plan changes in
docs/plan-refactor-inventory-core-v1.md (lines 84-94), but remove this PR’s
edits from docs/plans-skeleton/plan-refactor-persistence-slices-v1.md (lines
63-67) and docs/plans-skeleton/plan-refactor-wire-s2c-v1.md (lines 38-40); those
R3 and R6 skeleton updates must move to separate PRs.
---
Duplicate comments:
In `@docs/plan-refactor-inventory-core-v1.md`:
- Around line 138-142: 将文档中的“## 10.
Deferred-to-implementation-wave”重命名并改写为规定的“§10 实施工作流”，纳入 R10 的 P1–P4 至少四个
PR，按依赖顺序明确各 PR 的实施阶段，并规定单次 `/consume-plan` 需自动推进至最终归档 `docs/finished_plans/`。
- Around line 123-136: 更新“吸收边界与 P0 验真”章节中的审计表，为每个吸收项及“不吸收”项补充精确的源文件与行号锚点，以及对应的
plan 章节锚点。确保每行都能独立复核 live/fixed/invalid 结论，并在完成全部条目覆盖后再将该表作为 P0 证据。
- Around line 48-57: 在 DroppedLootRegistry 的设计中冻结 typed admission context，并让
try_insert 与 try_insert_batch 显式接收该上下文。上下文应统一包含
PlayerId（适用时）、OwnerOnly/Public、writer 类型、reservation 类型及 transaction
id；同时明确返回成功或包含 current、required、limit 的超限结果，以支持玩家配额、系统保留容量校验和 source mutation
前的原子批量 reservation。
- Around line 138-142: 三个达到 4 个 PR 范围的 plan 尚未统一定义 §10 实施工作流。请在
docs/plan-refactor-inventory-core-v1.md（138-142）扩展现有 deferred 说明，并在
docs/plans-skeleton/plan-refactor-persistence-slices-v1.md（63-67）和
docs/plans-skeleton/plan-refactor-wire-s2c-v1.md（38-40）末尾加入相同的 §10
实施工作流，明确按依赖顺序串行化 PR、指定 owner，并规定单次 /consume-plan 后自动归档至 docs/finished_plans/。
In `@docs/plans-skeleton/plan-refactor-wire-s2c-v1.md`:
- Around line 24-25: 统一 inventory receipt 的契约符号，选定并固定一个 canonical versioned
symbol，优先复用现有 server producer 使用的 InventoryEventV1::Moved。明确并冻结 request
identity、result revision、authoritative item view 及 rejected receipt 字段，并让
server、Fabric InventoryEventHandler、Python decoder 与 R4 handler 全部引用该同一契约，移除“或等价
accepted receipt”等多实现表述。
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 33cb301c-abc4-4bf8-b27a-ff202e04bdd8
📒 Files selected for processing (3)
docs/plan-refactor-inventory-core-v1.mddocs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
docs/**/*.md
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.md: 新 plan 头部必须写明接入面：进料、出料、复用的共享类型/event/schema、server/agent/client 跨仓库契约，以及对应的worldview.md锚点。
涉及真元、灵气、衰减、逸散、半衰、距离损耗、排斥或吸力的 plan，必须调用qi_physics；新物理常数和公式必须先扩展qi_physics，不得在功能 plan 中重复实现。
所有真元/灵气流动必须遵守守恒律并通过qi_physics::ledger::QiTransfer；释放使用qi_release_to_zone，吸收使用qi_excretion，不得凭空生成或销毁真元。
涉及玩家可感知行为的 plan，必须在对应机制阶段中内联可直接实现的粒子、音效、HUD、环境、动画和 narration 规格；不得将视听内容笼统推迟到独立阶段。纯 server 逻辑 plan 例外。
每份 plan 必须列出开放问题；实施前必须追加§N.1 决议，逐项给出结论、实施方案、边界条件，并以文件:行号和 plan 章节双锚点落地。
scope 大于或等于 4 个 PR 的 plan，必须在末尾包含§10 实施工作流，并按依赖顺序在一个 plan 内序列化多个 PR，不得拆成多个 plan。
涉及 NBT 建筑、worldgen layout 或复杂视觉资产的 TODO，必须完成三轮提交：(round 1/3)、(round 2/3)、(round 3/3)；终轮提交必须包含拼写准确的<PROMISE>担保块。
§10 最末必须包含“单次 consume-plan 全自动到 merge”章节，明确用户提交/consume-plan后即可等待最终归档至docs/finished_plans/。一个 PR 只允许修改一个 plan；
/consume-plan只能追加 Finish Evidence 或执行允许的 plan 归档移动，不得自动修改其他 docs 文件、CLAUDE.md或 worldview 文档。
Files:
docs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plans-skeleton/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
新建 plan 前必须先阅读
docs/CLAUDE.md；骨架 plan 必须包含主题和 P0/P1 等阶段总览。
Files:
docs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.md
**/*.{rs,ts,tsx,java,json,md}
📄 CodeRabbit inference engine (CLAUDE.md)
唯一真货币是骨币；矿物是交易筹码，灵石是燃料/衰变物，金银不是货币。
Files:
docs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plan-refactor-inventory-core-v1.md
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: 禁止git stash push后不执行对应git stash pop；不得留下孤儿 WIP stash。
每个逻辑单元使用中文 atomic commit；agent 产生的每个 commit 必须包含真实模型 ID 的Model:trailer。
未经明确确认不得执行 force push、hard reset、amend、交互式 rebase、批量删除/移动文件或依赖版本/生产配置修改；严禁--no-verify、--no-gpg-sign及关闭签名。
PR review 只能通过独立评论/review触发；不得等待 Codex，review 修改后必须重新等待 re-review。
Files:
docs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plan-*.md
📄 CodeRabbit inference engine (CLAUDE.md)
docs/plan-*.md: Active plan 每个阶段必须写出可核验的模块路径、类型/函数、测试、schema、Redis key 或跨仓库契约 symbol。
plan 归档前必须所有阶段标记为✅ YYYY-MM-DD并补充严格标题为## Finish Evidence的证据章节。
Files:
docs/plan-refactor-inventory-core-v1.md
🧠 Learnings (3)
📚 Learning: 2026-07-17T00:31:10.779Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:1-1
Timestamp: 2026-07-17T00:31:10.779Z
Learning: 在审查该仓库 `docs/plans-skeleton/` 下的“docs-only skeleton plan”创建类 PR 时：先核对 `docs/CLAUDE.md` 中“Plan 消费规范”，并逐份查看本计划文档里的“§10 实施工作流”，确认后续实施阶段是否会遵循“每个 PR 只修改一个 plan”，且实施/归档时不会出现跨 plan 的修改。该规则不适用于用户显式指定、共享调研基线且计划之间存在互相交叉引用的 skeleton plan 同批创建 PR；对这类情况应按实际交叉引用关系放宽，确保仍能按独立或约定的序列化方式推进。
Applied to files:
docs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.md
📚 Learning: 2026-07-17T00:31:13.643Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:81-85
Timestamp: 2026-07-17T00:31:13.643Z
Learning: 审核 docs/plans-skeleton/*.md 下的 skeleton 草案 PR 时：不得要求作者在“§N 开放问题（P0 决策门前需收口）”核查完成之前提前填写对应的“§N.1 决议”。仅当计划进入 active 且 P0 实施前，已由 Explore agent 并行核查代码现状后，才允许追加“§N.1 决议”，且该决议需包含结论、实施方案、边界条件，并使用“文件:行号 + plan 章节”的双锚点格式。
Applied to files:
docs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.md
📚 Learning: 2026-07-22T02:11:59.191Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1247
File: docs/plans-skeleton/plan-bughunt-animal-air-spawn-gravity-v1.md:0-0
Timestamp: 2026-07-22T02:11:59.191Z
Learning: 在 `docs/plans-skeleton/` 目录下的计划状态行中，若起草日期同时涉及 UTC 与本地日期（例如时区换算后可能跨到不同日期），请在该行中同时标注 UTC 起草日与本地起草日。这样可以避免基于 UTC 的时间基准在 GitHub/CodeRabbit 审查时将本地日期误判为“未来日期”。
Applied to files:
docs/plans-skeleton/plan-refactor-persistence-slices-v1.mddocs/plans-skeleton/plan-refactor-wire-s2c-v1.md
🪛 LanguageTool
docs/plan-refactor-inventory-core-v1.md
[style] ~108-~108: Consider using the more formal “until”.
Context: ...hot-only baseline 不通过。 9. forge 深链保留；另锁 /give hoe_iron → 新 snapshot → 真实非零 instance → held/equip → lingtian_start_till，禁止 instance_id=0 或任意 server-data 冒充成...
(TILL)
🔇 Additional comments (5)
docs/plan-refactor-inventory-core-v1.md (2)
1-14: LGTM!
61-73: LGTM!Also applies to: 96-121
docs/plans-skeleton/plan-refactor-persistence-slices-v1.md (1)
53-62: LGTM!docs/plans-skeleton/plan-refactor-wire-s2c-v1.md (2)
21-22: LGTM!
33-33: LGTM!
Central reviewDecision: Validated findings[major] Pickup tests omit the required freshness and anti-replay contract
The new pickup contract requires Root cause: the acceptance matrix does not include a positive/negative pin for the newly declared pickup freshness and anti-replay contract, despite making those facts part of authoritative authorization. this leaves a security/state-transition requirement unprotected and permits the transaction implementation to omit freshness validation without failing the planned suite. [major] R4 P2 is scheduled before the pickup APIs it must consume
Following the documented phase order reaches this conflict: the master plan allows R4 after R6 P1 ( Root cause: the new pickup handler deliverable was assigned to r4 p2, but that phase still retains the old r6-p1-era scheduling and does not depend on the r10 p3 pickup provider, r5 p3 attrition api, and r6 p4 receipt api that the canonical r10 plan requires. [major] Rejected inventory receipts cannot be correlated to requests
The new outcome contract defines accepted move/rotate/pack outcomes with a request ID and revision, but defines rejected outcomes only as Root cause: the rejected producer-to-wire contract omits the request correlation identity (and authoritative result revision) that its consumers and acceptance scenarios require to associate feedback with a specific action. [major] Recipient context changes never revoke stale private loot snapshots
The new P1 contract says dropped-loot snapshots are sent on join and when dropped-loot content changes, then filtered by the recipient's current dimension/range/owner/admin authority. That projection also changes when the recipient moves, changes dimension, or gains/loses administrator permission even if the registry content is unchanged, but none of those events is specified as a rebuild/resend trigger. The P2 client contract retains its previous store until a complete newer revision arrives, so a recipient who saw an Root cause: the plan treats recipient-specific projection as a function only of dropped-loot registry changes and join, but omits invalidation and revision emission when recipient authority or observation context changes. because the client deliberately retains the last complete projection, server-side filtering at encode time cannot revoke already-sent private entries without those additional triggers. [major] Full snapshot per mutation remains multiplicative across recipient-specific projections
The new P1 contract sends a recipient-specific, paginated full snapshot on every dropped-loot content change and only reuses work for recipients with an exactly identical visibility key. The same diff permits 4,096 durable entries ( Root cause: the plan treats pagination and exact-key cache reuse as a resource bound, but still mandates rebuilding and sending complete recipient projections for every registry mutation. because range and owneronly authorization commonly make visibility keys recipient-specific, aggregate work scales multiplicatively with connected clients and registry size. the contract needs an explicit aggregate bound such as mutation coalescing/rate limiting plus incremental or spatially indexed projection updates, rather than full per-key snapshots on each change. [major] Dropped-loot metadata lands before legacy rows can be migrated
The plan requires Root cause: the schema/metadata rollout is separated from its backward-compatible persistence migration and ordered ahead of it, leaving an intermediate merged phase with incompatible legacy dropped-loot rows. [major] Add a C2S request ID before requiring correlated inventory receipts
The changed R6 P4 contract requires an accepted inventory receipt to carry a "request identity" so R4/bot/client can correlate the result with the triggering move. However, the real C2S contract has no such value to echo: Root cause: the plan adds response-side request correlation without adding a producer-side correlation identifier to the |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/plans-skeleton/plan-refactor-c2s-gate-v1.md`:
- Line 23: 在 docs/plans-skeleton/plan-refactor-c2s-gate-v1.md 的第23行，明确 gate
授权失败先发送 request_rejected，且不得调用 InventoryTxn 或 attrition；仅授权成功后转发 R10
事务结果。在同文件第40行补充验收要求：使用真实 dropped-loot，区分并断言维度不一致的拒绝原因，同时确认
inventory、Qi、registry、事务状态及 accepted event 均无变化。
- Line 23: Update the inventory pickup handler requirements in the plan to
distinguish pre-R10 authorization failures from R10 transaction rejections: when
PickupAuthorization fails, send the unified R6 request_rejected outcome directly
without invoking InventoryTxn or attrition; only after authorization succeeds
should the handler call R10 and forward its transaction result through R6.
- Around line 23-24: 在该计划文档末尾补充“§10 实施工作流”，按依赖顺序将 P1、P2、P3、P4 拆分为多个连续 PR，并明确每个
PR 的交付范围、前置依赖及验证要求；加入单次 consume-plan 从实施到自动合并的完整流程，以及完成后归档至 docs/finished_plans/
的最终步骤。
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 36bd6843-a8ee-4617-9950-1286c9bc920c
📒 Files selected for processing (2)
docs/plan-refactor-inventory-core-v1.mddocs/plans-skeleton/plan-refactor-c2s-gate-v1.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
docs/**/*.md
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.md: 新 plan 头部必须写明接入面：进料、出料、复用的共享类型/event/schema、server/agent/client 跨仓库契约，以及对应的worldview.md锚点。
涉及真元、灵气、衰减、逸散、半衰、距离损耗、排斥或吸力的 plan，必须调用qi_physics；新物理常数和公式必须先扩展qi_physics，不得在功能 plan 中重复实现。
所有真元/灵气流动必须遵守守恒律并通过qi_physics::ledger::QiTransfer；释放使用qi_release_to_zone，吸收使用qi_excretion，不得凭空生成或销毁真元。
涉及玩家可感知行为的 plan，必须在对应机制阶段中内联可直接实现的粒子、音效、HUD、环境、动画和 narration 规格；不得将视听内容笼统推迟到独立阶段。纯 server 逻辑 plan 例外。
每份 plan 必须列出开放问题；实施前必须追加§N.1 决议，逐项给出结论、实施方案、边界条件，并以文件:行号和 plan 章节双锚点落地。
scope 大于或等于 4 个 PR 的 plan，必须在末尾包含§10 实施工作流，并按依赖顺序在一个 plan 内序列化多个 PR，不得拆成多个 plan。
涉及 NBT 建筑、worldgen layout 或复杂视觉资产的 TODO，必须完成三轮提交：(round 1/3)、(round 2/3)、(round 3/3)；终轮提交必须包含拼写准确的<PROMISE>担保块。
§10 最末必须包含“单次 consume-plan 全自动到 merge”章节，明确用户提交/consume-plan后即可等待最终归档至docs/finished_plans/。一个 PR 只允许修改一个 plan；
/consume-plan只能追加 Finish Evidence 或执行允许的 plan 归档移动，不得自动修改其他 docs 文件、CLAUDE.md或 worldview 文档。
Files:
docs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plans-skeleton/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
新建 plan 前必须先阅读
docs/CLAUDE.md；骨架 plan 必须包含主题和 P0/P1 等阶段总览。
Files:
docs/plans-skeleton/plan-refactor-c2s-gate-v1.md
**/*.{rs,ts,tsx,java,json,md}
📄 CodeRabbit inference engine (CLAUDE.md)
唯一真货币是骨币；矿物是交易筹码，灵石是燃料/衰变物，金银不是货币。
Files:
docs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plan-refactor-inventory-core-v1.md
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: 禁止git stash push后不执行对应git stash pop；不得留下孤儿 WIP stash。
每个逻辑单元使用中文 atomic commit；agent 产生的每个 commit 必须包含真实模型 ID 的Model:trailer。
未经明确确认不得执行 force push、hard reset、amend、交互式 rebase、批量删除/移动文件或依赖版本/生产配置修改；严禁--no-verify、--no-gpg-sign及关闭签名。
PR review 只能通过独立评论/review触发；不得等待 Codex，review 修改后必须重新等待 re-review。
Files:
docs/plans-skeleton/plan-refactor-c2s-gate-v1.mddocs/plan-refactor-inventory-core-v1.md
docs/plan-*.md
📄 CodeRabbit inference engine (CLAUDE.md)
docs/plan-*.md: Active plan 每个阶段必须写出可核验的模块路径、类型/函数、测试、schema、Redis key 或跨仓库契约 symbol。
plan 归档前必须所有阶段标记为✅ YYYY-MM-DD并补充严格标题为## Finish Evidence的证据章节。
Files:
docs/plan-refactor-inventory-core-v1.md
🧠 Learnings (3)
📚 Learning: 2026-07-17T00:31:10.779Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:1-1
Timestamp: 2026-07-17T00:31:10.779Z
Learning: 在审查该仓库 `docs/plans-skeleton/` 下的“docs-only skeleton plan”创建类 PR 时：先核对 `docs/CLAUDE.md` 中“Plan 消费规范”，并逐份查看本计划文档里的“§10 实施工作流”，确认后续实施阶段是否会遵循“每个 PR 只修改一个 plan”，且实施/归档时不会出现跨 plan 的修改。该规则不适用于用户显式指定、共享调研基线且计划之间存在互相交叉引用的 skeleton plan 同批创建 PR；对这类情况应按实际交叉引用关系放宽，确保仍能按独立或约定的序列化方式推进。
Applied to files:
docs/plans-skeleton/plan-refactor-c2s-gate-v1.md
📚 Learning: 2026-07-17T00:31:13.643Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1218
File: docs/plans-skeleton/plan-skill-av-relink-v1.md:81-85
Timestamp: 2026-07-17T00:31:13.643Z
Learning: 审核 docs/plans-skeleton/*.md 下的 skeleton 草案 PR 时：不得要求作者在“§N 开放问题（P0 决策门前需收口）”核查完成之前提前填写对应的“§N.1 决议”。仅当计划进入 active 且 P0 实施前，已由 Explore agent 并行核查代码现状后，才允许追加“§N.1 决议”，且该决议需包含结论、实施方案、边界条件，并使用“文件:行号 + plan 章节”的双锚点格式。
Applied to files:
docs/plans-skeleton/plan-refactor-c2s-gate-v1.md
📚 Learning: 2026-07-22T02:11:59.191Z
Learnt from: Kizunad
Repo: Kizunad/Bong PR: 1247
File: docs/plans-skeleton/plan-bughunt-animal-air-spawn-gravity-v1.md:0-0
Timestamp: 2026-07-22T02:11:59.191Z
Learning: 在 `docs/plans-skeleton/` 目录下的计划状态行中，若起草日期同时涉及 UTC 与本地日期（例如时区换算后可能跨到不同日期），请在该行中同时标注 UTC 起草日与本地起草日。这样可以避免基于 UTC 的时间基准在 GitHub/CodeRabbit 审查时将本地日期误判为“未来日期”。
Applied to files:
docs/plans-skeleton/plan-refactor-c2s-gate-v1.md
🔇 Additional comments (3)
docs/plan-refactor-inventory-core-v1.md (3)
142-148: 将 deferred decisions 改为规定的开放问题与决议结构。当前四项只记录延期事项和理由。它们没有
§N 开放问题、§N.1 决议、逐项结论、实施方案、边界条件，也没有文件:行号 + plan 章节双锚点。请在实施前为每项补充这些内容。若决议仍由 R10、R6 或 R5 的 owning phase 完成，也要明确本阶段的结论、交接条件和失败边界。不要只保留“留待……决定”。
As per coding guidelines：每份 plan 必须列出开放问题；实施前必须追加
§N.1 决议，逐项给出结论、实施方案、边界条件，并以文件:行号和 plan 章节双锚点落地。Source: Coding guidelines
8-11: LGTM!
86-94: LGTM!
| - ⬜ P2 巨石拆分批次 A：巨型 match 拆为按域 handler 注册表（combat/production/world/social/npc 五组），行为不变，bot 场景锁住；inventory pickup handler 必须从 ECS `CurrentDimension`、authoritative position/observation range 与 owner/private permission 构造 R10 `PickupAuthorization`，禁止仅凭 client XYZ/instance id 调用 txn，且把 R10 accepted/rejected outcome 交给 R6 emit API。**本批次的 inventory pickup consumer 仅在 R10 P3 pickup/merge txn、R5 P3 attrition API 与 R6 P4 receipt API 均已合入后实施；此前不得以 mock 或旧 R6 P1 schema 接线。** | ||
| - ⬜ P3 巨石拆分批次 B + 全量挂 spec + 删旧：113 变体全部声明门禁（含显式 `no_gate` 声明，杜绝静默无门禁）；删除各域内联距离常量与重复维度判断。 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
补齐 §10 实施工作流。
当前计划把 P1、P2、P3、P4 列为四个实施批次。请在文末按依赖顺序序列化多个 PR，并加入“单次 consume-plan 全自动到 merge”及最终归档到 docs/finished_plans/ 的章节。当前文档在“开放问题”后结束。
As per coding guidelines：scope 大于或等于 4 个 PR 的 plan 必须在末尾包含 §10 实施工作流。Based on learnings：skeleton plan 审查必须核对 §10 的实施顺序和归档路径。
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/plans-skeleton/plan-refactor-c2s-gate-v1.md` around lines 23 - 24,
在该计划文档末尾补充“§10 实施工作流”，按依赖顺序将 P1、P2、P3、P4 拆分为多个连续 PR，并明确每个 PR
的交付范围、前置依赖及验证要求；加入单次 consume-plan 从实施到自动合并的完整流程，以及完成后归档至 docs/finished_plans/
的最终步骤。
Sources: Coding guidelines, Learnings
Central reviewDecision: Validated findings[major] Add a wire acceptance scenario for paged dropped-loot sync
The wire plan changes dropped-loot synchronization to a paged, recipient-specific protocol and requires empty, one-page, exactly-256, 257, missing-final-page, and mixed-revision samples, plus atomic client replacement after all same-revision pages arrive. However, the wire plan's named bot acceptance list contains only scope, dimension-transfer, contract-sweep, and join-snapshot scenarios; none sends or consumes a paginated dropped-loot sync. The inventory plan's Root cause: the changed wire and client paging/atomicity contract has sample requirements but no named end-to-end acceptance path that drives the producer-to-decoder-to-client-store behavior. [major] R3 gates the migration seam on the wrong R10 phase
Root cause: the cross-plan dependency was updated to refer to r10 p3 even though the canonical r10 plan assigns the migration helper deliverable to p1. the plans therefore have inconsistent producer phase and consumer gating for the inventory migration api, making the required persistence integration sequencing ambiguous and capable of leaving the consumer disconnected or unnecessarily blocked. [major] Define revocation for stale OwnerOnly projections
Root cause: the plan introduces recipient-specific private loot filtering but leaves recipient-context revocation and stale-client cleanup as an undecided implementation detail. since the client store is specified to retain its old view when no complete replacement revision arrives, authorization changes do not have a defined invalidation path. [major] Add exact-limit dropped-loot hydration coverage
The persistence plan adds a bounded dropped-loot hydration contract, but its only named test says to load rows "超过 ... MAX_DURABLE_DROPPED_LOOT_ENTRIES" and assert the guard. It does not exercise the exact-limit success boundary (or limit-minus-one). The related R10 pins require limit-1/limit/limit+1 coverage, but that is a separate inventory plan and does not establish that the R3 hydration consumer accepts exactly the configured maximum. An implementation using Root cause: the newly specified persistence hydration boundary is tested only above the limit, leaving the exact capacity contract unprotected at the consumer boundary. |
1 similar comment
Central reviewDecision: Validated findings[major] Add a wire acceptance scenario for paged dropped-loot sync
The wire plan changes dropped-loot synchronization to a paged, recipient-specific protocol and requires empty, one-page, exactly-256, 257, missing-final-page, and mixed-revision samples, plus atomic client replacement after all same-revision pages arrive. However, the wire plan's named bot acceptance list contains only scope, dimension-transfer, contract-sweep, and join-snapshot scenarios; none sends or consumes a paginated dropped-loot sync. The inventory plan's Root cause: the changed wire and client paging/atomicity contract has sample requirements but no named end-to-end acceptance path that drives the producer-to-decoder-to-client-store behavior. [major] R3 gates the migration seam on the wrong R10 phase
Root cause: the cross-plan dependency was updated to refer to r10 p3 even though the canonical r10 plan assigns the migration helper deliverable to p1. the plans therefore have inconsistent producer phase and consumer gating for the inventory migration api, making the required persistence integration sequencing ambiguous and capable of leaving the consumer disconnected or unnecessarily blocked. [major] Define revocation for stale OwnerOnly projections
Root cause: the plan introduces recipient-specific private loot filtering but leaves recipient-context revocation and stale-client cleanup as an undecided implementation detail. since the client store is specified to retain its old view when no complete replacement revision arrives, authorization changes do not have a defined invalidation path. [major] Add exact-limit dropped-loot hydration coverage
The persistence plan adds a bounded dropped-loot hydration contract, but its only named test says to load rows "超过 ... MAX_DURABLE_DROPPED_LOOT_ENTRIES" and assert the guard. It does not exercise the exact-limit success boundary (or limit-minus-one). The related R10 pins require limit-1/limit/limit+1 coverage, but that is a separate inventory plan and does not establish that the R3 hydration consumer accepts exactly the configured maximum. An implementation using Root cause: the newly specified persistence hydration boundary is tested only above the limit, leaving the exact capacity contract unprotected at the consumer boundary. |
948da17 to
610f0ae
Compare
Central reviewDecision: The read-only review job did not produce a verifiable artifact. No code verdict was inferred. |
2 similar comments
Central reviewDecision: The read-only review job did not produce a verifiable artifact. No code verdict was inferred. |
Central reviewDecision: The read-only review job did not produce a verifiable artifact. No code verdict was inferred. |
基于现役代码验真拆分职责、满包落地策略、跨轨所有权与旧布局迁移门禁，避免 Wave 2 实施继续复制不一致交付语义。 Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
恢复灵田锄实例深链回归，收紧背包移动的动作级 accepted/rejected 门禁，并把 inventory outcome 到 S2C/client 的接线明确分配给 R10、R6、R4 具体阶段。 Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
Model: claude-sonnet-5 Co-Authored-By: Claude <noreply@anthropic.com>
Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
为旧掉落记录指定 R3 迁移消费者，校正 R6 provider 顺序并锁全可见性授权矩阵。 Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
610f0ae to
3fb07fa
Compare
Central reviewDecision: Validated findings[major] R6 dropped-loot projection can precede legacy metadata migration
Root cause: the dependency gate for the recipient-specific wire consumer is attached to the new r10 metadata provider, but not to the r3 legacy dropped-loot migration/hydration contract that supplies owner and visibility for existing persisted rows. the phase ordering allows the consumer to start while part of its input schema is still unconverted. [major] Dropped-loot migration API is referenced but never defined
The new R10 plan claims P1 includes "dropped-loot" migration helpers (line 7) and later requires R3 to call R10's pure dropped-loot migration before deserialization (line 81). However, the only migration contract actually defined is Root cause: the plan declares a complete dropped-loot migration contract and assigns its consumer to another track, but only freezes the inventory-layout function. this leaves the producer/consumer symbol and conversion boundary unspecified, so independent r10 and r3 implementations can choose incompatible migration behavior or cannot implement the stated acceptance path from the plan. |
明确 R3 legacy dropped-loot migration 先于 R6 projection 消费，并补齐 R10 P1 纯迁移 helper 的签名与 owner phase。 Model: cc-sonnet-high Co-Authored-By: Claude <noreply@anthropic.com>
1 participant
摘要
plan-refactor-inventory-core-v1从 skeleton 单次提升为 active，并完成 Wave 0 / P0 设计收口InventoryTxn原子契约、满包脚下落地策略与跨轨文件所有权总纲对齐
本 PR 属于
docs/plans-skeleton/plan-refactor-master-v1.md的重构轨 R10。按总纲 §4/§5，当前只完成 Wave 0 的 P0；R10 实现仍属于 Wave 2，不提前触碰 server/client 实现代码。验证
git diff --check origin/main...HEAD主导模型：
cc-sonnet-high