baku-coding-disciplinelisted

# 编码纪律 ## 概览 把所有编码任务先收束到一个工程纪律入口：先判断任务类型，再选择最小合适流程，最后用复杂度、测试、接口、故障和长期维护责任做门禁。 这个 skill 是总入口��不是把所有规则都硬套一遍。简单改动走轻量路径；行为变化、bug、重构和审查走对应模式。它也不替代项目自己的 `AGENTS.md`、测试策略或代码规范；如果有冲突，优先遵守用户明确要求和当前仓库规范。 ## 第一步 开始编码前先完成这四件事： - 明确用户要的结果、非目标、假设和成功标准。 - 如果用户说“先研究、只排查、先方案、不要执行、先别改、只读看看”，先进入只读 / 方案模式。 - 搜索并阅读相关代码、项目规范、测试和已有接口；不要凭文件名猜。 - 选择一个执行模式；不确定时先用最轻量模式，再按风险升级。 - 如果要编辑文件，先给 3-6 条计划，并写清每步验证方式；微小修改可以压缩流程，但不能跳过最小验证。 - 预判文档影响：只要变更可能影响 API、数据结构、配置、状态、业务规则、模块入口、联调方式、运维方式或用户可见行为，就把文档同步列为本次任务的一部分。 ## Git 提交建议 - 一个提交只表达一个清晰、可回滚的意图，标题说明结果，正文说明动机、影响和验证。 - 可以采用 Conventional Commits，例如 `feat(scope): add capability`；常见类型包括 `feat`、`fix`、`refactor`、`docs`、`test`、`perf`、`build`、`ci` 和 `chore`，不要用 `feature` 代替 `feat`。 - 分支同步、提交标题语言、emoji、scope 命名、推送门禁和是否允许强制推送属于项目约束，按当前仓库的 `AGENTS.md` 执行。 - 涉及提交、push、worktree 或分支归属时，必须先读取 [git-worktree-guardrails.md](references/git-worktree-guardrails.md)，再执行只读核对、提交范围确认和 push 前门禁。 ## 模式路由 按任务选择一个主模式，必要时组合： - **只读 / 方案**：用户要求先研究、只排查、先方案、不要执行时使用。只允许读代码、查日志、运行只读查询和写方案文档；禁止改代码、跑有副作用命令或顺手修相邻问题。 - **微小修改**：错别字、明显一行配置、纯格式或小文案。直接做最小改动，运行最便宜的检查。 - **功能 / 行为变更**：新增能力或改变行为。走 TDD 风格：一个可观察行为，一条测试或验证路径，一次最小实现。 - **故障 / 性能回归**：报错、失败、异常、性能下降。先建立反馈循环和复现，再假设、加观测、修复、补回归测试。 - **重构 / 架构调整**：结构调整、抽象迁移、技术债偿还。先确认 ROI、范围和回滚边界，再拆小步，每步保持可工作。 - **审查**：用户要求 review、合并前检查或审查 AI 生成代码。按规范和需求两轴报告问题，先列风险。 按需读取 reference，避免把所有细则一次性塞进上下文： - [mode-routing.md](references/mode-routing.md)：选择主模式、只读边界、各模式完成条件。 - [ai-coding-antipatterns.md](references/ai-coding-antipatterns.md)：写业务逻辑、错误处理、测试、调试修复或审查