supply-intelligence/tech/PRODUCTION_LAUNCH_CLOSURE_BOARD_2026-05-07.md

Supply-Intelligence 生产上线收敛任务板（2026-05-07）

状态：当前有效 目标：把 supply-intelligence 从“最小闭环骨架”推进到“可生产上线判定” 仓库：/home/long/project/立交桥/projects/supply-intelligence 事实基线：本地 go test ./... 通过；当前分支 main；最新提交 afdbea6 feat: bootstrap supply intelligence baseline

0. 当前门控结论

当前结论：REQUEST_CHANGES

原因不是项目不可运行，而是“可运行骨架”与“真源要求的生产闭环”仍存在关键差距，不能宣称可上线。

1. 事实基线

1.1 已验证事实

• 仓库存在真实代码、测试、迁移、文档：.git、go.mod、internal/、migrations/、tech/
• 本地执行 cd '/home/long/project/立交桥/projects/supply-intelligence' && go test ./... 通过
• 已存在模块：probe、discovery、admission、publish、gatewayconsumer、httpapi、repository
• 已存在 HTTP 路由：
  • /internal/supply-intelligence/accounts/{account_id}/routing-state
  • /internal/supply-intelligence/discovery/candidates
  • /internal/supply-intelligence/admission/run
  • /internal/supply-intelligence/gateway/package-changes
  • /internal/supply-intelligence/gateway/package-changes/{event_id}/ack
  • /internal/supply-intelligence/gateway/consume-once

1.2 已确认关键差距

• internal/domain/types.go 仍保留旧 candidate 状态：pending_admission、admitted
• internal/httpapi/server.go 的状态解析仍接受旧状态
• internal/probe/state_machine.go 仍是 suspended + explicit_failure -> disabled 的单步逻辑，未体现“3 次连续 explicit failure 才 disabled”
• internal/publish/service.go 已完成基础 publish event 持久化与 pending 状态写入，但仍未覆盖 draft -> active 与 candidate test_passed -> published 的完整事务联动
• GET /internal/supply-intelligence/models/{platform}/{model}/admission-state 未接入真实入口
• gateway consumer 已有最小 poll/apply/ack 骨架，但仍需补足生产门禁证据与发布状态联动

1.3 事实更新（2026-05-07 复核）

• 本地执行 cd '/home/long/project/立交桥/projects/supply-intelligence' && go test ./... 通过
• 代码中已存在 publish/service 与 repository 的事件落库、ack、gateway snapshot 基础路径
• 当前首个阻塞不再是“publish 事件未持久化”，而是“发布事务与 admission-state / 状态机联动未收口”
• 因此首个阻塞项应下沉为 B2/B3/B4 的联动闭环，而不是单纯 event append

2. 最短闭环路径

1. 先修 Phase A：probe/account 状态机与 routing-state 真正符合真源
2. 再修 Phase B/C：candidate 状态机与 admission/draft 闭环一致
3. 再修 Phase D：真实发布事务 + admission-state API + gateway sync 联动
4. 再做全链路 QA 复核与上线证据收敛

3. 任务板

A. Design

A1. 收敛状态机真源到代码级约束

• Owner：TechLead
• 交付物：状态机收敛设计说明
• 范围：
  • probe 账号状态迁移规则
  • candidate 生命周期合法状态与迁移
  • publish/gateway_sync 的语义边界
• 完成标准：
  • 明确删除 pending_admission / admitted
  • 明确 published != applied
  • 明确 suspended -> disabled 的窗口规则
• 验证方式：设计文档与现有代码差异清单完整
• 依赖：无
• 状态：pending

A2. 定义发布事务与 admission-state 读取契约

• Owner：TechLead
• 交付物：发布事务与 /models/{platform}/{model}/admission-state 契约说明
• 完成标准：
  • 明确 package、candidate、gateway_sync 三者联动字段
  • 明确 handler / service / repository 落点
• 验证方式：文件级任务拆解完成
• 依赖：A1
• 状态：pending

B. Implementation

B1. 修复 probe 状态机实现

• Owner：Engineer
• 交付物：internal/probe/*、internal/domain/*、相关 repo/test 修正
• 完成标准：
  • inconclusive 不触发惩罚性迁移
  • disabled 只在满足真源规则时发生
  • 补齐主路径与失败路径测试
• 验证方式：go test ./internal/probe ./internal/app ./internal/httpapi
• 依赖：A1
• 状态：pending

B2. 清理 candidate 旧状态并对齐 admission 流转

• Owner：Engineer
• 交付物：internal/domain/types.go、internal/discovery/*、internal/admission/*、internal/httpapi/server.go、相关测试
• 完成标准：
  • 删除 pending_admission / admitted
  • discovered/testing/test_passed/test_failed/retry_pending/ignored/published/deprecated/closed 全链路一致
  • discovery / admission / HTTP 参数校验统一
• 验证方式：go test ./internal/discovery ./internal/admission ./internal/httpapi
• 依赖：A1
• 状态：pending

B3. 实现真实 publish 事务

• Owner：Engineer
• 交付物：internal/publish/*、internal/repository/*、internal/app/*、相关测试
• 完成标准：
  • draft -> active
  • candidate test_passed -> published
  • event append 作为发布事务的一部分，不再只是独立记录器
• 验证方式：go test ./internal/publish ./internal/app ./internal/repository
• 依赖：A2
• 状态：pending

B4. 接入 admission-state API

• Owner：Engineer
• 交付物：internal/httpapi/server.go、internal/repository/*、相关测试
• 完成标准：
  • 存在真实读取入口 /internal/supply-intelligence/models/{platform}/{model}/admission-state
  • 返回 candidate/package/gateway_sync 组合态
• 验证方式：go test ./internal/httpapi ./internal/repository
• 依赖：A2, B2, B3
• 状态：pending

C. Verification

C1. QA 复核 probe/account 主链路

• Owner：QA
• 交付物：结构化审查报告
• 完成标准：
  • 验证 definition -> assembly -> call -> entry
  • 验证状态机与真源一致
• 验证方式：代码抽检 + 运行 targeted tests
• 依赖：B1
• 状态：pending

C2. QA 复核 candidate/admission/publish 主链路

• Owner：QA
• 交付物：结构化审查报告
• 完成标准：
  • 验证 candidate 状态无旧口径残留
  • 验证 publish 事务不是“只写 event”
  • 验证 published != applied
• 验证方式：代码抽检 + 运行 targeted tests
• 依赖：B2, B3, B4
• 状态：pending

C3. 端到端最小闭环验证

• Owner：QA
• 交付物：最小闭环验证记录
• 完成标准：
  • candidate -> test_passed -> publish -> package-changes -> ack
  • admission-state 可反映 pending/applied/failed
• 验证方式：go test ./... + 必要的集成命令/测试
• 依赖：C2
• 状态：pending

D. Release Evidence

D1. 上线证据包整理

• Owner：XL
• 交付物：上线前结论摘要
• 完成标准：
  • 列清已完成范围
  • 列清剩余非阻塞项
  • 列清不可宣称项
• 验证方式：对照 QA 结果与最新测试输出
• 依赖：C1, C2, C3
• 状态：pending

4. 明确禁止的错误结论

• 不得把 go test ./... 通过等同于“可生产上线”
• 不得把 published 等同于 gateway applied
• 不得把仅存在 handler/route 等同于真实主链路完成
• 不得把 event append 记录器等同于真实发布事务

5. 当前推荐执行顺序

1. TechLead 先出状态机/发布事务收敛设计
2. Engineer 先做 B1 + B2
3. Engineer 再做 B3 + B4
4. QA 做 C1/C2/C3
5. XL 汇总 D1 并给出“可上线/不可上线”结论