RXDB_SYSTEM_SCHEMA_VERSION

const RXDB_SYSTEM_SCHEMA_VERSION: 6;

Defined in: packages/rxdb/src/system/migration.ts:50

系统表结构版本

Remarks

2：rxdb_migration."name" 加唯一索引。 4：epic-006 的 10 张工作树 / 提交图表（当时长在核心）。 5：rxdb_branch.activeKey 可空唯一列（FR-048 的「至多一个 active」那一半）。 6：activeKey 就位，且 v4 那十张表不再归核心管——它们随 @aiao/rxdb-plugin-working-tree 走，认领与否改由能力水位裁决（见 system/capability-watermark.ts）。

5 是补记而不是新增能力：该列在 v4 水位线之后才进 system/branch.ts，于是已经被标成 4 的 库（开发机上的那批）再也不会走进升级路径——版本号是升级路径唯一的触发条件，列本身不是。 不 bump 就只能留下「除了那批库之外都正确」的洞。

6 不带任何 DDL，它只是把边界挪了位置。两个适配器的 migrateSystemSchema() 是一整块 幂等修复、只由 isCurrentRxDBSystemVersion() 把门，于是停在 4 的库补出 activeKey、 停在 5 的库空转一趟，两者都被重新标成 6，适配器一行都不用改。不复用 4 或 5 改语义： 水位号是升级路径唯一的触发条件，把 4 重新定义成别的意思会让已经标成 4 的那批库被静默误读， 而误读不产生任何编译错误。

有一种库它接不住，要写进发布说明：抽包之前就启用过提交能力的库停在 4/5，十张表 带着真实数据物理还在，却没有能力水位行（那是抽包之后才有的形态）。于是新客户端即便不装插件 也照常打开它，写入不再经过捕获——capability-watermark.ts 的守卫只认得水位行，够不到这一种。 不为它单开迁移是因为这批库只存在于开发机上：epic-006 从未发布过。

改这个常量是一次单向操作：bump 之后旧版本客户端打开该库会按 UnsupportedRxDBSystemVersionError 拒绝。这不是新增的危险面（2→3 同样如此）， 但每次 bump 都必须进发布说明。

常量停在旧值不会让任何一处编译失败——水位线是模板字符串拼出来的，会安静地跟着停住， 既有库于是永远进不了升级路径。__tests__/system/migration.spec.ts 的「系统 schema 版本常量 与水位行停在当前值」把它钉死就是为了这个——那是同一节里唯一写死版本号的一条， 不要顺手改成取常量。