agent-aide/statements/old-task-section.md

# 想法

创建一个新的command（暂时称为cmd-3），专门用于处理为项目创建和维护文档（这一command将会是“独立运行”的）：
- 在环境配置中建立一条用于记录项目文档目录路径的数据
- 如果项目文档目录路径不存在或该路径下文档为空，触发浅了解进行区块划分再进行完全深度了解然后新建文档
    - 先探索目录文件结构，文件大小，然后根据文件名、文件类型、目录结构可能含有的模块化语义等，对整个项目建立分初步区块计划，
    - 然后再逐个区块的尝试探索其各关键文档信息，验证区块划分是否合理，
    - 确定区块划分合理后，制定更详细和准确的区块分划计划文档，
    - 最后逐个区块的进行完全深度了解，并创建对应部分的文档，直到全部完成，
    - 注意，每当初次开始处理时都要检查区块计划文档，根据当前记录中的进度，接着完成接下来的任务，因为如果项目过大，可能需要多个全新对话多次重新执行才能完成所有区块的任务
    - 为了稳定多个不同步骤的关键联系，即区块计划文档，可以为这个文档建立一条环境配置数据记录其路径
- 若项目文档存在则分区块进行完全深度了解，对文档内容进行验证和同步更新
    - 验证文档内容是否属实，是否与最新实现效果保持一致
    - 若不一致则以实现为准更新文档内容

# 一些特定行为描述

独立运行：
- 指通常会在一个独立启动的全新的对话中直接执行
- 并在确认这部分任务目标完全解决后就退出关闭对话

项目文档：
- 这里的项目文档指的是专用于面向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/`，则忽略这两个目录，不需要了解，
- 对于未指定应该忽略掉的文件和目录，要每一个文件都进行读取和审阅分析，了解其内容含义