2.3 KiB
2.3 KiB
1. 重新确认基线与证据边界
- 1.1 解析当前主 Specs、
requirement-evidence.json和入口矩阵，确认待补 Requirement 键仍恰为 design.md 所列 36 条，且现有 evidence 没有过期键。 - 1.2 对每条待补 Requirement 静态追踪其路由、已注册任务或离线 CLI 至 Handler/Consumer、Application/Service/Query、状态/存储事实；缺少直接证明时停止，不写推测性证据。
- 1.3 为每条证据选择一个可重跑且只读的源码/脚本检查命令与确定性命中输出；不使用生产、外部渠道、数据库写入或已删除临时 smoke 结果。
2. 补齐 Requirement 证据记录
- 2.1 在
docs/verification/context-reset/requirement-evidence.json仅追加代理充值、开放接口、外部交互、审计归档、套餐历史、套餐激活与轮询类 Requirement 的直接证据行。 - 2.2 在同一文件仅追加实名策略、奇成迁移、零金额退款和店铺批量导入类 Requirement 的直接证据行，记录脚本/迁移事实而不虚构 HTTP 或 Asynq 调用链。
- 2.3 解析写入后的 JSON，确认 89 个唯一
capability::requirement键与主 Specs 双向一致，保留原有 53 行内容且无重复或过期键。
3. 同步入口能力矩阵
- 3.1 将 HTTP 可达的待补 Requirement 仅链接到已有路由行，将 Worker 行为仅链接到已有注册 async 行；不得新增、删除或重命名 HTTP/async 入口。
- 3.2 为奇成迁移和店铺导入的五条离线 Requirement 添加两个
cli入口行：scripts/migration/migrate_runtime.py与scripts/migration/import_shops.py，不影响 HTTP/async 入口集合比较。 - 3.3 解析矩阵并确认其 Requirement 链接集合与主 Specs 完全相同，HTTP 路由集合和 async 注册常量集合保持不变。
4. 验证与交付
- 4.1 运行只读集合核对，逐条复核新增 evidence 文件路径、符号和验证命令输出仍存在；对无直接证明的条目撤回并报告缺口。
- 4.2 运行
./scripts/context-health.sh，确认 Requirement 证据链、入口矩阵、OpenSpec 校验和既有生成确定性检查全部通过。 - 4.3 核对变更范围仅限两个验证 JSON 与本 Change 工件；不修改主 Specs、业务代码、迁移、测试体系或运行配置。