baku-coding-disciplinelisted

# 编码纪律 ## 概览 把所有编码任务先收束到一个工程纪律入口：先判断任务类型，再选择最小合适流程，最后用复杂度、测试、接口、故障和长期维护责任做门禁。 这个 skill 是总入口，不是把所有规则都硬套一遍。简单改动走轻量路径；行为变化、bug、重构和审查走对应模式。它也不替代项目自己的 `AGENTS.md`、测试策略或代码规范；如果有冲突，优先遵守用户明确要求和当前仓库规范。 ## 执行分组 按下面九个环节组织任务；第 3、4、7、8、9 步按需触发，不要求每个任务完整走一遍： 1. **边界与授权**：确认目标、非目标、成功标准、只读边界和副作用授权。 2. **代码与事实理解**：读取当前代码、测试、规范、接口、数据模型和领域术语。 3. **方案、Spec 与设计确认**：复杂需求读取 [plan-spec-and-grill.md](references/plan-spec-and-grill.md)，执行内置的规格化和逐轮确认。 4. **任务拆分与执行切片**：大功能或重构读取 [plan-spec-and-grill.md](references/plan-spec-and-grill.md)，执行内置的纵向 tickets 和依赖拆分。 5. **代码实现**：读取 [implementation-loop.md](references/implementation-loop.md)，按功能、故障或重构模式小步修改。 6. **测试、审查与质量验证**：按实现验证规则运行类型检查、测试和 review，检查 AI 编码反模式和文档影响。 7. **编码完成后的架构复盘**：非微小改动读取 [architecture-improvement-review.md](references/architecture-improvement-review.md)，提出架构改进候选；不自动重构。 8. **文档、知识与交接收尾**：代码影响文档时联动 `neat-freak`；需要中断或移交时读取 [handoff-and-delivery.md](references/handoff-and-delivery.md)。 9. **Git、Worktree 与交付核对**：涉及提交、冲突、分支或 push 时读取 [git-worktree-guardrails.md](references/git-worktree-guardrails.md)。 主链路是“理解 → 实现 → 验证 → 收尾”。方案、拆票和架构复盘是受条件控制的辅助环节，不是普通编码任务的固定前置流程。 所有运行期中间产物统一放到项目根目录的 `.baku-coding-discipline/`，按类型分组；不在项目根目录散落 spec、plan、ticket、报告、诊断脚本或 handoff。具体目录和生命周期见 [runtime-artifacts.md](references/runtime-artifacts.md)。 ## 第一步 开始编码前先完成这四件事： - 明确用户要的结果、非目标、假设和成功标准。 - 如果用户说“先研究、只排查、先方案、不要执行、先别改、只读看看”，先进入只读 / 方案模式。 - 搜索���阅读相关代码、项目规范、测试和已有接口；不要凭文件名猜。 - 选择一个执行模式；不确定时先用最轻量模式，再按风险升级。 - 复杂需求存在关键未决事项时，可在只读 / 方案模式下按需进行规格化、逐轮确认和纵向切片；明确需求和微