描述
随着插件接入的数据源与能力持续增加，主仓维护成本明显上升：部分专业/地方数据源受众很窄，却会持续占用核心维护精力；同时社区也出现了基于魔改分支扩展能力的需求，导致部分用户难以安心跟随主线更新。
计划引入一套挂载在本插件之上的 Extension（扩展）系统（注意：区别于 AstrBot 宿主插件本身），让有能力的贡献者通过独立扩展包复用主插件的事件管线、规则链、展示与推送能力，而无需长期维护 fork。
扩展系统的目标不是“再造一个插件框架”，而是把现有已相对清晰的静态注册能力（SourceEntry / SOURCE_CATALOG、parser_registry、RuleChain、presenter_registry、连接 handler、EventPipeline 等）升级为：
- 可发现（目录/manifest 加载）
- 可声明（扩展元数据、权限、依赖、提供能力）
- 可注册（运行时 Registry 动态合并）
- 可隔离（扩展失败不拖垮主插件）
- 可演进（
api_version / min_host_version）
设计哲学（草案）：
主插件 = 稳定的灾害事件“操作系统”
扩展 = 数据源、策略、皮肤、场景与增值能力
主仓追求正确与可维护，扩展仓追求丰富与创新
命名建议：
- 对用户：扩展 / Addon / 能力包
- 对代码：
extension（避免与 AstrBot plugin 概念混淆）
第一阶段（MVP，建议）：
- Extension Loader（本地目录发现 +
extension.yaml）
- Runtime Registry（至少支持 source / parser / presenter / rule）
- 窄而稳定的
ExtensionAPI（register_* + config/logger/storage 等）
- 配置：
extensions.<id>.enabled + 扩展私有 config
- 管理命令：扩展列表 / 启停状态 / 加载错误诊断
- 1 个官方示例扩展（如 HTTP 轮询地震源）
- 开发者文档（如何写 Source/Parser 扩展）
明确暂不做（MVP 外）：
- 进程级沙箱
- 扩展市场 / 签名体系
- Admin 动态页面完整框架
- 一夜之间把全部内置源插件化
后续可演进方向（画饼区，欢迎讨论）：
- Connection Handler / Ingress Adapter 开放（HTTP/WS/MQTT 等）
- Enrichment、Command、Card Theme、Pipeline Hook
- 场景包（Scenario Pack）：一键组合配置 + 规则 + 文案 + 卡片
- 扩展间事件总线、WebAdmin schema 自动渲染
- 内置低频源逐步外置，主仓最小化
与现有架构的贴合点（实现时需对齐）：
SOURCE_CATALOG → Runtime Catalog（builtin merge extensions）parser_registry 动态注册，收敛 source 特例分派ProviderFamily 从封闭 Enum 走向可扩展标识SourceMessageRouter.register_all 遍历已注册 handlerbuild_default_rule_chain 支持 stage + priority 插入presenter_registry 动态化EventPipeline 增加前后 hookConnectionPlanBuilder / 配置 schema / WebAdmin 合并扩展配置
状态说明：本 Issue 用于挂住长期方向与社区讨论，当前不承诺排期与交付时间。先收集需求边界、API 形状与迁移策略，再决定是否拆分为设计文档与实施子任务。
使用场景
-
专业用户 / 地方监测需求
希望接入北京地震局、广西地震局等小众源，或主要关注 M3.0 以下事件；这些能力对大多数用户无价值，但应由社区扩展提供，而不是塞进主仓。
-
避免魔改分支
有开发能力的用户现在可能 fork 后硬改 parser/catalog；扩展系统落地后，可在主插件更新的同时，仅保留/升级自己需要的扩展包。
-
能力复用，而不仅是“加源”
同一套扩展机制后续可承载：
- 自定义过滤规则（地理围栏、关键词、本地烈度策略）
- 专属文案/卡片主题
- 事件富化（轨迹、烈度圈、外部 API）
- 自定义命令与管理端诊断页
- 场景包（如“沿海海啸”“首都圈”“校园防灾”）
-
维护者减负
主仓只维护通用、稳定、高受众核心能力；长尾需求通过扩展生态消化，减少“帮我加一个只有我们单位用的源”类持续压力。
你希望该功能主要服务于哪个消息平台？
其他平台
其他平台名称（如选择“其他平台”请填写）
全平台（扩展系统位于插件内核层，与具体消息平台解耦；推送仍走现有 AstrBot 会话/适配器链路）
当前主要部署方式（可选）
不确定
补充说明（可选）
建议讨论并拍板的关键问题：
- MVP 边界：只做 Source + Parser，还是第一期就含 Rule / Presenter / Connection？
- 扩展安装方式：仅本地目录，还是后续支持 zip / git？
ProviderFamily 开放策略：可注册字符串，还是 Enum + custom 兜底？- 新灾种策略：MVP 是否仅允许扩展已有灾种（地震/海啸/气象/台风）？
- 去重与融合契约：扩展如何声明
event_id / fingerprint / fusion_group？
- 规则插入语义：
stage + priority 是否作为默认模型？
- 内置源是否逐步插件化：短期双轨，还是中期强制 builtin 也走同一 API？
- 权限模型粒度：
network / register_source / register_rule 等粗权限是否足够？
- 配置 UX：先 JSON/命令行，还是同步做 WebAdmin schema 渲染？
- 安全基线：异常隔离、超时预算、资源配额的最小集合如何定义？
建议的分阶段路线（供参考）：
- L0：扩展加载器 + 运行时注册 + 数据源/解析器外置（解决维护压力）
- L1：规则/展示/命令/富化/Admin 扩展（模块化能力）
- L2：市场、签名、兼容矩阵、更强隔离（生态治理）
非目标（至少现阶段）：
- 让普通用户必须会写 Python 才能用插件
- 用扩展系统替代 AstrBot 插件机制本身
- 在缺少稳定 API 的情况下鼓励深度 hook 内部私有模块
欢迎对命名、MVP 范围、API 形状、目录布局、迁移策略提出意见。若方向收敛，可再拆：
- Design Doc：
extension.yaml 字段 + ExtensionAPI 清单 + 加载时序
- 实施 Issue：Loader / Registry / 示例扩展 / 文档
你愿意提交 PR 吗?
Code of Conduct
描述
随着插件接入的数据源与能力持续增加，主仓维护成本明显上升：部分专业/地方数据源受众很窄，却会持续占用核心维护精力；同时社区也出现了基于魔改分支扩展能力的需求，导致部分用户难以安心跟随主线更新。
计划引入一套挂载在本插件之上的 Extension（扩展）系统（注意：区别于 AstrBot 宿主插件本身），让有能力的贡献者通过独立扩展包复用主插件的事件管线、规则链、展示与推送能力，而无需长期维护 fork。
扩展系统的目标不是“再造一个插件框架”，而是把现有已相对清晰的静态注册能力（
SourceEntry/SOURCE_CATALOG、parser_registry、RuleChain、presenter_registry、连接 handler、EventPipeline等）升级为：api_version/min_host_version）设计哲学（草案）：
命名建议：
extension（避免与 AstrBotplugin概念混淆）第一阶段（MVP，建议）：
extension.yaml）ExtensionAPI（register_* + config/logger/storage 等）extensions.<id>.enabled+ 扩展私有 config明确暂不做（MVP 外）：
后续可演进方向（画饼区，欢迎讨论）：
与现有架构的贴合点（实现时需对齐）：
SOURCE_CATALOG→ Runtime Catalog（builtin merge extensions）parser_registry动态注册，收敛 source 特例分派ProviderFamily从封闭 Enum 走向可扩展标识SourceMessageRouter.register_all遍历已注册 handlerbuild_default_rule_chain支持 stage + priority 插入presenter_registry动态化EventPipeline增加前后 hookConnectionPlanBuilder/ 配置 schema / WebAdmin 合并扩展配置使用场景
专业用户 / 地方监测需求
希望接入北京地震局、广西地震局等小众源，或主要关注 M3.0 以下事件；这些能力对大多数用户无价值，但应由社区扩展提供，而不是塞进主仓。
避免魔改分支
有开发能力的用户现在可能 fork 后硬改 parser/catalog；扩展系统落地后，可在主插件更新的同时，仅保留/升级自己需要的扩展包。
能力复用，而不仅是“加源”
同一套扩展机制后续可承载：
维护者减负
主仓只维护通用、稳定、高受众核心能力；长尾需求通过扩展生态消化，减少“帮我加一个只有我们单位用的源”类持续压力。
你希望该功能主要服务于哪个消息平台？
其他平台
其他平台名称（如选择“其他平台”请填写）
全平台（扩展系统位于插件内核层，与具体消息平台解耦；推送仍走现有 AstrBot 会话/适配器链路）
当前主要部署方式（可选）
不确定
补充说明（可选）
建议讨论并拍板的关键问题：
ProviderFamily开放策略：可注册字符串，还是 Enum + custom 兜底？event_id/ fingerprint /fusion_group？stage + priority是否作为默认模型？network/register_source/register_rule等粗权限是否足够？建议的分阶段路线（供参考）：
非目标（至少现阶段）：
欢迎对命名、MVP 范围、API 形状、目录布局、迁移策略提出意见。若方向收敛，可再拆：
extension.yaml字段 +ExtensionAPI清单 + 加载时序你愿意提交 PR 吗?
Code of Conduct