junhong_cmp_fiber/CONTEXT_RESET_PLAN.md

项目 Context 全量重置实施方案

状态：待用户评审，未批准前禁止执行删除、迁移、初始化或全局卸载操作。

性质：本文件是本次重置期间唯一执行契约，不是长期项目 Context。全部任务通过验证后删除，由 Git 历史保留。

1. 目标

在不修改业务代码、数据库迁移、测试、构建与部署配置的前提下：

1. 移除旧 GSD、.planning、旧 OpenSpec、过期文档、临时研究和规范型 Skills。
2. 保留外部系统接入资料，并统一收口到 docs/integrations/。
3. 使用 OpenSpec 1.8.0 当前默认结构重新初始化 Codex 与 Claude 集成。
4. 重建短小、稳定、渐进披露的 Agent Context。
5. 重建一页系统架构地图和可判定的工程约束，不再把规范包装成 Skill。
6. 从可执行代码、迁移、路由、配置和测试生成系统当前 As-Is 行为 Specs。
7. 当前 Bug、不一致和不合理行为照实进入基线，不在本任务中修复。
8. 后续所有行为修改通过独立 OpenSpec Change 完成。

2. 已确认决策

2.1 事实源

重置完成后的优先级：

可复现运行结果 / 自动化测试
  > 实际可达代码与生效配置
  > 数据库迁移与 Schema
  > 经归档同步后的 openspec/specs
  > ARCHITECTURE.md 系统地图与依赖边界
  > docs/engineering/工程约束.md 长期工程规则
  > docs/integrations 外部接口资料
  > AGENTS.md 导航

• openspec/specs/ 是已建立基线后的当前行为契约。
• 基线生成期间若 Spec 与代码冲突，以当前实际行为修正 Spec，不修改代码。
• 旧文档、旧 OpenSpec 和聊天记录不得作为新基线的规范来源。
• 外部接入资料只说明第三方契约，不直接证明本系统已经实现对应行为。

2.2 Bug 处理

• 当前系统确实存在的 Bug、不合理行为和历史兼容行为，均按现状写入 Spec。
• 不创建并行的 Known deviations 事实源，不要求用户逐条审查基线。
• AI 可以在后续 Explore 中指出疑似问题，但必须通过新 Change 才能修改行为。
• 建立基线时禁止顺手修复、重构、优化或理想化现有实现。

2.3 Context 分层

• 根 AGENTS.md：全局硬约束、常用验证命令、事实源优先级和导航，目标 80～120 行，150 行为软上限。
• openspec/specs/：可观察业务行为、状态流转、权限、金额、失败与幂等语义。
• openspec/changes/：未来单次变更的 proposal、delta specs、design、tasks。
• ARCHITECTURE.md：系统职责、运行单元、模块地图、依赖方向、关键数据流和验证入口；只作地图，不重复业务 Spec。
• docs/integrations/：按统一契约模板保存第三方版本、字段、签名、错误、重试、幂等、安全和验收证据。
• docs/engineering/工程约束.md：每条规则使用稳定 ID、适用范围、正反例、机械检查、例外、Owner 和最后验证日期。
• docs/engineering/从零构建Agent友好项目最佳实践.md：通用 Harness 方法和上述文档的生成/评审标准，不承载本项目业务事实。
• Skills：只保留有明确输入、执行步骤、产物和验证的工作流；DTO、Model、路由、迁移、注释等声明式规则不做 Skill。
• .lh-harness/：仅保存本次执行状态和证据，不是需求或行为事实源，不纳入 Git。

2.4 工作流边界

• 不使用 OMX；OMX 已完成本机卸载，本方案只做残留验证。
• 不使用 GSD；本方案负责删除项目 .planning 及本机 GSD Skills/Agents/引擎文件。
• 不使用旧 OpenSpec Change 管理本次 OpenSpec 自身重置。
• 本文件是重置期间唯一任务契约；LongHorizon-Harness 只能镜像任务状态和审计证据，不得生成第二份计划。
• 使用 Codex 原生 Subagent 处理可独立、只读或边界明确的任务；最终删除和验收由主 Agent 负责。

3. 当前盘点基线

以下数据仅用于评审，执行时必须重新盘点：

对象	当前状态
OpenSpec CLI	1.8.0，与 npm 最新版一致
OpenSpec Schema	官方 spec-driven：proposal → specs → design → tasks
主 Specs	154 个
活跃 Changes	10 个
归档 Changes	130 个
.planning	51 个文件，约 600 KB
.scratch	196 个文件，约 2.3 MB
.sisyphus	22 个文件，约 384 KB
docs	272 个文件，约 5.7 MB
openspec	1106 个文件，约 8.1 MB
当前工作树	已存在约 78 项未提交变更，必须原样保护
全局 GSD Skills	57 个 ~/.codex/skills/gsd-* 目录
全局 GSD Agents	18 个角色，共 36 个 .md/.toml 文件
GSD 引擎	~/.codex/get-shit-done/，约 1.6 MB
GSD Manifest	~/.codex/gsd-file-manifest.json

4. 范围

4.1 必须删除或重建

项目内

• .planning/
• .scratch/
• .sisyphus/
• CONTEXT.md
• 旧 openspec/ 全部内容
• 除外部接入资料外的旧 docs/ 内容
• 旧 OpenSpec 生成的 .codex/prompts/opsx-*、.codex/skills/openspec-*
• 旧 OpenSpec 生成的 .claude/commands/opsx/、.claude/skills/openspec-*
• 项目本地 DTO、Model、路由、迁移、DB 验证、注释、文档管理、API 契约等规范型 Skills
• 项目本地其他没有明确工作流价值的 Skills；默认删除，后续按真实需要重建
• 现有 AGENTS.md 正文，替换为最小导航
• CLAUDE.md 中重复项目规则，替换为对 AGENTS.md 的薄引用

用户级 GSD

• ~/.codex/skills/gsd-*
• ~/.codex/agents/gsd-*.md
• ~/.codex/agents/gsd-*.toml
• ~/.codex/get-shit-done/
• ~/.codex/gsd-file-manifest.json
• ~/.codex/config.toml、Hooks、Shell 配置中实际存在的 GSD 专属引用

4.2 必须保留

• cmd/、internal/、pkg/ 等业务代码
• migrations/ 中数据库迁移
• 所有 _test.go、tests/ 和测试基础设施
• go.mod、go.sum、Makefile、脚本、Docker、CI/CD 与部署配置
• 业务运行需要的配置模板和环境变量说明
• 外部系统接入资料，迁移后统一位于 docs/integrations/
• docs/engineering/从零构建Agent友好项目最佳实践.md
• .lh-harness/ 运行能力，但其运行数据必须保持 Git 未跟踪
• 用户级非 GSD Skills、插件和 Codex 配置
• 当前所有未提交业务修改

4.3 明确不做

• 不修改任何业务行为。
• 不修复已发现 Bug。
• 不重构目录或迁移 DDD 用例。
• 不新增领域对象、接口、抽象或依赖。
• 不调用生产服务、真实支付渠道或外部审批系统。
• 不把旧文档移动到仓库内 legacy/、archive/ 或其他可搜索目录。
• 不创建第二套 roadmap、PRD、issue、todo、status 或任务台账。
• 不自动提交 Git Commit。

5. 目标结构

AGENTS.md                         # 最小全局导航
CLAUDE.md                         # 仅保留 Claude 工具差异和 AGENTS 引用
README.md                         # 项目启动入口，不承载详细领域规则
ARCHITECTURE.md                   # 一页系统地图、依赖方向和验证入口

openspec/
├── config.yaml                   # 最小 schema 配置
├── specs/                        # As-Is 当前行为
└── changes/                      # 后续变更

docs/
├── engineering/
│   ├── 从零构建Agent友好项目最佳实践.md
│   └── 工程约束.md               # 带规则 ID 和检查方式的项目约束
└── integrations/
    ├── alipay/
    ├── wechat/
    ├── wecom/
    ├── fuiou/
    ├── gateway/
    ├── object-storage/
    └── _unclassified/            # 无法安全归类时的保守落点

.agents/skills/
└── openspec-*                    # OpenSpec 1.8.0 官方生成

.claude/
├── commands/opsx/                # OpenSpec 1.8.0 官方生成
└── skills/openspec-*             # OpenSpec 1.8.0 官方生成

6. 外部接入资料判定规则

6.1 保留内容

• 第三方官方 API、字段、签名、回调、错误码和协议说明。
• 本项目调用第三方所需的配置字段、环境变量和凭证名称说明，但不得包含真实密钥。
• 沙箱/生产地址差异、限流、超时、重试和验签说明。
• 必须人工完成的真实环境验收步骤。

6.2 不作为外部资料保留

• 某个功能的完成总结、测试总结或实施报告。
• 重复描述本系统业务行为的 API 文档。
• 已过期的内部设计方案、任务清单和前端联调总结。
• 仅因文件名包含“微信/支付宝/企微”等字样，但正文实际属于业务需求的文档。

6.3 迁移策略

1. 从代码依赖、配置键、适配器和现有文档反向识别全部第三方系统。
2. 建立原文件到 docs/integrations/<provider>/ 的迁移清单。
3. 对保留文件计算 SHA-256；优先原样移动，不在本任务中重写内容。
4. 内容混合时只提取第三方契约部分；提取前保留原文件于仓库外备份。
5. 无法判断时移入 _unclassified/，不得直接删除。
6. 迁移后检查所有仓库内引用并只修正文档链接；禁止修改业务代码引用。

7. 执行任务

所有任务必须按顺序完成，不得合并或跳过。每项只有通过对应验证后才能进入下一项。

0. 建立安全基线

架构通道：Infrastructure / 工程治理。 业务边界：仅保护工作树和 Context 文件；不迁移任何旧业务用例。

• 0.1 重新记录 git status --porcelain=v1 -z，区分已有修改与本任务修改。
• 0.2 对受保护业务路径生成文件清单与 SHA-256 基线。
• 0.3 将所有待删除 Context、GSD 文件和未跟踪 Context 打包到仓库外临时目录。
• 0.4 生成备份 SHA-256 和可运行恢复脚本，并实际在临时目录解包验证。
• 0.5 检查是否存在并发 Agent 正在写入待处理目录；存在时停止对应进程后再继续。

验证：

• 备份归档可列出、可解包，恢复脚本通过临时目录演练。
• 当前未提交业务文件数量、路径与哈希已记录。
• 受保护路径没有因备份发生变化。

1. 卸载用户级 GSD

架构通道：Infrastructure / 工具链。 业务边界：仅删除 GSD 用户级安装；不删除其他 Codex Skills、插件和配置。

• 1.1 依据 gsd-file-manifest.json 与实际文件系统取交集，形成精确删除集合。
• 1.2 备份 GSD Skills、Agents、引擎、Manifest 及包含 GSD 引用的配置片段。
• 1.3 删除 57 个 gsd-* Skill 目录及实际发现的新增 GSD Skill。
• 1.4 删除 gsd-* Agent .md/.toml 文件。
• 1.5 删除 ~/.codex/get-shit-done/ 与 ~/.codex/gsd-file-manifest.json。
• 1.6 只移除配置、Hooks、Shell 中确认属于 GSD 的引用。

验证：

find ~/.codex/skills -maxdepth 1 -name 'gsd-*'
find ~/.codex/agents -maxdepth 1 -name 'gsd-*'
find ~/.codex -maxdepth 2 \( -name 'get-shit-done' -o -name 'gsd-file-manifest.json' \)

以上命令均应无输出；codex --version 必须成功。重新启动 Codex 后，Skill 列表不得再出现 GSD。

2. 验证 OMX 已完全退出

架构通道：Infrastructure / 工具链。 业务边界：只读验证，不重复执行卸载。

• 2.1 验证 omx 命令、两套 npm 包、用户 Hooks 与 .omx 目录均不存在。
• 2.2 验证项目与用户级 Agent 指令中没有 oh-my-codex 或 OMX: 引用。

验证： command -v omx 无输出；Homebrew/NVM npm 列表无 oh-my-codex；Codex 可启动。

3. 收口外部接入资料

架构通道：Infrastructure / Adapter 文档。 业务边界：只移动第三方契约资料；不修改 Adapter、配置加载或业务调用逻辑。

• 3.1 从依赖、配置、Adapter 和现有文档识别第三方提供商全集。
• 3.2 按第 6 节规则分类现有候选资料。
• 3.3 创建 docs/integrations/<provider>/ 并移动保留资料。
• 3.4 混合文档只提取第三方契约内容，原文进入仓库外备份。
• 3.5 无法分类的资料进入 _unclassified/。
• 3.6 修复保留文档之间的相对链接。
• 3.7 为每个已分类 Provider 建立标准 README.md：Owner、官方来源与版本、适用环境、接入范围、端点/认证、请求响应、签名/回调、错误处置、幂等、超时重试、限流、安全、沙箱验证、人工验收、最后核验日期和更新触发条件。

验证：

• 迁移前后保留内容哈希一致；发生提取时有逐文件差异记录。
• docs/integrations/ 之外不存在第三方接入资料副本。
• 仓库中没有指向已删除旧文档的有效入口链接。
• 项目实际使用的字段、签名、金额单位、错误和重试规则均能追溯到官方来源或脱敏真实样例。

4. 删除旧项目 Context

架构通道：Infrastructure / 工程治理。 业务边界：删除说明与运行状态，不修改业务实现。

• 4.1 删除 .planning/、.scratch/、.sisyphus/、CONTEXT.md。
• 4.2 删除旧 openspec/。
• 4.3 删除 docs/integrations/ 和已确认保留的 docs/engineering/从零构建Agent友好项目最佳实践.md 之外的旧 docs/ 内容；工程约束.md 在任务 6 从零重建，不沿用旧正文。
• 4.4 删除项目本地旧 OpenSpec 指令、重复集成和规范型 Skills。
• 4.5 删除其余无明确工作流价值的项目本地 Skills。
• 4.6 清空旧 AGENTS.md 和 CLAUDE.md 内容，立即进入任务 5 重建，避免仓库长期无入口。

验证： 删除目标不存在；旧业务文档与旧工程规范无残留；受保护业务路径哈希与任务 0 基线一致。

5. 使用 OpenSpec 1.8.0 重新初始化

架构通道：Infrastructure / 工具链。 业务边界：只生成官方 OpenSpec Harness，不创建业务 Change。

• 5.1 再次确认 openspec --version 为 1.8.0 或执行时 npm 最新稳定版。
• 5.2 执行：

openspec init . --tools codex,claude --force --no-animation

• 5.3 将 openspec/config.yaml 保持为最小配置：

schema: spec-driven

• 5.4 不恢复旧 context、rules、consensus、测试比例或工程规范块。

验证：

openspec doctor --json
openspec schemas --json
openspec context --json

• Doctor healthy。
• Schema 仅使用官方 spec-driven。
• 生成的 Skills/Commands 标记来自当前 OpenSpec 版本。
• 不存在旧 .codex OpenSpec 重复入口。

6. 重建最小 Agent 入口、系统地图和工程约束

架构通道：Infrastructure / 工程治理。 业务边界：只建立 Agent 导航，不定义或修改业务行为。

• 6.1 从代码和有效构建命令重新生成 80～120 行的 AGENTS.md。
• 6.2 只保留：语言约束、不可替代技术栈、事实源优先级、受保护边界、常用验证命令、OpenSpec 入口和渐进披露规则。
• 6.3 不复制 DTO、Model、路由、迁移、审计、测试、DDD 的长规范与示例。
• 6.4 CLAUDE.md 只引用 AGENTS.md 并保留确有必要的 Claude 工具差异。
• 6.5 确保 .lh-harness/ 被忽略且不成为事实源。
• 6.6 从可达入口和真实依赖生成 ARCHITECTURE.md：系统职责/非职责、运行单元、模块职责与入口、允许/禁止依赖、关键同步/异步数据流、信任/事务边界、结构验证命令和详细资料链接。
• 6.7 从旧规范候选、代码惯例、构建配置和真实故障约束中重新建立 docs/engineering/工程约束.md；旧文档只用于发现候选，规则必须由当前代码、测试或配置重新证明。
• 6.8 每条工程规则使用 ENG-<AREA>-NNN，包含状态、适用范围、单一 MUST/MUST NOT、理由、最小正反例、机械检查或人工原因、例外条件、Owner、最后验证日期和更新触发条件。
• 6.9 DTO、Model、路由、迁移、注释等规则全部进入工程约束；不建立对应 Skill。能机械判断的规则链接现有检查器，不能判断的明确标记人工审查，不在本任务中为它们新造 Linter。

验证：

• AGENTS.md 不超过 150 行，所有链接有效。
• 不包含 GSD、OMX、旧 .planning、旧 OpenSpec 路径。
• 新 Codex 会话能够发现官方 OpenSpec Skills。
• ARCHITECTURE.md 中每个运行单元和模块入口都能在仓库定位，禁止依赖有验证命令或明确人工门禁。
• 每条工程约束都满足统一字段要求，且没有与 AGENTS、Specs 或外部契约重复的权威正文。

7. 从代码建立 As-Is Specs

主通道：Query / 只读分析；辅助通道：Infrastructure。 业务边界：描述现有完整用例，不迁移、不修改任何旧 Service、Domain、Application、Query 或 Handler。

• 7.1 从真实路由、Handler、Application/Service、Domain、Query、常量、迁移、配置和测试生成业务能力清单。
• 7.2 按可独立理解的业务能力分批创建 openspec/specs/<capability>/spec.md，避免按 Handler、Model、表或技术组件机械拆分。
• 7.3 每个 Requirement 使用可观察 SHALL，Scenario 使用 GIVEN/WHEN/THEN。
• 7.4 状态、权限、金额、失败、回调、重试和幂等行为按当前实现记录，包括 Bug。
• 7.5 队列、包名、函数名、GORM 标签等实现细节不得进入行为 Requirement。
• 7.6 死代码、不可达分支和仅存在于旧文档的行为不得进入 Spec。
• 7.7 每个能力由独立 Auditor 对照代码证据检查；无需用户逐条批准。
• 7.8 每批执行 OpenSpec 校验，通过后继续下一批。

建议批次，仅作为发现起点，最终以代码边界为准：

1. 认证、账号、组织与权限
2. 店铺、角色和数据范围
3. 卡、设备、资产与企业授权
4. 套餐、订购、激活与流量
5. 订单、支付、充值、钱包与退款
6. 佣金、提现与资金流水
7. 轮询、异步任务、通知与审计
8. 第三方回调与外部集成可观察行为

验证：

openspec validate --all

• 所有 Specs 格式有效。
• 每个 Capability 至少有一个执行其 Requirement 的 Scenario。
• 抽样从路由到持久化端到端追踪，Spec 与现有行为一致。
• Spec 不引用已删除旧文档。
• 受保护业务路径哈希未因生成 Spec 改变。

8. 建立最小机械门禁

架构通道：Infrastructure / 工程治理。 业务边界：只验证 Context 健康，不改变业务实现。

• 8.1 复用现有命令建立一个最小 Context 健康检查入口；不引入新依赖。
• 8.2 检查 OpenSpec、失效链接、禁止目录、GSD/OMX 残留和 .lh-harness Git 跟踪状态。
• 8.3 不在本任务中实现 DTO、Model、路由等新的定制 Linter；后续出现真实遗漏时独立立项。

验证： 健康检查在当前仓库通过；故意构造一个临时失效链接或禁止目录时能够失败，随后恢复。

9. 最终审计与收尾

架构通道：Infrastructure / 验证。 业务边界：只核对结果和证据。

• 9.1 Auditor 重新检查全部删除、保留和目标结构。
• 9.2 核对业务代码、迁移、测试、构建和部署配置未被本任务修改。
• 9.3 核对 GSD、OMX、.planning、旧 OpenSpec 和旧文档无残留。
• 9.4 核对所有外部接入资料已位于 docs/integrations/。
• 9.5 核对 OpenSpec Doctor、Validate 和 Context 健康检查通过。
• 9.6 输出删除清单、保留清单、移动映射、验证命令与字面结果。
• 9.7 重新打开并验证备份和恢复脚本。
• 9.8 删除本文件 CONTEXT_RESET_PLAN.md，确认 LongHorizon 临时状态未被 Git 跟踪。

8. As-Is 基线生成纪律

8.1 AI 自动决策

• 不要求用户逐条检查 Requirement。
• 同一请求在不同角色、状态或配置下结果不同，应记录为多个 Scenario，而不是选择“更合理”的一个。
• 测试与代码不一致时，先实际运行最小验证；能够复现的行为进入 Spec。
• 无法运行时，以实际可达代码和生效配置为准，并由 Auditor 检查调用链。
• AI 认为行为可能是 Bug 时仍照实记录，不增加价值判断。

8.2 只在以下情况请求用户输入

• 必须访问生产环境或真实第三方账户才能确认行为。
• 两条实际可达路径对同一输入产生冲突，且无法通过本地配置判断生效路径。
• 需要修改业务代码才能完成验证。
• 外部接入资料可能包含真实凭证或合规敏感内容。

除上述情况外，按最保守、最接近当前实现的判断继续，不逐文件询问。

9. 验收标准

全部条件同时满足才算完成：

1. command -v omx 无结果，系统和项目无 OMX 残留。
2. 用户级 GSD Skills、Agents、引擎与 Manifest 全部删除，重启 Codex 后不再显示 GSD。
3. .planning、.scratch、.sisyphus、旧 CONTEXT.md 和旧 OpenSpec 不存在。
4. docs/ 仅保留标准化的 integrations/、通用 Harness 最佳实践和从当前事实重建的 工程约束.md，没有旧业务资料。
5. 外部接入资料内容已保留、集中且无有效断链。
6. OpenSpec 使用执行时最新稳定版官方 spec-driven 初始化结果。
7. OpenSpec 配置不包含旧架构、测试比例、无效 Artifact Rules 或大段全局注入。
8. AGENTS.md 不超过 150 行，只承担导航和硬约束。
9. ARCHITECTURE.md 能从系统职责导航到运行单元、模块入口、依赖方向、关键数据流和验证命令。
10. 工程约束均有稳定 ID、范围、规则、证据/检查、例外和维护信息；规范型 Skills 已删除。
11. As-Is Specs 覆盖代码中发现的全部对外业务能力，并通过 openspec validate --all。
12. 当前 Bug 按现状记录，没有在本任务中被修正。
13. 业务代码、迁移、测试、构建和部署配置没有因本任务发生变化。
14. .lh-harness/ 未被 Git 跟踪，仓库不存在第二套计划或状态事实源。
15. 备份可解包，恢复脚本可运行。
16. 本文件在最终验证后删除。

10. 回滚

执行前在仓库外生成：

/tmp/context-reset-<timestamp>/
├── project-context.tar.gz
├── user-gsd.tar.gz
├── protected-files.sha256
├── git-status-before.bin
├── move-map.tsv
└── rollback.sh

rollback.sh 必须做到：

1. 验证备份 SHA-256。
2. 只恢复本任务删除或移动的 Context 和 GSD 文件。
3. 不覆盖任务开始前已存在的未提交业务修改。
4. 恢复外部资料原路径与 OpenSpec 旧结构。
5. 输出逐项恢复结果和退出码。

若任一受保护业务文件被本任务改动、备份无法恢复、外部资料丢失或 OpenSpec 初始化失败，立即停止后续任务并执行回滚。

11. 审计与公共能力决定

本任务只修改仓库 Context 与本机 Agent 工具链，不执行运行时业务用例：

• Audit Event：N/A，不产生系统业务操作。
• Domain Ledger：N/A，不修改金额、订单或状态事实。
• Integration Log：N/A，不调用外部服务。
• Outbox：N/A，不产生提交后可靠副作用。
• 数据库迁移：N/A。
• 业务架构迁移：N/A；明确不迁移任何旧 MVC/DDD 用例。

12. 决策来源

• OpenAI Harness Engineering：短 AGENTS 作为目录、仓库作为事实源、机械反馈闭环和持续清理熵。
• OpenSpec Overview / Writing Specs / Explore / Reviewing Changes：主 Specs 表达当前行为，Changes 表达拟议差异，Requirement 与 Scenario 必须可观察、可判定。
• AGENTS.md 实践资料：渐进披露，根文件只保存 Agent 无法自行发现且普遍适用的约束。
• 长任务资料：执行状态与独立审计可以持久化，但不得复制或改写唯一任务契约。