gsd-core 的实现机制：磁盘结构化状态 + 命令驱动按需加载 + 子会话隔离执行

它本质上不是一个后台自动同步工具，而是一套给 AI 编码 Agent 用的工作流操作系统：通过标准化的磁盘文件结构、元提示规则、命令集和子会话编排，把长对话记忆替换成磁盘文件接力 + 短干净会话，从根源上避免 context-rot。

gsd-core 的实现机制：不是新对话自动调取，而是「磁盘结构化状态 + 命令驱动按需加载 + 子会话隔离执行」。

核心实现的四层结构

1. 第一层：标准化磁盘状态目录（`.planning/`）——状态不寄生在对话

所有项目信息、决策、进度、约束全部持久化到磁盘的 markdown 文件，格式统一规范，不依赖任何对话历史保存。

.planning/
├── PROJECT.md          # 项目顶层愿景、边界、核心约束
├── REQUIREMENTS.md     # 需求清单、范围边界、非目标
├── ROADMAP.md          # 里程碑拆分、阶段路线图
├── STATE.md            # 当前进度、已做决策、阻塞点（跨会话续期的核心）
├── phase-01-CONTEXT.md # 本阶段业务背景、技术选型决策
├── phase-01-PLAN.md    # 本阶段原子任务拆分、依赖关系
├── phase-01-SUMMARY.md # 执行完成后的产出总结
├── phase-01-VERIFY.md  # 验收清单与测试结果
└── research/           # 调研证据、参考资料

作用：对话可以删、会话可以结束，磁盘上的文件是唯一真相源
关键原则：所有重要决策、结论、计划必须写进文件，不能只停留在聊天记录里

2. 第二层：元提示 Skill + 命令系统——Agent 的行为规程

安装 gsd-core 本质是给 Agent 注入一整套 Skill 规则 + /gsd: 前缀命令，规定了 Agent 的工作方式：

流程强制：必须遵循 discuss → plan → execute → verify 阶段循环，不能跳步
输出规范：每个阶段的产出必须按固定模板写入对应磁盘文件
加载规则：默认不加载全量文件，只读取当前命令对应的必要文件
粒度约束：单个 Task 必须能放进单个上下文窗口，装不下就强制拆分

它不是让 AI 自由发挥写代码，而是给 AI 套上了标准化的工作流程和输出格式。

3. 第三层：子会话（Sub-Agent）编排——真正的干净上下文

这是根治 context-rot 的核心机制，也是最容易被误解的地方：执行阶段（execute-phase）会把每个原子 Task，拆成独立的子 Agent 会话去执行，而不是在主对话里一直跑。

主会话只做规划、调度、验收，不执行具体编码
每个 Task 启动一个全新的、独立的子会话，只加载三样东西：
- 最小必要的项目约束（精简版 PROJECT/REQUIREMENTS）
- 本 Task 的具体任务说明
- 相关的代码片段 / 文件
子会话完成编码后，自动做 git 原子提交，写入 task summary，然后销毁这个子会话
主会话不继承子会话的聊天过程，只读取最终的代码提交和总结

效果：每个编码任务都在一个零历史包袱的干净上下文里跑，永远不会积累到需要压缩的地步；主会话始终保持精简，只做管理和决策。

4. 第四层：阶段校验与闭环——防止跑偏

plan 阶段会先校验任务列表能不能完整放进上下文窗口，装不下就继续拆
verify 阶段会单独跑验收，不通过就自动生成修复计划，回退到 execute 重跑
每个阶段完成后，产出自动归档到 .planning/，同步更新 STATE.md

回答你的疑问：开启新对话就会自动调取吗？

不是自动调取，是命令驱动的按需读取。

新开一个空白对话，Agent 不会主动扫描磁盘、自动加载全部 .planning 文件
你需要输入对应命令来接续，比如：
- /gsd:onboard：载入现有项目，读取核心文件接续进度
- /gsd:continue-phase 2：继续执行第 2 阶段，只读取阶段 2 相关的文件
- /gsd:verify：执行验收，读取对应阶段的计划和代码
设计原则：默认不加载，需要才读。避免一上来就把所有规划文件塞进上下文，平白浪费 token。

跨会话续期的本质：不是恢复聊天记录，是读取磁盘上的 STATE.md + 当前阶段文件，接续工作状态。