docs: add plugin system design proposal

[GuangchuangYu]

Summary

Adds the plugin system design proposal for Rho, closing the design discussion in #17.

Core decisions

• Operation-first: a plugin's primary unit is the operation; UI is derived from the schema, not hand-written.
• Declarative action: parameter schema + R code template, not native executable code.
• Seven parameter types: string / number / boolean / enum / file / dataframe / color.
• Global and project scopes with layered trust (global trusted / project untrusted).
• Plugins ship their own skills; they never discover external skills.
• Execution reuses the existing run/provenance pipeline, so "UI operation -> generated code -> reproducibility" is a mechanical guarantee.

Status: proposed; implementation not authorized. Each work package requires a separate focused handoff.

Closes #17 (design discussion).

[GuangchuangYu]

#17，我想到的插件系统，思考了一下，skills是给agent用的，带领域知识，影响agent怎么想的问题。

插件以一个zip打包，支持安装，里面包含json文件，R脚本/模版，skills（optional），以及其它一些可选的。

插件系统要回答的问题是不一样的，是怎么做的问题，所以是一个比较固定的界面化的东西，而界面不需要用户写，插件本质上是json文件来指定界面，Rho根据json文件来画UI，根据R脚本来执行。这个json即可以拿来画界面，也可以拿来给agent，让agent来自动化参数选择这些。同步可以给出完整代码，执行后，跟agent模式一样，进入run, output, review。

然后可以自带skills，让agent来干活的时候，什么样的情况，选什么样的参数，也就是agent怎么想，也可以在里面。

所以插件是一个可以让人干，也可以让agent干，确定性的怎么操作的东西。 skills管怎么想，插件管怎么做。确定性行为还是很重要。

然后我在一个项目里，我可以调用插件来做某件事，但我的项目，不是只有插件定义的行为就做完了。插件做完之后，我继续与AI互作，或者我自己继续做点别的，也就是插件在某个阶段来做某件事，之前之后，我都可以继续搞事。所以虽然插件要做的事情可以让AI干，但是插件中的AI只干插件要做的事情。边界立住，只做确定性行为。突破这些行为，再搞点别的，我还可以在这基础上继续干，不冲突。

[GuangchuangYu]

插件里的skills更小。插件比普通skills更具有确定性。这不比各种云平台好太多。外加以后支持远端服务器，操作在本地，计算在远程。

就是插件系统得Rho有用户基础，由社区来驱动开发才会繁荣。

[xiayh17]

Agent 生态的插件可以理解为一个专有软件，用于特定任务。创建插件本质上还是在写软件，除了针对性的场景和任务，还可能有配套的mcp、skills（包括调用插件的skills，和插件执行中调用的）、subagent.
以上是形式上的设想，第二就是为啥需要一个插件，如果说skills 提高了agent 的行为可控性，插件是直接把解决方案打包成一个现成的软件，agent只需要直接使用。
最直接的好处是agent不需要生成新的脚本，直接复用插件即可。就像人用软件一样。
···
举几个例子，

1. 远程服务器连接，如果用插件的方式实现，本质上就是一个ssh 客户端软件，有skills 引导Agent 使用这个软件，并且可以配套的有ui 帮助用户配置他的服务器信息，有skills 针对他的某个服务器限制规范如何使用。在这个例子中，插件的好处是规范了远程服务器的使用，agent 可以直接使用软件部分连接服务器，人可以直接使用软件部分设置凭据，ui 部分优化了交互体验，skills 部分会不对的积累agent和人在这个场景下的使用经验， 因为skills 的形式本质上是文档， 随时可以更新。
2. 服务器的例子过于通用，在Rho, 数据分析场景，更常用的插件可能是离不开数据分析。插件可以是数据的导入导出、针对特定数据类型的交互式可视化（地图\DNA\蛋白质、基因组）、特定非结构化信息的处理、 一些数据库的直接调用等， 借用已有的R 包。

[GuangchuangYu]

对的，形式上可以有你说的mcp, subagent这些，以及其它。思想上现在是统一的，就是确定性的操作。让人/AI用软件，做确定性的事情（出错的概率就很低了）。

[GuangchuangYu]

@xiayh17 可以把你对实现技术细节的想法，也合并写入。

[xiayh17]

Follow-up: two-phase plugin-runtime design

The runtime and authority aspects of this proposal have now been split into two independent, design-only Draft PRs for focused review:

• feat: build Phase 1 internal extension runtime #75 — Phase 1: Internal Plugins Only: freezes the internal capability graph, scopes, reversible effects, transactional activation/rollback, quiesce/dispose, and the trusted Broker boundary. No third-party or project executable code is in scope.
• feat: harden Phase 2 workspace plugin contracts #76 — Phase 2: Workspace Third-party Runtime: specifies project-level discovery, manifest/requested-capability semantics, permission grants, constrained handles, isolation candidates, contribution points, and adversarial boundaries.

Both branches start directly from the same upstream main@533ac12 commit and are Git-independent. Phase 2 product implementation is intentionally blocked on acceptance of Phase 1’s capability, scope, effect, and transport-safe facade contracts.

This comment does not alter PR #65’s proposed/unauthorized status, and none of the three design PRs adds product code, a marketplace, a dynamic executable plugin directory, public SDK, schema, version, or NEWS change.