[aide] 修复: aide flow finish 后工作目录不干净的问题
- 在 _merge_normal 方法中添加收尾提交 - record_branch_finish 更新 branches.json/md 后创建提交 - 确保 finish 完成后 git 仓库状态干净
This commit is contained in:
@@ -77,7 +77,9 @@
|
|||||||
"task_id": "2025-12-17T06-07-01",
|
"task_id": "2025-12-17T06-07-01",
|
||||||
"task_summary": "测试",
|
"task_summary": "测试",
|
||||||
"started_at": "2025-12-17T06:07:01+08:00",
|
"started_at": "2025-12-17T06:07:01+08:00",
|
||||||
"status": "active"
|
"status": "finished",
|
||||||
|
"end_commit": "346ec90386190363cb71651e6bff3c64bb6b86f9",
|
||||||
|
"finished_at": "2025-12-17T06:07:50+08:00"
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -6,8 +6,9 @@
|
|||||||
- **任务ID**: 2025-12-17T06-07-01
|
- **任务ID**: 2025-12-17T06-07-01
|
||||||
- **源分支**: master
|
- **源分支**: master
|
||||||
- **起始提交**: 8d4cae6
|
- **起始提交**: 8d4cae6
|
||||||
- **状态**: active
|
- **结束提交**: 346ec90
|
||||||
- **时间**: 2025-12-17 06:07
|
- **状态**: finished
|
||||||
|
- **时间**: 2025-12-17 06:07 ~ 06:07
|
||||||
|
|
||||||
## aide/006
|
## aide/006
|
||||||
|
|
||||||
|
|||||||
@@ -1 +0,0 @@
|
|||||||
43517
|
|
||||||
@@ -332,17 +332,21 @@ class BranchManager:
|
|||||||
# squash 合并任务分支
|
# squash 合并任务分支
|
||||||
self.git.merge_squash(task_branch)
|
self.git.merge_squash(task_branch)
|
||||||
|
|
||||||
# 创建压缩提交
|
# 创建压缩提交(结束提交)
|
||||||
self.git.add_all()
|
self.git.add_all()
|
||||||
commit_msg = f"[aide] 任务: {task_summary}"
|
commit_msg = f"[aide] 任务: {task_summary}"
|
||||||
end_commit = self.git.commit(commit_msg)
|
end_commit = self.git.commit(commit_msg)
|
||||||
|
|
||||||
# 记录完成
|
# 记录完成(更新 branches.json/md)
|
||||||
self.record_branch_finish(
|
self.record_branch_finish(
|
||||||
status="finished",
|
status="finished",
|
||||||
end_commit=end_commit,
|
end_commit=end_commit,
|
||||||
)
|
)
|
||||||
|
|
||||||
|
# 收尾提交:清理工作区(包含 branches.json/md 的更新)
|
||||||
|
self.git.add_all()
|
||||||
|
self.git.commit("[aide] 收尾: 更新分支记录")
|
||||||
|
|
||||||
return True, f"任务分支已合并到 {source_branch}"
|
return True, f"任务分支已合并到 {source_branch}"
|
||||||
|
|
||||||
def _merge_with_temp_branch(
|
def _merge_with_temp_branch(
|
||||||
|
|||||||
@@ -1,41 +1,14 @@
|
|||||||
# 想法
|
创建和维护一份用于记录git分支概况的文档,
|
||||||
|
当start一个新任务时,检查git状态是否干净,若有未跟踪未暂存的文件状态,使用git add .跟踪和暂存所有这些所有文件,然后创建一个提交保存状态版本,然后记录下这个提交的哈希,
|
||||||
|
如果已经是干净的状态了则无需新建提交,直接记录下目前最新的提交的哈希,
|
||||||
|
如果当前是空状态还没有任何提交,则(如果不在仓库没有被git管理就git init初始化一个仓库)创建一个空的.gitkeep文件然后创建一个初始化提交,记录下这个提交的哈希
|
||||||
|
然后从当前记录的提交,创建一个新的分支,并将分支名和该起始提交哈希还有从哪个分支创建出来的都记录到文档,
|
||||||
|
后续所有的流程变动与集成的git操作都是在这个分支上进行的,
|
||||||
|
最后finish之后,把finish时的哈希记录到那个文档中,作为结束提交哈希,
|
||||||
|
然后此时因为要记录下最后的结束哈希,flow的状态数据和那个文档都会有更新,把这些都git add .然后创建一个提交,此时仓库状态是干净的了,
|
||||||
|
从这个提交合并到原本的分支去,回到原来的分支后,使用git reset --soft 软重置到起始提交,
|
||||||
|
然后再git add . ,再根据那个分支所执行的任务名生成提交信息,创建一个新提交,
|
||||||
|
这样在原本的分支可以只留下极少的提交,同时又能切换到任务分支查看变更的细节,(提交主要是便于回溯,实际上如果问题最终解决了,即使过程中出了点问题,最后解决了,任务完成后可能也不会回去看了,我希望我的git记录能干净些,而且就算有查看细节的需求,也可以通过查那份维护的文档切换到目标分支去看步骤细节)
|
||||||
|
|
||||||
创建一个新的command(暂时称为cmd-3),专门用于处理为项目创建和维护文档(这一command将会是“独立运行”的):
|
我希望可以尽可能少的改动commands&skills,把这些全部封装到aide flow中,可能都不需要改commands,只要在skill中更新一部分信息让LLM简单了解到aide flow会发生这些副作用即可,
|
||||||
- 在环境配置中建立一条用于记录项目文档目录路径的数据
|
这样的封装能实现吗?
|
||||||
- 如果项目文档目录路径不存在或该路径下文档为空,触发浅了解进行区块划分再进行完全深度了解然后新建文档
|
|
||||||
- 先探索目录文件结构,文件大小,然后根据文件名、文件类型、目录结构可能含有的模块化语义等,对整个项目建立分初步区块计划,
|
|
||||||
- 然后再逐个区块的尝试探索其各关键文档信息,验证区块划分是否合理,
|
|
||||||
- 确定区块划分合理后,制定更详细和准确的区块分划计划文档,
|
|
||||||
- 最后逐个区块的进行完全深度了解,并创建对应部分的文档,直到全部完成,
|
|
||||||
- 注意,每当初次开始处理时都要检查区块计划文档,根据当前记录中的进度,接着完成接下来的任务,因为如果项目过大,可能需要多个全新对话多次重新执行才能完成所有区块的任务
|
|
||||||
- 为了稳定多个不同步骤的关键联系,即区块计划文档,可以为这个文档建立一条环境配置数据记录其路径
|
|
||||||
- 若项目文档存在则分区块进行完全深度了解,对文档内容进行验证和同步更新
|
|
||||||
- 验证文档内容是否属实,是否与最新实现效果保持一致
|
|
||||||
- 若不一致则以实现为准更新文档内容
|
|
||||||
|
|
||||||
# 一些特定行为描述
|
|
||||||
|
|
||||||
独立运行:
|
|
||||||
- 指通常会在一个独立启动的全新的对话中直接执行
|
|
||||||
- 并在确认这部分任务目标完全解决后就退出关闭对话
|
|
||||||
|
|
||||||
项目文档:
|
|
||||||
- 这里的项目文档指的是专用于面向LLM的文档
|
|
||||||
- 专用于为LLM保存上下文
|
|
||||||
- 把上下文记忆信息转储为持久化的文档内容
|
|
||||||
- 和初始化上下文
|
|
||||||
- 新对话中让LLM对项目结构、内容等有一个适当的认知,允许LLM先是只能看到脉络(先有对概况的认识,便于更好的分析任务提供帮助,又不会什么都还没干就消耗过多token和上下文),
|
|
||||||
- 然后以此可以允许LLM在实际过程中对项目按需细化深化的进行了解,追溯枝叶根须
|
|
||||||
- 所以对于这个项目文档的创建和维护时的编辑规范,相关的规则、约定等,可以针对面向LLM做优化、特化
|
|
||||||
- 我希望文档被分为(或者你觉得我下面的分划方式不具备普遍适用性、泛用性的话,你可以根据上面所述的项目文档的期望效果,制定更合适的规划)一份总导览和多个子区块部分,
|
|
||||||
- 但必须在子区块局部文档信息完整详细的同时保证总的来说语义一致,他人能仅依赖于子区块的文档及子区块本身的目录文件信息完全了解这个区块,并接手其后续工作,比如需要进行一些调整、删除、添加,
|
|
||||||
- 以当前目录下的项目为例子,我想达到的效果是,如果后续我想对commands中init的业务细节、职能界定等进行调整:
|
|
||||||
- 比如有一个新来的人,仅学习过docs/下那样的内容会写claude code的commands和skills,但是他对这个项目本身没有任何知识基础,那么我希望他可以在仅通过导览文档,知道他应该看哪个文档来完全掌握aide-plugin:init的信息和情况,然后对commands/init.md进行修改,还有更新对应子区块的文档,但仅需要更新子区块,而不用完整的知道aide-requirements.md(或者说所有所有子区块的信息,不必知道所有区块才行动,将文档区块化后我将会删除原aide-requirements.md)的全部内容
|
|
||||||
- 还比如我想对aide程序中的env子命令进行功能调整,那位开发人员可以仅知道跟aide env有关的文档(导览 → aide程序体系导览 → env子命令细节),而不必在完整了解整个commands+skills+完整aide程序设计后才开始行动,
|
|
||||||
- 并且对功能的调整也可以仅涉及相关代码文件和子命令细节文档,涉及导览时更新导览信息即可,导览远比全部的完整信息要轻量得多,
|
|
||||||
|
|
||||||
完全深度了解:
|
|
||||||
- 指对于涉及的内容,比如一个项目就是该项目下的所有目录及其子目录下的每一个文件,
|
|
||||||
- 如果是一个区块就是区块分划中制定的所有文件和目录及其子目录下的每一个文件,
|
|
||||||
- 除非特别制定了应该忽略的文件和目录,默认情况下存在.gitignore文件则遵循其忽略项配置,比如如果.gitignore中设置了忽略`cache/`和`node_modules/`,则忽略这两个目录,不需要了解,
|
|
||||||
- 对于未指定应该忽略掉的文件和目录,要每一个文件都进行读取和审阅分析,了解其内容含义
|
|
||||||
|
|||||||
Reference in New Issue
Block a user