mirror of
https://github.com/Yuyi-Oak/BlueArchiveToolkit.git
synced 2026-09-18 06:34:54 +08:00
docs: 校正文档分类与当前边界
This commit is contained in:
+62
-30
@@ -4,7 +4,7 @@
|
||||
|
||||
BlueArchive Toolkit 采用 **Monorepo + 多语言混合** 架构,旨在构建一个可持续维护十年以上的工业级开源项目。
|
||||
|
||||
当前文档描述目标架构和已经落地的关键边界。它不是部署手册;当前可部署能力包括 Rust 官方资源同步任务和 Go `cmd/bat-api` 资源 bootstrap/分发服务。完整游戏业务 API、Web、Provider 编排和 SDK 仍未完成,实际实现状态以根目录 `CURRENT_STATUS.md` 和 `PROJECT_PLAN.md` 为准。
|
||||
当前文档描述目标架构和已经落地的关键边界。它不是部署手册;当前可部署能力包括 Rust 官方资源同步任务和 Go `cmd/bat-api` 资源 bootstrap/分发服务。完整游戏业务 API、Web、Provider 编排和 SDK 仍未完成,实际实现状态以源码、测试和根目录 `CURRENT_STATUS.md` 为准;`PROJECT_PLAN.md` 只描述目标和路线图。
|
||||
|
||||
当前已经可用的官方资源入口包括:
|
||||
|
||||
@@ -25,9 +25,11 @@ BlueArchive Toolkit 采用 **Monorepo + 多语言混合** 架构,旨在构建
|
||||
|
||||
已接受的架构决策:
|
||||
|
||||
- `adr/0001-engine-and-application-boundaries.md`:Rust 引擎与 Go 应用层边界。
|
||||
- `adr/0001-engine-and-application-boundaries.md`:历史语言/层次边界决策;资源同步职责已由 ADR 0004 取代。
|
||||
- `adr/0002-cas-v1-design-boundary.md`:CAS V1 设计边界。
|
||||
- `adr/0003-cas-core-interface-and-error-boundary.md`:CAS 核心接口与错误边界冻结。
|
||||
- `adr/0004-rust-bat-go-bat-api-resource-boundary.md`:当前 Rust `bat` 与 Go `bat-api`
|
||||
的资源控制面边界。
|
||||
|
||||
---
|
||||
|
||||
@@ -41,16 +43,30 @@ BlueArchive Toolkit 采用 **Monorepo + 多语言混合** 架构,旨在构建
|
||||
|
||||
### 2. 语言选型
|
||||
|
||||
| 模块 | 语言 | 理由 |
|
||||
| 模块 | 语言 | 当前定位 |
|
||||
|------|------|------|
|
||||
| CLI、API Server、服务编排 | Go | 并发模型优秀、部署简单、生态成熟 |
|
||||
| 官方资源同步核心、AssetBundle 解析、Patch 引擎、CAS 引擎 | Rust | 零成本抽象、内存安全、性能和二进制处理更可靠 |
|
||||
| Web 管理后台 | Vue 3 + TypeScript | 渐进式、类型安全、生态完善 |
|
||||
| 官方资源同步与运维 CLI、同步核心 | Rust | **当前实现**;`bat` 负责生产资源和长期状态 |
|
||||
| 资源 bootstrap、只读分发和 Rust 管理入口 | Go | **当前实现**;`cmd/bat-api` 通过 `bat.sock` RPC 工作 |
|
||||
| AssetBundle 解析、Patch 引擎、CAS 引擎 | Rust | **当前已有基础,复杂覆盖仍按路线图推进** |
|
||||
| 完整 API、服务编排和 Provider | Go | **目标设计,尚未完整实现** |
|
||||
| 完整 Web 协作后台 | Vue 3 + TypeScript | **目标设计**;当前只有内嵌 dashboard MVP |
|
||||
|
||||
### 3. 数据流设计
|
||||
|
||||
当前已落地的数据流:
|
||||
|
||||
```
|
||||
用户请求 → CLI/API → Go 业务层 → bat --json / SDK → Rust 核心/同步层 → CAS 存储 → 数据库
|
||||
官方 metadata → Rust bat / daemon → release + current + manifest
|
||||
↓
|
||||
bat.sock JSON-RPC
|
||||
↓
|
||||
Go bat-api → bootstrap / CDN / dashboard
|
||||
```
|
||||
|
||||
目标扩展数据流(其中 Go 业务层、SDK、数据库和 Redis 尚未全部实现):
|
||||
|
||||
```
|
||||
用户请求 → CLI/API → Go 业务层 → bat.sock RPC / SDK → Rust 核心/同步层 → CAS 存储 → 数据库
|
||||
↓ ↓
|
||||
Web UI 缓存层 (Redis)
|
||||
```
|
||||
@@ -99,7 +115,7 @@ cas/
|
||||
|
||||
---
|
||||
|
||||
### 2. 官方资源同步器 (Rust 当前实现,Go 侧读取与编排)
|
||||
### 2. 官方资源同步器 (Rust 当前实现,Go 侧读取)
|
||||
|
||||
**职责**:从官方日服 HTTP metadata 自动发现资源入口,下载 Windows + Android 官方资源,增量检查,完整性校验,保持本地状态。
|
||||
|
||||
@@ -133,20 +149,24 @@ current symlink → official-sync-snapshot.json + official-download-manifest.jso
|
||||
- 本地文件损坏时 repair。
|
||||
- 官方 seed `.hash` 强校验;Addressables `catalog_*.hash` 作为变更 marker。
|
||||
|
||||
**后续 Go 职责**:
|
||||
**Go 当前职责**:
|
||||
|
||||
- 提供最小稳定 CLI。
|
||||
- 默认通过 `bat --json` 进程边界包装 Rust 同步入口,并转发结构化 report。
|
||||
- `bat-ffi` 仅作为可选无状态 C ABI 兼容层,不承载官方同步 daemon、下载器或 CAS handle。
|
||||
- 编排 API Server、任务队列、Provider 和用户配置。
|
||||
- `bat-api` 通过 `bat.sock` RPC 读取 Rust 已发布 release、manifest、snapshot 和状态。
|
||||
- 提供资源 bootstrap、server-info 改写、只读 CDN path、readiness、OpenAPI 和白名单管理转发。
|
||||
- 不运行另一套同步器,不直接管理官方下载、staging、version-state、CAS 或解析状态。
|
||||
|
||||
完整 API、服务编排、Provider 和用户配置属于目标扩展,不能从本节推断为当前已实现。
|
||||
|
||||
---
|
||||
|
||||
### 3. AssetBundle 解析器 (Rust)
|
||||
### 3. AssetBundle 解析器 (Rust,当前基础与目标扩展)
|
||||
|
||||
**职责**:解析 Unity AssetBundle,提取资源
|
||||
|
||||
**插件化架构**:
|
||||
以下插件注册和动态加载是目标扩展;当前实现以 `crates/bat-assetbundle`、
|
||||
`bat-adapters` 和真实 fixture 覆盖为准。
|
||||
|
||||
**目标插件化架构**:
|
||||
```rust
|
||||
pub trait AssetParser {
|
||||
fn name(&self) -> &str;
|
||||
@@ -172,7 +192,11 @@ pub struct ParserRegistry {
|
||||
|
||||
---
|
||||
|
||||
### 4. 翻译系统 (Go)
|
||||
### 4. 翻译系统 (目标设计,Go)
|
||||
|
||||
当前已实现的是 Rust `bat` 的离线 TextUnit 队列、mock/Crowdin provider worker、
|
||||
lease/retry 和结果落库;Translation Memory、Glossary 和完整 Provider 体系仍属
|
||||
后续缺口。
|
||||
|
||||
**架构**:
|
||||
```
|
||||
@@ -204,7 +228,7 @@ type TranslationProvider interface {
|
||||
|
||||
---
|
||||
|
||||
### 5. Patch 引擎 (Rust)
|
||||
### 5. Patch 引擎 (Rust,当前基础与目标扩展)
|
||||
|
||||
**职责**:生成和应用补丁
|
||||
|
||||
@@ -232,7 +256,10 @@ patch/
|
||||
|
||||
---
|
||||
|
||||
### 6. API Server (Go)
|
||||
### 6. API Server (Go,目标设计)
|
||||
|
||||
当前可用的 Go HTTP 服务是 `cmd/bat-api` 的资源 bootstrap、只读分发和 Rust 管理
|
||||
入口,不是下列完整游戏业务 API。
|
||||
|
||||
**框架**:Gin 或 Echo
|
||||
|
||||
@@ -259,7 +286,9 @@ HTTP Request → Middleware (Auth, CORS, Logger) → Handler → Service → Rep
|
||||
|
||||
---
|
||||
|
||||
### 7. Web 后台 (Vue 3)
|
||||
### 7. Web 后台 (Vue 3,目标设计)
|
||||
|
||||
当前只有 `bat-api` 内嵌 dashboard MVP;登录、角色、术语管理和完整协作审核仍未实现。
|
||||
|
||||
**技术栈**:
|
||||
- Vue 3 + Composition API
|
||||
@@ -278,7 +307,10 @@ HTTP Request → Middleware (Auth, CORS, Logger) → Handler → Service → Rep
|
||||
|
||||
---
|
||||
|
||||
## 数据库设计
|
||||
## 数据库设计(目标设计)
|
||||
|
||||
当前 Rust 资源链路使用 SQLite 维护本地 CAS、ResourceRepository 和翻译任务状态;
|
||||
PostgreSQL/Redis 业务服务端方案尚未完整落地。
|
||||
|
||||
### PostgreSQL Schema
|
||||
|
||||
@@ -322,7 +354,11 @@ CREATE TABLE resource_versions (
|
||||
|
||||
---
|
||||
|
||||
## 部署架构
|
||||
## 部署架构(目标设计)
|
||||
|
||||
当前可部署形态是 Rust `bat` 官方资源同步任务和同机/共享文件系统的 Go
|
||||
`bat-api` 资源 bootstrap/分发服务。以下多实例 API、PostgreSQL 主从和 Redis
|
||||
集群属于目标部署形态。
|
||||
|
||||
### 本地开发模式
|
||||
|
||||
@@ -350,7 +386,7 @@ API Server (多实例)
|
||||
|
||||
---
|
||||
|
||||
## 安全设计
|
||||
## 安全设计(目标设计)
|
||||
|
||||
1. **认证**:JWT Token
|
||||
2. **授权**:RBAC (Role-Based Access Control)
|
||||
@@ -361,7 +397,7 @@ API Server (多实例)
|
||||
|
||||
---
|
||||
|
||||
## 性能优化
|
||||
## 性能优化(目标设计)
|
||||
|
||||
1. **缓存策略**:
|
||||
- Redis 缓存热点数据
|
||||
@@ -380,7 +416,7 @@ API Server (多实例)
|
||||
|
||||
---
|
||||
|
||||
## 监控与日志
|
||||
## 监控与日志(目标设计)
|
||||
|
||||
- **日志**:结构化日志(JSON 格式)
|
||||
- **指标**:Prometheus + Grafana
|
||||
@@ -401,10 +437,6 @@ API Server (多实例)
|
||||
更多详细设计文档:
|
||||
|
||||
- [官方资源后端说明](./official-resource-backend.md)
|
||||
- [资源 release 布局与分发契约](./resource-release-layout.md)
|
||||
- [AssetBundle 解析与发布路线图](./assetbundle.md)
|
||||
- [API 设计](../api/README.md)
|
||||
|
||||
待创建的详细设计文档:
|
||||
|
||||
- `docs/architecture/cas.md`
|
||||
- `docs/architecture/assetbundle.md`
|
||||
- `docs/architecture/translation.md`
|
||||
|
||||
@@ -1,11 +1,17 @@
|
||||
# ADR 0001: Rust 引擎与 Go 应用层边界
|
||||
|
||||
**状态**:已接受
|
||||
**状态**:已接受(历史决策;资源同步职责已由 ADR 0004 取代)
|
||||
**日期**:2026-06-28
|
||||
**关联计划**:`../../../PROJECT_PLAN.md`
|
||||
|
||||
---
|
||||
|
||||
> 历史说明:本文保留 2026-06-28 的原始语言和层次决策。其关于 Go 负责资源同步、
|
||||
> 下载器和任务调度的职责描述已被当前实现和 ADR 0004 取代;阅读当前资源边界时,
|
||||
> 以 ADR 0004、`CURRENT_STATUS.md` 和 `docs/reports/GO_STATUS.md` 为准。
|
||||
|
||||
---
|
||||
|
||||
## 背景
|
||||
|
||||
BlueArchiveToolkit 的最终目标覆盖资源同步、CAS、AssetBundle 解析、文本提取、翻译、Patch、CLI、API Server、Web 和 SDK。项目天然包含二进制解析、文件完整性、网络同步、任务编排、数据库、用户界面等不同类型的问题。
|
||||
|
||||
@@ -0,0 +1,60 @@
|
||||
# ADR 0004: Rust bat 与 Go bat-api 当前资源控制面边界
|
||||
|
||||
**状态**:已接受
|
||||
**日期**:2026-09-04
|
||||
**关联文档**:`../../../CURRENT_STATUS.md`、`../../../docs/reports/GO_STATUS.md`
|
||||
|
||||
---
|
||||
|
||||
## 背景
|
||||
|
||||
项目同时包含 Rust 资源引擎和 Go HTTP 服务。历史设计曾把资源同步、下载器
|
||||
和任务调度归入 Go 应用层,但当前实现已经由 Rust `bat` 统一持有这些长期状态。
|
||||
如果继续沿用旧职责描述,会让 Go、Web 或其他入口重复实现资源状态机。
|
||||
|
||||
---
|
||||
|
||||
## 决策
|
||||
|
||||
1. **Rust `bat` 是官方资源生产者和状态拥有者**:
|
||||
- 负责官方 metadata 发现、下载、校验、staging、release 发布和 `current` 切换;
|
||||
- 负责 watch/daemon、`bat.sock` JSON-RPC、任务、日志、版本状态、解析、
|
||||
翻译 worker 和 localized release 状态;
|
||||
- 负责 CAS、AssetBundle 解析、Patch 核心算法及其文件安全边界。
|
||||
|
||||
2. **Go `bat-api` 是资源读侧和管理入口**:
|
||||
- 通过 `bat.sock` RPC 发现 Rust 已发布的 `resource_root`、snapshot、manifest
|
||||
和状态;
|
||||
- 提供资源 bootstrap、server-info 改写、只读 CDN path、readiness、OpenAPI
|
||||
以及鉴权后的白名单管理转发;
|
||||
- 不下载官方资源、不写 staging、不维护 version-state,不复制 CAS、解析器、
|
||||
Patch 核心算法或同步状态机。
|
||||
|
||||
3. **Go `cmd/bat` 和 `bat-ffi` 不是主集成边界**:
|
||||
- `cmd/bat` 只保留试验 CLI;
|
||||
- `bat-ffi` 只保留无状态、粗粒度、一次调用一次输入输出的兼容 helper;
|
||||
- 新的跨语言控制和查询能力优先增加 Rust RPC contract,再由
|
||||
`internal/backendrpc` 消费。
|
||||
|
||||
4. **完整游戏业务 API、完整 Web 协作后台、Translation Memory、Glossary 和
|
||||
Provider 扩展体系仍是后续目标**,不能从目标架构图推断为当前已实现。
|
||||
|
||||
---
|
||||
|
||||
## 后果
|
||||
|
||||
- 资源同步只有一个长期状态拥有者,`bat-api` 可以安全地横向扩展为只读服务。
|
||||
- Rust RPC、release layout、manifest 和 `status/status_code` 成为跨语言稳定契约。
|
||||
- Go 侧新增控制接口必须经过白名单和 RPC schema 复核。
|
||||
- 完整业务 API 和协作后台未来落地时,仍需遵守 Rust `bat` 对资源状态的所有权。
|
||||
|
||||
---
|
||||
|
||||
## 当前验证依据
|
||||
|
||||
- `infrastructure/src/bin/bat/`
|
||||
- `infrastructure/src/official_update.rs`
|
||||
- `internal/backendrpc/`
|
||||
- `cmd/bat-api/`
|
||||
- `docs/reference/rpc-backend-api.md`
|
||||
- `internal/api/testdata/contract/`
|
||||
@@ -1,9 +1,9 @@
|
||||
# AssetBundle 与资源解析路线图
|
||||
|
||||
- **更新时间**:2026-09-02
|
||||
- **更新时间**:2026-09-04
|
||||
- **适用范围**:Rust 解析引擎、官方同步后的解析缓存、CAS/ResourceRepository 接入、后续文本提取和 Patch 发布。
|
||||
- **权威关联**:`PROJECT_PLAN.md` Milestone 3/4/5/8,`docs/reports/CURRENT_GAPS.md` G-005/G-007/G-011/G-011D。
|
||||
- **维护冻结**:解析扩展遵循 [`docs/reports/PARSER_FREEZE.md`](../reports/PARSER_FREEZE.md),冻结期只接受稳定性、诊断、真实回归和文档一致性修复。
|
||||
- **开发状态**:解析扩展当前按路线图和真实回归继续推进。
|
||||
|
||||
---
|
||||
|
||||
@@ -32,7 +32,7 @@
|
||||
| UnityFS container | `.bundle`、zip 内 bundle | header、block、directory、解压文件、基础摘要 | 已支持基础解包、LZ4/LZMA、alignment、大小/计数/路径/边界校验 |
|
||||
| Serialized file | UnityFS directory 文件 | header、type table、TypeTree node、object table、TextAsset bytes | 已支持基础表结构和 TextAsset bytes |
|
||||
| Unity 对象字段 | TextAsset、MonoBehaviour、ScriptableObject | 可翻译文本单元、上下文、资源定位 | TypeTree 基础字段读取、`SerializedReference` / prefixed managed-reference metadata alias、payload 提取和字符串提取已落地,真实结构覆盖继续扩大 |
|
||||
| Patch 发布 | 已翻译 TextUnit、中间格式、原版资源 | 可验证 localized patch manifest、汉化 release 目录、current/state | TextAsset、TypeTree string field 和 managed-reference string field 的 localized publish/rollback 已落地;整体 AssetBundle 重打包与通用 manifest 发布仍冻结 |
|
||||
| Patch 发布 | 已翻译 TextUnit、中间格式、原版资源 | 可验证 localized patch manifest、汉化 release 目录、current/state | TextAsset、TypeTree string field 和 managed-reference string field 的 localized publish/rollback 已落地;整体 AssetBundle 重打包与通用 manifest 发布仍未完成 |
|
||||
|
||||
---
|
||||
|
||||
@@ -54,7 +54,7 @@
|
||||
|
||||
当前还不能宣称完整:
|
||||
|
||||
1. TypeTree-covered managed reference 字段和 registry 记录已可结构化解码并参与文本提取,常见 registry 命名别名(含 `m_ManagedReferences`、`RefIds`、`m_RefIds`、verbose type 字段)、metadata 命名别名(含 `id`、`typeInfo`)、payload 命名别名(含 `data`、`value`、`payload`、`object`、`managedReferencePayload`、`referencePayload`、`serializedReferencePayload`、`managedReferenceValue`、`referenceValue`、`serializedReferenceValue`、`managedReferenceObject`、`referenceObject`、`serializedReferenceObject`、`managedReferenceData`、`referenceData`、`serializedData`)、full typename 拆解和 payload-only TextUnit 提取已有回归覆盖,多记录 registry 聚合也已有单元回归;fallback 字段遍历会跳过常见 registry 元数据字符串,避免误入翻译队列,并按记录前缀或子字段可推导 metadata 保留 managed-reference TextUnit context。enum `value__` backing field 和 `LayerMask` / `BitField` 的 `m_Bits` backing field 已可语义化解码和替换;`Vector2f/3f/4f`、`Quaternionf`、`ColorRGBA`、`Rectf`、`AABB/Bounds/Ray`、`Matrix4x4f`、`Vector2Int/Vector3Int`、`RectInt`、`BoundsInt`、`RangeInt`、`GUID`、`Hash128` 等固定 Unity 值类型的 leaf 和 direct child TypeTree 形态已可结构化解码和语义替换;array/vector/staticvector/List/HashSet/map 元素与 registry payload 字段已保留独立 field path、offset 和 byte size,可用于字符串元素 patch,managed-reference registry payload 字符串、enum、bit_field、unknown fixed-size raw bytes、object 字段组合和 TypeTree schema 支撑的 array/vector/List/HashSet/map 已可整体变长替换,`first/second` 与 `key/value` map entry schema 已有 serialized 和 UnityFS 重建回归,ScriptableObject `key/value` map 解析、变长替换和 UnityFS 重建已有专门回归,且嵌套 vector `Array`、`List<T>` / `HashSet<T>` 集合 alias、enum、bit_field、unknown fixed-size raw bytes 与 managed-reference payload 字段已有重建回归覆盖;解析模块当前处于维护冻结,未见样本驱动的完整 managed reference registry / map entry 变体、unknown 字段结构语义和版本差异冻结后再推进。
|
||||
1. TypeTree-covered managed reference 字段和 registry 记录已可结构化解码并参与文本提取,常见 registry 命名别名(含 `m_ManagedReferences`、`RefIds`、`m_RefIds`、verbose type 字段)、metadata 命名别名(含 `id`、`typeInfo`)、payload 命名别名(含 `data`、`value`、`payload`、`object`、`managedReferencePayload`、`referencePayload`、`serializedReferencePayload`、`managedReferenceValue`、`referenceValue`、`serializedReferenceValue`、`managedReferenceObject`、`referenceObject`、`serializedReferenceObject`、`managedReferenceData`、`referenceData`、`serializedData`)、full typename 拆解和 payload-only TextUnit 提取已有回归覆盖,多记录 registry 聚合也已有单元回归;fallback 字段遍历会跳过常见 registry 元数据字符串,避免误入翻译队列,并按记录前缀或子字段可推导 metadata 保留 managed-reference TextUnit context。enum `value__` backing field 和 `LayerMask` / `BitField` 的 `m_Bits` backing field 已可语义化解码和替换;`Vector2f/3f/4f`、`Quaternionf`、`ColorRGBA`、`Rectf`、`AABB/Bounds/Ray`、`Matrix4x4f`、`Vector2Int/Vector3Int`、`RectInt`、`BoundsInt`、`RangeInt`、`GUID`、`Hash128` 等固定 Unity 值类型的 leaf 和 direct child TypeTree 形态已可结构化解码和语义替换;array/vector/staticvector/List/HashSet/map 元素与 registry payload 字段已保留独立 field path、offset 和 byte size,可用于字符串元素 patch,managed-reference registry payload 字符串、enum、bit_field、unknown fixed-size raw bytes、object 字段组合和 TypeTree schema 支撑的 array/vector/List/HashSet/map 已可整体变长替换,`first/second` 与 `key/value` map entry schema 已有 serialized 和 UnityFS 重建回归,ScriptableObject `key/value` map 解析、变长替换和 UnityFS 重建已有专门回归,且嵌套 vector `Array`、`List<T>` / `HashSet<T>` 集合 alias、enum、bit_field、unknown fixed-size raw bytes 与 managed-reference payload 字段已有重建回归覆盖;后续仍需继续补齐真实样本驱动的完整 managed reference registry / map entry 变体、unknown 字段结构语义和版本差异。
|
||||
2. Addressables 当前目标 JSON/compact 字段链已补齐;未识别的独立二进制格式仍返回明确错误,不静默降级。
|
||||
3. 官方 release 已可配置导入 CAS + ResourceRepository,并可通过 `resource.index` 查询现有资源索引;Resource metadata 已记录 release、平台、bundle path、parse status、TextAsset 名称和 TextUnit 摘要。
|
||||
4. 不能完成复杂对象字段重打包,也不能从真实 Crowdin 结果自动生成完整汉化文件集合。
|
||||
@@ -99,7 +99,7 @@
|
||||
4. 将 Windows/Android catalog 样本拆成可复现 fixture,不把大文件纳入 Git。
|
||||
5. 对未知结构返回明确错误或保真 raw metadata,不静默丢字段。
|
||||
|
||||
本次 issue #2 交付已完成上述 JSON/compact 字段链:provider ID、bundle name、
|
||||
当前 JSON/compact 字段链已完成:provider ID、bundle name、
|
||||
primary/dependency key、resource type、hash、size 和 CRC 会进入 `ResourceEntry`,
|
||||
并通过 SQLite `ResourceRepository` 持久化;旧索引会按列迁移继续可读。独立二进制
|
||||
catalog 仍按“明确不支持”处理,不把低保真路径伪装成完整解析。
|
||||
@@ -202,12 +202,13 @@ catalog 仍按“明确不支持”处理,不把低保真路径伪装成完整
|
||||
|
||||
---
|
||||
|
||||
## 7. 近期关闭路径
|
||||
## 7. 后续推进路径
|
||||
|
||||
优先顺序:
|
||||
|
||||
1. 完成 Addressables Windows/Android 当前版本 catalog 样本集合,关闭 G-007 当前阶段。
|
||||
2. 完成 TypeTree 字段 reader 和 MonoBehaviour/ScriptableObject 遍历,推进 G-005。
|
||||
1. 继续补充 Addressables Windows/Android 真实 catalog 样本和独立二进制格式诊断。
|
||||
2. 继续补充 TypeTree 字段 reader、MonoBehaviour/ScriptableObject 遍历和真实版本差异。
|
||||
3. 基于 `translation.worker.run` 推进翻译记忆和通用 manifest Patch 构建。
|
||||
4. 扩展翻译任务结果在 CAS/ResourceRepository 查询面的索引,推进 G-011。
|
||||
5. 在通用 Binary/JSON/Text Patch 基础上继续扩展复杂 AssetBundle 重打包和通用 Patch 发布流程统一,保留当前受支持 localized patch 发布/rollback 链路。
|
||||
4. 扩展翻译任务结果在 CAS/ResourceRepository 查询面的索引。
|
||||
5. 在通用 Binary/JSON/Text Patch 基础上继续扩展复杂 AssetBundle 重打包和通用
|
||||
Patch 发布流程统一,保留当前受支持 localized patch 发布/rollback 链路。
|
||||
|
||||
@@ -219,7 +219,9 @@ release 根目录写入 `translation-tasks.sqlite`,由版本化 `schema_migrat
|
||||
|
||||
集成边界:
|
||||
|
||||
1. 当前生产集成路径是 Rust `bat --watch` / `bat --daemon` 持久运行;Go `bat-api` 应优先通过 `internal/backendrpc` 调用 daemon RPC,one-shot/fallback 场景才运行 `bat --json` 并消费结构化 report。
|
||||
1. 当前生产集成路径是 Rust `bat --watch` / `bat --daemon` 持久运行;Go `bat-api`
|
||||
通过 `internal/backendrpc` 调用 daemon RPC,读取已发布 release 和状态,不运行
|
||||
另一套同步器。`bat --json` 只表示 Rust CLI 的机器输出形态。
|
||||
2. systemd、容器或上层 Go 进程只负责守护 `bat --watch` / `bat --daemon`,不直接接管下载器内部状态。
|
||||
3. `bat-ffi` 只允许作为可选无状态 C ABI 兼容层,用于 Manifest inspect 和 sync plan 这类一次性 JSON helper;它不是官方同步 daemon、下载器、资源锁、CAS handle 或主控制面的承载位置。
|
||||
|
||||
@@ -356,7 +358,7 @@ JSON-RPC 2.0 服务,是面向上层服务(Go 层)的**主要跨语言边
|
||||
- Go 层负责:资源 bootstrap、资源内容分发(`cmd/bat-api`)、HTTP API 进程配置、
|
||||
以及通过 `internal/backendrpc` 作为 RPC client 调用本机 daemon(连接
|
||||
`bat.sock`,每行一个 JSON-RPC 请求/响应)。`cmd/bat` 仍是试验骨架,不是产品级用户 CLI。
|
||||
- **`bat-api`(资源分发,issue #19)**:
|
||||
- **`bat-api`(资源分发)**:
|
||||
- 提供 `/v1/bootstrap`,把 `bat` 的 RPC 健康、release 摘要、server-info URL、
|
||||
client-patch base 和改写后的 Addressables root 组织成启动前资源发现响应。
|
||||
- 提供 `/healthz` 作为 liveness + 最近一次 RPC refresh 诊断,提供 `/readyz`
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 官方资源 Release 布局与资源侧契约
|
||||
|
||||
- **更新时间**:2026-09-02
|
||||
- **更新时间**:2026-09-04
|
||||
- **用途**:冻结日服官方资源在本地发布根上的布局、URL 映射、seed 规则、`bat`/`bat-api` 关系,以及 `bat-api` 分发 path 的 1:1 对应关系。
|
||||
- **范围**:资源发现 / 清单 / 落盘 / 只读分发(**不是**完整游戏业务 API)。
|
||||
- **权威代码**:
|
||||
@@ -319,18 +319,18 @@ Addressables 改写后客户端拼接:
|
||||
|
||||
---
|
||||
|
||||
## 9. issue #2 / #3 样本索引(R4/R5 预置)
|
||||
## 9. 真实资源样本索引
|
||||
|
||||
在服务器 release 上优先采集到 `/tmp` 隔离目录(**不入库大文件**):
|
||||
|
||||
| 用途 | 建议路径模式 |
|
||||
|---|---|
|
||||
| Addressables(#2) | `{PatchDir}/catalog_*.zip` 解压后的 JSON/bin + 旁路 `.hash` |
|
||||
| UnityFS(#3) | `FullPatch_*.zip` 内抽样 `.bundle`,或已解包 bundle |
|
||||
| Addressables | `{PatchDir}/catalog_*.zip` 解压后的 JSON/bin + 旁路 `.hash` |
|
||||
| UnityFS | `FullPatch_*.zip` 内抽样 `.bundle`,或已解包 bundle |
|
||||
| seed 加固(R2) | 各平台 `TableCatalog` / `BundlePackingInfo` / `MediaCatalog` 的 `.bytes`+`.hash` |
|
||||
|
||||
字段目标(#2,已有 `m_Crc` 部分):继续扩大 hash/size/CRC/依赖等可校验字段覆盖。
|
||||
结构目标(#3):header / block / directory / metadata / object table 引擎级解析。
|
||||
字段目标(已有 `m_Crc` 部分):继续扩大 hash/size/CRC/依赖等可校验字段覆盖。
|
||||
结构目标:header / block / directory / metadata / object table 引擎级解析。
|
||||
|
||||
---
|
||||
|
||||
@@ -360,7 +360,7 @@ bat.sock 或 state-dir: ...
|
||||
- `docs/architecture/official-resource-backend.md` — 拉取后端总览
|
||||
- `docs/reference/rpc-backend-api.md` — RPC 契约
|
||||
- `docs/guides/official-resource-test-pull.md` — 用户向运行说明
|
||||
- `docs/reports/CURRENT_GAPS.md` — G-009 / #2 / #3
|
||||
- `docs/reports/CURRENT_GAPS.md` — G-005 / G-007 / G-009
|
||||
|
||||
---
|
||||
|
||||
|
||||
+17
-19
@@ -1,6 +1,6 @@
|
||||
# 稳定工程基线指南
|
||||
|
||||
- **更新时间**:2026-08-03
|
||||
- **更新时间**:2026-09-04
|
||||
- **目标**:让工作区处于可继续开发核心功能的可信状态。
|
||||
|
||||
---
|
||||
@@ -37,28 +37,26 @@ make lint
|
||||
cargo test --workspace
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets -- -D warnings
|
||||
go test ./...
|
||||
go test ./internal/api/... ./internal/backendrpc/...
|
||||
go vet ./...
|
||||
```
|
||||
|
||||
说明:
|
||||
|
||||
1. 当前已有 `internal/backendrpc` fake socket 单测、`cmd/bat` 试验骨架和 `internal/ffi` 兼容包装;这些不代表 CLI/API 产品入口已完成。
|
||||
2. 后续新增 Go 产品 package,必须让 `go test ./...` 和 `go vet ./...` 纳入硬性验证。
|
||||
3. 当前 `golangci-lint` 可选;当 Go 代码进入主要开发阶段后,应纳入本地门禁。
|
||||
1. 默认 Go 测试只覆盖正式 `bat-api` 依赖的纯 Go 包:`internal/api` 和 `internal/backendrpc`;`make test-go-ffi` / `make test-go-all` 才会包含 FFI 和试验 CLI。
|
||||
2. `make check` 当前直接执行 `go vet ./...`,因此会检查所有已存在的 Go 包;新增 Go 产品 package 后,必须同时纳入默认测试门禁。
|
||||
3. `golangci-lint` 当前仍是可选补充门禁;Go 的硬性验证是默认 API 测试、全量 `go vet` 和 `bat-api` 构建。
|
||||
4. 官方同步相关修改必须额外运行 `cargo test -p bat-infrastructure --bin bat -- --nocapture`。
|
||||
|
||||
如果构建环境的默认 Go cache 不可写,可将 `GOCACHE` 指向工作区外的临时目录,例如
|
||||
`GOCACHE=/tmp/bat-go-cache`。
|
||||
|
||||
---
|
||||
|
||||
## 3. Git 基线
|
||||
|
||||
当前工作区原 `.git/` 是空目录,无法恢复原历史。本基线采用新初始化仓库,并以首次提交作为后续开发起点。
|
||||
|
||||
首次提交信息:
|
||||
|
||||
```text
|
||||
chore: establish development baseline
|
||||
```
|
||||
当前工作区以现有 Git 分支和提交为基线;原项目历史未恢复。提交前应确认工作区
|
||||
只包含本次有意修改,并核对文档、源码和测试状态。
|
||||
|
||||
提交前检查:
|
||||
|
||||
@@ -86,15 +84,15 @@ git check-ignore -v Cargo.lock CLAUDE.md AGENTS.md CONTRIBUTING.md
|
||||
|
||||
---
|
||||
|
||||
## 5. 下一阶段入口
|
||||
## 5. 当前开发入口
|
||||
|
||||
CAS V1 和 Rust 官方同步闭环完成后,下一阶段优先推进:
|
||||
当前开发优先推进:
|
||||
|
||||
1. 继续联调 Go `bat-api` 与 Rust daemon 的资源分发路径;Go 同步 CLI 不再作为产品目标。
|
||||
2. 按 `docs/guides/official-full-pull-smoke.md` 在隔离目录执行真实官方网络全量下载 smoke,并保留运行报告。
|
||||
3. 基于 `translation.worker.run` 推进翻译记忆和通用 manifest Patch 构建。
|
||||
4. 扩展 ResourceRepository 查询面:更丰富的 TextUnit 查询、翻译记忆查询和通用 Patch 发布所需资源视图。
|
||||
5. 继续完善 AssetBundle 复杂对象解析、复杂对象重打包和通用 Patch 发布流程统一;通用 Binary/JSON/Text Patch 基础与受支持 localized patch 发布/rollback 链路已可用。
|
||||
1. 继续 AssetBundle 复杂对象解析、真实 fixture 和发布级重打包。
|
||||
2. 基于 `translation.worker.run` 推进翻译记忆和通用 manifest Patch 构建。
|
||||
3. 扩展 ResourceRepository 查询面:更丰富的 TextUnit 查询、翻译记忆查询和通用 Patch 发布所需资源视图。
|
||||
4. 按 `docs/guides/official-full-pull-smoke.md` 在隔离目录执行真实官方网络全量下载 smoke,并保留运行报告。
|
||||
5. 在资源和翻译契约稳定后推进完整 Web 协作后台和完整游戏业务 API。
|
||||
|
||||
优先阅读:
|
||||
|
||||
|
||||
@@ -339,4 +339,4 @@ release。Go 只做鉴权、参数校验和转发,状态与产物仍由 Rust
|
||||
|
||||
## 边界
|
||||
|
||||
解析器新增类型覆盖和新的解析格式仍受 `docs/reports/PARSER_FREEZE.md` 约束。本次 issue 43 的例外只开放已有解析输出的手动编排、缓存刷新、工作台编辑、既有 patch 实现的重打包和独立汉化发布,不扩展 UnityFS/AssetBundle/Addressables/TypeTree 的解析类型覆盖。
|
||||
解析器新增类型覆盖和新的解析格式当前按路线图推进;新增覆盖仍需通过真实 fixture、回归测试和文档同步验收,不要只靠合成样本宣称能力。
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
#### Go
|
||||
```bash
|
||||
# 安装 Go 1.22+
|
||||
# 安装 Go 1.26.4+
|
||||
# 参考:https://golang.org/doc/install
|
||||
|
||||
go version # 验证安装
|
||||
@@ -118,9 +118,9 @@ git push origin feature/your-feature-name
|
||||
|
||||
禁止使用 demo、临时实现、硬编码路径或只为当前测试通过的伪实现。确实未完成的能力应写入当前缺口文档,而不是用 `TODO` 或 `FIXME` 隐藏。
|
||||
|
||||
### 解析模块冻结
|
||||
### 解析模块状态
|
||||
|
||||
UnityFS / AssetBundle / Addressables / TypeTree 解析当前处于维护冻结。冻结期不得新增解析类型、扩大解析覆盖、开放新的写入型解析 RPC/CLI,或用合成 fixture 宣称新增能力。允许变更仅限编译、测试、clippy、真实运行回归、诊断和文档一致性修复。细则见 `docs/reports/PARSER_FREEZE.md`。
|
||||
UnityFS / AssetBundle / Addressables / TypeTree 解析当前按路线图继续推进。新增解析类型、扩大解析覆盖和写入型解析 RPC/CLI 仍需遵守现有接口边界、真实 fixture 和回归验收要求。
|
||||
|
||||
### Go
|
||||
- 遵循 [Effective Go](https://golang.org/doc/effective_go)
|
||||
@@ -143,7 +143,7 @@ UnityFS / AssetBundle / Addressables / TypeTree 解析当前处于维护冻结
|
||||
### 合并前通用门禁
|
||||
|
||||
```bash
|
||||
cargo fmt --check
|
||||
cargo fmt --all -- --check
|
||||
cargo test --workspace
|
||||
cargo clippy --workspace --all-targets -- -D warnings
|
||||
make test-go-api
|
||||
@@ -192,7 +192,7 @@ cargo clippy -p bat-core -p bat-adapters -p bat-infrastructure --all-targets --
|
||||
|
||||
`bat-ffi` 只是可选无状态 C ABI 兼容层。修改 FFI 时必须运行 `cargo test -p bat-ffi -- --nocapture`。Go 服务层默认经 `internal/backendrpc` 调 daemon;同步任务由 Rust `bat` 执行,不由 Go 试验 CLI 承担。
|
||||
|
||||
Rust `bat` 的资源拉取、解析、翻译工作流、重打包、汉化发布和持久化调度命令见 [`docs/guides/bat-workflows.md`](bat-workflows.md)。推荐使用 `res`、`parse`、`i18n` 三个一级命令;该工作流当前对应 issue `#43`。
|
||||
Rust `bat` 的资源拉取、解析、翻译工作流、重打包、汉化发布和持久化调度命令见 [`docs/guides/bat-workflows.md`](bat-workflows.md)。推荐使用 `res`、`parse`、`i18n` 三个一级命令。
|
||||
|
||||
### 集成测试
|
||||
|
||||
@@ -273,7 +273,7 @@ cargo run -p bat-infrastructure --bin bat -- resource-index --limit 50
|
||||
cargo run -p bat-infrastructure --bin bat -- resource-index --release-id <ID> --platform windows --archive-entry <PATH> --format json --limit 50
|
||||
```
|
||||
|
||||
issue 47 的隔离回归测试:
|
||||
历史 release/CAS 复用的隔离回归测试:
|
||||
|
||||
```bash
|
||||
cargo test -p bat-infrastructure official_download::tests::reuses_verified_historical_release_when_cdn_root_changes -- --nocapture
|
||||
@@ -416,7 +416,8 @@ cargo fetch
|
||||
|
||||
`bat-ffi` 不是主集成边界,只用于需要 C ABI 的兼容场景。当前 Go 正式产品入口是
|
||||
`bat-api` 资源 bootstrap/分发服务,默认通过 `internal/backendrpc` 调用 daemon RPC;
|
||||
`cmd/bat` 仍是试验 CLI。未来新增 Go 集成仍优先使用 Rust `bat --json` 进程边界或稳定 RPC/SDK。
|
||||
`cmd/bat` 仍是试验 CLI。新的 Go 集成优先使用 Rust `bat.sock` RPC 或稳定 SDK;
|
||||
`bat --json` 仅是 Rust CLI 的机器输出形态。
|
||||
|
||||
重新构建兼容库:
|
||||
```bash
|
||||
|
||||
@@ -343,7 +343,7 @@ make official-smoke
|
||||
|
||||
默认输出在 `/tmp/bat-official-smoke-<UTC timestamp>/`,脚本会执行 dry-run plan、首次全量拉取、二次 `up_to_date`、本地文件破坏后的 `repair`、repair 后 `verify`,并检查 stderr progress log 中存在下载已完成计数、单文件进度和校验结果摘要。完整说明见 `docs/guides/official-full-pull-smoke.md`。
|
||||
|
||||
## 7. 例外输入
|
||||
## 7. 输入模式
|
||||
|
||||
可接受的 `server-info` 输入是:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# bat-api / Rust bat Contract Fixture Handoff
|
||||
|
||||
更新时间:2026-09-02
|
||||
更新时间:2026-09-04
|
||||
|
||||
本文用于两个 Codex 窗口之间间接联调 `bat-api` 与 Rust `bat` 的跨语言 contract fixture。
|
||||
仓库内归一化 fixture 已交付;本文保留生成、审核和后续扩展的协作协议。
|
||||
|
||||
+95
-530
@@ -1,585 +1,150 @@
|
||||
# 当前实现缺口清单
|
||||
|
||||
- **更新时间**:2026-09-02
|
||||
- **Go 进度权威**:`GO_STATUS.md`
|
||||
- **资源布局 / 逆向契约**:`../architecture/resource-release-layout.md`
|
||||
- **用途**:集中跟踪当前代码中的占位实现、设计缺口和下一步验收项。
|
||||
- **更新时间**:2026-09-04
|
||||
- **文档角色**:只记录尚未完成、仍需验证或仍需设计的工作,不重复维护完整实现状态。
|
||||
- **当前事实**:以源码、测试、稳定契约和 `CURRENT_STATUS.md` 为准。
|
||||
- **Go 进度**:`GO_STATUS.md`
|
||||
- **资源布局契约**:`../architecture/resource-release-layout.md`
|
||||
- **权威计划**:`../../PROJECT_PLAN.md`
|
||||
- **历史资料**:`docs/archive/` 和 `docs/reports/historical/` 只用于追溯。
|
||||
|
||||
---
|
||||
## 1. 当前工程缺口
|
||||
|
||||
## 1. 基线缺口
|
||||
### G-005:AssetBundle 复杂解析仍未完成
|
||||
|
||||
### G-001:Git 元数据不可用
|
||||
状态:**部分完成,继续推进**
|
||||
|
||||
状态:**已关闭,采用新初始化基线**
|
||||
当前已具备 UnityFS 容器校验、directory 文件提取、serialized file
|
||||
object/type table/TypeTree 元数据、TextAsset、基础 MonoBehaviour 和
|
||||
ScriptableObject 字段读取、TextUnit 提取,以及受支持字段的文件级重建。
|
||||
|
||||
原现象:
|
||||
仍需完成:
|
||||
|
||||
- `.git/` 是空目录。
|
||||
- `git status` 报 `not a git repository`。
|
||||
- 用真实资源 fixture 覆盖更多 MonoBehaviour、ScriptableObject、Unity 版本差异、
|
||||
复杂容器和 managed reference registry/map entry 变体。
|
||||
- 为未知字段补充结构语义;不能把低保真猜测当作已支持格式。
|
||||
- 完成发布级复杂对象重打包,并把 bundle、serialized file、path id、class id、
|
||||
field path、offset 和 byte size 的定位信息贯通到稳定发布流程。
|
||||
|
||||
处理结果:
|
||||
现有证据:`crates/bat-assetbundle` 的单元/重建测试、隔离真实 UnityFS 回归和
|
||||
`bat-infrastructure` 的解析缓存测试。新增格式覆盖必须同时补真实 fixture、回归测试
|
||||
和文档。
|
||||
|
||||
- 已执行 `git init`。
|
||||
- 已将初始分支调整为 `main`。
|
||||
- 已配置当前路径为 Git safe directory。
|
||||
- `git status --short --branch` 已可用。
|
||||
- 本轮创建首次基线提交。
|
||||
### G-006:通用 Patch 发布仍未完成
|
||||
|
||||
限制:
|
||||
状态:**基础完成,发布流程部分完成**
|
||||
|
||||
- 原项目历史未恢复。
|
||||
- 后续历史从当前基线提交开始。
|
||||
`bat-patch` 已提供 Binary/JSON/Text Patch、manifest、BLAKE3/size 校验和
|
||||
rollback 元数据;文件级 `patch.apply` 与受支持的 UnityFS TextAsset、TypeTree
|
||||
string field、managed-reference string field 写入及 localized publish/rollback
|
||||
已可用。
|
||||
|
||||
验收:
|
||||
仍需完成:
|
||||
|
||||
- `git log --oneline -1` 能看到基线提交。
|
||||
- 通用 manifest 驱动的跨类型 patch build/apply/publish/rollback。
|
||||
- 复杂 AssetBundle 重打包和完整翻译文件集合构建。
|
||||
- 原版 release 与 localized release 双发布后的查询、分发和清理策略。
|
||||
|
||||
### G-002:CAS 有两套实现边界
|
||||
所有发布产物必须先进入独立 staging,通过完整性校验后再原子发布;失败不得改变
|
||||
已发布的 `bat-resources/current` 或 `bat-localized/current`。
|
||||
|
||||
状态:**已关闭**
|
||||
### G-007:Addressables 完整兼容仍未完成
|
||||
|
||||
原现象:
|
||||
状态:**当前 JSON/compact 目标字段完成,独立二进制格式待后续**
|
||||
|
||||
- `crates/bat-cas-engine/src/storage.rs` 有文件系统存储。
|
||||
- `infrastructure/src/cas/filesystem.rs` 也实现了文件系统 CAS repository。
|
||||
当前 JSON/compact catalog 已覆盖 path、hash、size、address、dependencies、
|
||||
provider、bundle name、resource type 和 CRC,并有 fixture/golden 回归。
|
||||
|
||||
处理结果:
|
||||
仍需完成:
|
||||
|
||||
- `crates/bat-cas-engine` 新增 `repository` 组合层,成为 CAS 核心实现。
|
||||
- `infrastructure/src/cas/filesystem.rs` 已改为 `bat-core::CasRepository` 适配层。
|
||||
- infrastructure 不再直接写对象文件,不再维护自己的引用计数逻辑。
|
||||
- 更多 Windows/Android 真实 catalog 形态和失败诊断。
|
||||
- 独立二进制 catalog 入口;在未支持前必须明确拒绝,不得静默丢字段。
|
||||
|
||||
验收证据:
|
||||
### G-009:`bat-api` 仍是资源服务,不是完整官方游戏 API
|
||||
|
||||
- `bat-cas-engine::repository::FileSystemCasRepository`
|
||||
- `bat_infrastructure::FileSystemCasRepository`
|
||||
- `cargo test --workspace`
|
||||
状态:**资源 bootstrap/分发和管理控制面已可用,业务 API 未完成**
|
||||
|
||||
### G-003:CAS 引用计数和 GC 未实现
|
||||
当前 `cmd/bat-api` 通过 `bat.sock` 读取 Rust 已发布 release,提供 bootstrap、
|
||||
launcher 资源引导兼容、只读 CDN path、readiness、OpenAPI、鉴权管理入口和内嵌
|
||||
dashboard。Rust `bat` 继续拥有资源发现、下载、校验、staging、发布、任务和长期状态。
|
||||
|
||||
状态:**已关闭**
|
||||
仍需完成:
|
||||
|
||||
原现象:
|
||||
- 完整游戏业务 API、账号/登录/网关链和完整 launcher 安装包更新链。
|
||||
- 更丰富的 Resource/TextUnit/翻译记忆查询面。
|
||||
- 真实官方网络长期运行报告;运行使用 `make official-smoke`,产物留在隔离目录。
|
||||
|
||||
- `FileSystemCasRepository::add_reference` 返回固定 `1`。
|
||||
- `remove_reference` 返回固定 `0`。
|
||||
- `get_reference_count` 返回固定 `1`。
|
||||
- `gc` 返回固定 `0`。
|
||||
- `crates/bat-cas-engine/src/refcount.rs` 是占位。
|
||||
`bat-api` 不得复制 Rust 下载器、CAS、AssetBundle 解析、Patch 核心算法或同步状态机。
|
||||
|
||||
处理结果:
|
||||
### G-010:完整 Web 协作后台仍未完成
|
||||
|
||||
- `crates/bat-cas-engine/src/refcount.rs` 使用 SQLite 保存对象元数据和引用计数。
|
||||
- `store()` 会存储对象并增加引用计数。
|
||||
- `add_reference()`、`remove_reference()`、`get_reference_count()` 已持久化。
|
||||
- `gc()` 删除引用计数为 0 的对象和元数据。
|
||||
- `gc_candidates()` 提供 dry-run 能力。
|
||||
状态:**内嵌 dashboard MVP 已完成,完整后台未开始**
|
||||
|
||||
验收证据:
|
||||
当前页面可以调用已有资源、调度、任务、解析、翻译和 localized 控制接口。
|
||||
|
||||
- 引用计数增减有持久化测试。
|
||||
- GC 不删除仍被引用对象。
|
||||
- 并发引用更新测试通过。
|
||||
仍需完成:
|
||||
|
||||
---
|
||||
- 独立登录、角色权限和协作式翻译审核。
|
||||
- Glossary/术语管理、批量审核、搜索和完整历史版本视图。
|
||||
- 构建型前端工程、浏览器 E2E 和完整错误态交互门禁。
|
||||
|
||||
## 2. 核心功能缺口
|
||||
### G-011:ResourceRepository 查询面仍不完整
|
||||
|
||||
### G-004:CAS 写入不是生产级原子流程
|
||||
状态:**部分完成**
|
||||
|
||||
状态:**已关闭**
|
||||
当前已支持 CAS + SQLite 导入、资源类型/release/平台/path/parse status/TextUnit
|
||||
format 等资源级过滤,`parse.text_units` / `parse.errors` 和翻译任务查询也已可用。
|
||||
|
||||
原现象:
|
||||
仍需完成:
|
||||
|
||||
- 当前写入直接写目标路径。
|
||||
- 缺少临时文件、fsync、原子 rename、并发冲突处理。
|
||||
- 更丰富的 TextUnit、翻译记忆和 Patch 发布资源视图。
|
||||
- 从同一 manifest fingerprint 追溯资源、解析缓存、翻译任务和发布产物。
|
||||
- 更多 schema 迁移、权限、并发和损坏恢复场景验证。
|
||||
|
||||
处理结果:
|
||||
### G-011D:双 release 的完整查询与发布策略仍未完成
|
||||
|
||||
- `FileSystemStorage::put()` 使用临时文件写入、文件 sync、原子 rename、目录 sync。
|
||||
- 读取对象时强制 Hash 校验。
|
||||
- 并发写入相同内容只保留一个对象,引用计数按调用次数递增。
|
||||
- 损坏对象读取返回 `HashMismatch`。
|
||||
状态:**受支持范围完成,通用范围部分完成**
|
||||
|
||||
验收证据:
|
||||
官方原版和 localized release 已分离,受支持 patch 可独立 staging、校验、发布和
|
||||
rollback,`localized.status` 能校验当前官方 release 与 patch manifest 的一致性。
|
||||
|
||||
- 写入失败不会留下可见半成品对象。
|
||||
- 并发写入相同内容只产生一个对象。
|
||||
- 读取时 Hash 不匹配会返回明确错误。
|
||||
|
||||
### G-005:AssetBundle 引擎解析器仍未完成
|
||||
|
||||
状态:**UnityFS 基础容器校验目标完成,复杂对象能力仍部分完成**
|
||||
|
||||
冻结状态:自 2026-07-30 起,G-005 不再作为默认推进项。解析层只接受维护冻结规则允许的稳定性修复、诊断修复、真实回归修复和文档校正;新增 TypeTree 语义类型、扩大解析覆盖和新增写入型解析入口全部暂停。冻结细则见 `docs/reports/PARSER_FREEZE.md`。
|
||||
|
||||
现象:
|
||||
|
||||
- `crates/bat-assetbundle` 已接管 UnityFS 解析,提供 `UnityFsParser`、`UnityFsBundle`、header、block info、directory、压缩模式、block info at end、LZ4/LZMA block info 解压、数据 block 解压、alignment、总大小/计数/路径/目录边界诊断、directory 文件提取。
|
||||
- `crates/bat-assetbundle::serialized` 已提供 Unity serialized file header、type table、TypeTree node 元数据、object table、TextAsset bytes 和基础 TypeTree field reader。
|
||||
- `adapters/src/unity/unity_2021_3.rs` 已降为 Unity 版本选择薄层,复用 `bat-assetbundle`,不再维护第二套 UnityFS parser。
|
||||
- `ResourceImportService` 的 UnityFS 摘要已经能暴露解包文件数、serialized file 数、TextAsset 名称、TextUnit 数量/格式和字段诊断。
|
||||
- `MonoBehaviour`、`ScriptableObject` 已有基础 TypeTree 字段级反序列化和字符串提取入口;array/vector/staticvector/`List<T>`/`HashSet<T>`/map 元素与 TypeTree-covered managed reference registry payload 已保留独立 field path、offset 和 byte size,enum `value__` backing field 会暴露为语义化 `{type_name, storage_type, value}`,`LayerMask` / `BitField` 的 `m_Bits` backing field 会暴露为语义化 `{type_name, storage_type, bits}`,managed-reference full typename 可拆为 assembly/namespace/class,常见 `m_ManagedReferences` / `RefIds` / `m_RefIds` / verbose type 字段命名、`managedReference*` / `serializedReference*` prefixed metadata、`SerializedReference` 节点 alias 和 `data` / `value` / `payload` / `object` / `managedReferencePayload` / `referencePayload` / `serializedReferencePayload` / `managedReferenceValue` / `referenceValue` / `serializedReferenceValue` / `managedReferenceObject` / `referenceObject` / `serializedReferenceObject` / `managedReferenceData` / `referenceData` / `serializedData` / `serializedReferenceData` payload 命名已有回归覆盖,多记录 registry 聚合已有单元回归,TextUnit 提取会跳过 registry 元数据字符串并把它们作为 payload 文本上下文,fallback 字段遍历也会跳过常见 managed-reference 元数据别名,并按 `RefIds[n]` 等记录前缀或子字段推导 metadata 写入 payload TextUnit context;当前可对 string、bool、integer、float raw bits、bytes、enum、bit_field、常见固定 Unity float/int/hash 值类型的 leaf/direct-child 形态、unknown fixed-size raw bytes 同长度替换、PPtr、object 字段组合和 TypeTree schema 支撑的 array/vector/List/HashSet/map 整体替换执行文件级 patch,map entry 的 `first/second` 与 `key/value` 字段命名已有 serialized 和 UnityFS 重建回归,ScriptableObject `key/value` map 解析、变长替换和 UnityFS 重建已有专门回归;真实版本差异、未见样本驱动的复杂 managed reference registry / map entry 变体、unknown 字段结构语义和发布级重打包入口仍未完成。
|
||||
|
||||
issue 43 例外说明:新增的 `parse repack` 只编排已有 TextAsset、TypeTree string 和受支持语义 field patch 实现;它不新增解析器类型、字段族或 catalog 覆盖。人工翻译工作台和 localized publish 只消费已有 TextUnit 输出,当前 publish 支持 TextAsset、TypeTree string field 和 managed-reference string field。
|
||||
|
||||
影响:
|
||||
|
||||
- 可以对 UnityFS 容器做结构校验、解包 directory 文件,并提取 serialized file 中的 TextAsset 原始 bytes。
|
||||
- 对日语汉化最关键的 TextAsset 索引、bytes、JSONL TextUnit、MonoBehaviour/ScriptableObject 基础字符串字段、array/vector/List/HashSet/map 字符串元素和 TypeTree-covered managed reference payload 提取已有入口;managed-reference 类型元数据作为上下文保留,不进入翻译文本队列,fallback registry 字段遍历也会过滤常见元数据别名,并按记录前缀或子字段保留可推导 metadata。文件级 UnityFS 重建可覆盖 TextAsset、TypeTree string 字段、managed-reference registry payload 字符串、基础语义字段、enum、bit_field、unknown fixed-size raw bytes、object 字段组合和 TypeTree schema 支撑的 array/vector/List/HashSet/map 整体替换,但还不能完成发布级复杂对象重打包。
|
||||
|
||||
当前验收证据:
|
||||
|
||||
- `crates/bat-assetbundle` 能解析结构化测试样本和隔离真实样本;新增 UnityPy `char_118_yuki.ab` 真实 bundle 回归入口,样本只下载到 `/tmp`,不入库。
|
||||
- 支持 UnityFS header、blocks、directory、metadata 摘要、directory 文件提取,并拒绝声明总大小不符、计数越界、重复/不安全路径和目录数据越界。
|
||||
- 支持 Unity serialized file object table、TypeTree node 元数据和 TextAsset 提取的合成 fixture。
|
||||
- 错误包含偏移和字段上下文。
|
||||
|
||||
关闭前仍需:
|
||||
|
||||
- 冻结解除前不继续扩大 TypeTree 字段 reader 覆盖。当前 TypeTree-covered managed reference 字段与 registry 记录已可结构化解码,`m_ManagedReferences`、`RefIds` / `m_RefIds`、verbose type 字段、`managedReference*` / `serializedReference*` metadata、payload/value/object 家族、`managedReferenceData` / `referenceData` / `serializedData` / `serializedReferenceData` payload、多记录 registry 聚合、enum `value__` backing field、`LayerMask` / `BitField` 的 `m_Bits` backing field、固定 Unity float/int/hash 值类型 leaf/direct-child 形态、unknown fixed-size raw bytes 同长度替换、嵌套 vector `Array` 形态、`List<T>` / `HashSet<T>` 集合 alias、`first/second` 与 `key/value` map entry schema、空 array/vector/List/HashSet/map 扩容已有合成 fixture 覆盖;剩余真实版本差异、unknown 字段结构语义、更多 nested collection、managed reference registry / map entry 变体只记录为冻结后的工作。
|
||||
- 用真实 fixture 继续覆盖 MonoBehaviour、ScriptableObject 字段级遍历和字符串策略。
|
||||
- 输出可追溯文本定位:bundle path、archive entry、serialized file、path id、class id、field path、字段 offset/byte size。
|
||||
- 用真实资源 fixture 覆盖对象级解析、TextAsset 提取和字段级文本提取。
|
||||
- 将解析结果作为 Patch 输入;真正的重打包、Patch 生成和 `localized` 发布切换归 G-006/G-011D。
|
||||
|
||||
解析补全路线图:
|
||||
|
||||
- 见 `docs/architecture/assetbundle.md` 的 P2/P3/P5。
|
||||
|
||||
### G-006:Patch 引擎基础已落地,通用发布入口仍未完成
|
||||
|
||||
状态:**部分关闭**
|
||||
|
||||
已完成:
|
||||
|
||||
- `bat-patch::binary` 已提供确定性 Binary hunk diff/apply,应用前校验 source size/BLAKE3,应用后校验 target size/BLAKE3。
|
||||
- `bat-patch::json` 已提供 RFC 6902 JSON Patch apply,覆盖 add/remove/replace/move/copy/test 和 JSON Pointer escape。
|
||||
- `bat-patch::text` 已提供 UTF-8 Text Patch,按 source-relative byte range 替换,支持 expected 文本校验、UTF-8 边界校验、source/target BLAKE3 和 size 校验。
|
||||
- `bat-patch::manifest` 已定义通用 Patch manifest、文件级 patch kind、source/target BLAKE3、size、rollback 元数据和 manifest 文件完整性校验。
|
||||
- `LocalizedPatchManifest` 可转换为通用 `bat_patch::PatchManifest`,UnityFS TextAsset 发布链路和通用 Patch manifest 已有类型对齐点。
|
||||
- `infrastructure::patch_ops`、`patch.apply` RPC 和 `patch-apply` CLI 已开放文件级 Binary/JSON/Text patch apply;输入/输出为显式文件路径,输出原子写入并返回 size/BLAKE3。
|
||||
- `unityfs.patch_text_asset` / `unityfs.patch_string_field` / `unityfs.patch_field` RPC 和 `unityfs-patch-text-asset` / `unityfs-patch-string-field` / `unityfs-patch-field` CLI 已开放显式 UnityFS bundle 文件写入;TextAsset、TypeTree string 字段、managed-reference registry `data` / `managedReferenceData` payload 字符串、基础语义字段、enum、bit_field、固定 Unity 值类型 leaf/direct-child 形态、unknown fixed-size raw bytes、object 字段组合和 TypeTree schema 支撑的 array/vector/List/HashSet/map 整体替换会在重建后重新解析校验。
|
||||
|
||||
影响:
|
||||
|
||||
- 通用 Binary/JSON/Text Patch crate 能力可作为后续发布流程输入。
|
||||
- 文件级写入入口可用于隔离测试和上层工具显式产物生成。
|
||||
- 发布级通用 `patch build` / `patch rollback`、复杂 AssetBundle 重打包和完整翻译文件集合的正式使用仍未完成;issue 43 的 `parse repack`、`parse clear-cache`、`i18n validate` 与 `i18n publish` 仅覆盖已有 patch 实现支持的安全子集。
|
||||
|
||||
验收:
|
||||
|
||||
- Binary patch 能完成 diff/apply 往返。
|
||||
- JSON patch 能应用 RFC 6902 patch。
|
||||
- Patch manifest 包含 hash、版本和回滚信息。
|
||||
- Patch 构建/应用必须写 staging,完整性校验通过后才能发布。
|
||||
- `patch.apply` / `patch-apply` 对显式文件执行 apply 时必须原子写目标文件,并返回 source/patch/target hash 与 size。
|
||||
- 失败时不得影响 `bat-resources/current` 或已发布 `bat-localized/current`。
|
||||
|
||||
### G-007:Addressables Catalog 解析不完整
|
||||
|
||||
状态:**当前目标字段已关闭,独立二进制格式待后续**
|
||||
|
||||
现象:
|
||||
|
||||
- `AddressablesCatalogDriver` 已能解析当前真实形态 JSON catalog fixture/golden。
|
||||
- 已输出 path、hash、size、resource_type、address、dependencies、provider ID、bundle name、metadata,并已提取 `m_Crc` 到 `crc` 字段。
|
||||
- compact catalog 解析已补充 hash/size/CRC 的非 0 回归、资源计数 metadata,以及 blob 解码失败时的明确错误;不再在 compact 字段损坏时静默退回低保真 `m_InternalIds`。
|
||||
- `bat-core` 已提供 `crc32_ieee` 和 `ResourceEntry::verify_downloaded_bytes`,SQLite `ResourceRepository` 已有 `crc`、provider_id、bundle_name 兼容迁移。
|
||||
- 当前 JSON/compact 目标字段已通过 expanded、alias、compact 和真实形态 golden 回归;独立二进制 catalog 仍明确拒绝,不静默丢字段。
|
||||
|
||||
影响:
|
||||
|
||||
- 当前解析能力可以服务 Manifest inspect 和部分资源索引,但还不能宣称完整兼容所有 Unity Addressables/SBP catalog 形态。
|
||||
|
||||
验收:
|
||||
|
||||
- 能解析项目目标版本的真实 Catalog 样本集合。
|
||||
- 解析结果包含资源 key、provider、dependency、hash、size、path、bundle name、CRC。
|
||||
- 对不支持的 catalog 结构返回明确错误,而不是静默丢字段。
|
||||
- 解析结果能反查 bundle 文件、依赖链和本地下载 manifest 条目。
|
||||
- Windows/Android 样本集合需要覆盖 JSON、compact JSON 和后续二进制 catalog 入口。
|
||||
|
||||
解析补全路线图:
|
||||
|
||||
- 见 `docs/architecture/assetbundle.md` 的 P1。
|
||||
|
||||
---
|
||||
|
||||
## 3. 应用层缺口
|
||||
|
||||
### G-008:Go 同步/运维 CLI 产品入口
|
||||
|
||||
状态:**已决策关闭(wontfix)**
|
||||
|
||||
决策(2026-07-24,见 `GO_STATUS.md`):
|
||||
|
||||
- **正式同步/运维命令行 = Rust `bat`**(近乎全自动:auto-discover + watch/daemon,无需持久手操维护)。
|
||||
- **不另做**产品级 Go 同步 CLI,避免与 Rust `bat` 双轨。
|
||||
- Go 试验入口 `cmd/bat` 可保留为 experimental,产物必须为 `bin/bat-go`,**禁止**再构建为 `bin/bat`。
|
||||
- Go 正式产品入口集中在 **`bat-api` 资源 bootstrap/分发服务** + `internal/backendrpc`(G-009)。
|
||||
|
||||
原验收(真实 doctor / Go sync 包装)**不再作为当前里程碑**。
|
||||
|
||||
### G-009:API Server(`bat-api`,资源 bootstrap/分发)部分完成
|
||||
|
||||
状态:**资源 bootstrap + CDN MVP 已落地;非完整官方游戏 API**
|
||||
|
||||
目标(对应 issue #19,**按资源面收窄**):
|
||||
|
||||
- `cmd/bat-api`:组织 Rust `bat` 已发布 release 的启动前资源入口,并只读分发官方 CDN host/path 形态资源。
|
||||
- **拉取归属 Rust `bat`**;`bat-api` 不做下载器。
|
||||
- 发现经 `bat.sock`:先 `daemon.status`,再 `daemon.doctor`,再 `catalog.status` / `resource.manifest`。
|
||||
- Rust RPC 的 `resource.state`、`catalog.status`、`parse.status` 和 `localized.status` 会返回短状态 `status` 与稳定生命周期状态码 `status_code`;`backendrpc` 已提供对应 client 能力,当前 `bat-api` 发现流程只消费 `resource.state`、`catalog.status`、`resource.manifest`,translation task/handoff 通过受鉴权的 admin 查询端点暴露,parse/localized 不由 HTTP surface 暴露;错误原因仍以 `BAT-ERR-*` 为准。
|
||||
- `bat-api` 可通过受限 Web 控制面转发 `reload` / `refresh` / `restart` / `sync` / `verify` / `repair` / `catalog-refresh`,并通过 translation admin 端点查询/回写任务、触发 provider worker 和标记人工校对;这些动作均走 Rust live RPC;`parse.*`、`localized.status` 和文件级 `unityfs.patch_*` 属于 `backendrpc` 能力,但当前不由 HTTP surface 暴露;`daemon.clean-stable` 等危险或离线生命周期命令不经 Web 转发。
|
||||
- 生产与 Rust `bat` 同环境运行,资源根来自 RPC 返回的 `resource_root`;`--resource-root` 仅用于 fixture 或应急只读诊断。
|
||||
- `.env` 配置端口 / public base / RPC socket / RPC 刷新周期;预留 database/redis。
|
||||
- `/v1/bootstrap` 返回 RPC 健康、release 摘要、server-info URL、client-patch base 和改写后的 Addressables root。
|
||||
- `/v1/launcher/bootstrap` 和 `/api/launcher/...` 形状端点返回资源引导兼容信息,当前来源是 Rust `bat` 已发布 snapshot/RPC 中的 launcher metadata 与 GameMainConfig 摘要;Rust 侧已新增 release 内 `official-launcher-bootstrap.json` 版本化产物,后续 bat-api 字段统一和联调应以该产物加 RPC contract fixture 为准。
|
||||
- `/healthz` 暴露最近一次 RPC refresh 诊断;`/readyz` 在无可分发 release 时返回 `503`。
|
||||
- 玩家-facing HTTP 控制面必须支持 token 鉴权、限流、访问日志、反代 IP 适配、动态 JSON `no-store` 和 `/v1/resources` 分页上限。
|
||||
- CDN path 支持 `GET` / `HEAD` / `Range`、ETag、Last-Modified、Accept-Ranges 和长期缓存头。
|
||||
- launcher 完整安装包更新链、账号、登录、网关、游戏业务 API 和鉴权全链 **非关闭条件**;USERGUIDE 已补基础章节,联调后补生产排障样例。
|
||||
|
||||
已完成:
|
||||
|
||||
- `cmd/bat-api`、`internal/api`、`/v1/bootstrap`、`/v1/launcher/bootstrap`、launcher 资源 metadata 兼容端点、HTTP token 鉴权、限流、访问日志、反代 IP 适配、动态 JSON `no-store`、`/v1/resources` 分页上限、OpenAPI、`/admin/` 管理控制白名单、RPC 周期刷新/诊断、`/readyz`、CDN Range/缓存头、fixture 单测、USERGUIDE 基础章节、systemd bat-api 模板、`make build-go-api` / `test-go-api`
|
||||
- 进度权威:`docs/reports/GO_STATUS.md`
|
||||
- Rust snapshot schema 与 Go mirror struct 的仓库内 contract fixture 已完成,文件位于
|
||||
`internal/api/testdata/contract/`;同机 live daemon socket 和完整 fixture release 切换已由
|
||||
`make bat-api-local-live-smoke` 验证。
|
||||
|
||||
后续跟踪(不影响 issue #19 关闭):
|
||||
|
||||
- 同机 live 联调已完成(覆盖 bootstrap、server-info、CDN path、release 切换、无 release、RPC 断线/恢复);真实官方网络全量下载由 `make official-smoke` 独立跟踪
|
||||
- refresh 中 manifest 磁盘校验的 mtime/size 增量缓存优化(真实全量 release 观测后决定)
|
||||
- 文档与 GO_STATUS 持续一致
|
||||
|
||||
排期:P2 主体可联调;持久化 API 层与完整 launcher/业务链另议。
|
||||
|
||||
### G-010:完整 Web 管理后台仍未实现
|
||||
|
||||
现象:
|
||||
|
||||
- `web/` 已提供无构建内嵌 dashboard MVP,作为 `bat-api` 静态资产服务于
|
||||
`/admin/dashboard/`。
|
||||
- 当前页面可调用已鉴权的资源、调度、任务、日志、parse、翻译和 localized 发布/回滚
|
||||
接口,但不提供独立登录、角色权限、术语管理、批量审核工作流或构建型前端工程。
|
||||
|
||||
影响:
|
||||
|
||||
- 基础资源/调度/翻译控制可以在 dashboard 上完成。
|
||||
- 协作式翻译审核、术语管理和权限隔离仍缺少完整 UI。
|
||||
|
||||
验收:
|
||||
|
||||
- 登录、权限、翻译审核、术语管理基础流程可用。
|
||||
- Dashboard E2E、静态资产构建/发布策略和错误态交互纳入常规门禁。
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据与翻译缺口
|
||||
|
||||
### G-011:Resource Repository 查询面仍不完整
|
||||
|
||||
状态:**部分关闭**
|
||||
|
||||
影响:
|
||||
|
||||
- `SqliteResourceRepository` 已存在,可按领域 repository 接口保存资源元数据。
|
||||
- `ResourceImportService` 已能把 manifest 中有数据的资源写入 CAS + `ResourceRepository`,AssetBundle 会记录 UnityFS 摘要,TextAsset/Table/Media 会分类索引。
|
||||
- 官方同步下载结果可用 `--import-repository` / `BAT_IMPORT_REPOSITORY=1` 在已校验 release 发布后自动导入 CAS + ResourceRepository;默认 CAS 为 `<output>/.cas`,默认 SQLite 索引为 `<output>/resources.sqlite`,也可通过 `--import-cas-root`、`--import-resource-db`、`BAT_IMPORT_CAS_ROOT`、`BAT_IMPORT_RESOURCE_DB` 覆盖。
|
||||
- `resource.index` RPC/CLI 已能按资源类型、hash、路径模式、官方 release ID、平台、destination、bundle path、archive entry、parse status 和 TextUnit format 分页查询现有 SQLite 索引;release、平台、bundle path 和常用数组 metadata 过滤已下推到 SQLite;数据库不存在时返回 `available=false`,不会因查询创建空库。
|
||||
- `bat doctor cas` 可按 `<output>/.cas` 或 `--import-cas-root` 只读诊断既有 CAS 根目录、对象目录、元数据库文件和对象统计,缺失路径会报告为不健康,不会创建空库。
|
||||
- 官方 release 发布后会写出 `official-resource-changes.json` 和 `crowdin-translation-handoff.json`,新增+变更资源进入解析/翻译 handoff,删除资源只进入差异记录。
|
||||
- `Resource` metadata 已通过 SQLite `metadata_json` 兼容迁移保存 release、平台、bundle path、parse status、TextAsset 名称和 TextUnit 数量/格式;`resource.index` 会返回这些 metadata。
|
||||
- 官方 release 发布后会持久化 `official-textunit-index.json`,记录单条 TextUnit 和解析错误;`parse.text_units` / `parse.errors` RPC 和 `parse-text-units` / `parse-errors` CLI 可按 destination、archive entry、path id、class id、field path 和 format 分页过滤。
|
||||
- 官方 release 发布后会从 Added/Modified 资源、parse cache 和 TextUnit 明细索引派生 `official-textunit-tasks.json`、`crowdin-textunit-queue.json` 和 `translation-tasks.sqlite`;删除资源不会进入队列。
|
||||
- 官方 release 发布后还会写入版本化 `translation-handoff.json`;`translation.handoff` RPC/CLI 动态合并该快照与 SQLite worker 状态,暴露 job、unit、provider run、attempt 和 failure reason。
|
||||
- `translation-tasks.sqlite` 由 `schema_migrations` 管理 durable task state、attempt count、provider run ID 和 failure reason;重复同步会保留已有 worker 状态。
|
||||
- `translation.tasks` RPC/CLI 优先查询 `translation-tasks.sqlite`,旧 release 没有状态库时回退到 `official-textunit-tasks.json`;返回队列 `status`、worker `task_status`、failure reason 和时间/尝试次数。
|
||||
- `translation.tasks` / `translation.handoff` 已提供 Go typed helper 和 bat-api 鉴权查询端点;`translation.task.update` 已提供 queued/running/failed/completed/skipped 状态回写契约,并已通过 `bat i18n task update`、Go typed helper 和 bat-api 鉴权控制面暴露;`translation.worker.run` 已提供 Rust provider worker,支持 mock/Crowdin、独立 claim、lease、失败分类、重试和 TextUnit 级译文结果落库;`translation.proofread` 已提供人工校对状态标记契约。
|
||||
- issue #47 已补齐官方资源同步的历史 release 与 CAS 前置复用:按计划顺序生成结果、按共享队列动态领取任务、对复用源执行 size/BLAKE3/ZIP 校验,失败时保留诊断并回退网络;CAS release 引用写入版本化清单,staging GC 会先释放引用再删除目录。更丰富的 Resource 查询、翻译记忆和通用 Patch 发布仍属于后续缺口。
|
||||
- `i18n get/set/unset` 可查看、修改或清空单条工作台译文,`i18n validate` 可在发布前校验工作台 release、source text、重复 patch 目标,并区分可直接发布的 TextAsset 与必须进入 `parse repack` 的条目;`i18n proofread` 可把当前汉化 workflow 标记为人工校对中,且不会遮蔽已发布汉化 release;`parse clear-cache` 只删除可再生解析/队列 JSON,保留 `translation-tasks.sqlite` 的 worker 状态。
|
||||
- 翻译记忆和完整 localized repack 仍属于后续翻译系统工作,不在当前 provider worker 状态闭环范围内。
|
||||
|
||||
验收:
|
||||
|
||||
- schema 和迁移可重复执行。
|
||||
- 可按版本、平台、类型、hash、路径、destination、archive entry、parse status 和 TextUnit format 查询资源,且能明确区分索引缺失、版本缺失和空结果。
|
||||
- 官方同步后的资源可通过 CLI/RPC 查询并能追溯到 CAS 对象。
|
||||
- `official-parse-cache.json` 的 bundle、zip entry、TextAsset 和 TextUnit 摘要能进入 ResourceRepository 查询面。
|
||||
- `parse.status` 能报告 TextUnit 索引、TextUnit 队列路径与摘要。
|
||||
- `parse.text_units` / `parse.errors` 能分页查询当前 release 的 TextUnit 明细和解析错误。
|
||||
- 离线 TextUnit 翻译任务状态和跳过/失败 reason 可反查到对应官方 release、资源 destination 和 archive entry。
|
||||
- Crowdin handoff 被后续翻译 worker 消费后,worker 状态、远端失败原因和完成结果能反查到对应官方 release 与资源 destination。
|
||||
|
||||
解析补全路线图:
|
||||
|
||||
- 见 `docs/architecture/assetbundle.md` 的 P4。
|
||||
|
||||
### G-011A:资源导入链路基础能力不足
|
||||
|
||||
状态:**已关闭**
|
||||
|
||||
历史现象:
|
||||
|
||||
- 资源导入链路只导入 AssetBundle。
|
||||
- 非 AssetBundle manifest 条目只会被跳过。
|
||||
- 导入报告只包含 UnityFS 基础摘要,不包含稳定分类统计。
|
||||
|
||||
处理结果:
|
||||
|
||||
- `ResourceImportService` 会把有数据的 manifest 条目导入 CAS 并写入 `ResourceRepository`。
|
||||
- AssetBundle 仍执行 UnityFS header/block/directory 摘要解析。
|
||||
- TextAsset、TableBundle、Media 会按资源类型分类,缺少数据时记录为 skipped,便于渐进导入。
|
||||
- `ResourceImportReport` 增加 `category_counts`,`ImportedResource` 增加 `resource_type`、`category` 和可选 UnityFS 摘要。
|
||||
|
||||
验收:
|
||||
|
||||
- `cargo test -p bat-infrastructure import::tests::`
|
||||
- `cargo test -p bat-infrastructure --test synthetic_phase2_import`
|
||||
|
||||
### G-011B:官方版本状态管理不明确
|
||||
|
||||
状态:**已关闭**
|
||||
|
||||
历史现象:
|
||||
|
||||
- 当前可用版本主要靠 `current` symlink 和 release 内 snapshot 推断。
|
||||
- 未显式保存“正在拉取版本”和“失败版本”。
|
||||
- 上一个可用版本需要从目录状态间接判断。
|
||||
|
||||
处理结果:
|
||||
|
||||
- 新增 `<output>/official-version-state.json`。
|
||||
- 开始下载后写入 `in_progress_version`。
|
||||
- 发布成功后写入 `current_completed_version` 和 `previous_available_version`。
|
||||
- 失败或中断后写入 `failed_versions` 并清空 in-progress。
|
||||
- `bat status` 会读取并展示版本状态摘要。
|
||||
|
||||
验收:
|
||||
|
||||
- `cargo test -p bat-infrastructure version_state`
|
||||
- `cargo test -p bat-infrastructure --test official_game_main_config_bootstrap`
|
||||
|
||||
### G-011D:受支持汉化发布已完成,通用 Patch 发布流程仍未完成
|
||||
|
||||
状态:**部分关闭**
|
||||
|
||||
当前已完成:
|
||||
|
||||
- 官方原版资源发布根为 `./bat-resources`,汉化产物发布根为 `./bat-localized`。
|
||||
- CLI 支持 `--localized-output` / `BAT_LOCALIZED_OUTPUT`,并拒绝官方目录和汉化目录相同或互相嵌套。
|
||||
- 官方同步报告新增 `localized_release_status=not_localized`,明确表示原版资源已发布、汉化资源未发布;`translation.proofread` 只写 workflow 标记,不会把 `localized_release_status` 从 `localized` 回退成 `not_localized`。
|
||||
- `LocalizedPatchService` 已具备将给定汉化文件按官方相对路径发布到 `--localized-output` / `BAT_LOCALIZED_OUTPUT` 指定目录下的 `.staging/<id>`、校验后移动到 `versions/<id>`、原子切换 `current` 并写入 `localized-version-state.json` 的基础能力。
|
||||
- `LocalizedPatchService` 已写入结构化 `localized-patch-manifest.json`,记录 TextAsset、TypeTree string field 和 managed-reference string field 操作、原始/汉化 hash、size、byte delta、TextUnit/provider/review 和 rollback 信息;发布前后会校验 manifest hash/size 与 current symlink,失败时清理 staging / 未完成 version。
|
||||
- 已完成从 workbench 或 completed provider worker 结果生成受支持 patch operation 的流程;`localized.publish` / `localized.rollback` RPC、`i18n publish` / `i18n rollback` CLI,以及 bat-api 的鉴权 status/publish/rollback 接口已落地。
|
||||
- `localized.status` RPC 会读取 `.env` / daemon 配置中的汉化输出目录,校验汉化状态是否匹配当前官方 release,且要求 patch manifest 存在并匹配 release,避免写死 `./bat-localized` 或误报手工状态;其中 `status` / `status_code` 返回生命周期状态,`localized_release_status` 保留 `localized` / `not_localized` 发布标签,`translation_workflow_status=manual_proofreading` 仅描述人工校对流程,不影响已发布汉化资源继续正常发布。
|
||||
|
||||
仍未完成:
|
||||
|
||||
- 真实 Patch/翻译构建阶段尚未从 `crowdin-textunit-queue.json`、翻译记忆和 Crowdin 结果生成完整汉化文件集合。
|
||||
- 通用 Binary/JSON/Text Patch crate 基础和文件级 `patch.apply` / UnityFS 写入入口已经实现;通用 manifest 驱动的跨类型发布、复杂 AssetBundle 重打包和双发布后的清理策略仍未完成。
|
||||
- 尚未实现原版资源与汉化资源双发布后的查询、分发和清理策略。
|
||||
|
||||
验收:
|
||||
|
||||
- 原版资源同步成功后保持 `not_localized`,不发布半成品汉化资源。
|
||||
- Patch 构建和校验成功后,汉化产物按官方相对路径写入配置化汉化发布根下的 `versions/<id>`。
|
||||
- 汉化发布必须原子切换配置化汉化发布根下的 `current`,失败时不影响已发布原版资源。
|
||||
- `localized` 状态能证明原版和汉化两套资源都可发布,并能被 CLI/RPC/API 查询;缺 patch manifest 或 release 不匹配时不得返回 `localized`。
|
||||
|
||||
### G-011C:真实 fixture 与回归样本不足
|
||||
|
||||
状态:**已关闭当前阶段**
|
||||
|
||||
历史现象:
|
||||
|
||||
- 已有 Addressables real-shape fixture/golden,但缺少按问题类型命名的当前/上一版本/结构变化样本。
|
||||
- 403/404 和 hash mismatch 主要依赖单测内联构造,不便于后续回归扩展。
|
||||
|
||||
处理结果:
|
||||
|
||||
- 新增 `adapters/tests/fixtures/addressables_regression/current_catalog.json`。
|
||||
- 新增 `adapters/tests/fixtures/addressables_regression/previous_catalog.json`。
|
||||
- 新增 `adapters/tests/fixtures/addressables_regression/structure_changed_catalog.json`。
|
||||
- 新增 `infrastructure/tests/fixtures/official_regression/http_403.json`。
|
||||
- 新增 `infrastructure/tests/fixtures/official_regression/http_404.json`。
|
||||
- 新增 `infrastructure/tests/fixtures/official_regression/hash_mismatch_catalog.json`。
|
||||
- 对应测试会解析这些 fixture,防止样本只存在但不参与验证。
|
||||
|
||||
验收:
|
||||
|
||||
- `cargo test -p bat-adapters --test addressables_regression`
|
||||
- `cargo test -p bat-infrastructure regression_fixture`
|
||||
仍需完成通用 patch 发布、复杂重打包、双 release 查询/分发视图和清理策略。
|
||||
|
||||
### G-012:Translation Memory 未实现
|
||||
|
||||
影响:
|
||||
|
||||
- 无法复用人工翻译和 AI 翻译历史。
|
||||
|
||||
验收:
|
||||
|
||||
- 精确匹配、模糊匹配、上下文匹配可用。
|
||||
- 记录 Provider、模型、审核状态和历史版本。
|
||||
需要支持精确、模糊和上下文匹配,并保留 provider、模型、审核状态和历史版本。
|
||||
|
||||
### G-013:Glossary 未实现
|
||||
|
||||
影响:
|
||||
需要支持术语优先级、别名、分类、冲突检测和审核。
|
||||
|
||||
- 无法保证术语一致性。
|
||||
- AI 翻译无法强制遵守术语。
|
||||
### G-014:完整 Provider 扩展体系未实现
|
||||
|
||||
验收:
|
||||
当前已有 mock/Crowdin provider worker、lease、重试和 TextUnit 结果落库;仍需建立
|
||||
可替换的 Provider 扩展体系,以及批处理、限流、成本统计和质量检查。
|
||||
|
||||
- 术语优先级高于 AI。
|
||||
- 支持别名、分类、冲突检测、审核。
|
||||
## 2. 已确定的架构边界
|
||||
|
||||
### G-014:AI Provider 抽象未实现
|
||||
以下内容不是待实现的重复任务:
|
||||
|
||||
影响:
|
||||
1. 正式资源同步和运维命令行是 Rust `bat`;不另做产品级 Go 同步 CLI。
|
||||
2. Rust `bat` / daemon 是资源生产者和状态拥有者;Go `bat-api` 只读取已发布资源,
|
||||
通过 `bat.sock` 提供 bootstrap、分发和受限管理入口。
|
||||
3. `bat-api` 是资源 bootstrap/分发服务,**不是完整官方游戏 API**。
|
||||
4. `bat-ffi` 只保留无状态兼容 helper,不承载 daemon、下载器、CAS handle 或主控制面。
|
||||
5. 官方原版 release 和 localized release 使用独立目录、staging、manifest、current
|
||||
和 rollback 生命周期。
|
||||
6. `daemon.clean-stable` 是 CLI 生命周期清理入口,不在 live RPC 内执行在线清理;
|
||||
`task.create` 也不作为通用 RPC 入口开放。
|
||||
7. `status` / `status_code` 描述生命周期,`BAT-ERR-*` 描述错误;两者不混用。
|
||||
|
||||
- 无法接入 DeepL/OpenAI/Anthropic/Google/Azure。
|
||||
详细阶段报告仍保留在 `docs/reports/historical/`,不作为当前实现依据。
|
||||
|
||||
验收:
|
||||
## 3. 后续推进顺序
|
||||
|
||||
- Provider 可替换。
|
||||
- 支持批处理、限流、重试、成本统计和质量检查。
|
||||
|
||||
---
|
||||
|
||||
## 5. 文档与发布缺口
|
||||
|
||||
### G-015:README 与当前真实状态不完全一致
|
||||
|
||||
状态:**已关闭**
|
||||
|
||||
现象:
|
||||
|
||||
- 旧 README 描述了最终架构,但部分功能尚未实现。
|
||||
|
||||
验收:
|
||||
|
||||
- README 明确区分已实现、开发中、规划中。
|
||||
|
||||
处理结果:
|
||||
|
||||
- README 已明确区分当前可用能力、未完成模块、官方同步运行命令和近期优先级。
|
||||
|
||||
### G-016:架构文档需要更新为当前路线图
|
||||
|
||||
状态:**已关闭当前阶段**
|
||||
|
||||
现象:
|
||||
|
||||
- 旧 `docs/architecture/README.md` 偏目标架构,容易让读者误以为 Go 同步器和 API/Web 已经可用。
|
||||
|
||||
验收:
|
||||
|
||||
- 增加 ADR 或架构决策记录。
|
||||
- 明确 Rust/Go/DB/Plugin 边界。
|
||||
|
||||
处理结果:
|
||||
|
||||
- 架构 README 已明确当前 Rust 官方同步入口、Go 计划边界和目标架构差异。
|
||||
- 官方资源后端说明由 `docs/architecture/official-resource-backend.md` 承载。
|
||||
- `bat-ffi` 已降级为可选无状态兼容层,主集成边界明确为 `bat --json` 进程边界或未来稳定 SDK。
|
||||
|
||||
### G-017:CI 未落地
|
||||
|
||||
状态:**已关闭(决策:不引入托管 CI)**
|
||||
|
||||
原现象:
|
||||
|
||||
- 仓库没有 GitHub Workflows 或等价托管 CI,质量门槛无自动远端执行。
|
||||
|
||||
处理结果:
|
||||
|
||||
- 明确决策:本项目不加入 GitHub Workflows,也不引入其他托管 CI。
|
||||
- 目前补充了自托管 Gitea linux-runner workflow(`.gitea/workflows/bat.yml`),覆盖 Rust workspace 构建/测试、Go API 门禁和文档状态门禁,不改变“不引入托管 CI”的决策。
|
||||
- workflow 不使用外部 GitHub Action;它通过 runner 环境变量手动 `git fetch` 当前提交,并要求 runner 预装 `git`、Rust stable、rustfmt、clippy 和 Go,避免准备阶段因第三方 action 仓库代理或网络限制失败。
|
||||
- 质量门禁由本地默认验证命令和自托管 workflow 共同承担:提交前执行 `cargo fmt` / `cargo clippy --workspace --all-targets -- -D warnings` / `cargo test --workspace`、Go API 门禁和 `make check-docs`(见 `docs/guides/development.md` 与 `docs/guides/baseline.md`)。
|
||||
- 发布类检查(build、smoke)由 `Makefile` 与 `scripts/` 下的可重复脚本承担(如 `make official-smoke`)。
|
||||
|
||||
限制:
|
||||
|
||||
- 门禁执行依赖提交者本地自觉,无远端强制拦截;若未来出现多人协作或外部贡献需求,可重新评估本决策。
|
||||
|
||||
### G-018:真实官方网络全量下载 smoke test 已固化为可重复命令
|
||||
|
||||
状态:**已关闭(已固化可重复 smoke 命令;真实下载产物不纳入 Git)**
|
||||
|
||||
历史现象:
|
||||
|
||||
- 本地测试覆盖 mock、fixture、synthetic import 和 CLI 参数。
|
||||
- 曾缺少真实官方网络全量下载的固定 runbook 和可重复命令。
|
||||
|
||||
处理结果:
|
||||
|
||||
- 新增 `scripts/official-full-pull-smoke.sh`,默认在 `/tmp/bat-official-smoke-<UTC timestamp>/` 下创建隔离资源目录、状态目录和报告目录。
|
||||
- 新增 `make official-smoke` 统一入口。
|
||||
- 新增 `docs/guides/official-full-pull-smoke.md`,记录目标、命令、输出结构、环境变量、安全边界和成功判定。
|
||||
- smoke 流程覆盖 dry-run plan、首次全量拉取、二次 `up_to_date`、人工破坏 active release 文件后的 `repair`、repair 后 `verify`。
|
||||
- 脚本会检查二次 `up_to_date`、repair 完成、verify `healthy=true`,并检查首次拉取和 repair 的 stderr log 中存在下载已完成计数、单文件进度和校验结果日志。
|
||||
- 运行报告 `SMOKE_REPORT.md` 记录实际输出目录、active release、文件数量、release 大小和被破坏文件;大型官方资源文件保留在隔离输出目录,不纳入 Git。
|
||||
|
||||
验收:
|
||||
|
||||
- 使用 `scripts/official-full-pull-smoke.sh` 或 `make official-smoke`。
|
||||
- 默认输出目录必须是独立 `/tmp` 目录;非 `/tmp` 路径需要显式设置 `BAT_SMOKE_ALLOW_NON_TMP=1`,且输出目录必须为空。
|
||||
- 脚本退出码为 0 即表示 runbook 验收通过。
|
||||
- 真实网络执行需要外部网络和足够磁盘空间;本仓库只保存 runbook、脚本和测试,不保存官方大文件。
|
||||
|
||||
后续跟踪(非阻塞):
|
||||
|
||||
- 官方同步长期运行测试正在进行,运行报告将在后续提供。
|
||||
|
||||
### G-019:下载失败重试策略不够精细
|
||||
|
||||
状态:**已关闭**
|
||||
|
||||
历史现象:
|
||||
|
||||
- curl 失败只按固定次数重试,错误信息主要保留最后一次 stderr。
|
||||
- 403/404 和 5xx 没有不同处理。
|
||||
- 单个 URL 长期失败时缺少可查询的 quarantine 诊断状态。
|
||||
- 旧 launcher 包下载虽然有 primary/backup CDN 路径,但失败信息没有统一分类。
|
||||
|
||||
处理结果:
|
||||
|
||||
- 新增统一 curl 失败分类:`http_forbidden`、`http_not_found`、`http_client_error`、`http_too_many_requests`、`http_server_error`、`dns`、`connect`、`timeout`、`tls`、`interrupted`、`network` 等。
|
||||
- 403/404/普通 4xx 视为不可重试并提前停止;5xx、429、DNS、连接、超时、中断和网络类错误按尝试次数重试。
|
||||
- 单个资源 URL 最终失败会写入 `official-download-quarantine.json`,记录失败类型、HTTP 状态、是否可重试、尝试次数和最后错误。
|
||||
- 失败 URL 会发出 Failed progress,daemon status 和 `bat-events.jsonl` 暴露失败类型、HTTP 状态、重试属性和 quarantine 状态。
|
||||
- quarantine 会中断同步并阻止发布不完整 staging;下一轮成功下载或复用后清理对应 quarantine 条目。
|
||||
- 旧 launcher 包或 `resources.assets` 下载在 primary CDN 失败后会切换官方 backup CDN。
|
||||
|
||||
验收:
|
||||
|
||||
- HTTP 404 不重试,写入 quarantine,manifest 不写失败项。
|
||||
- HTTP 5xx 重试到上限后写入 quarantine。
|
||||
- launcher primary CDN 失败后会尝试官方 backup CDN。
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前关闭顺序建议
|
||||
|
||||
1. issue #24:失败 staging 复用回归已补;核对残余场景。
|
||||
2. issue #1:RPC 主体、文件级 `patch.apply` / `unityfs.patch_text_asset` / `unityfs.patch_string_field` / `unityfs.patch_field` 已落地;剩余发布级 patch build/rollback、复杂 UnityFS 语义编辑与设计边界确认。
|
||||
3. issue #17 的历史顺序/重试契约仍保留;当前 issue #33/#35 已补有界 downloader
|
||||
scheduler 和默认并发 8,范围 `1..=256`,worker 完成后立即领取下一个任务,
|
||||
进度即时按完成数上报,最终 report 保持 plan 顺序。
|
||||
4. **issue #47:官方资源历史 release/CAS 复用已完成**;后续只跟踪真实官方长期运行和更丰富的版本清理策略。
|
||||
5. **G-008:已决策关闭**(同步 CLI = Rust `bat`;见 `GO_STATUS.md`)。
|
||||
6. **G-009 / issue #19**:资源 bootstrap/分发和同机 live 联调已完成;非「从零实现」。后续真实官方网络长期运行、持久化和完整 launcher/业务链不属于本 issue 关闭条件。
|
||||
7. issue #2 / G-007(P1):Addressables 可校验字段。
|
||||
8. issue #3 / G-005(P1):UnityFS 容器基础解析已落地;对象级引擎解析继续跟踪 G-005。
|
||||
9. G-011:更丰富的 TextUnit 查询、翻译记忆查询和通用 Patch 发布所需资源视图。
|
||||
10. G-012 / G-006:Crowdin/翻译系统、复杂 AssetBundle 重打包和 Patch 发布流程统一。
|
||||
11. G-011D:原版/汉化双发布后的查询、分发和清理策略。
|
||||
|
||||
Go 进度以 `docs/reports/GO_STATUS.md` 为准。G-018 / G-017 已关闭。
|
||||
1. 继续 G-005:真实 AssetBundle 样本、复杂字段解析和发布级重打包。
|
||||
2. 继续 G-006/G-011D:通用 manifest Patch 和双 release 查询/清理策略。
|
||||
3. 继续 G-011/G-012/G-013/G-014:资源查询、Translation Memory、Glossary 和 Provider
|
||||
扩展体系。
|
||||
4. 在隔离环境执行 `make official-smoke`,补充真实网络长期运行报告。
|
||||
5. 最后推进完整 Web 协作后台和完整游戏业务 API。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Go 侧进度与边界(权威)
|
||||
|
||||
- **更新时间**:2026-09-02
|
||||
- **更新时间**:2026-09-04
|
||||
- **用途**:统一 Go module `bat-api` 的产品边界、既有约定和组件进度;其他文档与此冲突时以本文为准。
|
||||
- **关联**:issue #19 / G-009(资源 bootstrap/分发)、G-008(已决策关闭)、`docs/architecture/official-resource-backend.md` §7、`docs/guides/bat-api-local-live-smoke.md`
|
||||
- **关联缺口**:G-009(资源 bootstrap/分发);相关契约见 `docs/architecture/official-resource-backend.md` §7 和 `docs/guides/bat-api-local-live-smoke.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
|
||||
### 1.3 决策(已核验)
|
||||
|
||||
1. **G-008 决策关闭(wontfix)**:不另做产品级 Go 同步/运维 CLI。
|
||||
1. **Go 同步 CLI 边界已确定**:不另做产品级 Go 同步/运维 CLI,正式入口是 Rust `bat`。
|
||||
2. **G-009**:资源 bootstrap/分发 MVP 部分完成;非完整游戏业务 API。
|
||||
3. **USERGUIDE 的 bat-api 基础章节已补**;同机 live 联调 runbook 和内嵌 dashboard MVP 已补,真实官方网络下载仍由独立 smoke 负责。
|
||||
|
||||
@@ -100,7 +100,7 @@
|
||||
| 试验 CLI | `cmd/bat` | **试验** | doctor 固定 ok;manifest/sync 走 FFI |
|
||||
| FFI | `internal/ffi` | **可选** | 需 `build-ffi` |
|
||||
| 空骨架 | `api/`、`pkg/*`、部分 `internal/*` | **空** | 见各目录 README |
|
||||
| Web | `web/` | **内嵌 dashboard MVP** | issue #46;完整协作后台、登录/角色和术语管理仍属 G-010 剩余 |
|
||||
| Web | `web/` | **内嵌 dashboard MVP** | 完整协作后台、登录/角色和术语管理仍属 G-010 剩余 |
|
||||
|
||||
`go list ./...` 当前包:
|
||||
|
||||
@@ -129,13 +129,12 @@ make build-go-cli # 产出 bin/bat-go
|
||||
|
||||
---
|
||||
|
||||
## 5. 与缺口 / issue 对应
|
||||
## 5. 与缺口对应
|
||||
|
||||
| 项 | 状态 |
|
||||
|---|---|
|
||||
| G-008 Go 同步 CLI | **已决策关闭**(正式同步 CLI = Rust `bat`) |
|
||||
| Go 同步 CLI | **边界已确定**(正式同步 CLI = Rust `bat`) |
|
||||
| G-009 bat-api 资源 bootstrap/分发 | **资源面完成(非完整官方游戏 API)**;已含资源 bootstrap、launcher resource metadata 兼容、HTTP 鉴权/限流/日志/反代适配、RPC 周期刷新/诊断、readiness、OpenAPI、管理控制白名单、Rust-owned `schedule.*`、`task.*`、`parse.*`、翻译状态回写代理、内嵌 dashboard、同机 live smoke 和部署模板;持久化仍另议 |
|
||||
| issue #19 | **验收完成,本提交关闭**;`make bat-api-local-live-smoke` 已在同机隔离环境覆盖 live RPC、release 切换、清单不完整、未 ready、server-info 和 CDN path |
|
||||
| G-010 Web | 内嵌 dashboard MVP 已完成;完整协作后台、登录/角色、术语管理和构建型前端未开始 |
|
||||
|
||||
---
|
||||
@@ -143,10 +142,10 @@ make build-go-cli # 产出 bin/bat-go
|
||||
## 6. 资源布局与逆向
|
||||
|
||||
- **Release / URL / 分发契约(权威)**:`docs/architecture/resource-release-layout.md`
|
||||
- 真机全量实勘、seed inventory diff、issue #2/#3 样本采集按该文档 §9–§10 执行
|
||||
- 真机全量实勘、seed inventory diff 和样本采集按该文档 §9–§10 执行
|
||||
|
||||
## 7. 后续(不在进度统一范围内)
|
||||
|
||||
1. 预留 database/redis 的接入时机另议
|
||||
2. 真实官方网络全量下载长期运行报告(使用 `make official-smoke`,与 issue #19 同机 live 联调独立)
|
||||
3. launcher 完整安装包更新链 / 登录网关链(若需要,新 issue)
|
||||
2. 真实官方网络全量下载长期运行报告(使用 `make official-smoke`,与同机 live 联调独立)
|
||||
3. launcher 完整安装包更新链 / 登录网关链(如需推进,应另立范围明确的后续需求)
|
||||
|
||||
@@ -1,81 +0,0 @@
|
||||
# 解析模块维护冻结
|
||||
|
||||
状态:**生效中**
|
||||
|
||||
生效时间:2026-07-30
|
||||
|
||||
冻结目标:停止继续扩大 UnityFS / AssetBundle / Addressables / TypeTree 解析能力,把当前工作重心切换到运行稳定性、代码审核问题、文档一致性和发布链路可靠性。
|
||||
|
||||
## 冻结范围
|
||||
|
||||
冻结覆盖以下 Rust 解析相关模块和对外入口:
|
||||
|
||||
- `crates/bat-assetbundle`
|
||||
- `adapters/src/unity*`
|
||||
- `infrastructure/src/official_parse.rs`
|
||||
- `infrastructure/src/resources.rs` 中解析缓存、TextUnit 索引和解析状态相关逻辑
|
||||
- `unityfs.*`、`parse.*`、`text.*` 相关 RPC / CLI 契约
|
||||
- Addressables catalog、UnityFS、serialized file、TypeTree、TextUnit、AssetBundle patch 相关文档声明
|
||||
|
||||
## 允许变更
|
||||
|
||||
冻结期只允许以下解析相关变更:
|
||||
|
||||
- 修复编译失败、格式化失败、clippy 报错和测试失败。
|
||||
- 修复真实运行中已经复现的 panic、错误状态污染、重复解析、缓存失效、状态不一致或诊断误导。
|
||||
- 补充回归测试,前提是测试覆盖的是已存在能力的稳定性问题,不宣称新增解析能力。
|
||||
- 修正文档、CLI 帮助、RPC 参考和状态文件中与当前实现不一致的解析能力声明。
|
||||
- 改善错误信息、日志字段、状态记录和失败恢复,但不得改变解析输出契约,除非是修复错误契约且同步迁移说明。
|
||||
|
||||
## issue 43 的明确例外
|
||||
|
||||
本次 issue 43 经用户明确授权,允许新增 `bat` 的工作流编排入口:
|
||||
|
||||
- `parse run` 只刷新已有解析输出、TextUnit 索引和翻译队列;
|
||||
- `parse repack` 只调用已有 TextAsset、TypeTree string 和受支持语义字段 patch 实现;
|
||||
- `i18n` 工作台和 `publish` 只消费已有 TextUnit 输出,并发布独立汉化 release。
|
||||
|
||||
该例外不解冻解析器,不新增 UnityFS/AssetBundle/Addressables/TypeTree 解析类型、字段覆盖、catalog 结构或合成 fixture 能力。后续任何扩大解析覆盖的变更仍需单独解冻授权。
|
||||
|
||||
## issue 2/3 的开发例外
|
||||
|
||||
授权时间:2026-08-19
|
||||
|
||||
用户明确授权将 issue #2/#3 作为解析开发进展继续推进。本次例外允许:
|
||||
|
||||
- Addressables JSON/compact catalog 的 provider、bundle name、hash、size、CRC、资源类型和依赖关系字段补全,以及对应 SQLite/fixture 回归;
|
||||
- UnityFS 已有 header、block、directory、压缩和 alignment 能力的校验加固,以及隔离真实 bundle 回归;
|
||||
- 更新解析路线图、状态和 RPC/CLI 资源索引字段说明。
|
||||
|
||||
本次例外不包含发布级复杂对象重打包、完整 Unity 版本兼容承诺或新的汉化发布控制面;这些仍按后续 Patch/发布路线单独验收。
|
||||
|
||||
## 禁止变更
|
||||
|
||||
冻结期禁止以下解析相关变更:
|
||||
|
||||
- 新增 TypeTree 语义类型、字段族、managed reference 变体、Unity 内建结构体覆盖或 Addressables catalog 结构覆盖。
|
||||
- 用纯合成 fixture 推进“完整解析”并把它记录为已支持能力。
|
||||
- 开放新的写入型 `unityfs.*` / `patch.*` RPC 或 CLI。
|
||||
- 修改解析结果 schema、TextUnit schema、patch field JSON 语义或缓存状态格式,除非它是阻断级 bug 修复并附带兼容策略。
|
||||
- 将解析器和官方同步、汉化发布、Go API、Crowdin 或客户端流程进一步耦合。
|
||||
|
||||
## 解冻条件
|
||||
|
||||
解析扩展重新启动前必须同时满足:
|
||||
|
||||
- Rust `bat` 官方同步、daemon、status、校验、断点续传、增量更新和解析缓存链路稳定。
|
||||
- 当前 P0/P1 维护 issue 已关闭或被明确降级。
|
||||
- `bat-api` 与 Rust RPC / CLI 契约完成字段统一和联调验证。
|
||||
- 真实资源 fixture、验证命令和验收标准已写入文档,不能只依赖合成样本。
|
||||
|
||||
## 冻结期验证
|
||||
|
||||
解析相关维护变更至少运行:
|
||||
|
||||
```bash
|
||||
cargo fmt --check
|
||||
cargo test -p bat-assetbundle --locked
|
||||
cargo clippy -p bat-assetbundle --all-targets --locked -- -D warnings
|
||||
```
|
||||
|
||||
如果变更影响 `bat` CLI、RPC、官方解析缓存或 TextUnit 索引,还必须补充对应 `bat-infrastructure` 测试或说明未运行原因。
|
||||
@@ -70,12 +70,12 @@
|
||||
## 📚 重要文档索引
|
||||
|
||||
### 架构和设计
|
||||
- `docs/ARCHITECTURE_REVIEW.md` - 完整架构审查(1903行)
|
||||
- `docs/BLUE_ARCHIVE_TECHNICAL_ANALYSIS.md` - 技术分析
|
||||
- `docs/CODE_QUALITY_IMPROVEMENT.md` - 代码质量优化详情
|
||||
- `docs/archive/ARCHITECTURE_REVIEW.md` - 完整架构审查(1903行)
|
||||
- `docs/archive/BLUE_ARCHIVE_TECHNICAL_ANALYSIS.md` - 技术分析
|
||||
- `docs/reports/historical/nested-docs/CODE_QUALITY_IMPROVEMENT.md` - 代码质量优化详情
|
||||
|
||||
### 进度报告
|
||||
- `docs/PHASE_1_WEEK_1_COMPLETE.md` - Week 1 详细报告
|
||||
- `docs/reports/historical/nested-docs/PHASE_1_WEEK_1_COMPLETE.md` - Week 1 详细报告
|
||||
- `PHASE_1_WEEK_1_FINAL_REPORT.md` - Week 1 最终报告
|
||||
|
||||
### 代码质量
|
||||
|
||||
@@ -109,11 +109,11 @@ BlueArchiveToolkit/
|
||||
|
||||
## 📚 创建的文档
|
||||
|
||||
1. ✅ [ARCHITECTURE_REVIEW.md](./docs/ARCHITECTURE_REVIEW.md) - 完整架构审查(1903 行)
|
||||
2. ✅ [BLUE_ARCHIVE_TECHNICAL_ANALYSIS.md](./docs/BLUE_ARCHIVE_TECHNICAL_ANALYSIS.md) - 技术分析报告
|
||||
3. ✅ [PHASE_0.5_REPORT.md](./docs/PHASE_0.5_REPORT.md) - 深度验证报告
|
||||
4. ✅ [PHASE_1_WEEK_1_COMPLETE.md](./docs/PHASE_1_WEEK_1_COMPLETE.md) - Week 1 详细报告
|
||||
5. ✅ [WEEK_1_VERIFIED.md](./WEEK_1_VERIFIED.md) - 最终验证报告
|
||||
1. ✅ [ARCHITECTURE_REVIEW.md](../../../archive/ARCHITECTURE_REVIEW.md) - 完整架构审查(1903 行)
|
||||
2. ✅ [BLUE_ARCHIVE_TECHNICAL_ANALYSIS.md](../../../archive/BLUE_ARCHIVE_TECHNICAL_ANALYSIS.md) - 技术分析报告
|
||||
3. ✅ [PHASE_0.5_REPORT.md](../nested-docs/PHASE_0.5_REPORT.md) - 深度验证报告
|
||||
4. ✅ [PHASE_1_WEEK_1_COMPLETE.md](../nested-docs/PHASE_1_WEEK_1_COMPLETE.md) - Week 1 详细报告
|
||||
5. `WEEK_1_VERIFIED.md` - 原报告未纳入当前归档。
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user