Lite 规模、故障域与隔离决策
状态：已定（2026-09-29 文档化）。本文记录 WS-G1（Lite 规模与是否拆容器） 与 WS-G5（Renderer 隔离） 的结论，供部署文档与用户文档引用。 历史镜像层证据见已归档调研 §6–§9，未实施形态见已归档子计划。历史评估已归档至
docs/archive/architecture-2026-09/；最新复核与待验证事项见发布检查与待验证事项及归档索引。本文保留既有决策，下文发布形态描述需结合对应版本阅读，不能等同于当前 HEAD 的交付形态。
1. 推荐规模（H2a，产品目标）
| 项 | 口径 |
|---|---|
| 团队规模 | 5–10 人小团队 |
| 预览并发 | 约 3 |
| 项目形态 | 常规演示文稿工作区，非海量资产库 |
| 部署形态 | SQLite 单容器 Lite（llmxpm/web-presentation:sqlite-lite） |
硬口径：容量验收（D2）前，上述数字是目标规模，不是 SLA / 硬承诺。 D2（Lite 2C4G 空闲 + 混合负载写路径与 RSS/OOM 基线）尚未采集；在 D2 通过并回填文档之前，不得把 5–10 人 / 并发 3 写成性能承诺或容量保证。D2 通过后若实测低于目标，以实测为准修订本文，而不是维持名义数字。
2. Lite 故障域
SQLite 轻量版把 Backend + Runtime + Renderer（内置 Chromium）+ Nginx（Gateway）四个长期进程放在同一个容器 / 合并故障域内，由 tini 作为 PID 1 负责信号转发与 Chromium 孤儿子进程回收：
| 事件 | 影响 | 不影响 |
|---|---|---|
| 容器或宿主重启、进程被杀 | 预览缓存、构建临时运行态、内存锁与短生命周期任务状态丢失；进行中的 AI Run 会中断且不自动续跑（Run 产品承诺「会丢」） | 用户、工作空间、项目、页面、资源、组件、主题、样式等业务数据（SQLite / lite-data 卷内）不丢 |
| 单个内部进程异常退出（含 Renderer/浏览器） | 入口监督（PID 监督 + tini）语义下整容器退出，自动回收孤儿子进程，需容器重启恢复 | 同上；恢复后重新打开预览或重新触发构建即可 |
运维含义：Lite 的可用性边界是「单容器」，备份只需完整备份 lite-data 数据卷；不要按多服务拓扑假设可以只重启其中一个角色。
3. G1 决策：本轮不拆容器
决策：保持 Lite 单容器形态，本轮不拆分 Backend / Runtime / Nginx / 渲染为多容器。
| 理由 | 说明 |
|---|---|
| NAS 图形界面只能表达单容器 | 群晖 Container Manager / 飞牛 fnOS 等图形化路径无法可靠表达 Docker secret 文件与多容器编排；拆容器会把 Lite 主用户路径挡在门外 |
| 体积不是代价 | 约束来自编排复杂度而非镜像体积；自带浏览器形态与拆分形态的体积差在可接受区间（内部调研 §3 / §9） |
| 进程边界仍然成立 | Backend venv 仍无 Playwright，浏览器由独立 Renderer 进程持有（config.py fail-closed 校验守的是进程/依赖层）；单容器不等于「Backend 跑浏览器」 |
复审触发（任一满足再议拆容器）：Lite 面向多用户且渲染不可信页面代码；或合并故障域实测无法满足目标规模；或 NAS 主路径不再依赖图形界面单容器表达。复审时同步对照内部调研 §7.3 的三个层级（进程/依赖、镜像/交付、容器/隔离），避免把「合并镜像」误判为推翻控制面/执行面边界。
4. WS-G5 决策：Renderer 隔离 = 风险接受 + 分层说明
二选一结论：接受风险并分层说明隔离手段；不把「容器级隔离」作为 Lite 的前置。（容器级隔离与 Lite 单镜像形态冲突；见内部调研 §7.3。）
4.1 现状（如实描述）
- Renderer 与 Backend 处于同一 compose 网络（
platform-net），浏览器进程可触达 Backend 内网 API；现有page.route拦截只覆盖 Renderer 自身控制面路径（/internal/render/），不覆盖 Backend/api/v1。 - 控制 API 本身有服务身份凭证与 fail-closed 校验；泄漏面主要是「渲染用户/生成页面时的浏览器与 Backend 同信任域」，不是「任何人可调 Renderer 控制面」。
4.2 分层决策
| 部署形态 | 决策 | 说明 |
|---|---|---|
生产角色部署（compose.runtime-roles.yml 等） | 继续用网络隔离手段 | runtime-build / runtime-check 只挂 runtime-jobs-net、不进 platform-net；渲染 Worker 凭证与平台密钥分离（Docker secret / 独立 env）；需要时把 Renderer 挂独立网络并只放行 Backend 受信控制端口 |
| Lite 单容器 | 已接受的同容器风险 | 单容器下浏览器与 Backend 同文件系统/网络命名空间；在「自用 / 小团队内部」威胁模型下接受。多用户、低权限成员代码渲染场景必须再升级隔离（独立容器或非 root + 只读挂载），届时重开本决策 |
4.3 承诺边界（必须随文档对外保留）
本决策不是默认多副本 / 多租户安全。
在跨副本演练与多租户隔离升级完成前，不得将 Renderer 与 Backend 的同网/同容器形态描述为「生产级多租户隔离」；多副本拓扑也不因本决策而获得安全背书。
5. 文档与实现同步要求
- 用户侧规模与故障域描述以本文为准，保持「D2 前不是 SLA」原句。
- 部署文档引用本文的 G1 / G5 结论时，不得改写成「已具备多租户隔离」或「必须拆容器」。
- 镜像形态若按专项计划变更（Lite 内含 Renderer 进程等），须更新本文 §2–§4 并在发布说明中写清故障域是否变化。