Nop Task Planner

2. 读取过的有用的文件

• 记录你读取过的、对任务有帮助的文件。
• 格式：- [文件路径]：简要说明从中获取了什么信息或为什么有用。
• 如果同一个文件被多次读取，只需记录一次，但可在说明中补充多次使用的信息。避免列出无关文件。

3. 编写的文件

• 记录你创建或修改过的所有文件。
• 格式：- [文件路径]：简要描述新增或修改的内容（如功能、修复、结构等）。
• 如果文件后续被再次修改，请更新摘要以反映最新状态，不要保留旧版本描述。

4. 任务列表（两级结构）

• 开始任务前，根据用户需求拆解出清晰的 Phase（阶段）和每个 Phase 下的 Step（步骤）。
• 建议使用 Markdown 的二级标题 ## 表示 Phase，无序列表表示 Step，例如：

  ## Phase 1：环境配置
  - [x] 安装依赖包
  - [ ] 配置数据库连接
  
  ## Phase 2：核心功能实现
  - [ ] 实现用户认证模块
  - [ ] 编写 API 端点
  

• 每完成一个 Step，立即将其标记为 [x]。
• 如果任务过程中发现新的 Step 或需要调整 Phase，及时更新列表并保持结构清晰。
• 确保任务列表完整，未完成项清晰可辨。整个任务列表应简明扼要，不要过度细化到每个函数实现（除非必要）。

5. 附加信息的使用

• 在"附加信息"部分，你可以记录任何有助于恢复任务或理解决策背景的内容，例如：
  • 为什么选择某种技术方案？
  • 遇到的关键错误及解决方法。
  • 需要进一步验证的假设。
  • 后续步骤的重要注意事项。
• 保持此部分精简，仅记录真正有用的信息。

6. 文档长度控制

• 整个 nop-task.md 应保持简洁，避免长篇大论。关键信息应总结归纳，不重复对话内容。
• 例如，对于读取的文件，只需说明用途和核心信息点，不要复制整个文件内容。
• 对于编写的文件，摘要应聚焦于改动要点，而不是逐行描述。

7. 中断恢复场景

• 假设你在执行过程中突然中断，下次启动时你将获得 nop-task.md 作为唯一上下文。
• 因此，记录必须足够详细，确保仅凭此文档就能明白：
  • 已经完成了哪些工作（任务列表已完成项、已读文件、已编写文件）。
  • 还有哪些工作待完成（任务列表未完成项）。
  • 接下来从哪里开始（通常从第一个未完成的 Step 开始）。
  • 任何可能影响后续工作的决策或背景（附加信息）。

8. 敏感信息处理

• 禁止在文档中记录任何敏感信息，如密码、API密钥、个人数据等。如果任务需要这些信息，应在外部安全存储，并在文档中引用其位置（例如环境变量名）。

9. 单任务单AI假设

• 该任务由单一 AI 会话执行，不会有多个 AI 同时处理。因此文档无需考虑并发冲突。

10. 任务类型适配

• 根据任务类型（如软件开发、数据分析、文档撰写等），AI 可自主调整记录的侧重点，但必须保持上述基本结构。

初始化流程

• 在开始执行用户指定的具体任务前，立即创建 nop-task.md 文件，并写入基本结构（可以留空各章节，任务列表部分可先根据初始需求填写 Phase 和 Step）。
• 然后开始执行任务，并在每一步操作后更新文档。

任务完成

• 当所有任务列表中的 Step 都被标记为已完成时，任务即告完成。最终的 nop-task.md 可作为交付物之一提供，用于审计或后续参考。

示例片段（仅为示意，实际应根据任务调整）

## 读取过的有用的文件
- `config/settings.yaml`：读取了数据库连接参数和日志级别配置。
- `src/utils/helpers.py`：查看了 `read_file` 函数，计划复用。

## 编写的文件
- `src/main.py`：创建了主程序入口，调用 `parse_config` 和 `run_pipeline`。
- `tests/test_main.py`：添加了针对 `parse_config` 的单元测试。

## 任务列表
## Phase 1：准备
- [x] 分析需求文档
- [x] 读取配置文件
- [x] 搭建项目结构

## Phase 2：开发
- [ ] 实现数据处理管道
- [ ] 编写单元测试并验证

## 附加信息
- 选择使用 Pandas 进行数据处理，因为数据量预计在百万级以内。
- 在测试中发现配置文件路径问题，已通过添加环境变量解决。

开始工作

现在，请明确用户给你的具体任务，并立即初始化 nop-task.md 文档，开始按照上述规则执行。在每一步操作后，及时更新文档。当任务完成后，最终的 nop-task.md 应作为交付物之一提供。