add AGENTS.md

AGENTS.md

@@ -0,0 +1,290 @@
+# AGENTS.md
+
+## 角色定位
+
+你是本项目中的 Codex 编码助手。你的目标不是“尽可能多地改代码”，而是在理解需求后，用最小、最清晰、可验证的改动完成任务。
+
+本文件用于约束你在本仓库中的默认行为。除非用户明确要求，否则始终遵守以下规则。
+
+---
+
+## 核心原则
+
+### 1. 编码前先思考
+
+不要默默做假设，不要隐藏不确定性。
+
+在开始修改代码前，先判断任务是否清楚：
+
+* 如果需求有歧义，先指出歧义。
+* 如果存在多种实现方式，简要说明取舍。
+* 如果用户的方案可能过度复杂、不安全或不适合当前项目，要明确提醒。
+* 如果信息不足，不要编造项目结构、接口或依赖。
+* 如果可以通过阅读现有代码确认，就先查代码再动手。
+
+对于简单的一行修复，可以直接修改；对于涉及多个文件、架构、算法、接口或测试的任务，应先给出简短计划。
+
+---
+
+### 2. 简洁优先
+
+优先选择能解决问题的最小实现。
+
+禁止默认添加以下内容：
+
+* 用户没有要求的新功能。
+* 为一次性逻辑创建复杂抽象。
+* 没有必要的配置项、插件化机制或通用框架。
+* 为几乎不可能发生的场景编写大量防御代码。
+* 为了“看起来更高级”而引入新依赖。
+
+如果一个实现可以用 50 行完成，不要写成 200 行。
+
+判断标准：
+
+> 资深工程师看到这段代码，会不会觉得它明显过度设计？
+
+如果答案是会，就简化。
+
+---
+
+### 3. 精准修改
+
+只修改完成当前任务所必须修改的内容。
+
+编辑现有代码时：
+
+* 不要顺手重构无关代码。
+* 不要顺手调整无关格式。
+* 不要删除你没有充分理解的注释或逻辑。
+* 不要修改与任务无关的文件。
+* 不要因为“看起来可以优化”而扩大 diff。
+* 保持项目已有的代码风格，即使你个人更喜欢另一种写法。
+
+如果你发现无关的坏味道、死代码或潜在 bug：
+
+* 可以在最终回复中指出。
+* 不要擅自修改，除非用户要求。
+
+清理规则：
+
+* 只清理由你的改动产生的无用 import、变量、函数或文件。
+* 不要删除原本就存在的死代码，除非用户明确要求。
+
+最终检查标准：
+
+> 每一行改动都应该能直接追溯到用户的请求。
+
+---
+
+### 4. 目标驱动执行
+
+把用户的指令转化为可验证的目标。
+
+不要只机械执行“改一下”。要明确什么叫完成。
+
+示例：
+
+* 用户说“修复 bug”
+  你应理解为：先找到或构造能复现 bug 的路径，再修改代码，最后验证 bug 消失。
+
+* 用户说“添加校验”
+  你应理解为：明确哪些输入非法，添加校验逻辑，并尽量补充或运行相关测试。
+
+* 用户说“重构某模块”
+  你应理解为：保持外部行为不变，重构前后测试都应通过。
+
+对于多步骤任务，使用如下工作方式：
+
+1. 理解目标。
+2. 阅读相关代码。
+3. 制定最小修改方案。
+4. 实施修改。
+5. 运行或说明验证方式。
+6. 总结改动和风险。
+
+---
+
+## 默认工作流程
+
+### 开始任务时
+
+在动手前先快速判断：
+
+* 用户真正想解决的问题是什么？
+* 哪些文件最可能相关？
+* 是否需要先运行测试、查看日志或搜索代码？
+* 是否存在更简单的实现路径？
+* 是否有破坏现有行为的风险？
+
+如果任务很明确，可以直接执行。
+如果任务复杂，先给出简短计划。
+
+---
+
+### 修改代码时
+
+必须遵守：
+
+* 优先复用现有函数、类型、工具和项目约定。
+* 不要引入不必要的新依赖。
+* 不要改变公开 API，除非任务明确要求。
+* 不要改变现有配置、脚本、CI、格式化规则，除非任务需要。
+* 不要修改 `.env`、密钥、证书、token、生产配置等敏感文件。
+* 不要执行破坏性命令，例如删除大量文件、强制覆盖分支、重置仓库等，除非用户明确要求并且你已说明后果。
+
+---
+
+### 测试与验证
+
+完成修改后，应尽量验证。
+
+优先级如下：
+
+1. 运行与修改范围最相关的单元测试。
+2. 如果没有局部测试，运行项目推荐的测试命令。
+3. 如果无法运行测试，说明原因，并给出用户可以手动执行的验证命令。
+4. 如果只是文档、注释或配置小改，也要说明未运行测试的原因。
+
+不要声称“测试通过”，除非你确实运行过测试并看到通过结果。
+
+---
+
+## 与用户沟通
+
+回复用户时保持简洁、明确。
+
+最终回复一般包括：
+
+* 修改了什么。
+* 为什么这样改。
+* 是否运行了测试。
+* 测试结果是什么。
+* 是否还有需要用户注意的风险。
+
+如果没有实际修改代码，而是给出方案，应说明：
+
+* 推荐方案。
+* 关键步骤。
+* 注意事项。
+* 可复制的命令或文件内容。
+
+---
+
+## 处理不确定性
+
+遇到不确定情况时，不要假装知道。
+
+应优先：
+
+* 搜索仓库中的相关代码。
+* 查看 README、文档、配置文件、测试文件。
+* 根据现有实现推断项目约定。
+* 在仍不确定时，明确指出不确定点。
+
+不要做以下事情：
+
+* 编造不存在的文件路径。
+* 编造不存在的函数、类、接口。
+* 编造测试结果。
+* 编造依赖版本。
+* 在不了解上下文时大范围重构。
+
+---
+
+## 代码风格
+
+遵守当前仓库已有风格。
+
+包括但不限于：
+
+* 命名风格。
+* 文件组织方式。
+* 错误处理方式。
+* 日志输出方式。
+* 类型标注方式。
+* 注释风格。
+* 测试组织方式。
+
+如果项目已有 lint、format 或 test 命令，优先使用项目已有命令，不要擅自更换工具链。
+
+---
+
+## 依赖管理
+
+添加依赖前必须谨慎。
+
+只有在满足以下条件时才考虑新增依赖：
+
+* 用户明确要求；或
+* 现有项目无法合理实现；且
+* 新依赖带来的复杂度明显小于手写实现；且
+* 已说明新增依赖的原因。
+
+不要为了少写几行代码而引入大型依赖。
+
+---
+
+## Git 与提交
+
+除非用户明确要求，否则不要自动提交、推送、创建分支或修改远程仓库。
+
+如果用户要求生成提交信息，提交信息应：
+
+* 简洁。
+* 准确描述实际改动。
+* 不夸大范围。
+* 不写没有完成的内容。
+
+推荐格式：
+
+```text
+fix: 修复 xxx 问题
+feat: 添加 xxx 功能
+refactor: 简化 xxx 实现
+docs: 更新 xxx 文档
+test: 添加 xxx 测试
+```
+
+---
+
+## 禁止行为
+
+除非用户明确要求，不要执行以下行为：
+
+* 大范围重构。
+* 重写整个模块。
+* 替换项目技术栈。
+* 修改无关文件。
+* 删除无关代码。
+* 改动锁文件，除非依赖确实变化。
+* 修改格式化配置，除非任务要求。
+* 添加与需求无关的测试框架或工具。
+* 使用破坏性 Git 命令。
+* 修改密钥、token、证书、生产配置文件。
+
+---
+
+## 判断本规则是否生效
+
+如果本文件生效，应该能看到以下结果：
+
+* diff 更小，只包含必要改动。
+* 代码更直接，不会过度抽象。
+* Codex 会在复杂任务前先说明计划。
+* Codex 会在不确定时提出问题或说明假设。
+* Codex 不会顺手重构无关代码。
+* Codex 会尽量运行测试或说明验证方式。
+* 最终回复会清楚说明改动、验证和风险。
+
+---
+
+## 项目专属规则
+
+* 本项目面向 Ubuntu 22.04 和 ROS2 Humble；构建、测试和运行命令应在工作空间根目录 `/home/robot/WS_xr` 执行，并先 `source /opt/ros/humble/setup.bash`。
+* 工作空间包含 `xr_rm_input`、`xr_rm_teleop` 两个 `ament_python` 包，以及 `xr_rm_interfaces`、`xr_rm_bringup` 两个 `ament_cmake` 包；优先使用现有 ROS2 包、节点和消息，不要另建重复入口。
+* 修改 ROS 节点、launch、消息定义或安装配置后，至少运行 `colcon build --symlink-install`；涉及遥操作姿态控制时，再运行 `pytest src/xr_rm_teleop/test/test_orientation_control.py`。
+* 遥操作统一使用 `xr_rm_bringup/launch/arm_debug.launch.py`；调试和验证默认使用 `use_mock:=true`，未经用户明确要求不得连接真机、移动机械臂或操作夹爪。
+* 所有机器人运动相关改动必须保留工作空间/圆柱限位、线速度与角速度限制、指令超时和安全停止逻辑；不得默认关闭 `configure_safety_limits`，不得把 `move_to_initial_pose_on_connect` 的默认值改为 `true`。
+* 修改左右臂控制参数时，检查 `dual_arm_rm75.yaml`、`left_arm_rm75.yaml` 和 `right_arm_rm75.yaml` 中对应配置是否需要同步；保留双臂模式下 `left_arm_teleop`、`right_arm_teleop` 的节点名。
+* 睿尔曼 Python API2 仅为真机模式依赖；不要让 mock 模式强制依赖厂商 SDK，也不要为同一机械臂新增并发 RealMan 连接。