diff --git a/review/REMEDIATION_COMPLETION_CONFIRMATION_2026-04-17.md b/review/REMEDIATION_COMPLETION_CONFIRMATION_2026-04-17.md new file mode 100644 index 00000000..1b5ad6fa --- /dev/null +++ b/review/REMEDIATION_COMPLETION_CONFIRMATION_2026-04-17.md @@ -0,0 +1,132 @@ +# 整改完成确认单 + +- 项目：立交桥 +- 路径：`/home/long/project/立交桥` +- 日期：2026-04-17 +- 依据： + - `review/REPORT_CORRECTION_2026-04-17.md` + - `docs/plans/2026-04-17-remediation-execution-checklist.md` + +--- + +## 一、结论 + +本轮整改执行清单已经全部完成。 + +当前结论分三层： + +1. 纠偏报告中确认的阻塞性代码问题，已经全部修复。 +2. 当前仓库已经恢复到“可验证、可回归、可继续交付”的状态。 +3. 仍然存在的后续事项，不应再归类为“本轮未修复缺陷”，而应拆分为： + - 上线条件 + - 长期治理项 + +--- + +## 二、已修复 + +以下问题已经在本轮整改中完成修复，并通过当前仓库验证链确认： + +### 2.1 构建与测试链路 + +1. `supply-api` 的 HKDF 编译阻塞已修复，整仓 `go test -count=1 ./...` 已恢复。 +2. `gateway` 的 `BuildMux` 签名失配和错误脱敏断言失配已修复。 +3. `platform-token-runtime` 的中间件签名失配和 `audit-events` 鉴权测试失配已修复。 +4. `scripts/ci/repo_integrity_check.sh` 已升级为可信基线，默认使用无缓存测试，并纳入 `supply-api` 仓储集成。 + +### 2.2 运行时能力闭环 + +1. `platform-token-runtime` 已引入统一 store 抽象，并落地 PostgreSQL-backed 的最小 runtime / audit store。 +2. `supply-api` 默认补偿执行器已改为 fail-closed，不再出现“假成功”。 +3. `supply-api` 的 IAM 路由已经收敛为显式能力：默认关闭，满足条件才挂载。 +4. `supply-api` 的提现能力已经收敛为显式 readiness 门禁：SMS 未就绪时保持关闭并返回明确错误。 + +### 2.3 配置与对外行为 + +1. `gateway` 在生产环境下已禁止默认密钥与默认 `*` CORS。 +2. `gateway /v1/models` 已改为基于已注册 provider 动态聚合输出。 +3. `gateway` 已明确高级路由策略目前不进入主启动链路。 + +### 2.4 SQL 与文档边界 + +1. `supply-api/sql/postgresql/supply_core_schema_v2.sql` 已按当前真实领域状态补齐 `CHECK` 约束。 +2. `sql/postgresql/platform_core_schema_v1.sql`、`sql/postgresql/token_runtime_schema_v1.sql` 的服务边界已写清。 +3. `ClientIP` / `SourceIP` 的统一方向已经固化为规范，不再作为阻塞缺陷处理。 + +--- + +## 三、属于上线条件 + +以下事项不是“代码未修复”，而是正式上线时必须满足的环境或接入条件： + +### 3.1 `supply-api` 提现能力 + +1. 只有 `settlement.withdraw_enabled=true` 且 SMS 配置齐备，并实际注入真实 `SMSVerifier` 时，提现才会开放。 +2. 若 SMS 未就绪，系统会继续保持关闭态并返回 `SMS is not ready`。 + +### 3.2 `gateway` 生产配置 + +1. 生产环境必须显式提供 `PASSWORD_ENCRYPTION_KEY`。 +2. 生产环境必须显式提供 `GATEWAY_CORS_ALLOW_ORIGINS`。 +3. 这类要求是故意设计的 fail-closed 机制，不属于缺陷残留。 + +### 3.3 `platform-token-runtime` 部署条件 + +1. PostgreSQL-backed runtime 已经具备，但正式部署仍需要真实数据库实例。 +2. 正式部署仍需要执行对应 schema 初始化。 +3. 正式部署仍需要正确提供数据库连接环境变量与运行时装配。 + +--- + +## 四、属于长期治理项 + +以下事项真实存在，但不应继续与“本轮整改未完成”混为一谈： + +### 4.1 命名一致性 + +1. 仓库中仍存在历史存量 `ClientIP` / `SourceIP` 并存。 +2. 当前规则已经明确： + - HTTP / middleware 局部上下文允许保留 `ClientIP` + - 审计 / 持久化 / 对外字段统一 `SourceIP` +3. 后续如果要做全仓统一，应单独作为维护性重构推进。 + +### 4.2 测试层级差异 + +1. `supply-api` 的 e2e 仍以 HTTP 流程回归为主。 +2. 它不能等价为真实短信、消息总线、第三方支付等外部依赖已全部联通。 +3. 这属于测试覆盖层级边界，不是当前代码断裂。 + +### 4.3 实验性能力 + +1. `gateway` 中的 `cost_based`、`cost_aware`、`fallback` 仍属于实验性模块。 +2. 当前文档已明确它们未接入主启动链路。 +3. 若后续要进入主链路，应单独立项、补设计、补验证，而不是视为“本轮漏修”。 + +### 4.4 审查产物治理 + +1. 2026-04-16 原始审查报告仍保留在仓库中。 +2. 这些报告可作为历史输入，但不应再直接作为当前状态依据。 +3. 当前状态判断应以以下两份文档为准： + - `review/REPORT_CORRECTION_2026-04-17.md` + - `review/REMEDIATION_COMPLETION_CONFIRMATION_2026-04-17.md` + +--- + +## 五、最终验证 + +本轮整改完成后，已实际通过以下验证： + +1. `cd gateway && go test -count=1 ./...` +2. `cd platform-token-runtime && go test -count=1 ./...` +3. `cd supply-api && go test -count=1 ./...` +4. `cd supply-api && bash scripts/run_integration_tests.sh ./internal/repository` +5. `bash scripts/ci/repo_integrity_check.sh` +6. `git diff --check` + +--- + +## 六、确认结论 + +如果只保留一句话，当前最准确的表述是： + +**整改执行清单已经全部完成；纠偏报告中确认的阻塞性代码问题已经全部修复；剩余事项属于上线条件或长期治理项，不再属于本轮未完成缺陷。** diff --git a/review/REPORT_CORRECTION_2026-04-17.md b/review/REPORT_CORRECTION_2026-04-17.md index 0e5977ec..0cec6337 100644 --- a/review/REPORT_CORRECTION_2026-04-17.md +++ b/review/REPORT_CORRECTION_2026-04-17.md @@ -48,32 +48,42 @@ 更准确的结论是： -1. 仓库当前仍然**不可作为生产就绪版本判断为通过**。 -2. 主要原因不是旧报告列出的全部 P0 都还存在，而是： +1. 就 2026-04-17 纠偏启动时的代码快照而言，仓库**不可作为生产就绪版本判断为通过**。 +2. 启动时的主要原因不是旧报告列出的全部 P0 都还存在，而是： - 三块核心服务里有两块测试已经和代码失配 - `supply-api` 在当前工具链下存在编译阻塞 - `platform-token-runtime` 仍然没有仓库内可直接上线的持久化实现 - `supply-api` 补偿、IAM 接入等能力仍未闭环 -3. SQL 报告相对可信，Python / framework / architecture 类报告噪音较大，混入了竞品与归档目录，不能直接映射到核心项目完成度。 +3. 当前分支经过整改后，阻塞性代码问题已经移除；剩余事项需要按“上线条件”和“长期治理项”继续管理，而不是继续归类为本轮缺陷。 +4. SQL 报告相对可信，Python / framework / architecture 类报告噪音较大，混入了竞品与归档目录，不能直接映射到核心项目完成度。 ### 2.1 执行更新（2026-04-17） -本纠偏报告形成后，整改执行清单中的 `Task 1` 到 `Task 12` 已经完成并分别提交。当前状态与本报告前文提到的“初始阻塞项”已经不同： +本纠偏报告形成后，整改执行清单中的 `Task 1` 到 `Task 13` 已经完成并分别提交。当前状态与本报告前文提到的“初始阻塞项”已经不同： 1. `supply-api` 编译阻塞已修复，整仓 `go test -count=1 ./...` 已恢复 2. `gateway` 与 `platform-token-runtime` 的测试失配已修复，当前无缓存回归已恢复 3. `platform-token-runtime` 已具备 PostgreSQL-backed 的最小 runtime / audit store 4. `supply-api` 的补偿执行器、IAM 显式挂载、提现 / SMS readiness 门禁已经收口 5. `gateway` 的默认密钥 / 默认 CORS 已改为生产态 fail-closed，`/v1/models` 也已切到真实 provider 聚合输出 +6. SQL 基线边界、状态 `CHECK` 约束与 `ClientIP` / `SourceIP` 的统一方向已经收口到仓库文档与 DDL +7. 最终验证已经通过： + - 三个核心服务 `go test -count=1 ./...` + - `supply-api` 仓储集成基线 + - `scripts/ci/repo_integrity_check.sh` + - `git diff --check` 因此，阅读本报告时应区分： 1. 第三到第五章记录的是“纠偏启动时的真实问题” -2. 第七章给出的是“执行更新后的剩余治理项” +2. 第七章给出的是“执行收口后的当前分类结果” --- -## 三、已证实 +## 三、已证实（纠偏启动时） + +以下小节记录的是 2026-04-17 启动纠偏时已经被代码和命令直接证实的问题。 +其中已经纳入整改执行清单并完成的条目，不再代表当前分支仍然存在同一缺陷。 ### 3.1 P0：`supply-api` 当前无法通过 `go test -count=1 ./...` @@ -414,7 +424,10 @@ --- -## 五、漏报 +## 五、漏报（纠偏启动时） + +以下小节记录的是旧报告在纠偏启动时漏掉的真实问题。 +这些条目里已经完成整改的部分，当前应视为“已修复并经过验证”，而不是“仍未解决”。 ### 5.1 P0：旧报告没有识别“无缓存测试失败” @@ -525,28 +538,30 @@ --- -## 七、执行更新后的剩余优先级 +## 七、执行收口后的当前状态 -### 已完成（2026-04-17） +### 7.1 本轮整改结果 -1. `supply-api` 编译恢复，`go test -count=1 ./...` 已通过 -2. `gateway` / `platform-token-runtime` 无缓存测试链路已恢复 -3. `repo_integrity_check.sh` 已切到可信基线 -4. `platform-token-runtime` 最小 PostgreSQL 持久化已落地 -5. `supply-api` 补偿执行器、IAM、提现 / SMS readiness 已收口 -6. `gateway` 默认密钥 / 默认 CORS 已收紧，`/v1/models` 已改为动态输出 +1. 整改执行清单中的 13 个任务已经全部完成。 +2. 本轮纠偏识别出的阻塞性代码问题已经处理并通过验证。 +3. 当前仓库中不再保留“执行清单未完成项”。 -### 剩余项 +### 7.2 后续事项分类 -#### P2 +以下事项仍然存在，但它们不再属于“本轮未修复缺陷”： -1. 收敛 SQL 基线边界： - - 明确 platform / supply / token-runtime 三套 DDL 的服务边界 - - 把历史迁移脚本和 fresh setup 基线分开说明 -2. 用当前真实领域状态集合补齐 `supply_core_schema_v2.sql` 的 `CHECK` -3. 将 `ClientIP` / `SourceIP` 的统一方向固化为规范： - - 审计 / 持久化域统一 `SourceIP` - - 入口请求局部上下文允许保留 `ClientIP` +#### 上线条件 + +1. `supply-api` 提现能力仍然要求真实 SMS 配置和真实 `SMSVerifier`，否则继续保持关闭态。 +2. `gateway` 在生产环境仍然要求显式提供 `PASSWORD_ENCRYPTION_KEY` 与 `GATEWAY_CORS_ALLOW_ORIGINS`。 +3. `platform-token-runtime` 的 PostgreSQL-backed runtime 已落地，但正式部署仍需要真实数据库、schema 初始化和环境变量装配。 + +#### 长期治理项 + +1. `ClientIP` / `SourceIP` 的历史存量命名未做全仓机械替换；当前已先固化统一方向。 +2. `supply-api` 的 e2e 仍以 HTTP 流程回归为主，不等价于真实外部依赖全部闭环。 +3. `gateway` 的 `cost_based` / `cost_aware` / `fallback` 仍属于实验性模块，后续如要进入主链路，应单独立项。 +4. 2026-04-16 原始审查报告仍然保留在仓库中，但后续判断应以本纠偏版和整改完成确认单为准。 --- @@ -556,6 +571,6 @@ 1. **部分真实，但不能直接信。** 2. **最容易误导的是旧报告里的严重问题列表。** -3. **当前最真实的阻塞项不是那些已过时的安全结论，而是构建/测试断裂、持久化缺失和能力未闭环。** +3. **本轮整改已经消除了当前分支上的阻塞性代码缺陷；剩余事项应按“上线条件”和“长期治理项”分别管理。** -因此，后续所有治理和排期建议都应以本纠偏版为准，而不是继续直接引用 2026-04-16 的原始报告。 +因此，后续所有治理和排期建议都应以本纠偏版与整改完成确认单为准，而不是继续直接引用 2026-04-16 的原始报告。