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 事实源

重置完成后的优先级：

```text
可复现运行结果 / 自动化测试
  > 实际可达代码与生效配置
  > 数据库迁移与 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. 目标结构

```text
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 的引用。

**验证：**

```bash
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 执行：

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

- [ ] 5.3 将 `openspec/config.yaml` 保持为最小配置：

```yaml
schema: spec-driven
```

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

**验证：**

```bash
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. 第三方回调与外部集成可观察行为

**验证：**

```bash
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. 回滚

执行前在仓库外生成：

```text
/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 无法自行发现且普遍适用的约束。
- 长任务资料：执行状态与独立审计可以持久化，但不得复制或改写唯一任务契约。