长程任务的上下文治理：会话可以结束，项目状态需要接续

这份方案试图解决一个具体问题：一个任务经历多次会话后，接手的 Agent 应当从哪里了解当前状态？

只留下聊天摘要，容易把已经否决的方案与当前决定混在一起。把所有材料写成文件之后，也还需要决定先读哪些、怎样验证它们没有过时。

入口、当前任务与证据分开

方案采用逐层读取：入口只提供导航，任务索引说明当前做什么，相关文件解释需求和决策，日志与历史则留待核查。

项目规则文件不承担整本项目百科的职责。它应当指出权威来源和边界，让下一次会话能找到材料，而不是复制一遍所有内容。

一条上下文指针除了路径，还应说明用途与适用任务。恢复时需要判断这份材料对应哪个版本，以及后续变化是否使它失效。文件能被读到，不代表里面的结论仍然有效。

给信息标明依据

原方案区分已验证事实、他人报告、推断、假设与未知项。这些类别用来避免一种常见混淆：一段很确定的文字，被接手者误当成已经执行过的验证。

例如，记录中应当能够分清“预计修改后可以通过构建”与“已执行构建，结果通过”。前者仍然需要检查；后者也需要能找到命令、版本和结果。

交接保存什么

交接记录应覆盖当前目标、已经确认的进展、失败方案、不可违反的约束，以及下一步如何验证。历史细节保留路径即可。

恢复之后先核对真实工作区。若文档与代码或 Git 状态不一致，应调查差异，再决定沿用或修订旧记录。未经确认的猜测不能在交接时自动升级成事实。

先做最小闭环

原始材料还提出初始化、检查点、交接、恢复与审计等 Skills，以及辅助脚本和 Hooks。它们目前在本文中属于设计候选，不是已经安装和验证的能力。

可以先用少量文件手动完成一次中断与恢复，检查记录是否足够，再考虑自动生成指针、检查新鲜度和控制读取范围。增加自动化之前，先明确哪些状态值得保存，以及谁负责确认它们正确。