fix:checkpoint,issue #157

[Prado-learning]

关联 Issue

Fix #157

背景

当前 recall_checkpoint.json 中的 total_memories_extracted 和 l0_conversations_count 是增量累加字段。
当 memory-cleaner 清理历史数据，或者用户手动删除 records/*.jsonl / SQLite 中的记录后，checkpoint 中的计数不会同步下降，导致 checkpoint 计数高于真实数据。
这会让后续依赖 checkpoint 的 pipeline / scheduler 使用过期的聚合计数。

本 PR 做了什么

1. 在 CheckpointManager 中新增 recalibrate() 方法：

   • 用真实存储数据重新校准 checkpoint 中容易漂移的计数字段。
   • 只更新：
     • total_memories_extracted
     • l0_conversations_count
   • 不修改 runner_states 和 pipeline_states，避免破坏已有 session 状态恢复。

2. 新增安全的 JSONL 统计逻辑：

   • 统计 records/*.jsonl 中的非空行数，作为真实 L1 memory 数量。
   • 统计 conversations/*.jsonl 中的非空行数，作为 L0 fallback 数量。
   • 目录不存在时返回 0。
   • 单个文件读取失败时只记录 warning，不中断启动流程。
   • 不解析 JSON 内容，只按非空行计数，降低历史脏数据导致校准失败的风险。

3. L0 计数优先使用 VectorStore：

   • 如果 vectorStore 可用，优先调用 vectorStore.countL0()。
   • 如果 vectorStore 不可用、处于 degraded 状态，或 countL0() 抛错，则 fallback 到 conversations/*.jsonl 非空行数。

4. 在 scheduler 启动恢复 checkpoint 前执行校准：

   • 在 TdaiCore.ensureSchedulerStarted() 中，读取 checkpoint 并恢复 pipeline state 之前，先调用：

   await checkpoint.recalibrate({ vectorStore: this.vectorStore });

   • 确保后续 scheduler.start(...) 使用的是校准后的 checkpoint。

5. 调整 captureAtomically() 的 L0 计数语义：

   • 原来每次 capture 成功只执行 l0_conversations_count += 1。
   • 现在改为按实际捕获的消息行数累加：

   cp.l0_conversations_count += result.messageCount;

   • 这样可以和 vectorStore.countL0() / conversations/*.jsonl 的真实行数语义保持一致。

6. 新增单元测试：

   • 覆盖 checkpoint 原计数为 50，但 records/*.jsonl 真实只有 42 行时，校准后变为 42。
   • 覆盖 runner_states / pipeline_states 在校准后保持不变。
   • 覆盖 vectorStore.countL0() 优先路径。
   • 覆盖 vectorStore.countL0() 失败后 fallback 到 conversations/*.jsonl。
   • 覆盖目录不存在时计数归零。
   • 覆盖 captureAtomically() 按消息行数累加 L0 计数。

验证

已执行：

npm run test -- src/utils/checkpoint.test.ts
npm run test

验证结果

• 定向测试通过：1 passed (1), 4 tests passed

- 全量测试通过：`5 passed (5), 71 tests passed`

Change Type | 修改类型

• Bug fix | Bug 修复

Additional Notes | 其他说明

本 PR 没有直接修改 dist/index.mjs，只修改 src 源码并新增单元测试。

[YOMXXX]

Duplicate cleanup note: #177 is already the canonical PR for #157.

#177 covers checkpoint recalibration after cleanup and on scheduler startup, includes focused tests, and has been locally verified and approved. Compared with #177, this PR overlaps on recalibrating total_memories_extracted / l0_conversations_count but does not include the same cleanup integration and related counter adjustment behavior already covered by the canonical fix.

Recommendation: close this in favor of #177, or re-scope it only if there is a small follow-up behavior not covered after #177 lands.

[Maxwell-Code07]

Thank you for submitting this PR and participating in Tencent Rhino-bird Open-source Training Program!
We have successfully received your submission. The program is currently in full swing, and we will complete the Code Review for you as soon as possible. Please keep an eye on the status notifications for this PR so you can follow up promptly once the review feedback is provided.
Thanks again for your contribution and open-source spirit! 🚀