# 运行手册

## 安装
```bash
git clone https://git.kappiee.com/kappiee/plane-agentd.git && cd plane-agentd
python3 -m pip install --user pyyaml          # 唯一依赖；有 jsonschema 时用它校验，否则用内置子集校验器
cp config/agentd.example.yaml config/agentd.local.yaml   # git-ignored；或用 AGENTD_CONFIG 指向别处
cli/agentd check-config                       # 校验 + 列出各终端 token 环境变量是否已注入 + cron 所需 --secret-env 参数
python3 -m unittest                           # 离线单测
```
调度器迁到不装 agent CLI 的 LXC：见 `docs/deploy-lxc.md`。
配置里只写 Vault 键名（`token_key`）。agentd 读同名环境变量，token 只由 `agent-access.py exec --secret-env KEY=KEY` 注入进程内存；不要 export 到 shell、不要写文件。agentd 起的所有子进程（本机 runner/执行器、win10 中继脚本）拿到的环境都去掉了全部 `token_key` 与 `webhook_secret_key` 变量。

## 运行
**调度器 2026-10-21（PAD-11）起跑在 LXC `agentd-01`**（root，仓库 `/opt/plane-agentd`），部署细节见 `docs/deploy-lxc.md`。任何时候只能有一个调度器排程。
单次 tick（在 LXC 上）：
```bash
cd /root/.local/share/server-access-client && python3 -I agent-access.py \
  --config https://nas.tail9531b.ts.net:8443/identity/agent.json exec \
  --secret-env PLANE_OREGON_API_TOKEN=PLANE_OREGON_API_TOKEN \
  --secret-env PLANE_WINDOW10_API_TOKEN=PLANE_WINDOW10_API_TOKEN \
  --timeout 900 -- python3 /opt/plane-agentd/cli/agentd tick --once
```
crontab（LXC root，每 2 分钟）：
```
*/2 * * * * /opt/plane-agentd/cron/agentd-tick-lxc.sh
```
`cron/agentd-tick-lxc.sh` = `flock -n /var/lib/plane-agentd/cron.lock timeout 900 python3 -I agent-access.py --config <identity> exec --secret-env PLANE_OREGON_API_TOKEN=… --secret-env PLANE_WINDOW10_API_TOKEN=… --timeout 850 -- python3 /opt/plane-agentd/cli/agentd --config /opt/plane-agentd/config/agentd.yaml tick --once >> /var/log/plane-agentd/cron.log 2>&1`。空闲 tick 不打印任何东西（cron 日志为空是正常的），活着与否看 `heartbeat.json` 的 `at`；`skip: another tick holds …` 表示与手工 tick 撞锁，无害。
实际配置 `config/agentd.yaml`（已提交，不含密钥）：`state_dir: /var/lib/plane-agentd`、`log_dir: /var/log/plane-agentd`，所以下表的 `state/…` 在 LXC 上是 `/var/lib/plane-agentd/…`，`agentd.log` 在 `/var/log/plane-agentd/`。改配置/代码 = 在 oregon 提交并推送，然后 LXC 上 `cd /opt/plane-agentd && git pull`（下一个 tick 生效）。
oregon 上的 `cli/agentd` 只当 CLI 用（new/show/comment/state/assign，`smoke … --watch`）；**不要在 oregon 上跑 `tick` 或不带 `--watch` 的 `smoke`**（那是第二个调度器）。
暂停一个终端（不再派新运行、也不探测，在途运行照常收尾）：把它的 `concurrency` 设为 0。

常驻替代：`... exec ... -- cli/agentd tick --loop --interval 120`（vault 会话超时要够长，cron 更稳）。
执行器的二进制一律用终端 `bins` 写绝对路径（如 `claude: /home/ubuntu/.local/bin/claude`）：cron 和 SSH 非登录 shell 的 PATH 都只有系统目录。

### 执行器二进制的解析（`bins` 或 PATH）
命令模板的首词（`codex`、`claude`…）若在该终端的 `bins` 里，替换为那里的绝对路径；否则**原样交给终端的 shell 按 PATH 查找**。没有任何其他探测或回退：
- oregon（2026-10-21 起 `warpgate-ssh`，os linux）：agentd 经中继 `agent-access.py run --target oregon -- bash -c …` 在 oregon 上 `setsid nohup bash run.sh`，runner 的环境是 sshd 给 ubuntu 用户的非登录环境（PATH = 系统默认，没有 `~/.local/bin`），所以 `claude` 必须写进 `bins`。`transport: local`（runner 继承 agentd 进程环境，cron 下 PATH 只有 `/usr/bin:/bin`）仍可用于调度器与执行器同机的部署和测试。**示例配置的 oregon 列了 `codex` 执行器但没有 `bins.codex`，即假定 `codex` 在 PATH 上——目前 oregon 没装 codex**（`which codex` 为空），带 `exec:codex` 的 oregon 工作项会以 exit 127（`command not found`，类型=crash，非临时性）转 Waiting。要用就装 codex 并加 `bins: {codex: <绝对路径>}`，否则从 oregon 的 `executors` 去掉 codex。
- win10（warpgate-ssh）：runner 是计划任务里的 `powershell.exe -File run.ps1`，以创建任务的用户（Administrator，交互登录）运行，PATH 取该用户的环境。示例配置用 `bins.codex` 写死 `codex.exe` 绝对路径；去掉它就等于假定 Administrator 的 PATH 里有 `codex`。
- `check-config` 不检查二进制是否存在；首次接入一个终端用 `agentd smoke <PROJECT> <terminal>` 验证。

人工操作（同样在 `exec --secret-env` 下）：
```
cli/agentd new GWENT "T-010 标题" --file brief.md --assign window10 --labels model:astra,needs-game --module M1 --state Todo
cli/agentd show GWENT GW-12 3        # 状态/指派/标签 + 最近 3 条评论
cli/agentd comment GWENT 12 reply.md # 或 - 读 stdin
cli/agentd state GWENT 12 Todo       # Plane 状态名或配置键（todo/review…）
cli/agentd assign GWENT 12 window10
cli/agentd smoke GWENT oregon --watch   # 建一个要求回复 "[review] ok" 的工作项，等排程中的调度器跑完，PASS 则移到 Done
cli/agentd smoke GWENT win10 --labels model:sol --watch   # --labels 给冒烟项加标签（路由到模型/档位）
                                     # 不带 --watch = 本机自己 tick（只在调度器所在机器上、且它的 cron 停着时用）
```
CLI 以 `--as <terminal>` / `agentd.cli_terminal` / 第一个有 token 的终端的身份操作。

## Webhook（PAD-7：Plane 事件即时触发 tick）
cron 每 2 分钟一次的 tick 保留作兜底；另有常驻接收端，Plane 一有工作项/评论变化就立刻触发一次 tick。
- **服务**：LXC `plane-agentd-webhook.service`（单元文件在仓库 `systemd/`，`Restart=always`）= `agent-access.py … exec --secret-env PLANE_WEBHOOK_SECRET=PLANE_WEBHOOK_SECRET --timeout 315360000 -- python3 /opt/plane-agentd/cli/agentd webhook-serve --bind 10.77.10.249 --port 8790`。只听内网地址；密钥只在进程环境里，agentd 起的子进程（tick 脚本）环境里去掉了它。
- **端点**：`POST http://10.77.10.249:8790/plane`；`GET /healthz` → `{"ok": true, "pending", "queued", "running", "retrying_since", "ticks", "last": {rc, seconds, deliveries, at}}`。
- **Plane 侧**：工作区级 webhook（kappiee 工作区设置 → Webhooks，或 `tools/plane-webhook.py`），订阅"工作项"（`issue`）和"评论"（`issue_comment`）。Plane 会把所有项目的事件都发来，接收端按 `data.project` 只认配置里的项目。
- **签名**：头 `X-Plane-Signature` = 用 webhook 密钥对请求体做 HMAC-SHA256 的十六进制摘要（Plane 签的是 `json.dumps(payload)`，发出的正是这串字节；接收端先比原始请求体，再比重新序列化的结果，均为常量时间比较）。缺失/不对 → 401，什么都不触发。其他头：`X-Plane-Event`（issue / issue_comment）、`X-Plane-Delivery`（每次投递的 UUID）。请求体：`{"event","action"(created/updated/deleted),"webhook_id","workspace_id","workspace_slug","data":{…,"project":<uuid>},"activity":{field,new_value,old_value,actor…}}`；删除事件的 `data` 只有 `id`（没有项目 → 202 忽略，由 cron 兜底）。
- **触发逻辑**：配置项目的投递 → 200，3 s（`debounce_seconds`）内的投递合并成一次 tick；tick 运行期间又来的投递 → 它结束后再跑一次（正在跑的 tick 可能在变化之前就读过 Plane）。tick 命令就是 cron 脚本（`systemd-run --scope … cron/agentd-tick-lxc.sh`，在独立 scope 里跑，重启接收端不会杀掉正在跑的 tick）。脚本持 `flock -n -E 75`：锁被 cron/手工 tick 占着 → 退出码 75 → 每 15 s 重试，最长 2 min，之后交给下一个 cron tick。tick 本身的输出照旧进 `cron.log`/`agentd.log`。
- **日志** `/var/log/plane-agentd/webhook.log`：每次投递一行（`delivery=<X-Plane-Delivery> event=issue/updated project=GWENT item=<uuid> decision=tick|202 ignored|401 bad signature|401 missing signature`），每次 tick 两行（`tick start (n deliveries: …)`、`tick done rc=0 in 12.3s` / `tick busy …, retry in 15s` / `giving up`）。Plane 侧的投递记录：`tools/plane-webhook.py logs <webhook id>`。
- **查看**：`systemctl status plane-agentd-webhook`、`journalctl -u plane-agentd-webhook`、`curl -s http://10.77.10.249:8790/healthz`、`tail -f /var/log/plane-agentd/webhook.log`。
- **轮换密钥**（在 oregon 上，kappiee 管理员会话，密钥不出进程、直接写进 Vault）：
  ```bash
  cd ~/.local/share/server-access-client && python3 -I agent-access.py --config https://nas.tail9531b.ts.net:8443/identity/agent.json exec \
    --secret-env PLANE_KAPPIEE_PASSWORD=PLANE_KAPPIEE_PASSWORD --timeout 90 -- \
    python3 -I /home/ubuntu/Documents/wjj/project/plane-agentd/tools/plane-webhook.py regenerate <webhook id>   # id: … plane-webhook.py list
  ```
  然后 LXC 上 `systemctl restart plane-agentd-webhook`（接收端只在启动时取一次密钥；轮换到重启之间的投递会 401，cron 兜底）。核对：`agent-access.py … exec --secret-env S=PLANE_WEBHOOK_SECRET -- python3 -c 'import os;print(len(os.environ["S"]))'`。
- **停用**：只停接收端 `systemctl disable --now plane-agentd-webhook`（Plane 投递会失败并重试，多次失败后 Plane 自动停用该 webhook 并给管理员发邮件）；连 Plane 侧一起停：`plane-webhook.py patch <id> is_active=false`。cron 不受影响。
- **通知**：配置里的 `notify: {kind: none}` 是钩子，核心每次改状态都调用 `Agentd.notify()`，目前什么都不做（没有 ntfy 服务）。

## 文件
| 路径 | 内容 |
|---|---|
| `state/agentd-state.json` | 每项目每工作项：轮次、线程 ID 与所在终端/执行器、线程轮数、各轮标签、已见评论、重试计数/下次重试、在途运行（handle、deadline） |
| `<log_dir>/agentd.log`（默认 `state/`） | 每次 tick 的动作与错误 |
| `state/heartbeat.json` | 最近一次 tick 的时间、在途运行、启动未确认的运行（`launching`）、本 tick 跳过的不可达终端（`down`）、没派出去的 Todo 项及原因（`skipped`：`[{project, item, terminal, reason}]`）、错误；超过 10 分钟不更新 = agentd 没在跑 |
| `<log_dir>/webhook.log` | webhook 接收端：每次投递的决定、每次触发的 tick（见上节） |
| `state/agentd.lock` | tick 互斥锁 |
| `state/runs/<run_id>/` | `transport: local` 终端的运行目录：`prompt.md run.sh pid.txt started.txt exit.txt stderr.txt` + 执行器输出 |
| oregon `/home/ubuntu/.gwent-board/agentd-runs/<run_id>/` | 远程 Linux 终端（`run_root`）：同上，另有 `launch.pid`（启动时的 `$!`，与 `pid.txt` 相同）；claude 输出 `out.json` |
| `<repo>\runtime\agentd\<run_id>\`（win10） | 同上，`run.ps1`；codex 输出 `events.jsonl last.md` |

## 工作项生命周期
Todo + 指派给终端用户 → agentd 选最小编号、终端有空位、串行组空闲的项 → In Progress，评论 `[worker] 第 k 轮开始…` → 执行器结束后回帖 `[<executor>] 第 k 轮结束（exit, run, 终端, 日志）` + 最后消息：
- `[review]` → Review，指派 `reviewer`；`[question]`/`[blocked]` → Waiting，指派 `answerer`（默认 reviewer）；`[progress]` → Todo，留在原终端，下一轮续线程；首行无标签 → 按 review 处理并注明。
- 回到 Todo 的项总会被重新拾起；续线程时只发送上次之后的新评论（按评论 ID 判断，`[worker]` 评论永远跳过）。
- 线程重建：换终端/执行器、续线程失败、线程轮数 ≥ `max_rounds_per_thread` → 新线程，首轮输入附交接摘要（各轮标签 + 上一轮最后消息），开始评论里注明原因与"附交接摘要"。临时性错误的自动重试算同一轮，不计入线程轮数（run id 照常递增）。
- 连续 `max_progress_rounds`（项目配置，默认 12）轮 `[progress]` → 不再续跑，回帖说明并转 Waiting 指派 answerer；人工移回 Todo 后重新计数。
- 运行中工作项被移出 In Progress（任何状态）→ 下一 tick 结束该运行（kill），回帖 `[worker] 运行已取消：工作项状态被改为 <状态>`，释放终端槽位与串行组，保留线程 ID（移回 Todo 时续原线程）。kill 失败则保留槽位，下一 tick 再试。
- **未实现（TODO）**：Plane 的 "blocked by" 关系不参与调度——被阻塞的项只要在 Todo 且指派给终端就会被拾起。需要先后顺序时，先只把前一项放进 Todo。

## 常见故障
| 现象 | 原因 / 处理 |
|---|---|
| `no Plane token in the environment` / tick 报 `no Plane token` | 没在 `agent-access.py exec --secret-env …` 下运行，或键名不对；`check-config` 看 MISSING |
| `skip: another tick holds state/agentd.lock` | 上一 tick 还在跑（win10 上传慢）；正常（`tick` 此时退出码 75）。持续出现则查是否有卡死的 agentd 进程 |
| Todo 项一直不动、心跳看着空闲 | 看 `heartbeat.json` 的 `skipped`：`concurrency n/m (GW-x)` 槽位被谁占着；`serialize_group … held by …`；`busy_process codex (… not started by agentd)` = win10 上有不是 agentd 起的（或上一轮还没退干净的）codex.exe；`relay down`；`no route for assignee …` = 指派的用户不是终端。原因第一次出现时 `agentd.log`/`cron.log` 有一行 `GW-n not dispatched (<终端>): <原因>` |
| `webhook.log` 里 `decision=401` | 签名不对：Plane 侧密钥轮换后接收端没重启，或不是 Plane 发的。`systemctl restart plane-agentd-webhook` |
| Plane 建 webhook 报 "The webhook URL is not allowed…" | Plane 的 SSRF 防护拒绝内网地址：Plane api/worker 环境需 `WEBHOOK_ALLOWED_IPS=10.77.10.249/32`（design §10） |
| `[worker] 第 k 轮失败：类型=crash（临时性）…重试 n/N` | 网络/中继/429/5xx：按 `backoff_minutes` 自动重试，续原线程；超过 `transient_max` 转 Waiting |
| `类型=timeout` | 超过 `timeout_hours`（或 `budget:2h` 标签）；进程树已结束，转 Waiting。看运行目录日志决定拆分任务或加预算 |
| `类型=crash`（非临时）且是续线程 | 自动在新线程重跑一次（附交接摘要）；再失败转 Waiting |
| `类型=env` | 匹配 `retry.env_patterns`（焦点丢失/弹窗/断网等），转 Waiting，同串行组暂停到该项离开 Waiting |
| `win10 unreachable; skipping` / `busy (N codex running…)` | 中继不通，或 win10 上有不是 agentd 起的 codex（`busy_processes`）；等它结束 |
| `schtasks launch … failed` / `upload … failed` | 中继或 Windows 计划任务问题；手工 `win10-ps.sh "schtasks /Query /TN agentd-<run>"` 查看 |
| `relay oregon exit 255: …` / `relay timeout` / `<terminal> unreachable, skipping it for the rest of this tick` | 中继（Vault、Warpgate、目标 sshd）不通；该终端本 tick 余下的 poll/启动全部跳过（`heartbeat.down`），其他终端照常。poll 失败下一 tick 再试。手工：`agent-access.py --config … run --target oregon --timeout 30 -- bash -c 'echo ok'` |
| `run GW-n-k: unconfirmed launch found …; adopting it` | 启动调用失败/超时（或 agentd 在启动中途退出），但终端上已有 `exit.txt`/`launch.pid`/`pid.txt`：接管该运行，不重复启动；开始评论注明"启动未确认、已接管" |
| `run GW-n-k: nothing at …; relaunching in GW-n-k-r2` | 启动没有落地：同一 run id、新目录 `<run_id>-r2`（再失败 -r3…）重新启动，旧目录不清空。运行目录里已有 pid 文件时 transport 拒绝清空（`HASPID`），下一 tick 探测后接管 |
| heartbeat `launching` 一直不消失 | 终端探测不通（中继坏），标记保留并占着该终端的槽位；中继恢复后自动接管或重启。人工处理：停 cron，在终端上看 `<run_root>/<run_id>/`，再从状态文件删掉该项的 `launching` |
| `upload of … size mismatch` / `staging … size mismatch` | 远程写文件不完整（磁盘满、`run_root` 不可写）；看远程 `run_root` |
| 远程 Linux 终端每步都慢 | 每次中继调用约 10–14 s（取 Vault 凭据 + SSH 握手）。一轮：启动 1 次（prompt 超过约 45 KB 时多几次分块上传）、每 tick poll 1 次、收尾 claude 约 3 次 |
| 工作项在运行中被人改了状态 | 运行还没结束：下一 tick 取消（kill + `[worker] 运行已取消…` 评论），不改状态。已经结束（`exit.txt` 已写）：结果照常回帖，但不再改状态/重试 |
| Plane 回帖失败 | 在途记录保留，下一 tick 重新 collect 并回帖（可能重复一条评论） |
| 想手工终止一轮 | 把工作项移出 In Progress（如 Waiting）即可，下一 tick agentd 自己 kill 并释放槽位。中继不通、kill 一直失败时：在终端上手工结束（Linux 终端 `kill -TERM -- -$(cat pid.txt); pkill -TERM -s $(cat pid.txt)`，win10 `taskkill /T /F /PID <pid.txt>`），停 cron 后从 `state/agentd-state.json` 删掉该项的 `inflight` |
| `已连续 N 轮 [progress]` | 达到 `max_progress_rounds`：看最近几轮是否在原地打转；拆分任务或补充说明后移回 Todo |

## 回滚到 oregon（LXC 调度器出问题时）
1. 停 LXC：`agent-access.py … run --target agentd-01 -- bash -c 'crontab -r; flock /var/lib/plane-agentd/cron.lock true'`（删 crontab，等正在跑的 tick 结束）。
2. 状态拷回 oregon：LXC `/var/lib/plane-agentd/agentd-state.json` → oregon `~/.gwent-board/agentd/agentd-state.json`（base64 经中继读回，比对 sha256）。在途运行照常被 oregon 接着 poll。
3. oregon 恢复 cron：`crontab ~/.gwent-board/crontab.backup-20261021-pad11`（即 `*/2 * * * * /home/ubuntu/Documents/wjj/project/plane-agentd/cron/agentd-tick.sh`）。`cron/agentd-tick.sh` 用 `config/agentd.oregon.yaml`（`state_dir: ~/.gwent-board/agentd`，日志 `~/.gwent-board/agentd/agentd.log`、`~/.gwent-board/agentd-cron.log`），与 LXC 配置只差路径。
4. 看 oregon 的 `~/.gwent-board/agentd/heartbeat.json` 更新。再切回 LXC = 反过来做一遍（docs/deploy-lxc.md §5）。

## 上线记录（2026-10-22，PAD-7：Plane 侧 webhook 启用）
- 01:14 Plane VM 506：`plane.env` 与渲染 compose 设 `WEBHOOK_ALLOWED_IPS=10.77.10.249/32`（备份 `*.bak-pad7-20261022-011453`），`--dry-run` 确认后只重建 api、worker、webhook-consumer、outbox-poller、automation-consumer、beat-worker（01:15:43–01:16:33）；API 约 1 分钟后回到 200，api 容器 4 分钟内转 healthy。
- 01:19 `tools/plane-webhook.py create http://10.77.10.249:8790/plane` → 201（白名单生效），密钥写入 Vault `PLANE_WEBHOOK_SECRET`（替换临时值）；01:22:30 `systemctl enable --now plane-agentd-webhook`（LXC 代码 1b4d965，单元文件与仓库一致）；01:22:57 `patch c039c471-… is_active=true`。
- Plane 建出的是 **v2** webhook：负载 `{version: v2, event, entity_type, data, …}`，由 `plane/webhook/bgtasks/webhook_task.py` 的 `send_webhook` 发出，签名 `HMAC-SHA256(secret, json.dumps(payload))`，与接收端一致；`data.project` 路由到 GWENT 正常。
- 实测（真实投递）：评论 GW-25 → 01:24:34 投递到达 → 01:24:37 tick → 4.6 s 完成；GW-25 改 Done 同样 3 s 后 tick。建项 GW-26（01:25:14）→ 01:25:15 投递 → 01:25:18 tick 开始 → 01:26:49 `[worker] 第 1 轮开始`（win10 codex/astra）：**建项 → 开工 95 s，其中 tick 本身 91 s**（中继、上传任务书、计划任务启动）；只靠 cron 时在这之前还要平均多等约 60 s。剩下的成本都在中继调用上（PAD-12）。
- cron `*/2` 保留为兜底（同一把 `cron.lock`）；oregon crontab 仍为空，只有一个调度器。

## 上线记录（2026-10-21，PAD-7：webhook 接收端）
- 13:25 LXC 上 `plane-agentd-webhook` 启用（`6dc7e72`），cron 不变。**Plane 侧 webhook 未建成**：Plane 3.3.3 对 `http://10.77.10.249:8790/plane` 返回 400 "The webhook URL is not allowed. Provide a publicly reachable HTTP or HTTPS URL."（SSRF 防护拒绝内网地址，见 design §10）；需要在 Plane 的 api/worker 环境加 `WEBHOOK_ALLOWED_IPS=10.77.10.249/32`，之后按 deploy-lxc §8 第 2–5 步建 webhook。在此之前 Vault 里的 `PLANE_WEBHOOK_SECRET` 是临时随机值（`plane_wh_interim_…`），`plane-webhook.py create` 会用 Plane 生成的密钥覆盖它。
- 验收用的是在 LXC 上按 Plane 格式签名的合成投递（`/root/lxc_send.sh good|bad|missing|other`）：错签名、缺签名 → 401，不触发；别的项目 → 202；正确签名 → 200，3 s 后 tick 开始。tick 运行中又来一条 → 结束后补跑一次（13:27 两条投递：224 s 的 tick——收尾 GW-15、在 win10 启动 GW-5——之后接着 24 s 的补跑）；那段时间 cron 的 tick 撞锁立即退出，cron 本身照常每 2 分钟触发。
- 冒烟 GW-17（oregon claude-code）：建项 13:43:15.8 → 合成投递 13:43:41（经 oregon→LXC 中继发出，人为多了约 25 s）→ tick 开始 13:43:44 → `[worker] 第 1 轮开始` 13:44:56 → `[review] ok` 13:47:54，PASS 并移到 Done。**投递 → tick 开始 = 3 s；tick 开始 → 开始评论 = 72 s**（这一 tick 先 poll win10 上在途的 GW-5，再经中继启动 oregon；同期 cron 的启动 tick 也要 70–77 s）。真实 Plane 投递约 1 s 到达时，建项 → 开始评论预计约 75 s，而只靠 cron 是平均约 60 s 等待 + 同样的 tick 时长。≤10 s 的目标在"开始评论"这个口径上达不到：瓶颈是中继调用（每次约 10 s，vault + Warpgate SSH）和启动流程，不是触发方式。
- GW-16（第一次冒烟）：webhook 触发的 tick 里 LXC→中继报 `access-hub: config_private_transport_failed`（LXC 经 tailnet 取 `nas…/identity/agent.json` 15 s 超时；13:38 的 cron tick 也撞上一次），启动失败；下一 cron tick 探测无运行目录 → `GW-16-1-r2` 重新启动，PASS（防重复启动机制按设计工作）。
- 重启：tick 运行中 `systemctl restart plane-agentd-webhook`，tick（在 `systemd-run --scope` 里）没被杀、照常结束（heartbeat 13:50:10，errors=[]）；接收端约 19 s 后重新监听（取 vault 密钥 + 启动）。

## 切换记录（2026-10-21，PAD-11：调度器迁到 LXC agentd-01）
- 代码：防重复启动（`launching` 标记 + 探测接管/换目录重启）与"中继不通的终端本 tick 跳过"随本次一起上线（4f45d36）；LXC 用仓库里的 `config/agentd.yaml`，oregon 回滚用 `config/agentd.oregon.yaml`。
- 切换前 LXC 手工 `tick --once`（oregon cron 仍在跑，Plane 上无 Todo 项）：空闲、无错误；LXC 经 helper 探测 win10（`codex` 计数）与经中继探测 oregon 运行目录均正常。
- 切换时 oregon 刚收尾 GW-11-1（11:53 由 oregon 派出、11:57 `[review]`），无在途运行。11:59 删除 oregon crontab 行（备份 `~/.gwent-board/crontab.backup-20261021-pad11`，oregon crontab 现为空），状态文件（sha256 `106c2bce…`）复制到 LXC，12:00 装 LXC crontab，12:02:09 第一个 cron tick（heartbeat 更新，errors=[]）。
- 冒烟（oregon 上 `smoke … --watch`，由 LXC cron 派发）：GW-12 oregon claude-code/sonnet 12:04:20 启动 → 12:06:47 `[review] ok` PASS；GW-13 win10 codex/gpt-6.1-sol/fast 12:05:58 启动 → 12:07:45 `[review] ok` PASS。续线程：GW-12 评论"回复 `[review] ok 2`"后移回 Todo，12:08:20 第 2 轮续 session `2348d52f…`（两轮 `out.json` 的 `session_id` 相同），12:10:44 `[review] ok 2`。两项均移到 Done。

## 切换记录（2026-10-21，P1-5）
- 旧 worker `gwent-design/tools/board-worker-plane.py`（cron `board-worker-plane-cron.sh`）已从 crontab 移除；脚本与 `~/.gwent-board/plane-state.json`、`plane-worker.log` 保留作历史，不要再启用（两者会抢同一批 window10 的 Todo 项）。
- 切换时旧 worker 无在途运行（GW-6 的 board-6-2 已于 06:30 以 `[blocked]` 结束，项在 Waiting）。GW-6 的 codex 线程 `01a15ce3…` 已迁入 agentd 状态（`runs=2`、`thread_on=[win10, codex]`、旧评论标为已见），移回 Todo 并指派 window10 时 agentd 续这个线程，run id 从 `GW-6-3` 起。
- 运行目录变了：旧 worker 用 win10 `runtime\board\board-<n>-<k>`，agentd 用 `runtime\agentd\GW-<n>-<k>`。
- 冒烟：oregon（GW-7，claude-code/sonnet，约 30 s）与 win10（GW-8，codex/gpt-6.1-sol/fast，约 3.5 min）均 PASS。win10 上验证过：`codex exec resume` 也会输出 `thread.started`（与原线程同 ID）；续线程时 `-c sandbox_mode="workspace-write"` 生效，能在仓库内写文件；把运行中的项移出 In Progress 后，`taskkill /T /F /PID <pid.txt>` 结束了整棵树（runner powershell → codex.exe → code-mode-host / command-runner → powershell），`Get-Process codex` 归零，计划任务被删除。
- 差异（P1-5 时）：旧 worker 对没有 model 标签的项用 sol + `service_tier="fast"`；agentd 当时只在有 `model:sol` 标签时加 fast。P1-6 起 codex 执行器有 `tier_defaults: {gpt-6.1-sol: fast}`，无标签项也是 sol + fast；`tier:<x>` 标签改档位，`tier:none` 去掉档位参数。
- win10 上 codex 的 stderr 常见 websocket 连接被拒（`os error 10061`，`wss://chatgpt.com/...`）后回退成功；只有运行失败时它才出现在失败说明的尾部，不影响分类（不匹配临时性模式）。

## 切换记录（2026-10-21，P1-6：oregon 改为远程启动）
- `config/agentd.yaml` 的 oregon 从 `transport: local` 改为 `warpgate-ssh`（`target: oregon, os: linux, launch: nohup, run_root: /home/ubuntu/.gwent-board/agentd-runs`）。agentd 仍在 oregon 上跑，但启动执行器走 Warpgate 回到本机，与将来 LXC 上的路径完全相同。切换时 oregon 无在途运行；GW-7/GW-10 的 claude 线程（`thread_on=[oregon, claude-code]`）不受影响——会话存在 oregon 的 `~/.claude`，与 transport 无关。
- win10 不变（helper 脚本 + schtasks），只是中继子进程改由共用的 `call()` 启动；切换后 GW-9 的 poll/collect 已经走新代码并正常结束。
- 冒烟（经 Warpgate 远程启动）：GW-10 第 1 轮 claude-code/sonnet PASS（`[review] ok`，启动 08:08:54 → 结束 08:10:17，session `fa3be0f7…`）；评论"请回复 `[review] ok 2`"并移回 Todo 后第 2 轮续同一 session（`out.json` 的 `session_id` 不变），回 `[review] ok 2` 转 Review。启动只用 1 次中继调用（约 12 s）；72 KB 的 prompt 走分块上传（约 75 s）。
- kill：直接经中继对 oregon 起 `sleep 600 & sleep 500` 的运行再 kill，两个 sleep 都被结束（进程组 + 会话），`pid.txt` 与 `launch.pid` 相同（setsid 没有再 fork）。经 Plane 的取消冒烟（运行中移到 Waiting）因 Plane 当时 502（08:14 起）未做，待补。


## 回滚记录（2026-10-21：调度器回到 oregon）
- 原因：LXC agentd-01 经 tailnet 到 NAS 的路径走 DERP 中继，取 vault 身份端点（`nas…/identity/agent.json`）TCP 连接 30/30 超时，tick 里的中继调用不稳定。网络修好后再切回 LXC（docs/deploy-lxc.md §5）。
- 做法：LXC 删 cron 行、停用 `plane-agentd-webhook`、等 `agentd.lock`/`cron.lock` 空闲；`agentd-state.json`（sha256 7201077b…eb87，两端一致）拷到 oregon `~/.gwent-board/agentd/`（旧文件备份为 `.bak-<时间戳>`）；oregon 恢复 `*/2` 的 `cron/agentd-tick.sh`。LXC 上的文件、服务单元均未删除。`config/agentd.oregon.yaml` 无需改动（`check-config` 通过）。
- 验证：oregon 首个 tick 14:20:01 接管，在途的 GW-5-1（win10 Codex）已结束，结果回帖并进入 Review；heartbeat `errors=[]`、`inflight=[]`，下一 tick（14:22）同样。
- 重新切回 LXC 之前：先 `crontab -r`（oregon）并等 tick 结束，再按 deploy-lxc §5 把状态拷回 LXC，并重新 enable webhook 服务；任何时刻只能有一个调度器。

## 切换记录（2026-10-21，网络修复后重新切回 LXC）
- 网络：OPNsense 增加出站 NAT 静态端口规则 `Tailscale agentd-01 static-port`（10.77.10.249/32，UDP，WAN），LXC tailscaled 改听 UDP 41642；LXC 到 NAS 直连（`tailscale ping` 5 ms via 223.102.82.206:1549，身份端点 30/30 成功、中位 0.089 s）。详见 deploy-lxc §2.1。
- 切换：oregon crontab 清空（备份 `~/.gwent-board/crontab.backup-20261021-152423-recut`），状态文件（sha256 `54b747db…7155`，两端一致；LXC 旧文件备份 `agentd-state.json.bak-20261021-152504`）拷到 LXC，装 LXC crontab `*/2 … cron/agentd-tick-lxc.sh`。在途的 GW-18 带过去（LXC 上为 GW-18-2），之后的 run-1 结果已回帖。heartbeat errors=[]、down=[]、skipped=[]，只有一个调度器。
- Webhook（PAD-7）仍未启用：`plane-agentd-webhook` inactive/disabled；Plane 的 `WEBHOOK_ALLOWED_IPS` 尚未设置（见 deploy-lxc §8 的具体改法，Plane 实为 VM 506 / 10.77.10.69）。PLANE_WEBHOOK_SECRET 仍是临时值。待办：应用该改动后做 §8 第 2–5 步；考虑轮换 Plane 的 AES_SECRET_KEY（排查时被打印进了一次会话记录）。