记忆与上下文系统
Spec-First 当前更准确的说法，不是一个抽象的“多层记忆黑盒”，而是一组 可落在文件系统上的上下文与知识资产。
官网旧版这页提到的 task.json、.current-task、.agent-log、journal-N.md，并不是当前产品 README 和 skill 真源里对外稳定承诺的核心模型，因此这里改为按当前源码可证实的资产来说明。
当前真正稳定的几类上下文资产
1. Stage-0 上下文资产
这一层来自 spec-graph-bootstrap 与 stage0-context。
关键产物包括：
- Phase 0–4 facts
injection-index.yamlminimal-context/*.jsonselected_assetsverification_summaryverification_gate_state
这类资产的作用是：
- 让 LLM 在 Plan / Work / Review 开始前，先拿到结构化、带来源依据的上下文
- 明确当前上下文的
provenance、confidence、fallback_reason
2. 工作流 artifact
Spec-First 主工作流会把关键阶段结果写成稳定工件：
docs/ideation/*.mddocs/brainstorms/*.mddocs/plans/*.mddocs/solutions/**/*.md
这些文件不是运行时缓存，而是长期可读、可审查、可进入版本管理的知识与决策记录。
3. 持久 Todo
当前 Todo 系统的 canonical 路径是：
text
docs/todos/Todo 相关 skills 会把跨会话工作项写成 markdown 文件，而不是短期会话内的临时状态对象。
这类资产适合记录：
- code review 残留问题
- 技术债
- 需要跨会话跟踪的工作项
4. Session 历史
当前产品已经把 session history 作为一类可检索上下文来对待，对应 workflow 是：
- Claude：
/spec:sessions - Codex：
$spec-sessions
它的用途不是替代 plans 或 todos，而是回答：
- 之前这个问题怎么查过
- 哪些方案试过
- 某次会话里做了什么
5. 受管运行时状态
初始化后，项目内还会有宿主相关状态文件，例如：
.claude/spec-first/state.json.codex/spec-first/state.json.claude/spec-first/.developer.codex/spec-first/.developer
它们的职责是记录：
- 受管资产当前版本与分发结果
- 项目开发者身份
这类文件属于运行时治理面，不等同于团队知识库。
最实用的心智模型
如果要用一句话理解 Spec-First 的“记忆系统”，当前最稳妥的说法是：
text
Stage-0 上下文 + 工作流 artifact + docs/todos + session history + 运行时治理状态而不是：
text
某个统一的 task.json / 会话日志中心哪些是长期知识，哪些不是
长期知识
docs/solutions/**/*.mddocs/brainstorms/*.mddocs/plans/*.mddocs/ideation/*.mddocs/todos/*.md
运行时或控制面资产
minimal-context/*.jsonverification_summaryverification_gate_state.claude/spec-first/state.json.codex/spec-first/state.json
前者适合长期复用和团队协作，后者更接近运行时事实与治理状态。
这套系统解决什么问题
- 不让需求和计划只存在聊天里
- 不让 solved problems 在下一轮完全消失
- 不让 review 残留问题只能靠人脑记住
- 不让 LLM 每次都从裸代码库和空白会话重新开始
当前不该继续宣传的旧口径
task.json是官方统一任务真源.current-task/.agent-log是整套系统的核心记忆层- 记忆系统主要靠某个隐藏运行时文件组织
这些说法要么偏旧，要么不是当前 README 与 skills 真源的对外稳定承诺。