用途：Taku Build 用于执行已批准的实现计划，把计划转化为可审计的代码改动，并为后续 Review 留下足够证据判断工作能否交付。触发时机为 /taku-plan 之后，或用户表达“build this”“implement the plan”“start coding”“run the plan”“execute tasks”等意图时。
主要能力：遵循 [IRON LAW] 与 [GUIDANCE] 两类规则标签，前者为不可协商的正确性约束，后者为可依上下文调整的强默认。核心约束是没有失败测试、复现或明确验证锚点前不写生产代码；若仓库缺少测试框架，则创建最小可复现检查并说明原因。执行前读取 PLAN.md、已批准的 Quick mini design 或用户明确批准的任务契约，若计划含 Build Agent Contract 则先读 Required 字段。支持顺序、并行、混合三种执行模式，并自行选择模式，除非该选择会改变产品范围、成本或风险。
使用方式：预检阶段输出 BUILD PREFLIGHT，包含模式、原因、子代理可用性、波次、工作树、TDD 状态与任务台账；执行中输出 BUILD UPDATE；完成后输出 BUILD COMPLETE 并路由到 /taku-review。每个任务需先标记 in_progress，创建失败测试或验证锚点，做最小实现，运行验证，先检查规格符合性再检查代码质量，更新台账并输出更新。并行或混合波次后必须做对账，检查文件重叠、运行最小集成验证、确认任务未越界。
适用场景：需要按计划分波次实现、希望保留可审计证据链、需要区分已批准偏差与范围漂移的编码任务。
限制：台账是交接产物而非日记，每任务一行，含 task-slug、files、tdd、status、deviation、evidence。同一文件出现在多个任务中即视为依赖，不得并行。needs-review 偏差会阻止 READY_FOR_REVIEW，除非该偏差是唯一安全路径且已明确记录。子代理不可用时仍按相同波次本地顺序执行并在预检中报告。完成门要求每个任务已完成或明确未完成并说明原因，已完成任务均有证据，偏差均为 none、approved 或 needs-review，并列出改动文件与验证证据。