coding-disciplinelisted

# 编码纪律 ## 概览 把所有编码任务先收束到一个工程纪律入口：先判断任务类型，再选择最小合适流程，最后用复杂度、测试、接口、故障和长期维护责任做门禁。 这个 skill 是总入口，不是把所有规则都硬套一遍。简单改动走轻量路径；行为变化、bug、重构和审查走对应模式。它也不替代项目自己的 `AGENTS.md`、测试策略或代码规范；如果有冲突，优先遵守用户明确要求和当前仓库规范。 ## 第一步 开始编码前先完成这四件事： - 明确用户要的结果、非目标、假设和成功标准。 - 如果用户说“先研究、只排查、先方案、不要执行、先别改、只读看看”，先进入只读 / 方案模式。 - 搜索并阅读相关代码、项目规范、测试和已有接口；不要凭文件名猜。 - 选择一个执行模式；不确定时先用最轻量模式，再按风险升级。 - 如果要编辑文件，先给 3-6 条计划，并写清每步验证方式；微小修改可以压缩流程，但不能跳过最小验证。 ## 模式路由 按任务选择一个主模式，必要时组合： - **只读 / 方案**：用户要求先研究、只排查、先方案、不要执行时使用。只允许读代码、查日志、运行只读查询和写方案文档；禁止改代码、跑有副作用命令或顺手修相邻问题。 - **微小修改**：错别字、明显一行配置、纯格式或小文案。直接做最小改动，运行最便宜的检查。 - **功能 / 行为变更**：新增能力或改变行为。走 TDD 风格：一个可观察行为，一条测试或验证路径，一次最小实现。 - **故障 / 性能回归**：报错、失败、异常、性能下降。先建立反馈循环和复现，再假设、加观测、修复、补回归测试。 - **重构 / 架构调整**：结构调整、抽象迁移、技术债偿还。先确认 ROI、范围和回滚边界，再拆小步，每步保持可工作。 - **审查**：用户要求 review、合并前检查或审查 AI 生成代码。按规范和需求两轴报告问题，先列风险。 详细路由见 [mode-routing.md](references/mode-routing.md)。 实际修改代码、设计公共接口、做代码审查或接收 AI 生成补丁时，读取 [code-style.md](references/code-style.md)，用于补充编码规范、命名和注释要求。 涉及 UI、前端实现、原型、视觉还原、Figma / 截图 / URL 到代码、设计系统或用户界面改动时，额外读取 [frontend-ui-work.md](references/frontend-ui-work.md)。普通非 UI 编码任务不要加载它。 ## 工程门禁 对任何非平凡代码改动，至少快速过一遍 8 个门禁： 1. 真实需求与用户：这是真问题，还是用户给出的一个方案？ 2. 复杂度与代码经济性：能不能不写、少写、删旧逻辑或复用已有路径？ 3. 技术债与长期责任：新增债务是否可见、可追踪、可偿还？ 4. 故障与诊断纪律：是否有复现、根因、日志、降级、恢复或回归测试？ 5. 设计、重构与 ROI：重构是否明显值得，迁移成本是否可控？ 6. 数据、接口与领域语言：数据模型和公共接口是否清楚、稳定、难误用？ 7. 质量自动化与知识共享：测试、CI、文档、注释和 review 是否足够支撑维护？ 8. 专业信用与成长节奏：是否及时同步风险、承认不确定性、避免无边界加班式硬扛？ 完整清单和 38 条来源映射见 [maturity-checklist.md](references/maturity-checklist.md)。当任务涉及架构、重构、