Pre-flight checks
Problem
我自己参考zettlr加了点学术写作（主要是插入引文、导出docx增强）相关的功能。
但是感觉应用环境太特化了，而且对其他package中的代码有很多小改动，不适合并入项目，所以希望能有个插件系统，把这个功能做成插件。
Proposed solution
就插入引文和pandoc增强功能论的话，需要向外暴露的API主要涉及侧边栏、设置、和编辑器（点击插入引文）以及AI（保护引文格式的prompt）。目前 Markra 已经是高度模块化的，各功能以独立的 package 组织，这种架构非常适合直接改造为插件系统。新的插件同样可以以 @markra/ 下的 package 形式注册。
一些供参考的设想：
总体思路：
把需要对外开放的接入点改为动态注册机制，并在此基础上暴露稳定的 API，供插件扩展。
如果认可这个方案，我可以提交侧边栏、设置、编辑器和AI这几部分的PR，这些都是实现引文功能插件化所需的改动。最终目标是将所有 引文功能 相关代码都放到 package/reference 目录下，并做到可插拔，不耦合其他package。
Product area
Other
Alternatives considered
No response
Additional context
No response
Pre-flight checks
Problem
我自己参考zettlr加了点学术写作（主要是插入引文、导出docx增强）相关的功能。
但是感觉应用环境太特化了，而且对其他package中的代码有很多小改动，不适合并入项目，所以希望能有个插件系统，把这个功能做成插件。
Proposed solution
就插入引文和pandoc增强功能论的话，需要向外暴露的API主要涉及侧边栏、设置、和编辑器（点击插入引文）以及AI（保护引文格式的prompt）。目前 Markra 已经是高度模块化的，各功能以独立的 package 组织，这种架构非常适合直接改造为插件系统。新的插件同样可以以 @markra/ 下的 package 形式注册。
一些供参考的设想：
将 MarkdownPaperSurface.tsx 中的静态 import 重构为动态注册表，开放外部 ProseMirror 插件接入。
将设置模块 SettingsShell.tsx 和 SettingsWindow.tsx 中硬编码的数组和 if/else 分支，替换为注册表加字典的动态配置，以便插件注册自己的设置页签。
总体思路：
把需要对外开放的接入点改为动态注册机制，并在此基础上暴露稳定的 API，供插件扩展。
如果认可这个方案，我可以提交侧边栏、设置、编辑器和AI这几部分的PR，这些都是实现引文功能插件化所需的改动。最终目标是将所有 引文功能 相关代码都放到 package/reference 目录下，并做到可插拔，不耦合其他package。
Product area
Other
Alternatives considered
No response
Additional context
No response