1
This commit is contained in:
@@ -45,7 +45,7 @@
|
||||
修复：
|
||||
|
||||
1. 在 `map_password_entry_error(...)` 中补充 `InvalidPublicUserCode`
|
||||
2. 返回中文错误文案 `陶泥号格式不正确`
|
||||
2. 返回中文错误文案 `百梦号格式不正确`
|
||||
|
||||
### 3.3 `module-custom-world` 的 `Display` 分支未覆盖新字段错误
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# 资产操作陶泥币消耗接入方案
|
||||
# 资产操作光点消耗接入方案
|
||||
|
||||
## 背景
|
||||
|
||||
当前陶泥币钱包余额、充值流水与邀请奖励已经收口到 `server-rs/crates/spacetime-module/src/runtime/profile.rs`。资产图片生成和作品发布由 Axum API 调用外部模型或写入业务状态，SpacetimeDB reducer/procedure 不能直接执行外部网络生成，因此计费需要拆成两层：
|
||||
当前光点钱包余额、充值流水与邀请奖励已经收口到 `server-rs/crates/spacetime-module/src/runtime/profile.rs`。资产图片生成和作品发布由 Axum API 调用外部模型或写入业务状态，SpacetimeDB reducer/procedure 不能直接执行外部网络生成，因此计费需要拆成两层：
|
||||
|
||||
- SpacetimeDB 负责钱包余额和流水的原子变更。
|
||||
- Axum 资产操作服务负责在执行业务资产操作前扣费，并在生成、持久化或发布失败时补偿退款。
|
||||
@@ -24,13 +24,13 @@
|
||||
暂不接入以下入口：
|
||||
|
||||
- 旧资产工坊角色主形象/动作生成接口：当前仍使用 `asset-tool` 作为兼容归属，无法确认真实用户。
|
||||
- 手动上传封面：不调用外部生成模型，不消耗陶泥币。
|
||||
- 手动上传封面：不调用外部生成模型，不消耗光点。
|
||||
- 自定义世界草稿自动补图链路：属于后台补全流程，避免一次用户操作触发多笔不可预期扣费。
|
||||
- 文本实体、NPC 生成：本次需求聚焦图片资产和发布资产操作，首期只覆盖可明确归属的入口。
|
||||
|
||||
## 计费规则
|
||||
|
||||
- 每次可计费资产操作消耗 `1` 枚陶泥币。
|
||||
- 每次可计费资产操作消耗 `1` 枚光点。
|
||||
- 图片生成和作品发布都按资产操作计费；余额不足时禁止继续执行。
|
||||
- 在调用外部图片生成或发布 mutation 前预扣，余额不足时直接返回业务错误，不继续调用后续资产操作。
|
||||
- 如果图片生成、远程下载、OSS 写入、资产记录确认或发布 mutation 失败，资产操作服务自动发起同额退款。
|
||||
|
||||
@@ -34,7 +34,7 @@ Stage 1 已把 Rust 鉴权快照同步到 SpacetimeDB 的 `auth_store_snapshot`
|
||||
| 字段 | 类型 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| `user_id` | `String` | 主键。 |
|
||||
| `public_user_code` | `String` | 公开陶泥号。 |
|
||||
| `public_user_code` | `String` | 公开百梦号。 |
|
||||
| `username` | `String` | 当前账号用户名。 |
|
||||
| `display_name` | `String` | 展示名。 |
|
||||
| `phone_number_masked` | `Option<String>` | 脱敏手机号。 |
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
- 当前场景的核心任务描述。
|
||||
- 文本会作为游戏中首次进入某个场景生成章节任务的关键上下文。
|
||||
- 必须结合场景描述、场景入口钩子、出场角色与 3 幕事件，说明玩家首次进入该场景时要完成什么。
|
||||
- 世界档案的场景详情页必须直接展示该字段，便于陶泥主确认每个场景的默认章节任务。
|
||||
- 世界档案的场景详情页必须直接展示该字段，便于百梦主确认每个场景的默认章节任务。
|
||||
|
||||
### Landmark 生成源字段
|
||||
|
||||
|
||||
@@ -406,6 +406,12 @@ Node 侧入口位于：
|
||||
5. `profile_dashboard_state.total_play_time_ms` 通过同一用户同一世界的 `runtimeStats.playTimeMs - last_observed_play_time_ms` 增量累积，后端使用 `saturating_sub` 防止旧快照回退导致负增量。
|
||||
6. 作品卡上的公开热度计数如果需要覆盖 RPG 作品，应另立公开作品统计方案；不能把个人 `profile_played_world` 误当成全站作品 `playCount`。
|
||||
|
||||
## 10.2 2026-05-01 新用户注册赠送修正
|
||||
|
||||
新注册用户默认获得 `10` 个光点，注册链路通过 SpacetimeDB procedure 写入 `profile_dashboard_state.wallet_balance` 与 `profile_wallet_ledger`。流水来源为 `new_user_registration_reward`，流水 ID 固定为 `new-user-registration:{user_id}`，重复调用不重复发放。
|
||||
|
||||
注册赠送、邀请码奖励、充值、兑换码、资产扣费等都属于真实平台钱包流水。用户只要已经存在非 `snapshot_sync` 钱包流水，后续 `runtime_snapshot.game_state.playerCurrency` 不再覆盖 `wallet_balance`，只继续刷新游玩时长和玩过世界，避免首次保存旧运行态货币字段时把注册赠送覆盖成 `0`。
|
||||
|
||||
## 11. 测试策略
|
||||
|
||||
### 11.1 必跑
|
||||
|
||||
@@ -6,33 +6,33 @@
|
||||
|
||||
本轮在“我的”页面的“会员充值”入口落地账户充值弹窗，包含两个页签：
|
||||
|
||||
1. `陶泥币充值`
|
||||
1. `光点充值`
|
||||
2. `会员卡充值`
|
||||
|
||||
前端只负责展示与发起购买，套餐、价格、赠送规则、会员权益、生效时间、钱包余额与交易流水统一由 `server-rs` 后端返回。当前没有真实支付网关，本轮采用服务端模拟支付成功：创建订单后立即写入余额或会员状态，并返回最新账户中心快照。后续接入真实支付时，只替换订单支付状态推进，不改前端套餐与账户快照 contract。
|
||||
|
||||
## 2. 产品规则
|
||||
|
||||
### 2.1 陶泥币充值套餐
|
||||
### 2.1 光点充值套餐
|
||||
|
||||
| productId | 陶泥币 | 金额分 | 徽标 | 说明 |
|
||||
| productId | 光点 | 金额分 | 徽标 | 说明 |
|
||||
| --- | ---: | ---: | --- | --- |
|
||||
| `points_60` | 60 | 600 | 首充双倍 | 首充送60陶泥币 |
|
||||
| `points_180` | 180 | 1800 | 首充双倍 | 首充送180陶泥币 |
|
||||
| `points_300` | 300 | 3000 | 首充双倍 | 首充送300陶泥币 |
|
||||
| `points_680` | 680 | 6800 | 首充双倍 | 首充送680陶泥币 |
|
||||
| `points_1280` | 1280 | 12800 | 首充双倍 | 首充送1280陶泥币 |
|
||||
| `points_3280` | 3280 | 32800 | 首充双倍 | 首充送3280陶泥币 |
|
||||
| `points_60` | 60 | 600 | 首充双倍 | 首充送60光点 |
|
||||
| `points_180` | 180 | 1800 | 首充双倍 | 首充送180光点 |
|
||||
| `points_300` | 300 | 3000 | 首充双倍 | 首充送300光点 |
|
||||
| `points_680` | 680 | 6800 | 首充双倍 | 首充送680光点 |
|
||||
| `points_1280` | 1280 | 12800 | 首充双倍 | 首充送1280光点 |
|
||||
| `points_3280` | 3280 | 32800 | 首充双倍 | 首充送3280光点 |
|
||||
|
||||
陶泥币充值固定为 `¥6 / ¥18 / ¥30 / ¥68 / ¥128 / ¥328` 六个档位。全部档位参与首充双倍：用户历史上没有 `points_recharge` 流水时，本次购买到账陶泥币为基础陶泥币与等额赠送陶泥币之和；已有充值流水后只到账基础陶泥币。实际到账陶泥币写入交易流水，余额以 SpacetimeDB projection 为准。
|
||||
光点充值固定为 `¥6 / ¥18 / ¥30 / ¥68 / ¥128 / ¥328` 六个档位。全部档位参与首充双倍：用户历史上没有 `points_recharge` 流水时，本次购买到账光点为基础光点与等额赠送光点之和；已有充值流水后只到账基础光点。实际到账光点写入交易流水，余额以 SpacetimeDB projection 为准。
|
||||
|
||||
### 2.2 会员卡套餐
|
||||
|
||||
| productId | 类型 | 天数 | 金额分 | 权益 |
|
||||
| --- | --- | ---: | ---: | --- |
|
||||
| `member_month` | 月卡 | 30 | 2800 | 免陶泥币回合数100，每日签到加成0% |
|
||||
| `member_season` | 季卡 | 90 | 7800 | 免陶泥币回合数100，每日签到加成100% |
|
||||
| `member_year` | 年卡 | 365 | 24800 | 免陶泥币回合数100，每日签到加成210% |
|
||||
| `member_month` | 月卡 | 30 | 2800 | 免光点回合数100，每日签到加成0% |
|
||||
| `member_season` | 季卡 | 90 | 7800 | 免光点回合数100，每日签到加成100% |
|
||||
| `member_year` | 年卡 | 365 | 24800 | 免光点回合数100，每日签到加成210% |
|
||||
|
||||
购买会员时，如果当前会员仍有效，则从当前到期时间顺延；如果已过期或从未购买，则从当前服务端时间开始计算。状态只区分 `普通` 与已生效会员，前端不自行推断。
|
||||
|
||||
@@ -42,8 +42,8 @@
|
||||
|
||||
需要 Bearer JWT。返回：
|
||||
|
||||
1. 当前陶泥币余额、会员状态、到期时间
|
||||
2. 陶泥币套餐与会员套餐
|
||||
1. 当前光点余额、会员状态、到期时间
|
||||
2. 光点套餐与会员套餐
|
||||
3. 会员权益表
|
||||
4. 最近订单摘要
|
||||
|
||||
@@ -64,7 +64,7 @@
|
||||
|
||||
1. 校验 `productId`
|
||||
2. 后端创建已支付订单
|
||||
3. 陶泥币套餐写入钱包余额与流水
|
||||
3. 光点套餐写入钱包余额与流水
|
||||
4. 会员套餐写入会员状态
|
||||
5. 返回最新账户中心快照与订单摘要
|
||||
|
||||
@@ -74,15 +74,15 @@
|
||||
|
||||
1. “我的”页会员充值按钮打开独立弹窗，不在当前面板下方展开。
|
||||
2. 弹窗顶部标题为 `账户充值`，右上角关闭。
|
||||
3. 默认打开 `陶泥币充值`，可切换到 `会员卡充值`。
|
||||
3. 默认打开 `光点充值`，可切换到 `会员卡充值`。
|
||||
4. 点击套餐后调用下单接口，按钮进入处理中状态，成功后刷新 `profileDashboard`。
|
||||
5. 弹窗内不写大段说明文案，只保留必要金额、陶泥币、会员权益和状态反馈。
|
||||
5. 弹窗内不写大段说明文案，只保留必要金额、光点、会员权益和状态反馈。
|
||||
6. 会员卡充值区以套餐卡片优先展示周期、价格和处理状态；移动端单列，桌面端三列，权益表允许横向滚动，避免小屏挤压。
|
||||
|
||||
## 5. 验收
|
||||
|
||||
1. 普通用户打开弹窗能看到陶泥币与会员套餐。
|
||||
2. 陶泥币购买后余额增加，流水来源为 `points_recharge`。
|
||||
3. 首充赠送只在首次陶泥币充值时生效。
|
||||
1. 普通用户打开弹窗能看到光点与会员套餐。
|
||||
2. 光点购买后余额增加，流水来源为 `points_recharge`。
|
||||
3. 首充赠送只在首次光点充值时生效。
|
||||
4. 会员购买后会员状态与到期时间立即更新。
|
||||
5. 移动端弹窗单列可滚动，桌面端接近参考图卡片网格。
|
||||
|
||||
@@ -13,9 +13,9 @@
|
||||
|
||||
## 2. 前端交互
|
||||
|
||||
### 2.1 陶泥号复制
|
||||
### 2.1 百梦号复制
|
||||
|
||||
1. 点击“我的”页陶泥号后的复制按钮后，按钮文案临时切换为 `已复制`。
|
||||
1. 点击“我的”页百梦号后的复制按钮后，按钮文案临时切换为 `已复制`。
|
||||
2. 复制失败时临时切换为 `复制失败`。
|
||||
3. 状态自动恢复为 `复制`。
|
||||
|
||||
@@ -84,7 +84,7 @@ SpacetimeDB 正式表 `user_account` 需要增加 `avatar_url: Option<String>`
|
||||
## 5. 验收
|
||||
|
||||
1. 创作页已发布作品分享按钮点击后显示 `已复制`。
|
||||
2. “我的”页陶泥号复制按钮点击后显示 `已复制`。
|
||||
2. “我的”页百梦号复制按钮点击后显示 `已复制`。
|
||||
3. “我的”页不展示 `手机号` 与 `正常` 标签。
|
||||
4. 昵称编辑成功后，资料卡与顶部账号入口同步新昵称。
|
||||
5. 昵称与头像裁剪弹窗面板不透明，不能露出底层页面内容。
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
# 我的 Tab 邀请与玩家社区首期落地方案
|
||||
|
||||
更新时间：`2026-04-29`
|
||||
更新时间：`2026-05-01`
|
||||
|
||||
## 目标
|
||||
|
||||
在现有“我的”Tab 常用功能区落地三个轻量入口：
|
||||
在现有“我的”Tab 功能入口区（常用功能）落地三个轻量入口，入口顺序固定为 `邀请好友`、`填邀请码`、`玩家社区`：
|
||||
|
||||
1. `邀请好友`：弹出面板展示当前账号绑定的邀请码。
|
||||
2. `填邀请码`：弹出面板填写邀请码，成功后邀请者与被邀请者各获得 `30` 陶泥币。
|
||||
1. `邀请好友`：弹出面板展示当前账号绑定的邀请码、邀请奖励规则和成功邀请用户列表。
|
||||
2. `填邀请码`：弹出面板填写邀请码，成功后邀请者与被邀请者各获得 `30` 光点。
|
||||
3. `玩家社区`：弹出面板展示微信群与 QQ 群正式二维码图片。
|
||||
|
||||
## 后端边界
|
||||
|
||||
- 邀请码、邀请关系与奖励发放全部存入 `server-rs/crates/spacetime-module`。
|
||||
- Axum 只做鉴权、参数转发与响应映射，不在 API 层自行计算奖励。
|
||||
- 前端只读取后端状态与调用提交接口，不做本地加陶泥币。
|
||||
- 前端只读取后端状态与调用提交接口，不做本地加光点。
|
||||
- 钱包余额继续复用 `profile_dashboard_state.wallet_balance`。
|
||||
- 奖励流水继续复用 `profile_wallet_ledger`，新增来源类型：
|
||||
- `invite_inviter_reward`
|
||||
@@ -43,7 +43,7 @@
|
||||
- 每个用户拥有一个稳定邀请码，首次进入邀请中心时自动生成。
|
||||
- 用户不能填写自己的邀请码。
|
||||
- 用户最多填写一个邀请码，成功后不可修改。
|
||||
- 被邀请者绑定成功后获得 `30` 陶泥币。
|
||||
- 被邀请者绑定成功后获得 `30` 光点。
|
||||
- 邀请者每天最多获得 `10` 次邀请奖励，超过后关系仍可绑定，被邀请者仍获得奖励，邀请者当次不再加分。
|
||||
- 每次奖励都写入钱包流水，钱包余额以后端返回为准。
|
||||
|
||||
@@ -51,7 +51,26 @@
|
||||
|
||||
### `GET /api/runtime/profile/referrals/invite-center`
|
||||
|
||||
返回当前用户的邀请码、邀请链接、今日奖励次数、剩余奖励次数、已绑定状态与奖励参数。
|
||||
返回当前用户的邀请码、邀请链接、今日奖励次数、剩余奖励次数、已绑定状态、奖励参数与成功邀请用户列表。
|
||||
|
||||
成功邀请用户列表字段：
|
||||
|
||||
```json
|
||||
{
|
||||
"invitedUsers": [
|
||||
{
|
||||
"userId": "user_001",
|
||||
"displayName": "百梦玩家",
|
||||
"avatarUrl": null,
|
||||
"boundAt": "2026-05-01T08:00:00Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- `invitedUsers` 只包含当前账号作为邀请人的关系。
|
||||
- 列表按 `boundAt` 倒序返回，最多展示最近 `20` 位成功邀请用户。
|
||||
- 昵称与头像从 `user_account` 读取；缺失昵称时前端回退展示 `玩家`。
|
||||
|
||||
### `POST /api/runtime/profile/referrals/redeem-code`
|
||||
|
||||
@@ -69,13 +88,18 @@
|
||||
|
||||
- `server-rs/crates/spacetime-module` 已新增邀请码与邀请关系表，邀请中心读取和填码绑定均通过 SpacetimeDB procedure 执行。
|
||||
- `server-rs/crates/api-server` 已挂接 `/api/runtime/profile/referrals/*` 与 `/api/profile/referrals/*` 两组路由。
|
||||
- 前端“我的”Tab 三个快捷入口均打开独立弹窗，玩家社区使用 `media/social-media-group/wechat.png` 与 `media/social-media-group/qq.png` 两张正式二维码图片。
|
||||
- 复制邀请会复制邀请码和邀请链接；填码成功后刷新个人看板陶泥币。
|
||||
- 前端“我的”Tab 三个功能入口均打开独立弹窗，玩家社区使用 `media/social-media-group/wechat.png` 与 `media/social-media-group/qq.png` 两张正式二维码图片。
|
||||
- 复制邀请会复制邀请码和邀请链接；填码成功后刷新个人看板光点。
|
||||
- 邀请好友弹窗展示 `邀请一个用户注册，双方都可获得 30 光点。每日最多获得十次邀请奖励。`，不再展示“邀请 / 已奖 / 今日”三项统计。
|
||||
- 邀请好友弹窗底部展示成功邀请用户头像和昵称列表；没有成功邀请时展示短空状态。
|
||||
- “我的”页 `邀请好友` 按钮副标题展示 `双方得30（光点icon）`；`玩家社区` 按钮副标题展示 `每日领福利`。
|
||||
- “我的”页功能入口区不展示 `常用功能` 标题和 `快捷入口` 副标题，避免首屏重复说明类文案。
|
||||
|
||||
## 前端交互
|
||||
|
||||
- 三个入口继续放在“我的”Tab 常用功能区，不新增页面。
|
||||
- `邀请好友` 弹窗展示邀请码、复制按钮、邀请链接。
|
||||
- `填邀请码` 弹窗在未绑定时展示输入框；已绑定时展示短状态。
|
||||
- 三个入口继续放在“我的”Tab 功能入口区（常用功能），不新增页面。
|
||||
- `邀请好友` 弹窗展示邀请码、复制按钮、邀请奖励规则和成功邀请用户头像昵称列表。
|
||||
- `填邀请码` 入口只在账号注册后 `24` 小时内且尚未填写过邀请码时展示；若 `auth.user.createdAt` 缺失或解析失败，前端按已超时处理并隐藏入口。
|
||||
- `填邀请码` 弹窗在未绑定时展示输入框；成功绑定后刷新邀请中心与个人看板，并隐藏常用功能里的入口。
|
||||
- `玩家社区` 弹窗展示两个紧凑二维码图片区，保留微信群与 QQ 群短标签。
|
||||
- 弹窗文案只保留必要标签和短提示，不放长规则说明。
|
||||
- 弹窗文案只保留必要标签和短提示；本次邀请奖励规则属于必要交易说明，固定展示在邀请码下方。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 密码登录入口历史落地设计
|
||||
|
||||
> 2026-04-25 更新：当前产品策略已调整为“不开放密码注册”。新用户必须通过手机号验证码注册/登录，密码登录只面向已经登录后设置过密码的手机号账号。`POST /api/auth/entry` 只接受 `phone + password`，不支持邮箱、用户名或陶泥号登录，也不承担自动建号能力。本文原有“密码自动建号”内容仅作为历史背景保留，当前落地以本更新和 [PASSWORD_LOGIN_CHANGE_RESET_DESIGN_2026-04-24.md](./PASSWORD_LOGIN_CHANGE_RESET_DESIGN_2026-04-24.md) 为准。
|
||||
> 2026-04-25 更新：当前产品策略已调整为“不开放密码注册”。新用户必须通过手机号验证码注册/登录，密码登录只面向已经登录后设置过密码的手机号账号。`POST /api/auth/entry` 只接受 `phone + password`，不支持邮箱、用户名或百梦号登录，也不承担自动建号能力。本文原有“密码自动建号”内容仅作为历史背景保留，当前落地以本更新和 [PASSWORD_LOGIN_CHANGE_RESET_DESIGN_2026-04-24.md](./PASSWORD_LOGIN_CHANGE_RESET_DESIGN_2026-04-24.md) 为准。
|
||||
>
|
||||
> 2026-04-28 更新：为开发期本地/测试服联调新增服务端环境变量 `GENARRATIVE_DEV_PASSWORD_ENTRY_AUTO_REGISTER_ENABLED`，默认 `false`。仅当该变量显式为 `true` 时，`POST /api/auth/entry` 可对未知手机号用本次密码直接创建账号并登录；默认关闭时仍严格保持未知手机号返回 `401` 的生产语义。该开关不得用于生产环境，也不新增任何前端规则说明文案。
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
|
||||
1. `api-server` 对外只暴露 `phone + password` 的最小接口。
|
||||
2. `module-auth` 只负责已存在手机号账号的密码校验。
|
||||
3. 密码入口不创建账号，不接收邮箱、用户名或陶泥号。
|
||||
3. 密码入口不创建账号，不接收邮箱、用户名或百梦号。
|
||||
4. 登录成功后与 JWT、refresh cookie 的衔接方式。
|
||||
|
||||
## 1.1 当前冻结结论
|
||||
@@ -239,7 +239,7 @@
|
||||
1. 未知手机号密码登录返回 `401`，且不创建账号。
|
||||
2. 已登录手机号账号设置密码后可用 `phone + password` 登录。
|
||||
3. 同手机号错误密码返回 `401`。
|
||||
4. 邮箱、用户名或陶泥号作为密码登录标识返回 `400`。
|
||||
4. 邮箱、用户名或百梦号作为密码登录标识返回 `400`。
|
||||
5. 登录成功时返回 access token。
|
||||
6. 登录成功时写回 refresh cookie。
|
||||
7. `GENARRATIVE_DEV_PASSWORD_ENTRY_AUTO_REGISTER_ENABLED` 默认关闭时行为不变。
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
沿用现有 `POST /api/auth/entry`：
|
||||
|
||||
1. 请求字段固定为 `phone`、`password`，前端只提交手机号。
|
||||
2. 后端只按标准手机号归一化后查找账号，不兼容邮箱、用户名、陶泥号或历史开发游客标识。
|
||||
2. 后端只按标准手机号归一化后查找账号，不兼容邮箱、用户名、百梦号或历史开发游客标识。
|
||||
3. 手机号不存在时返回 `401`，不创建账号。
|
||||
4. 手机号存在但未设置密码时返回 `401`。
|
||||
5. 校验成功后签发 access token，并写入 refresh cookie。
|
||||
|
||||
26
docs/technical/PLATFORM_HOME_FUZZY_WORK_SEARCH_2026-05-01.md
Normal file
26
docs/technical/PLATFORM_HOME_FUZZY_WORK_SEARCH_2026-05-01.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# 平台首页作品模糊搜索 2026-05-01
|
||||
|
||||
## 背景
|
||||
|
||||
首页顶部搜索框原本主要承担公开编号直达能力，适合输入 `SY / CW / BF / M3 / PZ` 编号后打开用户或作品详情。用户在浏览首页时也会按作品名称、作者昵称或作品描述回忆作品，现有搜索口径没有覆盖这些常见路径。
|
||||
|
||||
## 落地规则
|
||||
|
||||
1. 首页搜索框先在当前公开作品聚合列表中做本地模糊匹配。
|
||||
2. 匹配字段包含：
|
||||
- 作品 ID：`publicWorkCode`、`profileId`、`workId`。
|
||||
- 作品名称：`worldName`。
|
||||
- 作者昵称：`authorDisplayName`。
|
||||
- 作品描述：`summaryText`、`subtitle`。
|
||||
3. 匹配忽略大小写，允许用户输入去掉空格、连字符或下划线后的连续片段，例如 `PZEPUBLIC1` 命中 `PZ-EPUBLIC1`。
|
||||
4. 输入完整公开作品号并本地命中时，保留既有作品号直达行为。
|
||||
5. 输入模糊片段命中公开作品时，在首页直接展示搜索结果列表，点击结果打开对应作品详情。
|
||||
6. 当前公开作品列表无命中时，保留既有公开编号直达兜底，继续支持远端按作品号或百梦号查找。
|
||||
|
||||
## 验收标准
|
||||
|
||||
1. 输入作品号片段可命中对应公开作品，输入完整公开作品号仍可直达。
|
||||
2. 输入作品名称片段可命中对应公开作品。
|
||||
3. 输入作者昵称片段可命中对应公开作品。
|
||||
4. 输入作品描述片段可命中对应公开作品。
|
||||
5. 未命中本地公开作品时，原有编号搜索行为不退化。
|
||||
@@ -1,23 +1,24 @@
|
||||
# 陶泥产品命名替换落地说明
|
||||
# 百梦产品命名规范落地说明
|
||||
|
||||
## 背景
|
||||
|
||||
本轮将产品中文展示名从“叙世”调整为“陶泥”，并同步调整平台内三类对外称谓：
|
||||
平台对外中文命名统一使用以下称谓：
|
||||
|
||||
- `叙世币` 对外展示为 `陶泥币`
|
||||
- `叙世号` 对外展示为 `陶泥号`
|
||||
- `创作者` 对外展示为 `陶泥主`
|
||||
- 产品中文展示名：`百梦`
|
||||
- 平台内消费单位：`光点`
|
||||
- 公开账号标识：`百梦号`
|
||||
- 创作侧面向创作者称谓：`百梦主`
|
||||
|
||||
## 落地边界
|
||||
|
||||
1. 前端页面、弹窗、测试断言和后端返回给用户的中文错误文案统一使用新称谓。
|
||||
2. SpacetimeDB 表字段、Rust/TypeScript contract 字段、流水来源枚举、`points_*` 商品 ID、`public_user_code` 字段名继续保持不变，避免引入数据库迁移和历史数据兼容风险。
|
||||
3. 公开编号现有 `SY-XXXXXXXX` 格式本轮不迁移，只调整用户可见标签为“陶泥号”；编号格式如需改为新前缀，应另起迁移方案并同步老用户兼容策略。
|
||||
3. 公开编号现有 `SY-XXXXXXXX` 格式本轮不迁移，只调整用户可见标签为“百梦号”；编号格式如需改为新前缀，应另起迁移方案并同步老用户兼容策略。
|
||||
4. 历史日志、构建产物、第三方依赖和生成绑定不参与本轮文本替换。
|
||||
|
||||
## 验收点
|
||||
|
||||
1. 首页、登录绑定页、我的页和搜索结果不再展示旧产品名。
|
||||
2. 钱包、充值、邀请、兑换码、资产计费和拼图道具确认文案统一展示“陶泥币”。
|
||||
3. 账号公开标识相关错误和搜索空状态统一展示“陶泥号”。
|
||||
4. 创作相关可见默认称谓使用“陶泥主”。
|
||||
2. 钱包、充值、邀请、兑换码、资产计费和拼图道具确认文案统一展示“光点”。
|
||||
3. 账号公开标识相关错误和搜索空状态统一展示“百梦号”。
|
||||
4. 创作相关可见默认称谓使用“百梦主”。
|
||||
24
docs/technical/PRODUCT_NAMING_BAIMENG_RENAME_2026-05-01.md
Normal file
24
docs/technical/PRODUCT_NAMING_BAIMENG_RENAME_2026-05-01.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# 百梦产品命名替换落地说明
|
||||
|
||||
## 1. 本轮目标
|
||||
|
||||
本轮统一平台对外中文命名，当前生效称谓如下：
|
||||
|
||||
- 产品中文展示名：`百梦`
|
||||
- 平台内消费单位：`光点`
|
||||
- 公开账号标识：`百梦号`
|
||||
- 创作侧面向创作者称谓：`百梦主`
|
||||
|
||||
## 2. 落地范围
|
||||
|
||||
1. 前端网页、管理后台、HTML 标题、metadata 与品牌标识统一展示“百梦”。
|
||||
2. 钱包、充值、邀请、兑换码、资产计费、拼图道具与作者激励统一展示“光点”。
|
||||
3. 公开账号标识、搜索兜底、登录限制与错误信息统一展示“百梦号”。
|
||||
4. 创作侧面向创作者的称谓统一展示“百梦主”。
|
||||
5. 后端错误信息、默认商品文案、测试断言与文档说明同步更新。
|
||||
|
||||
## 3. 非目标
|
||||
|
||||
1. 本轮只调整对外文本，不修改数据库字段名、API 字段名、流水 source、商品 productId 或现有 `SY-XXXXXXXX` 公开编号格式。
|
||||
2. 不修改 SpacetimeDB 表结构，因此不需要新增 migration。
|
||||
3. 不引入新的前端页面或后端系统。
|
||||
@@ -49,7 +49,7 @@ admin:{管理员用户名}:{邀请码}
|
||||
## 验收标准
|
||||
|
||||
1. 未登录用户访问 `/?inviteCode=ABC123` 自动打开注册弹窗并预填 `ABC123`。
|
||||
2. 有效邀请码注册成功后，被邀请人获得陶泥币奖励，邀请关系落库。
|
||||
2. 有效邀请码注册成功后，被邀请人获得光点奖励，邀请关系落库。
|
||||
3. 无效邀请码注册成功但不绑定，并返回短提示。
|
||||
4. 管理员可添加邀请码并写入 metadata，重复提交同管理员同码更新 metadata。
|
||||
5. 管理员邀请码被使用时不产生 `admin:*` 虚拟主体的钱包流水。
|
||||
|
||||
34
docs/technical/PROFILE_NEW_USER_WALLET_REWARD_2026-05-01.md
Normal file
34
docs/technical/PROFILE_NEW_USER_WALLET_REWARD_2026-05-01.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# 新用户注册默认光点落地说明
|
||||
|
||||
## 目标
|
||||
|
||||
每个新注册用户默认获得 `10` 个光点。赠送必须由后端统一落账，前端只展示余额和流水，不在本地补发或推算。
|
||||
|
||||
## 落账规则
|
||||
|
||||
1. 默认赠送数量固定为 `10`，由 `module-runtime` 暴露常量，避免不同 crate 散落数字。
|
||||
2. 钱包余额继续使用 `profile_dashboard_state.wallet_balance`，流水继续使用 `profile_wallet_ledger`。
|
||||
3. 新增流水来源 `new_user_registration_reward`，用于区分注册赠送、邀请奖励、充值和兑换码。
|
||||
4. 注册赠送的流水 ID 固定为 `new-user-registration:{user_id}`，SpacetimeDB procedure 内做幂等保护，重复调用不重复加钱。
|
||||
5. 手机号注册、开发密码自动注册、微信新用户绑定手机号后激活，都必须调用同一个注册赠送入口。
|
||||
6. 微信 callback 阶段只会生成待绑定手机号的临时账号，不在该阶段赠送；只有绑定新手机号并激活该微信账号时才赠送。若绑定到已有手机号账号，则不补发注册赠送。
|
||||
7. 注册赠送和邀请码奖励可以叠加。先发注册赠送，再处理邀请码奖励时，新用户最终余额为 `10 + 邀请奖励`。
|
||||
|
||||
## 存档同步约束
|
||||
|
||||
`runtime_snapshot.game_state.playerCurrency` 是运行态内的旧货币字段，不允许覆盖已经存在真实钱包业务流水的账户余额。只要用户已有非 `snapshot_sync` 的钱包流水，后续存档同步只能累计游玩时长和玩过世界，不再用 `playerCurrency` 回写 `wallet_balance`。
|
||||
|
||||
这样可以避免新用户注册赠送的 `10` 个光点，在首次保存 `playerCurrency = 0` 的运行态快照时被覆盖成 `0`。
|
||||
|
||||
## 影响文件
|
||||
|
||||
1. `server-rs/crates/module-runtime/src/lib.rs`
|
||||
2. `server-rs/crates/spacetime-module/src/runtime/profile.rs`
|
||||
3. `server-rs/crates/spacetime-client/src/runtime.rs`
|
||||
4. `server-rs/crates/api-server/src/phone_auth.rs`
|
||||
5. `server-rs/crates/api-server/src/password_entry.rs`
|
||||
6. `server-rs/crates/api-server/src/wechat_auth.rs`
|
||||
7. `server-rs/crates/shared-contracts/src/runtime.rs`
|
||||
8. `packages/shared/src/contracts/runtime.ts`
|
||||
9. `src/components/rpg-entry/RpgEntryHomeView.tsx`
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
|
||||
## 1. 目标
|
||||
|
||||
本轮在现有“我的”资料与钱包 projection 上新增兑换码能力。用户兑换成功后直接增加陶泥币余额，写入 `profile_wallet_ledger`，并同步刷新 `profile_dashboard_state.wallet_balance`。
|
||||
本轮在现有“我的”资料与钱包 projection 上新增兑换码能力。用户兑换成功后直接增加光点余额，写入 `profile_wallet_ledger`，并同步刷新 `profile_dashboard_state.wallet_balance`。
|
||||
|
||||
管理侧本轮只提供后端 API，不新增管理后台页面。私有兑换码创建时支持内部 `userId` 与公开陶泥号两类输入，后端创建阶段统一解析成内部 `userId` 存储。
|
||||
管理侧本轮只提供后端 API，不新增管理后台页面。私有兑换码创建时支持内部 `userId` 与公开百梦号两类输入，后端创建阶段统一解析成内部 `userId` 存储。
|
||||
|
||||
## 2. 兑换码类型
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
| --- | --- | --- |
|
||||
| `code` | `String` | 主键，标准化后的兑换码。 |
|
||||
| `mode` | `RuntimeProfileRedeemCodeMode` | 兑换码模式。 |
|
||||
| `reward_points` | `u64` | 单次到账陶泥币。 |
|
||||
| `reward_points` | `u64` | 单次到账光点。 |
|
||||
| `max_uses` | `u32` | 公共码为单用户上限，唯一码/私有码为全局上限。 |
|
||||
| `global_used_count` | `u32` | 全局已使用次数。公共码也记录总使用次数，但不参与公共码上限判断。 |
|
||||
| `enabled` | `bool` | 是否启用。 |
|
||||
@@ -42,7 +42,7 @@
|
||||
| `usage_id` | `String` | 主键，格式 `redeem:{code}:{user_id}:{micros}:{sequence}`。 |
|
||||
| `code` | `String` | 兑换码。 |
|
||||
| `user_id` | `String` | 兑换用户。 |
|
||||
| `amount_granted` | `u64` | 到账陶泥币。 |
|
||||
| `amount_granted` | `u64` | 到账光点。 |
|
||||
| `created_at` | `Timestamp` | 兑换时间。 |
|
||||
|
||||
索引：`code`、`user_id`、`(code, user_id)`。
|
||||
@@ -121,7 +121,7 @@
|
||||
|
||||
“我的”页头像右侧入口由 `会员充值` 改为 `兑换码`。点击打开独立模态窗口，窗口内只保留输入框、兑换按钮和后端返回提示，不展示兑换规则说明。
|
||||
|
||||
成功后展示 `已到账 X 陶泥币`，并刷新 profile dashboard。失败后直接展示后端 `message`。
|
||||
成功后展示 `已到账 X 光点`，并刷新 profile dashboard。失败后直接展示后端 `message`。
|
||||
|
||||
## 8. 测试矩阵
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 1. 背景
|
||||
|
||||
当前前端展示的“陶泥号”由前端基于 `AuthUser.id` 临时拼装：
|
||||
当前前端展示的“百梦号”由前端基于 `AuthUser.id` 临时拼装：
|
||||
|
||||
- 前缀固定为 `SY-`
|
||||
- 取 `user.id` 或 `username` 去除非字母数字字符后的末 8 位
|
||||
@@ -174,7 +174,7 @@
|
||||
1. `id` 返回内部 ID 仅供当前工程内部跳转与资源读取使用，不在 UI 上直接暴露为文案
|
||||
2. 不返回手机号、登录方式、绑定状态、tokenVersion 等敏感字段
|
||||
3. 未命中返回 `404`
|
||||
4. `by-id` 仅接受内部 `user_XXXXXXXX` 这类用户 ID，用于工程内跳转、运营排查或已有资源引用，不替代公开陶泥号主搜索语义
|
||||
4. `by-id` 仅接受内部 `user_XXXXXXXX` 这类用户 ID，用于工程内跳转、运营排查或已有资源引用，不替代公开百梦号主搜索语义
|
||||
|
||||
## 5.2 广场作品公开编号搜索
|
||||
|
||||
@@ -251,7 +251,7 @@
|
||||
|
||||
## 7.1 账号展示
|
||||
|
||||
当前首页资料卡和桌面顶部都展示前端拼装陶泥号，改为：
|
||||
当前首页资料卡和桌面顶部都展示前端拼装百梦号，改为：
|
||||
|
||||
1. 直接展示 `authUi.user.publicUserCode`
|
||||
2. 复制按钮复制后端返回值
|
||||
@@ -262,7 +262,7 @@
|
||||
广场作品卡和详情页增加：
|
||||
|
||||
1. 作品号 `CW-XXXXXXXX`
|
||||
2. 作者陶泥号 `SY-XXXXXXXX`
|
||||
2. 作者百梦号 `SY-XXXXXXXX`
|
||||
|
||||
展示要求：
|
||||
|
||||
@@ -284,7 +284,7 @@
|
||||
用户搜索命中后的最小行为：
|
||||
|
||||
1. 打开独立用户搜索结果面板或对话框
|
||||
2. 展示头像字母、显示名、陶泥号
|
||||
2. 展示头像字母、显示名、百梦号
|
||||
3. 提供“查看该作者作品”入口
|
||||
|
||||
作品搜索命中后的行为：
|
||||
@@ -325,7 +325,7 @@
|
||||
|
||||
## 11. 当前落地说明
|
||||
|
||||
1. 首页陶泥号展示已优先读取后端 `publicUserCode`，原本基于 `AuthUser.id/username` 的前端拼装仅保留为兼容兜底，避免老会话未刷新时界面直接空白。
|
||||
1. 首页百梦号展示已优先读取后端 `publicUserCode`，原本基于 `AuthUser.id/username` 的前端拼装仅保留为兼容兜底，避免老会话未刷新时界面直接空白。
|
||||
2. 用户公开搜索与广场作品公开搜索均已改为调用后端匿名接口，前端只负责输入、展示与跳转，不再自行决定最终编号格式。
|
||||
3. 自定义世界发布链路已改为从认证服务读取真实 `public_user_code` 写入作品真相与广场读模型，不再从内部 `user_id` 临时反推 `SY-XXXXXXXX`。
|
||||
4. 当前作品号 `public_work_code` 仍采用基于 `profile_id` 的稳定 fallback 方案生成 `CW-XXXXXXXX`；若后续补独立计数表，需要在不改变读写接口的前提下替换生成来源。
|
||||
|
||||
@@ -201,7 +201,7 @@ Rust DTO 只承载对前端公开的 HTTP contract，不直接泄露 `module-puz
|
||||
1. 每次生成 2 张候选图。
|
||||
2. 候选图通过 `api-server` 写入 OSS，兼容展示路径统一为 `/generated-puzzle-assets/...`，禁止再落到仓库 `public/` 目录。
|
||||
3. Axum 把候选图 URL、assetId、prompt snapshot 回写到 Spacetime session draft。
|
||||
4. 陶泥主在结果页选择其中 1 张作为正式图。
|
||||
4. 百梦主在结果页选择其中 1 张作为正式图。
|
||||
|
||||
这样可以保证：
|
||||
|
||||
@@ -211,7 +211,7 @@ Rust DTO 只承载对前端公开的 HTTP contract，不直接泄露 `module-puz
|
||||
|
||||
### 6.1 发布前编辑真相补充
|
||||
|
||||
结果页允许陶泥主在发布前直接编辑：
|
||||
结果页允许百梦主在发布前直接编辑：
|
||||
|
||||
1. `关卡名`
|
||||
2. `摘要`
|
||||
@@ -449,6 +449,8 @@ finalScore = tagSimilarityScore * 0.7 + sameAuthorScore * 0.3;
|
||||
|
||||
后续反馈要求合并块边界也要圆角后，外轮廓描边补充按四个角判断：只有相邻两条外露边同时存在的真实外轮廓角才应用圆角，内部拼接角保持直角且不显示分界线。
|
||||
|
||||
2026-05-01 追加修正：合并块的圆角不能继续依赖逐格 `border-radius` 叠加。运行时应根据合并组真实占据格提取一条整体 SVG 轮廓路径，外凸角和内凹角都通过同一条路径生成二次贝塞尔圆角；合并块图片层也必须用这条整体路径裁剪，避免 L 形、阶梯形凹口处仍露出直角图片像素。
|
||||
|
||||
### 12.4 第二关后打乱规则旁路修正
|
||||
|
||||
用户反馈“从第二关开始打乱规则像是完全相同”后，检查发现 `api-server` 的本地下一关 fallback 仍使用旧版 `build_local_puzzle_board` 固定左移一格，没有复用 `module-puzzle` 的种子化初始化规则。该路径会在图库/正式推荐不可用、由 API 临时构造下一关时触发。
|
||||
|
||||
@@ -14,8 +14,8 @@
|
||||
|
||||
1. 限定时间内未完成时弹出失败面板。
|
||||
2. 失败面板提供两个选择：
|
||||
- `重新开始`：重新开启当前拼图关卡，不扣陶泥币。
|
||||
- `继续1分钟`：先弹出确认窗口，确认后消耗 `1` 陶泥币，并把当前失败关卡恢复为 `playing`，剩余时间固定为 `60000ms`。
|
||||
- `重新开始`：重新开启当前拼图关卡，不扣光点。
|
||||
- `继续1分钟`：先弹出确认窗口，确认后消耗 `1` 光点，并把当前失败关卡恢复为 `playing`，剩余时间固定为 `60000ms`。
|
||||
3. 进入拼图作品后立即写入 `profile_save_archive`，存档页显示拼图存档。
|
||||
4. 每次进入下一关后更新同一条拼图存档，使存档恢复时指向最新可继续的关卡。
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
`PuzzleRuntimePropKind` 增加 `extendTime`，沿用现有道具确认与扣费接口：
|
||||
|
||||
1. 前端只在 `runtimeStatus = failed` 时开放 `继续1分钟`。
|
||||
2. 点击后打开独立确认弹窗，文案只显示短标题和 `消耗 1 陶泥币`。
|
||||
2. 点击后打开独立确认弹窗，文案只显示短标题和 `消耗 1 光点`。
|
||||
3. 正式 run 继续走 `POST /api/runtime/puzzle/runs/:runId/props`。
|
||||
4. `api-server` 将 `extendTime` 映射为账单 `asset_kind = puzzle_prop_extend_time`。
|
||||
5. SpacetimeDB 侧只允许失败关卡续时；续时成功后：
|
||||
@@ -37,7 +37,7 @@
|
||||
- 清空暂停与冻结生效点
|
||||
- 调整 `paused_accumulated_ms`，保证从确认成功那一刻开始完整倒计时 `60` 秒
|
||||
|
||||
本地调试 run 没有真实钱包，沿用本地道具兜底：仍弹确认窗，但不扣真实陶泥币。
|
||||
本地调试 run 没有真实钱包，沿用本地道具兜底：仍弹确认窗，但不扣真实光点。
|
||||
|
||||
### 重新开始
|
||||
|
||||
@@ -91,7 +91,7 @@ SpacetimeDB 拼图运行态每次持久化 run 时同步刷新存档：
|
||||
|
||||
1. 倒计时归零后失败弹窗有 `重新开始` 和 `继续1分钟`。
|
||||
2. 点击 `继续1分钟` 后先出现扣费确认，确认成功后失败弹窗关闭并恢复 `60` 秒倒计时。
|
||||
3. 陶泥币余额不足时确认弹窗保留，并展示错误。
|
||||
3. 光点余额不足时确认弹窗保留，并展示错误。
|
||||
4. 点击 `重新开始` 后当前关卡重新打乱并重置倒计时。
|
||||
5. 进入拼图作品后，存档页出现 `worldType = PUZZLE` 的拼图存档。
|
||||
6. 通过一关后，只要后端确认同作品下一关存在，同一条存档立即更新到新关卡；没有同作品下一关时保留已完成关卡，等待玩家选择相似作品。
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
2. 新 session 的 `seedText` 允许为空；SpacetimeDB 侧用空锚点和空表单草稿初始化，不得把默认题材文案写入玩家草稿字段。
|
||||
3. 初始表单输入自动保存到 session 的 `draft_json` 与 `puzzle_work_profile` 投影。保存字段只包含 `workTitle`、`workDescription`、`pictureDescription`、可推断标签和一个 `generationStatus = idle` 的默认关卡；草稿设置阶段默认关卡名称必须为空，不得写入“第一关”“第1关”或作品名称作为默认值。参考图只保存在当前前端会话内，不落入 SpacetimeDB。
|
||||
4. 玩家在生成草稿前退出，再次从创作中心点击这条拼图草稿时，必须恢复到填表页，并回填之前自动保存的作品名称、作品描述和画面描述；只有执行 `compile_puzzle_draft` 且生成结果页草稿后，草稿入口才进入结果页。
|
||||
5. 表单自动保存走 `save_puzzle_form_draft` action，不消耗陶泥币，不生成图片，不改变 `stage = collecting_anchors`；生成草稿按钮仍单独触发 `compile_puzzle_draft` 并进入进度页。
|
||||
5. 表单自动保存走 `save_puzzle_form_draft` action，不消耗光点，不生成图片，不改变 `stage = collecting_anchors`；生成草稿按钮仍单独触发 `compile_puzzle_draft` 并进入进度页。
|
||||
6. 点击拼图入口始终创建新草稿，不复用上一次未完成 session；恢复旧草稿只通过“我的创作”中的草稿卡进入。
|
||||
7. 若 Maincloud 仍运行旧 wasm，缺少 `save_puzzle_form_draft` procedure，前端提交生成或生成失败页重试时不得继续复用空 `seedText` 的表单 session，必须用当前表单 payload 新建带真实 seed 的 session 再执行 `compile_puzzle_draft`。
|
||||
8. api-server 也要兼容旧 wasm：`save_puzzle_form_draft` 缺失时，自动保存 action 降级返回当前 session；`compile_puzzle_draft` 前置保存缺失且当前 session 为空 seed 时，创建一条带表单 seed 的替代 session 后继续编译，避免再次暴露 `No such procedure`。
|
||||
@@ -71,7 +71,7 @@
|
||||
9. `StartPuzzleRunRequest` 新增可选 `levelId`。详情页或草稿结果页单独体验某关时传入目标关卡，后端从作品/草稿的 `levels` 中选取该关卡生成运行态。
|
||||
10. `ExecutePuzzleAgentActionRequest` 必须保留 `pictureDescription` 字段。表单直达生成时，`compile_puzzle_draft` 优先用 `pictureDescription` 作为首图 prompt，再回退到旧 `promptText`；避免生成页展示的是玩家画面描述，但后端实际用作品名称或旧摘要出图。
|
||||
11. `compile_puzzle_draft` 中的图片上游失败不得映射成 `400 BAD_REQUEST`。DashScope 返回 `InvalidParameter` 或任务失败时，api-server 统一按 `502 UPSTREAM_ERROR` 暴露，并在 `details.message` 中保留“拼图图片生成失败：...”的业务原因，避免生成页只显示“请求参数不合法”。
|
||||
12. `compile_puzzle_draft` 前置陶泥币预扣失败不得映射成 `400 BAD_REQUEST`。余额不足返回 `409 CONFLICT`，SpacetimeDB procedure 不可用、绑定不匹配、钱包服务异常等统一按 `502 UPSTREAM_ERROR` 暴露，并在 `details.message` 中保留真实钱包错误。
|
||||
12. `compile_puzzle_draft` 前置光点预扣失败不得映射成 `400 BAD_REQUEST`。余额不足返回 `409 CONFLICT`，SpacetimeDB procedure 不可用、绑定不匹配、钱包服务异常等统一按 `502 UPSTREAM_ERROR` 暴露，并在 `details.message` 中保留真实钱包错误。
|
||||
13. 生成拼图作品草稿动作涉及的表单 seed prompt 与首图 prompt 来源选择统一收口在 `server-rs/crates/api-server/src/prompt/puzzle/draft.rs`；`puzzle.rs` 只负责调用 SpacetimeDB、计费、图片服务和持久化，不再直接拼草稿 prompt 文本。
|
||||
|
||||
## 结果页
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
5. DashScope 上游失败时，api-server 必须在错误 details 中保留业务 message、`upstreamStatus` 和截断后的 `rawExcerpt`，日志也要记录同样的摘要，避免生成进度页只能看到通用 HTTP 文案。
|
||||
6. 图片生成仍由 `api-server` 执行。SpacetimeDB reducer 不做网络 I/O。
|
||||
7. 拼图文生图请求体按 DashScope Wan text2image 协议收口：`input` 放 `prompt` 与非空 `negative_prompt`，`parameters` 放 `n`、`size`、`prompt_extend`、`watermark`。不要在 `input` 与 `parameters` 里重复写入反向提示词，否则上游容易返回参数非法。
|
||||
8. 陶泥币预扣失败属于钱包或 SpacetimeDB 服务链路错误，不得映射成 `400 BAD_REQUEST`。除余额不足返回 `409 CONFLICT` 外，其余预扣异常统一按上游/服务错误暴露，避免生成页误提示“请求参数不合法”。
|
||||
8. 光点预扣失败属于钱包或 SpacetimeDB 服务链路错误，不得映射成 `400 BAD_REQUEST`。除余额不足返回 `409 CONFLICT` 外，其余预扣异常统一按上游/服务错误暴露，避免生成页误提示“请求参数不合法”。
|
||||
|
||||
### 2. 前端规则裁决
|
||||
|
||||
@@ -42,6 +42,8 @@
|
||||
1. 基础单块和合并块都必须使用圆角，不能只让合并后的外轮廓有圆角。
|
||||
2. 基础单块的图片层必须跟随单块容器裁剪，避免图片直角从圆角边框里露出。
|
||||
3. 合并块继续按实际拼块外轮廓描边，内部相邻边不额外显示边框。
|
||||
4. 合并块轮廓必须按真实占据格生成整体路径，再统一处理外凸角与内凹角圆角；不能只依赖单个格子的 `border-radius` 拼接，否则 L 形、阶梯形合并块的凹入角会露出直角。
|
||||
5. 合并块图片层必须使用同一条整体轮廓做裁剪，确保凹入角的图片像素也跟随圆角被裁掉。
|
||||
|
||||
## 验收
|
||||
|
||||
@@ -51,5 +53,5 @@
|
||||
4. DashScope 返回参数错误、任务失败或非 2xx 时，前端错误优先展示后端 details.message，后端日志能看到 `upstreamStatus` 和 `rawExcerpt`。
|
||||
5. 正式拼图 run 中拖动拼块后，前端立即更新棋盘、合并块和通关状态，不再等待 `/drag`。
|
||||
6. 移动端运行时棋盘为正方形，并尽量贴近屏幕两侧边缘。
|
||||
7. 基础单块和合并块都能看到圆角，且基础单块图片不会溢出圆角裁剪。
|
||||
7. 基础单块和合并块都能看到圆角，合并块的外凸角与内凹角都不是直角，且图片不会溢出圆角裁剪。
|
||||
8. 下一关、道具、排行榜仍走现有后端链路，不把外部 I/O 或扣费逻辑塞回前端。
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
拼图结果页此前存在两个串联问题：
|
||||
|
||||
1. 陶泥主在结果页修改 `关卡名`、新增标签、删除标签，只会改前端本地 `editState`，不会立即写回拼图作品 profile。
|
||||
1. 百梦主在结果页修改 `关卡名`、新增标签、删除标签，只会改前端本地 `editState`，不会立即写回拼图作品 profile。
|
||||
2. 发布弹窗同时混用了旧 session 内的 `publishReady` 与前端本地编辑态，导致标签已经在界面里补够，但发布校验仍然盯着旧草稿里的标签数量，用户无法通过发布检验。
|
||||
|
||||
这会直接破坏拼图创作主链的可用性：用户明明已经在结果页补齐正式标签，却因为没有自动保存、也没有按当前编辑态重算门槛而卡在发布前。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
1. 不同难度有明确倒计时，超时即失败。
|
||||
2. 底部固定 3 个轻量道具：提示、查看原图、冻结时间。
|
||||
3. 道具使用必须经过确认弹窗并消耗 `1` 陶泥币，确认弹窗期间暂停关卡计时。
|
||||
3. 道具使用必须经过确认弹窗并消耗 `1` 光点，确认弹窗期间暂停关卡计时。
|
||||
|
||||
本设计只处理拼图运行时，不改拼图创作链、发布链和广场推荐链。
|
||||
|
||||
@@ -95,7 +95,7 @@ remainingMs = max(0, timeLimitMs - effectiveElapsedMs)
|
||||
|
||||
## 计费规则
|
||||
|
||||
每次确认使用道具消耗 `1` 陶泥币。
|
||||
每次确认使用道具消耗 `1` 光点。
|
||||
|
||||
正式后端运行态复用现有资产操作钱包预扣链路，新增道具 `asset_kind`：
|
||||
|
||||
|
||||
@@ -6,18 +6,18 @@
|
||||
|
||||
1. 拼图草稿页“新增关卡”按钮下方显示一行小字：“获得更多积分激励”。
|
||||
2. 创作页的已发布拼图作品卡展示当前作品的积分激励总数、待领取积分数和领取按钮。
|
||||
3. 用户在他人已发布拼图作品中消耗陶泥币时，作品作者获得消耗陶泥币数量的一半作为积分激励。
|
||||
4. 作者领取时只能领取整数个陶泥币，待领取值向下取整；未满 1 个陶泥币的半数余额继续保留。
|
||||
3. 用户在他人已发布拼图作品中消耗光点时，作品作者获得消耗光点数量的一半作为积分激励。
|
||||
4. 作者领取时只能领取整数个光点，待领取值向下取整；未满 1 个光点的半数余额继续保留。
|
||||
|
||||
## 2. 数据模型
|
||||
|
||||
拼图作品激励归属到 `puzzle_work_profile`。
|
||||
|
||||
1. `point_incentive_total_half_points: u64`
|
||||
- 记录该作品累计获得的激励，单位为“半个陶泥币”。
|
||||
- 每消耗 `N` 个陶泥币，增加 `N` 个 half points；当前拼图道具每次消耗 1 个陶泥币，因此每次为作者增加 0.5。
|
||||
- 记录该作品累计获得的激励，单位为“半个光点”。
|
||||
- 每消耗 `N` 个光点，增加 `N` 个 half points；当前拼图道具每次消耗 1 个光点，因此每次为作者增加 0.5。
|
||||
2. `point_incentive_claimed_points: u64`
|
||||
- 记录作者已领取的整数陶泥币数量。
|
||||
- 记录作者已领取的整数光点数量。
|
||||
3. 前端展示：
|
||||
- 激励总数 = `pointIncentiveTotalHalfPoints / 2`，允许展示一位小数。
|
||||
- 待领取积分 = `floor(pointIncentiveTotalHalfPoints / 2) - pointIncentiveClaimedPoints`。
|
||||
@@ -33,7 +33,7 @@
|
||||
- 只允许作品作者领取。
|
||||
- 计算可领取整数 `claimable = total_half_points / 2 - claimed_points`。
|
||||
- `claimable <= 0` 时拒绝领取。
|
||||
- 同一事务内更新作品 `claimed_points += claimable`，并向作者钱包增加 `claimable` 陶泥币，钱包流水来源使用 `puzzle_author_incentive_claim`。
|
||||
- 同一事务内更新作品 `claimed_points += claimable`，并向作者钱包增加 `claimable` 光点，钱包流水来源使用 `puzzle_author_incentive_claim`。
|
||||
|
||||
## 4. API 与前端
|
||||
|
||||
@@ -55,6 +55,6 @@
|
||||
2. 已发布拼图作品卡展示“积分激励总数”和“待领取”两个数值。
|
||||
3. 待领取积分为 0 时领取按钮禁用。
|
||||
4. 非作者游玩他人拼图并使用付费道具后，该作品累计 half points 增加。
|
||||
5. 作者领取后钱包增加向下取整后的整数陶泥币，作品待领取数归零或保留不足 1 的小数余额。
|
||||
5. 作者领取后钱包增加向下取整后的整数光点，作品待领取数归零或保留不足 1 的小数余额。
|
||||
6. 领取成功后顶部/我的页钱包余额随个人看板刷新。
|
||||
7. 修改后运行编码检查、SpacetimeDB 绑定生成、Rust 检查和必要前端测试。
|
||||
|
||||
@@ -4,6 +4,7 @@
|
||||
|
||||
## 文档列表
|
||||
|
||||
- [PRODUCT_NAMING_BAIMENG_RENAME_2026-05-01.md](./PRODUCT_NAMING_BAIMENG_RENAME_2026-05-01.md)：冻结当前对外中文命名，产品展示名统一为“百梦”，消费单位为“光点”，公开账号标识为“百梦号”，创作侧称谓为“百梦主”。
|
||||
- [SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md](./SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md)：冻结 SpacetimeDB 表结构变更约束、自动迁移可接受范围、冲突后的系统行为，以及保留旧数据的增量迁移流程；凡涉及 `spacetime publish`、表字段调整或 `migration.rs` 对齐时优先参考。
|
||||
- [SPACETIMEDB_LOCAL_REPLICA_IDENTITY_MISMATCH_FIX_2026-04-30.md](./SPACETIMEDB_LOCAL_REPLICA_IDENTITY_MISMATCH_FIX_2026-04-30.md)：记录本地 standalone 启动时报 `mismatched database identity` 的 root-dir/replica 数据残留根因、备份重建步骤和脚本诊断口径。
|
||||
- [LLM_MODEL_ROUTING_RPG_AND_CREATION_2026-04-30.md](./LLM_MODEL_ROUTING_RPG_AND_CREATION_2026-04-30.md)：冻结 RPG 运行时剧情推理使用 `doubao-seed-character-251128` 的 `/chat/completions`，以及所有模板创作大模型推理使用 `deepseek-v3-2-251201` 的 `/responses`。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 背景
|
||||
|
||||
世界创作结果页已经提供“作品测试”入口，但测试运行时此前缺少与“幕预览”一致的显式退出按钮。陶泥主进入测试后只能依赖浏览器返回、刷新或其他间接链路离开，不符合独立运行时面板的交互语义。
|
||||
世界创作结果页已经提供“作品测试”入口，但测试运行时此前缺少与“幕预览”一致的显式退出按钮。百梦主进入测试后只能依赖浏览器返回、刷新或其他间接链路离开，不符合独立运行时面板的交互语义。
|
||||
|
||||
## 本次约束
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 背景
|
||||
|
||||
幕预览和测试作品用于陶泥主检查玩法表现，不能被当作玩家正式游玩记录。若这类运行时复用正式 RPG 壳、story action 或 snapshot 接口，必须在进入个人存档页、游玩统计、作品游玩历史前被过滤。
|
||||
幕预览和测试作品用于百梦主检查玩法表现，不能被当作玩家正式游玩记录。若这类运行时复用正式 RPG 壳、story action 或 snapshot 接口，必须在进入个人存档页、游玩统计、作品游玩历史前被过滤。
|
||||
|
||||
## 落地约束
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Rust API Server 路由索引（2026-04-23）
|
||||
|
||||
更新时间：`2026-04-30`
|
||||
更新时间：`2026-05-01`
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
## 2. 当前统计
|
||||
|
||||
当前 Rust `api-server` 从 `app.rs` 可抽取到 `102` 条路由：
|
||||
当前 Rust `api-server` 从 `app.rs` 可抽取到 `116` 条路由：
|
||||
|
||||
1. 管理后台 API：`6` 条。
|
||||
2. 内部鉴权调试接口：`2` 条。
|
||||
@@ -18,11 +18,12 @@
|
||||
4. assets / OSS 接口：`15` 条。
|
||||
5. auth 接口：`12` 条。
|
||||
6. custom world / agent 接口：`23` 条。
|
||||
7. llm proxy 接口：`1` 条。
|
||||
8. profile / runtime profile 接口：`12` 条。
|
||||
9. runtime story / story gameplay 接口：`15` 条。
|
||||
10. legacy generated 静态路径兼容：`6` 条。
|
||||
11. health check：`1` 条。
|
||||
7. match3d creation / runtime 接口：`14` 条。
|
||||
8. llm proxy 接口：`1` 条。
|
||||
9. profile / runtime profile 接口：`12` 条。
|
||||
10. runtime story / story gameplay 接口：`15` 条。
|
||||
11. legacy generated 静态路径兼容：`6` 条。
|
||||
12. health check：`1` 条。
|
||||
|
||||
## 3. 路由清单
|
||||
|
||||
@@ -117,7 +118,24 @@
|
||||
|
||||
1. `POST /api/llm/chat/completions`
|
||||
|
||||
### 3.8 Profile / Runtime Profile
|
||||
### 3.8 Match3D Creation / Runtime
|
||||
|
||||
1. `POST /api/creation/match3d/sessions`
|
||||
2. `GET /api/creation/match3d/sessions/{session_id}`
|
||||
3. `POST /api/creation/match3d/sessions/{session_id}/messages`
|
||||
4. `POST /api/creation/match3d/sessions/{session_id}/messages/stream`
|
||||
5. `POST /api/creation/match3d/sessions/{session_id}/actions`
|
||||
6. `POST /api/creation/match3d/sessions/{session_id}/compile`
|
||||
7. `GET /api/creation/match3d/works`
|
||||
8. `GET / PATCH / PUT / DELETE /api/creation/match3d/works/{profile_id}`
|
||||
9. `POST /api/creation/match3d/works/{profile_id}/publish`
|
||||
10. `GET /api/runtime/match3d/gallery`
|
||||
11. `POST /api/runtime/match3d/works/{profile_id}/runs`
|
||||
12. `GET /api/runtime/match3d/runs/{run_id}`
|
||||
13. `POST /api/runtime/match3d/runs/{run_id}/click`
|
||||
14. `POST /api/runtime/match3d/runs/{run_id}/stop / restart / time-up`
|
||||
|
||||
### 3.9 Profile / Runtime Profile
|
||||
|
||||
1. `GET /api/profile/dashboard`
|
||||
2. `GET /api/runtime/profile/dashboard`
|
||||
@@ -132,7 +150,7 @@
|
||||
11. `POST /api/profile/save-archives/{world_key}`
|
||||
12. `POST /api/runtime/profile/save-archives/{world_key}`
|
||||
|
||||
### 3.9 Runtime Story / Gameplay
|
||||
### 3.10 Runtime Story / Gameplay
|
||||
|
||||
1. `POST /api/runtime/save/snapshot`
|
||||
2. `GET /api/runtime/settings`
|
||||
@@ -150,7 +168,7 @@
|
||||
14. `POST /api/story/npc/battle`
|
||||
15. `GET /api/runtime/sessions/{runtime_session_id}/inventory`
|
||||
|
||||
### 3.10 Legacy Generated 路径
|
||||
### 3.11 Legacy Generated 路径
|
||||
|
||||
1. `GET /generated-character-drafts/{*path}`
|
||||
2. `GET /generated-characters/{*path}`
|
||||
@@ -159,7 +177,7 @@
|
||||
5. `GET /generated-custom-world-covers/{*path}`
|
||||
6. `GET /generated-qwen-sprites/{*path}`
|
||||
|
||||
### 3.11 Health
|
||||
### 3.12 Health
|
||||
|
||||
1. `GET /healthz`
|
||||
|
||||
|
||||
@@ -45,7 +45,8 @@ Vite 代理覆盖范围：
|
||||
|
||||
1. `/api/runtime/*` 会在 Rust 栈下代理到 Rust `api-server`，覆盖旧 runtime story 兼容接口。
|
||||
2. `/api/story/*` 会在 Rust 栈下代理到 Rust `api-server`，覆盖新 story session、battle 查询与 NPC battle 切片接口。
|
||||
3. 其他 `/api/auth`、`/api/assets`、`/api/custom-world`、`/api/llm` 等路径仍由同一个 `GENARRATIVE_RUNTIME_SERVER_TARGET` 控制，便于 M7 按服务能力逐项做对比 smoke。
|
||||
3. `/api/creation/*` 会在 Rust 栈下代理到 Rust `api-server`，覆盖 Match3D 等创作域接口，避免开发态请求落回 Vite SPA HTML。
|
||||
4. 其他 `/api/auth`、`/api/assets`、`/api/custom-world`、`/api/llm` 等路径仍由同一个 `GENARRATIVE_RUNTIME_SERVER_TARGET` 控制，便于 M7 按服务能力逐项做对比 smoke。
|
||||
|
||||
安全边界：
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
1. 草稿层可以承载 `scene chapter / scene act`
|
||||
2. 后端可以把 `scene_chapter` 编译成正式蓝图
|
||||
3. 陶泥主可以在现有场景编辑弹层里看到并编辑多幕配置
|
||||
3. 百梦主可以在现有场景编辑弹层里看到并编辑多幕配置
|
||||
4. 编辑后的幕信息可以正确写回 `sceneChapterBlueprints`
|
||||
5. 运行时共享层先具备读取幕背景、主角色、相遇 NPC 池的基础能力
|
||||
6. 当前幕主角色的负好感 `5` 轮聊天限制先形成首个可运行闭环
|
||||
@@ -60,7 +60,7 @@
|
||||
|
||||
前端已完成第一批接入：
|
||||
|
||||
1. `scene_chapter` 不再作为独立 Tab / 独立卡片暴露给陶泥主
|
||||
1. `scene_chapter` 不再作为独立 Tab / 独立卡片暴露给百梦主
|
||||
2. 多幕配置已内嵌到 `CustomWorldEntityEditorModal.tsx` 的 `LandmarkEditor`
|
||||
3. 单幕编辑已从文本表单切成“背景大图预览 + 3 个角色槽位”的轻量交互
|
||||
4. “幕标题 / 幕摘要 / 幕目标 / 过渡钩子”已从场景手工编辑区移除，继续留在草稿生成与编译层
|
||||
@@ -88,7 +88,7 @@
|
||||
7. 幕预览运行时已补 custom world NPC 的视觉兜底链路，优先使用 `visual / imageSrc` 渲染，避免角色形象或动画空白
|
||||
8. 当前幕小预览已调整为左侧玩家、右侧敌对/相遇角色的构图，NPC 站位采用一前两后
|
||||
前排主角色与玩家角色保持同一 y 轴；后排两个角色改为同一列、x 轴对齐并上下分布，且后排整体 y 轴中点与前排主角色一致
|
||||
9. 新增幕默认只带 1 个主角色，后续槽位由陶泥主按需补充
|
||||
9. 新增幕默认只带 1 个主角色，后续槽位由百梦主按需补充
|
||||
10. 小预览里的名字已移动到角色头顶，角色渲染不再带方形底板，避免遮挡场景背景
|
||||
11. 幕预览复用真实游戏壳时隐藏左上角角色等级徽标，退出入口固定在上方画面区域底部居中，并使用“结束预览”作为操作文案
|
||||
12. 创作侧场景列表封面、多幕配置卡片、配置背景弹层统一读取同一张场景显示图；在任一幕保存背景时同步回全部幕背景字段和场景兼容图，避免同一场景在不同层级出现不同预览图
|
||||
|
||||
@@ -409,7 +409,7 @@ Access-Control-Allow-Credentials: true
|
||||
|
||||
职责：
|
||||
|
||||
- 面向陶泥主、运营、内部编辑器
|
||||
- 面向百梦主、运营、内部编辑器
|
||||
- 必须鉴权
|
||||
- 必须审计
|
||||
- 不建议对公网完全开放
|
||||
@@ -469,7 +469,7 @@ flowchart TD
|
||||
当出现这些需求时，再进入下一阶段：
|
||||
|
||||
- 多人同时在线
|
||||
- 多陶泥主协作
|
||||
- 多百梦主协作
|
||||
- 图片/视频生成任务变多
|
||||
- 需要账号体系、存档、云同步
|
||||
- 需要审计和版本回滚
|
||||
|
||||
@@ -206,7 +206,7 @@
|
||||
|
||||
1. 密码登录仍由 `user_account.password_hash` 承担
|
||||
2. 本轮不引入 `password` provider identity
|
||||
3. 密码登录只接受已绑定手机号的账号，不支持邮箱、用户名或陶泥号作为登录身份
|
||||
3. 密码登录只接受已绑定手机号的账号，不支持邮箱、用户名或百梦号作为登录身份
|
||||
4. 密码登录不创建账号，新账号只由手机号验证码登录创建
|
||||
|
||||
### 9.2 `POST /api/auth/phone/login`
|
||||
|
||||
@@ -63,7 +63,7 @@ SELECT * FROM auth_store_snapshot WHERE snapshot_id = 'default';
|
||||
|
||||
### `user_account`
|
||||
|
||||
- 作用：用户账号主表，保存用户名、公开陶泥号、手机号掩码、登录方式、密码登录开关和 token 版本。
|
||||
- 作用：用户账号主表，保存用户名、公开百梦号、手机号掩码、登录方式、密码登录开关和 token 版本。
|
||||
- 结构：`user_id PK: String`, `public_user_code: String`, `username: String`, `display_name: String`, `avatar_url: Option<String>`, `phone_number_masked: Option<String>`, `phone_number_e164: Option<String>`, `login_method: String`, `binding_status: String`, `wechat_bound: bool`, `password_hash: Option<String>`, `password_login_enabled: bool`, `token_version: u64`。
|
||||
- 索引：`username`, `public_user_code`。
|
||||
|
||||
@@ -134,6 +134,7 @@ SELECT * FROM user_browse_history WHERE user_id = '<user_id>' AND owner_user_id
|
||||
- 作用：个人主页聚合状态，保存钱包余额和总游玩时长。
|
||||
- 结构：`user_id PK: String`, `wallet_balance: u64`, `total_play_time_ms: u64`, `created_at: Timestamp`, `updated_at: Timestamp`。
|
||||
- 索引：主键 `user_id`。
|
||||
- 新用户注册成功后默认写入 `10` 个光点，余额仍以后端钱包 projection 为准。
|
||||
|
||||
```sql
|
||||
SELECT * FROM profile_dashboard_state WHERE user_id = '<user_id>';
|
||||
@@ -144,6 +145,7 @@ SELECT * FROM profile_dashboard_state WHERE user_id = '<user_id>';
|
||||
- 作用：钱包流水账，记录金币/货币变更来源与变更后的余额。
|
||||
- 结构：`wallet_ledger_id PK: String`, `user_id: String`, `amount_delta: i64`, `balance_after: u64`, `source_type: RuntimeProfileWalletLedgerSourceType`, `created_at: Timestamp`。
|
||||
- 索引：`user_id`, `(user_id, created_at)`。
|
||||
- 注册赠送流水来源为 `new_user_registration_reward`，流水 ID 固定为 `new-user-registration:{user_id}`，用于保证重复调用不重复发放。
|
||||
|
||||
```sql
|
||||
SELECT * FROM profile_wallet_ledger WHERE user_id = '<user_id>';
|
||||
@@ -152,7 +154,7 @@ SELECT * FROM profile_wallet_ledger WHERE user_id = '<user_id>' ORDER BY created
|
||||
|
||||
### `profile_redeem_code`
|
||||
|
||||
- 作用：运营发放的陶泥币兑换码，支持公共码、唯一码和私有码。
|
||||
- 作用：运营发放的光点兑换码，支持公共码、唯一码和私有码。
|
||||
- 结构：`code PK: String`, `mode: RuntimeProfileRedeemCodeMode`, `reward_points: u64`, `max_uses: u32`, `global_used_count: u32`, `enabled: bool`, `allowed_user_ids: Vec<String>`, `created_by: String`, `created_at: Timestamp`, `updated_at: Timestamp`。
|
||||
- 索引：主键 `code`。
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@
|
||||
- 发布
|
||||
3. 完整复制外部 TXT 模式的运行机制：
|
||||
- 玩家游玩会话
|
||||
- 陶泥主测试/读档会话
|
||||
- 百梦主测试/读档会话
|
||||
- 流式动作执行
|
||||
- 文本模式显示
|
||||
- 历史记录
|
||||
@@ -99,7 +99,7 @@
|
||||
- 属性面板
|
||||
5. 双会话机制：
|
||||
- 玩家游玩会话
|
||||
- 陶泥主测试/读档会话
|
||||
- 百梦主测试/读档会话
|
||||
6. 流式动作接口与事件协议：
|
||||
- `start`
|
||||
- `raw_text`
|
||||
@@ -551,7 +551,7 @@ TXT 模式后续必须完整落地双会话机制：
|
||||
1. 玩家游玩会话
|
||||
- 对应外部 `POST /api/optical/games/session/create`
|
||||
- 用于正式游玩
|
||||
2. 陶泥主测试/读档会话
|
||||
2. 百梦主测试/读档会话
|
||||
- 对应外部 `POST /api/visual/session/create`
|
||||
- 用于测试体验与加载指定存档
|
||||
|
||||
|
||||
Reference in New Issue
Block a user