运维
ThreadCells 的日常运维主要在于维护四类事实：正在运行的构建标识、工作流所有权、可用容量和可恢复状态。
日常检查
使用 Home、Agents、Settings → General 和 Settings → Housekeeping 回答：
- 服务器是否健康，且是否正在运行预期的构建？
- 磁盘和容量是 GREEN、YELLOW 还是 RED？
- 哪些主管和工作者确实处于活动状态？
- 是否有已投递但尚未纳入的结果？
- 是否有工作流正在等待所有者决策？
- 如果启用了 Telegram，Settings → Telegram 是否显示预期的安全连接/测试状态？
命令行容量视图为：
threadcells-resource-status使用本地健康端点进行服务监控：
curl -fsS http://127.0.0.1:9889/health启动与停止
在回环地址上运行 threadcells-server，或使用规范的已安装服务。浏览器断开连接不会停止由 tmux 承载的代理。受支持的服务器重启会保留正当活动的终端运行时，随后重新水合持久化的开放工作流和 Inbox 投递状态。已关闭的运行时按精确的终端/进程身份退役；历史会话和结果记录不依赖 tmux 窗格仍然存活。
在计划重启前：
- 检查活动的提供商和重型工作；
- 尽可能避免中断变更操作；
- 记录当前活动与回滚构建标识；
- 为升级备份并完整性检查数据库；
- 只重启必需的 ThreadCells 服务；
- 重新连接，并在重试任何操作前验证工作流/结果。
对提供商生命周期请使用 Graceful Exit。手动杀死 tmux 或删除数据库行可能使终端状态与持久化工作流事实分离。
会话与工作流卫生
已退出的子项不会立即变得可处置。请确认其持久化结果已投递、读取、纳入并确认。随后退役其运行时资源，同时保留历史记录。
Add Agent 的目标是稳定的所选会话生命周期。历史会话删除和已退出终端删除以精确的持久化身份为目标；当存在活动运行时、开放/恢复工作流、写入者租约、待处理结果或其他真实生命周期依赖时，这些操作会被拒绝。保留的日志、受保护的清理 worktree 和退出后的清理声明本身不会阻止逻辑删除：ThreadCells 会保留资源权限、为精确会话写入墓碑，并使重试保持幂等。删除被阻止时会返回具体生命周期冲突，而不是通用的资源不存在/服务器错误。
在同一会话内，Home 和 Agents 的 List 与 Grid 视图都保留后端持久化的智能体创建顺序。状态、提供商、配置文件、活动、轮询、重连和重启都不会重新排列智能体；新创建的智能体会追加到已有智能体之后。
提供商最终回复不会关闭开放任务。仅在所有经所有者授权的工作完成后，才显式完成顶层工作流。仅对真正的决策边界使用所有者门控。
容量变更
Settings → Orchestration Capacity 无需服务器重启即可应用变更。降低限制会排空，而不会杀死活动会话。一次只变更一个约束，并观察预期队列是否改善。
容量变更需要已解锁的操作员会话，并会被审计。请参阅容量和资源模型。
日志与证据
保留足够的日志和结果历史以诊断失败运行，但不要将日志视为唯一的持久化事实。数据库、工作流结果、Git 提交/diff、候选清单和测试证据各自回答不同问题。
避免记录包含凭据的提示或值。ThreadCells 的公开/API 错误应始终可安全显示。
Housekeeping
Housekeeping 始终先规划。检查 dry-run 候选清单和计划标识，然后显式执行该精确计划。执行器会重建当前保护集，并在变更前重新验证每个候选项。它可以退役已证实关闭的终端运行时和已确认的待清理 worktree，而不会抹除持久化历史。
备份仅作清单记录，绝不会自动删除。未知或活动资源始终受到保护。Full Cleanup 是需要单独确认的操作员操作，仅在所有智能体空闲时运行；它保护 Ready 智能体的继续执行权限，并有意移除每个已证实不活跃的本地发布版本，因此本地回滚将不可用。请参阅Housekeeping。
生产变更纪律
升级时：
- 从精确提交构建并验证不可变候选版本；
- 保留当前安装以供回滚；
- 备份并完整性检查数据库；
- 通过规范部署机制进行暂存；
- 提升精确的已暂存候选版本；
- 只重启必需服务；
- 冒烟测试健康状态、UI、提供商预检、操作员授权、工作流、终端和已配置的全局 Telegram 通知。
不要把发布、推送、打标签或变更公开暴露作为本地部署的附带操作。请参阅升级和部署。
出现异常时
清理或重试前先保留证据。记录构建标识、会话/终端/工作流 ID、安全错误消息、相关日志窗口、Git 状态和当前容量。随后使用按症状组织的故障排除指南。