docs(review): finalize correction closure and completion confirmation
This commit is contained in:
Your Name
132
review/REMEDIATION_COMPLETION_CONFIRMATION_2026-04-17.md
Normal file
132
review/REMEDIATION_COMPLETION_CONFIRMATION_2026-04-17.md
Normal file
@@ -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`
|
||||
|
||||
---
|
||||
|
||||
## 六、确认结论
|
||||
|
||||
如果只保留一句话，当前最准确的表述是：
|
||||
|
||||
**整改执行清单已经全部完成；纠偏报告中确认的阻塞性代码问题已经全部修复；剩余事项属于上线条件或长期治理项，不再属于本轮未完成缺陷。**
|
||||
@@ -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 的原始报告。
|
||||
|
||||
Reference in New Issue
Block a user