3 Commits

Author	SHA1	Message	Date
DDSRem	2de976f6b3	Merge pull request #7050 from DDSRem-Dev/codex-comment-migration ... docs: 统一全项目中文注释和结构化契约说明	2026-10-17 19:26:29 +08:00
Aqr-K	3d594ecee3	refactor(plugin): 插件配置改走独立通道，SystemConfig 不再按键值分支 ... 插件配置此前借用 systemconfig 的 plugin.<实例ID> 单键，为了换表又在 SystemConfigOper 的 set/delete/load_snapshot 里按该前缀开分支。这是反向依赖： 一个对所有键一视同仁的通用键值存储被迫知道「插件」这个概念，读写路径依键值而 异，「这个键落在哪张表」只有读代码才说得清；规范方法按值加特例，也让此后任何新 键都要先确认自己会不会被拦截。 本次把插件配置整条链拆出，形状与本分支日志等级那条链一致： - SystemConfigOper 整体回退到官方实现，与 f70d7c141 逐字节相同，对所有键一视同仁。 - 配置端口改按实例 ID 寻址：PluginStorage 新增 read_config / write_config / async_write_config / delete_config，PluginConfigStore 去掉 key_prefix 与 _key， 不再有任何字符串键经过；plugin_exists 存在性规则、空键过滤与 force 语义不变。 - PluginInstanceOper 补齐读取与异步写入原语 get_config_data / async_save_config_data，同步与异步共用同一份落库决策，避免两条路径对「值未变化 不写」和「建行用哪个源插件」各自分叉。 - _PluginBase 的 get_config / update_config 直连 PluginInstanceOper，方法名、签名、 返回与 docstring 不变；self.systemconfig 保留，插件读 SystemConfigKey 枚举值仍 然合法，插件公开面没有扩大。 插件直接用 SystemConfig 存取自身配置不予支持。它本就不是封装过的插件配置通道， 为它设计兼容或加守卫拦截，等于再把「插件」塞回通用存储里——那正是本次要拆掉的东 西。拆开后 plugin.<ID> 只是一个与插件无关的普通 systemconfig 键：迁移已经把旧的 plugin.* 行搬进插件实例表，读它拿到 None，写它会新增一条谁也不读的 systemconfig 记录，插件配置通道既不读也不写它，两边不会再有任何交叉。 代价是读取从内存快照变成一次按实例 ID 的主键查询。调用点都不在热路径上：宿主侧 只有插件启动/重载、配置表单接口与分身创建三处，插件侧 get_config() 惯例在 init_plugin 里取一次。写入侧没有变化，本来就是一次事务。 回归防线：新增用例断言 SystemConfigOper 对 plugin. 前缀没有任何特殊行为——写进去 就是一行普通 systemconfig 记录，读出来就是刚写的值，不会被路由到插件实例表。 兼容层零改动，三个 alembic 迁移一行未改。	2026-09-13 01:41:57 -04:00
Aqr-K	4dbb8b8204	feat(plugin): 插件配置与实例描述符迁入独立表 ... 插件配置此前寄存在 systemconfig 的 plugin.<实例ID> 单键下，实例描述符则整份挤在 PluginInstances 这一个 JSON 键里，两者都不成立： - plugin.<ID> 是裸字符串 key，而仓库规则本身禁止用裸字符串做 SystemConfig key， 只允许先定义 SystemConfigKey 枚举项；插件 ID 由用户安装决定，永远枚举不出常量。 条目数随安装量增长，混在系统设置表里会把主程序自己的设置项淹掉。 - 那个键存的其实是实例 ID，表里没有任何一列说得出它属于哪个插件，想列出某个插件 的全部实例配置只能靠字符串前缀去猜。 - 实例描述符整份读出再整份写回，改一个分身要重写全部分身。 改为 plugininstance 一实例一行：instance_id 与 source_plugin_id 构成身份，本体与 分身由两者是否相等派生而不设模式列——模式列会是这个等式的冗余副本，两者一旦失步 同一行就会在不同读取口被判成不同角色。展示信息与业务参数同存一行，属于同一个 生命周期，分表只会让建分身、删分身退化成两张表之间的协调问题。 读写路由落在 SystemConfigOper.get/set/delete，而不是在各个调用方各改一处：第三方 插件可能直接用 self.systemconfig.get("plugin.xxx") 读写自己的配置，只改 PluginConfigStore 与 _PluginBase.get_config/update_config 必然漏掉它们。路由只做 前缀识别，插入、更新与空本体行回收都委托 PluginInstanceOper，不在配置层重抄一遍。 PluginInstances 旧键迁移后不删，留作回滚依据，并以 SystemConfigKey.PluginInstancesImported 标志防止重复导入；判据不能是「表当前为空」， 否则用户把分身全部删光后，下次启动会把它们整批导回来。 迁移链：b2d4f6a8c1e3 -> 281965691a20（3.0.34 建表并搬描述符） -> c4e1a7b9d2f6（3.0.35 加 config_data 并搬 plugin.* 配置）。 依赖基线与启动模块数随两个新模块重算，架构文档与数据库技能表目录同步登记新表。	2026-09-12 17:39:36 -04:00