docs: G-008 并入 G-009（bat-api 仿官方 API），调整关闭顺序

- G-008（Go CLI）关闭：用户命令入口由功能完整的 Rust bat 承担，
  Go 侧转向仿官方 API 的 bat-api（issue #19）
- G-009 重定义为 bat-api：仿 BlueArchive 官方 API 的 Go HTTP 服务，
  含鉴权/签名验签，经 daemon RPC + current/ 发布布局对接
- 关闭顺序改为先完善 Rust bat 后端（issue #2/#3/#17）再做 bat-api
- PROJECT_PLAN 近期任务同步为 Rust 后端优先

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/reports/CURRENT_GAPS.md

@@ -1,6 +1,6 @@
 # 当前实现缺口清单
 
-- **更新时间**：2026-07-17
+- **更新时间**：2026-07-18
 - **用途**：集中跟踪当前代码中的占位实现、设计缺口和下一步验收项。
 - **权威计划**：`../../PROJECT_PLAN.md`
 
@@ -169,44 +169,39 @@
 
 ### G-008：Go CLI 尚未实现
 
-现象：
+状态：**已关闭（并入 G-009）**
 
-- `cmd/bat` 已有 `main.go`，但只是通过 cgo 调用 `bat-ffi` 的最小骨架（doctor/manifest inspect/sync plan），不是产品级用户入口；且默认 Go/Rust 集成边界应是 `bat --json` 进程边界，而非 FFI。
-- `internal/ffi/ffi.go` 已存在，但只是可选 CGO 兼容包装，不是用户可运行的产品 CLI，也不是默认集成边界。
-- `go test ./...` 当前没有产品级 Go package 覆盖。
+处理结果：
 
-当前进展：
+- 用户命令入口继续由功能完整的 Rust `bat` binary 承担（one-shot / watch / daemon / status / verify / repair / doctor / clean-stable 等已可用），Go 侧不再做重复的产品级用户 CLI。
+- Go 侧职责收敛为架构文档 §7.2 划定的方向：BlueArchive 客户端请求处理、HTTP API、内容分发。这部分并入 G-009（`bat-api`）。
+- 现有 `cmd/bat` cgo 试验骨架不再作为产品入口目标，另行清理。
 
-- 对接边界已就绪：Rust daemon 的 `bat.sock` Unix socket JSON-RPC Backend API（issue #1 主体已完成：统一 envelope、`BAT-ERR` 错误码模型、`daemon.*`/`resource.*`/`catalog.*`/`task.*` 方法集）与 `bat --json` 进程边界均可用。Go CLI 缺的是产品级入口本身，实现时应重写 `cmd/bat` 现有 cgo 骨架为 RPC/进程边界对接。
-
-影响：
-
-- 用户没有统一入口。
-- 同步、提取、补丁流程无法从命令行串联。
-
-验收：
-
-- `bat doctor` 可运行。
-- `bat --help` 命令结构稳定。
-- 命令支持默认人类可读输出和 `--json` 机器输出。
-- Go CLI 默认通过 Rust `bat --json` 进程边界获取同步 report；除非明确兼容需求，不依赖 FFI。
-
-### G-009：API Server 和 OpenAPI 尚未实现
+### G-009：API Server（`bat-api`，仿官方 API）尚未实现
 
 现象：
 
-- `api/` 只有目录结构。
-- 无 handler、service、OpenAPI schema。
+- `api/` 只有目录结构，无 handler、service、路由。
+- Go 侧尚无对接 daemon RPC / `current/` 发布布局的服务端入口。
+
+目标（对应 issue #19）：
+
+- 新建 `cmd/bat-api`：**完全仿照 BlueArchive 官方 API** 的 Go HTTP 服务，把 Rust `bat` 后端发布的 `current/` release 按官方接口形态对外提供，使真实客户端/工具可将其当作官方服务端。
+- 仿真面：资源 CDN 面（TableCatalog/MediaCatalog/BundlePackingInfo、bundle、seed `.hash`）、server-info 面、launcher API 面。
+- 鉴权/签名**完全仿照**官方实现，服务端做验签（对齐 `adapters/src/official/launcher.rs` 的签名逻辑）。
+- 版本/状态经 daemon RPC（`catalog.*` / `resource.manifest`）发现，资源字节从 `current/` 读取；不读写 daemon 状态文件内部。
 
 影响：
 
-- Web 和第三方集成无服务端入口。
+- 客户端、工具和第三方集成无服务端入口。
 
 验收：
 
-- `/api/v1/health` 可用。
-- 统一错误结构落地。
-- OpenAPI 与实际路由同步。
+- Go 单测覆盖路由、签名验签、错误响应形态。
+- 真机 e2e：daemon 发布 fixture release → 启动 `bat-api` → 按官方 URL 与鉴权头请求 server-info / catalog / bundle / launcher 链，断言字节与形态正确、验签生效（缺签/错签被拒）。
+- 统一错误结构与官方响应 envelope 对齐；Makefile 增加 Go 构建/测试目标。
+
+排期：P2，排在 issue #2 / #3 / #17（完善 Rust `bat` 后端）之后启动。
 
 ### G-010：Web 管理后台尚未实现
 
@@ -462,11 +457,10 @@
 
 ## 6. 当前关闭顺序建议
 
-1. G-008
-2. G-011
-3. G-005
-4. G-007
-5. G-012
-6. G-006
+1. issue #2 / #3 / #17（完善 Rust `bat` 后端：Addressables 可校验字段、UnityFS 基础解析、下载多线程）
+2. G-007 / G-005（对应上面 #2 / #3 的缺口条目）
+3. G-009（`bat-api`，仿官方 API 的 Go HTTP 服务，issue #19）
+4. G-011（官方同步结果接入 CAS + ResourceRepository 用户级工作流）
+5. G-012 / G-006（翻译系统、Patch 引擎）
 
-这个顺序优先补齐用户入口和官方同步结果的资源索引编排，再推进解析、翻译和补丁。G-018 已固化为可重复 smoke 命令并关闭；G-017 已按"不引入托管 CI"决策关闭。
+这个顺序优先把 Rust `bat` 后端做扎实（解析能力 + 下载性能），再对外提供仿官方 API 服务端，最后推进资源索引编排、翻译和补丁。G-008 已并入 G-009（用户 CLI 由 Rust `bat` 承担）；G-018 已固化为可重复 smoke 命令并关闭；G-017 已按"不引入托管 CI"决策关闭。