feat(cloud): harden multi-tenant runtime resources

docs/multi-tenant/cloud-runtime-soak-gate.md

@@ -0,0 +1,106 @@
+# LangBot Cloud 24 小时资源 Soak 门禁
+
+`scripts/cloud_runtime_soak.py` 是生产候选拓扑的最终资源稳定性门禁。它不替代单元测试、历史 churn 探针或 nsjail 隔离测试；它把以下三类证据按同一时间轴采集并给出可机读的 pass/fail：
+
+- Core、Plugin Runtime 和 Box Runtime 的 HTTP liveness/readiness。
+- 三个 Python 进程的 event-loop recent max/p95 调度延迟。
+- Linux `/proc` 进程树的 current RSS、累计 CPU、线程、文件描述符和子进程数。
+- cgroup v2 的 `memory.current/peak/events`、swap、CPU usage/throttling、PID current/events 和实际硬限制。
+
+生产批准必须使用 cgroup 证据。`--pid` 只适合本地诊断，因为进程指标无法证明 OOM kill、PID limit 或 CPU throttling。
+
+## 运行位置
+
+建议把采集器放在独立的 node agent 或监控 sidecar 中，并只读挂载三个目标容器的 cgroup 路径。不要把采集器和样本文件放进被测容器自己的 cgroup/数据卷，否则采集器的 CPU、内存和 page cache 会污染目标数据。
+
+Kubernetes/containerd 生成的 cgroup 路径不是稳定 API。每次生产候选部署都必须从实际 pod/container ID 解析，不能从 pod 名猜路径。传入的每个目录都必须至少可读：
+
+- `memory.current`、`memory.events`
+- `cpu.stat`、`cpu.max`
+- `pids.current`、`pids.events`
+
+最终门禁应加 `--require-hard-limits`。该选项要求每个目标 cgroup 都能观察到有限的 CPU quota、memory、swap 和 PID 上限；任一值为 `max` 都失败。
+
+## 标准 24 小时命令
+
+```bash
+uv run python scripts/cloud_runtime_soak.py \
+  --duration 24h \
+  --startup-grace 5m \
+  --sample-interval 15s \
+  --cooldown 30m \
+  --analysis-window 30m \
+  --http-timeout 5s \
+  --max-memory-growth-mib 64 \
+  --max-memory-slope-mib-per-hour 32 \
+  --max-tail-cpu-cores 0.5 \
+  --max-throttled-period-ratio 0.25 \
+  --max-event-loop-lag-ms 1000 \
+  --max-event-loop-p95-lag-ms 250 \
+  --require-hard-limits \
+  --endpoint core=http://langbot:5300/healthz \
+  --endpoint plugin=http://langbot-plugin-runtime:5400/healthz \
+  --endpoint box=http://langbot-box:5410/readyz \
+  --cgroup core=/host-cgroup/CURRENT_CORE_CONTAINER \
+  --cgroup plugin=/host-cgroup/CURRENT_PLUGIN_RUNTIME_CONTAINER \
+  --cgroup box=/host-cgroup/CURRENT_BOX_RUNTIME_CONTAINER \
+  --samples-file artifacts/cloud-soak-samples.jsonl \
+  --report-file artifacts/cloud-soak-report.json \
+  --workload uv run python tests/load/cloud_candidate_workload.py
+```
+
+`--duration` 是包含启动观察、负载和冷却期的最大墙钟时间。工作负载必须在截止时间前退出并至少留出 30 分钟冷却；否则门禁会终止负载并失败。若负载由外部系统控制，可以省略 `--workload`，但必须保证最后 `--analysis-window` 完全无测试流量，该窗口才可解释为空闲尾段。
+
+工作负载命令的 stdout/stderr 会转发到采集器 stderr，不会混入 stdout 的最终 JSON 报告。命令以独立 process group 启动；超时或中断时整组收到 TERM，10 秒后仍未退出则收到 KILL。
+
+凭据只能通过 workload 进程环境或 secret mount 注入，不能放在命令参数中。最终报告只记录可执行文件名和参数个数，不保存参数正文；采集器也拒绝带 userinfo、query 或 fragment 的健康 URL。
+
+## 必须覆盖的负载
+
+同一候选版本至少要覆盖：
+
+1. 大批 Workspace 注册、成员邀请、登录和 entitlement 刷新。
+2. Plugin installation reconcile、依赖准备、正常调用、进程崩溃与重启。
+3. Dashboard/Embed/平台 WebSocket 建连、突发消息和批量断连。
+4. Box session、文件同步、并发 exec、managed-process 输出和清理。
+5. PostgreSQL pool 接近容量、事务超时和恢复。
+6. Core、Plugin Runtime、Box 分别收到 SIGTERM 后的优雅重启。
+
+工作负载不能把 API 过载拒绝当作成功吞掉。默认情况下，Core health 中 blocking executor 的 global/scope rejection counter 只要增长，门禁即失败；只有专门验证“过载会正确返回 429”的独立测试才可以使用 `--allow-rejections`，该次运行不能作为生产批准证据。
+
+## 判定规则
+
+整个有效观察期内出现以下任一情况即失败：
+
+- 健康接口请求失败、非 2xx、Core `code != 0`，或 Box `ready=false`。
+- `memory.events.high/max/oom/oom_kill/oom_group_kill` 增长。
+- `pids.events.max` 增长。
+- cgroup 单调计数器回退，表示目标很可能发生了未记录的重启或 cgroup 替换。
+- CPU throttled-period ratio 超过配置阈值。
+- 任一健康采样窗口的 event-loop recent max 超过 1 秒，或冷却尾段 recent p95 超过 250 ms。
+- 健康接口缺少 event-loop monitor、monitor 未持续运行，或其 sample counter 回退。
+- blocking executor rejection counter 增长。
+
+负载结束后的冷却尾段还必须满足：
+
+- `memory.current`/RSS 的稳健首尾增长和线性斜率不能同时超过阈值。
+- 平均 CPU 核数不超过 `--max-tail-cpu-cores`。
+- event-loop recent p95 不超过 `--max-event-loop-p95-lag-ms`。
+- blocking executor `pending` 至少回到过零；不能整个尾段持续积压。
+- telemetry、QueryPool、MCP host/dispatch、Box creating/closing/background 等临时 gauge 不能继续增长。
+
+内存判定要求“增长量”和“斜率”同时越界，避免几 MiB allocator/page-cache 噪声在短窗口被外推成很大的每小时斜率。最终报告仍保留实际增长与斜率，人工审查时不能只看 verdict。
+
+## 产物与退出码
+
+- `--samples-file`：逐样本 JSONL，写入后立即 flush，供时序图和故障定位。
+- `--report-file`：最终汇总、阈值、资源硬限制、OOM/PID/throttle delta、尾段斜率和 workload 状态。
+- stdout：与 report 文件相同的最终 JSON；workload 日志只写 stderr。
+
+退出码：
+
+- `0`：全部门禁通过。
+- `1`：采样完成但资源门禁失败。
+- `2`：CLI 参数或目标配置错误。
+
+必须保存原始 JSONL、最终报告、三个镜像 digest、LangBot/SDK commit、生产配置摘要和工作负载版本。滚动更新、节点迁移或镜像变化后，旧报告不能继续作为新候选版本的批准证据。

docs/multi-tenant/cloud-v2-pending-verification.md

@@ -0,0 +1,212 @@
+# Cloud v2 仍待验证事项
+
+状态：`NOT APPROVED FOR SAAS ACTIVATION`
+
+更新日期：2026-07-29
+
+本文是 Cloud v2 首期上线前的剩余验证清单。它只记录尚不能由当前代码审查、
+单元测试、集成测试、合成容量探针或短时 Linux 容器实验替代的证据。
+
+相关文档：
+
+- [多租户架构决策](./pending-architecture-decisions.md)
+- [实现决策记录](./implementation-decisions.md)
+- [Runtime 资源安全审查](./runtime-resource-audit-2026-07-28.md)
+- [24 小时资源 Soak 门禁](./cloud-runtime-soak-gate.md)
+
+## 1. 当前已形成的交付基线
+
+- LangBot Core 和 Plugin SDK 的全量测试、Ruff、`git diff --check` 已通过。
+- Plugin Runtime 和 Box Runtime 的公开健康接口、event-loop lag 与有界
+  blocking executor 指标已经过真实进程短时验证。
+- 仓库 Dockerfile 构建的 Linux/cgroup v2 短时探针已证明 CPU、memory、
+  swap 和 PID 限制代码路径可工作。
+- PostgreSQL 16 + RLS 的 1,000 Workspace 真实启动测试，以及 5,000
+  Workspace 三代替换合成探针已通过。
+- Core 已精确钉住 Plugin SDK 提交
+  `67be7c332ded4c1afa131b28232590cf9728f817`。最终验证必须使用包含该提交的
+  Core、Plugin Runtime 和 Box Runtime 镜像，不能混用旧 SDK。
+
+以上结果是进入生产候选验证的前提，不是 SaaS 上线批准。
+
+## 2. 尚有实现前置条件的阻断项
+
+以下项目不是“再跑一次测试”即可关闭。必须先完成实现，再执行对应验收。
+
+| 编号 | 阻断项 | 完成实现后的最低验收证据 |
+| --- | --- | --- |
+| B-01 | Plugin Runtime 缺少跨 installation 的重启风暴抑制，包括 jitter、全局重启并发上限和 Runtime 级 circuit breaker | 同时使大量 worker 因系统性故障退出，证明重启速率和并发受限、控制面仍可用，且单个故障 installation 不拖垮其他租户 |
+| B-02 | Cloud 插件缺少生产 egress policy | 证明插件只能访问允许的公网目标，不能访问 Core/Box/数据库、其他内部服务、loopback、link-local 或云 metadata endpoint |
+| B-03 | Plugin installation 与 Box Workspace/Skill/root/tmp/home 缺少真实的 byte 和 inode 硬配额 provider | 在写入边界原子拒绝超额；并发写入、重启和配额耗尽后不能越界，也不能用目录扫描或事后清理冒充硬配额 |
+| B-04 | 普通业务写入尚未具备贯穿 commit 的 generation-aware fence、同事务 business outbox，以及 generation cutover 后稳定的 durable-object 引用 | 在旧 generation 与新 generation 并发、事务提交竞态和重复投递下，旧 owner 不产生业务写入或外部副作用，outbox 可幂等恢复 |
+
+任一 B 类项目未关闭时，不得把 24 小时 soak 的通过结果解释为可以上线。
+
+## 3. 最终部署环境验证
+
+### V-01：Plugin Runtime 与 Box 的 Linux 隔离
+
+必须在最终 Cloud Pod security context、容器 runtime 和 cgroup 拓扑中验证，
+不能使用开发机或权限不同的一次性容器替代。
+
+验证内容：
+
+1. nsjail 可以建立 mount、PID、IPC、UTS namespace 和 private `/proc`。
+2. delegated cgroup v2 对每个插件进程和 sandbox 强制 CPU、memory、
+   `memory.swap.max=0` 和 PID 上限。
+3. open files、process 和单文件大小 rlimit 生效。
+4. 插件不能枚举、读取或 signal Runtime 及其他 installation 的进程，
+   不能读取其他 installation 的 home/tmp/data，也不能修改共享只读
+   artifact/environment。
+5. 超额只杀死或拒绝当前 installation/sandbox；Runtime、其他租户和健康接口
+   继续工作。
+6. 进程退出、取消、超时、generation 切换和 Pod SIGTERM 后，cgroup、nsjail
+   目录、子进程和文件描述符均被回收。
+7. 硬限制或 namespace 能力缺失时 readiness 失败关闭，不允许降级成普通进程。
+
+通过证据必须包含实际容器安全配置、cgroup 文件值、探针原始输出和失败注入结果。
+
+### V-02：Box 持久卷与硬存储配额
+
+在 B-03 的 quota provider 实现后，必须验证：
+
+1. Core 与 Box Runtime 通过随机 marker challenge 证明使用同一共享持久卷。
+2. Workspace、Skill store、ephemeral root/tmp/home 的 byte 和 inode quota
+   都在写入点生效。
+3. 并发写、压缩包展开、文件同步、重启恢复和删除重建不能绕过配额。
+4. 配额耗尽只影响目标 Workspace，其他 Workspace 仍能执行。
+5. 任一硬存储能力缺失时 `/readyz` 返回非 2xx，Pod 不进入就绪流量。
+
+### V-03：PostgreSQL 与 pgvector 生产边界
+
+必须在最终 PostgreSQL endpoint、凭据和网络策略下验证：
+
+1. migrator 与 runtime 使用不同 role；runtime role 无 superuser、
+   `BYPASSRLS`、DDL、对象所有权、role membership 或额外 schema 权限。
+2. runtime credential 只能连接目标 business database。需要专用
+   cluster/endpoint，或经过测试的 HBA/proxy policy；database 内 catalog
+   audit 本身不能证明这一点。
+3. release migration Job 的 advisory lock、失败重试、回滚和精确 Alembic head
+   校验有效；应用启动角色不能执行 migration 或其他 DDL。
+4. 若使用 PgBouncer，transaction pooling、异常回滚和连接复用不会残留
+   tenant context。
+5. 故意遗漏应用层 Workspace filter 时，RLS 仍阻止跨租户读写。
+6. 两个 Workspace 使用相同 `vector_id`、猜测其他 Workspace ID、后台任务和
+   连接复用时，pgvector CRUD 均不能越权。
+7. dimension mismatch、extension/schema/ACL drift 或 runtime audit 失败时，
+   Core 启动失败且不回退到其他向量后端。
+
+### V-04：最终镜像和配置一致性
+
+生产候选验证前必须固定：
+
+- Core、Plugin Runtime、Box Runtime 的不可变镜像 digest；
+- LangBot 与 SDK commit；
+- `data/config.yaml` 的非敏感摘要和所有环境变量覆写；
+- PostgreSQL migration revision；
+- Cloud Adapter、Space control plane 和 workload 的版本。
+
+滚动更新、节点迁移、配置变化或任一镜像 digest 变化后，旧验证报告失效。
+
+## 4. 多租户行为与故障注入
+
+### V-05：目录、entitlement 与 generation
+
+在真实 Space control plane、闭源 Cloud Adapter 和 Core 之间验证：
+
+1. 注册自动创建个人 Workspace、owner membership、Free subscription、
+   entitlement snapshot 和 outbox 事件，且重试不重复创建。
+2. 邀请、成员变更、套餐变更和 Workspace 撤销只影响目标 Workspace。
+3. 全量快照与增量事件覆盖乱序、重复、断点续传、缺页、签名错误、
+   high-water gap、snapshot coverage 和消费者重启。
+4. Core、Plugin Runtime 或 Box 重启后，权威 desired state 可恢复；
+   本地进程表和缓存不是唯一真相。
+5. generation/revision 切换期间，旧 callback、RPC、WebSocket、Box relay、
+   plugin worker 和缓存写入全部失败关闭。
+6. 为未来多副本预留的 replica-local cursor 语义通过故障注入：
+   一个副本追平不能使另一个副本跳过本地 cache 刷新。
+
+### V-06：套餐、Box 与 stdio MCP
+
+1. Free/非 Pro Workspace 不会自动获得 managed sandbox。
+2. 合资格 Workspace 最多只有一个持久 `global` sandbox，且新增 Workspace
+   不创建专属 Runtime、Pod、PVC、database、schema、role 或连接池。
+3. Cloud 即使 `box.enabled=true`，也不能 create/update/test/start stdio MCP；
+   旧记录和直接 API 调用同样失败关闭，且不创建 `mcp-shared` session。
+4. OSS 默认仍是单 Workspace、多用户，stdio MCP 保持兼容，多租户能力不会被
+   未签名配置或普通环境变量开启。
+
+### V-07：跨租户安全回归
+
+至少使用两个恶意测试 Workspace 验证：
+
+- 同 digest 插件只共享只读代码和依赖；进程、secret、日志及所有可写目录隔离。
+- 同 author/name/version 但 digest 不同的 artifact 不共享目录。
+- Plugin Host API、Box RPC、对象 key、WebSocket、RAG、storage、model/session
+  cache 和平台回调不能接受调用方伪造的 Workspace scope。
+- 撤销 entitlement、删除 installation 或 generation 切换后，已有长连接和
+  in-flight 请求不能继续访问旧权限。
+
+## 5. 生产候选容量与 24 小时门禁
+
+### V-08：真实容量曲线
+
+现有 fake adapter/requester/Plugin handler 探针不能替代真实容量数据。必须使用
+计划上线的平台 SDK、外部 HTTP/WebSocket 连接池、真实插件进程、真实
+PostgreSQL/pgvector 和代表性 Workspace 配置分布，测量：
+
+- 空 Workspace、活跃 Workspace、每个启用插件和每个 Pro sandbox 的边际
+  RSS、线程、文件描述符、连接和 PostgreSQL pool 成本；
+- 启动、目录重放、批量 reconcile 和故障恢复的耗时与峰值；
+- 单实例可批准的 Workspace、活跃 Bot、plugin worker 和 sandbox 上限。
+
+容量上限必须写入生产配置与告警，不能只保留在测试报告中。
+
+### V-09：24 小时资源 soak
+
+使用 [标准 24 小时命令](./cloud-runtime-soak-gate.md#标准-24-小时命令)，并强制
+`--require-hard-limits`。工作负载至少覆盖：
+
+1. 注册、邀请、登录和 entitlement 刷新；
+2. plugin reconcile、依赖准备、调用、崩溃与重启；
+3. Dashboard/Embed/平台 WebSocket 建连、突发消息和断连；
+4. Box session、文件同步、并发 exec、输出与清理；
+5. PostgreSQL pool 接近容量、事务超时和恢复；
+6. Core、Plugin Runtime、Box 分别 SIGTERM 和恢复。
+
+最后至少保留 30 分钟无测试流量冷却。任一健康失败、OOM/memory pressure、
+PID limit、blocking executor rejection、超阈值 CPU throttling/event-loop lag、
+冷却尾段内存持续增长或临时 gauge 不回落都判为失败。
+
+必须归档：
+
+- 原始 `cloud-soak-samples.jsonl`；
+- 最终 `cloud-soak-report.json`；
+- 三个镜像 digest、Core/SDK commit；
+- 生产配置摘要、数据库 migration revision 和 workload 版本；
+- 故障注入时间线及关联日志/trace。
+
+## 6. 本轮不作为验收条件的后续事项
+
+以下能力已明确暂缓，不能混入当前验证结果，也不能以“尚未验证”为理由临时发明方案：
+
+- Workspace export、释放、delete、单 Workspace restore 和在线迁移；
+- Workspace 级 BYOK E2B WebUI 配置；
+- 多 Core/Plugin Runtime/Box replica 的 lease store 与调度实现；
+- PostgreSQL 多 shard、dedicated shard 和跨地域部署；
+- 多 CloudInstance、Cell Router 或 Workspace Placement。
+
+这些事项需要后续单独决策。首期实现仍需保留稳定 UUID、generation fence、
+幂等事件和无副本地址泄漏的协议边界。
+
+## 7. 关闭规则
+
+每个 B/V 项只能通过以下方式关闭：
+
+1. 记录被测 commit、镜像 digest、配置摘要和环境拓扑；
+2. 保存可复现命令、原始输出和失败注入证据；
+3. 由报告明确给出 pass/fail，不能只依赖日志中“看起来正常”；
+4. 任一生产候选输入变化后，重跑受影响的验证。
+
+在 B-01 至 B-04 全部实现，且 V-01 至 V-09 均有当前生产候选版本的通过证据前，
+Cloud v2 状态保持 `NOT APPROVED FOR SAAS ACTIVATION`。

docs/multi-tenant/runtime-resource-audit-2026-07-28.md

@@ -0,0 +1,254 @@
+# LangBot Cloud Runtime 资源安全审查
+
+日期：2026-07-28 至 2026-07-29
+
+审查分支：
+
+- LangBot：`feat/multi-tenants`，审查起点 `32abbb636f4455e965141d8d209b359dbfbb5aae`
+- Plugin SDK：`feat/multi-tenants`，审查起点 `0cddf3c2bea5939c67b71e488a719e9903c28d17`
+
+## 结论
+
+本轮已覆盖 LangBot Core、Plugin Runtime 和 Box Runtime 的主要常驻对象、后台任务、队列、网络客户端、进程生命周期及数据库连接池。本轮定位到的攻击者可控或历史累积状态均已补充容量、超时、淘汰或确定性清理边界；修正后的高基数探针没有观察到随历史请求继续增长的活跃缓存。该结论不等于证明任意生产负载下不存在资源问题，生产激活仍受下述 Linux 隔离、硬盘配额和 soak 门禁约束。
+
+代码级审查、跨仓全量测试和仓库 Dockerfile 构建的 Linux/cgroup v2 探针已经通过，但当前状态仍不能作为 Cloud 生产激活批准。完整剩余清单见
+[Cloud v2 仍待验证事项](./cloud-v2-pending-verification.md)。其中与本轮资源审查直接相关、上线前还必须完成的项目包括：
+
+1. 在最终 Cloud 部署权限和 cgroup 拓扑下重复 nsjail、namespace 和 delegated cgroup v2 的 CPU、内存、swap、PID、文件句柄验证。本轮一次性 Linux 容器已经证明代码路径可工作，但普通容器和仅 `--privileged` 的 private cgroup namespace 都不满足条件。
+2. 为 Cloud Box 提供并验证硬文件系统 quota provider。普通 nsjail bind mount 不能证明总字节数和 inode 硬配额，当前严格 readiness 按设计会失败关闭。
+3. 使用最终生产配置分布继续做容量测试，并据此确定单实例 Workspace placement 上限。本轮真实 PostgreSQL 16 + RLS 启动测试已经覆盖 1,000 个各带 Provider、三类 Model、Bot、Pipeline、KnowledgeBase、MCP 和 Plugin setting 的 Workspace，启动加载耗时和 SQL 次数保持线性；5,000 Workspace 的合成三代替换探针也证明旧运行时会释放。仓库已新增可同时采集 Core/Plugin/Box HTTP、进程树和 cgroup v2 的 24 小时门禁工具，并在受 CPU、memory、swap、PID 硬限制的 Linux 容器中完成短时自检；但最终生产候选拓扑的 24 小时运行仍未执行。测试中的 fake adapter/requester/Plugin handler 仍不能替代真实平台 SDK、外部连接池和插件进程的容量数据；合法活跃租户本身仍会线性占用内存。
+SDK 已先行发布到分支提交 `67be7c332ded4c1afa131b28232590cf9728f817`，本提交集中的 LangBot
+`pyproject.toml` 和 `uv.lock` 已精确钉住该提交。最终镜像仍需按待验证清单记录并核对实际安装版本。
+
+## 覆盖范围
+
+### LangBot
+
+- 启动、停机、全局任务管理和运行时配置。
+- PostgreSQL、Tenant UoW、RLS、迁移和共享 pgvector。
+- HTTP、MCP、WebSocket、上传下载、S3/本地存储、维护任务和异步用户任务。
+- QueryPool、Pipeline Controller、会话/对话、限流、第三方 Agent/LLM runner 和同步 SDK 桥接。
+- PlatformManager 以及 DingTalk、QQ、Lark、WeCom、WeComCS、WeChatPad、LINE、Kook、Satori、OpenClaw Weixin、Telegram、Discord、Matrix、HTTP/WebSocket 等适配器。
+- Plugin Runtime connector、插件包校验、Marketplace 下载、pip 安装输出和 desired-state reconcile。
+- Box connector、admission、session/process 生命周期和 RPC 文件。
+- RAG、向量后端、Skill、Storage、Telemetry 和日志缓存。
+
+### Plugin SDK
+
+- stdio/WebSocket transport、请求 waiter、action task 和文件传输。
+- Runtime control handler、Workspace/generation fence 和 EventContext。
+- 插件 artifact、Marketplace、pip 依赖安装、共享依赖环境、installation desired state、Supervisor 和 worker launcher。
+- nsjail 参数、cgroup/rlimit、进程注册 capability 和 Runtime shutdown。
+- Box admission、generation fence、session/process/reaper、RPC/relay WebSocket 和 nsjail backend。
+
+## 主要修复
+
+### 确定性生命周期
+
+- 修复 `Application.shutdown()` 使用 `contextlib.suppress` 却未导入 `contextlib` 的问题。原行为会在实际资源关闭分支直接 `NameError`，阻断后续 Plugin、Box、HTTP 和数据库释放。
+- `make_app()` 在任一启动 stage 或初始化失败时会关闭尚未返回给 `main()` 的半构建 Application；Telemetry、Box、Tool、Platform、Vector 和 HTTP manager 在初始化前即挂到 Application，避免初始化中途失败后清理器无法发现已经创建的连接、会话、子进程或后台任务。
+- MCP streamable-HTTP session manager 现在随 Application shutdown 显式退出。
+- MCP loader 按 `(instance, workspace, generation)` 管理 host task 和 session；任务完成会从注册表移除，代次推进会取消旧 host task 并关闭旧 session，reload/shutdown 会先清空现有运行时，避免 completed task 和旧代连接永久驻留。
+- Platform bot reload/remove/shutdown 统一串行化，旧 bot、代理、adapter 任务和进程会先停止再从注册表移除。
+- Model provider requester 新增异步关闭契约；provider reload/remove、Workspace generation 替换、全量 reload 和 Application shutdown 都会确定性关闭旧 requester，允许第三方 requester 安全持有自己的 HTTP client 或连接池。
+- Plugin Runtime、Box Runtime、stdio transport、adapter 连接和共享 HTTP client 均补齐 close/cancel/await。
+- `Application.dispose()` 只允许一个可追踪 shutdown task；重复的信号、窗口关闭或调用方清理不会铺开多个并行停机流程。
+- Lark、微信、钉钉、企业微信和 QQ Official 的凭证交换后台任务统一进入 Application TaskManager，受全局/单 Workspace admission 约束并随应用停机取消；容量满时关闭尚未调度的 coroutine 并返回 429，不留下游离 task。
+- `TaskCapacityError` 已下沉到无 Application/controller 依赖的纯错误模块。原来的 HTTP 过载异常路径会在特定冷启动导入顺序下触发 TaskManager/controller 循环导入，把应返回的 429 变成框架 500。
+- S3 storage provider 在初始化失败或 Application shutdown 时关闭 botocore HTTP connection pool；Storage manager 在 provider 初始化前即挂到 Application，避免 bucket probe 失败后遗留 client。
+- 修复 Coze runner 每次请求创建 `aiohttp.ClientSession` 却不关闭的问题；现在 runner 的 `aclose()` 会确定性关闭底层 API client。
+- LINE SDK client 现在随 adapter 停止关闭；Plugin Runtime shutdown 回调只创建一个可追踪、可等待的后台任务，重复回调不会累积清理 task。
+- SDK `lbp publish` 现在用上下文管理器关闭插件包上传文件；原实现的成功、API 错误和 HTTP 错误返回路径都会遗留文件句柄。
+- Plugin worker、Box Docker/CLI backend、Box nsjail backend 和 nsjail 依赖安装在调用方取消时会 terminate/kill、读取管道并 `wait()` 回收子进程；Windows worker 的原生进程路径也进入相同的 `finally` 清理契约，避免取消安装、停机或超时后留下孤儿进程。
+- Box 服务入口现在从 Runtime initialize、aiohttp app/runner setup、端口 bind 到主循环共用一个外层清理边界；建站期间的非 `OSError` 也会关闭 Runtime 和 reaper。WebSocket 控制模式端口绑定失败会退出并交给编排器重启，不再在没有任何可用 RPC/health 端口时永久等待；stdio 模式仍允许仅 relay 绑定失败后继续控制通道。
+- Plugin artifact 解压、installation staging/activation/rollback/delete、共享依赖环境和 nsjail session 目录的关键文件系统变更均移出事件循环。已经开始的原子变更在取消时会先等待线程结束，再回滚临时目录、目标目录或旧 supervisor，不会让后台线程继续修改一个调用方已经认为清理完毕的路径。
+- Core 和 SDK 的阻塞 executor 新增独立的有界清理入口。普通工作在容量耗尽时仍快速拒绝；已经拥有资源的 close/unlink/rmtree/进程回收则等待有限 worker 槽位并保证原子操作结束后再传播取消，避免过载恰好导致清理任务被拒绝。SeekDB、Milvus、S3、LINE、WeChatPad、MCP staging 和 TBox 临时文件等关键路径已接入。
+
+### 有界队列、缓存和历史状态
+
+- QueryPool 同时限制全局与单 Workspace 的 queued/running query；调度后不再被过载淘汰；历史 scope counter 有上限。
+- Session、Conversation、WebSocket connection/proxy/message、rate-limit identity、task record/log、telemetry task、vector handle 和 adapter 私有队列均有容量或 LRU/TTL。
+- SessionManager 现在维护 Workspace 二级索引和带 revision 校验的最小过期堆。新会话只扫描目标 Workspace 的有界会话集，TTL 回收只消费已过期堆前缀，全局 idle 淘汰使用最小堆；高频命中产生的旧堆项按活跃会话的有界倍数压缩。原实现会在每个攻击者可制造的新 launcher id 上扫描并排序实例全部会话。
+- SDK 的 EventContext 和依赖准备锁使用 weak reference；generation、admission、installation、capability 和 completed-process 状态有上限。
+- 空 Workspace 不再预分配 Model generation scope、Plugin installation set 或 Box generation event；只有 Workspace 实际拥有对应运行时资源或等待任务时才创建这些对象。
+- Runtime RPC 文件同时限制单文件字节数和单连接未消费文件数量，连接关闭时清理连接拥有的临时文件。
+- Box Runtime 维护实例与 Workspace 到活跃 session 的二级索引；创建、删除、过期、撤销和 shutdown 共用同一清理路径，避免每个租户 RPC 都扫描实例中的全部 session。
+- Box Runtime 另外只索引“可过期 session”和“持有 managed process 的 session”。Cloud 的持久 `global` sandbox 不进入 TTL 索引，managed process 被禁用时进程索引为空；session 创建、周期 reaper、状态和 `/healthz` 因此不会随全部持久租户数线性扫描。测试把总 session 字典替换为禁止迭代的映射，仍能完成第二个持久 session 创建、reap、status 和 health。
+- Core MCP loader 同样维护 Workspace/generation 到 session、host task 的二级索引；请求、代次回收和动态配置不再扫描实例中的全部租户 MCP session，已完成 task 的 done callback 会同步移除所有索引。
+- Box admission 过期回收使用带 revision/generation 校验的最小堆，只访问已到期记录；重复续期产生的旧堆项会被忽略，堆大小超过活跃 grant 的有界倍数时压缩，不再在每次 RPC 上全表扫描所有租户 grant。
+- 旧 QQ message ID/object cache 和 stdio MCP Workspace copy lock 不再随历史请求无限增长。
+- LLM/Agent runner 的单次生成结果默认限制为 1 MiB，流式传输限制单事件 1 MiB、单请求累计 16 MiB，并限制最多 100,000 个流式事件，避免上游异常响应无限占用内存或 CPU。
+- Marketplace JSON 限制为 1 MiB、插件包限制为 64 MiB；pip stdout/stderr 各最多保留 1 MiB，超出部分继续 drain 但不驻留内存。
+- Plugin Runtime stdio/WebSocket 协议除 16 MiB 消息字节上限外，新增最多 4,096 个入站和出站碎片的对象数量上限；大消息的 UTF-8 编码、分片、拼接、JSON 编解码和 Pydantic 验证均在线程执行。WebSocket receive 异常使用稳定的 `ConnectionClosed` 类型，不再因库顶层未导出 `exceptions` 属性而在错误路径二次失败。
+- HTTPX response hook 和 aiohttp 有界读取统一把第三方响应限制为 10 MiB；JSON 解析及诊断文本转换在线程执行，错误正文最多保留 4 KiB，避免大 JSON 在共享事件循环集中解析。
+- 图片、data URI 和平台媒体默认限制为 10 MiB，Base64 在解码前先校验编码长度；Plugin binary storage 默认单值 10 MiB，并设置不可由错误配置绕过的 64 MiB 绝对上限。
+- Skill 文本单文件限制为 1 MiB，Plugin UI 文件限制为 4 MiB，host edit 文件限制为 1 MiB；Box Skill ZIP、插件 artifact 和 GitHub Skill archive 同时限制条目数、单文件、解压总量和压缩比。
+- SDK E2B 文件同步限制为最多 2,048 个目录项、1,024 个文件、单文件 10 MiB、总计 50 MiB；同步文件 IO 从事件循环移到线程。
+- Dify 待提交表单、用户 Space OAuth state 和 Cloud launch JTI replay cache 改为带 revision 校验的最小过期堆；Space credits 使用按时间有序的 LRU/TTL 队列。原实现会在每次攻击者可触发的请求上扫描整个历史缓存并在满容量时再次线性寻找最旧项；现在过期回收为摊销 `O(log N)` 或仅消费已过期前缀，旧堆项会忽略并按活跃状态的有界倍数压缩。
+- Cloud launch JTI cache 达到 4,096 个仍有效 token 时失败关闭，不再为了接纳新 token 淘汰仍有效的 replay 记录；否则攻击者可以在容量满后重放被提前遗忘的合法签名。
+- Entitlement resolver 现在跟随 Cloud directory 的权威 Workspace 活跃集合。全量目录投影会丢弃已 fenced/removed Workspace 的历史 entitlement snapshot，delta 批量更新不会对每个变化重复扫描；provider 请求进行中发生目录撤销时，返回前的第二次 active fence 会阻止旧结果重新写回缓存。
+
+### CPU 和事件循环保护
+
+- 修复旧 QQ `repeat_seed('')` 空输入无限循环。
+- ZIP 校验/重打包、PIL、Base64、AES、JSON 解析、fsync probe、插件 artifact/依赖文件、Skill、S3、本地存储和维护目录扫描从事件循环移到线程。
+- 公开 Slack、QQ Official、HTTP Bot、公众号、WeCom/WeComCS 回调体显式限制为 1 MiB；JSON/XML 解码移出共享事件循环。QQ、DingTalk、Satori、WeCom AI 和 WeChatPad 网关帧同样设置 1 MiB 上限或在解码前拒绝超限消息；KOOK zlib 数据使用 10 MiB 解压后硬上限，阻断小压缩包制造的大内存解压。
+- Dashboard、Embed 和 Plugin Runtime 的协议 JSON 编解码在线程执行；Dashboard/Embed 在接收端提交 terminal error 后为发送端保留有界 drain 窗口并使用内部 sentinel 唤醒，不会因“任一方向结束即取消”在撤权错误帧发出前关闭连接。
+- 租户配置的敏感词、内容忽略和群响应正则统一使用声明为直接依赖的 `regex` 引擎：最多 64 个 pattern、单 pattern 1,024 字符、输入 1 MiB、单次总匹配 CPU 预算 50 ms，并在线程中执行。超时、非法正则和替换放大均失败关闭；灾难性 `(a+)+$` 回归在 1 ms 测试预算内被中断。
+- 原生 `read/write/edit/glob/grep` 文件工具移出事件循环并继承 Workspace 阻塞预算。目录列举、递归 walk、grep 文件/总字符、单行、pattern、结果和 regex CPU 均有硬上限；glob 只用固定大小最小堆保留最新 100 项，不再先把全部命中路径驻留内存。Box 内执行的 glob/grep 脚本同样限制命中集合、扫描量和正则时间。
+- Dify、DingTalk、QQ、WeCom 等客户端复用连接并在生命周期结束时关闭，响应体和下载有字节上限。
+- DashScope、TBox 等同步第三方 SDK 的调用和生成器迭代改为在线程执行；单个同步生成器最多消费 100,000 个事件。
+- Dashboard 和 Embed WebSocket 改为任一收发 task 结束即取消并等待另一方向，避免发送端退出后接收 task 永久阻塞；两方向 task 同时继承从认证结果或 RuntimeBot 得到的可信 Workspace 阻塞预算。
+- Plugin installation 生命周期全局串行化；不同租户的依赖 pip/nsjail 准备不会在安装高峰并发抢占 CPU。
+- S3 同步 SDK 使用线程执行，并通过实例级 semaphore 限制并发；默认 `storage.s3.max_concurrency=16`，可通过实例配置和环境变量覆写。
+- Box 子进程 stderr 以 64 KiB 块读取，日志最多每秒输出 4 个摘录并汇总抑制数量，避免无换行或刷屏输出制造无界缓冲与日志放大。
+- Plugin worker 日志单行最多保留 64 KiB；Box managed-process stdout relay 以固定 64 KiB 块读取，不再依赖换行符，避免超长无换行输出触发 `StreamReader` limit 或堵塞子进程。
+- Box generation fence 的代次更新改为只访问目标 Workspace 的 event 和 active-task 二级索引。原实现每次更新都会遍历全部 Workspace 的 fence/task 记录，10,000 个 Workspace 的第二阶段更新会退化为 O(N²) 并在 40 秒后仍未完成；修正后包括其他 SDK 高基数负载和本轮协议 offload 在内的当前完整双阶段探针耗时 `9.037s`。
+- Box session 枚举、旧 generation 回收和 admission 计数均通过 Workspace 索引执行；admission 过期回收通过最小堆执行，不再在每次 RPC 上产生 O(实例总 session/grant 数) 的扫描。
+- Model、Pipeline、RAG 和 Platform manager 均维护 Workspace 到运行时 key 的二级索引。Workspace generation 更新只清理目标 Workspace 的缓存和运行时，不再扫描实例内所有租户的 provider/model、pipeline、knowledge runtime 或 bot；回归测试使用禁止全局迭代的映射验证该边界。
+- Cloud heartbeat 直接读取已加载且有容量边界的 Pipeline、MCP、KnowledgeBase 和 Bot registry 计数，不再为每个活跃 Workspace 依次打开 Tenant UoW、执行四类 COUNT 查询；这消除了租户数增长后每日周期性形成的串行 SQL/CPU 尖峰。OSS 模式仍保留数据库统计语义。
+- Cloud 启动阶段先生成一份经过部署适配器和目录投影校验的 Workspace binding 快照，Model、Platform、Pipeline、RAG 和 Plugin 初始化共用该快照，初始化完成后立即释放；避免启动期间为每个 manager 重复执行整批租户发现和投影校验。
+- Platform、Pipeline 和 RAG 的资源加载在使用已验证启动快照时不再为每个 Bot/Pipeline/KnowledgeBase 重新查询同一个 execution binding；常规请求和动态更新路径仍保留数据库 generation fence。
+- MCP 初始 host 和 shutdown burst 由实例级 semaphore/批次限制；默认 `mcp.lifecycle_concurrency=16`，支持 `MCP__LIFECYCLE_CONCURRENCY` 覆写并硬性限制最大 128。初始加载不再先为每个 server 创建一个等待 semaphore 的 task，而是由一个可取消 dispatcher 每批最多物化 `lifecycle_concurrency` 个子 task；同时去掉了 ORM server/config 的双份临时列表，避免大量租户启动时集中占用 CPU、内存、socket 和文件句柄。
+- Core、Plugin Runtime、Box Runtime 和独立 Plugin worker 的默认 `asyncio.to_thread()` executor 统一改为硬有界线程池。默认最多同时运行 8 个阻塞调用、排队 128 个，达到容量后立即抛出 admission 错误，不再使用 Python 默认 `ThreadPoolExecutor` 的无界工作队列保留任意数量的请求对象、Future 和闭包。每个可信 Workspace 的 running + queued 默认再限制为 4，并强制配置值不超过 worker 数的一半，避免单个租户先提交一整批同步工作占满全部 worker/FIFO 队列。Core 使用 `system.blocking_executor.max_workers/max_pending/max_inflight_per_scope`，原生支持对应的 `SYSTEM__BLOCKING_EXECUTOR__*` 覆写；SDK 进程使用 `LANGBOT_BLOCKING_EXECUTOR_MAX_*`，并分别限制全局最大值为 64/4096。
+- Core、Plugin Runtime 和 Box Runtime 各自运行固定 1 秒间隔、仅保留最近 120 个样本的 event-loop lag monitor；健康快照输出 current/recent max/recent p95/进程期最大延迟和累计样本数。Plugin Runtime 的两个 WebSocket 端口现在都在免认证 `/healthz` 返回同一份无凭据、无租户标识的聚合 JSON，Box `/readyz` 同时附带资源快照。24 小时门禁默认拒绝缺失或停止的 monitor、超过 1 秒的 recent max、超过 250 ms 的尾段 recent p95 及 sample counter 回退。
+- Workspace 阻塞预算由服务端认证后的 `RequestContext`、公开 bot 的 RuntimeBot、公开对象 key 中经 binding fence 验证的 Workspace、Platform/TaskManager 的 ExecutionContext，以及 SDK 入站 ActionContext 建立，不接受调用方伪造的租户 header。公开 webhook、公开对象下载、Dashboard/Embed WebSocket、普通 HTTP handler、Platform adapter 和 detached tenant task 均已覆盖。容量拒绝在 Core HTTP 路径返回稳定的 429，health/debug counter 分开报告 global 与 scope rejection。
+- Argon2 密码 hash/verify 只允许一个实例级在途操作，额外并发立即返回容量错误而不是在 asyncio semaphore 中无限积累等待请求；该 CPU/内存密集工作同时使用独立的 `system:authentication` 阻塞作用域。Cloud 本身仍禁用本地密码登录。
+- WeCom 扩展 API 的无限客户端超时改为 120 秒；平台 webhook 的 AES、媒体 Base64 与同步 SDK 调用均移出共享事件循环。
+
+### 插件和 Box 资源隔离
+
+- Plugin worker 数量受 `max_workers`、`max_total_cpus / max_cpus` 和 `max_total_memory_mb / max_memory_mb` 的最小值约束。
+- Shared profile 强制 Linux 和 nsjail；Cloud 强制 `plugin.worker.require_hard_limits=true`；cgroup v2 delegation 不可用时拒绝启动。
+- 每个 worker 下发 CPU、memory、swap、PID cgroup 限制，以及 process、open-file、file-size rlimit；插件 manifest 不能提高限制。
+- Box nsjail 的 cgroup v2 路径现在同时设置 `memory.max` 和 `memory.swap.max=0`。修复前，48 MiB 沙盒可以把强制提交的 128 MiB 页面换出并正常退出，形成宿主 swap 抢占；修复后同一探针以 exit 137 被 cgroup 杀死。
+- 仓库 Docker Compose/Kubernetes 示例显式下发 Core、Plugin Runtime 和 Box Runtime 的 blocking executor 上限；Kubernetes Box readiness probe 从仅报告进程存活的 `/healthz` 改为 `/readyz`，使 backend 或 managed-mode 隔离检查失败时不会把 Pod 加入就绪流量。
+- 相同 digest 的已验证代码和依赖环境可只读共享，每个 installation 的 home/tmp/data 和进程独立。
+- Box session、managed process、completed process、admission record 和 RPC 文件均有实例级上限；Cloud entitlement 仍限制每个合资格 Workspace 一个 `global` session、零 managed process。
+
+### PostgreSQL
+
+- Cloud 强制 PostgreSQL 业务库、共享 pgvector 和允许的固定向量维度。
+- pgvector Cloud 模式复用业务数据库的同一个 AsyncEngine，不创建第二个连接池。
+- `database.postgresql` 新增并校验 `pool_size`、`max_overflow`、`pool_timeout_seconds`、`pool_recycle_seconds`；默认最大连接数为 `10 + 10`。
+- Application shutdown 显式 dispose 业务引擎；standalone pgvector 仅关闭自己拥有的引擎。
+- PersistenceManager 提供统一异步 shutdown；Cloud 常驻进程的启动失败、正常停机和一次性 release migration 的成功/异常路径都会释放数据库引擎。真实 PG catalog 测试还覆盖了“入口已经关闭后测试再次复用 manager 会重开 pool”的第二生命周期，严格资源告警模式下无 asyncpg socket/transport 遗留。
+
+## 本轮采用的默认决策
+
+- 优先 fail closed 或淘汰最老的 idle cache，不允许攻击者控制的历史 key 无限驻留。
+- 插件依赖准备选择实例级串行化，以稳定 CPU/磁盘峰值；代价是批量安装耗时增加。
+- PostgreSQL 使用一个显式有界共享连接池；未拆分 pgvector pool。
+- 第三方 runner 采用 1 MiB 单结果、16 MiB 单流总量和 100,000 个同步/异步事件的统一实例级安全上限；超限请求失败关闭。
+- S3 默认允许 16 个并发阻塞调用，最大配置值 128；在没有独立 worker service 的前提下限制线程池排队和上游连接压力。
+- MCP 生命周期默认并发 16、最大 128；该限制统一约束实例启动时的 session host 峰值和 shutdown 批次，不允许租户配置单独放大。
+- Core 与 SDK 各进程的通用阻塞 executor 默认使用 8 个 worker、128 个 pending 槽位、每 Workspace 4 个在途槽位；它是实例/进程级共享背压，不由 Workspace 或插件 manifest 调高，单 Workspace 配置硬性不得超过 worker 的一半。生产值应按容器 CPU 和上游阻塞时延校准，不能把 pending 当吞吐配置无限放大。
+- 插件包下载上限 64 MiB，pip stdout/stderr 保留上限各 1 MiB；这不会限制安装进程实际输出，只限制父进程内存中的诊断副本。
+- 通用远程响应和媒体默认上限 10 MiB；错误诊断正文只保留 4 KiB。Plugin binary storage 默认 10 MiB、绝对上限 64 MiB；Skill 文本、Plugin UI 和 host edit 分别限制为 1 MiB、4 MiB 和 1 MiB。
+- Managed-process relay 保留 stdout 的原始换行，并按 64 KiB WebSocket frame 分块；不再承诺“一行对应一个 frame”。这是为无换行输出提供确定内存边界所需的协议收敛。
+- 本轮没有把 Pipeline、Model、KnowledgeBase 等合法租户资源改成 lazy runtime。该改动会改变启动和请求语义，留到 Workspace placement/释放机制一起设计。
+- 本轮没有为普通 nsjail 声称伪硬盘配额；严格 Cloud readiness 保持失败关闭。
+
+## 验证结果
+
+| 验证项 | 结果 |
+| --- | --- |
+| LangBot Ruff + `git diff --check` | 通过 |
+| Plugin SDK Ruff + `git diff --check` | 通过 |
+| LangBot 全量测试（使用本地新 SDK，含 unit/integration/Box/E2E） | `2803 passed, 33 skipped` |
+| Plugin SDK 全量测试 | `1301 passed` |
+| 真实 PostgreSQL 16 + pgvector 迁移/RLS/发布测试（严格资源告警） | `22 passed` |
+| 真实 PostgreSQL 16 + RLS populated Cloud 启动容量 | 500 Workspace `6.178s / CPU 3.026s`；当前 1,000 Workspace 复跑 `12.109s / CPU 5.967s` |
+| 当前 Core Dockerfile Linux 镜像构建与 `regex` 导入 | 通过，image SHA `8893a14053df`；仍使用待更新的旧 SDK pin |
+| `ResourceWarning` + `PytestUnraisableExceptionWarning` 全量门禁 | Core 与 SDK 均通过，并已固化到 pytest 配置 |
+| Plugin SDK Box 专项测试（含全局扫描回归保护） | `669 passed` |
+| Docker Compose 渲染、Compose/Kubernetes YAML 解析与 diff 检查 | 通过 |
+| Cloud soak 门禁解析/采样/判定单元测试 | `23 passed` |
+| Core/Plugin SDK event-loop monitor 专项测试 | 两仓各 `7 passed`，包含真实 50 ms scheduler stall |
+| Cloud soak Linux 硬限制短时自检 | 通过；CPU `0.5`、memory+swap `256 MiB`、PID `128` 均从 cgroup v2 读回，冷却尾段 verdict `pass` |
+| Core 双阶段历史 churn 资源探针（使用本地新 SDK） | audit 通过，`11.275s` |
+| Core 5,000 个 populated Workspace 三代容量探针（使用本地新 SDK） | audit 通过，最大替换耗时比 `1.378` |
+| Plugin SDK 双阶段资源探针 | audit 通过，`9.037s` |
+
+两个仓库新增了可重复执行的历史 churn 探针，Core 另有 populated Workspace 三代替换探针：
+
+```bash
+# LangBot Core
+PYTHONPATH=../langbot-plugin-sdk/src uv run python scripts/runtime_resource_probe.py --scale audit --json
+
+# LangBot Core：5,000 个带代表性资源的 Workspace
+PYTHONPATH=../langbot-plugin-sdk/src uv run python scripts/workspace_runtime_capacity_probe.py --scale audit --json
+
+# LangBot Core：真实 PostgreSQL 16 + RLS populated Workspace 启动
+TEST_POSTGRES_URL=postgresql+asyncpg://... \
+LANGBOT_PG_CAPACITY_WORKSPACES=1000 \
+uv run pytest \
+  tests/integration/persistence/test_migrations_postgres.py::TestPostgreSQLTenantRuntime::test_populated_cloud_startup_is_linear_and_task_bounded \
+  -q -W error::ResourceWarning --log-cli-level=INFO
+
+# langbot-plugin-sdk
+uv run python scripts/runtime_resource_probe.py --scale audit --json
+```
+
+Core audit 每个阶段执行 10,000 个空 Workspace 的真实 Model/Plugin manager 加载与 reconcile、25,000 次 Query、2,500 次 session churn、10,000 个限流身份、5,000 个 task 和 2,500 次 WebSocket churn。第一、第二阶段的保留状态完全一致：
+
+- 20,000 个历史空 Workspace：Model scope/provider/LLM、Plugin Workspace set/installation 均为 `0`。
+- 50,000 个历史 Query：活跃 query cache `0`，历史 scope counter `100`。
+- 5,000 个会话身份：session cache `200`。
+- 20,000 个限流身份：rate-limit container `10,000`。
+- 10,000 个历史 task：task record `200`。
+- 5,000 次 WebSocket churn：conversation 与 stream index 均为 `200`。
+- event-loop task、线程和文件描述符保持 `1 / 1 / 6`；强制加载本地最新 SDK 的当前复跑中，第二阶段相对第一阶段 RSS 增长 `1,605,632 bytes`、tracemalloc current 增长 `344,735 bytes`，总耗时 `11.275s`。Session 淘汰改为 Workspace 索引和最小堆后，同一 audit 工作量相对此前 `16.150s` 明显下降。
+
+Populated Workspace audit 为 5,000 个 Workspace 各加载一个 Provider、LLM、Embedding、Rerank、Pipeline、Bot、KnowledgeBase 和 MCP session，然后全部推进两个 generation：
+
+- 三个阶段的活跃 provider/model、pipeline、bot、knowledge 和 MCP registry 均精确维持 `5,000`，不存在按历史 generation 增长。
+- 到第三阶段，前两代的 requester、Bot adapter 和 MCP session 各 `10,000` 个全部收到确定性关闭；weak reference 断言旧代对象可被回收。
+- event-loop task、线程和文件描述符保持 `1 / 1 / 6`；强制加载本地最新 SDK 的当前复跑中，第三阶段相对第二阶段 RSS 增长 `1,277,952 bytes`，tracemalloc current 反而减少 `148 bytes`。
+- 初始/第一次替换/第二次替换分别耗时 `1.707s / 2.205s / 2.351s`，最大替换耗时比为 `1.378`，未随历史代次出现 CPU 退化。
+- macOS RSS sample 从初始的 `154,271,744` 增至第一阶段 `367,820,800`、第二阶段 `388,726,784` 和第三阶段 `390,004,736 bytes`；第二次替换只比第一次替换增加约 1.22 MiB，但“合法活跃租户资源的线性容量”仍必须作为 placement 容量输入。这里使用轻量 fake adapter/requester，不应把第一阶段约 204 MiB 增量外推为生产每租户成本。
+
+Plugin SDK audit 每个阶段执行 25,000 次 loopback RPC、5,000 次安装 binding 激活/撤销、10,000 个 Workspace generation 更新和 2,500 次带 Workspace 上下文的 Box session 创建/删除。第一、第二阶段的保留状态完全一致：
+
+- RPC waiter、stream queue、action task 和活跃 installation binding 均为 `0`。
+- installation watermark 为有界的 `5,000`；Workspace generation record 为有界的 `10,000`，没有等待者时 generation event 为 `0`。
+- generation active task/index、Box session、Box Workspace session index、creating/closing/background task 和 session lock 均为 `0`。
+- event-loop task 和文件描述符保持 `1 / 7`；当前复跑第二阶段相对第一阶段 RSS peak 增长 `2,654,208 bytes`、tracemalloc current 增长 `289,634 bytes`，总耗时 `9.037s`。耗时增加来自本轮把大协议消息的 JSON/Pydantic、UTF-8 编码、分片和拼接移入有界线程池；25,000 RPC/阶段的合成探针仍约为 5,500 RPC/s，结构状态和第二阶段 tracemalloc 增量保持平稳。
+
+第二轮反向静态审查另外枚举了 Core 的 50 个显式 task 创建点和 204 个线程、阻塞调用及子进程调用点，以及 SDK 的 28 个显式 task 创建点和 62 个线程、阻塞调用及子进程调用点。显式 task 均具有持有者、完成回调或 `finally` 回收路径；所有生产入口在第一次 `asyncio.to_thread()` 前安装有界默认 executor。Core、Plugin Runtime 和 Box 的公开 `/healthz`（Box `/readyz` 亦同）会输出各自的 aggregate runtime/resource counter 和 event-loop lag，供 soak 对比活跃量、pending、累计 capacity rejection 与调度延迟；不输出 debug key、控制 token、租户或插件身份。Plugin Runtime 的授权 debug info 复用同一资源快照，避免公开/私有指标语义漂移。
+
+真实 PostgreSQL populated 启动门禁会先通过 release migration 创建最新 schema，再用无 `BYPASSRLS` 的临时 Cloud Runtime 角色启动。每个 Workspace 都含九类代表性资源，测试会走实际的 instance discovery、tenant UoW、启动 binding 快照和 Model/Platform/Pipeline/RAG/MCP/Plugin 加载路径：
+
+- 500 Workspace：启动加载 `6.178s`，进程 CPU `3.026s`。
+- 当前 1,000 Workspace 复跑：启动加载 `12.109s`，进程 CPU `5.967s`；相对此前 500 Workspace 的墙钟比为 `1.960`。
+- `model_providers`、`llm_models`、`embedding_models`、`rerank_models`、`bots`、`legacy_pipelines`、`knowledge_bases`、`mcp_servers`、`plugin_settings` 九张表的 SELECT 次数均精确等于 Workspace 数，没有重复的全租户发现或超线性资源扫描。
+- MCP host dispatcher、host task 和临时 Runtime 角色/asyncpg 连接在测试结束后均清空；严格 `ResourceWarning` 模式通过。
+
+探针要求第二阶段的结构状态与第一阶段精确相等，并对第二阶段 RSS 与 tracemalloc 增长设置失败阈值。macOS 的 RSS 来源是 `getrusage` peak，因此这里验证的是峰值增量边界而非“当前 RSS 回落”；最终 Linux 24 小时 soak 仍需采集 current RSS/PSS 和 cgroup `memory.current`。
+
+LangBot 全量测试的 33 个 skip 中，22 个是默认全量运行未提供 PostgreSQL/pgvector 而跳过的集成用例，10 个是未提供 Valkey，另 1 个是可选环境的 collection skip；真实 PostgreSQL 相关路径已由上表单独运行覆盖。Plugin SDK 的 22 个 warning 为现有 Pydantic v2 deprecation 与 aiohttp AppKey 建议；没有失败、未关闭资源或资源上限降级。Core 当前全量产生 192 个既有第三方/兼容性 warning；`ResourceWarning` 和 `PytestUnraisableExceptionWarning` 仍由 pytest 配置提升为错误，本轮没有此类泄漏告警。
+
+Linux Runtime 探针使用上述镜像并只读挂载本地最新 SDK 源码：
+
+- 普通容器：nsjail binary 可执行，但 namespace、mount、network 与 cgroup v2 检查均为 `false`，严格 readiness 按预期失败关闭。
+- `--privileged` + private cgroup namespace：namespace、mount、network 通过，但 cgroup v2 delegation 为 `false`，仍按预期不能进入 Cloud ready。
+- 一次性容器内建立可写 delegated cgroup 子树后：Plugin 与 Box cgroup 探针均为 `true`，nsjail namespace、mount、network 和 cgroup v2 均通过；硬文件系统与 inode quota 继续报告 `false`。
+- `cpus=0.1` 的 1.0 秒 process-CPU busy loop 实际耗时 `9.13s`；`memory_mb=48` 下逐页提交 128 MiB 以 exit `137` 终止；`pids_limit=8` 下批量 fork 返回 `EAGAIN`。这些结果验证了 CPU、memory+swap 和 PID 的实际内核执行路径。
+- 新增 `scripts/cloud_runtime_soak.py` 后，在同一 Linux 镜像的独立容器中设置 `--cpus 0.5 --memory 256m --memory-swap 256m --pids-limit 128`，工具从目标 cgroup 读回 quota `50000/100000 usec`、memory `268435456 bytes`、swap `0 bytes` 和 PID `128`。最终复跑中，32 MiB 子负载退出后的 4 秒冷却尾段 `memory.current` 稳健增长和斜率均为 `0`，平均 CPU `0.00132 cores`，OOM、memory pressure、PID max 和 throttle delta 均为 `0`，最终 verdict 为 `pass`。这只是采集器/判定器自检，不替代最终 24 小时生产候选运行。
+- 本地实际启动 Plugin Runtime 后，控制端口与 debug 端口的公开 `/healthz` 均返回相同聚合 JSON，event-loop monitor 为 running，且正文不含 debug key。采集器显式绕过进程级 HTTP proxy 后，对控制端口执行 6 秒短时 endpoint gate：无失败，观测到的 recent max/p95 均为 `2.233 ms`，verdict 为 `pass`。
+- 本地实际启动 Box Runtime（未创建 sandbox session）后，`/healthz` 与 `/readyz` 均返回 event-loop、blocking executor、session/process/task 聚合快照；monitor 为 running、样本持续增长，两个端点观测到的 recent max 均为 `2.265 ms`。SIGINT 后 aiohttp、Runtime、reaper 与 monitor 走统一清理路径并正常退出。
+
+## 上线配置与监控门禁
+
+最终 24 小时命令、运行位置、阈值语义、负载矩阵和产物要求见 [LangBot Cloud 24 小时资源 Soak 门禁](./cloud-runtime-soak-gate.md)。该工具默认把任一健康失败、OOM/memory pressure、PID limit、CPU throttling 超阈值、blocking executor rejection、冷却尾段内存持续增长或空闲 CPU 过高判为失败；生产运行必须使用 `--require-hard-limits`。
+
+至少需要监控并告警：
+
+- Core/Plugin Runtime/Box Runtime 的 RSS、CPU throttling、OOM、PID 数和 event-loop lag。
+- 各进程 blocking executor 的 running、pending、inflight、active scopes、`global_rejected_total` 和 `scope_rejected_total`；pending 持续不归零或 rejection 增长都应告警。
+- QueryPool、WebSocket、session、task、plugin worker、Box session 的当前量、容量拒绝和淘汰计数。
+- Plugin crash/restart 频率、dependency prepare 耗时和失败率。
+- PostgreSQL pool checked-out/overflow/wait timeout、事务耗时和连接错误。
+- 临时文件、artifact、dependency environment、Box Workspace volume 的字节数和 inode。
+
+生产 soak 应覆盖租户突发登录、批量插件 reconcile、插件崩溃重启、WebSocket 断连、Box 并发执行、PG pool 饱和和应用 SIGTERM；持续运行至少 24 小时，并验证负载停止后 RSS、task、socket、文件和子进程数量回到稳定基线。