仓库基础变更 是做什麼的？
将针对现有项目的优化请求转化为已确认、可实施的变更，然后仅执行已批准的方案。
交互与授权约定
- 在提出解决方案前检查当前仓库。不要询问用户那些可以从代码、测试、配置或适用的产品文档中获取的事实。
- 在用户明确批准某个方案或修改基线之前，保持只读状态。诊断和仓库检查不代表授权进行编辑。
- 不要将此工作流强行应用于直接、明确的实现请求。当用户要求先进行评估，或当某个选择会实质上影响行为、兼容性、风险或范围时，再启用此门控。
- 只提出影响决策的问题。在可能的情况下使用结构化的用户输入控件；否则使用简洁的选项代码，如
Q1-A。 - 通常提供2或3个互斥的可行方案。将推荐的方案放在首位并说明原因。如果只有一个安全的方案，则说明为何拒绝其他备选方案，而不是编造虚假选项。
- 确认后，实施选定的方案，不要静默地添加不相关的清理工作。如果新的仓库事实会实质上改变已批准的行为、范围、迁移、依赖或验收标准，请停止并请求修订后的决策。
证据与决策标签
将事实与解释分开：
用户目标: 用户陈述的痛点和预期结果。代码事实: 从当前源代码、测试、运行时或配置中观察到的行为。文档事实: 适用的已批准产品文档所要求的行为。技术建议: 保持预期产品行为的实现建议。产品假设: 一个可逆的、需要确认的假设。待确认: 一个未解决的选择，阻碍了实施。已确认: 用户明确批准的方案或基线。本次不改: 有意排除在已批准的变更范围之外的行为或代码。
除非用户另有指定，否则使用此权限顺序：
- 当前明确的用户指令。
- 在当前任务中已明确确认的决策。
- 适用的已批准产品规范。
- 现有行为的当前代码和测试。
- README 文件和历史文档。
暴露冲突；不要默默选择一个来源。
工作流
1. 发现当前行为
阅读 references/discovery-and-impact.md。仅检查重现或解释痛点所需的仓库区域。保护现有的用户更改，并在适当时建立当前的测试基线。
在呈现方案之前，报告当前行为、用户影响、相关的代码边界以及缺失的证据。
2. 明确变更目标
将请求转化为可观察的结果和约束。仅澄清那些可能改变方案、范围、兼容性策略或验收结果的问题。
如果字面上的 UI 措辞会引入不正确的交互语义，请不要将其视为必需的实现机制。解释其中的区别，并提供与仓库兼容的方案。
3. 比较可行方案
阅读 references/options-and-clarification.md。比较产品和工程影响，包括用户体验、保留的行为、状态和数据兼容性、可访问性、测试影响、实现工作量、回滚难度以及重大风险。
4. 生成推荐的变更规范
阅读 references/change-spec-and-acceptance.md。推荐的方案必须可由 Codex 直接执行，并包括：
- 目标行为和交互；
- 受影响的模块、组件、文件、接口和状态；
- 相关的兼容性、持久性、迁移、降级和回滚处理；
- 必须保留的行为和数据；
- 明确排除项；
- 测试计划和可观察的验收标准。
此步骤中不要修改代码。
5. 获得明确批准
展示建议方案和剩余选择。在要求用户选择一个方案或回答最小必要的澄清轮次后停止。
在收到响应后，总结已确认的方案、用户修改、未解决事项、下游影响和最终验收基线。仅当响应明确授权执行时才开始实施，例如 确认方案A 或 按推荐方案执行。
6. 实施已批准的方案
重新检查脏工作树，保留不相关的更改，并进行最小的一致实现。注释应解释非显而易见的约束或兼容性决策，而不是重述代码。
不要仅仅因为 UI 展示被移除就删除底层领域数据，除非删除已被明确批准。当更改持久化状态、路由、模式或枚举时，如果仓库指示可能存在遗留值，则需处理它们。
7. 验证与报告
先运行聚焦测试，然后进行相称的仓库范围检查，如类型检查、lint、完整测试、构建以及 UI 交互或视觉验证。如果检查无法运行，则不要声称它已通过。
报告已实现的成果、主要文件、验证证据、已知限制以及任何不相关的预先存在的警告。如果请求的验证表面不可用，请披露它，并且未经批准不要绕过明确选择的工具或环境。
强制停止条件
在以下情况下停止并请求决策：
- 两个可行方案会产生实质上不同的用户行为；
- 实施需要未经批准的依赖、集成、凭证、迁移、破坏性操作或业务规则更改；
- 当前用户更改与所需的编辑重叠且无法安全保留；
- 仓库事实与已批准的方案相矛盾；
- 验收标准无法变得可观察；
- 安全地完成变更需要扩展现有批准的范围。
难度、持续时间或普通的实现细节不是重新开启已确认决策的理由。
完成标准
仅当所选方案在范围内实施、兼容性决策已处理、验收标准与可观察证据对应、相关检查已运行且限制已如实报告时，工作流才算完成。