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>

PROJECT_PLAN.md

@@ -380,14 +380,15 @@ BlueArchiveToolkit 不是一次性脚本，也不是演示项目。最终交付
 
 ## 6. 近期具体任务
 
-1. 落地 Go CLI 的最小生产入口：`bat doctor`、`bat sync --help`、`bat official sync --help`。
+优先完善 Rust `bat` 后端（用户 CLI 已由 Rust `bat` 承担，Go 侧转向仿官方 API 的 `bat-api`，见 issue #19 / G-009）：
-2. 让 Go CLI 默认调用 Rust `bat --json` 官方同步入口，并稳定转发结构化 report；除非有明确兼容需求，不走 FFI。
+
-3. 记录一次真实官方网络 smoke：dry-run、首次下载、二次 up-to-date、本地损坏 repair。
+1. 继续逆向 Addressables catalog，提取 bundle hash/size/CRC 等可校验字段（issue #2）。
-4. 将官方同步下载结果接入 CAS + `SqliteResourceRepository` 的用户级流程。
+2. 对 AssetBundle/UnityFS 做基础解析校验：header/block/directory/metadata（issue #3）。
-5. 继续扩展 Addressables parser 的真实 catalog 变体覆盖和错误诊断。
+3. 下载资源时增加多线程模式（issue #17）。
-6. 开始 AssetBundle UnityFS header/block/directory 解析。
+4. 之后：实现 `bat-api`（仿官方 API 的 Go HTTP 服务，含鉴权/签名验签，issue #19 / G-009）。
-7. 为 CLI 和 CAS 增加 `doctor cas` 诊断入口。
+5. 将官方同步下载结果接入 CAS + `SqliteResourceRepository` 的用户级流程（G-011）。
-8. 为 `bat --watch` / `bat --daemon` 持续补充发布型构建、systemd service 示例和运维检查清单；后台 live control plane 已改为 Unix socket JSON-RPC；基础生产部署模板、日志路径、权限用户、升级/回滚流程已补齐。
+6. 为 CAS 增加 `doctor cas` 诊断入口。
+7. 为 `bat --watch` / `bat --daemon` 持续补充发布型构建、systemd service 示例和运维检查清单；后台 live control plane 已改为 Unix socket JSON-RPC；基础生产部署模板、日志路径、权限用户、升级/回滚流程已补齐。
 
 ---
 

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/进程边界对接。
+### G-009：API Server（`bat-api`，仿官方 API）尚未实现
-
-影响：
-
-- 用户没有统一入口。
-- 同步、提取、补丁流程无法从命令行串联。
-
-验收：
-
-- `bat doctor` 可运行。
-- `bat --help` 命令结构稳定。
-- 命令支持默认人类可读输出和 `--json` 机器输出。
-- Go CLI 默认通过 Rust `bat --json` 进程边界获取同步 report；除非明确兼容需求，不依赖 FFI。
-
-### G-009：API Server 和 OpenAPI 尚未实现
 
 现象：
 
-- `api/` 只有目录结构。
+- `api/` 只有目录结构，无 handler、service、路由。
-- 无 handler、service、OpenAPI schema。
+- 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` 可用。
+- Go 单测覆盖路由、签名验签、错误响应形态。
-- 统一错误结构落地。
+- 真机 e2e：daemon 发布 fixture release → 启动 `bat-api` → 按官方 URL 与鉴权头请求 server-info / catalog / bundle / launcher 链，断言字节与形态正确、验签生效（缺签/错签被拒）。
-- OpenAPI 与实际路由同步。
+- 统一错误结构与官方响应 envelope 对齐；Makefile 增加 Go 构建/测试目标。
+
+排期：P2，排在 issue #2 / #3 / #17（完善 Rust `bat` 后端）之后启动。
 
 ### G-010：Web 管理后台尚未实现
 
@@ -462,11 +457,10 @@
 
 ## 6. 当前关闭顺序建议
 
-1. G-008
+1. issue #2 / #3 / #17（完善 Rust `bat` 后端：Addressables 可校验字段、UnityFS 基础解析、下载多线程）
-2. G-011
+2. G-007 / G-005（对应上面 #2 / #3 的缺口条目）
-3. G-005
+3. G-009（`bat-api`，仿官方 API 的 Go HTTP 服务，issue #19）
-4. G-007
+4. G-011（官方同步结果接入 CAS + ResourceRepository 用户级工作流）
-5. G-012
+5. G-012 / G-006（翻译系统、Patch 引擎）
-6. G-006
 
-这个顺序优先补齐用户入口和官方同步结果的资源索引编排，再推进解析、翻译和补丁。G-018 已固化为可重复 smoke 命令并关闭；G-017 已按"不引入托管 CI"决策关闭。
+这个顺序优先把 Rust `bat` 后端做扎实（解析能力 + 下载性能），再对外提供仿官方 API 服务端，最后推进资源索引编排、翻译和补丁。G-008 已并入 G-009（用户 CLI 由 Rust `bat` 承担）；G-018 已固化为可重复 smoke 命令并关闭；G-017 已按"不引入托管 CI"决策关闭。