Module admin 

v1.4.32+ daemon 管理 admin REST API。

由同事 2026-04-18 提议“出问题时快速重置“需求衍生出 3 个 endpoint：

• GET /api/admin/status — 只读健康状态快照（Day 1 已实现）
• POST /api/admin/reload — 重刷 auth + 重建 broker 通道 + 清 cipher（Day 3）
• POST /api/admin/shutdown — 优雅退出（Day 2）

全部要求 Scope::Admin（scope 模式下）。legacy 模式默认放行 + 日志 WARN。

为什么只放 REST / CLI 运维面而不是 MCP / gRPC：LLM 或通用 proto requester 不该有 shutdown/reload daemon 的能力，blast radius 太大。 这 3 个 endpoint 是 daemon-local admin surface，没有公开 gateway proto_id，因此也不进入 gRPC generic proto request。

运行时上下文（v1.4.106 codex 0554 F4 [P3]）

三个 handler 都跑在 axum async runtime 里 (#[tokio::main] + axum Router::route). 业务约定:

• admin_status: 调 closure provider 同步生成 snapshot, 完全不 阻塞 tokio runtime (无 I/O / 无 lock 竞争, 仅几个 Arc clone + RwLock::read). 任意时刻可调.
• admin_shutdown: 同步返 200 → 立刻 tokio::spawn 1s 后调 std::process::exit(0). 1s 是给 HTTP body 写回 socket 时间; 期间 其他请求继续正常处理直到 exit.
• admin_reload: 同步阶段清 cipher + bump cipher_state_version (走 bridge.reload(), 已是 sync, 几 µs); 后台阶段 tokio::spawn 跑 refresh_credentials_on_disk 网络 I/O. handler 自身 await 的 Future 不含网络 I/O — closure 只 serialize ReloadReport. ops 通过 /api/admin/status 看 last_reload_refresh 字段 (Running / Succeeded / Failed / Skipped / NotApplicable) 监控后台 refresh 进度.

这意味着 /api/admin/reload 的 HTTP response 总是 <10ms (sync 阶段的 时间), 不再 hang 几秒等 backend 响应. 之前 v1.4.32 - v1.4.105 的 reload() async 整段 await 模式被 v1.4.106 F3 拆掉.

Body 校验 (v1.4.106 codex 0554 F2 [P2])

POST /api/admin/reload + /api/admin/shutdown 无 proto request struct, handler 完全不读 body. 但 strict_fields middleware 对这两 path 强制 empty-body / {} / null, 任何 user-supplied 字段返 400 列出 unknown fields. 防 {"force": true} / {"reason": ...} 之类被 silently 接受 (用户以为生效, 实际 server 完全无视) 的 silent-success 反模式.

Functions

admin_reload

POST /api/admin/reload — 重置 trade cipher 缓存（同步）+ 后台刷 credentials

admin_shutdown

POST /api/admin/shutdown — 优雅退出

admin_status

GET /api/admin/status — daemon 健康状态快照