Merge remote-tracking branch 'origin/master' into codex/publish-flow
CI / verify (pull_request) Has been cancelled
CI / verify (pull_request) Has been cancelled
# Conflicts: # docs/technical/JENKINS_SPACETIMEDB_DATABASE_MIGRATION_PIPELINES_2026-04-29.md # docs/technical/README.md # jenkins/Jenkinsfile.database-export # jenkins/Jenkinsfile.database-import
This commit is contained in:
@@ -44,8 +44,8 @@ spacetime generate --lang typescript|csharp|rust|unrealcpp --out-dir ./bindings
|
||||
### Publishing & Deployment
|
||||
|
||||
```bash
|
||||
# Publish to Maincloud (default)
|
||||
spacetime publish my-database --yes
|
||||
# Publish to an explicit server
|
||||
spacetime publish my-database --server http://127.0.0.1:3101 --yes
|
||||
|
||||
# Publish to local server
|
||||
spacetime publish my-database --server local --yes
|
||||
@@ -133,8 +133,8 @@ spacetime logout
|
||||
|
||||
| Name | URL | Description |
|
||||
|------|-----|-------------|
|
||||
| `maincloud` | `https://maincloud.spacetimedb.com` | Production cloud (default) |
|
||||
| `local` | `http://127.0.0.1:3000` | Local development server |
|
||||
| `dev` | `http://127.0.0.1:3101` | Genarrative local development server |
|
||||
|
||||
## Common Workflows
|
||||
|
||||
@@ -224,6 +224,6 @@ rustup target add wasm32-unknown-unknown
|
||||
## Notes
|
||||
|
||||
- Many commands are marked UNSTABLE and may change
|
||||
- Default server is `maincloud` unless configured otherwise
|
||||
- Genarrative scripts should pass `--server` or `--server-url` explicitly instead of relying on the CLI default
|
||||
- Use `--yes` flag in scripts to avoid interactive prompts
|
||||
- Dev mode watches files and auto-rebuilds on changes
|
||||
|
||||
@@ -119,6 +119,11 @@ RPG_LLM_WEB_SEARCH_ENABLED="true"
|
||||
DASHSCOPE_BASE_URL="https://dashscope.aliyuncs.com/api/v1"
|
||||
DASHSCOPE_API_KEY="YOUR_DASHSCOPE_API_KEY"
|
||||
|
||||
# Server-side APIMart image generation config for optional puzzle image models.
|
||||
APIMART_BASE_URL="https://api.apimart.ai/v1"
|
||||
APIMART_API_KEY="YOUR_APIMART_API_KEY"
|
||||
APIMART_IMAGE_REQUEST_TIMEOUT_MS="180000"
|
||||
|
||||
# 阿里云 OSS 配置。
|
||||
# Rust `server-rs` 的 `api-server` 会优先从 `.env` / `.env.local` 读取这些变量,
|
||||
# 用于签发浏览器 PostObject 直传票据,并保持 `/generated-*` 旧路径习惯。
|
||||
|
||||
+1
-5
@@ -54,11 +54,7 @@ GENARRATIVE_SPACETIME_SERVER_URL="http://127.0.0.1:3101"
|
||||
GENARRATIVE_SPACETIME_DATABASE="xushi-p4wfr"
|
||||
GENARRATIVE_SPACETIME_TOKEN=""
|
||||
|
||||
GENARRATIVE_SPACETIME_MAINCLOUD_SERVER_URL="https://maincloud.spacetimedb.com"
|
||||
GENARRATIVE_SPACETIME_MAINCLOUD_DATABASE="xushi-p4wfr"
|
||||
GENARRATIVE_SPACETIME_MAINCLOUD_TOKEN=""
|
||||
|
||||
# admin
|
||||
GENARRATIVE_ADMIN_USERNAME=admin
|
||||
GENARRATIVE_ADMIN_PASSWORD=123456
|
||||
ADMIN_API_TARGET=http://127.0.0.1:8082
|
||||
ADMIN_API_TARGET=http://127.0.0.1:8082
|
||||
|
||||
@@ -29,3 +29,4 @@ temp*build*/
|
||||
/public/generated-characters
|
||||
/.codex-temp
|
||||
/target/
|
||||
/logs
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
# AGENTS.md
|
||||
|
||||
## 项目约束
|
||||
- 在修改server-rs的内容时,不要去兼容server-node中的任何内容,只允许参考,以及把server-node中未迁移到server-rs的内容迁移过来
|
||||
- 代码需要有完善的中文注释
|
||||
- 在落地工程修改前检查是否有详细指导本次落地的文档,若没有文档或文档的完善程度仍有落地过程中编码级别的歧义优先优化文档后落地工程迭代。
|
||||
- 对工程的修改不仅要落地到代码更面,还要更改对应文档,若没有生成新的文档,文档统一存在doc目录中
|
||||
@@ -14,13 +13,20 @@
|
||||
- UI设计需要兼顾网页端、移动端双端的使用体验,确保在不同设备上都能正常显示和操作,移动端优先考虑。
|
||||
- 不要在gitignore中添加.env.local文件。
|
||||
- 严格遵循简洁的代码风格
|
||||
- 前端只负责做表现,所有的逻辑、数据都放到后端工程,后端使用server-rs中用Rust+spacetimeDB的方案实现,禁止继续使用server-node(Express)和postgreSQL
|
||||
- 后端采用多crate设计
|
||||
- 请默认保持系统的简洁性,能复用、修改、扩展现有系统、页面就不新建新系统新页面。
|
||||
- 禁止将功能说明描述类的文本默认写入UI界面中。
|
||||
- prd文档中每个模块的描述要落地设计到可以精准编码到位,不能出现需求落地漂移。
|
||||
- 点击按钮弹出独立的面板的设计不要实现成在当前面板下面显示内容。
|
||||
- 每个阶段任务完成后自动压缩上下文,确保后续阶段在清晰、低噪音的上下文基础上继续推进。
|
||||
|
||||
## 后端技术约束
|
||||
- 后端最新技术约束以 [`docs/technical/SERVER_RS_DDD_FULL_REFACTOR_2026-04-28.md`](docs/technical/SERVER_RS_DDD_FULL_REFACTOR_2026-04-28.md) 为总纲;执行和收口状态以 [`docs/technical/SERVER_RS_DDD_PARALLEL_TASKLIST_2026-04-29.md`](docs/technical/SERVER_RS_DDD_PARALLEL_TASKLIST_2026-04-29.md) 为准。
|
||||
- 契约、路由、DTO 去留和 breaking change 以 [`docs/technical/SERVER_RS_DDD_G1_CONTRACT_AND_ROUTE_MATRIX_2026-04-29.md`](docs/technical/SERVER_RS_DDD_G1_CONTRACT_AND_ROUTE_MATRIX_2026-04-29.md) 为准;不得在前端、`api-server` 或临时兼容层中重新发明旧接口。
|
||||
- SpacetimeDB 表结构、自动迁移限制和冲突处理以 [`docs/technical/SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md`](docs/technical/SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md) 为准;涉及 table、reducer、procedure、row shape 或绑定变化时,必须同步 `migration.rs`、表目录和生成绑定。
|
||||
- 后端路线固定为 `server-rs + Axum + SpacetimeDB`。旧 `server-node`、Express、PostgreSQL 不再作为兼容目标;历史实现只能作为迁移参考,若旧文档与 DDD 约束冲突,先修正文档和方案再编码。
|
||||
- DDD 分层边界按总纲执行:领域规则沉到 `module-*`,SpacetimeDB 表和事务编排留在 `spacetime-module`,后端访问 SpacetimeDB 统一经 `spacetime-client` facade,HTTP/SSE/BFF 留在 `api-server`,外部副作用留在 `platform-*`,前后端 DTO 留在 `shared-contracts`。
|
||||
- 前端只做表现、交互和临时 UI 状态,不承接正式业务真相,不绕过后端投影或后端 API 直接实现业务规则。
|
||||
- 修改后端代码后,按对应 DDD 文档中的验收命令执行测试;涉及 API smoke 时使用 `npm run api-server` 重新拉起后端并执行相应自动测试,同时确认 `/healthz`。
|
||||
- 凡是涉及 SpacetimeDB 的设计、实现、脚本、调试、前端绑定接入,统一显式使用以下 skill 作为执行依据:
|
||||
- [$spacetimedb-cli](.codex\\skills\\spacetimedb-cli\\SKILL.md)
|
||||
- [$spacetimedb-rust](.codex\\skills\\spacetimedb-rust\\SKILL.md)
|
||||
@@ -30,7 +36,7 @@
|
||||
- 涉及 `crates/spacetime-module` 的表、reducer、view、Rust API 使用时,按 `spacetimedb-rust` 与 `spacetimedb-concepts` 执行。
|
||||
- 涉及前端或 Node 侧的 SpacetimeDB TypeScript SDK、订阅、绑定使用时,按 `spacetimedb-typescript` 与 `spacetimedb-concepts` 执行。
|
||||
- 若仓库内旧实现或旧文档与这些 skill 冲突,先修正文档和方案,再继续编码。
|
||||
- 修改后端代码后,必须使用 `npm run api-server:maincloud` 自动重新运行后端,并执行相应自动测试;不要再使用旧的后端重启命令。
|
||||
- 修改后端代码后,必须使用 `npm run api-server` 自动重新运行后端,并执行相应自动测试;不要再使用旧的后端重启命令。
|
||||
- 数据库表结构更改后,需要对齐migration.rs
|
||||
|
||||
## 文档图谱
|
||||
|
||||
@@ -0,0 +1,77 @@
|
||||
# server-rs DDD 一次性重构方案
|
||||
|
||||
## Summary
|
||||
|
||||
当前仓库已不再存在 `server-node`,本次只针对现有 `server-rs` 做一次性 DDD 化。
|
||||
|
||||
目标是把 Rust + SpacetimeDB 后端统一成清晰边界:领域规则在 `module-*`,事务和持久化在 `spacetime-module`,HTTP/BFF 在 `api-server`,外部能力在 `platform-*`,共享值处理和 DTO 分别在 `shared-kernel` / `shared-contracts`。
|
||||
|
||||
全局并行执行任务清单见 `docs/technical/SERVER_RS_DDD_PARALLEL_TASKLIST_2026-04-29.md`。runtime story 去兼容层属于该清单中的 `WP-RS` 工作包,不再单独维护专项清单。
|
||||
|
||||
## Target Architecture
|
||||
|
||||
- `module-*`:领域模型、值对象、聚合方法、领域服务、命令、领域错误、领域事件、纯应用编排结果;禁止直接依赖 Axum、reqwest、OSS、LLM、文件系统、SpacetimeDB table 操作。
|
||||
- `spacetime-module`:SpacetimeDB adapter,只保留 table、reducer、procedure、row/snapshot mapper、事务内查询写回、event table;核心规则必须调用 `module-*`。
|
||||
- `api-server`:HTTP/BFF adapter,只保留路由、鉴权上下文、请求响应映射、SSE、SpacetimeDB client 调用、平台服务调用。
|
||||
- `platform-*`:JWT/SMS/微信/OSS/LLM/HTTP client 等外部能力实现。
|
||||
- `shared-kernel`:跨领域纯值处理;`shared-contracts`:HTTP/前端契约 DTO。
|
||||
|
||||
## Required Refactor
|
||||
|
||||
- 为所有业务上下文统一目录:
|
||||
- `domain.rs` 或 `domain/*`:聚合、值对象、领域方法。
|
||||
- `commands.rs`:写入用例输入。
|
||||
- `application.rs`:用例处理函数。
|
||||
- `events.rs`:领域事件与跨上下文事件。
|
||||
- `errors.rs`:领域错误。
|
||||
- `mapper.rs` 仅允许出现在 adapter crate。
|
||||
|
||||
- 一次性处理混合边界:
|
||||
- `module-auth` 拆出认证、会话、验证码、微信绑定领域;内存 store / 文件持久化移出领域核心。
|
||||
- `module-assets` 拆出资产对象确认规则;OSS head、reqwest、fallback store 移出领域核心。
|
||||
- `spacetime-module` 全量拆分 table、reducer/procedure、mapper、跨上下文事务编排。
|
||||
- `api-server` 中 handler 只保留 transport 逻辑,业务分支迁移到领域或应用层。
|
||||
- `runtime_story`、`custom_world`、`puzzle`、`big_fish`、`inventory`、`quest`、`npc`、`combat`、`progression` 全部对齐同一结构。
|
||||
|
||||
- 去兼容层任务边界:
|
||||
- `module-runtime-story-compat` 不作为目标架构保留,迁移为无 `compat` 命名的 `module-runtime-story` 或拆入对应领域模块。
|
||||
- `api-server/src/runtime_story/compat*` 只允许作为待删除历史入口,不再新增兼容分支。
|
||||
- 前端 runtime story / chat client 统一改到 `POST /api/runtime/story/sessions/:sessionId/...` 新接口族。
|
||||
- 旧请求体里的 `worldType / character / monsters / history / context` 不再作为正式主链输入。
|
||||
|
||||
- 表结构硬约束:
|
||||
- 默认保持现有 SpacetimeDB 主表兼容。
|
||||
- 表结构变更采用最小必要原则。
|
||||
- 只有为修正聚合边界、读写分离、事件化、查询索引或生命周期独立性不可避免时,才新增或调整表。
|
||||
- 优先新增 optional 字段、投影表、事件表,不做破坏性 rename/delete/type change。
|
||||
- 任何 table 变更必须同步 `migration.rs`、SpacetimeDB 表目录、相关 reducer/procedure 测试。
|
||||
|
||||
- 统一跨上下文协作:
|
||||
- 单聚合内部变化由聚合方法完成。
|
||||
- 跨聚合流程由应用服务或 SpacetimeDB 事务 adapter 编排。
|
||||
- 战斗奖励、任务奖励、成长记账、画廊投影、agent 操作进度等副作用必须显式表达为事件或应用结果。
|
||||
|
||||
- 统一查询策略:
|
||||
- 写模型不复用给复杂查询。
|
||||
- 每个前端场景有独立 query/result DTO。
|
||||
- SpacetimeDB private table 默认不暴露;public table 只服务明确订阅读模型。
|
||||
|
||||
## Documentation
|
||||
|
||||
- 新增 `docs/technical/SERVER_RS_DDD_FULL_REFACTOR_2026-04-28.md`,写清 DDD 规则、依赖方向、crate 职责矩阵、每个上下文的聚合/命令/事件/读模型、SpacetimeDB adapter 映射、表结构变更约束。
|
||||
- 更新现有后端基线、SpacetimeDB 表目录、API 路由索引、相关模块技术文档。
|
||||
- 表结构或 reducer/procedure 变化同步 `migration.rs`。
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- `server-rs` 所有业务模块通过统一 DDD 目录和依赖边界检查。
|
||||
- `spacetime-module/src/lib.rs` 不再承载大段业务流程,拆到上下文 adapter。
|
||||
- 默认不破坏现有 SpacetimeDB 主表;确需改表时有文档、migration 和测试。
|
||||
- 所有领域规则都有纯 Rust 单元测试。
|
||||
- 所有 reducer/procedure 有事务适配测试或最小 smoke。
|
||||
- HTTP contract shape 不发生未记录 breaking change。
|
||||
- 执行并通过:
|
||||
- `cargo test --workspace --manifest-path server-rs/Cargo.toml`
|
||||
- `cargo check -p spacetime-module --manifest-path server-rs/Cargo.toml`
|
||||
- `npm run api-server:maincloud`
|
||||
- 仓库编码检查
|
||||
@@ -15,6 +15,8 @@
|
||||
|
||||
生产部署切换到 systemd + Nginx + SpacetimeDB 自托管的总方案见 [PRODUCTION_DEPLOYMENT_PLAN_2026-05-02.md](./technical/PRODUCTION_DEPLOYMENT_PLAN_2026-05-02.md),该文档也是当前生产 Jenkinsfile 的唯一入口。SpacetimeDB 表结构变更、自动迁移边界和保留旧数据的分阶段迁移流程见 [SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md](./technical/SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md);private 表迁移 JSON 导入导出、HTTP 413 分片导入和旧数据库迁移流水线经验见 [SPACETIMEDB_JSON_STRING_MIGRATION_PROCEDURE_2026-04-27.md](./technical/SPACETIMEDB_JSON_STRING_MIGRATION_PROCEDURE_2026-04-27.md) 与 [JENKINS_SPACETIMEDB_DATABASE_MIGRATION_PIPELINES_2026-04-29.md](./technical/JENKINS_SPACETIMEDB_DATABASE_MIGRATION_PIPELINES_2026-04-29.md);后台管理独立前端工程技术方案见 [ADMIN_WEB_CONSOLE_TECHNICAL_SOLUTION_2026-04-30.md](./technical/ADMIN_WEB_CONSOLE_TECHNICAL_SOLUTION_2026-04-30.md)。
|
||||
|
||||
SpacetimeDB 表结构变更、自动迁移边界和保留旧数据的分阶段迁移流程见 [SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md](./technical/SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md)。
|
||||
|
||||
## 推荐阅读顺序
|
||||
|
||||
1. 先看 [经验沉淀](./experience/README.md),快速建立这个项目的开发共识。
|
||||
|
||||
@@ -628,7 +628,7 @@ SpacetimeDB 方向:
|
||||
4. LLM、OSS、图片生成等外部 I/O 放在 `api-server` / `platform-*` crate 中,再把确定结果写回 SpacetimeDB。
|
||||
5. 前端调用 reducer 使用生成绑定和对象参数,不编辑生成代码。
|
||||
6. 涉及表结构修改时同步更新 `migration.rs`。
|
||||
7. 修改后端代码后统一执行 `npm run api-server:maincloud`,并跑对应自动测试。
|
||||
7. 修改后端代码后统一执行 `npm run api-server`,并跑对应自动测试。
|
||||
|
||||
## 9. 最小验收标准
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@
|
||||
1. `package.json` 中不存在 `server-node:*`、`dev:node`、`m7:api-compare`、`check:server-node-freeze` 等旧入口。
|
||||
2. `scripts/` 下不存在 `dev-node.mjs`、`smoke-server-node.ts`、`m7-api-compare.ts`、`smoke-same-origin-stack.ts` 等旧 Node 后端脚本。
|
||||
3. `package.json` 与 `package-lock.json` 中不存在 `express`、`@types/express`、`pg`、`postgres` 依赖。
|
||||
4. 当前开发入口继续固定为 `npm run dev`、`npm run dev:web`、`npm run api-server:maincloud` 与 Rust / SpacetimeDB 相关脚本,不恢复旧 Node 后端切换开关。
|
||||
4. 当前开发入口继续固定为 `npm run dev`、`npm run dev:web`、`npm run api-server` 与 Rust / SpacetimeDB 相关脚本,不恢复旧 Node 后端切换开关。
|
||||
|
||||
## 9. Caddy 本地服务入口移除(2026-04-26)
|
||||
|
||||
|
||||
@@ -255,14 +255,14 @@ node scripts/vite-cli.mjs --port=3000 --host=0.0.0.0
|
||||
后端代码更新后统一执行:
|
||||
|
||||
```bash
|
||||
npm run api-server:maincloud
|
||||
npm run api-server
|
||||
```
|
||||
|
||||
执行要求:
|
||||
|
||||
- 该命令是后端更新后的默认重启入口,不再使用此前的后端重启命令。
|
||||
- 重启后必须继续执行与本次后端改动对应的自动测试;涉及 Rust workspace 时优先跑 `server-rs` 下的检查或测试脚本。
|
||||
- 若本次改动涉及 SpacetimeDB 发布、绑定生成或 Maincloud 联调,按 `spacetimedb-cli` 经验执行,并在验证记录中写清楚实际命令与结果。
|
||||
- 若本次改动涉及 SpacetimeDB 发布、绑定生成或本地联调,按 `spacetimedb-cli` 经验执行,并在验证记录中写清楚实际命令与结果。
|
||||
|
||||
## 14. 一句话总结
|
||||
|
||||
|
||||
@@ -493,12 +493,15 @@ interface CustomWorldCoverProfile {
|
||||
第一版必须有:
|
||||
|
||||
1. `进入世界`
|
||||
2. `删除作品`
|
||||
|
||||
可选:
|
||||
|
||||
1. `查看作品`
|
||||
2. `基于此作品继续创作`
|
||||
|
||||
`删除作品` 必须放在已发布卡片主操作的左侧,并在创作页内弹出二次确认面板后再执行删除。
|
||||
|
||||
第一版不强制做“基于已发布作品继续创作”,避免先把发布后再开草稿链带复杂。
|
||||
|
||||
---
|
||||
@@ -884,7 +887,7 @@ type SelectionStage =
|
||||
|
||||
1. 不做完整 Agent 工作区
|
||||
2. 不做世界底稿生成
|
||||
3. 不做作品删除确认流
|
||||
3. 不做独立的作品删除管理后台,删除确认统一收口在创作页内完成
|
||||
4. 不做作品搜索排序高级功能
|
||||
5. 不做发布世界管理后台
|
||||
6. 不做已发布作品的二次派生创作
|
||||
@@ -901,9 +904,10 @@ type SelectionStage =
|
||||
2. 创作页面能同时展示草稿和已发布作品。
|
||||
3. 草稿作品可以继续创作。
|
||||
4. 已发布作品可以进入世界。
|
||||
5. 新建作品入口可以正确创建 Agent session 并跳转到创作工作区。
|
||||
6. 页面在移动端首屏可用,信息层级清楚。
|
||||
7. 草稿与已发布作品都通过后端聚合接口返回,前端不自己拼数据来源。
|
||||
5. 已发布作品卡的删除按钮位于主操作左侧,点击后先弹出创作页内的二次确认面板。
|
||||
6. 新建作品入口可以正确创建 Agent session 并跳转到创作工作区。
|
||||
7. 页面在移动端首屏可用,信息层级清楚。
|
||||
8. 草稿与已发布作品都通过后端聚合接口返回,前端不自己拼数据来源。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -753,7 +753,7 @@ RPG 运行时链:
|
||||
|
||||
这些脚本不直接参与玩法,但直接支撑开发、发布、绑定和检查:
|
||||
|
||||
### `scripts/api-server-maincloud.mjs`
|
||||
### `scripts/api-server-dev.mjs`
|
||||
|
||||
职责:
|
||||
|
||||
|
||||
@@ -259,7 +259,7 @@ export interface ProfileInviteCodeAdminResponse {
|
||||
|
||||
`tableStats` 中单表失败必须展示 `errorMessage`,不能让整页变成空白。SpacetimeDB private 表或当前身份不可见的表在 `/sql` 下可能返回 `no such table` / `marked private`,后台服务必须将这类错误归一为“不可统计(private 或当前身份不可见)”,避免把预期的访问边界展示成原始 HTTP 400 故障。
|
||||
|
||||
线上如果大量表都显示“不可统计(private 或当前身份不可见)”,优先检查 `api-server` 启动环境中的 `GENARRATIVE_SPACETIME_TOKEN` / `GENARRATIVE_SPACETIME_MAINCLOUD_TOKEN` 是否存在且属于目标库 owner。Jenkins 覆盖发布包时必须保留部署目录已有运行 token;只带迁移 token 不能让后台概览读取 private 表。
|
||||
线上如果大量表都显示“不可统计(private 或当前身份不可见)”,优先检查 `api-server` 启动环境中的 `GENARRATIVE_SPACETIME_TOKEN` 是否存在且属于目标库 owner。Jenkins 覆盖发布包时必须保留部署目录已有运行 token;只带迁移 token 不能让后台概览读取 private 表。
|
||||
|
||||
### 4.6 API 调试 contract
|
||||
|
||||
@@ -380,7 +380,7 @@ export interface ProfileInviteCodeAdminResponse {
|
||||
|
||||
### 7.1 本地联调
|
||||
|
||||
1. 启动后端:`npm run api-server:maincloud`。
|
||||
1. 启动后端:`npm run api-server`。
|
||||
2. 启动后台前端:在 `apps/admin-web` 执行 `npm run dev`。
|
||||
3. 后台 dev server 通过 Vite proxy 转发 `/admin/api` 到 `ADMIN_API_TARGET`;未配置时默认 `http://127.0.0.1:3100`。
|
||||
4. 若使用非 3100 端口,在仓库根目录 `.env.local` 设置 `ADMIN_API_TARGET=http://127.0.0.1:<api-server-port>`,并重启后台前端 dev server。
|
||||
@@ -437,7 +437,7 @@ export interface ProfileInviteCodeAdminResponse {
|
||||
- 后续接入根 workspace 后,补充后台工程 build/typecheck 脚本。
|
||||
3. 后端:
|
||||
- 继续保留 `cargo test -p api-server --manifest-path server-rs/Cargo.toml admin`。
|
||||
- 修改后端管理 API 后必须运行 `npm run api-server:maincloud` 并手动验证 `/admin` 为 404、`/admin/api/login` 可用。
|
||||
- 修改后端管理 API 后必须运行 `npm run api-server` 并手动验证 `/admin` 为 404、`/admin/api/login` 可用。
|
||||
|
||||
## 9. 后续扩展边界
|
||||
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
# api-server 合并后编译修复记录
|
||||
|
||||
日期:`2026-05-02`
|
||||
|
||||
## 背景
|
||||
|
||||
`codex/ddd` 合入 `master` 后,`api-server` 编译失败。问题集中在合并后的跨 crate 契约缺口:`api-server` 已引用新接口或新字段,但对应的领域 crate 与 HTTP 转接层没有同步补齐。
|
||||
|
||||
## 修复范围
|
||||
|
||||
1. `module-auth` 补齐个人资料更新契约:
|
||||
- 新增 `UpdateProfileInput` 与 `UpdateProfileResult`。
|
||||
- `AuthUser` 增加 `avatar_url` 与 `created_at`,并通过 `serde(default)` 兼容旧认证快照。
|
||||
- `PasswordEntryService::update_profile` 统一校验昵称与头像 data URL,并写回认证快照。
|
||||
2. 微信绑定手机号结果补齐 `activated_new_user`:
|
||||
- 待绑定微信账号绑定新手机号时返回 `true`,用于注册奖励发放。
|
||||
- 待绑定微信账号合并到已有手机号账号时返回 `false`。
|
||||
3. 拼图运行态补齐 HTTP 转接:
|
||||
- `POST /api/runtime/puzzle/runs/{run_id}/drag` 读取 `DragPuzzlePieceRequest`。
|
||||
- 转发到 SpacetimeDB client 的 `drag_puzzle_piece_or_group` procedure 包装。
|
||||
4. runtime story 聊天接口改用当前 shared contract:
|
||||
- 旧 `runtime_story::RuntimeStorySnapshotPayload` 已删除。
|
||||
- `api-server` 侧临时别名到 `story::StoryRuntimeSnapshotPayload`,保持现有请求结构不漂移。
|
||||
5. `api-server` 全量测试修复:
|
||||
- `custom_world_foundation_draft` 的 mock LLM 响应仍是旧 Chat Completions 结构。
|
||||
- 当前 `LlmClient` 默认走 Responses API,测试 mock 已改为 `output[].content[].text` 结构。
|
||||
6. 前端全量测试期望补齐:
|
||||
- 自定义世界结果页的第二幕场景预览断言改为校验第二幕生成图。
|
||||
- 拼图下一关交互测试保留后端下一关调用断言,并明确只调用一次。
|
||||
- 拼图正式 run 客户端补回 `/drag` 调用包装,测试 mock 同步走正式 run 的 `swap/drag` 服务路径。
|
||||
7. 前端门禁合并缺口修复:
|
||||
- 拼图测试运行前更新作品时同步提交 `levels`,对齐当前 `updatePuzzleWork` 契约。
|
||||
- 大鱼和 Match3D 测试 mock 对齐当前共享契约,避免 typecheck 阻塞。
|
||||
- 移除 Vite dev proxy 中重复的 `/api/creation` key,避免 build gate 将 warning 视为失败。
|
||||
|
||||
## 验证
|
||||
|
||||
本次修复应至少通过:
|
||||
|
||||
```powershell
|
||||
cargo check -p module-auth --manifest-path server-rs\Cargo.toml
|
||||
cargo check -p api-server --manifest-path server-rs\Cargo.toml
|
||||
cargo test -p module-auth --manifest-path server-rs\Cargo.toml
|
||||
cargo test -p api-server --manifest-path server-rs\Cargo.toml
|
||||
npm run check:encoding
|
||||
npm test
|
||||
npm run typecheck
|
||||
npm run build
|
||||
npm run check:content
|
||||
```
|
||||
|
||||
后端代码变更后,按项目约束还需要用 `npm run api-server:maincloud` 做一次启动验证。
|
||||
|
||||
本轮最终结果:
|
||||
|
||||
- `cargo test -p module-auth --manifest-path server-rs\Cargo.toml` 已通过,结果为 `17 passed; 0 failed`。
|
||||
- `cargo test -p api-server --manifest-path server-rs\Cargo.toml` 已通过,结果为 `237 passed; 0 failed; 4 ignored`。
|
||||
- `cargo test --manifest-path server-rs\Cargo.toml` 已通过,结果同 `api-server` 默认测试。
|
||||
- `npm test` 已通过,结果为 `160 passed` 个测试文件、`704 passed` 个用例。
|
||||
- `npm run typecheck`、`npm run build`、`npm run check:content`、`npm run check:encoding`、`git diff --check` 已通过。
|
||||
- `npm run api-server:maincloud` 已完成启动烟测,`/healthz` 返回 `200`;期间 Maincloud 订阅恢复出现 `503` warning,但未阻止服务启动。
|
||||
|
||||
仍需单独处理的非本轮阻塞:
|
||||
|
||||
- `cargo test --workspace --manifest-path server-rs\Cargo.toml` 在 Windows 原生测试链接 SpacetimeDB module crate 时失败,缺失 `bytes_sink_write`、`console_log`、`table_id_from_name`、`identity`、`datastore_table_scan_bsatn` 等 SpacetimeDB 宿主符号;这是 module crate 原生 Windows test 链接环境问题。
|
||||
- `npm run check` 当前仍会停在全仓 `lint:eslint`,涉及大量既有 import 排序、未使用符号和 hook dependency lint debt;本轮触碰文件已清掉 lint error,仅 `PlatformEntryFlowShellImpl.tsx` 保留既有 hook dependency warnings。
|
||||
@@ -11,7 +11,7 @@
|
||||
|
||||
## 2. 根因
|
||||
|
||||
### 2.1 Maincloud 目标库挂起
|
||||
### 2.1 远端目标库挂起
|
||||
|
||||
CLI 直接查询 `xushi-p4wfr` 返回:
|
||||
|
||||
@@ -20,7 +20,7 @@ Error: database is suspended
|
||||
HTTP status server error (503 Service Unavailable)
|
||||
```
|
||||
|
||||
这说明 `maincloud.spacetimedb.com` 入口在线,但具体数据库 `xushi-p4wfr` 当前不可订阅、不可查 schema、不可执行 SQL。所有依赖该库的 procedure 都会失败。
|
||||
这说明远端 SpacetimeDB 入口在线,但具体数据库 `xushi-p4wfr` 当前不可订阅、不可查 schema、不可执行 SQL。所有依赖该库的 procedure 都会失败。
|
||||
|
||||
### 2.2 认证快照同步被当成硬失败
|
||||
|
||||
@@ -64,7 +64,7 @@ HTTP status server error (503 Service Unavailable)
|
||||
|
||||
## 4. 本地可跑链路
|
||||
|
||||
Maincloud `xushi-p4wfr` 挂起期间,抓大鹅本地体验应使用本地 SpacetimeDB:
|
||||
远端 `xushi-p4wfr` 挂起期间,抓大鹅本地体验应使用本地 SpacetimeDB:
|
||||
|
||||
```powershell
|
||||
spacetime --root-dir=server-rs/.spacetimedb/local start --edition standalone --listen-addr 127.0.0.1:3101
|
||||
@@ -75,10 +75,10 @@ spacetime --root-dir=server-rs/.spacetimedb/local publish xushi-p4wfr --server h
|
||||
再让 Rust API 指向本地库:
|
||||
|
||||
```powershell
|
||||
$env:GENARRATIVE_SPACETIME_MAINCLOUD_SERVER_URL="http://127.0.0.1:3101"
|
||||
$env:GENARRATIVE_SPACETIME_MAINCLOUD_DATABASE="xushi-p4wfr"
|
||||
$env:GENARRATIVE_SPACETIME_MAINCLOUD_TOKEN=""
|
||||
npm run api-server:maincloud
|
||||
$env:GENARRATIVE_SPACETIME_SERVER_URL="http://127.0.0.1:3101"
|
||||
$env:GENARRATIVE_SPACETIME_DATABASE="xushi-p4wfr"
|
||||
$env:GENARRATIVE_SPACETIME_TOKEN=""
|
||||
npm run api-server
|
||||
```
|
||||
|
||||
最后重启前端:
|
||||
@@ -96,10 +96,10 @@ npm run dev:web
|
||||
1. `GET http://127.0.0.1:3000/api/auth/login-options` 返回 `["phone","password"]`。
|
||||
2. `GET http://127.0.0.1:3000/api/runtime/match3d/gallery` 返回 `{"items":[]}`,不再返回 SpacetimeDB 503。
|
||||
3. 未登录请求 `POST http://127.0.0.1:3000/api/creation/match3d/sessions` 返回 `401`,说明同源请求已进入 Rust 鉴权层,不再被 Vite `404`。
|
||||
4. 隔离端口指向挂起的 Maincloud 并使用 mock 短信时,手机号验证码登录返回 `200` 和 token;日志只记录“认证快照写入 SpacetimeDB 失败,当前认证流程继续”。
|
||||
4. 隔离端口指向挂起的远端库并使用 mock 短信时,手机号验证码登录返回 `200` 和 token;日志只记录“认证快照写入 SpacetimeDB 失败,当前认证流程继续”。
|
||||
|
||||
## 6. 后续
|
||||
|
||||
1. Maincloud `xushi-p4wfr` 仍需恢复数据库挂起状态,否则正式云端玩法 procedure 仍不可用。
|
||||
1. 远端 `xushi-p4wfr` 仍需恢复数据库挂起状态,否则对应玩法 procedure 仍不可用。
|
||||
2. 本地开发如只为体验抓大鹅,可继续使用本地 SpacetimeDB 链路。
|
||||
3. 认证快照同步失败会影响进程重启后的云端恢复完整性,需要在 Maincloud 恢复后重新完成一次成功同步。
|
||||
3. 认证快照同步失败会影响进程重启后的远端恢复完整性,需要在目标库恢复后重新完成一次成功同步。
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
但当前链路仍暴露出两个直接体验问题:
|
||||
|
||||
1. 前端草稿进度页仍把大鱼吃小鱼展示成单个 `compile` 步骤,用户会感觉“整个生成过程只有一步,而且一直卡在第一步”。
|
||||
2. 前端在打开大鱼草稿或结果页时,会通过 `GET /api/runtime/big-fish/agent/sessions/:sessionId` 拉取完整会话;当 Maincloud 上游偶发抖动时,Rust `spacetime-client` 统一 10 秒超时会直接映射成 `502`,用户会看到反复报错。
|
||||
2. 前端在打开大鱼草稿或结果页时,会通过 `GET /api/runtime/big-fish/agent/sessions/:sessionId` 拉取完整会话;当 SpacetimeDB 上游偶发抖动时,Rust `spacetime-client` 统一 10 秒超时会直接映射成 `502`,用户会看到反复报错。
|
||||
|
||||
## 修复口径
|
||||
|
||||
@@ -39,7 +39,7 @@
|
||||
|
||||
这样可以覆盖两类常见情况:
|
||||
|
||||
1. Maincloud 连接偶发抖动,第一次 procedure 超时但第二次马上恢复。
|
||||
1. SpacetimeDB 连接偶发抖动,第一次 procedure 超时但第二次马上恢复。
|
||||
2. 用户打开草稿页时碰到短暂断链,不再被立即判定成稳定的坏网关故障。
|
||||
|
||||
## 落地范围
|
||||
|
||||
@@ -31,3 +31,12 @@
|
||||
- 本地与远端部署:`RUST_LOCAL_AND_REMOTE_DEPLOYMENT_SCRIPTS_2026-04-22.md`、`JENKINS_RUST_BUILD_DEPLOY_PIPELINES_2026-04-23.md`。
|
||||
|
||||
如果旧文档与本基线冲突,以本基线和更新日期更近的 Rust / SpacetimeDB 文档为准。
|
||||
|
||||
## 4. DDD 重构总纲补充
|
||||
|
||||
`2026-04-28` 起,`server-rs` 后续后端改动还必须同时遵循 [SERVER_RS_DDD_FULL_REFACTOR_2026-04-28.md](./SERVER_RS_DDD_FULL_REFACTOR_2026-04-28.md):
|
||||
|
||||
- `module-*` 只承载领域模型、命令、应用编排结果、领域事件和领域错误。
|
||||
- `spacetime-module` 只承载 SpacetimeDB 表、reducer、procedure、事务 adapter 与 mapper。
|
||||
- `api-server` 只承载 HTTP / SSE / BFF adapter 和外部平台服务编排。
|
||||
- 任何表结构变化仍必须同步 `migration.rs` 与 [SPACETIMEDB_TABLE_CATALOG.md](./SPACETIMEDB_TABLE_CATALOG.md)。
|
||||
|
||||
@@ -95,7 +95,7 @@ Genarrative-Database-Import
|
||||
|
||||
## 5. 本地部署测试参数
|
||||
|
||||
`Genarrative-Build-And-Deploy` 增加以下本地发布包参数,便于在 Jenkins 中测试本地 SpacetimeDB,不依赖 Maincloud:
|
||||
`Genarrative-Build-And-Deploy` 增加以下本地发布包参数,便于在 Jenkins 中测试本地 SpacetimeDB:
|
||||
|
||||
1. `DATABASE`:发布包默认数据库名,默认 `genarrative-pipeline-local-test`。SpacetimeDB CLI 当前要求数据库名匹配 `^[a-z0-9]+(-[a-z0-9]+)*$`,只能使用小写字母、数字,并用单个短横线分隔;不要使用大写字母、点号、下划线、首尾短横线或连续短横线。
|
||||
2. `API_PORT`:发布包内 api-server 端口,默认 `8082`。
|
||||
@@ -111,7 +111,7 @@ SERVER_URL=http://127.0.0.1:3101
|
||||
DEPLOY_DIRECTORY=/var/lib/jenkins/deploy/Genarrative
|
||||
```
|
||||
|
||||
这样脚本会自动使用 `/var/lib/jenkins/deploy/Genarrative/.spacetimedb` 作为 `spacetime --root-dir`,避免回退到 Jenkins 用户全局 CLI 登录态,也避免误连 Maincloud。
|
||||
这样脚本会自动使用 `/var/lib/jenkins/deploy/Genarrative/.spacetimedb` 作为 `spacetime --root-dir`,避免回退到 Jenkins 用户全局 CLI 登录态,也避免误连非本地目标。
|
||||
|
||||
## 6. 文件清单
|
||||
|
||||
|
||||
@@ -76,4 +76,4 @@ Responses 非流式解析优先读取 `output_text`,再兼容 `output[].conten
|
||||
3. `platform-llm` 单测覆盖 Responses 非流式、Responses SSE、Responses web_search tools 请求体。
|
||||
4. `cargo test -p platform-llm --manifest-path server-rs/Cargo.toml` 通过。
|
||||
5. `cargo test -p api-server creation_agent_llm_turn --manifest-path server-rs/Cargo.toml` 通过。
|
||||
6. 修改后按项目约束使用 `npm run api-server:maincloud` 重新启动后端,并执行相应自动测试。
|
||||
6. 修改后按项目约束使用 `npm run api-server` 重新启动后端,并执行相应自动测试。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
日期:`2026-04-22`
|
||||
|
||||
归档说明:截至 `2026-04-26`,Rust 迁移已完成,旧 `server-node/` 已删除,M7 阶段性预检包装入口已移除。后续长期检查统一使用 `server-rs/scripts/check.ps1`、`server-rs/scripts/smoke.ps1`、`server-rs/scripts/oss-smoke.ps1` 与 `npm run api-server:maincloud`。
|
||||
归档说明:截至 `2026-04-26`,Rust 迁移已完成,旧 `server-node/` 已删除,M7 阶段性预检包装入口已移除。后续长期检查统一使用 `server-rs/scripts/check.ps1`、`server-rs/scripts/smoke.ps1`、`server-rs/scripts/oss-smoke.ps1` 与 `npm run api-server`。
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
|
||||
@@ -277,56 +277,56 @@ Rust DTO 只承载 HTTP contract 和跨 crate 稳定模型,不直接暴露 `mo
|
||||
|
||||
## 6.1 创作链
|
||||
|
||||
1. `create_match3d_agent_session(input)`
|
||||
1. `create_match3d_agent_session(input)`
|
||||
创建会话,写入初始配置或空配置,返回 session snapshot。
|
||||
|
||||
2. `get_match3d_agent_session(input)`
|
||||
2. `get_match3d_agent_session(input)`
|
||||
获取会话、消息和当前 draft。
|
||||
|
||||
3. `submit_match3d_agent_message(input)`
|
||||
3. `submit_match3d_agent_message(input)`
|
||||
只写 user message,不调用 LLM,不生成 assistant 回复。
|
||||
|
||||
4. `finalize_match3d_agent_message_turn(input)`
|
||||
4. `finalize_match3d_agent_message_turn(input)`
|
||||
由 `api-server` LLM turn 完成后写入 assistant message、配置状态、进度和 `last_assistant_reply`。
|
||||
|
||||
5. `compile_match3d_draft(input)`
|
||||
5. `compile_match3d_draft(input)`
|
||||
校验题材、需要消除次数、难度,生成草稿和作品 draft profile。
|
||||
|
||||
## 6.2 作品链
|
||||
|
||||
1. `update_match3d_work(input)`
|
||||
1. `update_match3d_work(input)`
|
||||
更新游戏名称、标签、封面、题材、需要消除次数和难度。
|
||||
|
||||
2. `publish_match3d_work(input)`
|
||||
2. `publish_match3d_work(input)`
|
||||
校验基础信息完整后发布作品,不要求试玩通关。
|
||||
|
||||
3. `list_match3d_works(input)`
|
||||
3. `list_match3d_works(input)`
|
||||
查询当前用户作品。
|
||||
|
||||
4. `get_match3d_work_detail(input)`
|
||||
4. `get_match3d_work_detail(input)`
|
||||
查询作品详情,支持结果页恢复和作品详情页。
|
||||
|
||||
5. `delete_match3d_work(input)`
|
||||
5. `delete_match3d_work(input)`
|
||||
可后置;若接入创作中心删除,需要与其他玩法卡片删除语义一致。
|
||||
|
||||
## 6.3 运行态链
|
||||
|
||||
1. `start_match3d_run(input)`
|
||||
1. `start_match3d_run(input)`
|
||||
基于作品配置生成单局快照,返回 `Match3DRunSnapshot`。
|
||||
|
||||
2. `get_match3d_run(input)`
|
||||
2. `get_match3d_run(input)`
|
||||
返回当前权威运行态快照。
|
||||
|
||||
3. `click_match3d_item(input)`
|
||||
3. `click_match3d_item(input)`
|
||||
根据 `run_id / item_instance_id / client_snapshot_version` 权威确认点击、入槽、三消、失败或胜利,返回新快照和确认结果。
|
||||
|
||||
4. `stop_match3d_run(input)`
|
||||
4. `stop_match3d_run(input)`
|
||||
把运行态标记为 `Stopped`,供试玩中止和返回结果页使用。
|
||||
|
||||
5. `restart_match3d_run(input)`
|
||||
5. `restart_match3d_run(input)`
|
||||
复用同一作品配置创建新 run,返回新快照。
|
||||
|
||||
6. `finish_match3d_time_up(input)`
|
||||
6. `finish_match3d_time_up(input)`
|
||||
可选。若倒计时由前端触发,前端在倒计时归零时调用该 procedure,后端确认 `TimeUp`。也可以由 `click_match3d_item` 或 `get_match3d_run` 懒确认超时。
|
||||
|
||||
## 6.4 procedure 输入输出约束
|
||||
@@ -784,7 +784,7 @@ B3 当前落地状态:
|
||||
1. 创作到发布到试玩主链通过。
|
||||
2. 运行态点击、入槽、三消、失败、胜利通过。
|
||||
3. 移动端视口检查通过。
|
||||
4. `npm run api-server:maincloud` 通过。
|
||||
4. `npm run api-server` 通过。
|
||||
5. 对应测试与 `npm run check:encoding` 通过。
|
||||
|
||||
---
|
||||
@@ -820,7 +820,7 @@ npm run check:encoding -- docs/technical/MATCH3D_CREATION_AND_RUNTIME_MINIMAL_IM
|
||||
```powershell
|
||||
cargo test -p module-match3d
|
||||
cargo test -p shared-contracts
|
||||
npm run api-server:maincloud
|
||||
npm run api-server
|
||||
npm run check:encoding
|
||||
```
|
||||
|
||||
|
||||
@@ -110,4 +110,4 @@ server-rs/crates/module-match3d
|
||||
1. `cargo test -p module-match3d` 通过。
|
||||
2. `cargo test -p shared-contracts match3d` 通过。
|
||||
3. `npm run check:encoding` 覆盖新增中文文档和新增源码。
|
||||
4. 本阶段不要求运行 `npm run api-server:maincloud`,因为未修改后端运行服务入口、SpacetimeDB 表或 `api-server` facade。
|
||||
4. 本阶段不要求运行 `npm run api-server`,因为未修改后端运行服务入口、SpacetimeDB 表或 `api-server` facade。
|
||||
|
||||
@@ -143,4 +143,4 @@ npm run check:encoding
|
||||
3. 不把 Match3D 公开广场并入更复杂的推荐、排行和运营榜单策略。
|
||||
4. 不删除 `/match3d` 本地 playground;它作为开发调试入口继续保留。
|
||||
5. 全量 `npm run typecheck` 曾存在非 Match3D 既有阻塞,本轮以 Q1 定向测试和后端定向检查作为集成验收口径。
|
||||
6. Maincloud 运行态仍依赖当前 SpacetimeDB 环境稳定性;如 `npm run api-server:maincloud` 现场遇到订阅 HTTP 500,应按 Maincloud/SpacetimeDB 联调链路单独排查。
|
||||
6. 运行态仍依赖当前 SpacetimeDB 环境稳定性;如 `npm run api-server` 现场遇到订阅 HTTP 500,应按本地 SpacetimeDB 联调链路单独排查。
|
||||
|
||||
@@ -0,0 +1,74 @@
|
||||
# 抓大鹅运行态 3D 几何体实验 2026-05-02
|
||||
|
||||
## 1. 实验目标
|
||||
|
||||
本轮只验证抓大鹅运行态把可消除物从 2D 纯色几何图案切换为 3D 几何体后的可读性、点击手感和堆叠碰撞观感。
|
||||
|
||||
3D 表现层必须满足:
|
||||
|
||||
1. 圆形图案映射为球体。
|
||||
2. 方形图案映射为方块。
|
||||
3. 三角形、菱形、五角星、六边形、胶囊、心形、梯形、平行四边形等现有视觉键映射为近似 3D 几何体。
|
||||
4. 物体在圆形空间内保持边界约束,并使用物理模拟产生轻微碰撞、堆叠、晃动效果。
|
||||
5. 点击、备选栏、消除、胜负判定仍使用当前后端权威快照与前端即时反馈协议,不把规则真相迁到前端。
|
||||
|
||||
## 2. 回退要求
|
||||
|
||||
这是一次可取消实验,不替换现有 2D 方案。
|
||||
|
||||
1. 现有 `Match3DVisualIcon`、`Match3DToken` 和托盘 2D 图案渲染代码必须保留。
|
||||
2. 新增 3D 表现层只作为运行态棋盘的可选渲染分支。
|
||||
3. 当浏览器不支持 WebGL、3D 依赖加载失败或实验开关关闭时,运行态必须自动回到现有 2D 图案表现。
|
||||
4. 托盘继续使用当前 2D 图标,便于玩家识别已选物品,也便于实验失败时快速回滚。
|
||||
|
||||
## 3. 工程落点
|
||||
|
||||
本轮只改前端表现层:
|
||||
|
||||
```text
|
||||
src/components/match3d-runtime/Match3DPhysicsBoard.tsx
|
||||
src/components/match3d-runtime/Match3DRuntimeShell.tsx
|
||||
src/components/match3d-runtime/Match3DRuntimeShell.test.tsx
|
||||
src/components/match3d-runtime/match3dRuntimePresentation.ts
|
||||
src/components/match3d-runtime/match3dVisualAssets.tsx
|
||||
```
|
||||
|
||||
新增依赖:
|
||||
|
||||
```text
|
||||
three
|
||||
cannon-es
|
||||
@types/three
|
||||
```
|
||||
|
||||
3D 棋盘默认启用;需要快速回到当前 2D demo 表现时,在运行态 URL 上追加任一参数:
|
||||
|
||||
```text
|
||||
?match3dRender=2d
|
||||
?match3d3d=off
|
||||
```
|
||||
|
||||
3D 分支只读取后端快照中的物品坐标、层级、可点击状态和视觉键。物理碰撞、轻微堆叠和几何体姿态只作为前端表现层,不改变消除规则、备选栏规则、胜负判定或最终权威快照。
|
||||
|
||||
`match3dVisualAssets.tsx` 保留 2D 纯色几何图案映射,运行态托盘继续使用该 2D 图标;`match3dRuntimePresentation.ts` 收口显示层坐标和状态兼容,避免异常旧坐标把 2D 或 3D 物体推到圆形边界外。
|
||||
|
||||
## 4. 验收口径
|
||||
|
||||
1. `/match3d` 能打开并默认看到 3D 几何体棋盘。
|
||||
2. 3D 几何体保持在圆形区域内,不被圆形边界裁切到不可点。
|
||||
3. 物体进入场景后有轻微物理碰撞和堆叠稳定过程。
|
||||
4. 点击 3D 物体后仍执行原有乐观入槽、后端确认、三消反馈和结算。
|
||||
5. 单元测试仍覆盖 2D 回退图案,确保回退路径没有被删除。
|
||||
6. 390px 移动端与桌面端均不能出现横向溢出,顶部状态、圆形棋盘和 7 格备选栏都要完整可见。
|
||||
|
||||
## 5. 锅型容器优化
|
||||
|
||||
2026-05-02 追加一轮 3D 表现优化,把运行态圆形空间明确解释为一口有固定深度和确定边界的锅。
|
||||
|
||||
编码口径:
|
||||
|
||||
1. 相机改为俯视角,玩家优先看到锅内物体的平面分布、遮挡关系和向上堆叠。
|
||||
2. 3D 场景里的圆形区域拆成锅底、锅壁和锅沿三层视觉结构,锅壁有固定高度,锅沿明确标出边界。
|
||||
3. 物理世界使用同一个锅内半径作为水平活动边界,所有可消除物体的初始位置和运行中位置都必须被约束在圆形锅内。
|
||||
4. 物体受到重力后只允许在锅内碰撞、滑动、翻滚和向上堆叠,不能因为碰撞或初始坐标散落到圆形区域外。
|
||||
5. 该优化仍只属于前端 3D 表现层,不改变后端运行态坐标、点击权威判定、备选栏、消除和胜负规则。
|
||||
@@ -119,10 +119,10 @@ cargo check -p spacetime-client --manifest-path server-rs\Cargo.toml
|
||||
cargo check -p api-server --manifest-path server-rs\Cargo.toml
|
||||
cargo test -p shared-contracts match3d --manifest-path server-rs\Cargo.toml
|
||||
npm run check:encoding
|
||||
npm run api-server:maincloud
|
||||
npm run api-server
|
||||
```
|
||||
|
||||
`api-server:maincloud` 是修改后端后的必跑项;如果本地缺少 Maincloud 环境或 SpacetimeDB 发布态不一致,需要在最终结果里明确说明。
|
||||
`api-server` 是修改后端后的必跑项;如果本地 SpacetimeDB 发布态不一致,需要在最终结果里明确说明。
|
||||
|
||||
## 7. 后续接入点
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user