diff --git a/docs/EXECUTION_BOARD.md b/docs/EXECUTION_BOARD.md
index a48bd37b..b441d515 100644
--- a/docs/EXECUTION_BOARD.md
+++ b/docs/EXECUTION_BOARD.md
@@ -12,6 +12,10 @@
 - 上游直探分流证明：
   - DeepSeek 上游 `/chat/completions` = `HTTP 200`，因此 host 侧 502 是真实兼容性问题，不是单纯 key 失效。
   - MiniMax 上游 `/chat/completions` = `HTTP 403 insufficient_user_quota`，因此当前验证 key 本身不具备真实 completion 流量能力。
+- 2026-05-21 进一步缩圈结果：
+  - DeepSeek managed key 直打 fresh host `http://127.0.0.1:18097/v1/chat/completions` 仍稳定返回 `502`；但同一台 remote43 主机直接 `curl https://aitoken.quanfuli.cn/v1/chat/completions`（同一 upstream key、同一 payload）返回 `HTTP 200`，且 `Content-Type: text/event-stream`。
+  - fresh-host app 日志显示 DeepSeek group `5` 当前挂了 10 个 active account（IDs `14,15,16,17,19,20,23,25,26,28`），chat 请求会在这些重复 account 之间 failover，全部记为 `account_upstream_error 500/502` 后才落成 gateway `502`。
+  - MiniMax group `6` 当前挂了 6 个 active account（IDs `18,21,22,24,27,29`），`temp_unschedulable_reason` 都明确记录为 `insufficient_user_quota`；说明它的 completion 阻断已不是 CRM/host 路由问题，而是验证 key 配额不足。
 - 汇总证据：`artifacts/real-host-acceptance/20260521_064910_completion_smoke_calibration.md`
 - 调通细节与经验沉淀：`docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md`
 - 代码门禁与本地运行态已于 2026-05-21 再次独立复跑：`gofmt -l .`、`go vet ./...`、`go test ./... -count=1`、`go test -race ./... -count=1`、`go test -cover ./internal/... -count=1`、`go test ./tests/integration/... -count=1` 全通过；本机 CRM(18100) 的 `GET /healthz` / 带 token 的 `GET /api/hosts` = `200`，另起 fresh smoke 实例 `127.0.0.1:18101` 也成功返回 `GET /healthz = ok`、`GET /api/hosts = {"hosts":[]}`。
diff --git a/docs/PRODUCTION_CLOSURE_BOARD.md b/docs/PRODUCTION_CLOSURE_BOARD.md
index 526dde2b..6dbc7096 100644
--- a/docs/PRODUCTION_CLOSURE_BOARD.md
+++ b/docs/PRODUCTION_CLOSURE_BOARD.md
@@ -12,6 +12,10 @@
 - 上游直探分流证明：
   - DeepSeek 上游 `/chat/completions` = `HTTP 200`，host 侧 502 属于真实兼容性问题。
   - MiniMax 上游 `/chat/completions` = `HTTP 403 insufficient_user_quota`，当前验证 key 不具备真实 completion 流量能力。
+- 2026-05-21 进一步缩圈结果：
+  - DeepSeek managed key 直打 fresh host 仍稳定 `502`；但 remote43 主机上对同一 upstream key + 同一 payload 的直接 `curl` 返回 `HTTP 200`，且响应是 `Content-Type: text/event-stream`。这把阻断进一步收敛为“宿主 chat 上游兼容层”而非 CRM 导入失败。
+  - fresh-host app 日志显示 DeepSeek subscription group `5` 当前挂了 10 个 active duplicate accounts，host chat 会在这些 account 间持续 failover，全部报 `account_upstream_error 500/502` 后才返回 gateway `502`。
+  - MiniMax subscription group `6` 当前挂了 6 个 active duplicate accounts，但它们的 `temp_unschedulable_reason` 都已明确写成 `insufficient_user_quota`，因此该分支的主阻断仍是 key/quota，而不是 CRM 路由链路。
 - 汇总证据：`artifacts/real-host-acceptance/20260521_064910_completion_smoke_calibration.md`
 - 调通细节与经验沉淀：`docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md`
 - 代码/本地运行态门禁已于 2026-05-21 再次独立复跑：`gofmt -l .`、`go vet ./...`、`go test ./... -count=1`、`go test -race ./... -count=1`、`go test -cover ./internal/... -count=1`、`go test ./tests/integration/... -count=1` 全通过；并额外验证了本机 CRM(18100) `GET /healthz` / `GET /api/hosts` = `200`，以及 fresh smoke 实例 `127.0.0.1:18101` 可启动并返回 `GET /healthz = ok`、`GET /api/hosts = {"hosts":[]}`。
diff --git a/docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md b/docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md
index e62a32d2..e53f8e44 100644
--- a/docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md
+++ b/docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md
@@ -207,11 +207,46 @@
 - channel 是否同时具备 `model_mapping + model_pricing + restrict_models + billing_model_source=channel_mapped`
 - 是否误打到了旧 CRM 进程
 
-### 现象 C：`/v1/models` 已 200，但 `/v1/chat/completions` 返回 502
+### 现象 C：`/v1/models` 已 200，但 `/v1/chat/completions` 失败
 优先判断：
-- host 侧 provider 兼容性问题
-- 上游 provider key/quota 问题
-- 不要再把问题回退归因为 CRM 导入或 access closure
+- host provider 兼容性
+- 上游 key/quota
+- 不要先回退归因为 CRM 导入失败
+
+### 进一步缩圈：DeepSeek `chat/completions` 当前更像宿主兼容层问题，而不是 key 失效
+
+2026-05-21 新增的直接证据链：
+
+1. managed key 直打 fresh host 仍稳定失败
+   - `http://127.0.0.1:18097/v1/models` = `HTTP 200`
+   - `http://127.0.0.1:18097/v1/chat/completions` = `HTTP 502`
+   - 说明普通用户 / subscription / key / group 绑定链路不是这一步的主阻断
+
+2. 同一台 remote43 主机直打 upstream 反而成功
+   - 对 `https://aitoken.quanfuli.cn/v1/chat/completions`
+   - 使用同一 upstream key、同一 `deepseek-v4-flash` payload
+   - 返回 `HTTP 200`
+   - 但响应 `Content-Type` 是 `text/event-stream`
+
+3. fresh-host app 日志显示 host chat 会在一组重复 DeepSeek accounts 间 failover，全部记成 `account_upstream_error 500/502`
+   - 当前 group `5` 里有 10 个 active DeepSeek accounts：`14,15,16,17,19,20,23,25,26,28`
+   - 它们 `credentials.api_key/base_url/model_mapping` 相同
+   - 请求并不是命中一个固定坏 account，而是在重复 account 集合中轮流失败
+
+当前最合理的解释：
+- DeepSeek 这条 completion 阻断已经缩到“宿主 chat 上游兼容/解析层”
+- 不是 CRM 没把模型、channel、subscription、managed key 准备好
+- 重复 account 不是唯一根因，但会把一次失败放大成整组 failover 噪音，增加生产不稳定性
+
+### 进一步缩圈：MiniMax 当前是 quota 阻断，不是 CRM 路由阻断
+
+1. managed key 视角 `/v1/models` 已 200
+2. upstream 直探 `/chat/completions` = `403 insufficient_user_quota`
+3. fresh-host group `6` 内 6 个 active MiniMax accounts 的 `temp_unschedulable_reason` 都明确记录了 `insufficient_user_quota`
+
+因此：
+- MiniMax 当前要解的是“换可用 key / 补额度”
+- 不应继续把它归因为 CRM import/access 逻辑失败
 
 ## 当前建议固化到后续文档/脚本的规则