研究报告生产机 V2.0 快速开始
1. 获取与基础验证
bash
git clone https://github.com/joinwell52-AI/joinwell52.git
cd joinwell52
npm install
npm run runtime:validate
npm run docs:build2. 先理解事实源
不要用“Actions 有没有绿”代替 Runtime 状态。按以下顺序检查:
research/runtime/SCHEDULER.json:正式任务、时间、Family;research/runtime/records/...:机器事实状态;research/runtime/YYYY/MM/YYYY-MM-DD-runtime.md:人类可读复合账本;- GitHub Actions:只确认 heartbeat、状态持久化和校验是否执行。
3. Daily 顺序
text
Discovery → Queue → Reading → Analysis → Production → Publication周日 Publication 完成后再运行 Weekly。任何后置任务不得越过未完成前置任务。
4. 漏班恢复
正常情况下无需手工指定“现在该补哪个”。Scheduler heartbeat 会:
- 找到已经到时的任务;
- 检查 durable status;
- 检查前置依赖;
- 识别依赖已解除的 Blocked;
- 每次只打开最早的一个可执行欠班。
如果需要人工恢复,仍应从最早未完成依赖开始,不得直接跳到当前钟点对应阶段。
5. 自检
恢复或调度后至少验证:
bash
npm run runtime:validate
node scripts/runtime-markdown.mjs render --date YYYY-MM-DD
node scripts/runtime-markdown.mjs validate --date YYYY-MM-DD同时检查:机器 taskStatus、Markdown 状态、Execution Slot Opened 时间线和 durable Git commit 是否一致。
6. Blocked 恢复
依赖型 Blocked 应带 blockedBy。依赖完成后由 Scheduler 受控 reopen;不要删除 Blocked 历史事件,也不要手工把它改成 Completed。
7. 周日检查
周日当天应有 7 个任务:六个 Daily 阶段加 20:30 Weekly。若页面只显示 6 个,应检查 Weekly family record / projection,而不是修改 Daily 六阶段定义。
8. 故障处理原则
text
确认事实
→ 找最早缺口
→ 修前置依赖
→ 自检
→ 持久化并 Verify
→ 再推进下一阶段禁止为了“赶进度”同时打开多个依赖阶段。