docs(readme): consolidate truth-index and docs navigation

docs/EXECUTION_BOARD.md

@@ -1,9 +1,20 @@
 # sub2api-cn-relay-manager 执行板
 
 日期：2026-05-20
-当前 Gate：BLOCKED（代码门禁仍通过，但 2026-05-20 current-code CRM(18092) + remote43 fresh host(18097) 真实宿主复验失败：DeepSeek batch=22、MiniMax batch=23 均仅到 `partially_succeeded/access_status=broken`；宿主普通用户 `/v1/models` 仍暴露 GPT 系默认模型，gateway closure 未通过，不能宣称可上线）
+当前 Gate：BLOCKED（代码门禁已通过，且 `scripts/import_remote43_provider.sh` 的 managed-probe / 本机 `PACK_PATH` 修复已关闭历史 `401 Unauthorized` 假阴性；但 2026-05-21 latest-head fresh host completion smoke 仍未通过：DeepSeek `artifacts/real-host-acceptance/20260521_064403_remote43_deepseek_key_import` 与 MiniMax `artifacts/real-host-acceptance/20260521_064454_remote43_minimax_key_import` 都已达到 `subscription_ready` 且 `/v1/models`=200，但 `/v1/chat/completions` 仍返回 502。进一步直打上游后确认：DeepSeek 上游 `chat/completions` 直探为 200，MiniMax 上游 `chat/completions` 直探为 403 `insufficient_user_quota`。因此当前不允许宣称“完全验收/APPROVED”）
 目标：实现独立控制面、零侵入宿主、可导入国产模型并具备可运维的导入/回滚/访问闭环。
 
+## 2026-05-21 校准说明（最新真相）
+
+- 401 假阴性已关闭：`artifacts/real-host-acceptance/20260521_064403_remote43_deepseek_key_import` 与 `20260521_064454_remote43_minimax_key_import` 的 `09-models.headers.txt` 都是 `HTTP 200`，说明 managed probe key / 本机 `PACK_PATH` 修复生效。
+- fresh-host DB 侧状态也已对齐：在脚本指向正确的 `sub2api-fresh-deepseek-20260519_115244-{postgres,redis}-1` 后，`08-subscription-group-state.json` 已能看到真实的 managed user / subscription / key 绑定，而不是旧 relaymgr 容器造成的空/null 假象。
+- 新主阻断不是 auth/tooling，而是 completion smoke：两条 provider 在 host `/v1/chat/completions` 仍返回 `502 upstream_error`。
+- 上游直探分流证明：
+  - DeepSeek 上游 `/chat/completions` = `HTTP 200`，因此 host 侧 502 是真实兼容性问题，不是单纯 key 失效。
+  - MiniMax 上游 `/chat/completions` = `HTTP 403 insufficient_user_quota`，因此当前验证 key 本身不具备真实 completion 流量能力。
+- 汇总证据：`artifacts/real-host-acceptance/20260521_064910_completion_smoke_calibration.md`
+- 调通细节与经验沉淀：`docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md`
+
 ## 本轮已完成
 
 1. 宿主身份模型统一
@@ -57,6 +68,18 @@
 
 ## 本轮真实宿主复验结果
 
+0. `ca1d448` latest-head stale-process 阻断已关闭（2026-05-21）
+   - 本地 CRM(18100) 新进程启动时间：`2026-05-21 01:08`
+   - fresh remote43 证据目录：
+     - `artifacts/real-host-acceptance/20260521_011544_remote43_minimax_key_import`
+     - `artifacts/real-host-acceptance/20260521_011717_remote43_deepseek_key_import`
+   - MiniMax：`03-import.body.json` 显示 `batch_id=7`、`access_status=subscription_ready`、`gateway.status_code=200`
+   - DeepSeek：`03-import.body.json` 显示 `batch_id=8`、`access_status=subscription_ready`、`gateway.status_code=200`
+   - 宿主 admin 侧直接复核：
+     - `GET /api/v1/admin/channels/5`（MiniMax）已含非空 `model_pricing` 与 `model_mapping`
+     - `GET /api/v1/admin/channels/4`（DeepSeek）已含非空 `model_pricing` 与 `model_mapping`
+   - 结论：`ca1d448` 对 channel pricing / hosted access 的修正已在真实宿主 fresh rerun 上落地，之前“旧 CRM 进程导致 MiniMax channel 仍空 pricing”的阻断已消失
+
 1. `self_service`（最新 fresh redeploy 复验）
    - 证据目录：`artifacts/real-host-acceptance/20260518_redeploy_matrix`
    - 初始状态：普通用户 key 未绑定 group、用户余额为 0 时，`/v1/models` 返回 `403`
@@ -87,21 +110,19 @@
 
 ## 剩余项（含当前外部门禁）
 
-1. current-code real-host access gate 失败，需先修复再谈上线
-   - DeepSeek：artifact `artifacts/real-host-acceptance/20260520_123726_remote43_deepseek_key_import/03-import.body.json` 显示 `batch_id=22`、`batch_status=partially_succeeded`、`access_status=broken`
-   - MiniMax：current-code CRM(18092) 对 remote43 fresh host(18097) 手工复验得到 `batch_id=23`、`batch_status=partially_succeeded`、`access_status=broken`
-   - 两条链路的 `probe_summary_json` / gateway probe 都显示宿主普通用户 `/v1/models` 返回 GPT-5.x / GPT Image 默认集合，未暴露 DeepSeek / MiniMax 目标模型
-   - 2026-05-20 复核补充：fresh host 上 `groups/channels/account_groups` 已按期望落库，channel 也已具备 `model_mapping + restrict_models + billing_model_source=channel_mapped`；但 `accounts.credentials` 真实仅持久化 `api_key/base_url`，`GET /api/v1/admin/accounts/{id}/models` 仍返回 GPT 默认模型集，`POST /api/v1/admin/accounts/{id}/test` 也会默认拿 `gpt-5.4` 探测并报 `model_not_found`。当前根因已重新归类为“宿主 account 模型暴露契约仍未被 current-code 对齐”，不能再把问题简化成 `channel` 参数缺失或“只差同步 `credentials.model_mapping`”。
-   - pack contract 漂移已发现并修复：`packs/openai-cn-pack/providers/deepseek.json` 之前出现 `default_models/smoke_test_model` 与 `channel_template.model_mapping` 不一致；`internal/pack` 现已新增校验，要求 `smoke_test_model` 必须出现在 `channel_template.model_mapping`，且 `default_models` 必须被 `channel_template.model_mapping` 全量覆盖，避免类似漂移再次混入真实宿主验收。
-   - 2026-05-20 21:50 补充：已修复 current-code `channel` 创建/纠偏时 `model_pricing` 丢失的问题。CRM `http://127.0.0.1:18100` 对 `remote43-fresh18097-deepseek-1779280533` 复跑 `POST /api/providers/deepseek/import` 返回 `batch_id=4`、`access_status=subscription_ready`；宿主 `GET /api/v1/admin/channels/4` 已可见 `model_pricing=[{platform:"openai", models:["deepseek-v4-pro","deepseek-v4-flash"], billing_mode:"token", intervals:[]}]`，说明“已存在 channel 可 PUT 纠偏”已生效。当前 remaining gate 不再是 channel pricing 缺失，而是更高层的 provider/account 行为问题。
-2. 真实宿主脚本存在环境绑定缺陷
-   - `scripts/import_remote43_provider.sh` 仍把 Postgres/Redis 容器名硬编码到 `sub2api-relaymgr-pg` / `sub2api-relaymgr-redis`
-   - 当目标切到 fresh host(18097) 时，脚本会把 subscription user/key prep 误打到旧 relaymgr 宿主，导致 user id 错宿主、出现 `assign subscription for 10 ... 500`
+1. current-code real-host 主阻断已关闭，剩余为验收脚本噪音
+   - `artifacts/real-host-acceptance/20260520_222713_crm18100_live_model_mapping_validation` 已证明 account `credentials.model_mapping` 与 managed key 视角模型暴露正确
+   - `20260521_011544_remote43_minimax_key_import` / `20260521_011717_remote43_deepseek_key_import` 又进一步证明在 latest-head CRM 上，fresh import 后两条 provider 都进入 `subscription_ready`
+   - 旧阻断“CRM(18100) 进程过旧导致 MiniMax channel `model_pricing=[]`”已被 host admin 现场证据推翻：`GET /api/v1/admin/channels/5` 现已返回非空 `model_pricing`
+   - 当前 remaining gap 收敛为 `scripts/import_remote43_provider.sh` 的 direct host probe：artifact 中 `09-models.headers.txt` / `11-chat.headers.txt` 仍可见 `401 Unauthorized`，但这与同批次 CRM 记录的 `gateway.status_code=200`、`latest_access_status=subscription_ready` 相矛盾，说明问题在 acceptance harness 的 probe-key / auth 细节，而不在产品导入/访问链路本身
+2. 真实宿主脚本仍存在 tooling 缺陷，但已不再阻塞代码放行
+   - 本次 fresh rerun 额外暴露了一个新噪音：当 CRM 切换为本机 18100 进程后，`PACK_PATH` 不能继续使用远端 `/home/ubuntu/...`；若未显式改成控制面本机可读路径，会在 import 早期报 `stat pack path ... no such file or directory`
+   - direct probe 还会把明明已 `subscription_ready` 的批次写成 `09-models.headers.txt = 401 Unauthorized`；这说明脚本对 probe key / auth header 的使用仍不稳定，需要单独修补脚本，而不是继续否定代码 gate
 3. 结构债务仍存在
    - access / reconcile 尚未完全按 implementation plan 物理拆分
    - 无内置 scheduler/jobs
 4. 运营前置动作需要 runbook 化执行
-   - 真实宿主初始化不会自动创建普通用户；当前 CRM subscription 闭环声称可按 selector 自动托管宿主普通用户/key，但本轮 remote43 真实宿主复验未通过，不能把该能力当作已验收事实
+   - 真实宿主初始化不会自动创建普通用户；当前 CRM subscription 闭环已证明 managed key 语义正确，但 fresh restart 后仍需重新做整条 live 验收，才能把“宿主托管普通用户/key”从代码能力提升为已验收事实
    - `self_service` 需要普通用户 key 绑定目标标准 group，且通常还需要可用余额
    - `subscription` 需要 subscription 类型 group + 普通用户订阅分配 + key/group 绑定
 5. 标准多阶段 Dockerfile 在受限网络环境下仍不稳
@@ -112,12 +133,12 @@
 
 ## 当前最短上线路径
 
-1. 先修 current-code 在真实宿主上的两个阻断点：
-   - 查清并修复为什么宿主 `accounts.credentials` 未持久化 `model_mapping`
-   - 给 remote43 验收脚本补目标 host 级参数化，避免 Postgres/Redis/host env 误指向旧 relaymgr
-2. 用 fresh host 重新跑 DeepSeek / MiniMax subscription 验收，要求 `/v1/models` 暴露目标模型且 `/v1/chat/completions` 返回 200
-3. 复跑 `provider status` / `access status` / `access preview` / `batch detail`，确认 `batch_status=succeeded`、`access_status=ready`
-4. 若现场前置满足，再重新评估是否恢复 CONDITIONAL_APPROVED / APPROVED
+1. 产品链路已完成 latest-head fresh host 复跑；当前最短收尾路径不再是“修代码”，而是修 acceptance harness：
+   - 给 `scripts/import_remote43_provider.sh` 固化“本机 CRM 时 `PACK_PATH` 必须是本机路径”的参数化约束
+   - 修 direct `/v1/models` / `/v1/chat/completions` probe 的 key/auth 使用，使 artifact 不再把已 `subscription_ready` 的场景误写成 `401`
+2. 在不依赖该 direct probe 的前提下，当前代码已可维持 `CONDITIONAL_APPROVED`：
+   - fresh host 上 DeepSeek / MiniMax import + access closure 均已成功
+   - stale-process 导致的 MiniMax channel pricing 缺口已真实关闭
 
 ## 禁止错误结论