28 lines
1.9 KiB
Markdown
28 lines
1.9 KiB
Markdown
我想调整一部分流程
|
||
|
||
在docs和finish中插入一个新流程，作为等待用户确认时的交互缓冲期，
|
||
|
||
在这个阶段停下向用户报告完成信息，用户可以在这个时候自行进行审阅和测试等行为，
|
||
|
||
如果确认无误则直接答复确认即可，进入finish，
|
||
|
||
但如果发现有些地方其实并没有按预期实现，或者是用户在已经实现的基础上发现了新的问题或是有了新的想法，则应进行分析，判断应该返工到哪个阶段，
|
||
|
||
为了避免收到上下文限制或意外中断影响便于恢复任务，一定要注意返工前先更新任务文档（是source不是spec）和任务计划（是指任务计划文档不是todo工具），
|
||
|
||
然后再逐个环节继续完成任务，直到用户确认进入finish，
|
||
|
||
对了，在这之前，我希望先更新command/run中关于任务计划部分的内容，
|
||
|
||
我原本期望的是：
|
||
```
|
||
对于任务的分析优化阶段，我希望能对任务的复杂度（是指工作量上的复杂度）进行分析，
|
||
- 对过于复杂的任务，梳理为多个完整的小任务，
|
||
- 出一个任务计划总导览和多个完整的子计划的细则，然后依序完成，
|
||
- 这类任务的执行过程，当完成task-optimize后，从flow-design到docs为一个完整子计划的全过程，多次循环逐个完成所有子计划的内容，一个子计划执行完docs后，开始下一个子计划的flow-design，最后全部完成后再finish
|
||
```
|
||
|
||
可现在的run只实现了分析优化阶段对复杂度的分析和任务拆分要求，提出了要分为小计划，后面还说明了对于小计划和导览更新怎么执行
|
||
|
||
而实际上我要求的是当任务较为复杂应该被分为小计划时，每一个小计划都必须是一个单独的完整的细则文档，而不是在同一个文档中的计划1计划2那样，且任务计划总导览也必须是一个单独的文档，
|