645a30c的任务收尾

This commit is contained in:
2025-12-18 13:58:35 +08:00
parent 645a30cace
commit e808201ec3
12 changed files with 843 additions and 125 deletions

View File

@@ -1,5 +1,5 @@
{
"next_number": 16,
"next_number": 17,
"branches": [
{
"number": 1,
@@ -174,6 +174,18 @@
"status": "finished",
"end_commit": "80ebbd4d85aaa8b3408cd83c35627c972057beda",
"finished_at": "2025-12-18T12:50:59+08:00"
},
{
"number": 16,
"branch_name": "aide/016",
"source_branch": "master",
"start_commit": "645a30cace5e7653c19c60fa1f23c22d1db73d34",
"task_id": "2025-12-18T13-29-05",
"task_summary": "开始任务准备: 构建 auto-run 全自动任务执行命令",
"started_at": "2025-12-18T13:29:05+08:00",
"status": "finished",
"end_commit": "645a30cace5e7653c19c60fa1f23c22d1db73d34",
"finished_at": "2025-12-18T13:58:35+08:00"
}
]
}

View File

@@ -1,5 +1,15 @@
# Git 分支概况
## aide/016
- **任务**: 开始任务准备: 构建 auto-run 全自动任务执行命令
- **任务ID**: 2025-12-18T13-29-05
- **源分支**: master
- **起始提交**: 645a30c
- **结束提交**: 645a30c
- **状态**: finished
- **时间**: 2025-12-18 13:29 ~ 13:58
## aide/015
- **任务**: 开始任务准备: 调整 Aide 工作流流程

Binary file not shown.

After

Width:  |  Height:  |  Size: 122 KiB

View File

@@ -0,0 +1,73 @@
@startuml auto-run-logic-flow
title auto-run 命令逻辑流图
|#LightBlue| 入口 |
start
:加载 aide skill;
:检查 flow 状态;
if (有活跃任务?) then (是)
:进入续接流程;
else (否)
:进入新任务流程;
endif
|#LightGreen| 新任务流程 |
:启动流程追踪;
:aide flow start task-optimize;
:读取任务文档;
:任务分析与优化;
if (有待定项?) then (是)
:分析各选项;
:自动选择 recommend 选项;
:记录决策理由;
else (否)
:继续;
endif
:生成任务细则;
note right: 无用户确认,直接继续
:aide flow next-part flow-design;
:创建流程图;
:aide flow next-part impl;
:迭代实现;
|#LightYellow| 错误处理 |
if (遇到错误?) then (是)
if (存在 general-purpose 子代理?) then (是)
:委托子代理解决;
else (否)
:记录遇到的情况;
:更新任务计划文档;
:自行解决问题;
endif
else (否)
:继续执行;
endif
|#LightGreen| 继续流程 |
:aide flow next-part verify;
:验证交付;
:aide flow next-part docs;
:文档更新;
note right
跳过 confirm 阶段
直接进入 finish
end note
:aide flow next-part finish;
:清理临时文件;
:汇报完成情况;
stop
@enduml

Binary file not shown.

After

Width:  |  Height:  |  Size: 47 KiB

View File

@@ -0,0 +1,44 @@
@startuml auto-run-task-flow
title auto-run 任务执行流程图
start
:复制 run.md 为 auto-run.md;
:修改命令标题和描述;
:改造待定项处理逻辑;
note right
- 移除用户 Web 决策
- 改为自动选择最优解
- 记录决策理由
end note
:删除任务细则确认;
note right
移除 AskUserQuestion 调用
end note
:删除 confirm 阶段;
note right
- 移除阶段 6 定义
- 调整流程跳转
- 移除返工流程
end note
:新增错误自动处理机制;
note right
优先委托子代理
否则自行解决
end note
:新增计划外情况处理机制;
note right
先记录 → 更新计划 → 再处理
end note
:验证命令文件;
stop
@enduml

View File

@@ -0,0 +1,115 @@
{
"task_id": "2025-12-18T13-29-05",
"current_phase": "finish",
"current_step": 13,
"started_at": "2025-12-18T13:29:05+08:00",
"history": [
{
"timestamp": "2025-12-18T13:29:05+08:00",
"action": "start",
"phase": "task-optimize",
"step": 1,
"summary": "开始任务准备: 构建 auto-run 全自动任务执行命令",
"git_commit": "26c735ed294c7a6a4790dce190129baa7a6048bc"
},
{
"timestamp": "2025-12-18T13:31:10+08:00",
"action": "next-step",
"phase": "task-optimize",
"step": 2,
"summary": "任务解析完成",
"git_commit": "4748a0a7a92746600c69bbe57c32d04d75fbef3c"
},
{
"timestamp": "2025-12-18T13:34:59+08:00",
"action": "next-step",
"phase": "task-optimize",
"step": 3,
"summary": "任务细则已确认",
"git_commit": "a10d9de196ef4ee2b61fa180ec5605c195803c3d"
},
{
"timestamp": "2025-12-18T13:35:18+08:00",
"action": "next-part",
"phase": "flow-design",
"step": 4,
"summary": "进入流程设计环节",
"git_commit": "f0909c5124d8bb3e81dcaac876ab8ff40b6fe7ca"
},
{
"timestamp": "2025-12-18T13:36:15+08:00",
"action": "next-step",
"phase": "flow-design",
"step": 5,
"summary": "流程图设计完成",
"git_commit": "5c1ada7991903f9394460fa8eedfcd7b1a320ee8"
},
{
"timestamp": "2025-12-18T13:36:35+08:00",
"action": "next-part",
"phase": "impl",
"step": 6,
"summary": "流程设计完成,进入实现环节",
"git_commit": "7a748544773259a10759da7578d96bc6aefdef23"
},
{
"timestamp": "2025-12-18T13:50:07+08:00",
"action": "next-step",
"phase": "impl",
"step": 7,
"summary": "auto-run.md 实现完成",
"git_commit": "a2531526536ee3b47a68fb8aea245180477f5bee"
},
{
"timestamp": "2025-12-18T13:50:21+08:00",
"action": "next-part",
"phase": "verify",
"step": 8,
"summary": "实现完成,进入验证环节",
"git_commit": "5fa9b25d78bf10e58faa14be122e32b9835572c9"
},
{
"timestamp": "2025-12-18T13:51:18+08:00",
"action": "next-step",
"phase": "verify",
"step": 9,
"summary": "验证完成: 所有验证标准通过",
"git_commit": "3fd58acbd07ae284b96eb0791aad74933bf5da2f"
},
{
"timestamp": "2025-12-18T13:51:30+08:00",
"action": "next-part",
"phase": "docs",
"step": 10,
"summary": "验证通过,进入文档环节",
"git_commit": "ffa5ba5d4e553f5ddda9d8e305b92a02c0084b9a"
},
{
"timestamp": "2025-12-18T13:52:42+08:00",
"action": "next-step",
"phase": "docs",
"step": 11,
"summary": "文档更新完成",
"git_commit": "ec847df46943eb3d89754c48380b53766b0b2da9"
},
{
"timestamp": "2025-12-18T13:52:57+08:00",
"action": "next-part",
"phase": "confirm",
"step": 12,
"summary": "文档更新完成,进入用户确认环节",
"git_commit": "360628db5766ec02d7df654eebcdb4451503f128"
},
{
"timestamp": "2025-12-18T13:58:35+08:00",
"action": "next-part",
"phase": "finish",
"step": 13,
"summary": "用户确认通过,进入收尾",
"git_commit": "e9e12a672e67b7630762a5d95588abed8cd338d3"
}
],
"source_branch": "master",
"start_commit": "645a30cace5e7653c19c60fa1f23c22d1db73d34",
"task_branch": "aide/016"
}

View File

@@ -1,108 +0,0 @@
{
"task": "调整 Aide 工作流流程",
"source": "task-now.md",
"items": [
{
"id": 1,
"title": "新阶段命名",
"location": {
"file": "task-now.md",
"start": 3,
"end": 9
},
"context": "需要在 docs 和 finish 之间插入一个用户确认阶段。当前 flow phases 为: task-optimize, flow-design, impl, verify, docs, finish。新阶段需要一个简洁且语义明确的英文名称。",
"options": [
{
"value": "review",
"label": "review",
"score": 90,
"pros": ["语义清晰,表示审阅", "简洁常用"],
"cons": ["与 code review 可能混淆"]
},
{
"value": "confirm",
"label": "confirm",
"score": 85,
"pros": ["明确表示确认动作", "与任务流程含义一致"],
"cons": ["较长"]
},
{
"value": "approve",
"label": "approve",
"score": 75,
"pros": ["表示批准/通过", "正式感强"],
"cons": ["较正式,可能过于严肃"]
}
],
"recommend": "review"
},
{
"id": 2,
"title": "复杂任务文档存储位置",
"location": {
"file": "task-now.md",
"start": 27,
"end": 28
},
"context": "复杂任务需要生成任务计划总导览和多个子计划细则,每个都是独立文档。需要确定这些文档的存储位置。",
"options": [
{
"value": "aide_dir",
"label": ".aide/task-plans/",
"score": 90,
"pros": ["与现有 .aide/ 结构一致", "集中管理", "自动被 gitignore"],
"cons": ["路径较深"]
},
{
"value": "root_dir",
"label": "项目根目录",
"score": 60,
"pros": ["访问方便"],
"cons": ["污染根目录", "需要手动 gitignore"]
},
{
"value": "spec_alongside",
"label": "与 task.spec 同目录",
"score": 75,
"pros": ["与现有细则位置一致"],
"cons": ["需要额外的命名规范"]
}
],
"recommend": "aide_dir"
},
{
"id": 3,
"title": "子计划文档命名规范",
"location": {
"file": "task-now.md",
"start": 27,
"end": 28
},
"context": "每个子计划需要独立的细则文档,需要确定命名规范以便识别和管理。",
"options": [
{
"value": "numbered",
"label": "数字编号: spec-01.md, spec-02.md",
"score": 85,
"pros": ["简洁", "顺序清晰"],
"cons": ["无语义信息"]
},
{
"value": "named",
"label": "语义命名: spec-login.md, spec-payment.md",
"score": 80,
"pros": ["语义清晰", "易于识别"],
"cons": ["命名需要额外考虑", "可能重名"]
},
{
"value": "hybrid",
"label": "混合: spec-01-login.md, spec-02-payment.md",
"score": 90,
"pros": ["兼顾顺序和语义", "易于排序和识别"],
"cons": ["命名较长"]
}
],
"recommend": "hybrid"
}
]
}

View File

@@ -6,6 +6,20 @@
### 新增功能
**全自动任务执行命令 `/aide:auto-run`**
- 基于 `/aide:run` 的全自动化版本
- 去除所有用户交互环节:
- 待定项自动决策(选择 recommend 或最高分选项)
- 任务细则自动确认(无需用户确认)
- 跳过 confirm 阶段docs → finish
- 新增错误自动处理机制:
- 优先委托 `general-purpose` 子代理解决
- 无子代理时自行解决(需先记录并更新计划)
- 新增计划外情况处理机制:
- 必须先记录遇到的情况
- 更新任务计划文档后才能继续
- 适用场景:批量处理、后台执行、无需人工干预的任务
**用户确认阶段 (confirm)**
- 在 docs 和 finish 之间新增 `confirm` 阶段
- 用于用户审阅和测试已完成的工作

View File

@@ -1,9 +1,9 @@
{
"name": "aide-plugin",
"description": "Aide 工作流体系插件,提供环境配置、项目认知、文档管理和任务执行的标准化流程",
"version": "2.0.9",
"description": "Aide 工作流体系插件,提供环境配置、项目认知、文档管理和任务执行(含全自动模式)的标准化流程",
"version": "2.1.0",
"author": {
"name": "Aide Team"
},
"keywords": ["workflow", "task", "aide", "productivity", "documentation"]
"keywords": ["workflow", "task", "aide", "productivity", "documentation", "automation"]
}

View File

@@ -0,0 +1,571 @@
# Aide 全自动任务执行
你正在执行 Aide **全自动**任务执行流程。这是 `/aide:run` 的自动化版本,去除了所有需要用户参与的环节,适用于批量处理或后台执行场景。
**与 `/aide:run` 的主要区别**
- 待定项自动决策(无需用户 Web 确认)
- 任务细则自动确认(无需用户确认)
- 跳过 confirm 阶段(无需用户验收)
- 错误自动处理(优先委托子代理,否则自行解决)
## 参数
- `$ARGUMENTS`:任务文档路径(可选)
- 未传入时根据 flow 状态决定行为
---
## 前置准备
**首先触发 `aide` skill 学习 aide 命令的使用方法。**
这是一个非常长的任务,因此规划您的工作可能会很有益。**建议花费您的整个输出上下文来处理任务 - 只需确保您不会在有大量未提交的工作时用尽上下文。**继续系统地工作,直到您完成此任务。**您的上下文窗口将在接近其限制时自动压缩,允许您从中断的地方继续无限期地工作。因此,不要因为令牌预算问题而提前停止任务。**当您接近令牌预算限制时,在上下文窗口刷新前将您当前的进度和状态保存到内存中。始终尽可能坚持和自主,并完全完成任务,即使您的预算即将用尽。无论剩余上下文如何,永远不要人为地提前停止任何任务。
---
## 开始
### 检查 flow 状态
```bash
aide flow status
```
根据状态决定行为:
- **无活跃任务** 或 **当前任务已 finish** → 进入**新任务流程**
- **当前任务未完成** → 进入**续接流程**
---
## 新任务流程
### 阶段 1任务准备 (task-optimize)
#### 1.1 启动流程追踪
```bash
aide flow start task-optimize "开始任务准备: <任务简述>"
```
#### 1.2 确定任务文档
```bash
# 如果传入了参数
任务文档 = $ARGUMENTS
# 如果未传入参数,使用配置默认值
aide config get task.source
```
读取任务文档内容。如文档不存在,**报错退出**(全自动模式不支持交互式输入)。
#### 1.3 口语化内容检测
检查任务文档或用户对话是否具有以下口语化特征:
- 使用非正式的口头表达方式
- 包含大量模糊表述("我觉得"、"好像"、"大概"、"应该"等)
- 句子结构松散,缺乏条理性
- 包含冗余或重复的表达
- 思维跳跃,逻辑不连贯
**如果检测到口语化特征**
1. 触发 `task-parser` skill 学习口语化内容解析方法
2. 按照 skill 指南对内容进行深度理解和规范化转换
3. 将转换后的结构化内容作为后续分析的基础
> 即使内容部分口语化,也应进行解析,提取核心意图
#### 1.4 任务分析
##### 深度理解任务
- 任务要解决什么问题?
- 最终交付物是什么?
- 成功的标准是什么?
- 涉及哪些模块/系统?
- 是否有技术难点?
##### 分析项目环境
根据需要阅读相关代码/文档,理解任务与项目现有结构的关系。
> 复杂任务(多子目标、多方案对比)建议使用 sequential-thinking 进行结构化分析
#### 1.5 复杂度评估
根据**任务复杂度评估指导原则**(见附录)评估任务复杂度:
- **简单/中等任务**:直接生成任务细则
- **复杂/超大任务**:拆分为多个子计划
#### 1.6 任务优化
##### 准确性优化
- 识别**歧义**和**不明确之处**
- 识别**隐含假设**和**未说明的前提**
- 明确任务**边界**
##### 简洁性优化
- 识别**冗余表述**
- 区分**真冗余**与**必要强调**
##### 可执行性优化
- 将抽象要求转化为**具体步骤**
- 确保每个步骤有明确的**输入、输出、验证标准**
- 识别可能的**替代方案**
##### 生成待定项
对于存在多种方案、有歧义、需要用户确认的内容,准备待定项数据。
#### 1.7 待定项自动处理
**必须执行**,无论是否有待定项:
1. **如果有待定项**
- 分析各待定项的选项
- 对于每个待定项:
- 如果有 `recommend` 字段,选择推荐选项
- 如果无推荐,根据 `score` 字段选择最高分选项
- 如果无评分,选择第一个选项
- 记录决策理由到 flow 日志:
```bash
aide flow next-step "自动决策: <决策摘要>"
```
2. **如果无待定项**
- 继续下一步(无需向用户报告)
#### 1.8 生成任务细则
**必须执行**
##### 简单/中等任务
1. 根据分析结果生成任务细则文档
2. 保存到配置的路径:
```bash
aide config get task.spec
```
##### 复杂任务(需拆分为子计划)
1. 获取计划文档目录:
```bash
aide config get task.plans_path
```
2. 创建目录(如不存在)
3. 生成以下文档:
**任务计划总导览guide.md**
```markdown
# 任务计划总导览
## 任务简述
[一句话描述任务目标]
## 子计划列表
| # | 名称 | 状态 | 细则文档 |
|---|------|------|----------|
| 1 | [子计划1名称] | pending | spec-01.md |
| 2 | [子计划2名称] | pending | spec-02.md |
...
## 执行顺序
[说明子计划之间的依赖关系和执行顺序]
## 备注
[其他需要说明的内容]
```
**各子计划细则spec-01.md, spec-02.md, ...**
```markdown
# 子计划 N[名称]
## 目标
[具体目标]
## 具体步骤
1. [步骤1]
2. [步骤2]
...
## 验证标准
- [标准1]
- [标准2]
## 依赖
- 前置:[依赖的子计划,如无则写"无"]
- 后续:[依赖本计划的子计划,如无则写"无"]
```
##### 自动确认
全自动模式下,生成任务细则后直接进入下一阶段:
```bash
aide flow next-step "任务细则已生成,自动确认"
```
### 阶段 2流程设计 (flow-design)
```bash
aide flow next-part flow-design "进入流程设计环节"
```
#### 2.1 制定执行计划
- 具体的实现步骤
- 每个步骤的预期产出
- 潜在风险和应对方案
#### 2.2 创建流程图
在配置的流程图目录创建 PlantUML 源文件:
```bash
aide config get flow.diagram_path
```
##### 流程图类型
根据任务类型,需要创建不同类型的流程图:
| 类型 | 适用场景 | 必需性 |
|------|----------|--------|
| 任务执行流程图 | 所有任务 | **必需** |
| 程序逻辑流图 | 含程序设计与代码编写的任务 | **必需** |
##### 任务执行流程图规范
展示任务执行的步骤顺序:
- **步骤分解**:将任务分解为具体的执行步骤
- **顺序关系**:明确步骤之间的先后顺序
- **决策点**:标注关键决策点和分支条件
- **依赖关系**:体现步骤之间的依赖
##### 程序逻辑流图规范
展示程序代码的执行逻辑(仅限程序类任务):
- **入口点**:从程序入口函数(如 main、\_\_main\_\_开始
- **控制结构**体现顺序、分支if/switch、循环for/while结构
- **语义化抽象**:将代码逻辑抽象为人类可理解的业务描述,而非代码细节
- **模块化表示**
- 函数/模块表示为"盒子"
- 标注预期输入和输出
- 复杂函数可单独绘制详图
- **层次化组织**
- 主流程图展示程序整体执行流
- 关键子系统/模块可单独绘制详细流程图
- 通过引用关联主图与详图
> **为什么需要程序逻辑流图**
> - 用户可以通过流程图快速理解程序的执行逻辑
> - 在流程图阶段发现业务逻辑错误,避免实现后才发现方向错误
> - 比逐行审阅代码更高效
##### 流程图示例结构
```plantuml
@startuml
' 主程序流程图
start
:初始化配置;
:解析命令行参数;
if (参数有效?) then (是)
:调用处理模块;
note right: 详见 process-module.puml
else (否)
:显示错误信息;
stop
endif
:输出结果;
stop
@enduml
```
**所有任务必须有流程图**,用于:
- 规范化思考
- 方便用户审阅
- 早期发现逻辑错误
```bash
aide flow next-step "流程图设计完成"
```
#### 2.3 进入实现环节
```bash
aide flow next-part impl "流程设计完成,进入实现环节"
```
> aide flow 会自动校验 PlantUML 并生成 PNG
### 阶段 3迭代实现 (impl)
按计划执行,每完成一个步骤:
```bash
aide flow next-step "<完成内容简述>"
```
遇到问题时:
```bash
aide flow issue "<一般问题>"
aide flow error "<严重错误>"
```
#### 错误自动处理
全自动模式下,遇到错误时按以下流程处理:
1. **记录错误**
```bash
aide flow error "<错误描述>"
```
2. **尝试自动解决**
- **优先委托子代理**:如果存在 `general-purpose` 子代理,使用 Task 工具委托其解决
- **自行解决**:如果无子代理可用,则自行解决
3. **自行解决前的必要操作**(见下文「计划外情况处理」)
需要回退时:
```bash
aide flow back-step "<原因>"
aide flow back-part <环节名> "<原因>"
```
#### 计划外情况处理
当遇到以下情况时:
- 只能自行解决的问题(无子代理可用)
- 可能大幅消耗上下文的计划外情况
- 需要重大决策但无法委托的情况
**必须执行以下操作后才能继续**
1. **记录遇到的情况**
```bash
aide flow issue "<情况描述>"
```
2. **更新任务计划文档**
- 简单任务:更新 `task.spec`
- 复杂任务:更新相应的子计划文档(`spec-NN.md`
- 新增「计划外处理」章节,说明:
- 遇到的情况
- 选择的处理方案
- 预期影响
3. **记录更新完成**
```bash
aide flow next-step "计划外情况已记录,继续执行"
```
4. **执行处理方案**
> 这一机制确保即使上下文中断,也能通过文档恢复状态
### 阶段 4验证交付 (verify)
```bash
aide flow next-part verify "实现完成,进入验证环节"
```
- 对照任务细则验证每个成功标准
- 执行测试(如适用)
- 验证失败则回退修复
```bash
aide flow next-step "验证完成: <验证结论>"
```
### 阶段 5文档更新 (docs)
```bash
aide flow next-part docs "验证通过,进入文档环节"
```
更新相关文档:
- `README.md`(如有用户可见变更)
- `CHANGELOG.md`
- 其他相关文档
```bash
aide flow next-step "文档更新完成"
```
### 阶段 6收尾 (finish)
> 全自动模式跳过用户确认阶段,从文档更新直接进入收尾
```bash
aide flow next-part finish "文档更新完成,进入收尾"
```
- 清理临时文件
- 检查遗漏的 TODO
- 输出完成摘要
```bash
aide flow next-step "任务完成"
```
---
## 续接流程
当检测到未完成的任务时:
### 1. 智能续接判断
1. **检查任务细则文档是否存在**
```bash
aide config get task.spec
```
读取配置的细则文档路径。
2. **如果细则文档不存在**
- 旧状态已无效
- **报错退出**:「检测到未完成的任务,但任务细则不存在。全自动模式无法继续。」
3. **如果细则文档存在**
- 阅读细则文档内容
- 判断上次未完成任务的名称和步骤是否符合细则含义
- **符合** → 接续之前的状态继续执行
- **不符合** → 旧状态已无效,需要 start 新任务
4. **如果判断为应继续,但 git 状态不干净**
- aide flow 会自动执行 git add . 并创建清理提交
- 这是预期行为,无需手动处理
### 2. 分析当前进度
```bash
aide flow status
aide flow show <task_id>
```
了解:
- 当前处于哪个环节
- 已完成哪些步骤
- 最后的操作是什么
### 2. 载入项目认知
调用 `/aide:load` 的逻辑,按需载入项目文档。
### 3. 读取任务细则
```bash
aide config get task.spec
```
读取任务细则,了解任务目标和计划。
### 4. 继续执行
根据当前环节,从中断处继续执行。
---
## 复杂任务的子计划执行
对于拆分为多个子计划的复杂任务:
### 文档结构
复杂任务的文档存放在 `task.plans_path` 配置的目录下(默认 `.aide/task-plans/`
```
.aide/task-plans/
├── guide.md # 任务计划总导览
├── spec-01.md # 子计划 1 细则
├── spec-02.md # 子计划 2 细则
└── spec-NN.md # 子计划 N 细则
```
### 执行模式
```
task-optimize → [flow-design → impl → verify → docs] × N → finish
```
> 全自动模式:跳过 confirm 阶段,每个子计划完成 docs 后直接进入下一个子计划
### 流程
1. 完成 task-optimize
- 生成 `guide.md`(任务计划总导览)
- 生成所有 `spec-NN.md`(子计划细则)
2. 对每个子计划:
- 进入 flow-design为该子计划设计流程图
- 进入 impl实现该子计划
- 进入 verify验证该子计划
- 进入 docs更新该子计划相关文档
- 更新 `guide.md` 中该子计划状态为 `completed`
3. 所有子计划完成后,进入 finish
### 子计划切换
完成一个子计划的 docs 后:
```bash
aide flow next-step "子计划 N 完成,开始子计划 N+1"
aide flow back-part flow-design "开始下一个子计划的流程设计"
```
### 子计划状态管理
每完成一个子计划,更新 `guide.md` 中的状态表:
| # | 名称 | 状态 | 细则文档 |
|---|------|------|----------|
| 1 | [子计划1名称] | **completed** | spec-01.md |
| 2 | [子计划2名称] | **in_progress** | spec-02.md |
| 3 | [子计划3名称] | pending | spec-03.md |
---
## 附录:任务复杂度评估指导原则
### 评估维度
1. **结构维度**:模块数量、文件数量、依赖关系
2. **逻辑维度**:业务复杂度、状态管理、边界条件
3. **集成维度**:外部依赖、数据格式、兼容性
4. **风险维度**:技术风险、影响范围、回滚难度
### 复杂度等级
| 等级 | 特征 | 处理方式 |
|------|------|----------|
| 简单 | 单文件或少量文件,逻辑清晰 | 直接执行 |
| 中等 | 2-4 个模块,有一定依赖 | 直接执行,注意顺序 |
| 复杂 | 5+ 模块,复杂依赖 | **拆分为子计划** |
| 超大 | 10+ 模块,全面重构 | 拆分为独立任务 |
### 拆分判断标准
满足以下任一条件时应拆分:
1. 涉及 3 个以上独立功能模块
2. 任务自然分为多个可独立交付的阶段
3. 存在高风险环节,需要阶段性验证
4. 存在明确的前后依赖关系
5. 单次对话可能无法完成

View File

@@ -1,13 +0,0 @@
我想基于当前command/run的基础构建一个auto-run命令用于全自动处理流程
把run中所有原本需要用户参与的过程全都优化其规则去除掉需要用户参与的部分
其中主要的几项,
比如decide这样原本跟用户强相关的部分改为自行取综合考虑下的最优解
而优化结果确认和finishi前的确认可以直接删掉
然后还有一些情况是原本出错了需要用户处理的改为交给通用子代理general-purpose来解决如果不存在此子代理则自行解决
但注意,如果只能自行解决问题的话,还有其他所有可能上下文大幅度消耗的计划外情况出现时,都必须首先完成对遇到的情况的记录,同时讲处理方案编排到任务计划文档中,才能继续处理