版本契约

版本控制契约¶

每个数据库都在两个位置记录其已发布的模式：

• PRAGMA user_version 是 SQLite 模式版本。
• 主 schema_meta 行记录 role、agent_id、schema_version 和 app_version。app_version 是最后写入模式元数据的 OpenClaw 构建版本。

OpenClaw 在打开较旧但受支持的数据库时应用仅向前迁移。它会拒绝 user_version 比当前构建更新的数据库，并报告 newer schema version 错误。Gateway 在启动前检查所有已注册数据库。openclaw update 也会拒绝声明的模式支持早于磁盘上数据库的软件包或源码目标。在添加模式元数据之前发布的已知稳定版本会按其随附的 schema-1 契约进行检查。由 2026.9.2 发布线驱动的更新可以在旧更新器完成期间临时延迟发布共享状态模式版本；参见 模式版本升级与旧更新器。

当 Gateway 启动遇到更新的数据库模式时，它以状态 78 退出，以免生成的 systemd 服务反复重启它。在 macOS 上，它还会暂停其管理的 LaunchAgent，以停止 KeepAlive 重试。这适用于 CLI 引导期间以及服务器启动期间的故障，并且不依赖于基于数据库的崩溃计数器。使用支持现有模式的构建启动 Gateway。旧安装无法使用 openclaw doctor --fix 修复它们；如果需要进一步迁移，请从兼容的安装中运行 openclaw doctor --fix，然后通过服务或部署负责人重启。

只有当降级后的读取器仍然安全时，变更才可以保持相同的模式版本。新表符合条件，因为旧构建会忽略它们。现有表上显式兼容的列仅在声明恰好是一个裸的可空 SQLite STRICT 数据类型时符合条件：ANY、BLOB、INT、INTEGER、REAL 或 TEXT。该声明不能具有默认值、NOT NULL、主键或唯一键、检查、引用、排序规则、生成表达式或其他后缀。对现有表的受约束新增需要改为提升模式版本或使用伴随表。

Linux Node worker 清理使用增量式 node_worker_launch_process_scopes 伴随表。其绑定到启动的 linux-subreaper 证书独立于 node_worker_launch_cleanup.lineage_settled 记录内核后代消亡。现有清理行保留 owned-anchor，没有合成谱系完成，因此旧读取器保留不确定的托管状态，而不是将新证书视为较早的证明。现有行不会被回填或重新解释。伴随行在相同保留策略下随其启动一起修剪；模式版本保持不变。

数值版本匹配是必要条件，但并非充分条件。发布版本可以在不提升 user_version 的情况下添加惰性或可在启动时修复的表、列、索引或触发器，因此两个相同版本的数据库仍可能具有不同的结构。OpenClaw 会验证当前运行发布版本所拥有的规范表定义、约束、索引、触发器、虚拟表和表选项。

已准入的代理和缓存的共享状态句柄保留其模式版本和表事实。句柄所有者在本地 DDL 或事务回滚后撤销这些事实。新的 PRAGMA data_version 探测会在下一次未固定读取时观察到外部提交，即使在同一事件循环轮次内也是如此。在外部提交时，所有者在一个固定快照中比较 schema_version 和 user_version，并在两者均未变化时保留事实及其修订版本。因此，仅数据提交可以避免表和列扫描，而仅版本变化仍会在存储版本比当前构建更新时触发拒绝。实际的 SQLite 读取快照会保留其视图直到结束；下一次读取随后会观察到已提交的更改。规范会话验证使用相同的模式修订版本。未变化的版本会复用已解析的模式事实和预编译语句，而不重复模式扫描。迁移和快照一致性检查仍为新鲜读取。这不会更改任何存储模式、迁移、持久性或更新行为。

GitHub 发布生命周期和仓库回执上的可空请求者权限列需要 状态模式 18。随附读取器会精确验证这些可选表，并拒绝额外列，即使它们是裸的且可空的。迁移会保留具有未知请求者权限的历史行；版本提升还会阻止旧发布者在新权限检查缺失的情况下重新打开请求。

会话标签查找使用 session_nodes(label, session_key) 上针对非空标签的非唯一部分索引，且不改变代理模式 20。现有的可写模式所有者会安装并修复该索引；只读启动会接受其缺失，直到该所有者打开数据库。存在但非规范的定义仍会失败严格离线验证；Gateway 启动会在就绪前将规范索引修复准入到同一可写模式所有者，并记录重建的索引和耗时。缺失的表和不兼容的列定义仍会被拒绝。规范会话 JSON、标签唯一性检查和保留策略保持不变。较旧的相同版本读取器可以忽略额外索引，因此二进制回滚会使其保持完整。已接受的设计记录在 会话标签索引决策。

任务和维护查找添加了非唯一索引，但未改变状态模式 17 或代理模式 21：任务请求者会话、按环境划分的 worker 放置，以及有效性尚未确认的会话条目。在 Tasks 运行时移除后，任务请求者索引仍保留在物理模式中。存储行、保留策略和所有权检查保持不变。只读准入接受缺失的索引；规范可写模式所有者会安装或修复它们。初始构建使用与受影响表成比例的时间和临时磁盘，后续写入会维护新增的索引。较旧的相同版本读取器可以忽略它们，因此二进制回滚会同时保留行和索引。参见 已接受的索引设计。

移除 Tasks 和 TaskFlow 运行时不会更改共享状态或 agent 架构。现有表、索引以及可选的执行所有者列仍然是已发布存储契约的一部分。Cron 通过其自身存储读取和写入 task_runs 中现有的 runtime = 'cron' 历史行。非 Cron 的 Task 和 TaskFlow 行保持原样，且不被运行时使用；它们不会被转换为替代账本。Codex 插件的 Doctor 迁移 从带有所有者标记的旧行中保留符合条件的原生子恢复事实，并将其保存在现有父级绑定元数据中，同时使用原子导入标记防止重放。源行保持逐字节相同。此次移除不伴随删除表、SQL 架构变更或架构版本提升。

Node 工作进程恢复使用现有启动日志中的私有 node_worker_launch_cleanup 伴随表。启动所有者在首次使用时添加该表，并在允许执行之前，在与工作进程身份相同的交易中，将所选的进程组或拥有锚点传输记录到 cleanup_mode。拥有锚点只能在其根进程退出且其继承的谱系达到正向 EOF 之后，针对其精确的当前运行身份记录 lineage_settled = 1。恢复还会在释放容量之前验证已记录的进程组已经消失。缺失或模糊的谱系结果仍保持未知；仅凭空的锚点组无法证明其他组中的后代已经停止。

Node 恢复修复 保持日志作为唯一的持久所有者。清理记录不包含启动描述符或凭据，不进入公开回执，并通过级联外键共享启动现有的 24 小时终端回执保留期。架构版本保持不变；旧版读取器忽略新的伴随表，而不更改其启动表契约。缺失的清理记录保留已发布的 2026.9.4 进程组契约，而不会回填推测的身份。使用未标记锚点的未标记中间构建必须在替换之前，在该原始构建上排空其工作进程。活动的现代工作进程在降级或回滚到旧版写入器之前也必须排空，因为旧版写入器无法解释锚点谱系完成。

通知所有权使用相同架构版本下的裸可空 TEXT 列：session_watch_cursors.watcher_store_path、 subagent_runs.requester_store_path 和 subagent_runs.controller_store_path。 它们的写入器在首次使用时幂等地确保这些列存在；读取不会安装它们。 旧版读取器忽略这些列。NULL 仍表示未知，因此 Gateway 通知投递不会仅凭键将历史记录分配给当前父级。

Cron 常设授权定义代次使用 cron_jobs 上的三个裸可空投影：grant_definition_revision、grant_definition_generation 和 grant_definition_updated_at。规范作业仍然是 job_json。当前写入器与其原子地更新这些投影，在实质性定义变更（包括编辑后恢复）时推进代次，并在禁用和重新启用之间保留代次。

已发布的 operator_approval_standing_grants 表保持其精确形状。首次使用的伴随表 operator_approval_standing_grant_generations 将每个新铸造的授权绑定到其作业代次，并随授权级联。旧版同版本读取器忽略伴随表和裸可空作业列，因此可以重新打开数据库。重新升级后，没有伴随行的授权被视为遗留项，并需要再次批准；它永远不会被追溯分配代次。作业重新创建会推进到保留的伴随代次之后，包括旧版写入器删除作业行的情况。

旧版写入器不会维护这些投影。其编辑会使投影过期，因此当前读取器在重新升级后会失败关闭。当旧版构建运行时，它无法强制代次绑定，而保留每个可观察作业值和时间戳的变更之后无法重建。无需回填或架构版本提升。已接受的设计和回滚契约记录在 #142153。

保留的 ACP 导入使用同版本附加列例外，针对裸可空 session_nodes.legacy_acp_migration_json TEXT 列。旧版会话导入在首次使用时确保该列存在，并记录精确的源组件来源；普通会话编辑保留它，规范键修复会随会话携带它。规范 ACP 初始化或关闭会在现有共享状态迁移账本中消费这些组件，并与 ACP 变更原子执行。之后的 Doctor 重试会读取该完成事实，而不是将缺失的 ACP 行视为恢复旧版元数据的许可。缺失的来源仍保持未知；读取器不会创建该列或从旧版文件中重建它。该列随其会话的生命周期存在，而已完成的回执保留现有迁移账本生命周期。无需架构版本提升。

旧版同版本读取器可以忽略该可空列并打开数据库。旧版 ACP 写入器不会记录此取代；当需要该保护时，在返回旧版写入器之前完成待处理迁移。

冷转录存储 即使添加了伴随表，也需要 agent 架构 20。旧版读取器会将提取的转录行解释为缺失的历史，并且无法安全地忽略新的表示。受支持的更新器的 Doctor 阶段执行架构迁移；之后更改冷存储年龄设置无需重启 Gateway。这些是独立操作：实时配置重载不会授权活动架构迁移。

Agent 架构 21 使规范验证待处理表及其节点、窗口和主键失效触发器成为必需。这需要版本提升：旧版架构检查器会拒绝规范表上的意外触发器。维护迁移将现有节点标记为待处理，而不重写其内容；就绪状态和 Doctor 拥有验证。已打开的旧版连接在更改规范输入时会留下待处理标记。使用旧版代码重新打开会被拒绝。回滚使用经过验证的迁移前备份和匹配构建，而不是仅更改标记或移除派生表。参见 增量规范会话验证。

Agent 模式 22 引入了精确的 transcript FTS 行所有权，带有可空的完整性计数和惰性回填。模式 23 同时接受该已部署形态以及模式 21。它会从现有 FTS 内容重建所有权映射，保留待处理协调，并退役旧的完整性计数器。

Agent 模式 23 更改了现有负载表示：transcript 事件可以使用 Zstd BLOB，内存嵌入使用 Float64 BLOB，内存全文维护使用稳定的整数 chunk 标识。旧版写入器无法保留这些契约，因此尽管保留了逻辑事件和 chunk ID，仍需要提升版本。共享状态模式保持为 17。用量汇总缓存格式会随此迁移更改，但可以独立重建。有关转换、运行时要求和恢复，请参阅紧凑 Agent 负载存储。

Agent 模式 19 在可空的 session_pending_inputs.consumed_event_id TEXT 列中记录已收集输入的消耗情况。Doctor 以及该功能首次使用时的 ensure 会在需要时添加它；模式版本保持为 19。该列在 2026.8.2 中发布（#133457），因此受支持的 beta 升级会运行 2026.8.2 或更高版本的 Doctor。已经验证可选的 pending-input 表的中间构建版本可能会拒绝新增的列，即使它们共享版本 19。已消耗的源回执会保留到其会话窗口被删除为止，因此重写 transcript 无法使旧输入再次可运行。

Cron 运行回执使用可选的 cron_run_trigger_state_retirements 伴随表，而不更改状态模式 17 或已发布回执表的形状。其唯一列是 receipt_id，一个引用现有回执的主键，并带有 ON DELETE CASCADE。已提交的 condition、script-payload 或共享状态编辑会在与作业编辑相同的交易中创建一条退役行。这包括一个已由 agent-owner 编辑关闭但仍等待运行协调的精确回执。正常完成和重启恢复会保留替换项的状态，同时保留旧运行的历史。第一个符合条件的编辑会创建该表；排队中的编辑不会退役未来的评估。作业的私有运行时状态会保留精确的运行中回执 ID，直到调度器协调为止，包括 agent-owner 编辑先关闭回执的情况。恢复和后续状态编辑会使用该关联，即使运行时间戳冲突。回执修剪会保留该待处理回执；普通历史保留其现有的 64 回执上限，并随回执一起删除退役行。

在此关联被记录之前写入的行会保留其旧版恢复回退。该关联不添加任何 SQL 表、列或模式版本。当前构建版本会将其从公共作业状态和公共状态补丁模式中省略。

缺少表或行表示没有记录的退役；较早的编辑无法从最终作业定义中重建。旧版兼容读取器会忽略该伴随表，但不会强制实施此保护。为了保留已编辑的 watcher 状态，请在降级前在当前构建版本上完成活动运行和待处理的调度器协调。终结历史结果或回执仍可能使作业状态未协调。

在运行等待协调期间进行的调度编辑会在现有作业运行时状态中记录一个私有的 runningScheduleChangeId，并与编辑位于同一交易中。新值可以区分连续提交的编辑，即使被动编辑器的快照跨越两个运行。完成和恢复会保留已编辑的调度状态；新运行和待处理运行清理会清除该标记。这不会添加任何表、列或公共作业字段。

没有此标记的待处理运行会保留其先前的恢复行为。旧版构建版本确认的编辑无法可靠地从时间戳或最终调度中重建。对这些待处理作业的新编辑会正常记录该标记。旧版兼容读取器会忽略它；如果必须保留其已编辑的节奏，请在降级前完成待处理运行。

Worker 准备对共享状态数据库中裸可空的 worker_environments.preparation_purpose TEXT 列使用相同版本规则。共享状态数据库启动修复会添加它，而不更改状态模式 17。新准入写入 reserve 或 build；现有准备行保留 NULL 并读取为 reserve，不会回填 demand 或更改 expiry。旧版读取器会忽略该列，并将现有 reserve 策略应用于所有已准备的 worker；如果必须完成待处理构建，请在降级前停止它们。重新打开会保留 purpose、consumption、demand 和 cleanup 所有权。

placement-move 表对其裸可空的 abandon_source INTEGER、target_machine_class TEXT 和 target_os TEXT 列使用此相同版本规则。该功能仅在首次使用 move 时确保这些列；数据库启动不会添加它们，模式版本保持不变。target_machine_class 和 target_os 保留显式的 profile-target 覆盖；NULL 表示无覆盖。对于 abandon_source，NULL 表示普通的 reconcile-first 移动；1 记录操作员明确的离线设备放弃决定，因此重启恢复不会意外恢复远程协调。旧版读取器会忽略新增列，并可以安全地重新打开同一数据库；它们未实现较新的操作系统覆盖。

Conversation 关联对可空裸 route_context_json TEXT 列使用相同规则。数据库打开修复会为更新后的二进制文件确保该列。旧版读取器会忽略它，并可以安全地重新打开和更新同一数据库；它们的关联更新会使较新写入器捕获的上下文失效，因此重新升级后无法重放。

保留的 Conversation 进度快照使用 agent 数据库的 cache_entries 表，作用域为 conversation-progress，并以投递操作 ID 作为键。Tasks 支持的 detached presenter 已被移除，但其存储的快照和回执清理契约保持不变。此次移除不伴随任何表、列、模式版本更改或迁移。旧回执不会回填。

The receipt owns the known platform message identity and delivery status. The removed presenter no longer writes or reads progress snapshots. Existing snapshot bytes remain opaque retained data; desired presentation is not proof that a platform edit was delivered or that work completed.

Reopening does not restore the removed Tasks presenter from cached snapshots; a snapshot never grants execution or delivery authority. Canonical session repair carries snapshots with their receipt identities. The existing session delivery cleanup removes matching snapshot keys with their receipts, with no new expiry policy, cleanup loop, or completion owner.

Transcript context eligibility uses a bare nullable session_transcript_active_events.context_eligible INTEGER column without changing agent schema 18. Database open installs the column and a non-unique partial index of unclassified rows. 1 includes an entry in bounded context acquisition, 0 excludes display-only activity, and NULL means the projection still needs reconciliation. Bootstrap control markers remain eligible; history counts, positions, and cursors do not change. Raw transcript JSON stays canonical.

Older same-version writers can append or rebuild without supplying eligibility. The existing transcript reconciler detects their NULL rows even when its sequence watermark is current, then rebuilds from raw events before publishing readiness. Readers return a retryable projection-unavailable result while this work is pending; they do not parse every payload or guess eligibility. Initial index creation scans projection metadata once, and startup awaits reconciliation with off-thread parsing and bounded write chunks. Total rebuild cost remains proportional to history. Rewrites invalidate or rebuild the projection in their own transaction, and transcript deletion removes its eligibility rows. Downgrade leaves the additive column and index intact; re-upgrade reconciles unknown rows.

Multi-account person profiles add the bare nullable user_profiles.primary_github_account_id INTEGER column on first profile use, without changing the shared-state schema version. Existing single-account profiles have an unambiguous primary; explicit merges retain all verified account rows and keep the target primary. This deliberately accepts a downgrade limitation: older single-account writers can discard secondary account links or split a linked person again. Re-upgrading cannot reconstruct discarded links. Keep a backup before downgrading, and explicitly relink affected profiles after upgrading. The version number does not certify preservation of multi-account relationships.

User profiles use the same rule for the nullable bare user_profiles.role TEXT column in state schema 9. Operator-role assignment lazily ensures the column on first use. Older readers ignore the column and can reopen the same database safely.

Web Push subscription ownership uses the same rule for nullable bare web_push_subscriptions.device_id TEXT, user_profile_id TEXT, and preferences_json TEXT columns. Web Push lazily ensures all three columns on first use. Existing rows remain unbound and test-only until the browser reconnects; older readers ignore the columns and continue reading or updating the endpoint and key fields safely.

Approval-notification cleanup uses the same-version additive web_push_approval_deliveries table. It records the approval/subscription identifiers plus the request-time device/profile binding for notifications that may have reached a browser. A terminal or restarted Gateway sends only when the current subscription still has that binding. The table is lazily created on first use, rows cascade away with their approval or subscription, and older readers ignore it safely.

Installing OpenClaw manually through npm bypasses the updater guard. Database open checks still refuse an incompatible build.

Structured Goal controls use a lazy per-agent session_goal_operations table without changing the schema version. Goal start/resume commits the Goal transition, input turn, run lifecycle, and operation receipt in one transaction. Management operations commit the Goal transition and receipt together. Older readers ignore the added table. Receipts survive Goal clear and session reset/deletion until their 24-hour validity expires; later Goal writes prune expired rows. They retain the original result and a keyed request fingerprint, not a second raw request. There is no backfill or configuration switch. Downgrading preserves the table but disables the new structured controls; upgrading can read retained receipts.

Schema bumps and older updaters¶

OpenClaw 2026.9.2 introduced the update ledger but reopens it with old code after running the target's Doctor, including a final read after recording its terminal outcome. The shared state database runner lets this updater finish by applying migration content first and publishing the new schema version later. This rule applies to every writable open, including Doctor, the restarted Gateway, and other CLI processes.

The runner records the applied content version in the existing config_machine_state key state.schema.contentVersion. While publication is deferred, new code uses that content version, and both PRAGMA user_version and schema_meta.schema_version retain the previous published version. Content and its marker commit together. Reopening skips migration steps already covered by the marker, including the schema-16 Skill Workshop rebuild; it does not infer completion from table shape or repeat the rebuild. This requires no new table, configuration option, or environment override.

Current content is ready for readers even while its version is unpublished. Ordinary CLI commands can run alongside the Gateway throughout this window; publication alone does not trigger schema repair or require stopping the Gateway.

A subsequent update can run during this window. Its migration verification and rollback checks compare applied content versions from private database snapshots. Publishing already-applied content is not another migration; applying new content still blocks rollback even when the published number has not changed. Managed service stop, activation, and Doctor maintenance keep their normal ownership rules.

发布将等待每一条其 before.version 标识 2026.9.2 发布系列的更新行满足其适用条件：

• 终止行的 finished_at_ms 至少已过去五分钟。
• 运行中的行的 updated_at_ms 已超过 30 分钟。就发布而言，运行器会将该驱动视为已放弃；它不会改写该次运行的结果。

缺少账本或没有受影响的行时，可以立即发布。截止时间来自这些行的时间戳，绝不由观察进程的启动时间决定。新 Gateway 的账本监视器会在适用的截止时间无抖动地调度发布。发布持有 Gateway 生命周期围栏：拥有所有权的 Gateway 可以发布；当没有 Gateway 拥有状态目录时，后续的可写打开操作也可以发布。其他进程会静默地将发布留给该所有者。

发布会在推进两个已发布 schema 标记之前，在同一个同步写事务内重新读取内容标记和所有受影响的行。新的或刷新的运行中行会再次阻止发布。重启 Gateway 不会缩短或重新开始宽限期。

五分钟宽限期旨在容纳 2026.9.2 的遗留账本读取；该发布系列没有记录驱动进程身份，因此无法证明这些读取已经完成。旧版 CLI 在提交其终止行后被阻塞超过五分钟（例如卡在停滞的 stdout 管道上），仍然可能在发布后的最终渲染中失败。到那时，软件包替换、任何请求的服务重启以及终止账本结果都已完成。2026.9.2 发布系列的降级保护会被相同的宽限期或 30 分钟的放弃驱动限制所推迟。保留的版本并不表示允许针对已迁移的功能表运行旧代码。请勿手动降低任一版本标记，也不要删除内容标记。

更新时的 Doctor 会在其他修复之前检查共享及已注册的 agent 数据库。仅状态迁移会在推迟发布的情况下继续，并报告 schema content applied; version publication deferred until update run <id> finishes。在该次运行结束后，发布仍会遵守五分钟宽限期。Agent schema 版本不会被推迟或重新标记。对于受支持的 2026.9.2 包更新，早期 Doctor 会在旧驱动仍可回滚其包安装时，对私有数据库副本运行 schema 修复。只有在私有 Doctor 及其子进程都成功完成后，它才会报告成功；在线 agent 数据库保持不变。在此回滚窗口内，已知的待处理 agent 数据库若没有已注册的规范备份所有者，仍会拒绝继续执行。

随附驱动提交软件包并进入其全新的 post-core 阶段后，当前更新器会在其执行器与维护所有权下委派 Doctor。Doctor 会在常规在线迁移之前，创建并验证一个覆盖每个待处理 agent 数据库的保留恢复归档。覆盖要求 agent 所有者和物理文件标识相匹配，包括已注册的自定义路径；不透明的归档字节并不是经过验证的 SQLite 快照。在备份工作之后，以及版本化 schema 写入与提交边界处，会再次检查权威和在线文件标识。Doctor 会报告保留的归档路径；它不会在后续失败时自动恢复该归档。

当阶段或当前所有者无法验证、可恢复的备份覆盖缺失，或所需的 config_machine_state 表不存在时，Doctor 仍会给出类型化的 update-schema-bump-unfenced 拒绝。私有预演失败和备份失败会使在线 agent schema 保持不变。失败的内容事务会回滚。该拒绝会包含受影响的数据库版本、发起更新的更新器版本，以及手动更新命令。包回滚无法逆转已经发生的迁移；在线迁移后的恢复需要经过验证的备份和匹配的构建。

驱动检查要求有效的语义化版本，并且包含 2026.9.2 重建版本。更早的更新器（包括 2026.9.1）没有账本，并保持正常的发布行为。从 2026.9.3 起的构建（包括预发布版本）使用事务性更新，将旧进程的账本访问隔离，并让候选代码在迁移后完成运行；它们也保持正常的发布行为。同 schema 修复和常规 Doctor 运行仍然可用。

Profile 拥有的技能库¶

个人和团队技能使用共享状态数据库中的四张首次使用表，且不改变其 schema 版本：skill_library_entries、skill_library_revisions、skill_library_events 和 skill_library_uploads。普通工作区技能和未使用库的发现不会创建这些表。所有权、共享、当前修订指针、可移植文件清单和发布事件都是规范的 SQLite 数据。会话选择仍保留在现有的按 agent 区分的会话存储中；继承的 cron 选择仍保留在现有的私有作业记录中。

完整技能包是位于 <state-dir>/skill-library/<skill-id>/revisions/<revision-hash>/ 之下的产品工件。发布会在一个同步数据库事务中提交其当前指针和事件之前，写入并验证一个不可变技能包。并发编辑必须基于预期的修订版本。该提交之前的崩溃可能会留下未被引用的完整技能包，但不会留下指向部分写入内容的指针。共享和转移会更改元数据，而不会移动修订文件。

移除技能会将其排除在未来的选择之外；现有会话会保留其已选择的修订版本。已发布的历史记录和完整的孤立修订版本会被保守地保留。过期的上传记录会在另一次上传开始时被清理；明显废弃的暂存目录会在后续发布期间得到清理。请同时备份状态数据库和 skill-library 目录，而不只是当前的修订指针。

较旧的同 schema 读取器会忽略这些新表，但无法提供托管库选择或创作功能。更换构建版本时，请保持这些表和技能包目录完整；不要为了禁用该功能而降低 schema 标记或删除修订版本。已接受的存储和所有权决策记录在Profile 拥有的技能设计问题中。