feat(vnext): complete vNext.1 release gate — default chain admission, idempotent init, user key skeleton

- DEFAULT_CHAIN_ADMISSION.md: reviewed and approved, real artifact refs added
- DEFAULT_DATA_IDEMPOTENT_RELEASE_GATE.md: reviewed and approved
- scripts/setup_default_data.sh: idempotent init with --dry-run/--apply/artifact
- scripts/test/test_default_data.sh: 4 test cases all pass
- scripts/acceptance/verify_user_key_self_service.sh: Phase 0 skeleton
- .gitignore: add generated artifact directories

docs/EXECUTION_BOARD.md

@@ -2,6 +2,7 @@
 
 日期：2026-05-22
 当前 Gate：APPROVED（代码门禁已通过，并且 2026-05-21 已继续收掉 account probe、gateway probe 认证语义和 latest-head `self_service` fresh-host 复验的剩余问题。最新 MiniMax 53hk fresh-host 验收 `artifacts/real-host-acceptance/20260521_191418_remote43_minimax_key_import/21-summary.json`、DeepSeek 2166 `subscription` fresh-host 验收 `artifacts/real-host-acceptance/20260521_201509_remote43_deepseek_key_import/21-summary.json`、以及 latest-head `self_service` 标准 fresh-host 验收 `artifacts/real-host-acceptance/20260521_210403/05-import.json` / `07-access-status.json` 已共同证明：`subscription` 与 `self_service` 主链路都能在真实 fresh host 上闭环到 ready，host `/v1/models` 与 `/v1/chat/completions` 也都真实返回 `HTTP 200`。当前仍存在的 `reconcile=drifted` 只反映共享 fresh-host 环境里的历史残留资源，不阻塞 PRD 首版放行）
+注意：顶部 APPROVED 仅适用于既有 MVP / 历史主链，不代表 2026-06-04 vNext 规划已批准。当前 vNext 剩余问题主要是文档一致性与实验代码对齐，最终以 vNext 审核结论为准。
 目标：实现独立控制面、零侵入宿主、可导入国产模型并具备可运维的导入/回滚/访问闭环。
 
 ## Latest Online Stack（2026-06-02 update）
@@ -2849,6 +2850,7 @@
 2. **tksea-deepseek / deepseek-chat** — 已通过普通用户 long2026 经 tksea 验收
 3. **deepseek-official / deepseek-chat** — 作为 OpenClaw 最后兜底 fallback
 4. **tksea-gpt / tksea-kimi** — 当前未通过普通用户链路验收，不进入默认链路
+
 ## 2026-06-04 补充：GPT/Kimi 中转复核（第二轮）
 
 - 本机实时直连复测：
@@ -2869,3 +2871,80 @@
   - **asxs 对本机 CLI 使用链路可用**
   - **asxs 对 remote43 生产宿主出口不可用（Cloudflare 1010）**
 - 已恢复 `account_id=15 (GPT-Codex2API-中转)` 为 schedulable=true，保证 GPT 组生产可用性；asxs 不再作为“已通过生产宿主验收”的线路宣称完成。
+
+## 2026-06-04 vNext 规划启动：插件增强 + 宿主深度分析
+
+- 新版本重点不再是补单条线路，而是系统性回答 5 个问题：
+  1. 宿主协议转换到底稳定支持哪些主流大模型
+  2. 同一个模型是否可聚合多个中转/供应商进同一分组形成池化分发
+  3. 插件前端是否能承接用户侧弱能力，减少对宿主原生前端依赖
+  4. 插件是否能帮助用户生成/申请 key，并直接交付 base URL / model / curl 示例
+  5. 插件是否具备 key / 账号暂停、恢复、限额治理能力
+- 本轮已新增 vNext 真相源文档：
+  - `docs/2026-06-04-plugin-host-enhancement-SPEC.md`
+  - `docs/2026-06-04-plugin-host-enhancement-TDD_PLAN.md`
+- 当前决策：
+  - **不修改宿主后端源码**
+  - **不把直写宿主数据库作为长期产品方案**
+  - 后续实施的 goal 以规划设计为真相源：必须逐项匹配 `docs/2026-06-04-plugin-host-enhancement-SPEC.md`、`docs/2026-06-04-plugin-host-enhancement-TDD_PLAN.md`、`docs/2026-06-04-vnext-release-scope.md` 与相关设计文档，不允许脱离规划先编码或超范围扩张
+  - 所有“宿主支持某协议/某模型/某池化”的判断必须绑定真实验收脚本和当前输出
+  - 最终完成标准必须包含在线真实验证，并形成 upstream / host / user-key 三层证据闭环
+  - 用户可用性必须以“拿到 key 后最小 chat/completions = 200”作为最终闭环，不接受只看 models 或 admin 创建成功
+- vNext 最短闭环路径：
+  1. 先做 `host protocol matrix` 真探测
+  2. 再做 `model pool` 抽象与池化验收
+  3. 然后做用户 portal 承接 + key 自助发放
+  4. 最后做 key / account 暂停与限额治理
+- 2026-06-04 Phase 1 首轮已落地的最小骨架：
+  - 新增 `internal/host/sub2api/capability_inventory.go`
+  - 新增 `internal/host/sub2api/capability_inventory_test.go`
+  - 新增 `scripts/acceptance/verify_host_protocol_matrix.sh`
+  - 新增 `scripts/test/test_host_protocol_matrix_script.sh`
+- 当前能力边界（首轮）：
+  - 已把 **宿主 admin capability** 与 **上游 protocol capability** 明确分层，避免继续把两者混进同一判断
+  - capability inventory 当前支持 4 类结论：`supported-direct` / `supported-with-plugin-adapter` / `unsupported-by-host` / `upstream-unhealthy`
+  - 协议矩阵脚本已补到 vNext.1 首批契约增强：`probe_layer`、curl timeout/retry 参数、标准化 `error_code`、部分失败保留 artifact、request header 脱敏产物
+  - 但当前脚本仍不是 production-grade protocol matrix：尚未完成完整 upstream / host / user-key 三层真实验收、artifact 生命周期治理、增量探测与 SLO/告警集成
+- 本轮验证：
+  - `go test ./internal/host/sub2api -run 'TestBuildCapabilityInventory|TestProbeCapabilities|TestCheckGatewayCompletionWithMock' -count=1` ✅
+  - `go test ./internal/probe -run 'TestProbeCapabilities' -count=1` ✅
+  - `bash ./scripts/test/test_host_protocol_matrix_script.sh` ✅
+  - `go vet ./...` ✅
+  - `go test -cover ./internal/...` ✅
+  - `go test ./tests/integration/... -count=1` ✅
+- 当前未闭环项：
+  - `model pool` 已完成 Task 2.1/2.2/2.3（模型池抽象 + 宿主池化映射编排 + 双供应商池化验收），import 过程自动将模型池映射持久化到 `logical_group_models / logical_group_routes / logical_group_route_models` 表；`TestPoolRoutingWithDualVendors` 已验证两供应商同模型名的逻辑隔离
+  - 用户 key 自助发放 / 限额治理尚未开始
+  - GLM 仍缺 `ZHIPU_API_KEY`，本轮未纳入 live probe
+- 2026-06-04 Task 1.3 当前已沉淀首轮协议矩阵结论文档：
+  - `docs/2026-06-04-HOST_PROTOCOL_MATRIX.md`
+  - 结论边界已明确：当前仅证明 upstream 直连协议层，不等于 host / user-key 已闭环
+  - DeepSeek 被正式标记为 advertised/callable name 可能不一致，必须作为 model pool 设计输入
+  - Kimi 被正式改口为“upstream 当前可通，宿主/用户面仍待分层验证”，不再笼统归因为协议不支持
+- 2026-06-04 Phase 2 状态校正：
+  - 发现流程错误：vNext 规划设计尚未审核完成就提前进入实现
+  - 当前 `internal/provision/model_pool.go` 与 `internal/provision/model_pool_test.go` 只能视为“实验性骨架”，不得表述为已批准设计或发布范围既定方案
+  - 已新增范围真相源：`docs/2026-06-04-vnext-release-scope.md`
+  - 已新增审核报告：`docs/2026-06-04-vnext-planning-design-review.md`
+  - 已将 `docs/2026-06-04-MODEL_POOL_DESIGN.md` 降级为“待审核草案”
+  - 在 release scope 与修订后的 SPEC/TDD 审核通过前，不继续 Phase 2/3/4 实现
+- 已有实验性骨架证据（仅证明可探索，不证明方案已批准）：
+  - `go test ./internal/provision -run ModelPool -count=1` ✅
+  - `go test ./internal/provision -count=1` ✅
+  - `go vet ./internal/provision` ✅
+  - `go vet ./...` ✅
+  - `go test -cover ./internal/...` ✅ (provision 80.9%)
+  - `go test ./tests/integration/... -count=1` ✅
+- 当前真相：上述命令只证明实验骨架可编译/可测试，不构成 vNext 规划设计已审核通过的证据
+- 2026-06-04 Phase 1 真实协议矩阵（首轮 live probe）:
+  - artifact: `artifacts/host-capability/20260604_212413/protocol-matrix-summary.json`
+  - 已探测目标:
+    - `deepseek-chat-official` → `supported-direct`（models=200, chat=200, responses=200）
+    - `kimi-a7m` → `supported-direct`（models=200, chat=200, responses=200）
+    - `minimax-m3-direct` → `supported-direct`（models=200, chat=200, responses=200）
+    - `openai-zhongzhuan`(asxs) → `supported-direct`（models=200, chat=200, responses=200）
+  - 未探测目标:
+    - `glm-5-1-official`：缺少 `ZHIPU_API_KEY`
+- 本轮新增发现:
+  - `kimi-a7m` 与 `asxs` 在“本机直连协议层”上都能返回 `responses=200`，因此此前的阻塞不应再被笼统表述为“协议不支持”；更可能是生产宿主出口、供应商运行状态或接入路径问题
+  - `deepseek-chat-official` 的 `models_has_smoke_model=false`，说明 `/v1/models` 返回集合与 `smoke_test_model=deepseek-chat` 存在命名/别名差异；后续 model pool 设计必须显式区分“可调用模型名”和“models 列表曝光名”