admin
c1b5e4d966
- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次） - .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…）， 目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪 - .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/） - .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*） - .gitignore 补：备份件（*.bak-*） - 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）
224 lines
16 KiB
Markdown
224 lines
16 KiB
Markdown
# 基础服务插件 · 能做 / 不能做 总清单与拍板路径（2026-09-26）
|
||
|
||
> **本文 = 决策件（成品）**。逐模块明细 ⇒ `平台新增功能总盘点与插件化归属-20260926.md` §3–§8（⛔ 不复制）。
|
||
> 本文只做三件事：① 按**插件单元**重组"能做/不能做"（换一个切面）② 列清**不可做**及其判据 ③ 给出**拍板路径**（哪个决定决定哪个）。
|
||
> ⚠️ 本文的 ✅/❌ 全部沿用 §3–§16 的既有判定，⛔ 不新增结论；本棒的增量只有**重组 ＋ 拍板路径**。
|
||
|
||
---
|
||
|
||
## 0 一句话判定
|
||
|
||
- ✅ **能做**：平台新增里的**客户端侧能力**（约九成，按功能组计）⇒ 收进「**一个包、两个半**」，以后**随插件更新**，不必重发安装包。
|
||
- ❌ **不能做**：只有 **5 件**，全部发生在**「插件存在之前」**（引导层）。⛔ 不是"不做"，是"**只能放在那里**"。
|
||
- ⚠️ **范畴不同**：服务器侧自有服务**本来就不依赖 DSH** ⇒ **不算"不能进插件"**（算作候选是范畴错误）。
|
||
|
||
---
|
||
|
||
## 1 插件规划总览（四个层，只有第 3 层是"插件"）
|
||
|
||
| 层 | 是什么 | 改一次要重发安装包吗 |
|
||
|---|---|---|
|
||
| **L0 官方宿主** | 宿主进程 · 界面框架 · 插件机制与扩展点 · 技能加载 | ⛔ 不是我们的（R2 零改动） |
|
||
| **引导层** | 起实例 · 起窗口 · 取身份 · 把包装进去 · 原生网络守护 | 🔴 **要** —— 所以必须**冻结到最薄** |
|
||
| **插件（本文主角）** | 能力入口与界面，**全部落在官方已有槽位** | ✅ **不要** ← 规划的价值就在这一行 |
|
||
| **服务器侧自有服务** | 账号 · 多租户编排隔离 · 协作内核 · 中继 · 门户 · 运维 | ✅ 不要（跑在服务器上，不是客户端的事） |
|
||
|
||
> 🔑 **本规划的核心主张**：把"客户端里会变的东西"尽可能压进第 3 层 —— 于是**更新插件 = 更新客户端**，第 2 层（唯一要重发安装包的那层）就永远不动。
|
||
|
||
---
|
||
|
||
## 2 判据 —— 一条就够，自己也能判
|
||
|
||
> **这件事发生在「插件存在之前」还是「之后」？**
|
||
> **之前** ⇒ 引导层，⛔ 不可插件化；**之后** ⇒ ✅ 可插件化。
|
||
|
||
配套三条"为什么"（判据背后的机制，⛔ 记住就能自己推）：
|
||
|
||
| # | 为什么"之前"的事下不来 | 出处 |
|
||
|---|---|---|
|
||
| ① | **先有鸡还是先有蛋** —— "把包装进去"这个动作，⛔ 不能由**被装的那个包**来做 | §4 · §10-4 |
|
||
| ② | **画面要先出来** —— 渲染早于插件加载，窗口与首屏不可能由插件画 | §3 · §10-2 |
|
||
| ③ | **判决者唯一** —— 权威（谁托管谁、谁能进、谁是设备）**不能由被判决的一方自己选**；双写 = 脑裂 ⇒ 数据损坏 | §16.2 |
|
||
|
||
---
|
||
|
||
## 3 ✅ 能做 —— 全部收进「一个包、两个半」
|
||
|
||
**形态**：一个包，两个入口（先例＝本地代理包就是"一个自研包两个入口"）。
|
||
|
||
### 3.1 服务端半（平台能力的**统一出口**）
|
||
|
||
| 能力 | 说明 |
|
||
|---|---|
|
||
| 身份态与账号设置 | 登录**动作**不在这里，但**身份展示与设置**在这里 |
|
||
| 可用插件清单 / 启停 / 版本矩阵 / 定向钉版 | 管理界面 ＋ 调接口（装配**动作**在引导层，见 §4） |
|
||
| 插件数据面（一插件一库） | **本来就是给插件用的** ⇒ 天然属于本包 |
|
||
| 插件 SDK / 扩展点 / 回调桥 | 同上 —— **本身就是给插件用的** |
|
||
| 协作（房间 / 消息 / 发言规则）的**客户端侧** | 内核在服务器，客户端侧是插件 |
|
||
| 技能清单 / 共享模型授权态 / 网络与设备状态 | 全部为**展示 ＋ 申请入口** |
|
||
| 更新检查（问一句"我落后了吗"） | 拉取**动作**在引导层，见 §5-4 |
|
||
| 审计 / 日志 / 健康 | 展示 |
|
||
|
||
### 3.2 界面半（⛔ 不新造页面体系）
|
||
|
||
| 能力 | 落点 |
|
||
|---|---|
|
||
| 各能力的管理页／列表页 | **官方已有槽位**（设置 → 插件 / 能力管理 …）各一页 |
|
||
| 工作台 UI / 窄档响应式 | 插件本来就是干这个的 |
|
||
| 会话与工作区分组的列表与切换 | 存储在服务器，界面在插件 |
|
||
|
||
> ⇒ 用户那句「**基于这个插件可以去使用现有新增能力**」—— ✅ **成立**，而且这正是把这些能力**统一出口**的正确做法。
|
||
|
||
---
|
||
|
||
## 4 ❌ 不能做 —— 6 件（**同一条判据：都在"插件存在之前"**）
|
||
|
||
| # | 事情 | 归属 | 为什么（一句话） |
|
||
|---|---|---|---|
|
||
| 1 | **起实例**（把官方宿主进程跑起来） | 引导层 | 插件跑在实例里，实例不可能由插件起 |
|
||
| 2 | **起窗口 / 渲染首屏** | 引导层 | 画面早于插件加载 |
|
||
| 3 | **取身份**（登录 ＋ 设备授权） | 引导层 ＋ 服务器侧 | 要**先拿到身份**才能取到包（⇒ 身份是信任链起点） |
|
||
| 4 | **把包拉下来并装进去**（含版本管理与拉取器） | 引导层 | 判据① —— 装包的动作不能由被装的包做 |
|
||
| 5 | **原生网络守护**（拨号 / 中继 / 寻址 / 组密钥） | 引导层（原生进程） | 隧道必须**在界面之前**建好，且要原生权限 |
|
||
| 6 | **起承载服务（Manager / Worker 本体）** | 引导层（原生进程） | 它们要**系统级能力**（独立账号 / cgroup / 监听端口），而插件跑在实例里、权限是收窄的 |
|
||
|
||
⚠️ **计数沿革（如实记）**：§10 原记 **4** 件 → 本轮并入第 **5** 件（原生网络守护，原散在 §7）→ 再并入第 **6** 件（起承载服务，见 `五种角色选择场景-明确件-20260926.md` §2）。**总数 6**。
|
||
⚠️ 第 6 件的**口径辨析**：服务本体属**范畴不同**（本来就不依赖 DSH，见 §5），但**"把它起起来"这件事**需要系统级权限 ⇒ **属引导层**。两者不矛盾。
|
||
|
||
🔴 **这 6 件必须"冻结到最薄"**：它们是唯一"一变就要重发安装包"的部分 ⇒ 每加一点，就永久损失一点"插件更新即客户端更新"的收益。
|
||
|
||
---
|
||
|
||
## 5 ⚠️ 范畴不同 —— 服务器侧自有服务（⛔ 别算作插件的候选）
|
||
|
||
**多租户编排 / 沙箱隔离 / 用户卷 / 协作内核 / 中继 / 门户 / 运维（部署·回滚·备份·域名·证书）**
|
||
|
||
- 它们**不是"不能进插件"，而是"本来就不依赖 DSH"** —— 官方**没有账号体系**，所以这部分从第一天起就是**我们自己的独立进程**。
|
||
- 客户端在其中只能是**调用方**（插件里只做**入口与展示**）。
|
||
- 运维面（部署 / 回滚 / 备份）**根本不在客户端**。
|
||
|
||
⚠️ **一处不建议（可推翻）**：**门户六页（含登录页）不要搬进插件** —— 桌面线口径是「套壳 ＋ 同步服务器代码」「UI 与服务器版本一模一样」；插件里再实现一份 ⇒ **两份 UI 必然漂移**（负向迭代）。⇒ 门户**保持服务器页面**，插件只做**入口与内嵌**。
|
||
|
||
> ⚠️ **本组是此前"为什么不能"的最大误会来源**：把服务器提供的能力当成客户端功能，再看插件，就会得出"什么都做不了"。
|
||
|
||
---
|
||
|
||
## 6 拍板路径（**哪个决定决定哪个**）
|
||
|
||
```
|
||
┌─────────────────────────────────────────────┐
|
||
│ P1 插件规划走不走？（产品主路径 · 业务方向） │
|
||
└───────────────────────┬─────────────────────┘
|
||
┌───────────┴───────────┐
|
||
▼ ▼
|
||
┌───────────────────────┐ ┌──────────────────────────┐
|
||
│ P2 设备要不要有读包的权 │ │ P3 节点提供哪些具体服务 │
|
||
│ （权限面 · 决定安全要件）│ │ （业务方向 · 决定值不值得）│
|
||
└───────────┬───────────┘ └──────────────────────────┘
|
||
▼
|
||
┌─────────────────────────────────────────────┐
|
||
│ 自动结论：包签名校验（P2 给权 ⇒ 立即由"要件"升"必需"）│
|
||
└─────────────────────────────────────────────┘
|
||
```
|
||
|
||
**顺序不可颠倒**：P1 是"要不要这么规划"；P2/P3 是"规划里的两条支路"。⛔ 先答 P2/P3 会白答 —— 若 P1 走别的形态，这两条的前提就变了。
|
||
|
||
⚠️ **上图只覆盖"客户端形态"这一轴**。2026-09-26 09:4x 起新增 **P5（服务端形态：平台要不要做成用户可自建）**，**与 P1 并列但不同轴** ⇒ 见 §7-P5。
|
||
|
||
**本线已自决、⛔ 不必你拍（登记备查，可推翻）**：
|
||
|
||
| 项 | 自决结果 | 依据 |
|
||
|---|---|---|
|
||
| 引导层冻结到最薄 | ✅ 冻结（列 5 件为上限） | 判据：它一变就要重发安装包 |
|
||
| 门户搬不搬进插件 | ⛔ 不搬（保服务器页面） | 两份 UI 必漂移 ⇒ 负向迭代（R11） |
|
||
| 承载归属迁移（实例换机）**立不立项** | ⛔ **不立项**（登记为具名未设计项） | 候选**只有缺点**（不可逆级、需独立设计）⇒ 按判据自己拍掉 |
|
||
| 包签名校验**谁做/何时** | 由 **P2** 自动决定 | 给读取权 ⇒ 必需；不给 ⇒ 非阻塞 |
|
||
|
||
**不在本线拍板（指向他线，⛔ 本线不替代）**：
|
||
|
||
- **跨区可见性默认**（各区互不可见 vs 允许自由接入任意节点）⇒ 属**覆盖网络线**口径；本规划**触发**了它（§16.2-3），但不在此处定。
|
||
- **多 Manager（控制面联邦）治理口径** ⇒ 同属覆盖网络线架构定稿。
|
||
|
||
---
|
||
|
||
## 7 待拍板（按 §6 顺序，逐条编号 · 候选带优缺点）
|
||
|
||
### P1 —— 插件规划走不走？
|
||
|
||
**要你定的是**：以后客户端**"只装官方宿主 ＋ 装我们的插件"**，还是**继续保留我们自己那个壳**。
|
||
|
||
**为什么需要你定**：它决定"更新"这件事的成本结构 —— 走插件路线 ⇒ 以后改功能**不重发安装包**；保留自研壳 ⇒ 每次改客户端都要用户重装。这是产品形态，我定不了。
|
||
|
||
- **A 案｜只装官方宿主 ＋ 我们的插件**
|
||
优点：功能更新**不重发安装包**；我们的维护面收到一个包；界面上限受官方槽位约束反而稳定。
|
||
缺点：第一眼是**官方页面**、不是我们的门户；界面受官方槽位限制（⛔ 做不了官方没给的位置）；与官方版本升级绑定；引导层 5 件仍需自己维护并**冻结**。
|
||
- **B 案｜保留自研壳（现状为主）**
|
||
优点：界面与体验**完全自主**；可以做官方没给的页面结构。
|
||
缺点：**每次改客户端都要重发安装包**；壳的升级要自己维护；与官方宿主仍是两套东西。
|
||
|
||
**我的倾向**：**A 案，但引导层那 5 件按"最小原生守护 ＋ 半个宿主插件"来落地**（即形态上走 A，实现上不放弃既有壳的资产）。理由：只有 A 能让"九成功能随插件更新"这句话成立；B 案的代价是每次改界面都要用户重装，长期最贵。
|
||
|
||
### P2 —— 用户设备要不要获得「读取平台插件包」的权限？
|
||
|
||
**要你定的是**：让不让**用户设备**也能读平台上的插件包。
|
||
|
||
**为什么需要你定**：它决定"轻节点当内容副本 / 设备当消费者"这条路走不走得通；它会让设备能读到平台上的包，属**权限面变动**。
|
||
|
||
- **A 案｜给（只读、可撤销）**
|
||
优点：设备可当内容副本；断网时靠邻居；省跨区流量。
|
||
缺点：**多开一个读取口**，包来源面变大；**必须配套包签名校验**才安全。
|
||
- **B 案｜不给（维持现状）**
|
||
优点：**权限面零变化**，攻击面最小。
|
||
缺点："轻节点当副本 / 设备当消费者"**直接堵死**；以后要再开等于重走一遍权限评估。
|
||
|
||
**我的倾向**：**A 案**，前提是与**包签名校验绑在一起上线**。
|
||
|
||
### P3 —— 节点提供**哪些具体服务**？
|
||
|
||
**要你定的是**：当一台机器"成为节点"时，它对别人到底**提供什么**。
|
||
|
||
**为什么需要你定**：这决定"自选当节点"值不值得做、以及节点之间怎么分工。属业务目标，我定不了。
|
||
|
||
- **A 案｜先只提供"内容"**（插件与能力的来源）
|
||
优点：**已实测跑通**（106 → 47）；不新增权限面；范围最小、最快能用。
|
||
缺点：节点只是"下载源"，吸引力有限；用不上节点的算力。
|
||
- **B 案｜内容 ＋ 承载**（还能托管别人的实例）
|
||
优点：真正用上节点的机器资源；"当节点"有意义。
|
||
缺点：要**入向可达**（家用网络不一定满足）；要平台的放行与配额治理；离"迁移"议题很近，而迁移**未设计**。
|
||
|
||
**我的倾向**：**先 A 案**，把 B 案里"承载"部分挂在迁移机制之后（迁移未设计 ⇒ ⛔ 现在不做）。
|
||
|
||
### P4 —— 跨用户要不要打通？（2026-09-26 09:2x 新登记）
|
||
|
||
**要你定的是**：让不让**不同用户之间**的设备/实例直接连上（现状是**结构性不通**）。
|
||
|
||
**为什么需要你定**：现状每个用户**各一张网**，`u:A` 与 `u:B` 之间**在"能不能拨"那一步就走不到** ⇒ 跨用户协作**只能走平台（443）**。打通 = **扩大可见面**，属权限面决策。
|
||
|
||
- **A 案｜不打通（维持现状）**
|
||
优点：**隔离是结构性的**（⛔ 不靠一张可写错的清单）；跨用户协作一律过平台 ⇒ 可审计、可限流。
|
||
缺点：跨用户的数据交换**多一跳**、依赖平台在线；点对点能力用不上。
|
||
- **B 案｜打通（按需授权互联）**
|
||
优点：跨用户可直连，省中继流量、低延迟。
|
||
缺点：**可见面扩大**（要新增"谁能连谁"的授权面，而现状刻意没有它）；网维度从"结构性隔离"退化为"策略性隔离"；审计面变复杂。
|
||
|
||
**我的倾向**：**A 案**。理由：本规划的价值在"把能力收进插件、把隔离做成结构性的"，B 案会把已经做硬的隔离重新变软。⚠️ **本条排在 P1 之后** —— 若 P1 走"只装官方宿主 ＋ 插件"，跨用户协作**本来就该走平台**，P4 可能自动消失。
|
||
|
||
### P5 —— 平台要不要做成「用户可以自己搭一套」？（2026-09-26 09:4x 新登记）
|
||
|
||
⚠️ **与 P1 是不同轴**：**P1 = 客户端形态**；**P5 = 服务端形态**。⛔ **答了 P1 不等于答了 P5。**
|
||
|
||
**要你定的是**：允不允许用户在自己机器上**建自己的控制面**（即"装插件后选 Manager、多个 Manager 关联、其中一个升为根"这条路），也就是把平台从「一个我们的服务」变成「一份可被别人部署的东西」。
|
||
|
||
**为什么需要你定**：它决定后面全部工作量的方向 —— 走这条路，要**新做三件硬东西**（选主实现、多控制面权威关系、撤根机制）；不走，那些场景就只对我们自己那几台机器成立。
|
||
|
||
- **A 案｜做成可自建**
|
||
优点：平台变成可分发的东西，用户能自建自己的区（5 个角色场景全部成立）。
|
||
缺点：**要新做三件硬东西**（选主实现 / 多控制面权威关系 / **撤根机制**）；⚠️ **撤根机制缺失 ⇒ "升根"暂时不可逆**；运维面显著变复杂。
|
||
- **B 案｜维持单一控制面（只对我们自己的机器）**
|
||
优点：**零新增风险**，现有隔离与 fencing 口径原样成立。
|
||
缺点：**"用户自建 Manager / 多 Manager 网络 / 升根"三条不成立**，只剩"当 Worker"与"当客户端"可用。
|
||
|
||
**我的倾向**：**A 案，但分两步** —— 先只做「**多控制面共存**」所需的最小件（**选主**），把「**升格为根**」明确挂起到撤根机制有结论之后。理由：多控制面共存是这条形态里**唯一有独立价值、且不引入不可逆操作**的一步；升根在撤根机制缺失时**只有缺点**（按判据 ⇒ 自己拍掉）。
|
||
|
||
📂 **逐条判定与代码实测缺口** ⇒ `交付物/五种角色选择场景-明确件-20260926.md`（⛔ 不复制正文）。
|