补充历史表清空与备份现场证据

记录 release 阶段一 apply、全零复核和观察窗口结果
记录 files-minimal 备份与 restore dry-run 验证
记录大库非 minimal files 备份的 catalog 序列化边界

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

@@ -799,11 +799,12 @@ Godot 编辑器操控复用既有 AGC 插件宿主、EditorAdapter、Runner 和
 
 ## 2026-09-22 旧创作模板历史表从 schema 与生成绑定中删除
 
-- 背景：旧创作模板的 63 张历史玩法表已经完成业务代码退役和数据清空，继续保留 table 定义、迁移白名单、旧行兼容分支和生成绑定会让当前 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 及后端数据契约。
-- 验证方式：`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` 通过。未连接生产库执行发布或破坏性维护操作。
+- 生产数据闭环：`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；生产 module 尚未执行阶段二发布。
+- 验证方式：`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 旧玩法表采用两阶段退役清理
 

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，只改仓库文件不生效。