|
|
@@ -11,6 +11,37 @@
|
|
|
- 修复缺陷时优先用可复现检查或测试证明问题，再验证修复结果；多步骤任务给出简短、可验证的执行计划。
|
|
|
- 当用户说“只改 X”时，只改 X。简单的格式、显示或单文件修改不要创建任务计划，也不要启动 Agent。
|
|
|
|
|
|
+## OMG 支付执行纪律与本次复盘
|
|
|
+
|
|
|
+### 已暴露的问题
|
|
|
+
|
|
|
+- 已确认的需求仍被重复分析、确认和审查，导致实现节奏失控。
|
|
|
+- 单个接口被拆成过多小步骤，频繁读取规格、检查状态和执行零散命令，没有一次性收口。
|
|
|
+- 用户已要求全部 OMG 功能完成后统一测试，但实现过程中仍沿用逐测试推进方式；在不运行测试的情况下既没有获得反馈，又浪费了时间。
|
|
|
+- 工具命令失败后曾重新展开分析，而不是直接修正命令并继续。
|
|
|
+- 曾把中间文件修改描述为进展，但源码仍处于接口与实现不一致、不可交付的状态。
|
|
|
+- PowerShell 命令换行使用错误，造成暂存失败；执行前没有按当前 Shell 语法一次写对。
|
|
|
+
|
|
|
+### 后续强制执行规则
|
|
|
+
|
|
|
+- 用户已经确认的 OMG 需求不得重复询问、重新设计或反复论证；只有发现会实质改变结果且无法从仓库确认的新歧义时才能暂停说明。
|
|
|
+- 每个 OMG 接口按一个批次完成生产代码、测试源码、spec-kit 文档和 SQL；不要把同一接口拆成多个等待用户确认或重复审计的小批次。
|
|
|
+- 开始实现前只读取完成当前接口必需的文件；实现过程中不反复运行 `git status`、`rg`、`git diff` 或同类审计命令。
|
|
|
+- 每个接口完成后只进行一次统一静态检查、一次暂存范围检查和一次提交；检查发现问题时直接修复，再做一次最终复核，不重新展开方案设计。
|
|
|
+- 在用户明确要求的本轮 OMG 重做期间，不运行 Maven、编译或测试；等创建、回调、查询、补单、退款等全部计划功能调整完成后，再统一运行 JDK 21 定向测试、模块构建和完整回归。
|
|
|
+- 测试源码可以随接口实现一并编写，但不得借“测试先行”之名增加逐文件、逐方法的工具往返；延后运行测试时必须明确说明测试仅已编写、尚未验证。
|
|
|
+- 工具命令失败时优先直接纠正命令；不得因命令语法、路径或暂存错误重新分析已经确认的业务方案。
|
|
|
+- PowerShell 多路径命令使用数组传参或其他合法 PowerShell 语法，不使用 Bash 风格反斜杠续行。
|
|
|
+- 进度只使用四种状态：`未开始`、`实现中`、`已提交`、`已验证`。未完成提交前统一报告为“实现中”，不得把局部修改、测试源码已写或静态检查部分完成描述成接口已完成。
|
|
|
+- `已提交` 只表示代码已形成独立提交；只有实际运行约定的测试和构建并检查结果后，才能报告为 `已验证`。
|
|
|
+- 如果违反上述任一规则，立即停止当前低效操作，说明违反的具体条款，纠正执行方式后继续；不得只口头承认后仍沿用原方式。
|
|
|
+
|
|
|
+### 可审计交付要求
|
|
|
+
|
|
|
+- 最终交付必须给出提交 SHA、实际执行的检查以及明确未执行的验证项。
|
|
|
+- 提交前核对暂存文件清单，只包含当前 OMG 接口及其规格、测试和 SQL；不得混入工作区原有脏文件。
|
|
|
+- 不依赖“我会遵守”的口头承诺；以后以 `AGENTS.md` 本节、命令记录、暂存清单和提交结果作为执行是否合规的依据。
|
|
|
+
|
|
|
## 技术栈和相关项目
|
|
|
|
|
|
- 后端：Java、Spring Boot、MyBatis XML Mapper、MySQL。
|
qmj