# DevFlow 工作规范

## 任务看板自动领单（最高优先级纪律）

1. **会话启动即读板**：任何会话开工前，先读 `docs/todo.md`——按优先级领任务：🔴 高危项 > B 批次/编号项 > C 类候选。
2. **批收敛即回读**：每完成一个任务批（提交后），重读看板领下一项——挂机/连续工作模式下每批必回读，禁凭记忆连续开工。
3. **领单动作**：领单后将条目改为 `[→]`（进行中），完成后改 `[x]` 并附验收命令输出（G4）；无法完成的改 `[!]` 附卡点，禁静默跳过。
4. **🔴 门禁（G2）**：看板存在未清零 🔴 条目时，只允许领 🔴 销账任务，新功能任务禁领（除非用户明示）。
5. **提交纪律（G3/G4）**：提交描述与 diff 机械对应；一笔一事或逐件列全；分组提交按看板标注的主题分组。
6. **汇报实测**：任何进度/完成汇报，先跑 `git log -1 --format="%h %s"` 与 `git status --short | wc -l` 实测再报，禁凭记忆报状态。
7. **看板顶部「挂机必读」警示**：启动时若存在，视为最高优先级上下文覆盖。

## 自主修复纪律

- 明确 bug（实证在案/用户指出/唯一正确解或用户已给修法方向）：直接修并报告，禁反问「要不要修」（2026-10-06 用户纠正：发现换装脚本缺陷后反问=自主性差）。
- 边界对齐意志卡 forbidden：发版/部署/重启线上、git push、生产数据操作、对外发消息，攒齐等拍板。
- 本机工具/脚本的行为变更属 report_after 级（干完通报、可回滚），不属确认级。

## 命名与代码风格（2026-10-10 用户重申）

- **变量/方法名：精简 + 准确**——一眼看出「是什么/做什么」且不超必要长度。忌把实现细节写进名字（`..._after_tool_run`）、忌无信息缩写（`tmp2`/`h`）、忌同概念多叫法。名字过长通常说明该拆函数或把说明下沉到注释（注释承载「为什么」，名字只承载「是什么」）。
- **DRY · 简洁 · 扩展性 · 高内聚低耦合**（同期重申）：新增能力先找共用底座（如定时消息与定时任务共用一张 `ai_outbox` + 一个调度器），不造双轨；同一事实只留**单一真值来源**（如 token 估值口径）。

## 其他规范
- 架构设计文档在 `docs/02-架构设计/`；当前活跃专项：无人值守可靠性（B1-B4）+ 异步任务会话（13-17），设计见 `temp/` 与 docs。