# ZenTao Decision Rules

这份文件用于约束智能体在“任务创建”和“查询视图选择”上的决策，不要靠猜。

## 1. 创建任务前检查清单

在真正创建任务前，先确认这 4 件事：

1. 这是普通任务，还是“从需求拆分任务”。
2. 目标是单负责人任务，还是多人并行任务。
3. 任务应该落在哪个项目、哪个执行下。
4. 如果关联需求，这个执行是否真的属于该需求归属项目，并且适合承接该需求。

缺任何一个关键条件时，不要直接创建到一个猜测出来的执行下面。

## 2. 多人并行任务规则

当前工具已经支持多人任务创建。

因此：

- 用户明确给出一个任务、多个执行人时，默认创建“多人并行”任务。
- 用户明确说“串行”“依次处理”时，才创建“多人串行”任务。
- 如果用户表达的是“拆成几个人各自处理不同子项”，优先拆成多个单人任务，而不是硬塞成一个多人任务。
- 如果用户既说了多人，又说了明确子任务边界，先拆分再创建，不要偷懒建成一个总任务。
- 多人任务创建成功后，返回时要明确说明任务模式是“多人并行”还是“多人串行”。

## 3. 需求拆分任务规则

只要用户提供了需求 ID、需求链接，或者明确表达“从需求拆任务”，就必须走需求拆分路径，不要直接把任务建到一个随手选的执行下面。

标准顺序：

1. 先读取需求详情。
2. 识别需求归属的项目。
3. 优先查该项目下当前可用执行。
4. 如果需求已经挂在某个执行体系里，优先复用同项目、同周期的执行。
5. 如果当前月没有可用执行，再走“复制上个执行配置 -> 创建本月执行”。
6. 最后再调用 `task create --storyId ...`，确保任务与需求绑定。

禁止行为：

- 只因为某个执行“看起来在进行中”，就直接把任务建进去。
- 没核对项目归属，就把 A 项目的需求任务建到 B 项目的执行下。
- 已知要关联需求，却不传 `storyId`，导致任务和需求脱钩。

## 4. 执行选择规则

### 普通任务

- 用户已明确给出 `execId`：可以直接使用。
- 用户只给了项目，没有给执行：先查该项目活跃执行，再决定是否复用或新建。
- 用户既没给项目也没给执行：不要盲建，先补项目上下文。

### 需求拆分任务

- 优先以需求归属项目为准。
- 如果用户手动指定了执行，也必须核查该执行是否属于该项目。
- 如果执行不属于需求归属项目，不能直接创建，应提示用户修正。

## 5. 什么时候用 my，什么时候用 manage

这是最容易混淆的一层，必须按意图路由。

### 用 `my`

适用于这些场景：

- 用户明确说“我”“我的”“当前登录用户”。
- 用户要看官方地盘视角的指派事项。
- 用户要精确查看“某个账号被正式指派了哪些任务”，而不是管理汇总口径。

典型理解：

- “我现在有什么任务”
- “我名下有哪些 Bug”
- “查 zhangsan 被指派的任务”

### 用 `manage`

适用于这些场景：

- 用户是管理者，要看某个人“相关的任务池”，而不是只看官方指派。
- 用户要汇总一个团队的任务、需求、Bug。
- 用户要做晨会、周报、延期排查、团队风险扫描。

典型理解：

- “帮我看张三今天需要盯哪些事项”
- “汇总后台一组的任务、需求、Bug”
- “帮我出今天的晨会通报”

### 一句话判断

- “官方指派 / 我自己的地盘” -> `my`
- “管理汇总 / 团队总览 / 风险筛查” -> `manage`

## 6. 输出要求

创建任务后，返回时至少说清楚：

- 是否成功创建
- 创建到了哪个项目/执行
- 是否已成功关联需求
- 指派给谁
- 如果没有创建，明确卡在哪个前置条件

查询时，返回时至少说清楚：

- 这是 `my` 视角还是 `manage` 视角
- 当前筛选口径是什么
- 结果是单人还是团队汇总

如果用户给的是任务 / 需求 / Bug 链接，并且在问：

- “是否闭环”
- “是不是已经完成”
- “这个人是不是做完了”

则优先走 `view`，并遵守这 3 条：

1. 先说整体状态。
2. 如果是多人并行任务，再单独说成员个人状态。
3. 最终明确回答“个人是否完成”和“整体是否闭环”是否为同一件事。