1
This commit is contained in:
@@ -0,0 +1,19 @@
|
||||
# 平台首页 Banner 图尺寸修复记录
|
||||
|
||||
更新时间：`2026-04-25`
|
||||
|
||||
## 问题
|
||||
|
||||
首页 Hero / banner 使用作品封面作为背景图。全局 `.platform-surface > *` 会把所有直接子节点重新设为 `position: relative`，导致带有 Tailwind `absolute` 类的背景图和遮罩被覆盖，图片重新进入普通文档流后可能撑高首页，影响首屏布局。
|
||||
|
||||
## 落地
|
||||
|
||||
- 修改 `src/index.css`，将 `.platform-surface > *` 收敛为 `.platform-surface > :not(.absolute)`。
|
||||
- 保留普通内容层的 `z-index: 1`，让文字、按钮仍稳定压在背景之上。
|
||||
- 让 banner 背景图继续使用绝对定位和 `object-cover`，只在固定容器内裁切显示，不参与首页高度计算。
|
||||
|
||||
## 经验
|
||||
|
||||
- 首页、结果页、详情页的背景图都必须由固定尺寸容器承载，图片本身不要参与布局流。
|
||||
- 给通用容器写层级规则时，不能无差别覆盖 `.absolute` 节点，否则会破坏所有“背景图 + 遮罩 + 内容”的结构。
|
||||
- 后续若新增平台 Hero，优先沿用 `platform-surface--hero`，并确认背景图节点仍是 `absolute inset-0 h-full w-full object-cover`。
|
||||
@@ -250,13 +250,27 @@ node scripts/vite-cli.mjs --port=3000 --host=0.0.0.0
|
||||
|
||||
这类项目里，后者几乎一定导致返工。
|
||||
|
||||
## 13. 一句话总结
|
||||
## 13. 后端修改后的重启与测试
|
||||
|
||||
后端代码更新后统一执行：
|
||||
|
||||
```bash
|
||||
npm run api-server:maincloud
|
||||
```
|
||||
|
||||
执行要求：
|
||||
|
||||
- 该命令是后端更新后的默认重启入口，不再使用此前的后端重启命令。
|
||||
- 重启后必须继续执行与本次后端改动对应的自动测试；涉及 Rust workspace 时优先跑 `server-rs` 下的检查或测试脚本。
|
||||
- 若本次改动涉及 SpacetimeDB 发布、绑定生成或 Maincloud 联调，按 `spacetimedb-cli` 经验执行，并在验证记录中写清楚实际命令与结果。
|
||||
|
||||
## 14. 一句话总结
|
||||
|
||||
这个项目最重要的经验不是“做了多少页面和功能”，而是：
|
||||
|
||||
**必须把 AI 文本生成、本地规则、动画演出、场景状态、编辑器工具这几套系统严格分层，再通过 function 和统一状态流把它们重新接起来。**
|
||||
|
||||
## 14. 相关文档
|
||||
## 15. 相关文档
|
||||
|
||||
如需继续细看已有沉淀，可结合以下文档一起阅读：
|
||||
|
||||
|
||||
@@ -27,3 +27,5 @@
|
||||
## 近期专项记录
|
||||
|
||||
- [RPG_DRAFT_IMAGE_PARALLEL_GENERATION_2026-04-24.md](./RPG_DRAFT_IMAGE_PARALLEL_GENERATION_2026-04-24.md)：记录 RPG 底稿阶段角色主形象与场景背景图并行生成约束。
|
||||
- [PLATFORM_HOME_BANNER_IMAGE_SIZE_FIX_2026-04-25.md](./PLATFORM_HOME_BANNER_IMAGE_SIZE_FIX_2026-04-25.md)：记录首页 banner 背景图不能进入普通布局流的修复经验。
|
||||
- [RPG_PUBLISH_GALLERY_REFRESH_FIX_2026-04-25.md](./RPG_PUBLISH_GALLERY_REFRESH_FIX_2026-04-25.md)：记录 RPG 发布后首页 / 分类页公开作品列表刷新链路。
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
# RPG 发布作品广场刷新修复 2026-04-25
|
||||
|
||||
## 背景
|
||||
|
||||
已发布 RPG 作品会进入 `custom_world_profile`，并由 SpacetimeDB 模块同步到公开读模型 `custom_world_gallery_entry`。平台首页和分类页不直接读取“我的作品”，而是共同消费 `/api/runtime/custom-world-gallery` 返回的公开作品列表。
|
||||
|
||||
本次问题表现为：结果页显示发布完成后，作品没有立即出现在平台首页和分类页。
|
||||
|
||||
## 修复原则
|
||||
|
||||
1. `publish_world` 必须写入真实作者公开信息。
|
||||
- Axum 层在执行 `publish_world` 前补充 `authorPublicUserCode` 与 `authorDisplayName`。
|
||||
- SpacetimeDB 模块发布时优先使用 payload 中的作者公开信息，再退回历史兜底。
|
||||
|
||||
2. 发布完成后必须刷新公开广场列表。
|
||||
- 前端 `executePublishWorld` 等待发布 operation 完成后，同时刷新 `refreshPublishedGallery()` 与 `refreshCustomWorldWorks()`。
|
||||
- 首页和分类页都复用 `publishedGalleryEntries`，因此刷新 gallery 后两个页面会同步看到新发布作品。
|
||||
|
||||
## 多玩法公开列表补充
|
||||
|
||||
- 平台首页 / 分类页不是只展示 RPG 作品，也需要展示已经发布到公开接口的 Puzzle 作品。
|
||||
- Puzzle 已有 `/api/runtime/puzzle/gallery` 公开接口；平台入口额外读取该接口，并把 `PuzzleWorkSummary` 映射为首页卡片模型。
|
||||
- 首页 / 分类页按 `rpg:{ownerUserId}:{profileId}` 与 `puzzle:{ownerUserId}:{profileId}` 去重后按发布时间排序。
|
||||
- 点击 RPG 卡片仍进入 RPG 公开详情；点击 Puzzle 卡片进入现有 Puzzle 广场详情，不复用 RPG 详情链路。
|
||||
|
||||
3. 历史已发布作品必须能自动补齐 gallery 投影。
|
||||
- 公开列表读取 `list_custom_world_gallery_entries` 前，会扫描 `custom_world_profile` 中已发布且未删除的 profile。
|
||||
- 若已发布 profile 缺少 `custom_world_gallery_entry`，或缺少公开作品码 / 作者叙世号，会先补齐公开字段并同步 gallery 投影。
|
||||
- 这样旧版本发布成功但未落入广场读模型的作品，在下一次首页 / 分类页读取公开列表时会自动出现。
|
||||
|
||||
## 经验
|
||||
|
||||
- 作品发布链不能只看“我的创作”列表，必须同时检查公开读模型。
|
||||
- 分类页的数据不是独立接口，修首页公开列表通常也会影响分类页。
|
||||
- Agent 发布链和普通 library profile 发布链要共享公开作者字段语义，避免同一个 gallery card 在不同发布入口下字段不一致。
|
||||
- 已发布 profile 与 gallery 投影不是同一张表，线上修复时要考虑历史数据补投影，不能只修新增发布路径。
|
||||
Reference in New Issue
Block a user