# Copilot Instructions
当前仓库的核心文档入口如下：
- 设计文档见 [design.md](../docs/design.md)，当你刚开始接手这个项目的时候务必阅读。如果需要修改某一层次的业务实现的时候 **必须** 先阅读对应层次的文档。并且如果在修改了仓库中的业务代码（比如增加了某些 helper 方法，或者某些 facts 可以给后层消费的）需要同步更新文档。
- 调试文档见 [debug.md](../docs/debug.md)，排查错误、需要调试 cli 以及库的时候务必阅读。
- 仓库内有完整的lua执行环境，见 [lua/README.md](../lua/README.md)。
## 工作时一定、必须遵循的规则
- 务必使用以下skills: rust-best-practices
- 当在某个case下发现问题的时候，应该尽可能追踪是不是更早的某个层次漏掉了什么东西，就算找到了觉得是问题的根源的也不妨再多推几步确认推断。**不要** 在后面的层次为前面缺失或者错误的东西兜底；**永远不要** 用堆特判的方式去让某个问题不再出现，而是应该在遇到问题的时候定位问题的根源尝试从结构上去修复问题。判定规则是永远都写不完的，再多的判定规则也总是会被特定的case hack。
- 如果要解决的问题，本质上只是现有某个 pass 已经在处理的同类形状因为约束过窄而漏掉了，那么应优先扩充这个 pass 或它的共享 helper，而不是平行再新建一个 pass 去接同一类职责。
- 每一个文件头都需要通过中文文档注释的方式解释当前文件的的设计理念，也就是说为啥要要有这个文件？这个文件提供什么方法或者struct？然后当你修改某个文件的时候也需要判断是否需要同步更新注释。从 `StructureFacts` 开始，所有 pass 风格文件都应带中文说明，至少说明：这个 pass 解决什么问题、它依赖哪一层已提供的事实、它不会越权做什么、至少一个“输入形状 -> 输出形状”的例子。同样当修改pass的时候也需要酌情修改注释。在代码可能产生误解或者代码本身不足以解释“为什么”的时候也需要补充中文注释，告知维护者某一段代码为什么存在，拒绝翻译代码的注释，也就是说你需要做的是讲清楚“为什么”而非“做什么”。
- 当某个文件超过1000行的时候，**需要特别注意** 是否可以根据职责 或者 根据关注点进行拆分，当然如果确实职责一致且关注点一致的话可以保留长度过长的文件。
- 局部不变量测试、pass 级单元测试不要内嵌在实现文件底部；统一放到该模块同目录的 `tests.rs` 内，并在实现文件里只保留 `#[cfg(test)] mod tests;`。端到端行为则继续放在 `tests/regression`。
- 该库需要考虑到编译成wasm模块的方式分发，因此需要避免使用某些导致库无法编译为wasm模块的操作或者依赖。
- 每一轮工作完成如果修改了业务代码则需要通过一下两条命令进行验证。
- `cargo clippy --workspace --all-targets --all-features --locked -- -D warnings`
- `cargo unit-test --jobs 8`
- 当更新了decompile参数输入的时候，需要同步更新以下项目：
- `README.md/README_en.md` 中的参数列表
- `packages/unluac-js/src/index.ts` js包装库中的类型声明
- `packages/unluac-cli/src/cli.rs` cli工具中的参数解析部分
- `packages/unluac-wasm/src/lib.rs` wasm库中的参数解析部分