合并最新master的历史表清理与聊天优化

同步master历史表清理、生成绑定和客户端优化，保留埋点实现。

docs/project-memory/shared-memory/decision-log.md

@@ -828,6 +828,15 @@ Godot 编辑器操控复用既有 AGC 插件宿主、EditorAdapter、Runner 和
 - 验证方式：运行评论弹层恢复竞态回归、完整 `appSurface.test.ts`，并执行类型、编码和 diff 检查。
 - 关联文档：`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md`、`apps/ai-game-creator-shell/src/features/project-workspace/GddApprovalCard.tsx`。
 
+## 2026-09-22 旧创作模板历史表从 schema 与生成绑定中删除
+
+- 背景：旧创作模板的 63 张历史玩法表已经完成业务代码退役；release 在 2026-09-22 apply 前仍有 26 张表、5922 行历史数据。维护窗口内先完成可恢复备份，再执行固定清单清空，继续保留 table 定义、迁移白名单、旧行兼容分支和生成绑定会让当前 schema、客户端类型和迁移合同长期停留在退役状态。
+- 决策：从 `spacetime-module` 可达源码删除旧 gameplay、自定义世界、Puzzle / Puzzle Clear、Bark Battle、Match3D、Jump Hop、Wooden Fish、Square Hole、Visual Novel 与 Big Fish 的 63 张表定义及专属类型；同步删除只服务这些表的 `clear_retired_database_tables` procedure、固定清单、migration 导入导出项和旧行归一化分支，并重新生成 `spacetime-client` bindings。`runtime_setting`、`runtime_snapshot`、`user_browse_history`、`creation_entry_config` 等现役表和通用迁移能力保持不变。
+- 门禁处理：SpacetimeDB schema guard 只对本轮 63 个已确认 accessor 的从基线删除放行，其他表删除/改名以及字段级破坏性变更仍失败；该一次性白名单在删除结果进入后续主线基线后移除。生产发布仍必须单独完成冷备份、客户端兼容性和运行态确认，禁止用 SQL `DROP TABLE`、`--delete-data=always` 或系统表写入代替受控发布。
+- 影响范围：`server-rs/crates/spacetime-module/src/{active.rs,migration.rs}`、旧表专属 module/legacy schema 文件、`server-rs/crates/spacetime-client/src/module_bindings*`、schema guard 及后端数据契约。
+- 生产数据与发布闭环：`genarrative-prod` 在维护态、API/controller/worker 已停止时，以已授权 migration operator 执行 `clear_retired_database_tables`；apply 返回 63 张表且每张 `cleared_row_count == row_count_before`，共清空 5922 行。apply 前后两次 `dry_run=true` 均为 63/63 全零，第二次在 10 分钟观察窗口结束后执行。清空前完成 files-minimal OSS 备份、latest/catalog 验真和 restore dry-run；随后将 release 从 `2.7.0` 直接切换到本地锁定并有 commit 校验的 `2.8.3 / 8e410d…` 二进制，再用 source commit `05a5ea4d8534b3f96d4d462c6cfda9b0775073df` 的 wasm 发布。发布后 schema 为 84 张表、旧表为 0、`clear_retired_database_tables` 为 0；API/controller/worker 已恢复，维护退出，`genarrative.world` 与 `www.genarrative.world` 返回 200。
+- 验证方式：`npm run spacetime:generate` 生成 766 个 binding 文件；`cargo check -p spacetime-client -p api-server`、`cargo test -p spacetime-module migration`（21 passed）、`npm run check:server-rs-ddd`、`npm run check:spacetime-schema`（84 tables）、`npm run check:spacetime-runtime-access`、schema guard 单测（9 passed）、`npm run check:encoding`、`npm run check:doc-index` 与 `git diff --check` 通过。
+
 ## 2026-09-02 旧玩法表采用两阶段退役清理
 
 - 背景：旧创作模板的业务代码已退出现役编译链，但 SpacetimeDB 中的历史表仍需先完成数据清理；直接删除表定义会扩大 schema 迁移和客户端兼容风险。

docs/project-memory/shared-memory/pitfalls.md

@@ -49,6 +49,8 @@
 
 按上游 [#5555](https://github.com/clockworklabs/SpacetimeDB/pull/5555) 的 retention 语义，只有最近 `retain-snapshots`（默认 2）份 snapshot 与覆盖它之后的 commitlog 段是重启所需，其余历史可丢；因此备份改为 `files + full + --minimal --retain-snapshots 2`（release 实测 40G → 3.6G，热备不停服），不再做增量差异计算，也不需要 44.7G 冷备空间。
 
+2026-09-22 的 release 清表窗口再次验证：41.2GiB 数据目录执行 `archive` 会因根盘不足失败；尝试非 minimal 的 `files + full + --stop-service` 虽通过空间预检，但在扫描 43GiB 后于 catalog 序列化阶段报 `RangeError: Invalid string length`。生产中等数据目录继续使用可验真的 `files + full + --minimal` 备份，并在 apply 前执行 `restore-files-state --dry-run`；非 minimal files 大库备份需要先修复 catalog 序列化上限，不能把失败备份当作通过。
+
 ## copyArtifacts 报「Unable to find project for artifact copy」的用户触发构建差异
 
 Copy Artifact 插件在**非 SYSTEM 认证**下按「认证用户」判权：只有当被复制 Job 的 `CopyArtifactPermissionProperty`（仓库里由 Declarative 的 `copyArtifactPermission(...)` 维护）显式列出当前消费者，或者该 Job 对认证用户开放 Item.Read 时才放行；`ACL.SYSTEM2` 的定时构建会短路通过。因此会出现「定时调度一路成功、手动发布必挂」的现象（2026-09-21 手动发布 #6/#7 与同期的用户触发探测全部命中，定时调度 #104+ 正常）。`Genarrative-Agc-Global-Version-Issue` 生产权限模式的授权名单必须同时包含 `Genarrative-Scheduled-Revision-Trigger` 与 `Genarrative-Manual-Build-And-Deploy`；改完 `copyArtifactPermission` 后要先跑一次发号 Job 把 Job property 写回 Jenkins，只改仓库文件不生效。

docs/【开发运维】本地开发验证与生产运维-2026-05-15.md

@@ -1141,20 +1141,7 @@ SELECT * FROM profile_recharge_product_config ORDER BY sort_order ASC;
 - 微信新用户的内部 `user_id` 改为不可复用的 `user_` 前缀 UUID 风格，避免清库后旧作品被后来的顺序号账号顶替。
 - 当作品作者的 `owner_user_id` 找不到真实账号时，作品统一显示为占位作者：`失效作者`，公开陶泥号固定为 `SY-00000000`，占位账号 ID 为 `wx-openid-placeholder`。
 - 该占位账号只用于作品作者域，不扩展到全站其它身份域。
-- 如需把历史孤儿作品批量回填到占位作者，使用 `scripts/rebind-orphan-work-owners.mjs` 先基于当前 auth 快照识别有效用户，再把缺失作者对应的作品表写回为占位 ID；脚本输入输出都基于 SpacetimeDB 迁移 JSON。
-
-### 回填脚本用法
-
-```bash
-node scripts/rebind-orphan-work-owners.mjs --in <exported-migration.json> --out <rebound-migration.json>
-node scripts/rebind-orphan-work-owners.mjs --in <exported-migration.json> --dry-run
-node scripts/rebind-orphan-work-owners.mjs --in <exported-migration.json> --out <rebound-migration.json> --placeholder-user-id wx-openid-placeholder
-```
-
-- `--in`：SpacetimeDB 导出的迁移 JSON。
-- `--out`：写回后的迁移 JSON 输出路径。
-- `--dry-run`：只统计回填行数，不写文件。
-- `--placeholder-user-id`：需要时可覆盖默认占位账号 ID。
+- 旧作品表退役后，迁移 JSON 回填工具 `scripts/rebind-orphan-work-owners.mjs` 已删除，不再提供回填脚本用法或当前操作入口；占位作者的显示与身份域语义继续保持上述规则。
 
 ## 维护页目标文件安全边界（2026-08-05）