Task Tracker

定位

task-tracker 是任务层的 bookkeeping skill。它知道 task-framework 的内部约定（TASK.md checkbox 格式、CHANGELOG.md 追加格式、索引更新），对外暴露简单的参数接口。

角色不需要知道 task-framework 的任何细节——它们只需要加载 task-tracker 并传入参数。

参数

执行步骤

1. 读取 TASK.md
2. 找到包含 <phase> 文本的 - [ ] 行，改为 - [x]
3. 同步回写 runtime/INDEX.md：任务使用 runtime/ 执行状态时，phase 对应条目状态变化（完成→done，阻塞→blocked+原因）必须在同一次回写中更新，保持索引与实际状态一致（格式见 compact-directory-memory）
4. 在 CHANGELOG.md 末尾追加记录：

## <phase> — <executor>

- **执行时间**: <当前时间>
- **状态**: completed
- **关键发现**:
  - <finding line 1>
  - <finding line 2>
- **输出**:
  - `<output file 1>`
- **下一步**: <next>

5. 运行 python3 scripts/update-index.py # from the skill directory

连续操作补记（session 收尾，非 phase 驱动）

除 phase 完成时回写外，每次连续操作（一个 session 或一批连续工作）结束、或切换到新的工作领域前，必须立即回写账本——即使这批工作不严格对应某个 phase（跨领域收尾、部署、数据迁移、工具/skill 勘正等都算）：

1. CHANGELOG.md 追加：本次连续操作的「操作 / 原因 / 结果」，一条 ## <日期 时间（含秒）> <主题> 记录。跨领域的工作也要记，不能只记 phase 内的产出。
2. MEMORY.md 补硬事实/决策：本次产生的「决策」「工具事实」「环境事实」立即追加，不留在会话记忆里。
3. runtime/INDEX.md 同步：状态变化（完成/阻塞）在同一次回写更新，保持索引与实际一致。

反模式（实测踩过）：连续推进多件跨领域的事（批次收口、数据迁移、ClickHouse/MinIO 部署、看板测试、skill 重构），一路靠会话记忆，直到用户问「都记录了吗」才发现 CHANGELOG 停在很早以前、MEMORY 缺硬事实。补记必须在收尾时做，不是等用户问。凡「这次会话做了什么」能列出清单，就说明该回写了。

使用示例

加载 task-tracker：
  task_dir: $HERMES_TASKS_ROOT/<ts>.<task-name>-<hash6>
  phase: Phase 0: scrutiny-pipeline
  executor: my-agent
  findings:
    - Finding 1
    - Finding 2
  outputs:
    - output/docs/00-scrutiny-report.md
  next: Phase 1: domain-analysis

与 task-framework 的关系

task-tracker 封装了 task-framework 的以下操作：

• TASK.md checkbox 格式（- [ ] → - [x]）
• CHANGELOG.md 追加格式
• update-index.py 调用

task-framework 不需要知道 task-tracker 的存在——它只提供 task 容器。task-tracker 是独立工具，消费 task-framework 的产出格式（runtime/INDEX.md 回写即其中之一，格式由 compact-directory-memory 定义）。

与 orchestrator 的关系

Orchestrators读取 TASK.md 的 ## Tracking 段，获取 tracker skill 名和参数定义，注入到每个 phase 的 card body 或 worker brief 中。

角色收到 card 后，在工作完成时按 brief 指令加载 task-tracker 并传入参数。角色不需要理解 task-framework——它只管传入参数。