tt/ttstd-infinite-canvas
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(merge): 本地整合 - 保留主分支交互与样式并排除不安全用户删除

Browse Source
This commit is contained in:
ddCat committed 2026-09-07 23:02:34 +08:00
2 parents 58805e73a5 2247c7c1cf
commit 14adaa1e99
100 files changed
+4845 -865
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/content/docs/backend/backend-database.mdx
+8
View File
@@ -118,6 +118,14 @@ description: 影策后端核心持久化表与状态边界
| `channel_model_price_tiers` | 保存系统模型按规格匹配的上游 SKU 与价格 | 价格档与渠道模型同事务保存；未启用或未完成定价的规格不进入普通用户目录 |
| `logical_models` | 保存前台模型的公开名称、Logo、能力类型和归档状态 | 前台模型与系统渠道模型分别维护展示信息；供应线路通过 revision 和 route 关联；`code` 仅在 `archived_at IS NULL` 的活动记录中唯一，归档后可用同 code 重建目录项 |
图片分档尺寸保存在现有模型能力 JSON 的 `image.size.presets` 中，不新增表、列或 SQL 迁移。每项结构为 `{ tier, ratio, size, width, height }`，例如 `{ "tier": "1k", "ratio": "16:9", "size": "1824x1024", "width": 1824, "height": 1024 }`。
- `tier` 仅允许 `1k`、`2k`、`4k`，管理员分别配置各档支持的比例；新增比例自动计算像素，原有精确尺寸不被重算。
- 同档等价比例不能重复。比例须为正整数比且不超过 3:1；像素最长边不超过 3840，总像素为 655360–8294400，并与比例及 `size` 一致（允许 2.5% 比例取整误差）。这些档位是工作台预设，不保证上游返回完全相同的像素。
- `parameter=size` 的支持值与请求使用精确像素；`parameter=aspect_ratio` 使用比例，独立分辨率由协议质量值映射。未允许自定义且质量值对应明确档位时，保存默认配置和创建任务均校验已声明的“档位 × 比例”组合，不能借用其他档位的比例。
- `allowCustom` 只开放支持值之外的输入，不新增上游分辨率能力；比例协议未配置对应质量值时不开放该档位。模型声明的精确像素可不满足 16px 对齐；自定义像素仍须满足请求端的 16px 对齐及尺寸限制。
- 未声明 `presets` 时，界面从已有支持值推导候选；禁用尺寸参数时清除分档配置。发布与回滚均无需数据库迁移，但旧程序不识别分档组合约束，回滚前应核对相关模型配置。
## 插件管理
| 表 | 用途 | 关键边界 |
docs/content/docs/backend/meta.json
+1
View File
@@ -7,6 +7,7 @@
"code-map",
"backend-database",
"task-runtime-stability",
"newapi-channel-2",
"system-update",
"protocol-plugins",
"canvas-data-structure"
docs/content/docs/backend/newapi-channel-2.mdx
+51
View File
@@ -0,0 +1,51 @@
---
title: NewAPI Video Generations Channel 2
description: Channel 2 视频任务创建、轮询与上游任务同步延迟处理
---
# NewAPI Video Generations Channel 2
## 请求流程
声明式插件使用以下接口：
- 创建：`POST /v1/video/generations`
- 查询：`GET /v1/video/generations/{taskId}`
创建响应支持顶层 `id`、`task_id`、`taskId`，以及 `data.id`、`data.task_id`、`data.taskId`。当中转包装 ID 与真实上游任务 ID 同时存在时，按 `data.task_id`、`data.taskId`、顶层 `task_id`、顶层 `taskId`、`data.id`、顶层 `id` 的顺序解析，避免把中转内部记录 ID 用作上游查询 ID。宿主把解析出的值保存为 `provider_request_id`，后续查询始终使用该值，并对路径参数进行 URL 编码。
查询响应进入成功状态后，插件会从 `data.result_url`、`data.video_url`、`data.output_url`、`data.url`、`data.metadata.url` 以及对应的 `data.data.*` 嵌套字段读取视频地址，再回退到兼容的顶层结果字段。只返回成功状态而没有任何结果地址时，宿主仍按协议异常处理，不会创建空资源。
## 上游同步延迟
创建接口返回任务 ID 后，Channel 2 可能在数百毫秒到数秒内仍对查询接口返回结构化的 `400`：
```json
{"code":"task_not_exist","message":"task_not_exist"}
```
宿主只在同时满足以下条件时把该响应视为“任务状态尚未同步”：
1. 渠道接口类型精确为 `newapi-channel-2`；
2. 已经保存非空 Provider Task ID；
3. HTTP 状态为 `400`；
4. JSON 的 `code` 或 `message` 精确等于 `task_not_exist`。
不符合条件的 HTTP 错误、非 JSON 正文或其他错误码仍立即按失败语义处理。
## 轮询与延期
新任务首次查询前等待 `2` 秒；同步错误在同一次执行中按 `2` 秒、`3` 秒、`5` 秒、`5` 秒退避，最多短期查询 5 次。短期窗口耗尽后，Worker 不发送新的创建请求，也不切换渠道或退款，而是：
- 保持本地任务状态为 `running`；
- 保留原 `provider_request_id` 和计费状态；
- 释放当前租约并把 `next_poll_at` 延后 15 秒；
- 下一轮从已保存的 Provider Task ID 恢复，只发送查询请求。
`task_not_exist` 的跨轮次同步等待从本地任务首次开始执行起最多持续 5 分钟。超过该上限仍未得到有效任务状态时，Worker 将任务置为失败并释放活跃任务与计费预留，避免无效 Provider Task ID 永久占用用户任务名额。该限制只针对持续的 `task_not_exist`；查询接口已经返回正常 pending/running 状态后的长视频生成仍按视频任务超时和延期策略恢复。
因此，上游生成耗时 500 至 600 秒时，只要查询接口返回有效的处理中状态，本地会持续以低频查询等待完成，不会把正常排队误报为“模型服务拒绝了请求”。视频真正返回失败状态时，仍按供应商失败处理。
## 兼容边界
该容错只适用于 `newapi-channel-2` 视频任务。其他 NewAPI 接口、其他 Provider、缺少 Provider Task ID 的任务，以及真实参数错误不进入延期路径。
docs/content/docs/progress/pending-test.mdx
+93 -4
View File
@@ -5,6 +5,83 @@ description: 当前项目已实现功能的手工验证清单与未确认边界
# 待测试
## 创作页面附件缩略图
- 聊天消息与分镜简报附件的放大图标样式排除 `.cached-resource-image-shell`，避免缓存图片容器被误设为透明和绝对定位；悬停与键盘聚焦仍显示放大图标。
- [ ] 在真实创作会话中确认远端图片加载后无需悬停即可显示，移开鼠标后保持可见，点击可放大；同时确认分镜简报附件、本地图片和视频预览正常。
## MiniMax H3 分辨率能力与价格档
- 视频能力比较复用请求意图和价格档的分辨率别名归一规则，修复 MiniMax H3 供应线路配置 2K 价格档后，前台模型声明 2K 时误报「创作端参数超出供应线路能力：vquality」。内部价格档仍使用归一值，MiniMax 请求保持官方参数 `resolution: "2K"`。
- [x] 回归测试在修复前复现相同保存校验错误，修复后通过；相关能力匹配、线路覆盖和 MiniMax 专项测试通过。模拟 HTTP 请求验证 2K 与内部 1440p 均发送 2K，未声明的 4K 仍被拒绝，图片 quality 参数不受视频别名影响。
- [ ] 在实际 `/admin/channels` 配置 768P / 2K 价格档后，于 `/admin/models` 保存包含 2K 的模型能力，确认创作端可选并正确报价；未调用真实收费生成接口或部署服务。
## 对象存储优先发送媒体 URL
- 开启对象存储后，参考图、视频、音频发给上游时：协议支持 URL 就优先发对象存储签名链接；协议必须传文件字节时仍走 Base64 或 multipart。不会在上游失败后再自动重发一次生成。
- 强制 URL：NewAPI 系列、火山方舟视频、MiniMax 视频，以及声明需要公网媒体 URL 的插件协议。优先 URL：chat-completion、openai-response、claude-api、Grok 图片、火山方舟图片、xAI/Novita/Grok/Seedance 视频等。Gemini 图片、Gemini Veo、带蒙版的 OpenAI 图片编辑继续走字节。
- 本地资源在“优先 URL”协议下仍读成 Base64；对象存储资源签发失败、资源不存在或未就绪会直接报错，不会伪装成“不支持 URL”。存储桶不必公开读，使用短期签名链接即可。
- [x] 后端专项测试覆盖协议策略、OSS 强制 URL、本地强制 URL，以及 preferURL 时对象存储走签名 URL、本地回退 Base64。
- [ ] 用户浏览器验收：开启 OSS/COS/七牛/S3 后，图生图或视频参考素材应发对象存储 URL；Gemini 或蒙版编辑仍发文件字节。签名失败不能变成静默回退 Base64。
## 管理后台系统性能
- 管理后台「系统配置」新增独立「系统性能」页面，集中展示主机与 Go 进程、数据目录所在磁盘、系统/进程内存、数据库连接池与 Schema、PostgreSQL 统计、Redis 运行状态和运行时缓存 key 数量；连接地址、账号、密码、DSN 与 Redis URL 不返回前端。
- 页面提供 15 秒自动刷新、手动刷新、降级提示和紧凑 KPI。SQLite 环境明确隐藏 PostgreSQL 专属统计，Redis 未配置时显示单实例本地协调状态；macOS 无可靠系统可用内存时降级展示 Go 堆内存，避免把未知可用量误报为 100% 占用。
- 缓存维护仅接受 `runtime` scope，通过 Redis `SCAN + UNLINK` 清理请求频控、渠道失败/熔断和线路临时禁用四类白名单；保留活动并发租约、跨实例目录版本以及用户、任务、素材、模型配置和数据库数据，同时清理可重建的进程内读缓存并写入管理员审计。
- [x] 后端专项测试覆盖管理员权限、SQLite/无 Redis 状态、非法 scope 拒绝、本地缓存清理和审计写入；专项竞态测试、handler 路由注册、repository/service 和前端生产构建通过。Redis 白名单删除与保留边界的集成用例已实现，但本机无 `redis-server`，本轮自动跳过。
- [x] 浏览器 mock 已验证 PostgreSQL + Redis 完整态、SQLite + 本地协调降级态、桌面浅色与 390px 深色布局、无横向溢出，以及缓存清理二次确认文案；未调用真实清理接口。
- [ ] 在真实部署的 `/admin/settings/system-performance` 验证 PostgreSQL 统计、Redis 指标、自动刷新和 Redis 断连降级；仅在测试环境执行缓存清理，确认流量高峰期间不影响活动并发租约和业务数据。
## 图片组预览、连线菜单与尺寸设置
- 折叠图片组背板读取真实子图，排除当前主图、最多显示五张，并复用资源缓存与视口懒加载；未完成的子图保留占位背板。
- 连线创建菜单的说明与禁用原因可换行，菜单限制在视口宽高内并允许纵向滚动。隔离组件页已通过浏览器确认真实图片背板与长说明显示。
- 管理员固定展示 1K / 2K / 4K 三组，可选择或手动输入每档比例，等价比例归一去重；1K + 16:9 自动换算为 1824x1024，已有精确像素保持原值。未配置分档时，从已有尺寸按总像素推导档位（例如 1920x1080 为 2K）。
- 图片协议的尺寸参数独占首行，输出数量与可选参数移到下方；每个分辨率档位用横向比例卡片直接点选，额外比例通过输入框添加，默认输出也改为直接点选，不再使用比例下拉框。窄容器自动改为单列，视频协议布局保持不变。
- 后台未保存的新增模型表单已验证：比例选中/取消、32:18 等价去重、17:11 添加与像素展示、0:9 错误提示、默认输出切换、Enter 添加而非提交表单；1440px 桌面尺寸卡片独占整行，390px 明暗主题和长比例标签无横向溢出，焦点轮廓可见。验证后已取消表单、放弃测试修改并恢复原主题。截图工具未成功，本轮布局依据浏览器 DOM 几何测量与交互结果，视觉效果仍待人工确认。
- 画布、创作和短剧生产接入同一“分辨率 → 宽高比 → 像素展示”组件。用户端仅显示协议支持且已配置比例的档位：例如 2K 比例为空时隐藏 2K，允许自定义也不额外显示空档位；剩余按钮等宽填充。管理员仍保留三档配置入口。允许自定义时开放比例或像素输入，切档尽量保持比例；重新打开保留真实自定义尺寸展示，不将已隐藏档位的旧尺寸伪装成其他档位选中，也不自动改写尺寸。
- 空档位隐藏已在隔离组件页验证：仅配置 1K/4K 时无 2K 按钮，选择 4K 返回 3840x2160；仅一档时按钮铺满可用宽度，全空时隐藏分辨率标题和按钮，保留自动尺寸与自定义入口。未保存模型或发起生成，真实路由仍待人工复验。
- 比例请求配置 aspect_ratio；精确像素配置 size。独立分辨率字段由对应模型协议适配，仅比例不能保证输出像素。模型声明的精确像素预设不受自定义尺寸的 16 倍数对齐限制，保持原值发送，其余尺寸边界继续校验。
- 浏览器隔离组件页已确认：旧比例配置切 4K 实际交给请求转换函数的是 3840x2160；自定义 2:1 后切 2K 保持比例；0:9 显式报错且不改已选值；管理员输入 32:18 去重、17:11 自动计算并同步用户选项；Grok 禁用 4K。390px 视口内的 264px 面板在明暗主题下测得无横向溢出，含长比例标签。以上不等同于真实上游生成或三个路由的完整验收。
- 前端 29 项尺寸、协议及能力专项测试和生产构建通过，包含空档位隐藏、比例无下拉框、禁用状态与图片/视频布局隔离回归；此前后端尺寸预设、能力规格转换及图片任务相关测试通过，覆盖默认组合拒绝、跨档位比例拒绝及 JSON 往返，本轮纯 UI 改造未重跑后端。构建仍有既有的大分包与无效动态导入警告。
- [ ] 复验画布、创作、短剧真实路由中的模型切换、保存后重开、默认档位与比例组合、明暗主题和键盘交互；管理员真实保存由用户确认后执行。
- [ ] 用真实模型确认新增尺寸是否受上游支持、实际输出与计费档位是否一致；本次未修改已保存模型配置或执行收费生成。
## Issue #432 多角度编辑器
- 多角度编辑器改为居中 Modal，复用遮罩点击、Escape 和关闭按钮的取消行为，不再定位到节点底部或随节点拖拽卸载。
- #428、#429、#432 的定向源码回归检查与前端生产构建通过；浏览器访问现有服务停在登录页，未完成真实登录态交互验收。构建保留现有大分包和混合静动态导入警告。
- [ ] 人工复验不同缩放和明暗主题下的位置、遮罩与 Escape 关闭、重新打开重置参数、预设与角度拖动；本轮不执行收费生成。
## Issue #429 文本节点选中
- 普通文本和富文本预览恢复鼠标事件冒泡，单击进入节点选中和编辑面板流程；编辑中的输入框仍隔离拖拽和滚轮。
- [ ] 人工复验正文单击、标题拖拽、富文本、组合键多选、双击编辑和正文滚动。
## Issue #428 插件协议分类
- 分类筛选同时限制展示分区，避免音视频协议在音频筛选结果中重复展示；全部分类仍展示各自支持的能力分区。
- [ ] 人工复验 AutoDL 在音频、视频和全部分类中的展示，以及搜索、状态筛选和详情入口。
## 画布多图分组与展开动画
- 新生成的多图组默认收起；复制图片或替换节点生成多图时，结果也保留分组归属，可展开、收起和设置主图。
- 子图入场动画仅在主动展开图片组时触发；普通选择、拖动或重新进入视口不播放入场动画，快速切换展开与收起时清理上一轮动画状态。
- 22 项相关测试及前端生产构建通过，包含子图普通挂载、选中与展开/收起的组件渲染回归；浏览器已确认本地画布可加载，尚未复验截图中的多图场景。
- [ ] 人工确认多图生成后的堆叠预览、数量按钮展开/收起、子图点击与拖动、主图切换，以及保存后重新打开画布。已有画布保留用户保存的展开状态。
## PR #426 本地整合验收
- 保留主分支图片尺寸选择器、后台尺寸预设布局、插件分类筛选、文本节点单击编辑、多角度居中弹窗、附件缩略图、站点外观与系统性能页面；接入 PR 的 UI 组件族和创作会话交互。
- 创作结果添加到画布前继续校验全部结果均有归属明确的素材记录，避免部分结果尚未落库时只转交部分素材；测试同步到消息级结果组件。
- 本次不接入 PR 新增的用户彻底删除功能，移除其按钮、客户端调用、路由和级联实现，原有停用/启用及素材回收站功能保持不变。临时 SQLite 回归已复现原实现成功返回后残留镜头修订和素材展示记录；其资源物理清理、账务保留与事务边界需单独完善后再接入。
- 无新增数据库迁移，不运行开发服务、不操作真实用户数据、不推送远程或部署。
- [x] 前端生产构建、前端主测试及主分支交互/外观和剪辑专项测试通过；后端 `go test ./...` 全量通过。
- [ ] 浏览器验收：明暗主题下图片分辨率/比例、自定义尺寸、后台模型能力预设、插件分类、文本节点编辑、多角度弹窗、附件常显、创作历史与完整结果转交画布。
- [ ] 确认后台用户管理保留查看/编辑/启用/停用入口，不展示未完成的用户彻底删除功能；实际生成与剪辑链路由用户验证后再决定是否推送。
## UI 组件同角色迁移（P0，2026-09-06）
依据 `docs/plans/ui-kit-consumption-audit.md` 实施：主界面/后台同角色控件统一消费 `components/ui`，消除 antd 与 ui 双观感。变更范围：Tooltip 29 处、Switch 10 处、朴素单选 Select 12 处、Checkbox.Group 1 处迁移至 ui 族；同步清理 globals.css 中 3 段 antd Checkbox 死选择器。antd `Switch`/`Checkbox`/`Tooltip` 全库归零；Empty/Alert/Badge/状态 Tag 维持零。
@@ -130,6 +207,15 @@ description: 当前项目已实现功能的手工验证清单与未确认边界
- [x] PR #423 合并验证：前端完整测试脚本 1139 项通过、生产构建通过；后端邮件、任务摘要和图片计价专项通过。后端全量仍有 4 项既有失败（私网上游校验 2 项、视频恢复策略 2 项），已在未合并的 `main` 基线上复现；最后一轮另有资源清理测试 SQLite 表锁失败，该项在合并分支与基线单独复跑均通过。未为通过测试而放宽安全或恢复策略。
- [ ] 真实 SMTP 投递、浏览器刷新恢复和收费生成仍待人工验证。本次不触发外部邮件或收费请求。
## NewAPI Video Generations Channel 2 轮询恢复
- [x] 官方插件兼容从 `data.task_id` 和 `data.taskId` 读取上游任务 ID；Channel 2 创建成功后首次查询等待 2 秒，仅将结构化 `400 task_not_exist` 识别为上游同步延迟，并按 2 秒、3 秒、5 秒、5 秒退避复查同一任务。
- [x] 短期重试耗尽后，Worker 保留本地任务 `running`、原 `provider_request_id` 和计费状态，延后 15 秒继续查询；恢复过程不重复发送创建请求、不切换渠道，也不立即失败或退款。其他接口类型、HTTP 状态和错误码仍按原失败语义处理。
- [x] 合并补修为跨轮次 `task_not_exist` 增加 5 分钟总同步上限；超过上限进入明确失败态并释放任务与计费资源，正常 pending/running 长视频仍可跨执行窗口恢复。
- [x] Channel 2 终态响应兼容 `data.result_url`、`data.video_url`、`data.output_url`、`data.url`、`data.metadata.url` 及对应的 `data.data.*` 嵌套路径；API 调用日志在该接口下优先记录嵌套真实任务 ID。协议与日志富化专项回归测试通过。
- [ ] 使用真实 Channel 2 分别验证上游任务 ID 短暂不可见和生成耗时 500 至 600 秒的任务：本地不再提示“模型服务拒绝了请求”，创建请求只出现一次，后续始终查询同一 Provider Task ID，最终视频正常回写；真实参数错误仍应及时失败。
- [ ] 使用返回 `SUCCESS` 且视频地址位于 `data.result_url` 或 `data.data.video_url` 的真实任务，确认不再提示“声明式协议已完成但没有返回结果”，并在当前 OSS 配置下成功下载并持久化为本地资源。
## 编辑器（M2 命令状态机）
- [x] 命令协议黄金文件：`editor-commands` 8 个黄金 op（addClip/moveClip/trimClip/splitClip/removeClip/setClipProperty/addSubtitle/removeSubtitle）全量快照比对通过；未知 op、非法 payload 一律抛错（fail-closed）且输入不可变。
@@ -496,6 +582,13 @@ description: 当前项目已实现功能的手工验证清单与未确认边界
- [ ] 在画布中分别选择按次图片模型、按秒视频模型和前台逻辑模型，确认修改数量、时长、分辨率和参考素材后价格立即更新且与实际账单一致。
- [ ] 在浅色/深色主题及生成中、禁用状态下确认胶囊价格可读、圆形操作区清晰且不挤压模型与参数控件。
## 系统渠道模型批量删除
- [x] 管理员可勾选最多 100 个渠道模型并一次删除；任一模型仍被活动线路或进行中任务引用时整批拒绝，不产生部分删除。
- [x] 合并补修将兼容 `models_json` 的重建收进删除事务，并由 repository 在取得渠道写锁后读取当前启用模型；模型保存后的目录同步也复用同一锁定入口，避免并发管理员操作用事务外旧快照覆盖较新的模型目录。
- [x] 后端批量删除与引用拒绝专项测试、前端管理页回归测试和格式检查通过。
- [ ] 在 PostgreSQL 测试环境由两个管理员并发执行模型新增、启停和批量删除，确认 `channel_models` 与渠道 `models_json` 最终一致，删除失败时列表不发生部分变化。
## 系统渠道默认积分价格
- [x] 新建渠道模型默认使用“所有规格统一价格”，管理员只需填写一次积分；1K/2K/4K、画幅和生成方式差异定价收进可选的“按规格定价”。
@@ -1144,7 +1237,3 @@ v2（用户反馈首版难看后重做）：菜单改用 antd Dropdown（placeme
- [ ] 让 AI 回复含多行代码（如 markdown 围栏 ```ts```）：代码块顶部有语言标签 + 复制按钮，点复制后变「已复制」，粘贴内容正确（不含语言标记行）。
- [ ] 代码块圆角/边框/底色在明暗主题均可辨；长代码横向滚动不破版；流式输出中代码块容器稳定不跳动、复制按钮可用。
- [ ] 消息中的行内代码（如 `const x`）样式不受影响；画布 Agent 消息里的代码块同样获得新外壳。
docs/design/plugin-platform-and-marketplace-research.md
+314
View File
@@ -0,0 +1,314 @@
# 插件机制现状、对外回应与插件市场演进调研
> 状态：调研与建议，未实施；不是现有能力承诺。
> 基线：2026-09-06，本地工作区 HEAD `df94c3bd`。未修改运行时代码、部署、数据库或现有用户文件。
> 范围：影策内部的 Provider、应用/UI、编辑器与支付插件；不将 `plugins/yingce/` 的 Codex App 连接插件与影策自身扩展系统混为一谈。
## 1. 决策摘要
用户反馈**对应用/UI 插件大体成立，但不能泛化为所有插件都只是开关**。现在是三种成熟度并存：
1. **声明式 Provider 扩展已经成立**：在现有请求、响应与表达式能力内，新协议可以通过包安装，不必修改宿主源码。
2. **应用/UI 扩展主要仍是内置模块化**：清单、注册表与开关存在，但大量实现、路由、设置和节点渲染仍随主应用编译。外部 Web 包的校验合同不等于执行运行时。
3. **支付存在真正的包内程序执行**：RPC 加载链路已存在；但它是专用能力，不是通用后端扩展平台，其现有隔离方式也不足以直接承接开放市场的不可信程序。
因此，当前准确定位是：**“已有声明式插件能力和部分独立运行时，应用插件正在从内置模块化演进为外部可安装扩展。”**
建议优先投入：**外部应用插件最小闭环 → 外部作者试用 → 受控分发目录 → 开放市场 → 商业化**。不是先建设市场 UI，也不是把所有内置组件搬进名为 plugins 的目录。
### 真正插件化的判断标准
关键不是“不写代码”，而是**扩展代码由谁编写、在哪发布、是否必须改宿主**。
- 插件作者可以写代码；声明式配置也可以是真插件，不必刻意引入可执行代码。
- 针对宿主已经开放的能力，作者不应修改宿主源码、不应依赖私有 store/service、不应等待宿主重新编译发布。
- 宿主仍然需要维护稳定的扩展点与公共 API。全新系统能力、权限类型和核心数据语义可能需要宿主升级，不承诺“任意未来功能永远不改宿主”。
- “内部模块化”“独立发布安装”“安全隔离”“市场运营”是不同维度；安全隔离不足不等于没有扩展能力，但不能因此宣称可安全开放市场。
## 2. 仓库审计：哪些已经有，哪些没有
以下是本次读取或执行得到的事实；“未找到”只限定为本次检查的工作区与路径，不代表对其他分支、线上版本作结论。
| 面向用户的能力 | 当前证据 | 判断 |
| --- | --- | --- |
| 安装新模型协议 | `.yingce-plugin` 经校验、存储、加载为 `manifestAdapter`，进入运行时 registry | 现有 DSL 范围内是真扩展，不只是开关 |
| 工作流声明 | 统一 `contributes.workflows` 与 Provider 引用合同；另有 RunningHub/ComfyUI 专用状态及配置流程 | 有可扩展基础，但不能从清单推导所有工作流集成都已通用化 |
| 新应用/UI | builtin 静态导入；上传记录转为 `{ manifest, source }`，未构造外部代码实例 | 主要仍是宿主内置能力管理 |
| 新画布节点 | 节点注册表可接声明；通用 declarative 分支按 schema 展示数据 | 有基础声明式显示，不是任意交互组件运行时 |
| sandbox 节点 | 直接渲染“插件节点等待隔离运行时” | 已声明、未打通执行 |
| 编辑器插件 | UI 插槽注册存在；`editor-shell` 静态导入八个组件，以同一插件 ID 注册 | 是内部插槽化，不能据此声称八个独立外部插件已落地 |
| 应用启停与配置 | 后端按官方应用 ID 策略表分类；前端仍有 Eagle 等专用配置分支 | 用户“新增插件仍要改代码”的直接来源 |
| 支付 RPC | 从包提取 `backendEntry`，创建 `payment.NewRPCProvider` 并执行包内程序 | 已实现专用动态后端执行 |
| WASM | 清单允许声明；支付加载时明确返回“wasm 支付运行时尚未启用” | 合同预留，不是已支持运行时 |
| 完整市场 | 检查到本地包、安装接口、已安装 Provider catalog；未找到完整发布者提交/审核/发现/签名分发链路 | 插件中心不等于插件市场 |
### 2.1 包产物清点
只读取 ZIP 中的清单，未运行包内程序：
- `plugin-packages/*.yingce-plugin` 共 **80** 个文件，均可读取 `manifest.json`。
- **78** 个包含 Provider 贡献，未显式声明 backend/web runtime；现有加载路径按声明式处理。
- **2** 个包含支付贡献，声明 `runtime.backend=rpc`。
- **0** 个声明 Web `entry`。
- **1** 个包同时包含 workflow 贡献；贡献数量可重叠，不能与包数量相加。
这说明当前随仓库分发的样本集主要验证协议包与支付包，不能作为外部应用插件已可用的证据。数量仅是本地快照，不是线上安装量、用户数或市场规模。
### 2.2 关键证据定位
| 编号 | 文件 / 符号 | 支持的结论 |
| --- | --- | --- |
| E1 | `web/src/lib/plugins/builtin/index.ts:1–6` | Eagle、提示词优化、工作流、肖像排查、审美批改与 editor-shell 均静态导入 |
| E2 | `web/src/components/canvas/canvas-node-content.tsx:63–97`，`CanvasNodeContent` / `PluginCanvasNodeContent` | 肖像排查与审美批改专用渲染分支；sandbox 是占位提示；declarative 是基础数据展示 |
| E3 | `web/src/lib/plugins/builtin/editor/editor-shell.tsx:1–100` | 八个组件通过静态 import，在模块顶层注册到同一插件的插槽 |
| E4 | `web/src/pages/plugins/index.tsx:515` 附近及 `toRegisteredPlugin` | Eagle 专用设置；后端记录只转换为 manifest/source |
| E5 | `web/src/router.tsx:45,121` | Eagle 页面仍是宿主专用 import 和路由 |
| E6 | `backend/internal/service/plugin_management.go`，`officialApplicationPolicies` / `pluginManagement` | 应用类别与管理 scope 依赖宿主 ID 表；上传来源固定按系统级协议管理，未形成通用第三方应用分类 |
| E7 | `backend/internal/service/protocol_plugins.go`，`install` / `reload`；`backend/internal/protocol/manifest.go`，`LoadInstalledProviders` | 包安装与声明式 Provider 动态加载已存在 |
| E8 | `backend/internal/protocol/package.go`，`validatePluginPackageRuntime`；相邻 `package_test.go` | Web 入口存在性与路径校验已实现；相关测试只验证包合同 |
| E9 | `backend/internal/service/protocol_plugins.go:380–445`；`backend/internal/payment/rpc.go:75–145` | 支付专用程序加载；WASM 未启用；RPC 通过宿主子进程执行 |
| E10 | `web/src/lib/plugins/plugin-types.ts`，`RegisteredPlugin`；`web/src/services/plugin-host.ts`，`createPluginHostContext` | 声明了 activate/deactivate；当前 host context 主要封装 ai.text；未检索到通用生命周期调用调度器 |
| E11 | `backend/internal/service/protocol_registry.go`，`InstallPluginForAdmin` | 上传入口要求管理员、保护保留 ID 并写审计；不是任意用户当前均可上传程序 |
| E12 | `backend/internal/service/payment_plugin_lifecycle_test.go` | 已有未完成订单阻止升级等守卫，后续平台化不能丢掉这些业务约束 |
| E13 | `docs/adr/0005-editor-preset-plugin-architecture.md` | 既有 ADR 明确把外部安装/市场/沙箱放在后续，预设插件本身是原阶段边界 |
### 2.3 不应误判的地方
- `backend/internal/protocol/builtin.go` 确实还包含静态适配器，但**不能仅因文件存在，就断言已安装包在生产执行时全部委托给它**。本次看到 `reload` 使用 `LoadInstalledProviders(raw, nil)`；无 resolver 的 `host:` 会被拒绝，上传也禁止 `host:`。现有安装链路本身有真实声明式执行。
- 支付 RPC 已设超时、输出大小限制、精简环境变量、入口/平台校验和包摘要校验。这些是有效措施，但不是文件系统、网络、进程与租户资源隔离。
- 未运行真实第三方支付网关或模型上游；测试通过不代表所有随包协议都已做供应商联调。
## 3. 如何对用户回应
建议直接回应，不争论“插件”一词，也不把责任推给用户不会开发：
> 这条反馈我们认可，尤其是应用和界面类插件。目前部分插件仍是主程序内置能力的模块化管理，启停独立了，但新增能力仍需要修改主程序；我们之前没有把这个边界说明得足够清楚。
>
> 同时，模型协议类插件已经可以在现有声明式能力范围内通过安装包扩展，支付也有独立运行时，所以并不是所有插件都只是开关。
>
> 下一步我们会先补齐外部应用插件的 SDK、隔离运行环境和通用扩展入口。验收标准不是多几个插件卡片，而是第三方开发者不修改影策源码，也能开发、安装、运行和升级插件。这个闭环经过外部开发者验证后，再开放插件市场。
>
> 在这之前，我们会明确标注哪些是内置扩展、哪些支持外部安装、哪些运行时尚未支持，不把规划能力写成已实现能力。
不要承诺未经验证的交付日期、任意插件零成本运行，或“以后完全不用改宿主”。对外更有说服力的证据是**第三方独立开发与安装演示、可下载样例包、SDK 文档和兼容性测试**。
## 4. 外部体系对照：借鉴机制，不照搬技术名词
来源均为官方开发文档/官方仓库，见 §10。下表的“借鉴”是本报告建议，不是这些产品对影策的推荐。
| 体系 | 官方资料确认的机制 | 对影策的借鉴 / 限制 |
| --- | --- | --- |
| VS Code | Manifest contribution points 与扩展宿主分离；Node 和浏览器 Worker 有不同入口。[S1–S3] | 定义贡献点、版本化 API、按环境声明入口；不要让插件直接绑定主应用内部结构 |
| VS Code 安全与市场 | 桌面扩展宿主拥有与 VS Code 相同权限；市场另做扫描、签名验证和封禁。[S4] | **独立进程不自动等于安全沙箱**；市场信任与运行时隔离都要单独设计 |
| Figma | 插件逻辑运行于有限 JS 环境，UI 在 iframe；文档访问与浏览器 UI 通过消息连接。[S5] | 适合画布产品的“受控文档 API + 隔离 UI + 消息调用”模式，而非注入主 React 树 |
| Dify | 插件按能力扩展；daemon 管生命周期和不同运行环境；有 CLI 与包发布流程。[S6–S7] | 将模型、工具、工作流的插件执行与业务 API 进程解耦；复用影策已有任务/配额体系，不复制整套 Dify |
| Dify Marketplace | 发布流程含安装/打包验证、元数据与隐私材料检查、自动检查和人工审核。[S8] | 先建立发布和安装质量门槛，再谈搜索、推荐与规模增长 |
特别排除两个误区：
1. **Module Federation 或远程 import 是代码装载方式，不是安全边界。** 本报告不建议将未经审查的市场代码直接加载进主应用 React 上下文；可信内置模块可以保留高性能直连，但必须通过同样的公开业务合同，而不是继续增加私有捷径。
2. **Web Worker 不是“自动禁网的沙箱”。** Worker 可以发网络请求，且脚本响应的 CSP 有自己的边界；iframe 也不能简单加一个 sandbox 属性就视为完成隔离。[S9–S10]
## 5. 目标结构：一个包合同，多类贡献，分级运行
```text
本地包 / 官方预置包 / 受控目录 / 未来市场
│
安装校验与不可变版本仓库
│
Contribution Registry + 生命周期管理
│
权限代理（用户/项目/插件/版本/操作）
┌─────────┼───────────┐
声明式执行器 隔离 Web UI 专用后端插件运行服务
Provider/表单 iframe/RPC 受限任务执行，后续完善
└─────────┼───────────┘
稳定 Host API / 命令协议
│
画布、任务、资源、模型、权限、账务
```
统一的是**包身份、版本、贡献声明、权限授予与安装记录**，不是强迫所有插件使用一种语言或运行环境。一个包可以同时提供 Provider、面板和命令，不能重新拆成互不相通的多套市场。
### 5.1 宿主必须保留的责任
保留登录和归属校验、项目与画布存储、任务队列、资源访问、模型中转、配额和账务、撤销重做、基础 UI 插槽、权限代理、生命周期与审计。插件不得直连数据库、写内部 Zustand 状态、直接修改订单状态，或绕过任务/计费协议请求模型。
插件负责其业务算法、供应商适配、自己的 UI、配置 schema 与版本迁移。新增同类型插件不应再改路由表、供应商 switch、平台插件 ID 白名单或专用设置页。
### 5.2 首批公共 API：小而可用
以下是建议接口，不是现有可调用 API：
| 能力 | 第一批 API 方向 | 约束 |
| --- | --- | --- |
| 命令与界面 | 注册命令、打开插件面板、通用 `/plugins/:pluginId/*` 宿主页 | 仅支持已声明的贡献；快捷键冲突可见，路由不由任意字符串注入 |
| 画布 | 读选区/选中节点、提交受校验的命令批次 | 写入走撤销栈与 revision 校验；没有整份内部 store 暴露 |
| 模型与任务 | 调用宿主已配置的文本/生成能力、订阅进度、取消 | 按请求实时校验权限、归属、配额；插件不接收原始模型密钥 |
| 资源 | 读取获授权的资源引用、上传/导入结果 | 默认不是全素材库权限；大文件走受控资源通道，不反复拷贝 base64 |
| 配置与存储 | schema 设置表单、插件私有 KV、宿主保管的秘密引用 | 用户/工作区/插件作用域隔离；配置声明不是权限授予 |
先支持命令、面板和基础设置；素材源、复杂节点渲染、时间线细粒度工具在首个闭环后扩展。高频拖拽/播放不逐帧跨 iframe RPC：由宿主渲染基本节点/时间线，通过批量命令和事件快照交换数据。
### 5.3 Manifest 与 SDK
- 在现有 v1/v2 基础上梳理合同，不为宣传而先发 v3；仅在真实破坏性变更时升级主版本。
- 区分包版本、Manifest 格式版本、Host API 版本、插件数据 schema 版本。
- 增加宿主 API 兼容范围、目标运行环境、按需激活事件、网络域名及权限需求等合同；无法支持的必要 runtime 必须明确拒绝激活。
- 插件来源与信任由安装渠道和管理员策略确定；不能信任清单里作者自填的 `trusted`、`official` 或“自动授予权限”。
- 用共享 JSON Schema/协议定义生成或对照校验 TS 与 Go 合同，避免前端枚举不含 rpc、后端已经执行 rpc 这类漂移。
- SDK、打包工具与开发宿主必须能脱离主仓库使用；首期可放同一 monorepo，验收必须从独立目录完成，不能用目录位置冒充独立性。
建议工具目标：初始化模板、校验包、开发连接、合同测试、打包、发布。**本报告没有创建这些 CLI 或命令。**
### 5.4 生命周期必须是真的，而不是 toggle 字段
建议状态：`installed → validated → awaiting-grant → disabled/activating → active → stopping → disabled`，另有 `failed / quarantined / incompatible`。
- `activate(context)` 注册贡献并返回可释放句柄；失败时回滚本次所有注册，不能半激活。
- `deactivate()` 释放事件、定时器、面板、Worker、任务订阅；宿主在超时后强制终止实例。
- “安装成功”“用户已启用”“runtime 就绪”“某贡献可用”分开呈现，不能用统一 enabled 掩盖未支持 runtime。
- 升级先验证目标版本和新增权限，再切换；失败恢复旧版本引用。
- 运行中任务绑定插件版本与包摘要，升级不让旧任务半途换适配器。支付可先继续采用已有未完成订单阻止升级的保守策略。
- 卸载要做引用检查。画布中已有插件节点保留数据与不可用占位，不静默删除；代码回滚不意味着数据迁移自动可逆。
- 卸载与清除用户数据分开操作，后者明确授权。
- 多副本部署时，安装/升级要有共享的版本与授权真相源、并发互斥及实例间失效通知；不能只依赖当前进程锁和本地 JSON registry。小规模自部署可保留文件存储实现，但共享部署必须显式选择持久化与一致性方案；实施数据库变更时同步数据库专题与迁移方案。
### 5.5 安全边界：公开市场的发布前置条件
**Web 插件建议采用单独源的受限 iframe 与宿主消息桥。** 优先避免共享主站 Cookie 的部署方式；不向插件注入主站 token、内部 API 客户端或 store。[S5、S9]
- sandbox/CSP 组合限制脚本、外连、图片/媒体外传、嵌套框架、表单、导航、弹窗与动态代码装载。具体策略必须通过 PoC 验证，不能只设置 `connect-src` 就声称禁止外传。
- 对不透明 origin 的 frame，不能只按 origin 字符串辨识调用者；由宿主绑定 `event.source`、一次性握手及 MessagePort，再关联安装记录、用户、项目和版本。
- RPC 校验消息 schema、方法白名单、实例状态、实际授予权限、归属、revision、频率和大小；不能相信插件消息自填的 pluginId/userId。
- Worker 若用于计算，要独立约束网络、存储与 CPU/内存风险；不能将主站同源 Worker 直接等同于隔离。[S10]
**后端代码插件不能直接复制当前支付子进程模式后全面开放。** 建议首期仅批准受控作者和能力；后续建设独立低权限 runner，配置只读包、独立临时目录、资源/进程限制、按插件区分网络出口、超时杀进程组、无数据库与主服务秘密挂载。具体容器/WASM 隔离方案应以威胁建模和压测决定，不因更换语言就宣称安全。
API Key 由宿主保管。凡需代签名或供应商请求的能力，应通过受控凭据代理处理；无法避免向代码提供凭据的插件必须单独提高信任等级并明示风险。支付插件先维持严格审核，不作为开放市场试点。
## 6. 下一步迁移顺序与验收
下面是按依赖安排的阶段，**不是已确认排期**。前期由前端宿主与后端协议能力各一名工程师推进，配合测试/安全评审；先通过垂直验证再估全量工期。
| 阶段 | 交付内容 | 退出标准 |
| --- | --- | --- |
| P0：纠正边界 | 能力支持矩阵、runtime 不可用原因、贡献点与权限合同草案、更新既有预设插件 ADR 的演进边界 | 产品说明不把已上传等同于可执行；目标结构获确认 |
| P1：外部应用闭环 | 隔离 UI + RPC、通用命令/面板/设置、SDK 模板、真正生命周期、一个独立示例插件 | 未包含该插件的宿主构建可安装运行；宿主源码不变；卸载无残留 |
| P2：以迁移验证抽象 | 将提示词优化器迁出专用入口，随后验证一个陌生作者应用与声明式 Provider；逐步去掉 ID 专用设置和节点分支 | 每新增一个同类插件，宿主无专用改动；现有业务语义与权限不退化 |
| P3：受控目录 | 不可变包版本、发布者身份、签名验证、审核、兼容矩阵、升级回滚、封禁、诊断日志 | 至少有外部作者独立发布/维护的包，完整经历一次失败升级与恢复演练 |
| P4：公开市场 | 开发者提交与支持流程、搜索与分类、质量指标、分批自动更新、滥用举报与撤销 | 不可信插件隔离通过评审；安装、升级、卸载、事故处置形成闭环 |
| P5：商业化 | 再评估付费授权、订阅与用量定价、作者结算、退款/争议流程 | 先有真实使用和维护成本数据；模型调用费用与插件费用清晰分离 |
### P1 推荐样例：外部“选中文本优化”插件
使用新的测试插件 ID，在独立目录开发：
1. 安装包贡献一个命令和面板。
2. 用户主动打开，读取被授权的画布选区。
3. 通过宿主调用文本模型，接收流式结果并可取消。
4. 预览后提交画布命令，支持撤销。
5. 升级插件 UI/算法但不重新构建宿主。
6. 停用或卸载后，面板、命令和订阅全部释放，画布数据仍保留。
用测试宿主模型替身做 CI 合同测试；真实模型联调另外执行并记录，不能把模拟结果当作真实上游已通过。先不替换现有提示词优化器，待闭环通过再迁移，降低回归范围。
### 防止“再次做成配置开关”的验收门禁
- **宿主冻结**：记录一个不包含样例插件的前后端构建摘要；后续只安装新包，宿主摘要保持不变。
- **独立作者**：作者仅拿 SDK、文档和已构建宿主，不能引用 `web/src` 或后端内部 package。
- **无专用分支**：在宿主源码中搜索新插件 ID，无专用路由、配置 switch、节点分支；安装记录和通用测试数据不算硬编码。
- **陌生能力实现**：在已开放 API 范围内实现一项未预置的逻辑，而不是只换标题、图标或开关。
- **权限拒绝**：未授权、已撤权、跨用户、跨项目、伪造 pluginId、超额调用均失败，写路径不能静默降级。
- **失败隔离**：崩溃、死循环、超大消息和外连违规不破坏其他用户数据；资源耗尽测试纳入专门环境，不在生产试验。
- **完整生命周期**：安装、激活失败回滚、停用清理、升级失败恢复、卸载引用保留都有自动化测试。
## 7. 插件市场：先分发闭环，再市场规模
### 7.1 市场和宿主必须分工
市场负责发现、发布者身份、版本元数据、包分发、签名与撤销信息；影策实例负责信任策略、授权、安装、执行、业务数据和付费任务。用户的项目、素材、密钥不应为了浏览市场自动上传。
现有 `/plugins/catalog` 是可用 Provider 目录，不应原地承担所有市场责任。可以复用安装器和包格式，但发布/审核/版本仓库应有明确边界。
建议概念模型（不是本次数据库迁移）：
- Publisher：身份、命名空间、维护者与账号保护状态。
- Plugin / Release：包身份、不可变版本、摘要、目标平台、Host API 范围、权限、变更说明。
- Review / Attestation / Revocation：检查结果、人工审批、签名证明、撤销原因。
- Installation / Grant / RuntimeInstance：部署范围、用户启用、实际授权、运行实例；与发布者元数据分开。
- Entitlement：未来付费权益，不与版本签名、用户权限或执行凭据混为一谈。
### 7.2 发布到安装的最小流程
```text
作者提交包和材料
→ 路径/大小/依赖/秘密/兼容性检查
→ 隔离环境安装与合同测试
→ 按风险人工审核
→ 固化版本并签名
→ 进入目录
→ 实例管理员选择版本和授权范围
→ 下载并验证摘要、签名与撤销状态
→ 激活与健康检查
```
- 摘要只证明字节一致，签名只证明来源/完整性，两者都不能证明代码无恶意。
- 新增权限、网络域名、维护者重大变更或高风险能力的更新应重新审批，不能随自动更新静默提权。
- 同一发布版本不可覆盖；依赖锁定并校验供应链，首期限制插件互相依赖的复杂度。
- 市场下架、阻止新安装、禁止激活、撤销运行实例、删除用户数据是不同动作；不能用一个“删除”按钮混在一起。
- 市场暂时不可用时，已安装、校验通过的普通插件原则上仍可运行；撤销缓存和高风险插件的离线策略应明确，不把市场服务变成所有创作任务的单点故障。
- 自部署用户保留手工安装受信包/私有目录能力；用安全策略约束，而不是强制连接公共市场。
### 7.3 冷启动与商业化
先邀请少量外部作者，优先已有用户需求的提示词/模板、批量处理、素材导入和模型适配。目录初期采用人工审核即可，不急着建设推荐算法与复杂分成。
衡量“是否形成生态”的指标应是：**独立作者成功发布率、无需宿主改动的插件比例、安装激活成功率、故障与回滚率、用户持续使用率、作者维护响应**，不是插件卡片数量。门槛目标在试点后设定，不拿本次 80 个包当生态成绩。
付费市场至少区分插件授权费、模型上游费用、宿主资源成本、第三方服务订阅。先以使用数据验证价值和成本，再设计定价与结算；具体税务、支付合规和法律条款另行专业评估，本报告不作结论。
## 8. 风险与明确不做的事
- 不推倒现有 Provider DSL；先收敛通用协议，复杂转换有证据后再引入代码运行时，避免 DSL 无限膨胀成难维护的语言。
- 不把“八个内部组件”作为“八个第三方可装插件”的交付。
- 不立即把支付、权限、数据库或账务写接口开放给公共市场插件。
- 不使用 `eval`、主页面远程脚本注入或仅改名为 sandbox 的执行器来补 Web runtime。
- 不将模型协议、UI 插件、市场各做一套互不兼容的身份和生命周期。
- 不一次迁移全部内置功能；先用一个真实外部插件证明边界，再逐个清除专用依赖。
- 不用更多 helper、更多 Manifest 字段和更多启停按钮替代运行时、SDK 与治理能力。
## 9. 本次验证记录与边界
环境：Go `1.25.6 darwin/arm64`；仓库要求 Go `1.25.0`。未启动开发服务器，未调用真实模型/支付上游，未安装外部依赖。
在 `backend/` 执行的最小测试均通过：
```sh
go test ./internal/protocol -run 'Test(ParsePluginPackage|DeclarativeManifest|ManifestAgentMapsRequestAndResponse|ManifestMapsSynchronousTextResponse)' -count=1
go test ./internal/payment -run 'TestRPCProvider' -count=1
go test ./internal/service -run 'Test(ApplicationPluginUsesUserStateUnderPlatformAvailability|UploadedManifestCannotClaimUserActivationScope|ArtCritiqueIsUserToggleableApplication|PaymentPluginUpgradeBlockedByActiveOrders|PaymentPluginRemovalAllowedAfterOrdersFinish)$' -count=1
```
分别验证已有包合同/声明式映射、支付 RPC 合同/错误处理、应用启用策略/支付生命周期守卫。服务测试使用测试内存数据库或临时目录，没有迁移用户数据库。
这些结果**不覆盖**：外部 Web 插件浏览器运行、公开市场安全、全部供应商联调、真实支付成功率、线上安装状态、多实例并发安装一致性。没有把静态检索写成浏览器验证，也没有执行与本次调研无关的全量构建。
## 10. 外部一手资料
本次联网搜索工具没有返回可用正文，随后直接获取以下官方页面/仓库内容（HTTP 200）并核对相关段落；不是基于搜索摘要或第三方转载。失效页面与只有空壳内容的页面未作为证据。以下来源的总结限于本报告引用的机制，不代表对产品整体安全性的评级。
| 来源 | 标题 | 官方地址 |
| --- | --- | --- |
| S1 | VS Code — Extension Host | `https://code.visualstudio.com/api/advanced-topics/extension-host` |
| S2 | VS Code — Contribution Points | `https://code.visualstudio.com/api/references/contribution-points` |
| S3 | VS Code — Web Extensions | `https://code.visualstudio.com/api/extension-guides/web-extensions` |
| S4 | VS Code — Extension Runtime Security | `https://code.visualstudio.com/docs/configure/extensions/extension-runtime-security` |
| S5 | Figma — How Plugins Run | `https://developers.figma.com/docs/plugins/how-plugins-run/` |
| S6 | Dify — Dify Plugin | `https://docs.dify.ai/en/develop-plugin/getting-started/getting-started-dify-plugin` |
| S7 | Dify Plugin Daemon — README | `https://raw.githubusercontent.com/langgenius/dify-plugin-daemon/main/README.md` |
| S8 | Dify — Publish to Dify Marketplace | `https://docs.dify.ai/en/develop-plugin/publishing/marketplace-listing/release-to-dify-marketplace` |
| S9 | MDN — iframe element | `https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe` |
| S10 | MDN — Using Web Workers | `https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers` |
**最终建议：批准 P0/P1 的范围与验收标准，先交付一个主程序完全不认识、但能通过公共 SDK 正常运行的外部应用插件。用这个事实回应用户，再建设市场。**
docs/index.md
+2
View File
@@ -4,6 +4,8 @@
## 设计沉淀
- [插件平台与市场演进调研](design/plugin-platform-and-marketplace-research.md)：插件机制代码审计、对外回应、外部 SDK 与隔离运行时、独立插件验收、受控目录到公开市场的分阶段方案（调研建议，未实施）。
- [站点及外观与皮肤主题设计合同](design/site-appearance-and-skins.mdx)：品牌一致性、登录页与邮件、SEO/备案、三层皮肤令牌、无闪屏启动顺序和验收边界。
- [工作区外壳设计沉淀](design/workspace-shell-design.mdx)：侧栏（260px 可折叠导航 + 分组折叠）、主区卡片、顶部栏（账户/公告/主题）的设计决策与样式约束。