GameAgentEngine

Imported from Destinykami/GameAgentEngine (AGENTS.md). Install upstream with npx skills add Destinykami/GameAgentEngine. Copyright stays with the author.

项目协作规范

本文件适用于整个仓库。修改项目时，遵循“先设计、后实现、验证后按模块提交”的流程。

设计文档入口

• 项目的模块说明与设计文档统一维护在 docs/ 下。
• 开始修改前，阅读 docs/README.md，定位相关模块在 docs/modules/ 下的设计文档。
• 涉及整体架构、源码布局或跨模块依赖时，同时阅读 docs/architecture.md、docs/source-layout.md 及相关模块文档。

修改流程

1. 先修改设计文档，再修改实现。 对模块进行功能新增、缺陷修复、接口调整或重构前，先更新对应设计文档，说明问题、目标行为、修改范围、模块边界、接口与状态变化，以及验证方案。不得先改代码、最后才补设计。
2. 如果模块尚无设计文档，先参考 docs/templates/module-design.md 创建对应文档，并在 docs/README.md 中补充入口。
3. 文档明确区分当前实现、目标设计和未决问题，不能把尚未实现或验证的方案描述为已完成。
4. 根据更新后的设计修改代码。涉及多个模块时，先更新相关模块的设计与接口约定，再按依赖顺序实施；实现中需要调整方案时，先回写设计再继续。
5. 完成后运行与修改范围相符的检查或测试，在设计文档中记录实现状态、验证结果和未运行项。遵守文档中适用的验证约束，不把离线测试结果描述为真实模型效果。

Git 提交规范

• 每个模块的修改完成并验证后，必须提交到 Git。 将模块修改作为一个完整工作单元处理，不在多个模块完成后统一打包提交。
• 提交应包含该模块相关的设计文档、实现和必要的测试；可以先单独提交设计，再提交对应实现。跨模块无法拆分的原子修改，应在提交正文中说明涉及的模块和共同提交的原因。
• 提交前检查工作区和暂存区差异，只暂存本次工作相关文件，不混入、覆盖或撤销用户及其他任务的改动。
• 提交标题采用 type(scope): 简述修改，例如 fix(memory): 限定观察去重的关系流范围。常用类型包括 feat、fix、refactor、docs、test 和 chore；scope 使用模块或职责名称。
• 提交正文说明修改原因、模块边界、主要改动、兼容性或行为变化、验证结果及未运行项。
• 提交前运行 git diff --check 并检查暂存内容；存在相关验证失败时，先修复或明确报告阻塞原因，不宣称模块已完成。
• 完成后向用户报告修改内容、验证结果和提交编号。提交到本地 Git 不代表推送远端；推送按用户要求执行。