suzmii
ce614d59c1
Project CI / AI game creator shell Rust crates (pull_request) Successful in 6m1s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 7m10s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Successful in 7m58s
Project CI / Backend tests (pull_request) Successful in 9m10s
Project CI / Frontend tests (pull_request) Successful in 2m58s
Project CI / AI game creator shell web tests (pull_request) Successful in 2m32s
Project CI / Native shell tests (pull_request) Successful in 6m37s
Project CI / Repository checks (pull_request) Successful in 4m55s
裁定（与族谱 `truncated` 同约定）：`memberCount` = **真实可见成员数**（不受展示上限污染），新增布尔 `rootsTruncated`，**仅当 `roots` 被 50 上限截断时为 true**。此前两个数被同一个 50 上限截断 ⇒ 可见成员 > 50 时静默截断，客户端既看不到全部树、也拿不到任何信号。 - 纯函数：`game_distribution_theme_roots_truncated(visible_member_count, returned_root_count)` （相等 / 回传更多 ⇒ false；后者是防御性口径：两组数字不同源时不得凭空报「还有更多」）。 - 契约：`GameDistributionThemeDetail` 加 `roots_truncated`（serde camelCase ⇒ `rootsTruncated`）， TS 镜像同步；parity `public_theme_detail_payload.mustEmit` 6 键 → **7 键**。 - 事务：`member_count` 走可见成员清单的 `len()`（**不再**经 `page_theme_members` 与上限），`roots` 仍是 同一清单排序后取前 50，`rootsTruncated` 由纯函数算出（不写死「>50 就 true」——阈值与上限是两个 独立事实）；列表入口共用同一计数函数 ⇒ 同一主题在列表与详情里不会报出两个 `memberCount`。 - api-server：`public_theme_detail_payload` 增加 `rootsTruncated`；形状单测 6 → 7 键，并加 `memberCount=120 / roots=1 / rootsTruncated=true` 用例，证明两个键口径独立。 - 结构断言同步修正：列表侧原「成员数与 roots 共用同一上限」改为「成员数数的是全部可见成员（断言 源码里不含切页函数与上限常量）」；详情侧改为「必须调用共享纯函数 + 不得再恒等 `roots.len()` + 该字段必须进入返回值」。 - 生成绑定：`module_bindings/game_distribution_theme_detail_result_type.rs` 手改后用临时 out-dir 重跑 `spacetime generate --lang rust` 逐字节校对一致。**wire format 变更 ⇒ 部署需重新 publish 模块** （客户端绑定已同步）。 - 文档：技术方案 §3.4 / §3.10.6 / §3.10.9（原「已知限制·三个备选待拍板」→ 已定口径）、里程碑 （依赖、接口表、验收标准、纯函数表、测试清单、待确认项）、以及数据契约文档里那句「主题详情的 roots 与列表的 memberCount 永远一致」（本改动已使其为假）。 门禁：wasm build 0；`cargo check --all-targets` 0；`cargo test -p api-server game_distribution` 86 passed； `cargo test -p module-game-distribution` **101 passed**；`cargo test -p spacetime-module` 286 passed / 1 ignored；DTO parity 0（58 组 / **15** 构建器 / 12 手拼类型）；`check:spacetime-schema` 0（96 tables）； `check:encoding` 0（5420 files）；`cargo fmt --all -- --check` 0；`git diff --check` 0。 遗留（不在本仓可改范围，需前端 session 跟进）：`src/services/gameDistributionClient.ts` 有自己一份主题 详情本地类型与 normalize，会丢弃 `rootsTruncated`（约 3 行小改），因此网页主题页暂时拿不到截断信号； admin-web 走共享契约类型，后台侧即时生效。
Genarrative / 陶泥儿
一个 AI 原生互动内容与小游戏平台，当前主站聚焦图片画布创作、项目与素材管理，以及账号、钱包和后台管理等平台公共能力。
当前已经具备这些主要能力：
- 图片画布编辑、项目与素材管理
- 图片、视频、音频等外部生成任务
- 账号、钱包、充值、兑换码与个人资料
- 后台运营、配置与生产运维工具
- AI 游戏创作独立 App
运行
前置条件：
- Node.js
- Rust / Cargo
- SpacetimeDB CLI
安装依赖：
npm install
该命令会按根 package.json 的 npm workspaces 一次安装主站、Admin、Mobile、Desktop、AGC、Preview Deployer、内部 packages 与工具依赖；仓库只使用根 package-lock.json，不要在子目录单独执行 npm install / npm ci 或提交嵌套 lockfile。
准备环境变量：
- 复制
.env.example为.env.local - 只填写本次联调所需配置；不要提交
.env.local、密钥、Token 或其它本地认证信息 - api-server 环境变量和 Provider 配置以
.env.example及当前开发运维文档为准
启动开发环境：
npm run dev
补充说明：
npm run dev会启动 SpacetimeDB standalone、独立bgfilter-worker、Rustapi-server、主站 Vite 与后台 Vite，适合完整联调；内部 worker ready 后才启动 API。- 主站默认地址是
http://127.0.0.1:3000，后台可从http://127.0.0.1:3000/admin/进入，也可直连http://127.0.0.1:3102。 - 五个模块可独立启动：
npm run dev:spacetime、npm run dev:api-server、npm run dev:bgfilter-worker、npm run dev:web、npm run dev:admin-web；其中dev:api-server会安全带起同 runner 的 BgFilter worker 依赖。 - 如需自动刷新后端模块，使用
npm run dev -- --watch；其中spacetime-module改动后只会重新发布模块，不会重启 standalone，Rust 源码改动会把api-server与bgfilter-worker作为一个组合单元重启。主站和后台前端源码变化交给 Vite 自身 HMR，不由外层 watcher 重启。非 watch 模式下可在npm run dev终端输入rs api-server、rs bgfilter-worker、rs web、rs admin-web、rs spacetime或rs all，其中rs spacetime也是只重新发布模块。
构建生产包：
npm run build
常用检查
类型检查：
npm run lint
编码检查：
npm run check:encoding
主要结构
主运行时：
- src/active-main.tsx
- src/ActiveApp.tsx
- src/AuthenticatedApp.tsx
- src/routing/activeAppRoutes.tsx
- src/components/platform-entry/PlatformEntryActiveFlowShell.tsx
创作与项目能力：
- src/components/image-editor/ImageCanvasEditorView.tsx
- src/components/creation-home/CreationLandingView.tsx
- src/components/project/ProjectGalleryView.tsx
文档入口
docs/ 已在 2026-08-25 按当前代码与运行态重新收口。旧 PRD、设计、审计、阶段计划和技术流水账不再作为实现依据；专题文档的现役清单统一从 docs/README.md 进入：
- docs/README.md：当前文档总入口。
- docs/【项目基线】当前产品与工程约束-2026-05-15.md：产品、命名、UI、协作和废弃路线。
- docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md：DDD 边界、API 分组、SpacetimeDB schema 规则和表目录。
- docs/【玩法创作】平台入口与玩法链路-2026-05-15.md：平台现役入口、项目页和画布链路。
- docs/【开发运维】本地开发验证与生产运维-2026-05-15.md：本地启动、检查、部署、埋点和运营查询。
- docs/project-memory/README.md：团队共享的当前项目记忆、决策和未关闭事项。
- UI_CODING_STANDARD.md：像素 UI 资产与编码规范。