[aide] task-optimize: 开始任务准备: Aide 工具 Git 分支管理和任务细则强制确认功能

task-now.md

@@ -1,26 +1,34 @@
 对当前的commands&skills&aide做一些调整，记得完成调整后同步更新所有相关文档
 
-我曾经提过一个想法，我把它的其中一部分节选出来保存在了 @statements/old-task-section.md ，
+我想为run添加一些步骤规定，同时更新aide配合实现目标，对一些可程序化的行为进行封装
 
-这个cmd-3现在已经被正式命名为`docs`了，且已被实现，但是我在实际使用时它好像没有按我原本预期的效果进行，
+我的想法如下：
 
 ---
 
-我期望的是它要完全的深度的探索所有文件，每一个文件，每一个目录，不需要考虑是否过度设计、是否开销过大、是否效率过低等问题，
+1.
 
-一定要完全的深度的对整个目录下所有文件、目录及其子目录下所有文件，除了匹配.gitignore中设置的忽略规则的文件，
-每一个文件都要完全的阅读，从头到尾，不允许遗漏任何一行，进行分析后对其文件内容、意义等做出概况，而二进制数据文件则根据其文件名、大小和根据其他文件内容跟它的关联信息进行上下文推断做出概括，
+创建和维护一份用于记录git分支概况的文档，
+当start一个新任务时，检查git状态是否干净，若有未跟踪未暂存的文件状态，使用git add .跟踪和暂存所有这些所有文件，然后创建一个提交保存状态版本，然后记录下这个提交的哈希，
+如果已经是干净的状态了则无需新建提交，直接记录下目前最新的提交的哈希，
+如果当前是空状态还没有任何提交，则（如果不在仓库没有被git管理就git init初始化一个仓库）创建一个空的.gitkeep文件然后创建一个初始化提交，记录下这个提交的哈希
+然后从当前记录的提交，创建一个新的分支，并将分支名和该起始提交哈希还有从哪个分支创建出来的都记录到文档，
+后续所有的流程变动与集成的git操作都是在这个分支上进行的，
+最后finish之后，把finish时的哈希记录到那个文档中，作为结束提交哈希，
+然后此时因为要记录下最后的结束哈希，flow的状态数据和那个文档都会有更新，把这些都git add .然后创建一个提交，此时仓库状态是干净的了，
+从这个提交合并到原本的分支去，回到原来的分支后，使用git reset --soft 软重置到起始提交，
+然后再git add . ，再根据那个分支所执行的任务名生成提交信息，创建一个新提交，
+这样在原本的分支可以只留下极少的提交，同时又能切换到任务分支查看变更的细节，（提交主要是便于回溯，实际上如果问题最终解决了，即使过程中出了点问题，最后解决了，任务完成后可能也不会回去看了，我希望我的git记录能干净些，而且就算有查看细节的需求，也可以通过查那份维护的文档切换到目标分支去看步骤细节）
 
-最终产出整个项目目录下完整的全部文件目录的导览，从脉络到枝叶，从导览到区块，
-
-其中对于被忽略的文件，仅保留文件名或目录名，不需要任何分析，标注ignored，
+我希望可以尽可能少的改动commands&skills，把这些全部封装到aide flow中，可能都不需要改commands，只要在skill中更新一部分信息让LLM简单了解到aide flow会发生这些副作用即可，
+这样的封装能实现吗？
 
 ---
 
-你可以检查一下当前项目的aide-plugin中已实现的docs.md，再对比一下.aide/project-docs中的由LLM根据docs.md的要求执行产出的项目文档，
+2.
 
-为什么这个项目文档中没有看到docs这个目录的导览信息，整个project-docs读完都对它们完全没有感知，
+我发现command/run中对细则信息的创建相关的规范比较简陋，只是简单提及了，
 
-原因是什么，单纯是docs.md没有按预期行为准确的给出提示词？还是我之前的想法没有描述到位？还是什么其他原因？
+实际上我希望的是完成分析优化和待定项处理后是必须生成和保存结果的，也就是任务细则文档，
 
-应该怎么解决这个问题，来让commands/docs实现预期效果
+还有，待定项处理和产出结果保存细则文档这两步，都是必须用户确认后才能继续工作的，不论是否顺利，任务是否简单，都必须由用户确认才能继续