Files

T

weichen ded40d071e docs(remediation): design final artifact vault

2026-09-14 10:09:32 +00:00

9.4 KiB

Raw Blame History

title, created, status, confidence

title	created	status	confidence
运行数据精简、迁移语料与演示数据保留策略	2026-09-14	done	high

调研：运行数据精简、迁移语料与演示数据保留策略

结论

用户提出的“及时清理过往数据，只保留最新、有用且必要的一部分，并用保留数据验证迁移和重载”方向合理，尤其适合当前快速迭代期的 dev/test 环境。

但必须补充两个边界：

清理历史运行数据只能降低数据转换量和现场噪声，不能替代对受支持旧 schema 的迁移兼容；应把有价值的旧状态压缩成小型、可重复、脱敏的 migration corpus。
不应在当前库上逐表删除后继续使用；当前跨项目数据存在非完整级联和 DB/文件双事实源，优先采用“新库 + 新状态根 + 选择性导入 + 旧卷隔离”的蓝绿轮换。
对最终成果再增加独立 Final Artifact Vault，但它只辅助成果定位与部分恢复，不能替代完整 DB+state 备份或旧 schema migration corpus。

当前数据画像

2026-09-14 只读现场：

环境	schema	项目数/特征	文件状态	判断
dev	33	366 个项目；149 active、217 planning；全部产生于 9 月 11–14 日	主仓 `data/dev` 约 100MB	大量 PG/E2E 夹具，适合立即精简，但须先解决当前错误挂载事故
test	29	约 37 个项目	主仓 `data/test` 约 20KB	schema 落后且数据价值低，应改为可重建/短 TTL
main	25	10 个历史 seed 项目，当前无受控文档	主仓 `data/main` 约 20KB	不应用作日常迁移试验；清理需另行确认业务/展示用途
shared KB	独立	跨环境共享知识库	`data/shared`	不属于本方案的项目数据清理范围

dev 主要表约有：projects=366、chat_sessions=421、chat_messages=1923、task_runs=307、document_records=153、document_snapshots=283、document_change_events=257。数据库总体不大，主要问题不是容量，而是数据来源混杂、迁移噪声和无法判定哪些记录应保留。

现有清理为何不能直接做

1. `DELETE projects` 不是完整项目删除

当前外键有 101 条，部分项目子表 CASCADE，但存在关键例外：

task_runs.project_id 是 ON DELETE SET NULL，项目删除后 run/event 仍可残留；
document_versions、document_snapshots、document_change_events、document_change_reports、document_agent_candidates 依赖 doc_id/snapshot/version，但不完整依附 projects；
document_content_blobs 与 storage_blobs 需要引用计数/mark-and-sweep，不能看到文件就删；
工作区、agent sessions、CAS 文件位于状态根，数据库 cascade 不会删除文件；
notification/outbox/audit/lineage 的保留语义不同，不能一律级联。

所以简单删除项目会制造孤儿数据，反而加重后续迁移与排障成本。

2. 现有备份/恢复不足以支撑安全轮换

backup-system-db.sh 只导出 PostgreSQL，不包含与之匹配的 data/<env> 文件状态；
restore-system-db-drill.sh 校验 dump 列表并运行迁移测试，但当前没有真正把 dump restore 到新隔离数据库；
restore 未强制隔离目标，默认路径存在误触共享 dev 库的风险；
没有 dataset manifest、项目选择、文件 SHA inventory、脱敏、预期断言与导入校验；
备份脚本的凭证来源需要改成统一安全配置，不应保留脚本内默认值。

在这些缺口补齐前，不能用“有 dump”作为可删除证明。

建议的数据分类

类别	用途	典型内容	是否进入日常运行库	保留策略
`operational-pinned`	当前人工使用/正在排障	项目 143 等明确认领项目	dev 可保留；main 按业务规则	显式 pin，禁止自动清理
`demo-current`	产品展示	每个正式工作流 1 个完整、可解释项目	dev/demo 环境	只保留当前版本；新版验证后替换旧版
`regression-golden`	功能回归	文档版本、人工修订、并发冲突、reload 等完整链	隔离验收库，可选只读展示副本	小型、确定性、脱敏；按能力而非数量保留
`migration-baseline`	旧 schema → 当前 schema	旧 release 的最小 DB + 匹配文件包	仅隔离迁移测试	最多保留 3 个 release 基线，滚动替换
`ephemeral-test`	PG/E2E 单次运行	自动测试项目、会话、run、workspace	每次独立数据库/状态根	PASS 后立即删；FAIL 保留 3–7 天
`quarantine`	清理回滚与取证	被替换的完整卷/状态根	不挂载到运行容器	只读 7–14 天，恢复演练通过后销毁

建议的最小保留集合

当前 dev 可先采用 6–10 个项目的上限，而不是按日期盲留：

项目 143：暂作旧数据/canonical repair/active workflow 回归样本；若含真实内容，不进入 Git，后续用脱敏等价 fixture 替换。
项目 6173：目前最新且证据完整的受控正文 UI 全链，含两份受控文档、V3/r2、并发、权限与 restart 验证，可作为当前回归/展示候选。
项目 6159：保留一个发布周期作为上一轮文档账本对照；6173 corpus 稳定后删除，避免永久重复。
三个正式工作流各生成 1 个 demo-current：main、product_manager、test_manager；必须由固定 seed/真实页面脚本可重建，不能依赖手工挑出的偶然状态。
1 个失败/异常样本不进入展示库，只进入隔离 regression-golden：覆盖 projection missing、hard-break、旧消息 scope、高 ID sequence 等历史风险。

最新项目不等于最有价值。选择评分应优先：证据完整度、覆盖的能力、是否可脱敏重建、DB/文件一致性、是否有预期断言；时间只作为同类样本的淘汰条件。

本轮已只读确认 143、6159、6173 共 5 份受控文档在主仓状态根的 output.md 均存在且 SHA 与 document_records 一致；这说明它们具备候选资格，但仍需通过敏感性、owner 和可恢复性审查后才能进入最终 retain allowlist。

迁移语料库策略

不保存每个 Goose 版本的整库。按产品 release 边界保留：

oldest-supported：当前承诺支持的最老 release；
previous-release：上一发布版；
current-pre-upgrade：本次上线前快照，下一次轮换为 previous。

当前建议先建立三个最小基线：

schema 25：文档账本前/早期治理状态，覆盖 main 当前落后路径；
schema 28/29：文档 revision 首次引入后的状态，覆盖 test 当前路径；
schema 32/33：canonical repair、task 状态和当前数据根契约。

这些基线应由迁移 fixture builder 在隔离库中构造或从已批准快照脱敏得到，不能直接把 main/test 的运行数据当测试资产。

每个 corpus package 必须包含：

manifest.json
database.dump
state.tar.zst
checksums.txt
assertions.yaml

manifest 至少记录 dataset 版本、source schema、目标 schema、生成 commit、storage identity、项目/会话/文档/run 数量、文件总数和 SHA、脱敏状态、过期时间；assertions.yaml 记录迁移后必须成立的版本、状态、正文 hash、序列与权限断言。

二进制 dump/状态包不进 Git；仓库只保留 manifest schema、fixture builder、脱敏规则、选择规则和非敏感断言。实际包放受控备份目录或对象存储。

每次发布的数据轮换模型

旧运行库/状态根（只读）
        │ export + manifest + checksums
        ▼
迁移语料构建区（脱敏/裁剪/恢复验证）
        │
        ├── oldest-supported corpus
        ├── previous-release corpus
        └── current demo/regression corpus
        │
        ▼
新数据库 + 新状态根（latest schema）
        │ import selected datasets
        ▼
工程门禁 + 页面验收 + rebuild/reload
        │ PASS
        ▼
切换运行 identity；旧卷 quarantine 7–14 天后销毁

这比在原 dev 库上大规模 DELETE 更适合当前阶段：新库天然消除未知孤儿，导入过程本身又验证了备份、迁移、文件配对、序列和重载。

风险边界

main 真实业务数据不能套用 dev 的 7–14 天策略；须先定义业务、合规、审计和用户删除规则。
项目 143 等真实内容不能直接固化为仓库 fixture；应保留 hash/结构特征并脱敏重建。
migration corpus 不能只有 happy path，否则清场后会失去发现 legacy bug 的能力。
任何清理必须先完成隔离 restore，并验证数据库与文件包属于同一 storage identity。
任何清理还必须验证应归档终态成果均已取得 FAV verified receipt；“有归档正文”不能替代完整关系闭包恢复。
错误 /tmp 数据根属于当前事故证据；在 split-brain 恢复报告签字前不纳入普通清理。

建议动作

采用运行数据生命周期与迁移语料整改方案。
首轮只处理 dev；test 改为短 TTL 隔离环境；main 仅盘点，不删除；shared KB 排除。
先实现 dataset inventory/export/restore/verify，再执行蓝绿精简，不先写清理 SQL。
并行实施最终成果保险库整改，把成果覆盖率加入 GC/销毁门禁。

9.4 KiB Raw Blame History Unescape Escape