personal-bot 0.2.8 → 0.2.9

package/docs/subagent-upgrade-proposal.md

@@ -1,357 +0,0 @@
-# Subagent 升级方案：独立工作与团队协作
-
-状态：独立模式与两种团队策略在 0.1.3 实现，双成员真实模型单轮冒烟已通过。0.2.0 保留这套执行链路，将子会话 JSONL 交给 Pi 原生存储，不兼容或迁移旧会话布局；此项调整仅做本地 SDK 与无认证进程验证。剩余验收见[验证](validation.md)。当前用法见[专家协作](agent-collaboration.md)。本方案遵循奥卡姆剃刀原则：复用现有运行链路，只补团队必需的规则，不以重构执行器为前置条件。
-
-## 1. 收敛范围与版本
-
-保留两种工作方式：独立委派与持续对话；成员直接交换原文的团队协作。仍由 tmux 和独立 Pi 进程运行成员，不增加协调者模型或后台服务。
-
-团队增量最初采用 **0.1.3**，未更改原有控制字段。随后在 **0.2.0** 中取消旧会话位置兼容，改由 Pi 管理对话文件。该次变更只改变会话定位与恢复契约，不引入先前被删去的统一队列、事件日志或执行器重构；当前发布版本以 package.json 为准。
-
-| 上一版的复杂点 | 本版处理 |
-| --- | --- |
-| 新增 AgentRuntimeService，改造统一 WorkRequest 队列 | 删除；保留 AgentService、现有 inbox 与子入口 pump |
-| 修改 AgentMessage、AgentCycle 的持久结构 | 不修改；团队关联存入独立团队记录 |
-| 团队事件日志、快照和重建 | 删除；一个 team.json 作为唯一团队事实来源，原子更新 |
-| 多层锁与成员 membershipId | 删除；复用现有控制锁，首版固定团队成员 |
-| 动态 ask、返回唤醒、次数预留 | 暂缓；先实现轮流讨论和并行轮次 |
-| uncertain 的独立状态机与 resolve 工具 | 删除；异常暂停，不自动重跑，核查后显式开展新一批工作 |
-| 私人工作与团队工作混合排队 | 不做；团队运行期间独占成员，暂停收尾后才能切换 |
-| 新增团队扫描器与定时器 | 不做；复用父侧 1 秒扫描和子侧 250 毫秒 pump |
-| 新建复杂团队 TUI | 不做；先用 Pi 原生列表、输入与查看对话框 |
-| 先升级 Pi 再开发 | 团队最初在 Pi 1.1.0 验证，不以升级为前提；当前依赖已升级至 1.5.0 |
-
-首版限于同一工作区、同一父 session，一个 agent 最多属于一个未关闭团队。成员在 create 时确定；需要换人时关闭旧团队、用原 agent 创建新团队，历史保留。团队关闭不停止成员，成员仍可继续独立工作。
-
-这不是无边界的自由 swarm：成员能直接读写公共消息，代码按有限轮次请求回应。动态点名唤醒、热增减成员、跨团队私信、多机通信和任务 DAG 等出现明确需求后再设计，不预留通用插件接口。
-
-## 2. 现有代码如何复用
-
-主链路不变：
-
-```text
-pbot_agent → AgentService → AgentFiles.inbox → 子入口 pump
-                                       ↓
-                           Pi 原生会话与完成记录
-                                       ↓
-                            原有父侧扫描与通知
-```
-
-团队在这条链路旁增加一份记录：
-
-```text
-pbot_team → TeamService → team.json（成员、轮次、公共消息）
-                              ↓ 生成普通父侧发言请求
-                  AgentService.enqueueTeam → 原 inbox
-                              ↓
-                子入口注入团队原文，执行既有任务链路
-                              ↓
-             父侧读取既有 completion → 保存公开答复 → 下一位/轮
-```
-
-主模型不读取、改写后再转发成员发言。父进程运行调度代码即可，主模型可以同时处理其他独立任务。
-
-保留现有模型、cwd、工具、MCP、技能、Python、50 个存活子进程上限、分支归属和 stop/resume 规则。没有团队记录时，原独立流程保持原样。
-
-## 3. 最小数据与存储
-
-### 3.1 不改旧持久契约
-
-以下结构保持字段和含义不变：AgentDescriptor、AgentLaunch、AgentMessage、AgentStatus、AgentCycle。
-
-团队发言请求也是父侧发起的请求，继续使用已有 requestId、generation、sequence 和 cycle.requestIds。cycle.source 仍为 parent/interactive/mixed，不增加 team 枚举。是否属于团队，通过 requestId 查团队记录，而不是从提示词中解析。
-
-原子 JSON、文件路径校验与目录权限继续复用，不加哈希校验、存储版本计数或迁移代码。
-
-### 3.2 原生对话与独立控制记录
-
-```text
-当前 Pi agent dir/
-├── sessions/<Pi 编码的 cwd>/<时间戳>_<agentId>.jsonl
-└── pbot/
-    ├── subagents/<agentId>/
-    │   ├── 原有 descriptor、launch、inbox、status、completions
-    │   ├── session-ref.json   # 原生文件引用；首次输入前为 null
-    │   └── team-ready.json    # 仅表示当前代次支持团队接入
-    └── teams/<teamId>/team.json
-```
-
-sessions 的实际位置遵循子进程的 Pi 原生配置。新建使用 `--session-id <agentId>`，首次输入前固定文件引用，恢复使用 `--session <绝对路径>`。pbot 不生成原生文件名、不复制 JSONL，也不为了空待命会话落盘而伪造消息。完整规则见[文件存储](file-storage.md)。
-
-team.json 的领域结构如下。嵌套数据不是独立服务或另一套执行框架。
-
-```ts
-interface TeamRecord {
-  teamId: string;
-  release: string;
-  workspace: string;
-  parentSessionId: string;
-  parentLeaf: string | null;
-  name: string;
-  brief: string; // 目标、范围、交付要求；不是新增执行授权
-  closed: boolean;
-  members: { agentId: string; role: string }[];
-  runs: {
-    runId: string;
-    instruction: string;
-    mode: "roundRobin" | "parallel";
-    rounds: number;
-    maxConcurrent: number;
-    deadlineAt: number;
-    generations: Record<string, string>; // 本批次成员的既有启动代次
-    state: "running" | "paused" | "finished";
-    reason?: string;
-    issued: {
-      requestId: string;
-      agentId: string;
-      generation: string;
-      round: number;
-      throughSeq: number;
-    }[];
-  }[];
-  messages: {
-    seq: number;
-    operationId: string;
-    author: { kind: "user" | "coordinator" | "member"; agentId?: string; name: string };
-    text: string;
-    replyTo?: number;
-    runId?: string;
-    source?: { requestId: string; cycleId: string };
-  }[];
-}
-```
-
-- issued 只记已安排的请求及关联，不复制 accepted、running、completed 等 agent 执行状态；这些继续从 status/completions 读取。
-- run 保存成员现有 generation 的快照，不引入新的代次计数；stop/resume 后的新代次不能接管旧批次。
-- 每个 runId 下，每位成员每轮最多一个 requestId。轮次进度由 issued 和完成记录计算，不再维护一套调度游标。
-- messages 只增不改。seq 在锁内递增；replyTo 引用同一团队的消息序号。
-- operationId 用于同一发布操作去重；最终答复使用关联 requestId 的固定操作 ID。并非按正文相似度去重。
-- 作者由入口绑定。模型不能指定自己是用户或冒充其他成员。
-- 单文件适合首版短时、小团队讨论，避免跨文件提交协议。暂不做分片、归档或自动清理；有实际规模问题后再调整。
-- 一次扫描只读取相关团队快照一次并建立 requestId 索引，不在每条 inbox 消息上重扫全部团队。写操作仍在锁内重新读取，不把过期快照覆盖回文件。
-
-team-ready.json 只含 `{ generation, ready }`。新子入口完成注册后写 ready=true，关闭或 reload 前写 false。父侧要求标记代次与 launch 一致且进程存活。它不是 schema 版本或工作区启用开关。
-
-同一兼容线内缺少就绪标记的成员不能接团队请求，可在空闲时 reload 子入口或 stop/resume。0.1.x 使用旧会话布局，不能通过 reload 或 resume 接入 0.2.0；更新前停止旧进程，再新建成员。不重启旧任务，不改写旧 descriptor.release。
-
-## 4. 工具契约
-
-### 4.1 pbot_agent：仅作局部扩展
-
-- 原 action 保留，独立模式的 send/steer/followUp 语义不变。
-- start 未提供 message/prompts/files 时只启动待命进程，不 enqueue、不调用模型。返回值不含 requestId/messageStatus，原 schema 已允许这两个字段缺省。
-- 无初始请求的待命进程被停止时，不生成“任务交付前退出”的虚假失败。
-- 团队正在运行或该成员还有已领取的团队请求未收尾时，私人 send 返回 `TEAM_BUSY`，无论 steer 还是 followUp；不另建私人等待队列。
-- read/status/rename/stop 仍可使用。stop 使相关团队批次暂停；resume 仍须新要求，不恢复旧团队请求。
-
-用户切换工作方式的路径是：`pause → 等在途工作结束，必要时 stop → 独立 send/resume`。其他未被团队占用的 agent 始终可以独立工作。
-
-### 4.2 pbot_team：主会话管理
-
-| action | 参数与行为 |
-| --- | --- |
-| create | name、brief、members[{agentId, role}]；固定成员，不创建子进程，不启动模型 |
-| list/status | 查询当前父会话的团队，显示归属、成员状态、轮次、在途请求和结束原因 |
-| read | teamId、afterSeq、limit；也可按 seq 与 offset/limit 读取单条长消息 |
-| run | teamId、instruction、mode、rounds、maxConcurrent、timeoutSeconds；启动新批次 |
-| pause | teamId；停止新的领取与安排，不中断已领取请求 |
-| close | teamId；仅在已暂停/结束且无在途工作时关闭，否则返回忙碌状态；不阻塞等待，保留全部记录 |
-
-run 的建议默认值为 2 轮、15 分钟；rounds 首版限定 1–10。roundRobin 的并发固定为 1；parallel 默认并发为成员数与 2 的较小值，可在 1–成员数之间调整。总请求数最多为成员数乘轮数，没有额外回调次数预算。
-
-run 的前置条件：团队可操作、未关闭、没有其他运行批次或仍在执行的旧团队请求；所有成员属于当前可操作分支、进程空闲、没有未消费的普通 inbox 输入，且 team-ready 有效。条件不满足直接返回具体成员与原因，不引入“等所有人就绪”的后台任务。
-
-post 使用工具调用 ID 或 UI 操作 ID 去重，任务入队按 requestId 去重。create/run 的写入结果不明时先查询 list/status，不自动再次创建；不为此增加通用操作登记表。调用返回只表示记录/请求已保存，不表示模型完成。
-
-### 4.3 pbot_team_message：公共通信
-
-只保留 read/post。主会话与成员都可使用，read 复用团队读取实现。
-
-post 参数为 teamId、text、可选 replyTo。正文沿用现有消息量级上限 24000 字符；长证据引用工作区文件。所有成员可读同一公共记录，不提供伪装成私信的 to 参数。
-
-成员入口绑定 agentId/generation；成员发言限于自己的团队工作。主会话可以在团队暂停时补充公共信息，再通过 run 请求下一批回应。普通 post 不启动模型、不改变轮次、不触发主模型处理。
-
-读取返回 seq、作者、原文、回复关系与分页信息。正文截断必须标明剩余位置；不得把展示摘要当作完整记录。首版不提供 ask、wait 或自动返回唤醒。
-
-## 5. 请求投递：沿用 inbox，先关联后发布
-
-### 5.1 仅一个控制锁
-
-复用 `AgentFiles.control()`，团队修改、团队输入的领取、普通 send 的占用检查均使用该锁。TeamFiles 不再创建第二种锁。所有操作短时同步完成；锁内不等待模型、认证、进程退出或 UI。
-
-这保证两个关键顺序：
-
-1. 两个团队不能同时占用同一个 agent。
-2. pause 与子侧领取有确定先后；先领取的算在途，先 pause 的不再领取。
-
-普通锁竞争由下一次扫描重试，不重发工作。实现时只把建锁的 EEXIST 作为占用，并补充稳定错误码；权限、磁盘等错误直接失败，不靠中文报错文本分支。坏文件和崩溃遗留锁仍报错，不自动删锁。
-
-### 5.2 父侧安排一位成员
-
-1. TeamService 根据现有完成记录选出下一位或本轮可并行的成员。
-2. 锁内再次检查团队状态、分支资格、成员 generation、空闲情况和期限。
-3. 生成 requestId，把 agentId/generation/round/throughSeq 写入 team.json 的 issued，原子保存后释放锁。
-4. 调用 AgentService 新增的窄方法 enqueueTeam；该方法再次在锁内检查关联、团队状态、generation 和 team-ready 仍有效，再使用原 AgentFiles.enqueue 写普通 AgentMessage。
-5. 输入正文只描述父侧安排的本次发言任务、公开答复要求和团队标识；成员原文通过独立的 custom context 注入，不改写成用户命令。
-
-AgentFiles.enqueue 只需增加可选的预定 requestId。没有该参数时保留原行为；已有相同 ID 时核对代次与输入后返回原请求，不再次增加 sequence，不覆盖。无需新消息类型或新 inbox。
-
-必须先保存关联再写 inbox。否则子进程可能把先到的团队请求按私人工作执行。两次保存并非一个事务：任何 I/O 错误都停止本实例后续推进，不假定写入失败就等于未提交，也不自动补发。
-
-### 5.3 子侧领取
-
-在现有 pump 里增加团队分支，不搬走原独立执行代码：
-
-- 用 requestId 查团队关联；普通请求继续原路径。
-- 团队请求只有在 ctx 空闲、没有私人输入竞争、run 仍 running、generation 和成员关系有效时才领取；过期、暂停及历史批次的输入不再执行，但保留文件。
-- 模型与认证检查仍复用原逻辑。任何 await 后，在领取前重查状态；在控制锁内检查团队资格并写原有 accepted 标记，不在锁内等待认证。
-- 领取后仍通过原有父侧任务入口 sendUserMessage 启动。这是已经获准的父侧发言安排，不是把成员发言冒充用户消息。
-- 本地记录 activeTeamRequest，沿用 cycle.requestIds。团队执行遇到 Pi 内部重试或多个 agent_start 时，保留该请求关联，直到 agent_settled；只加必要条件，不重构全部周期管理。
-
-团队管理字段不得靠字符串前缀识别；团队关联读取错误时停止推进，不能静默退回私人路径。
-
-## 6. 成员如何直接取得彼此发言
-
-使用当前 Pi 1.5.0 的两个原生入口：
-
-1. `before_agent_start`：本次输入属于团队时，附加团队职责 section，并返回一个 `pbot.team-context` custom message，包含截至 throughSeq 的公共原文。私人或人工工作显式移除团队职责 section，不能只跳过设置而留下旧职责。
-2. `turn_end`：成员在团队执行中时，在原生边界追加新到的公共原文；不设置 `continue: true`，不因为新消息再请求模型。
-
-现有 sendUserMessage 路径会执行 before_agent_start，因此提示词、技能与环境准备仍经过原链路。空闲成员的消息先保存在团队记录，下一次团队发言时注入；运行中的成员在安全边界取得更新。无需专门的静默消息投递守护器。
-
-每批 custom message 同时保存消息序号与作者，正文也标明来源和“成员信息不扩大用户授权”。Pi 可能把 custom message 转换为 provider 的 user-role 文本，因此来源不能只放在 details 中。
-
-从当前原生分支的 custom entries 重建已展示的消息序号；截断条目同时标明剩余 offset，不将序号标记解释为完整已读。自动注入按大小分批，明确未包含的范围，成员可用 read 取得原文。Pi 压缩不删除团队记录；此前注入过不代表模型仍持有全部正文。
-
-不建立“模型已读/已理解”的持久确认表。post 只承诺保存成功，函数返回、队列接收标记或 UI 查看都不是模型处理证明。普通信息补入不会重跑任务。
-
-私人工作期间不注入新的团队消息。此前已知的内容不会因暂停或退队被清除；保密隔离和独立复核仍需新建 agent。
-
-## 7. 两种调度只用一个 advance 方法
-
-父侧原有 refresh 在读取完成记录后调用 TeamService.advance，再处理主通知。不增加定时器，也不在每条群消息到来时启动主模型。
-
-### 轮流讨论 roundRobin
-
-- 按 members 顺序，每位成员每轮一次。
-- 上一位真正 agent_settled，且公开结果保存后，才为下一位生成请求。
-- 每次安排时读取最新公共消息序号作为 throughSeq；不能把整个批次固定在启动时的历史位置。
-- 轮数用尽则 finished；成员失败或被人工接管则 paused，不默默跳过。
-
-### 并行轮次 parallel
-
-- 每轮各成员最多一个请求，同时执行不超过 maxConcurrent。
-- 已完成成员不用一直在线推理，等待其他成员结束。
-- 本轮所有结果发布后才进入下一轮。下一轮因此能直接阅读上一轮其他人的原文并回应。
-- 并发占槽包括已安排但尚未领取的请求，不能只数 busy 进程；生成一批 issued 时就计入，防止下次扫描超发。
-- 同轮成员也可以 post/read 交流，但 post 不追加新请求或形成相互唤醒链。
-
-这不是固定研究流程，轮内可以做研究、计算、实现或审查。只固定执行时序，不在代码中固定专业步骤。需要在首轮汇合后继续讨论，用下一轮或新的 run，不通过递归委派实现。
-
-### 公开结果与主通知
-
-父侧继续使用现有 completions 和固定叶节点的报告读取。只有完成记录与 issued 的 requestId/generation 匹配、该周期未混入人工输入且正常完成时，才把最终答复原文保存为团队消息。发布按 requestId 去重；这一步由代码完成，不调用主模型总结。
-
-人工插话使周期保持原有 mixed 来源，暂停团队，不自动公开混合答复。中途显式 post 已公开的内容保留。业务成功、共识和用户授权不从 completed 状态推导。
-
-已关联团队的周期不再同时走逐个 agent 的自动完成通知。主模型只收到批次结束、暂停/失败及所需处理事项；收据沿用原生父会话与分支检查，按 teamId/runId/结果事件去重。用户仍可通过 pbot_agent read 查看成员报告。
-
-## 8. 暂停、恢复和故障规则
-
-这里选择保守且容易实现的规则，不建立通用恢复状态机。
-
-| 情况 | 处理 |
-| --- | --- |
-| 用户 pause 或主侧中断 | 保存 paused，禁止新增安排和领取；已领取的工作继续收尾 |
-| 需要立即停止在途成员 | 使用现有 pbot_agent stop；不再增加另一套 cancel 工具 |
-| 成员失败、停止、代次变化 | 暂停批次，显示现有状态与报告，不自动 resume |
-| 主 reload | 团队暂停；保留子进程及在途结果，不自动续排。独立模式原有 reload 行为不变 |
-| 主退出或切换 session | 先暂停团队，再执行现有子进程清理 |
-| 主 session 恢复、子 reload 或异常退出 | 恢复记录，核对已有完成事件，不自动重跑旧批次 |
-| 父分支失去团队或成员归属 | 暂停新增调度与主模型结果投递；在途结果仍可保存 |
-| 达到 deadlineAt | 不再安排/领取；子入口仅中断自己当前且未被人工接管的团队工作，不停止无关私人工作 |
-| close | 要求没有仍在执行的团队工作；关闭后只读，不删除记录、不停止 agent |
-
-pause 返回时可能还有在途请求；status 明确显示它们。只有它们已结束或进程确已停止，才能开始新的独立工作或新的团队批次。暂停批次中尚未领取的输入不再占用成员；它们保留在 inbox，但子入口按旧 run 关联跳过，不能阻塞后续私人输入。
-
-继续讨论用新的 runId、新 instruction 和新的有限轮数。旧批次保留原状，不把旧 requestId 重置为待执行。对于无法确认的历史执行结果，先查原生报告和外部状态；新 run 不是“自动重试失败步骤”。
-
-### 三个崩溃窗口
-
-| 窗口 | 恢复动作 |
-| --- | --- |
-| 团队关联已保存，inbox 尚未写入 | 团队暂停，展示未收到结果的安排；不在恢复时自动补发 |
-| accepted 已写，模型是否执行不明 | 保留未知事实、暂停；不能据此判断已完成，也不能重新执行旧请求 |
-| completion 已保存，公开答复尚未保存 | 可以根据原固定报告补交付，按 requestId 去重；不调用模型 |
-
-同一原则适用于原子发布后的 I/O 错误：停止后续写入和发起工作，不因再次读取成功就假定上一次没有副作用。
-
-## 9. 具体改动清单
-
-新增领域模块限于一份数据定义、一个服务和一个存储文件。工具与简单命令按现有分层放置。
-
-| 文件 | 最小改动 |
-| --- | --- |
-| `src/model/team.ts`（新增） | TeamRecord 与 team-ready 的数据类型 |
-| `src/storage/team-files.ts`（新增） | team.json 与就绪标记的读写、校验；复用 atomic-json 和原控制锁，不实现调度 |
-| `src/services/agents/team-service.ts`（新增） | create/run/pause/close、post/read、关联查询、advance；业务规则集中于此 |
-| `src/tools/teams/contract.ts`、`tool.ts`（新增） | 两个工具的 schema、执行适配和结构化结果 |
-| `src/extension/teams-command.ts`（新增） | `/pbot teams` 的原生列表、查看和输入；调用同一服务 |
-| `src/services/agents/agent-service.ts` | 无任务 start；私人 send 占用检查；窄的 enqueueTeam；空闲无任务退出不伪造失败 |
-| `src/storage/agent-files.ts` | enqueue 接受预定 requestId 并去重；必要的锁错误码；旧存储结构不变 |
-| `src/extension/subagent-entry.ts` | team-ready、团队领取检查、本地关联、上下文注入与人工插话处理；保留原 pump/finish |
-| `src/extension/agent-events.ts` | 在原 refresh 中推进团队；过滤重复个人通知；使用原有通知边界 |
-| `src/pbot.ts`、`lifecycle.ts`、工具注册与命令入口 | 装配 TeamFiles/TeamService；关闭前暂停团队；显式注册主/子工具 |
-| 现有角色与技能 | 补充公共发言、轮次、独立复核与授权说明，不内置专业流程 |
-
-不改既有 agent 控制类型；0.2.0 只新增原生会话引用类型。保留 PiAgents，不创建 AgentRuntimeService、通用消息总线、调度策略接口或单独 team-events 扫描循环。
-
-TeamService 接收普通成员状态与完成记录，返回待投递的父侧请求；AgentService 负责实际入队和再次校验。AgentService 可读取同一 TeamFiles 检查占用，不反向依赖 TeamService，避免服务循环依赖。Pi ctx 与模型事件仍留在现有接入代码。工具继续绑定工作区实例，关闭后旧调用失效；关停顺序先禁用新增工作并暂停团队，再按原逻辑释放子进程。
-
-`/pbot teams` 首版提供列表、读记录、post、run、pause、close 和进入原成员 TUI。查看不领取模型通知，不抢占现有确认对话框。无 TUI 时使用同样的结构化工具，不另写终端框架。
-
-## 10. 兼容性与验收顺序
-
-### 兼容性
-
-- 0.2.0 不兼容旧会话布局，0.1.x 记录留在原位置，不迁移、不接管或删除；更新后新建 agent。
-- 原 descriptor、launch、inbox、status、completions 字段不变；新增会话引用和团队数据放在独立文件中。
-- 版本兼容与运行能力分开判断：同一兼容线内还须核对 team-ready，不能只靠版本字符串猜测能力。
-- 降级前关闭团队并停止相关进程；不承诺旧子入口能安全参与新团队协议。
-- 不自动导入配置，不增加工作区格式、升级系统或存储版本计数。
-- 开发依赖现锁定 Pi 1.5.0；测试按新版结构化触发对象调用 before_agent_start，验证用户/custom 消息入口与 turn_end 本地契约，不增加旧 SDK 适配层。
-
-### 三个实现步骤
-
-1. **团队基础**：新增 TeamFiles/TeamService、无任务 start、预定 requestId 入队与 team-ready；验证独立行为和新记录原子性。
-2. **最小可用团队**：create/run、轮流讨论、post/read、上下文注入、结果发布和暂停；用原生命令提供入口。
-3. **并行与收尾**：增加同一 advance 中的并行轮次分支，补全通知、生命周期和真实多模型验收。
-
-上述团队步骤在 0.1.3 完成。0.2.0 保留执行器与控制字段，另将对话位置交回 Pi，并新增原生会话引用测试。双成员真实模型单轮冒烟针对 0.1.3；新布局的真实模型恢复、多轮/异构模型协作、长时间运行与完整 TUI 验收仍未完成。
-
-### 具体测试风险
-
-使用 node:test、真实本地文件、进程和 Pi SDK；不使用假模型、模拟 provider、个人凭据或真实交易。
-
-- 独立 start/send/read/stop/resume、50 进程限制、原生会话引用与固定叶节点报告；旧布局记录不被迁移或误接管。
-- 无任务 start 不发起模型请求，停止待命进程不伪造失败；旧子入口不能误消费新团队请求。
-- 同一 requestId 入队不增加两次 sequence；团队关联先于 inbox 发布；真实 I/O 错误不自动重发。
-- 团队 run 与私人 send 竞争、两个团队争用同一成员、pause 与领取竞争都有确定结果。
-- 轮流顺序、并行上限、轮间汇合、期限、失败暂停，以及运行中 post 不增加模型请求。
-- 当前 Pi SDK 的 before_agent_start custom message 与 turn_end 追加顺序；不拆开工具调用和结果，不依赖字符串判别任务。
-- Pi 内部多次 agent_start 不丢团队 requestId；人工 mixed 输入不被自动公开。
-- 团队 JSON 并发更新不丢消息；长消息分页；结果补交付不重跑、不重复发布。
-- 主/子 reload、退出、分支和代次变化后不续排旧批次，主通知不重复、非所属分支不接收结果。
-
-双成员、两种策略各一轮的真实模型冒烟已记录于[验证](validation.md)。剩余真实模型验收包括：A/B/C 在主模型不逐条介入的情况下完成多轮讨论；并行轮次能引用其他成员原文；其他 agent 可同时独立工作；暂停后成员可回到独立工作。连接和测试通过不代表模型理解、业务成功或外部操作恰好一次。
-
-## 11. 源码参考的最小取舍
-
-| 来源 | 本版只采用的部分 |
-| --- | --- |
-| [YoungJurry/pi-agents](https://github.com/YoungJurry/pi-agents/blob/ec2827cdc0a3bbcdb738fc88d8c277a089af48b7/tools.ts) | 信息与执行请求分开；不引入其 agent 树和统一调度器 |
-| [pi-relay](https://github.com/nicknisi/pi-extensions/blob/ef9ab9986584e11541aedd541d0b696e7b83ef8a/packages/relay/index.ts) | 稳定消息身份与“不把发送返回当作处理完成”；不照搬另一套信箱 |
-| [pi-messenger-swarm](https://github.com/monotykamary/pi-messenger-swarm/blob/f70a0e6776ce074b23a13778de90614ee9d47b1e/channel.ts) | 公共记录独立于私人会话；不引入服务进程、任务板或事件日志重建 |
-| [sloanb/pi-roundtable](https://github.com/sloanb/pi-roundtable/blob/72c4177c241604a2cbb7f2db171be69534d3e20d/lib/roundtable.mjs) | 代码轮流点名、直接提供讨论原文；保留 pbot 持久进程与原生会话 |
-
-这些是源码设计参考，不表示已经安装运行验收。业务授权、工具接入与副作用处理继续遵循[工具与执行](capability-design.md)。团队通信与成员占用规则不是宿主安全隔离。

package/docs/validation.md

@@ -1,189 +0,0 @@
-# 验证
-
-## 本地检查
-
-```bash
-npm run check
-npm test
-git diff --check
-npm pack --dry-run
-```
-
-完整开发与验收使用 Linux、Node.js 24.9+；Pi 与独立 CLI 消费路径保留 Node.js 22.19+。CI 使用 Node 24.x 安装完整开发依赖、执行全量检查并构建候选包，再由独立 Node 22.19.0 作业安装同一 tarball，检查无宿主 SDK 的 CLI 与显式安装 Pi SDK 后的扩展、工具、技能及资料初始化。消费者检查不安装 dsh 开发依赖，也不调用模型。npm test 先构建 dist 和 CLI、dsh Host/Web 的 lib，再串行执行 Node 测试。测试使用真实本地文件、进程、计算、Pi 1.5.0 与开发基线 dsh 0.2.2-rc.1 SDK。Pi 开发依赖与相关传递组件统一锁定 1.5.0；宿主提供的包声明为 optional peer，不增加运行时副本。发布包包含 bin/lib，扩展仍由 Pi 加载 src，dist 不进入发布包。
-
-| 范围 | 检查内容 |
-| --- | --- |
-| 领域与基础模块 | 工具契约、状态转换、版本兼容、原子保存和非法路径 |
-| tests/installation/ | 真实子进程、Pi 原生配置、来源与资源过滤保留、过期计划、CLI 打包入口、无模型认证时的初始化分发与拦截 |
-| tests/smoke/ | 实际 tarball 加载、资料准备、独立 Python setup 脚本 |
-| tests/e2e/ | Pi SDK/RPC 命令与工具、确认、持久化、重启和 Bash 环境继承 |
-| tests/integration/ | Pi 首轮上下文、原生差量、技能禁用与包过滤、init 后的原生 reload、必需资料读取失败时取消 |
-| tests/dsh/ | 真实 Agent/Session、代次与占用、附件、文件规则、团队、通知、双来源 history、原生 Remote、preset 继承、资源可见性与生命周期 |
-| 历史并发 | 真实多进程与来源短锁，拒绝过期扫描和摘要覆盖，损坏来源隔离与独立取消 |
-| 专家协作 | 真实 tmux/Pi 进程、无任务待命、原 inbox、消息顺序、分支归属、通知领取和异常退出 |
-| 历史查询 | 真实 SDK 保存的问答、补充输入、工具过滤、分支隔离、四叉分组、原文与摘要搜索、正文分页、重载复用、空会话不误报、旧目录复制、跨目录读取、缺失原文时保留存档、旧路径清理、按会话 ID 重新关联与工具契约 |
-| 原生会话存储 | 真实 CLI 的默认 cwd 目录、settings/环境变量优先级、tmux 旧环境覆盖、空待命恢复、进入已停止会话不入队或重放旧任务、绝对路径绑定、身份检查、固定叶节点只读报告与旧布局保留 |
-| 团队协作 | 轮流顺序、并行上限与轮间汇合、暂停/领取、原文分页、并发保存、mixed 隐私边界与未知结果 |
-| 团队宿主接入 | Pi 1.5.0 的用户/custom 消息 before_agent_start、turn_end、原生 context 去重、子 reload 不重跑、窄通信工具与实例关闭 |
-
-冒烟与 E2E 可分别运行 npm run test:smoke 和 npm run test:e2e。驱动直接提交工具输入，不生成模型响应。打包冒烟复用本地已安装依赖。
-
-团队服务测试使用实际文件和结构化历史执行记录，不生成模型响应。Markdown 上下文与报告检查原文保真、嵌套代码围栏、渲染长度、续读位置、来源关联与分支去重；工具继续校验原有结构化 schema，不对提示词全文做快照断言。进程验收使用隔离的 Pi 认证目录与 tmux 服务，验证待命和无认证失败路径，不调用真实模型；这不等于完整多模型协作已通过验收。
-
-0.2.0 的会话存储测试不调用模型。真实 CLI 观察扩展只记录会话身份、路径和原生模型状态；历史输入通过实际 SDK 保存。测试覆盖引用 I/O 失败阻断输入，以及缺失、空白、无效、错误身份/cwd 和非普通文件在 generation/入队变更前拒绝恢复。无认证环境只能验证不以初始模型选项覆盖原生恢复；保存模型的认证恢复成功仍需获准环境验收。
-
-新增输入与通知检查使用真实本地附件和 Pi SDK：验证多附件来源、图片内容与原生截断续读，报告不可读时 status 仍可查询，工具拒绝缺项及跨 action 字段，以及故障通知进入模型上下文并遵循中断。通知回归使用真实控制锁与时间，检查暂停持续受阻后的延迟通知、去重和锁释放后的恢复；损坏的团队记录用于检查已通知的读取错误升级为需重载故障时再次通知，以及修复存储后仍须原生 reload 才恢复团队工具。这些检查不验证通知文案、真实模型的工具选择或提示优化效果。
-
-Node 测试不下载第三方 Python 依赖；原生库集成验证见 [Python 说明](../python/README.md)。
-
-## Pi 1.5 本地回归
-
-开发依赖及全部 8 个 Pi 传递组件统一锁定 1.5.0。macOS、Node.js 24.22.2、npm 11.19.1 下，`npm run check`、`npm test` 和正常 prepack 打包通过；125 项测试全部通过，无跳过。补充 9 项包接入回归通过，实际资源加载检查扩展错误与包警告均为空。
-
-全仓版本检查覆盖源码、测试、脚本、CI、资料、文档和锁文件。自有依赖与当前使用说明已统一到 Pi 1.5.0。固定版 dsh 的第三方 `dsh-llm-pi-ai` 仍声明 `pi-ai: ^1.3.0`，当前锁文件与安装树均解析到 1.5.0，没有旧版 Pi 副本；不改写第三方发布包的依赖范围。既有 Pi 1.1/1.4 验收记录保留原版本。
-
-实际 tarball 在隔离消费者目录通过 `scripts/check-consumer.mjs` 验证：独立 CLI 无需 Pi/dsh SDK，显式安装 Pi 1.5.0 后扩展加载无错误或包警告，四个工具、技能和 `/pbot init` 均通过，不发起模型请求。
-
-上述 Pi 1.5 本地批次未调用真实模型，也未重新执行 Linux、Node.js 22.19.0 或人工 TUI 验收。后续 CI 结果单独记录如下，不改写本地批次的范围。
-
-## CI 与发布（2026-11-06）
-
-以下记录限定为提交 `1625a78af324de412ba12b0689de6c9ebde61698`、`personal-bot@0.2.6`，Pi SDK 为 1.5.0，dsh 为 0.2.2-rc.1。
-
-- [CI 运行 42242658306](https://github.com/realqiyan/personal-bot/actions/runs/42242658306)：Ubuntu、Node.js 24.22.2、npm 11.19.1 下，`npm ci --ignore-scripts`、`npm run check`、`npm test`、`git diff --check` 均通过。125 项测试全部通过，无失败或跳过；依赖边界为 135 个模块、554 条依赖。package 作业正常执行 `npm pack`，包括 prepack 的检查、CLI 构建和 dsh Host/Web 构建。
-- 同次 CI 的 pi-consumer 作业使用 Node.js 22.19.0、npm 10.9.3，安装同一候选 tarball。独立 CLI 与显式安装 Pi 1.5.0 后的扩展加载、四个工具、技能、`/pbot init` 均通过，不调用模型。
-- [发布运行 42242680832](https://github.com/realqiyan/personal-bot/actions/runs/42242680832)：同一提交的 OIDC 发布及 `Verify public version and latest` 成功。公开 npm registry 的只读核对确认 `personal-bot@0.2.6` 存在、`latest=0.2.6`，导出包含 `./lib/dsh.js` 与 `./lib/client.js`，dsh 元数据包含 Host/Web 所需的 bundle/client 声明。
-
-这些结果补齐了该提交的 Linux 全量、Node.js 22.19.0 Pi/CLI 消费者和远端发布检查。独立消费者作业仅覆盖 Pi/CLI；dsh 本地 SDK 测试不代表候选包的包根 Web 加载及 Remote 传输已自动验收。下文保留此前 tarball 的 Web/桌面人工验证；公开版本和元数据核对不代表 0.2.6 已从 registry 完成全新 npx、Pi 或 dsh 安装，也不证明完整桌面模型流程。人工 TUI、成功模型调用、摘要取消和长运行缺口仍保留。
-
-## 文档校正与安装来源回归（2026-11-07）
-
-本次记录针对基于 `1625a78` 的文档校正及安装来源检查修复，不属于已发布 0.2.6 的验收记录。macOS、Node.js 24.22.2、npm 11.19.1 下，`npm run check`、`npm test`、`git diff --check` 与正常执行 prepack 的 `npm pack --dry-run --json` 均通过；127 项测试全部通过，无失败或跳过。
-
-新增两项回归使用隔离的用户/项目配置、真实文件、子进程和 Pi SDK，检查缺失本地目录、未安装 Git 来源及无有效包名目录在计划前被拒绝，原配置保持不变；来源修复后能识别为保留项，独立单文件扩展与未安装 npm 声明仍可识别。测试没有执行联网安装或调用模型。本次改动未重新执行 Linux、Node.js 22.19.0、人工 TUI 或 dsh Web/桌面验收；前节 CI 结果仅适用于其记录的提交。
-
-## dsh 命令与版本策略（2026-11-07）
-
-当前源码的 dsh 安装示例改为 `latest`，`engines.dsh` 改为最低版本 `>=0.2.2-rc.1`，dsh SDK 保持 optional peer、范围为 `"*"`；开发依赖及解析版本仍为 0.2.2-rc.1。已同步中英文 README，并提供内容对应的[中文](dsh.md)和[英文](dsh.en.md)完整指南。已发布的 0.2.6 元数据没有被改写，本次范围放宽需后续发布才作用于 registry 安装。
-
-npm 只读查询确认当时 `latest=0.2.2-rc.1`、Node.js 要求为 `>=24.9.0`。实际运行原生 CLI 版本与帮助，在临时 DSH_HOME、HOME 和工作目录创建独立 Web profile、导出配置及读取 Web 帮助；未启动个人 profile 或调用模型。插件命令参数对照原生转发实现与 pnpm 文档核对，本机 PATH 没有 pnpm，因此本轮没有实际安装、更新或移除 profile 插件。
-
-使用真实 dsh `evaluatePluginCompatibility` 检查最低版本、后续版本和预发布版本字符串，并核对 package.json 与 shrinkwrap 的范围一致；这只验证范围语义，不代表那些后续版本的运行验收。macOS、Node.js 24.22.2、npm 11.19.1 下再次执行 `npm run check` 与 `npm test`，127/127 通过，无失败、取消或跳过，依赖边界为 135 个模块、554 条依赖。`git diff --check` 及正常执行 prepack 的 `npm pack --dry-run --json` 通过；267 个包条目包含两份 README、中英文 dsh 指南、Host/Web 产物和包/锁文件。
-
-同日此前的全量复测还在已准备的用户级 Python 3.12.16 venv 中执行隔离模式的 `pip check` 与 `python/tests` 原生库测试，依赖检查和 5/5 测试通过；未安装或升级依赖。本轮文档和包声明修改后未重复计算库测试。Linux、Node.js 22.19.0、真实 Web/桌面插件安装及成功模型工作流的范围仍以上述既有记录为限。
-
-## 模型上下文审查（2026-11-07）
-
-本次针对基于 `1625a78` 的未发布工作区修改，覆盖 Pi/dsh 主会话、专家、团队任务及两种历史摘要入口，内容取舍与加载方式见[模型上下文](model-context.md)。macOS、Node.js 24.22.2、npm 11.19.1、Pi 1.5.0、dsh 0.2.2-rc.1 下，`npm run check`、`npm test`、`git diff --check` 均通过；135 项测试全部通过，无失败、取消或跳过，依赖边界为 137 个模块、558 条依赖。该总数包含当前工作区的安装与通知回归，不全是本次新增测试。
-
-- Pi 使用真实资源加载器和 `_prepareRun` 观察认证前的主会话、专家首轮及后续差量，核对原生 AGENTS、用户职责补充、工具声明、技能目录、精简环境和条件性团队内容。主会话 no-skills、包级 `skills: []` 过滤均生效；未变化的 section 不追加，角色修改在下次准备时可见。新建 AGENTS 在原生 reload 后加载，已有内容保持原样。
-- Pi 主会话与真实专家入口分别用不可读取的职责文件触发加载失败，实际 custom-message run 的原生 abort 信号已设置，未进入 provider 请求，tokens 为零。此处检查取消与调用时序，不以错误文案或唯一 stopReason 判断成功。
-- dsh 使用真实 preset、Agent/Session 和原生文件/技能工具，核对专家 create/resume 的 preset 继承、首轮 AGENTS 和工具可见性、角色当次刷新、原文保真，以及项目/用户/包技能的优先级、文件更新监听和卸载生命周期。complete persona 保留宿主覆盖规则；noSkills 隐藏模型技能目录和工具，用户显式技能手势保留原生行为。
-- dsh 团队首轮在实际 request/header 前收到共同目标、成员职责和公共原文；简报每次团队发言一次，公共序号按实际消费确认。回归覆盖无公共消息、准入拒绝后重新发言、后续批次去重及人工输入不追加团队内容。最终快照另保存主会话连续两次输入、普通专家、noSkills 专家和团队首轮；各请求在原生上下文组装后因缺少 provider adapter 失败，没有生成模型响应。
-- 两个历史摘要入口通过源码核对：只提供专用提示与本次历史文本，不提供工具或普通会话上下文。现有历史测试继续验证分组、分页、持久化和并发；没有通过替代模型证明摘要质量。
-
-首轮全量检查曾有一项真实 tmux/Pi 待命测试超时。隔离观察确认 Pi 联网元数据查询使子进程停留在 starting；在该离线 fixture 补齐其他原生进程测试已有的 `PI_OFFLINE=1` 后，单项与最终全量均通过。没有延长超时、修改生产启动规则或调整提示来迁就断言。
-
-正常执行 prepack 的 `npm pack --dry-run --json` 通过，共 269 个包条目；包含 CLI、dsh Host/Web、team-member、compute-finance 和本文引用的上下文设计文档，已删除的 tool-guidelines 不再进入包。未发布。
-
-证据目录：`/tmp/pbot-pi-context-audit-8UHhUu/` 保存 Pi 原始观察及最终六种加载场景；`/tmp/pbot-dsh-context-review-pn3D9O/` 保存修改前的 dsh 发现；`/var/folders/tg/_ll136tn58387kdsr5vxzzwr0000gn/T/pbot-dsh-final-context-3tSpqi/` 保存最终 dsh 原生请求和事件；`/var/folders/tg/_ll136tn58387kdsr5vxzzwr0000gn/T/pbot-context-review-RJEmho/` 保存修改前资源、Pi 汇总、待命诊断脚本及最终打包结果。临时文件可能被系统清理，行为回归保留在仓库测试中。
-
-本次使用临时工作区及隔离的用户、认证和 Python 故障目录，不使用个人凭据，不修改用户资料、历史或备份。本地结果只证明上下文的来源、内容保真、出现时机及去重，不证明模型理解、专业判断、实际 token/费用或成功的外部服务工作流。没有重新验收 Linux、Node.js 22.19.0、完整 Web/桌面或成功模型调用；前述旧版本与已发布提交的验收范围保持不变。
-
-## 模型指令通用提醒清理（2026-11-07）
-
-在 `3d48fdd` 之后，清理公共提示、角色、团队消息、通知、工具说明及技能中的重复证据、权限和验收引导，保留目录用途、分页、配置作用域、计算方法与防重复执行说明；后续要求写入 AGENTS.md 及[模型指令编写原则](model-instruction-guidelines.md)。本轮不修改加载机制、状态规则或审批实现，不新增文案断言。
-
-同一 macOS、Node.js 24.22.2、npm 11.19.1、Pi 1.5.0、dsh 0.2.2-rc.1 环境下，`npm run check`、`npm test`、`git diff --check` 通过；135/135 测试通过，无失败、取消或跳过，依赖边界仍为 137 个模块、558 条依赖。测试总数包含工作区已有的安装与通知回归。未调用真实模型；此前上下文快照对应上一轮措辞，本次通过现有行为回归检查加载、分页与通知，不将旧快照当作新文案实测。
-
-## 0.2.8 本地候选检查（2026-11-07）
-
-本次候选在 0.2.7 的安装、恢复和双宿主基础上，同步 Task Conductor 0.1.6 的 Pi/dsh 安装、原生 MCP、会话通知和自定义 ACP 使用指引。package.json、shrinkwrap 与两份 README 的当前版本同步为 0.2.8，子会话兼容线仍为 0.2。
-
-macOS、Node.js 24.22.2、npm 11.19.1、Pi 1.5.0、dsh 0.2.2-rc.1 下，`npm run check`、`npm test`、`git diff --check` 全部通过；135/135 测试通过，无失败、取消或跳过，依赖边界为 137 个模块、558 条依赖。正常执行 prepack 的 `npm pack --dry-run --json` 通过，270 个包条目包含 CLI、dsh Host/Web、Pi 源码、提示与技能、编写原则和中英文 dsh 指南，不包含 dist 或 node_modules。此记录为本地候选检查，未执行本版本的远端 CI、npm 发布或真实模型验收。
-
-## 双宿主接入验收
-
-已完成 dsh 0.2.2-rc.1 基线的 Host/Web、专家与团队、附件、通知、双来源 history 和人工管理。当前结果与证据位置持续记录在[实施记录](dsh-implementation-plan.md)，使用入口见[dsh 使用](dsh.md)。
-
-- Pi 1.5 本地回归在 macOS、Node.js 24.22.2、npm 11.19.1 下完成 `npm run check`、`npm test`、`git diff --check`，125/125 通过，无跳过；依赖边界为 135 个模块、554 条依赖。正常 `npm pack --dry-run` 与 prepack 打包通过。2026-11-06 对提交 `1625a78` 的 Linux 全量检查也已通过，见上节 CI 记录。
-- 正常 tarball 在独立消费者目录安装后没有安装 Pi/dsh SDK 副本；Node.js 22.19.0 下独立 CLI 返回版本，Pi 实际加载四个工具与技能、执行资料初始化和空专家查询通过。固定版 dsh 原生安装最终运行代码后，完整 Web 流程再次通过。
-- 正常执行 prepack 的 tarball 经原生插件命令安装后，真实 Chrome 验证四个 Remote、资料准备、文件与图片上传、长原生记录分页、私人草稿、公共消息分页、停止后冷读、显式恢复、history 查询与页面刷新。缺 provider 的批次真实失败并暂停，没有生成模拟响应。
-- 原生 Web 审批验证单次允许、真实取消以及等待期间符号链接变化；使用原生 Session 审计和真实 write 工具，不生成模型响应。
-- 原生 Web 停用插件后入口移除，专家释放；重新启用后专家保持停止且记录可冷读。单独关闭管理页不停止已接纳专家。关闭整个浏览器进程后重新连接，父身份与两个专家的存活状态保持。长断线及真实模型运行中的接管、取消仍需后续验证。
-- SDK 资源检查验证包内及工作区技能发现、不同工作区目录隔离、实际 skill 工具读取、noSkills 与专家工具限制。它证明原生可见性与加载，不证明模型会正确选用方法。
-
-Python 测试已同时隔离 HOME 与 XDG_DATA_HOME，并用真实准备脚本确认目标目录。首轮 macOS 全量前的 fixture 隔离不完整；随后对个人 Python 目录的元数据核查未发现该轮开始后修改的文件或目录条目。没有删除、回滚或覆盖个人环境，不能追溯声称首轮从未访问它。临时损坏环境只验证失败与恢复路径，不代表依赖成功安装。
-
-尚无本次获准的真实提供方工作流。成功专家/团队协作、通知后的模型推进、后台摘要成功及真实请求取消均未验收；旧版 Pi 模型冒烟和缺 provider 失败路径不能替代这些结果。
-
-### macOS 桌面应用实测
-
-使用本机 `/Applications/DeepSeek Harness.app` 0.2.2-rc.1、自带 Node.js 24.21.0，另开隔离的 Electron userData、DSH_HOME、HOME 与 Documents 工作区；原有应用进程持续运行。通过应用原生“插件 → 添加插件”安装实际 tarball 并启用，没有使用 dsh CLI 安装该测试 profile。
-
-- 四页签与资料准备、524,305 字节文件及 1×1 图片上传、完整 JSON 分页重组、草稿保留、20,000 字符公共消息分页、团队真实缺 provider 后暂停、停止后冷读、携新要求恢复、history 查询及 Renderer 刷新全部通过。观察到 10 次管理写命令，轮询和刷新没有增加写命令，页面错误为空。
-- 32 MiB 上传开始后立即关闭管理页，上传取消且没有提交 chat 命令或追加 inbox 消息；已创建专家继续存活。完整退出应用后再启动，两个专家保持停止且原生记录保留；插件停用、重新启用同样不自动恢复。
-- 临时登录 Shell 的 PATH 配置为真实 Python 3.12 后，应用自动创建独立 venv 并安装锁定依赖，状态达到 ready。该环境 `pip check` 成功，5 项 Python 原生库测试通过，覆盖 TA-Lib/backtesting、统计与 sklearn、Excel/Parquet/Feather 往返及绘图。这证明本机桌面准备和库配合，不证明模型能正确开展研究。
-- 隔离实例的原生模型选择器显示 `No models available`，未配置认证，没有进行成功模型调用。
-
-证据位于 `/tmp/pbot-dsh-desktop-test/`：`smoke.json`、`verified.json`、`lifecycle.json`、`python.json`、`python-library-tests.log`、`model-picker.txt` 与对应截图；脚本位于 `/tmp/pbot-dsh-browser/desktop-*.mjs`。临时文件可能被系统清理，测试应用进程已退出，资料与记录保留。
-
-### 界面验收
-
-- Pi 1.4.0 真实终端通过 `/pbot` 菜单、只读状态页、历史入口和窗口缩放验证。真实组件测试覆盖长列表、中文／emoji 换行、滚动及深浅主题。
-- 桌面应用通过原生插件页安装最终 tarball。专家切换保留各自草稿与附件；轮询保留表单焦点和分页。文件／图片、完整事件分页、团队消息、history、停止／恢复及刷新通过，8 次写命令，页面错误为空。
-- 原生设置切换浅色／深色后，四页在 1360、560、360 像素宽度均无横向溢出；主按钮文字对比检查通过。
-
-证据位于 `/tmp/pbot-ui-review/`，包括 `check.log`、`pi.json`、`gui.json`、`themes.json` 与截图。此轮未执行成功模型工作流。
-
-## 安装器验收（2026-11-03）
-
-本次实现完成以下验证。安装验收使用临时工作区与独立的用户目录、npm cache/prefix，不使用个人凭据或模型请求：
-
-- Linux、Node 24.15.0、npm 11.19.1、Pi SDK 1.4.0：`npm ci --ignore-scripts`、`npm run check`、`npm test` 全部通过，99 项测试无跳过；`npm pack --dry-run` 通过。
-- macOS、Node 24.22.2、npm 11.19.1：17 项安装测试通过；实际 tarball 的全局安装与 npm exec 均可执行 `pbot --version`，两种安装都未下载 Pi SDK。现有 Pi 1.5.0 managed launcher 与实际安装根目录的识别通过。
-- Linux 真实终端：从无 Pi 的独立 prefix 安装 Pi 1.5.0，再通过 Pi 安装 registry 的 pbot 0.2.3；重复运行、原生项目信任确认和不启动 Pi 的选择均成功。另将临时 Pi 安装为 1.4.0，确认 setup 通过原生 `pi update` 升级至 1.5.0。工作区仅有 `npm:personal-bot@latest` 声明，未选插件未安装，未直接创建 AGENTS.md。
-- 全局 npm 资源过滤的真实终端验收：工作区声明继承 `extensions: []` 和 `skills: []`，全局配置原文未变化，未启用被禁用的资源。
-- 本次打包的 pbot 与 Pi 1.5.0 SDK 完成 `/pbot init` 分发，创建资料且不调用模型；没有 pbot 时，保护扩展拦截未分发输入。共享 Python 环境使用真实的不可用临时目录，验证失败提示和资料初始化的独立性，不作为 Python 依赖安装成功的证据。
-- 系统 Python 缺少 ensurepip 时，真实 CLI 在安装软件前退出。正向终端验收使用已存在的 Python 3.13.13，没有更改系统 Python。服务器原有 npm 12.0.2 的 `npm ci` 未接受仓库 shrinkwrap，本次仓库回归使用临时安装的 npm 11.19.1，未更换服务器 npm。
-
-仍需验收 Homebrew/各 Linux 包管理器的提权与 tmux 实际安装、macOS 完整安装交互、Pi TUI 登录及模型选择、配套插件的外部服务与模型调用。同一工作区不应并发运行多个安装器；各原生包管理器不提供跨组件事务。全局 Git/本地来源与工作区 npm 来源发生身份冲突时，安装器保留现状并要求先用 Pi 原生配置调整加载范围，不自动移除全局来源。
-
-## 已批准的真实模型冒烟（0.1.3）
-
-2026-10-28 在 Linux、Node.js 24.15.0、tmux 3.3a、Pi 1.1.0 下验收当时的 0.1.3 源码。0.2.0 改用原生会话位置及开发依赖升级至 Pi 1.4.0 后均未追加真实模型冒烟，以下结果不作为新布局或新宿主版本的模型验收。主会话与两个独立子进程均使用 openai-codex/gpt-6-astra、low 思考级别；复用同一对成员，roundRobin 和 parallel 各运行一轮。这是同型号多 agent 验收，不是异构模型组合验收。
-
-| 项目 | 实测结果 |
-| --- | --- |
-| 无任务 start | 两个成员进入 idle，没有模型响应或初始请求 |
-| 普通 post | 不唤醒主模型 |
-| roundRobin | 32.8 秒完成两个请求；B 在 A 结束后启动，逐字引用 A 的公开 JSON，核验 17+25=42；B 的原生 custom context 保存了 A 的原文 |
-| parallel | 23.9 秒完成两个请求；两周期重叠约 21.8 秒，双方的最终答复均逐字引用了对方的 post |
-| 自动公开 | 四份公共最终答复与对应原生固定叶节点报告完全相同 |
-| 主通知 | 主模型没有在成员工作期间运行；每批结束后自动恢复一次工作周期，只调用 status/read，没有个人完成通知重复投递 |
-| 关闭与退出 | close 保留两个 idle 成员；主会话退出后无存活子进程，独立 tmux 服务已清理，临时认证已删除 |
-
-无扩展错误，未修改运行代码。原生记录共计 18 条模型响应（含工具调用响应），usage 合计 input=30272、cacheRead=52608、output=1075。Pi 目录价估算约 0.4091 美元，不代表 OAuth 订阅的实际账单。
-
-证据保存在临时目录 `/tmp/pbot-live-smoke-icSpOD/`：`result.json` 是结果与用量摘要，`run.log` 是阶段日志，`config/pbot/teams/` 与 `config/pbot/subagents/` 保存团队记录和原生会话。临时目录可能被系统清理，本节保留验收摘要；认证文件不保留在证据中或仓库内。
-
-本轮只发送人工生成的通信数据，不加载 MCP，不向模型开放文件或 Shell 工具，不使用交易凭据。为避免改动共享 Python 环境，用隔离的占位路径使准备步骤报告未就绪；Python 不是本轮验收对象。工具选择和临时目录不构成宿主沙箱。
-
-## 剩余外部验收
-
-以下行为仍需获准环境验收，不能从上述单轮冒烟或本地测试推导：
-
-| 范围 | 验收重点 |
-| --- | --- |
-| 历史摘要 | 真实模型的摘要质量、递归汇总后按大意回溯、取消与恢复的实际模型请求、长会话扫描性能及人工浏览 |
-| 真实模型与专家 | 0.2.0 原生会话存储下的委派交付与认证模型恢复、运行中 steer/follow-up、独立复核、通知推进和实际用量 |
-| 真实模型团队 | 异构模型组合、三人及多轮讨论、并行轮间互相引用、自动重试/恢复、人工 mixed 输入、团队/私人工作切换、长时间运行及实际账单 |
-| Task Conductor | 实际多节点产物、至少两轮周期任务、Pi 关闭或重载后的查询与防重复提交 |
-| CLI/MCP | 认证、发现、重连、动态工具、取消与业务结果 |
-| TUI/RPC | 人工 attach、焦点、批准、查看器、长时间运行和会话导航 |
-| npm 分发 | 0.2.6 从公开 registry 全新安装的 npx 入口、Pi 与 dsh 原生安装及 Host/Web/Remote 检查、用户环境反馈；该版本 OIDC 发布与公开版本/latest 查询已于 2026-11-06 完成 |
-| 平台与存储 | macOS 独立安装器的完整交互、断电持久性及文件系统差异；提交 `1625a78` 的 Linux 全量检查已于 2026-11-06 完成 |
-
-研究与资料方法使用真实任务资料验收，重点检查来源追溯、口径一致、缺失数据处理、历史前提复核、产物引用和结项依据。知识沉淀需检查是否提炼方法与口径，以及后续任务能否据此重新取数。探索任务应区分实验失败与假设被否定。
-
-记录验收环境、实际结果、证据位置与剩余缺口。连接可用、资源可见或格式正确只证明相应技术环节，不代表模型完成了业务任务。