开发者如何提交插件

萌卡 NT 官网的发布表单、审核系统和框架插件市场已经打通。开发者一次填写资料并提交审核；审核通过后，官网才会原子更新线上文章和市场目录。无需手写市场 JSON，也不需要再到投稿中心重复提交。

未登录时会先进入官网登录页。插件 ID 发布后不可更换；它同时关联官网文章、安装记录、权限快照和运行配置。

发布流程

这是一条完整流程，不再需要“先保存、进入 Halo 编辑器、返回列表后再次提交”。若提交失败，页面会保留错误原因；不会产生已上架但缺少权限或下载信息的半成品。

项目	填写要求
插件名称	官网文章和插件市场显示名称
插件 ID	稳定唯一标识，例如 `Bilibili-Utility-Suite`
插件版本	当前发布版本，例如 `1.5.0`
一句话介绍	插件市场卡片摘要
插件 Logo	PNG、JPG/JPEG 或 WebP，最大 5 MB；自动归一为 512×512
支持平台	仅 Windows、仅 Linux、Windows + Linux 或“其他”
下载地址	Windows x86_64、Linux x86_64、Linux ARM64 分别填写；识别后必须在候选附件中单选确认，三个目标允许选择同一个通用文件
更新日志地址	双平台插件的统一 GitHub/Gitee Releases 页面
接入模式	正向、反向或正向 + 反向 WebSocket
监听端口	快捷添加服务时预填；无固定端口填 `0`
内置 Web 后台	只有插件确实提供管理页面时才选择“支持”
调用 API	从当前框架 API 清单多选，支持搜索、快捷全选和清空
订阅事件	从标准事件清单多选，支持搜索、快捷全选和清空

标准事件名为：group_message、friend_message、group_event、friend_event、bot_offline。

官网以发布页选择结果生成“调用 API”和“订阅事件”审核快照。插件安装包不需要 mengka-plugin.json，即使安装包中存在同名文件，里面的 capabilities 也不参与授权判断，不能扩大或缩小官网审核通过的权限。

完整的托管运行、可选启动元数据、配置、生命周期和 HTTP 适配说明见插件托管与权限协议。所有公开 action 标准名见 API 总览。

Windows、Linux x86_64 和 Linux ARM64 应提供与目标平台匹配的可部署成品包。
安装包无需清单文件。框架会在解压后自动寻找可执行入口，并优先匹配插件 ID、bin 和 release 目录。
包内存在多个同等优先级入口时，框架会停止自动选择并提示开发者整理包结构，避免误启动其他工具。
需要自定义启动参数、工作目录、配置 Schema 或内置 Web 后台时，可以提供 mengka-plugin.json 作为可选运行描述文件；它只负责启动和管理元数据，不负责 API 或事件授权。
“其他”类型不会下载、解压或启动安装包。用户点击安装后直接进入正向/反向 WebSocket 服务添加流程，开发者仍需填写更新日志地址。

在“管理我的插件”中选择“发布更新”。表单会载入已上架资料，并优先从 GitHub/Gitee 最新 Release 读取版本、附件和 Markdown 更新日志。

提交审核后不能继续修改同一待审版本；这是为了保证审批人员看到的内容与最终发布内容完全一致。被驳回后可修正并再次提交。

单平台插件可填写直接压缩包或 Releases 页面。
双平台插件必须提供独立“更新日志地址”，作为版本号和日志的统一来源，避免偏向某个平台附件。
官网会为 Windows x86_64、Linux x86_64、Linux ARM64 分别识别候选附件并默认选择最匹配的文件。开发者必须在每组单选框中确认，也可以改选其他候选附件。
三组选择互不排斥；Shell、Java、Node.js 等真正跨平台或跨架构的成品包可以由 Windows 和两个 Linux 架构选择同一个文件。原生二进制仍应按平台和架构分别打包。
已上架插件的发行版信息会周期刷新；刷新只更新已批准插件，不会绕过审核扩大权限。
插件包必须是可部署成品，但不要求包含清单文件。自动识别支持 .zip、.tar、.tar.gz/.tgz、.tar.bz2/.tbz2、.tar.xz/.txz、.tar.zst/.tzst、.7z 和 .rar；不要把源码仓库首页当成安装包。