项目任务流程

项目任务流程

本技能是流程指引，不是逐条打勾清单：按场景判断使用，遇不适用情况保持裁量，不机械执行。

适用场景

L1 组织和管理项目任务链（一个 app、一个游戏、一部网络小说等复杂长期任务）时加载本 skill。项目 = 真实文件夹 + 登记（projects 域），不是任务实体。

一、项目挂靠流程

1. 澄清需求
2. 确认项目：项目由用户在界面创建（新建任务表单选"挂靠项目"）或已存在——L1 向用户确认项目 ID 后，后续任务提交都传 project_id=项目ID（子任务系统自动继承，无需显式传）
3. 设置进度触发器：使用 trigger_setup 设置定时触发器（详见下文）
4. 方案规划（计划模式，自执行）：加载 plugins/shared/modes/mode_planning/rules/plan_workflow.md（mode=planning 键在场时已随模式段注入），严格按其口径执行；方案经用户明确确认后，用 project_state（action=transition, target_state=running, reason=定稿说明）申请过门（弹用户审批；状态闸细节见该口径与 task_submit 工具描述）
5. 执行任务链（过门后立即执行，无需询问用户）：
   • 直接传递方案路径：不要自己读任务链再转述给下级，下级比你更专业，它自己会读。goal 中写明方案文档路径（如 docs/{title}_solution.md），让下级自行读取任务链并执行
   • 用 file_read(fields=["task_chain"]) 只读取任务链中的执行者列表，用于检查所需 Agent 是否已存在
   • 缺失资源 → 触发资源准备流程创建
   • 等待资源就绪后，将方案路径提交给对应执行者
6. 项目任务链收尾：任务链全部完成（含最后的端到端验证任务）后通知用户
   • 取消触发器：任务链完成后立即使用 trigger_setup(action="cancel", trigger_id="之前记录的ID") 取消进度触发器
   • 项目的暂停/恢复/删除由用户在界面管理（projects 域），L1 不代操作

二、workspace 决策

场景	workspace 填法
挂靠项目（project_id）	不填——系统恒解析为项目文件夹（worktree 从项目仓库分叉）
独立任务 + 用户明确指定某个目录	填该目标目录
⚠️ 系统内部路径（.ai_workspaces 等）	禁止填写，只用于资源管理任务

三、进度触发器配置

使用 trigger_setup 设置定时触发器，定期检查项目任务执行进度。

配置项	值
触发间隔	15 分钟
最大触发次数	小型 32 次（约 8 小时）、中型 96 次（约 24 小时）、大型 288 次（约 3 天）
触发动作	检查项目任务当前状态，对照速查表验证产出物是否已生成
共用触发器	已有相同间隔的活跃触发器时不要新建，用 update 延长其生命周期
超时处理	触发次数耗尽后任务链仍未完成 → 延长次数并通知用户
记录 trigger_id	任务链完成时用于取消

停滞检测：子任务运行超 1 小时时查看详细进度，下次触发对比是否有变化。有变化继续等，无变化按优先级处理：①注入提示引导恢复 ②分析错误尝试修复 ③多次无效再通知用户。

四、方案不可变原则与修订分级

方案准备阶段人类确认的方案稿是任务执行的绝对标准，确认后不可更改。 「可不可改」的判据 = traces_to 追溯链（任务级 AC 是否仍可完整追溯到现行方案级 AC）：

• 执行层修正（traces_to 不断链）：失败任务重派、任务内执行方案调整、 实现细节/性能优化/不改接口契约的重构——running 内直接做，改动记入方案总纲 「变更记录」并通知用户；
• 方案层修订（traces_to 断链：方案级 AC 增删改、功能范围、技术选型、架构 模式级变更）：running 态禁止边跑边改方案文档，只许用 project_state （action=transition, target_state=plan，reason 附改动点+断链影响面+在途任务 清单）申请回门（反向审批，可选在途处理：跑完冻结派发/立即停）；回 plan 态 按 plan_workflow 修订后经同一道门再审恢复 running；
• 细化细节可调整：方案细化的粒度、实现步骤等细节可以在不违背方案核心的 前提下调整（属执行层修正）；
• 追溯完整性由 task-chain-viewer 检查兜底：任务级 AC 对账方案级 AC，断链在 任务链可视化中可见。