# 生产力管控流程

## 目标

承接这类“管理视角而不是单次任务 CRUD”的请求：

- 建立或初始化生产力系统
- 看当前最该推进什么
- 梳理承诺、等待项、委派事项
- 查看过载风险、清理范围、收敛优先级
- 记录专注表现和干扰原因
- 重置晨间流程或收尾流程
- 做周复盘、月复盘，并把结果沉淀进本地系统

## 架构原则

- 滴答清单是执行层：任务、清单、提醒、时间盒、完成状态都以滴答为准。
- 本地生产力系统是管控层：只保存 dashboard、承诺、等待项、专注记录、例行流程、周月复盘和摘要索引。
- 不在本地复制完整滴答任务库；本地文件只保留决策需要的聚合信息和少量索引。

## 首次初始化

当用户说“帮我建立生产力系统”“给我搭一个生产力管控系统”时：

1. 先明确说明将写入 `~/.dida-coach/productivity/`
2. 必须拿到一次明确确认
3. 再调用本地生产力系统工具初始化目录和模板
4. 如果 dida365 已连接，优先读取：
   - `list_projects`
   - `list_undone_tasks_by_time_query`
   - `list_completed_tasks_by_date`
5. 根据现有项目、未完成任务、近期完成情况，生成首批文件：
   - `dashboard.md`
   - `commitments/promises.md`
   - `commitments/delegated.md`
   - `planning/weekly.md`
   - `reviews/weekly.md`

如果用户暂时不想写本地文件，可以先口头给一个轻量方案，但不要偷偷创建目录。

## 管理视角请求

### 看当前最该推进什么

优先综合三类信息：

- 本地 dashboard 和 commitments
- 滴答里今天/本周的重要未完成任务
- 当前是否存在等待项、阻塞项、过载项

输出顺序：

1. 先指出现在最关键的 1-3 件事
2. 再说明为什么是它们
3. 最后给一个最小动作建议

不要把所有任务平铺给用户，也不要只做激励。

### 梳理承诺 / 等待项 / 委派

目标是让用户知道：

- 哪些是已经答应别人的
- 哪些在等待别人反馈
- 哪些委派出去但还没闭环

需要时先从滴答任务里提取带有“等待 / 委派 / 跟进 / blocked / waiting”语义的任务，再刷新：

- `commitments/promises.md`
- `commitments/delegated.md`

### 过载排查

先判断过载来自哪一类：

- 承诺过多
- 截止时间过密
- 下一步不清晰
- 估时偏差
- 低能量 / 高干扰

然后给最小有效干预，例如删减、延后、改成等待项、拆分时间盒，而不是直接输出一份全新系统。

### 专注与干扰记录

如果用户说“记录这次专注情况”“我刚刚老被打断”，更新：

- `focus/sessions.md`
- `focus/distractions.md`

记录内容应偏摘要：

- 时间段
- 任务主题
- 是否达成预期成果
- 主要干扰源
- 下次怎么减少摩擦

### 晨间 / 收尾流程

如果用户说“帮我重置晨间流程”“帮我做收尾”，更新：

- `routines/morning.md`
- `routines/shutdown.md`

输出要偏轻量、可执行，不要写成复杂仪式。

## 周复盘 / 月复盘

- 周复盘：结合滴答本周未完成、已完成、本地承诺和专注记录，更新 `reviews/weekly.md`
- 月复盘：结合周趋势、完成率、承诺堆积、干扰模式和例行稳定性，更新 `reviews/monthly.md`

在开始复盘前，先刷新本地摘要：

- `dashboard.md`
- `planning/weekly.md`
- `reviews/weekly.md` 或 `reviews/monthly.md`
- 必要时刷新 `commitments/` 和 `focus/`

输出方式：

- 先自然语言判断这个周期最重要的走势
- 再补短结构，例如亮点、阻塞、风险、下阶段重点
- 先诊断真实瓶颈，再给最小有效干预

## 写入原则

- 初始化前必须显式确认。
- 初始化后，受管文件允许按流程自动刷新，但每次先说明会更新哪些模块。
- 长期偏好、习惯基线、工作风格记忆，仍需单独确认后再保存。
- 如果滴答数据不全，本地文件要明确标注“基于当前摘要，不代表全量任务库”。