先写规范，再以测试优先的小步方式开发

## 把不清楚的需求记成问题，得到回答前不做规划 只要关键要求仍不明确，就不要规划或实施。在提出变更前，先确定尚未解决的要求、非功能性预期、行为、遥测、策略和验收标准。 在请求做出决定前，将每项高影响澄清事项和每项中等影响的不确定性记录到仓库指定的待决问题登记表中。为每个问题分配一个稳定的标识符，并在问题解决前，让主规范、计划和任务列表的范围始终与该标识符对应。 展示备选方案时，先保存同一组选项，再直接向用户概述。将推荐选项排在首位，简要说明优缺点，引用问题标识符，并在获得所需答案前停止。问题解决后，将答案纳入规范的规范性章节，并关闭登记表中的相应条目。 ## 规划前阅读规范和架构图 从仓库根目录开始工作，并应用仓库级指令以及所有相关的嵌套规则。在规划前，阅读当前路线图、主导该功能的规范、模块图或知识图谱、编码约定，以及与受影响功能相关的架构决策。 梳理变更可能影响的模块、契约和职责边界。使用仓库维护的架构快照，不要仅根据附近的一个文件推断关系；当模块、依赖项或契约发生变化时，更新该图。 为规范、计划、任务和架构决策使用已批准的模板，以确保元数据、验证记录和交叉链接保持一致。 ## 先更新规范，再更新计划和任务清单 在实施前创建或更新功能规范。定义要求、非功能性要求、行为或接口细节、遥测与策略、验收分支；如果视觉行为发生变化，还要提供接口草图。 在生成实施计划前，解决所有高影响和中等影响的问题。更新规范后，将具有重要架构意义的结果记录到架构决策记录中，并将已解决的澄清事项保留在规范性章节中，而不是单独的旧版澄清列表中。 只有完成这些工作后，才能更新计划和任务清单。把测试安排在实施之前，将工作划分为预计可在90分钟内完成的逻辑增量，并在规范、计划和任务相互一致后运行仓库的分析门禁。除非用户明确提出要求，否则不要自行添加回退行为或兼容性行为。 ## 从一份保存的快照恢复会话，交接前更新它 开始一个不带上下文的会话时，遵循仓库的重置或交接操作手册。在开始新的实施工作前，概述路线图状态、当前计划进度和未解决的问题。 只维护一个指定的当前会话快照，作为跨会话状态的实时记录。交接前更新该快照，写明当前功能、已完成的工作、待解决的问题、验证状态和下一项安全操作。不要创建相互竞争的进度记录。 明确标示功能和模块的职责归属，确保文档、自动化、安全、持久化和接口工作在各自的主导位置更新。 ## 每个行为都先写一个会失败的测试 在修改代码前更新主规范和计划。对于每项行为，先编写或扩展一个可执行的单元测试、行为测试、契约测试或场景测试，并确认它因预期原因而失败。 在规划期间列出成功、验证和失败分支，并为每条路径添加一个最小化的失败测试。只实施足以让测试通过的代码，然后在保持测试通过的同时进行重构。 循环结束后，在计划或路线图中记录覆盖率变化、经验和后续工作，使推理过程保持可审计。 ## 让改动小而独立，任务完成后立即标记 使每个增量都自成一体，并遵循仓库在语言、框架、文档和测试方面的约定。与深层嵌套的内联分支相比，优先使用由小型验证和规范化辅助函数组成的直线式编排。 随着行为变化，同步更新路线图、规范、计划和任务清单。每项任务一经验证就立即标记为完成，不要集中批量更新状态；每当模块关系或契约发生变化时，都要更新架构图。 决策记录只用于已经确认的架构决策。避免无关的重构、大规模格式化或推测性的兼容性工作，并确保实施与已批准的增量一致。 ## 按改动的文件类型运行检查，失败时调查而不是跳过 迭代时，运行适用范围最小的格式化工具、代码检查工具、静态分析、类型检查和聚焦测试。完成前，针对已修改的文件类型以及任何直接受影响的集成边界，运行仓库要求的每项门禁。 将失败的本地检查或持续集成检查视为需要调查的缺陷，而不是可以绕过的门禁。如果仓库策略明确允许临时豁免测试，只禁用受影响的测试，添加清晰的`TODO`及原因，并在主计划中记录后续工作。 为每项已变更的行为添加或更新测试。检查最终差异，确认文档和测试覆盖率与实施一致；只要必需检查仍在失败，就不要宣布该增量完成。 ## 添加依赖或执行有风险的 Git 操作前先取得批准 只暂存属于该增量的文件。如果可能存在生成的输出、数据库产物或并行工作，不要进行大范围暂存。准备一份原子化的约定式提交说明；文档和代码一起变更时，还要写明对规范的影响。但除非执行工作已被明确委派，否则应由指定的操作人员提交。 在添加或升级依赖项、删除指定的文件或目录、重写历史、推送或创建外部评审前，先获得明确批准。在功能计划中记录采用已批准依赖项的理由，并为受管理的钩子和质量流水线留出充足时间。 绝不要提交机密信息，也不要把破坏性清理当作捷径。将意外出现的已跟踪或未跟踪文件提交审查，并保持无关工作不变。 ## 除非被要求，不加兼容性回退，并先提出有风险的改动 遵循仓库声明的兼容性立场。当接口被视为全新设计时，除非用户针对当前任务明确要求，否则不要添加回退方案、适配层或旧版检查。 在当前计划或链接的附录中记录提示摘要、重要命令序列和理由。在编辑前提出高风险重构、持久化变更、安全策略变更和重大非功能性权衡，然后将批准的架构决策记录到正确的决策日志中。 在自动化门禁建成前，持续在计划中跟踪未来的契约测试、变异分析和安全演练。将操作指南放在其权威工作流附近，避免在多份文档中重复容易变化的指令。 ## 只在测试数据库上运行测试，重置前确认连接目标 绝不要针对未经验证的连接运行数据库重置、全量清除或全新迁移命令。在执行任何迁移或重置前，确认当前环境、连接目标，以及操作是否仅限于可随时弃用的测试数据库。 针对仓库的隔离测试数据库运行应用测试，并采用其文档规定的事务或迁移设置。仅在必要时重置明确指定的测试数据库；不要假设测试命令与交互式应用命令使用同一连接。 以文件形式创建新的迁移，并通过测试工作流验证。如果数据库范围不明确，应停止并获取确认，而不要让开发或生产数据面临风险。 ## 每完成一步，在交接中写明改了什么、检查了什么 一个自成一体的增量通过适用门禁后，确认已完成任务、路线图状态、规范变更、决策记录和当前会话快照已经同步。 提供一份简洁的交接说明，列出已变更文件、运行的检查及其结果、未解决的阻碍、后续工作，以及可直接复制的操作人员命令。区分已经实施的工作与仅处于计划阶段或等待授权的工作。 验证后及时准备该功能的提交，但只有在仓库委派策略允许的范围内才执行提交。保留足够证据，使下一个会话无需重复调查即可继续。