mc-align

name	mc-align
description	将当前项目的代码与 Minecraft 原版代码对齐，确保功能和逻辑都能准确复刻 Minecraft。

任务

请你先阅读相关readme文件，以初步了解此次任务内容和范围，然后启动5～7个子代理，彻查用户指定路径（或者用户指定的某个子系统）下的代码。审查依据：

1. 是否准确复刻D:\Minecraft\MC研究\Minecraft1.16.5源码\net\minecraft下的算法、逻辑、时序等，与原版任何一点点偏差都会导致偏离预期。对于精确度要求极高的逻辑（如渲染相关），必须在写文件之前阅读对应mc源码！
2. 是否完整，没有遗漏类、文件、函数、数据、结构、逻辑分支等
3. 是否留有TODO、临时的简化实现、被注释掉的逻辑等
4. 是否闭环、是否完整集成到游戏逻辑当中，没有形成无法被调用的“孤岛代码”

上述5～7个子代理要求不能在后台运行，而是必须阻塞等待它们完成。它们完成之后，请你接着启动3~5个子代理，根据之前那5～7个子代理的需求，专门负责探索项目中已有的对应基建，以实现完美的、最高程度的复用。不要限制子代理的输出字数，让它们尽可能详细地输出它们的探索结果。

子代理的配置项必须如下：

run_in_background: false, model: haiku, isolation: 不要配置

注意本项目基建已经相当完善（代码量已经60w行），各种常数、常用工具函数、音频系统、粒子系统、资源包系统、命令系统、实体系统、物品系统、物理系统、碰撞、tick调度等都已经有了相当完善的实现（存档系统除外，目前未实现存档系统）(另外world对象上面也挂了相当多的工具方法以便访问世界、操作世界等)，务必充分探索以实现复用，避免重复实现，或者以未实现为理由留下TODO。

善用README

几乎每个目录下都有一个简体中文编写的 README.md，它很重要，在你探索项目实现的时候，提前看看它，能节省不少多余的文件查找与查看，节省不少上下文开销。

【重要】为了节省上下文，请你尽量阅读各级目录的 README.md 来获取你需要的信息，而不是直接查看代码文件。

例如：当你修改想修改或查看src\common\world\chunk\ChunkLoadTicketManager.cpp，你必须提前依次查看目录链上的各级目录上的readme文件：

• 项目根目录的 README.md
• src\common\README.md
• src\common\world\README.md
• src\common\world\chunk\README.md

请你不仅自己要严格遵照上述要求，而且在给子代理的prompt中也要要求它们先查看相关目录链上的README.md来获取信息，而不是直接查看代码文件。

实现要求

1. 阻塞等待所有子代理完成（禁止子代理在后台运行）。所有子代理完成之后，请你总结出一个对齐报告，列出所有不对齐的地方，并且给出详细的逐步修复建议。然后不要停下来，而是继续立即开始一步步执行！
2. 当你完成一个任务后，不要停下来，请继续做后面的任务，直到任务清空你才能停！就算任务很复杂，也绝对不允许中途停下来！
3. 你时间充足、上下文也充足，先把所有任务代码一口气写完，最后再编译
4. 请你使用cmake --build --preset windows-clang-relwithdebinfo进行编译
5. 务必尽可能复用项目中已有的基建！
6. 在任务执行过程中，你可以随时派出子代理来帮你完成一些子任务，比如说探索项目中已有的对应基建、探索项目中需要依赖的某个子系统是否存在、甚至帮你编写代码！

关于代码

【重要】必须参考下面mc源码！ windows环境源码位于 D:\Minecraft\MC研究\Minecraft1.16.5源码 macos环境源码位于 ～/MC_Dev/Minecraft1.16.5源码

1. 必须优雅、考虑到未来拓展、结构清晰美观整洁、架构强大，必须参考mc源码（主要是为了学习mc真实游戏逻辑而非架构。mc的架构水平和代码质量并不高！），但不要照搬，必须根据cpp的特性和当前项目的架构进行合理的架构设计和调整。
2. 当前项目是一个复刻项目，目标是完全使用cpp尽可能一致地复刻java版mc的游戏体验，并在存档、数据包等层面上尽可能兼容和复用现有java版minecraft生态。务必要有清晰、优雅、能让人赏心悦目的目录结构，不要把很多文件全部堆在一个目录下，要划分好细分的子目录。
3. 你需要先阅读readme文件了解怎么构建项目
4. 需要断言+单测来保证代码质量；每个方法前都要附上doc注释说明方法的用法和注意事项（容易踩坑的地方）
5. 务必要有清晰、优雅、能让人赏心悦目的目录结构，不要把很多文件全部堆在一个目录下，要划分好细分的子目录！
6. 编译过程中遇到的warning你也要一并解决
7. 需要使用命名空间隔离各个子系统的标识符。下面是最佳实践：

namespace mr {
namespace entity {
namespace attribute {

/**
 * @brief 属性修改器操作类型
 *
 * 定义属性修改器如何影响基础值
 */
enum class Operation : u8 {
    // ...
}}}}

任务结束后

任务结束之后，请你进行严格的多轮自查，检查是否完整实现、是否留有TODO、是否未完整集成到现有游戏流程中导致形成“孤岛代码”、测试用例是否完备且合理且足够复杂以便暴露问题、没用了的旧代码是否彻底清除、相关文档（readme）是否更新等。

自查完成之后，执行/simplify命令，进行代码简化，去除冗余、合并重复、提升可读性、提升性能等。

提交代码之前，必须使用clang-format对你修改的文件进行格式化：

clang-format -i src\common\xxx\Foo.cpp
clang-format -i src\common\xxx\Foo.hpp

最后，生成简体中文提交信息并提交代码。