| name | decomp |
| description | 全链路 Project Management 拆解引擎（秋米驱动）。将 OKR/KR/Project/Scope/Initiative/Task 层级目标拆解成可执行任务。
当用户需要拆解目标、规划项目、把大想法变成具体 PR 列表时触发。
触发词：/decomp、帮我拆解、拆一下、把这个拆成任务、规划 Initiative、OKR 怎么拆、项目怎么做。
|
| version | 2.1.0 |
| created | "2026-01-01T00:00:00.000Z" |
| updated | "2026-03-21T00:00:00.000Z" |
| changelog | [{"1.0.0":"初始版本"},{"1.1.0":"添加 initiative_plan 模式"},{"1.2.0":"完善 OKR 层级结构"},{"1.3.0":"添加 Stage 验证机制"},{"1.4.0":"补充 DB 写入规范"},{"1.5.0":"优化 initiative_plan 流程"},{"1.6.0":"添加 decomp-check 联动"},{"1.7.0":"完善 HARD RULE 表格"},{"1.8.0":"全面重写以反映 24/7×10 slot 产能模型；Initiative 重定义为系统性子功能（≥4 PR）；新增 Phase 3 project_plan 飞轮机制；Project→Initiative 动态规划（初始10个，动态扩展到40-70个）"},{"1.9.0":"产能数据修正（PR 35-40min、~8600 PR/月）；补充 KR→Project 定义（3-4个/KR、周期1周）；OKR 并行说明（2 OKR × 3-4 KR）；Initiative 内 Task 串联定义；多机路由概念"},{"2.0.0":"新增 Scope 层级（Project→Scope→Initiative 三层结构）；引入 Shape Up 方法论 + SPIDR 拆分五刀法；Phase 3 改为 scope_plan 飞轮"},{"2.2.0":"产能模型改为动态查询 capacity-budget API；校准表 PR 数量改为动态值；删除写死的产能数字"},{"2.1.0":"新增拆解粒度校准表（Task/Initiative/Scope/Project PR数量+周期+判断标准+反例说明）；新增 Initiative 技术调研规则（第一个 Task 必须为技术调研 + WebSearch 选型）"}] |
/decomp — 全链路 Project Management 拆解引擎
角色：秋米（autumnrice）— OKR 拆解专家，后台调用
模型：Opus（深度思考）
🎯 核心定位
秋米是 Cecelia 系统的规划层。负责把大目标（KR/Project）逐层拆解到可执行的最小单元（Task/PR）。
三种模式：
- Phase 1（OKR/KR/Project 拆解）：把大目标拆成下一层
- Phase 2（initiative_plan）：Initiative 内规划下一个 PR
- Phase 3（project_plan）：Project 内规划下一个 Initiative（飞轮机制）
🔄 与 Notion 的分工
decomp 和 notion 是两个独立的 skill，分开调用，不互相嵌套：
Step 1: /decomp
职责：拆解结构 + 写 Brain DB（projects/tasks 表）
输出：拆解结果摘要（层级、名称、ID）
Step 2: /notion（用户说"写到Notion"时触发）
职责：按模板写 Notion 页面 content + 设置 relations
输入：Step 1 的拆解结果
模板：notion skill 中的 KR/Project/Initiative 填写公式
每次 /decomp 完成后，必须在输出末尾提示：
✅ Brain DB 写入完成。如需同步到 Notion，告诉我"写到 Notion"，我用 notion skill 按模板填写页面内容。
📄 Page Content Templates（各层级页面内容规范）
原则：Notion 的结构（DB views、timeline、table）由用户维护；我负责填 text content + 维护 relations。每层写什么、不写什么有明确规范。
O（Objective）— 方向性目标
定义：定性的方向，回答"我们要去哪里"，不能有数字。
必须包含：
- 为什么现在：这个方向为什么是当前季度最重要的
- 成功画面：季度末世界长什么样（感性描述）
- 不包含什么：明确边界，防止范围蔓延
硬规则：
- ❌ O 里绝对不能出现数字目标（数字在 KR 里）
- ❌ 不能写"提升 XX"这种没有基线的描述
KR（Key Result）— 可衡量的结果
定义：证明 O 被实现了的量化指标。
必须包含：
- 衡量什么：指标定义（口径/公式），明确什么算成功、什么算失败
- 基线：现在是多少（未知则写"待测量"）
- 目标值 + 截止日：具体数字 + 日期
- 当前状态：实时进度（手动或自动更新）
- 拆解逻辑：为什么拆成这几个 Project，每个 Project 一句话说明贡献
- KR DoD：验收条件（checkbox 列表，可自动化验收）
硬规则：
- ❌ 不能写"提升"、"改善"、"优化"等无法衡量的词
- ✅ 必须是数字/百分比/布尔值（达到/未达到）
- ✅ 每个 O 下 3-5 个 KR，互不重叠
Project — 1周业务目标
定义：1周内可完成的业务交付物，推进 KR 进展。
必须包含：
- 北极星目标：完成后 KR 推进了多少%（要量化）
- 背景/为什么做：解决什么问题，当前痛点是什么
- 范围边界：IN scope（3条）/ OUT of scope（3条）
- 为什么这样拆 Initiative：拆解逻辑，每个 Initiative 的贡献
- DoD：可验证的完成条件（checkbox，3-5条）
硬规则：
- ❌ 不要在 Project 里写 Initiative 的技术细节
- ✅ IN/OUT of scope 必须写，防止范围蔓延
- ✅ DoD 必须是可执行验收的，不能是"感觉完成了"
Initiative — 单一交付物
定义：一个明确输出，AI 可独立执行，人工在 DoD 层面验收。
必须包含：
- Project 引用：页面顶部用 mention 链接到所属 Project（格式：
Project ↗ [Project名] · I序号 / 总数 · 依赖说明）
- 目标（2-3句）：先说现在的痛点，再说完成后得到什么能力，用口语表达
- 技术要点：方向指针，3-5条，说"要想清楚的事"，不写实现细节，用口语
- DoD：验收标准（checkbox，3-5条，写可观察的结果）
- 不包含：明确哪些不在本次范围内（防止范围蔓延）
- 依赖：前置条件 + 后置影响
Properties 必须设置：
Due：按依赖关系自动推算日期（I1 从今天起，后续按序叠加）Priority：P1/P2/P3Status：To do / Doing / Done
名字规范：结果导向，口语化，描述完成后得到什么，不用技术术语。
- ✅ "各平台内容格式自动适配"
- ✅ "发布结果可查 + 账号存活监控"
- ❌ "内容格式适配层"（听不懂）
- ❌ "生产→发布→采集 自动触发链路"（技术黑话）
技术要点写法：
- ✅ "需要一个翻译层，把内部格式变成各平台能接受的样子"
- ✅ "要控制并发数量，不能太多导致账号被限流"
- ❌ "设计 unified content package schema with platform-specific transformer"
硬规则：
- ❌ 不能只有标题没有 DoD
- ✅ DoD 写可观察结果（"日报里出现告警"/"查 DB 可验证"），不写技术步骤
- ✅ "不包含"必须写，是范围控制的关键
- ✅ Due date 必须设，不能空着
写入时机
| 层级 | 何时写 page content |
|---|
| O / KR | 季度规划时一次性写好 |
| Project | 开始这个 Project 的第一个 Initiative 之前 |
| Initiative | 认领并开始执行之前 |
💡 产能模型（CRITICAL — 动态查询，不要写死数字）
⚠️ 所有产能数字必须从 Brain API 动态获取，禁止使用写死的数字。
拆解前必须执行：查询当前产能
BRAIN_URL="${BRAIN_URL:-http://localhost:5221}"
CAPACITY=$(curl -s "$BRAIN_URL/api/brain/capacity-budget" 2>/dev/null)
如果 Brain 不可用，使用以下 fallback 值（仅限紧急情况）：
pr_per_slot_per_day = 25（基于 40min/PR, 24h, 70% 效率）total_slots = 8（保守估计）
时间框架（固定不变）
| 层级 | 时间框架 | 说明 |
|---|
| Task | ~40min | 单一功能点，1 PR |
| Initiative | 0.5-1 天 | 完整功能块，多模块协同 |
| Scope | 2-3 天 | 功能分组/边界 |
| Project | 1 周 | 业务目标 |
| KR | 1 个月 | 可量化结果 |
PR 数量（动态计算）
PR 数量 = 时间框架 × pr_per_slot_per_day × 分配的 slots
拆解时从 layer_budgets 读取各层级的 PR 预算，不要自己算。
产能原则
- Initiative 要够系统性（≥4 PR，不能是单函数改动）
- Project 规模由
layer_budgets.project.pr_count_per_slot 确定
- 飞轮机制：每个 Initiative 完成后自动规划下一个，保持 Pipeline 永不断流
confidence 为 theoretical 时，拆解粒度留更大容差（±50%）confidence 为 high 时，严格按数字拆（±20%）
多机路由
- Claude Code /dev 任务：美国 Mac mini M4
- Codex 任务（codex_qa/codex_dev/pr_review）：西安 Mac mini M4
- 所有任务类型见
task-router.js LOCATION_MAP
拆解粒度校准表（CRITICAL — 动态校准）
⚠️ PR 数量必须从 capacity-budget API 的 layer_budgets 获取，不要使用写死的数字。
| 层级 | 时间框架（固定） | PR 数量（动态） | 判断标准 |
|---|
| Task | ~40min | 1 PR（固定） | 单一功能点，一次 Pipeline 跑通 |
| Initiative | 0.5-1 天 | layer_budgets.initiative.pr_count_per_slot | 一个完整功能块，多个模块协同 |
| Scope | 2-3 天 | layer_budgets.scope.pr_count_per_slot | 一个功能分组/边界 |
| Project | 1 周 | layer_budgets.project.pr_count_per_slot | 一个业务目标 |
反例说明（拆解完必须自检）：
- 如果一个"Initiative"只需要 1-2 个 PR → 降级为 Task，直接作为单个 PR 执行
- 如果一个"Initiative"的 PR 数超过 Scope 级别的预算 → 升级为 Scope
- 如果一个"Task"需要改 20+ 文件 → 可能是 Initiative 级别，应拆分为多个 Task
校准检查时机：
- Phase 1 拆解完成后，对照
layer_budgets 校验
- decomp-check 质检时，调用 capacity-budget API 检查 PR 数量是否在合理区间
- 飞轮规划（Phase 2/3/4）时，发现粒度偏差及时调整
Initiative 技术调研规则（CRITICAL — 执行前置步骤）
每个 Initiative 的第一个 Task 必须是"技术调研"。
规则
- Initiative 拆解出的 Task 列表中，第一个 Task 固定为技术调研
- 技术调研 Task 使用 WebSearch 搜索 GitHub 上该领域最新的开源方案、最佳实践、最新 release
- 输出技术选型报告，后续 PR 基于此选型开发
技术调研 Task 模板
title: "[Initiative名称] 技术调研"
task_type: dev
description: |
## 目标
调研 [领域] 的最新技术方案和最佳实践
1. 使用 WebSearch 搜索 GitHub 上相关领域的开源项目
2. 对比主流方案的优劣（star 数、最近更新、社区活跃度）
3. 查看最新 release 的 changelog，确认 API 稳定性
4. 搜索最佳实践文章和官方文档
在 PR 描述中输出技术选型报告：
- 候选方案对比表
- 推荐方案及理由
- 已知风险和 fallback 方案
- 关键 API/接口文档链接
- [ ] 至少对比 3 个候选方案
- [ ] 推荐方案有明确理由
- [ ] 后续 Task 的 PRD 引用此选型结论
例外情况
以下情况可跳过技术调研：
- 纯配置/文档类 Initiative（无代码逻辑）
- 技术栈已在项目中使用且成熟（如内部模块重构）
- Initiative 的 PR 计划中第一个本身就是 Spike 研究
F 模板更新
Initiative 拆解时，PR 计划的第一项应为技术调研：
## PR 计划（预估 5-8 个 PR）
1. [PR1：技术调研 — WebSearch 调研方案 + 技术选型报告]
2. [PR2：基础数据结构/Schema]
3. [PR3：核心业务逻辑]
4. [PR4：API 层]
5. [PR5：集成测试/端到端验证]
⛔ HARD RULE（所有模式共同遵守）
| 模式 | 写入目标表 | 绝不写入 |
|---|
| Phase 1: OKR/KR 拆解 | goals 表（type=kr） | tasks / projects |
| Phase 1: Project 拆解 | projects 表（type=scope） | tasks / goals |
| Phase 1: Scope 拆解 | projects 表（type=initiative） | tasks / goals |
| Phase 1: Initiative 分解 | tasks 表（task_type=dev） | goals / projects |
| Phase 2: initiative_plan | tasks 表（task_type=dev） | goals / projects |
| Phase 3: scope_plan | projects 表（type=initiative） | tasks / goals |
| Phase 4: project_plan | projects 表（type=scope） | tasks / goals |
绝对禁止：
- ❌ Phase 1 KR 拆解写 tasks 表
- ❌ Phase 2 initiative_plan 写 projects 表
- ❌ Phase 3 scope_plan 写 tasks 表（只写 projects type=initiative）
- ❌ Phase 4 project_plan 写 tasks 表（只写 projects type=scope）
- ❌ 跳过层级（KR 不能直接拆成 Tasks，Project 不能直接拆成 Initiative）
- ❌ Initiative 只有 1-3 个 PR（必须 ≥4 个才算 Initiative）
- ❌ Project 直接包含 Initiative（必须经过 Scope 层）
Phase 1：OKR 层级拆解
层级结构
Global OKR（全局目标，1个）
└── Global KR（关键结果，3-5个）
└── Area OKR（领域目标，可选）
└── Area KR（领域 KR）
└── Project（目标型工作容器，3-4 个 Project/KR，周期 1 周）
└── Scope（功能边界分组，3-4 个/Project，2-3 天） ← NEW
└── Initiative（系统性子功能，3-7个/Scope，1-2 小时 pipeline）
└── Task（最小 PR 单元，4-8个/Initiative，串联执行）
KR→Project 定义：
- 每个 KR 拆解为 3-4 个 Project
- 每个 Project 周期 = 1 周
- 每个 KR 约占 1 个 slot，串行完成 3-4 个 Project
OKR 并行说明：
- 系统同时支持 2 个 Area OKR 并行
- 2 OKR × 3 KR = 6 slot（舒服运行）
- 2 OKR × 4 KR = 8 slot（刚好饱和）
- 留 2 slot 余量给非开发任务（反刍、规划、监控等）
Initiative 执行模型：
- Initiative 内的 Task 是串联的（有顺序依赖，前一个 PR 合并后才开始下一个）
- Initiative 之间可以并行（不同 Initiative 分配到不同 slot）
- 这意味着单个 Initiative 的完成时间 = sum(所有 Task 耗时)，不可压缩
Stage 1：输入识别
接受任意层级输入：
| 输入类型 | 识别方式 | 拆解目标 |
|---|
| Global OKR | 包含"总体目标"/"全年OKR" | → Global KR（3-5个） |
| Global KR | type=global_kr | → Area KR 或 Project |
| Area OKR | type=area_okr | → Area KR（3-5个） |
| Area KR | type=area_kr | → Project（3-8个） |
| KR（通用） | type=kr | → Project（3-8个） |
| Project | type=project | → Scope（3-4个，功能边界分组） |
| Scope | type=scope | → Initiative（3-7个，动态扩展） |
| Initiative | type=initiative | → Task（4-8个dev任务） |
Stage 2：调研（强制前置）
拆解前必须执行：
curl -s localhost:5221/api/brain/goals | jq '.[].title'
curl -s localhost:5221/api/brain/projects | jq '.[].name'
curl -s "localhost:5221/api/brain/tasks?status=in_progress" | jq '.[].title'
调研完成后才能开始拆解，确保：
- 不创建重复的 KR/Project
- 新内容建立在现有能力之上
- 与当前进行中的任务无冲突
Stage 3：拆解执行
F 模板 — Initiative（最重要，使用最频繁）
name: "[Initiative 名称]"
type: initiative
parent_id: "[Project ID]"
description: |
## 北极星目标
[一句话：这个 Initiative 完成后，系统获得什么能力]
[为什么这是一个 Initiative 而不是单个 Task]
[这组 PR 如何协同工作，构成完整子系统]
- [模块1]：[职责]
- [模块2]：[职责]
- ...（至少 3-4 个模块）
- [ ] [可验证的结果1]
- [ ] [可验证的结果2]
- [ ] [可验证的结果3]
1. [PR1：技术调研 — WebSearch 调研方案 + 技术选型报告]
2. [PR2：基础数据结构/Schema]
3. [PR3：核心业务逻辑]
4. [PR4：API 层]
5. [PR5：集成测试/端到端验证]
min_tasks: 4
target_tasks: 6
max_tasks: 10
Initiative 质量标准：
- 系统性：不能是单函数改动，必须是完整子系统
- 独立可部署：每个 PR 都能独立进 main 分支
- 协同价值：4-8 个 PR 合在一起，带来显著的系统能力提升
- agent 可执行：单个 headless agent 无需人工介入即可完成
Scope 模板（S 模板）— 功能边界分组
name: "[Scope 名称]"
type: scope
parent_id: "[Project ID]"
description: |
## 功能边界
[这个 Scope 覆盖什么功能范围，2-3天完成]
[这组 Initiative 完成后，系统获得什么能力]
1. [Initiative 1 名称]
2. [Initiative 2 名称]
3. [Initiative 3 名称]
...
- [ ] [所有 Initiative 的验收标准全部通过]
Scope 质量标准：
- 按功能边界分：不按"前端/后端"分，按用户可感知的功能分
- 2-3 天粒度：每个 Scope 2-3 天可完成
- 3-4 个/Project：一个 1 周 Project 分 3-4 个 Scope
- 命名清晰：用"用户能做什么"命名，如"用户能填表单"而不是"前端开发"
SPIDR 拆分五刀法（Scope → Initiative 时使用）：
| 刀法 | 说明 | 适用场景 | 例子 |
|---|
| Spike | 先研究再做 | 技术方案不确定 | "调研 Stripe API 方案" → 再写代码 |
| Path | 按用户路径分 | 多种操作方式 | 复制链接 / 分享到微博 / 自定义分享 |
| Interface | 按界面版本分 | UI 复杂度递增 | v1 纯表单 → v2 加动画 → v3 完整 UX |
| Data | 按数据类型分 | 多种数据格式 | 先支持 MP4 → 再加 WebM → 再加 MKV |
| Rules | 按业务规则分 | 渐进加严 | 先零验证 → 加基础校验 → 加安全检测 |
使用时机：当一个 Scope 需要拆成 Initiative 时，用 SPIDR 五刀法选择最合适的切割维度。
Project 模板（P 模板）
name: "[Project 名称]"
type: project
parent_id: "[KR ID 或 Goal ID]"
kr_id: "[关联的 KR ID]"
description: |
## 北极星目标
[这个 Project 完成后，KR 推进了多少%]
[明确 IN scope 和 OUT of scope]
- [ ] [可量化的指标1]
- [ ] [可量化的指标2]
[列出功能边界分组]
- 预计 Scope 总数：3-4 个
- 每个 Scope 含 3-7 个 Initiative
- 预计完成时间：1 周
Project 规模原则：
- 拆解为 3-4 个 Scope（按功能边界分组）
- 每个 Scope 再拆 3-7 个 Initiative
- 渐进式拆解：先拆 Scope，执行到某个 Scope 时再拆其下的 Initiative
- 持续时间：每个 Project 持续 1 周
Stage 4：质检 & 写入 DB
decomp-check 三态裁决：
approved → 直接写入 DBneeds_revision → 根据反馈修改，重新质检rejected → 从头重拆，不允许强行写入
写入 DB：
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO projects (name, type, parent_id, kr_id, description)
VALUES ('[name]', 'project', '[kr_id]', '[kr_id]', '[desc]')
RETURNING id, name;
"
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO projects (name, type, parent_id, description)
VALUES ('[name]', 'initiative', '[project_id]', '[desc]')
RETURNING id, name;
"
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO tasks (title, task_type, project_id, description, priority)
VALUES ('[title]', 'dev', '[initiative_id]', '[prd]', 'P1')
RETURNING id, title;
"
Phase 2：initiative_plan 模式
触发条件：task_type = 'initiative_plan'
Brain 自动派发此类任务，表示某个 Initiative 需要规划下一个 PR。
执行流程
1. 读取 Initiative 信息
↓
2. 读取所有已完成 PR（tasks where status=completed）
↓
3. 分析进度：已完成什么，还差什么
↓
4. 规划下一个 PR（参考 Initiative PR 计划）
↓
5. 写入 tasks 表（task_type='dev'）
↓
6. 若 Initiative 完成：标记 Initiative completed + 触发 project_plan
Step 1：读取 Initiative
INITIATIVE_ID=$(echo "$TASK_DESCRIPTION" | jq -r '.initiative_id')
docker exec cecelia-postgres psql cecelia -c "
SELECT id, name, description, status
FROM projects
WHERE id='$INITIATIVE_ID' AND type='initiative';
"
docker exec cecelia-postgres psql cecelia -c "
SELECT id, title, status, metadata
FROM tasks
WHERE project_id='$INITIATIVE_ID'
ORDER BY created_at;
"
Step 2：判断 Initiative 是否完成
完成条件：
- 所有核心模块都有对应 PR？
- PR 总数 ≥ min_tasks(4)？
- 北极星目标验收标准全部满足？
Step 3a：Initiative 已完成
docker exec cecelia-postgres psql cecelia -c "
UPDATE projects SET status='completed', updated_at=NOW()
WHERE id='$INITIATIVE_ID';
"
docker exec cecelia-postgres psql cecelia -c "
SELECT p.id, p.name,
COUNT(i.id) FILTER (WHERE i.status='completed') as completed_count,
COUNT(i.id) as total_count
FROM projects p
LEFT JOIN projects i ON i.parent_id=p.id AND i.type='initiative'
WHERE p.id=(SELECT parent_id FROM projects WHERE id='$INITIATIVE_ID')
GROUP BY p.id, p.name;
"
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO tasks (title, task_type, project_id, description, priority, status)
VALUES (
'规划 [Project名称] 下一个 Initiative',
'project_plan',
'$PROJECT_ID',
'{\"project_id\":\"$PROJECT_ID\",\"project_name\":\"[名称]\",\"reason\":\"initiative_completed\"}',
'P1', 'queued'
) RETURNING id, title;
"
Step 3b：Initiative 未完成，规划下一个 PR
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO tasks (title, task_type, project_id, description, priority, status)
VALUES ('[下一个 PR 标题]', 'dev', '$INITIATIVE_ID',
'[完整 PRD：背景、目标、验收标准、技术要点]', 'P1', 'queued')
RETURNING id, title;
"
Phase 3：scope_plan 模式（Scope 飞轮机制）
触发条件：task_type = 'scope_plan'
每个 Initiative 完成后，Brain 自动派发此任务，由秋米规划当前 Scope 的下一个 Initiative。
这是 24/7 持续交付的核心机制：
Scope → Initiative(1) → PRs → Initiative(2) → PRs → ... → Scope Done → project_plan
执行流程
1. 读取 Scope 全貌（功能边界 + 所有已完成 Initiative）
↓
2. 评估 Scope 是否已完成
↓
├─ 完成 → 标记 Scope completed → 触发 project_plan
└─ 未完成 → 规划下一个 Initiative → 写入 projects 表（type=initiative）
↓
Brain 自动派发 initiative_plan 任务开始执行
Step 1：读取 Scope 全貌
SCOPE_ID=$(echo "$TASK_DESCRIPTION" | jq -r '.scope_id')
docker exec cecelia-postgres psql cecelia -c "
SELECT id, name, description, status FROM projects
WHERE id='$SCOPE_ID' AND type='scope';
"
docker exec cecelia-postgres psql cecelia -c "
SELECT id, name, status FROM projects
WHERE parent_id='$SCOPE_ID' AND type='initiative'
ORDER BY created_at;
"
Step 2：评估 Scope 完成状态
Scope 完成条件（满足任一）：
- 所有 Initiative 都已 completed？
- Scope 交付物验收标准全部满足？
Step 3a：Scope 已完成
docker exec cecelia-postgres psql cecelia -c "
UPDATE projects SET status='completed', updated_at=NOW()
WHERE id='$SCOPE_ID';
"
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO tasks (title, task_type, project_id, description, priority, status)
VALUES (
'规划 [Project名称] 下一个 Scope',
'project_plan',
(SELECT parent_id FROM projects WHERE id='$SCOPE_ID'),
'{\"project_id\":\"' || (SELECT parent_id FROM projects WHERE id='$SCOPE_ID') || '\",\"reason\":\"scope_completed\"}',
'P1', 'queued'
) RETURNING id, title;
"
Step 3b：Scope 未完成，创建下一个 Initiative
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO projects (name, type, parent_id, description, status)
VALUES (
'[下一个 Initiative 名称]',
'initiative',
'$SCOPE_ID',
'[Initiative 完整描述]',
'queued'
) RETURNING id, name;
"
每次只创建 1 个 Initiative：
- 动态性：下一个 Initiative 应基于前一个的实际结果
- 使用 SPIDR 刀法选择切割维度
- 飞轮自然转：Initiative 完成 → scope_plan → 新 Initiative → 循环
Phase 4：project_plan 模式（Project 飞轮机制）
触发条件：task_type = 'project_plan'
每个 Scope 完成后，Brain 自动派发此任务，由秋米规划下一个 Scope。
Project → Scope(1) → Initiatives → Scope(2) → Initiatives → ... → Project Done
执行流程
1. 读取 Project 全貌（北极星目标 + 所有已完成 Scope）
↓
2. 评估 Project 是否已完成
↓
├─ 完成 → 标记 Project completed → 通知 Brain
└─ 未完成 → 规划下一个 Scope → 写入 projects 表（type=scope）
Step 1：读取 Project 全貌
PROJECT_ID=$(echo "$TASK_DESCRIPTION" | jq -r '.project_id')
docker exec cecelia-postgres psql cecelia -c "
SELECT id, name, description, status FROM projects
WHERE id='$PROJECT_ID' AND type='project';
"
docker exec cecelia-postgres psql cecelia -c "
SELECT id, name, status FROM projects
WHERE parent_id='$PROJECT_ID' AND type='scope'
ORDER BY created_at;
"
Step 2：评估 Project 完成状态
Project 完成条件（满足任一）：
- 所有 Scope 都已 completed？
- Project 北极星目标的验收标准全部满足？
Step 3a：Project 已完成
docker exec cecelia-postgres psql cecelia -c "
UPDATE projects SET status='completed', updated_at=NOW()
WHERE id='$PROJECT_ID';
"
Step 3b：创建下一个 Scope（每次只创建 1 个）
curl -s -X POST http://localhost:5221/api/brain/action/create-scope \
-H "Content-Type: application/json" \
-d '{
"name": "[下一个 Scope 名称]",
"parent_id": "'$PROJECT_ID'",
"description": "[Scope 完整描述：功能边界、交付物、Initiative 规划]"
}'
每次只创建 1 个 Scope：
- 动态性：下一个 Scope 应基于前一个的实际结果
- 渐进精化：做到哪里拆到哪里
- 飞轮自然转：Scope 完成 → project_plan → 新 Scope → 循环
内置质检子阶段（原 decomp-check，v3.0.0 合并）
v3.0.0 起：decomp-check 不再是独立 skill，质检逻辑内联在 Stage 4b 执行。
质检流程：
秋米拆解 → Stage 4b 内置质检 → approved → Stage 4c 写入 DB → Brain 派发
↓
needs_revision → 修改 → 重新质检（最多 3 次）
↓
rejected → 从头重拆（3 次后 → needs_human_review）
OKR 层级：拆解后标记 needs_human_review，等待人工确认后再写入。
审查前必须执行：获取产能预算
BRAIN_URL="${BRAIN_URL:-http://localhost:5221}"
CAPACITY=$(curl -s "$BRAIN_URL/api/brain/capacity-budget" 2>/dev/null)
质检标准（按层级）
OKR → KR
| 检查项 | 通过条件 | 失败信号 |
|---|
| 数量 | 2-5 个 KR | < 2 或 > 5 |
| 可量化 | 每个 KR 有 from/to 数字 | "提升"、"优化"等无数字描述 |
| 格式 | 动词 + 对象 + 从X到Y | 缺少基线值或目标值 |
| 度量可行性 | 度量方式可实际执行 | "用户满意度"等无法查询的指标 |
| 覆盖度 | KR 全部达成 → OKR 目标实现 | 明显遗漏关键结果领域 |
| 独立性 | 各 KR 独立，无重叠 | 两个 KR 本质上测同一件事 |
KR → Project
| 检查项 | 通过条件 | 失败信号 |
|---|
| 数量 | 1 个 KR → 3-4 个 Project | < 3 → needs_revision；> 6 → needs_revision |
| 因果链 | 每个 Project 有具体"推动方式"说明 | "有助于提升"等空洞描述 |
| 覆盖度 | 所有 Project 加起来能推动指标 from→to | 做完这些明显不够达到目标值 |
| 命名具体 | 名称是可交付的功能模块 | "研究XXX"、"优化YYY"等模糊名称 |
| 验收标准 | 每个 Project 有可测试的验收条件 | 验收标准不可测试 |
| 战略对齐 | Project 方向与 KR 一致 | Project 和 KR 关联牵强 |
Project → Scope
| 检查项 | 通过条件 | 失败信号 |
|---|
| 数量 | 3-4 个 Scope（每个 2-3 天） | < 2 → rejected；> 6 → needs_revision |
| 功能边界 | 按用户可感知的功能边界分组 | 按技术分层（"前端"/"后端"/"数据库"） |
| 命名清晰 | 用交付物命名，如"用户能提交订单" | "处理逻辑"、"完善功能"等无内容词 |
| 覆盖度 | 所有 Scope 做完 → Project 验收条件全过 | 明显遗漏关键功能 |
| 独立性 | 各 Scope 之间低耦合 | 两个 Scope 强依赖、必须严格串行 |
| 时间粒度 | 每个 Scope 2-3 天可完成 | 某个 Scope 需要整周（应拆分） |
| type 字段 | 每个 child 的 type = 'scope' | type 为其他值 |
| 无层级跳跃 | children 中不存在 type='initiative' | 出现 type='initiative' 说明跳过了 Scope 层 |
Scope → Initiative
| 检查项 | 通过条件 | 失败信号 |
|---|
| 数量 | 3-7 个 Initiative | < 3 → needs_revision；> 10 → needs_revision |
| 内部串联依赖 | Initiative 内的 Task 有顺序依赖 | Task 之间无依赖关系 |
| Initiative 间可并行 | 不同 Initiative 之间可以并行执行 | Initiative 之间强串联依赖 |
| DoD 明确 | 每个 Initiative 有清晰完成定义 | DoD 是"做完XXX"这种无法验证的描述 |
| Test 字段 | 每个 DoD 条目有 test: 字段 | DoD 纯文字描述，无 test 字段 |
| 覆盖度 | 所有 Initiative 做完 → Scope 交付物实现 | 明显遗漏关键步骤 |
| 命名可执行 | 名称明确说明交付什么 | "处理"、"完善"、"优化"等无内容词 |
| 层级正确 | Initiative 下是 Task，不是另一个 Initiative | 层级错误（Initiative 嵌套） |
| type 字段正确 | 每个 child 的 type = 'initiative' | type 为其他错误值 |
| SPIDR 切割 | 使用了合理的切割维度（Spike/Path/Interface/Data/Rules） | 切割随意，无明确维度 |
Initiative → Task（Task 数量检查）
| 检查项 | 通过条件 | 失败信号 |
|---|
| Task 数量下限 | 每个 Initiative 至少 4 个 Task | < 4 → rejected |
| Task 数量上限 | 每个 Initiative 最多 8 个 Task | > 8 → needs_revision |
| Task 串联依赖 | Task 之间有明确的顺序依赖 | Task 之间完全独立无依赖 |
PR 数量校验（动态产能校准）
| 检查项 | 通过条件 | 失败信号 |
|---|
| Initiative PR 数量 | 在 layer_budgets.initiative.pr_count_per_slot 容差内 | 偏差超出容差 |
| Scope PR 总量 | 接近 layer_budgets.scope.pr_count_per_slot | 偏差超出容差 |
| Project PR 总量 | 接近 layer_budgets.project.pr_count_per_slot | 偏差超出容差 |
容差规则（基于 confidence）：
confidence: theoretical → ±50%；low → ±40%；medium → ±30%；high → ±20%- Brain 不可用时：跳过 PR 数量校验，仅做结构性检查
PR 数量失败处理：偏低/高超过容差 → needs_revision；极端偏离（>2x 或 <0.3x）→ rejected
裁决规则
approved ✅：所有检查项通过。
needs_revision ⚠️：1-2 个轻微问题（命名模糊、数量轻微不足、DoD 少量缺 test 字段）。秋米在原基础上修正。
rejected ❌（以下任一立即打回）：
- 因果链断裂 / KR 无数字 / 拆解与父层不相关
- 层级错误：Initiative 嵌套，或 Project 直接包含 Initiative 跳过 Scope
- 子项全是空洞名称，无法执行
- DoD 无 Test 字段（所有 DoD 都是纯文字）
- 层级跳跃（Project children 出现 type='initiative'）
- Initiative Task 不足（Task < 4）
- Scope 按技术分层（"前端/后端"而非功能边界）
- PR 数量极端偏离（>2x 或 <0.3x capacity-budget 预算）
质检输出格式（内部记录）
{
"verdict": "approved | needs_revision | rejected",
"score": 1-10,
"decomp_type": "project_to_scope",
"findings": {
"因果链": "对齐 / 断裂（原因）",
"覆盖度": "完整 / 遗漏（具体遗漏什么）",
"命名质量": "清晰 / 模糊（哪几个，为什么）",
"数量": "合理（N个）/ 过少 / 过多",
"功能边界": "正确（按功能分）/ 错误（按技术分层）",
"战略对齐": "对齐 / 偏离",
"PR 数量": "合理 / 偏低 / 偏高 / 跳过（Brain 不可用）"
},
"issues": ["具体问题1", "具体问题2"],
"summary": "一句话总结",
"next_action": "proceed | revise | redispatched_to_autumnrice"
}
数据库规范
INSERT INTO goals (title, type, description) VALUES ('...', 'kr', '...');
INSERT INTO projects (name, type, parent_id, description, decomposition_depth)
VALUES ('...', 'scope', '[project_id]', '...', 1);
INSERT INTO projects (name, type, parent_id, description, decomposition_depth)
VALUES ('...', 'initiative', '[scope_id]', '...', 2);
INSERT INTO tasks (title, task_type, project_id, description, priority, status, ability_id)
VALUES ('...', 'dev', '[initiative_id]', '[PRD]', 'P1', 'queued', NULL);
快速参考
docker exec cecelia-postgres psql cecelia -c "SELECT id, title FROM goals WHERE type IN ('kr','global_kr','area_kr');"
docker exec cecelia-postgres psql cecelia -c "
SELECT p.name, p.status,
COUNT(t.id) as task_count,
COUNT(t.id) FILTER (WHERE t.status='completed') as done
FROM projects p LEFT JOIN tasks t ON t.project_id=p.id
WHERE p.parent_id='[project_id]' AND p.type='initiative'
GROUP BY p.id, p.name, p.status ORDER BY p.created_at;
"
docker exec cecelia-postgres psql cecelia -c "
INSERT INTO tasks (title, task_type, project_id, description, priority, status)
VALUES ('规划下一个 Initiative', 'project_plan', '[project_id]',
'{\"project_id\":\"[project_id]\",\"reason\":\"manual_test\"}', 'P1', 'queued')
RETURNING id;
"
