docs: mark phase 3 complete, record the skills and caching findings

Two findings that changed the plan rather than confirming it:

  23. Skills require a tool literally named `read`. Curator's tools are all
      domain-specific, so every --skill argument was discarded in silence. The
      planned split into curator-core / video-arr / books-ingest was inert before
      it was written; the policy stays in APPEND_SYSTEM.md. memo-inbox is
      unaffected because it registers a restricted `read` override, which is why
      the earlier note generalised wrongly from it.

  24. A long-lived session is worth far more than the startup it saves: 99.97% of
      input read from cache on a continuing conversation against 0% on a new one.
      That is what makes the generated tool list necessary rather than merely
      tidy -- anything varying at the front of the prompt destroys it -- and it
      makes rotation a cost to be bounded rather than applied eagerly.

profile.toml now describes the phase-3 configuration that is actually deployed,
including that the empty `skills` list is a finding and not an oversight.
pi_rpc gains --system-prompt support and no longer guesses whether a `read` tool
will exist; extension_registers_read has to be stated.

harness-layering.md records what transfers from a widely-shared account of
building a personal coding harness on pi, and what does not. The layering frame
holds and the cache-hit figure was the useful part. Its central recommendation --
installing third-party packages -- is disqualifying for an unattended agent
holding tracker credentials, and its discipline layer (AGENTS.md) is precisely
what we block, because it is discovered from every parent directory.

docs/plans/2026-08-curator-agent-refactor.md

@@ -309,7 +309,42 @@ destructive 处理**，所以漏分类会 fail closed。拒绝本身作为 `plan
 **验收**：Web 与 Telegram 的同一动作产生同构账本记录；`control_events` 有读者；
 任一任务可查出意图、计划、执行、核验、失败。
 
-### 阶段 3 · Curator 采用 memo-inbox 模式（约 2.5 天）
+### 阶段 3 · Curator 采用工具 + 长驻 RPC —— ✅ 已完成 2026-08-28
+
+commits：`be6e1dc` 桥接 + extension + 工具提示生成 · `7bb7b03` 长驻 RPC +
+工具驱动回答 + 每对话 token。测试 108 → 129。已部署并重启，生产验证见下。
+
+**§4b 里「skills 拆三个」这一项作废，不是延后。** pi 只在有一个**名叫 `read`**
+的工具激活时才渲染 skills；Curator 的工具全是领域工具，所以每个 `--skill`
+都被静默丢弃（实测四种组合，见 pi-runtime-notes §23）。策略留在 `APPEND_SYSTEM.md`。
+memo-inbox 不受影响，因为它注册了受限的 `read` 覆盖。
+
+**写操作需要两个独立判断一致**：模型可以调 `propose_write`，但只有 Curator
+自己的意图识别（在这一轮之前跑完）也认定用户要求写，才会执行。两个判断里，
+偏向「动手」的那个是模型的。授权在 `finally` 里撤销，否则后续纯对话轮会继承它。
+
+**长驻会话的真实收益**（同一问题同一模型）：延续会话 **99.97%** 输入命中缓存，
+新会话首轮 0%。省的不是 1~2 秒进程启动，而是整个系统提示与历史不再重复计费。
+这也是工具清单必须**生成进系统提示**而不是每轮注入的原因 —— 前缀一变，缓存就没了。
+
+**三个跑起来才发现的问题**：
+
+1. 每个对话进程都用了池的默认 token，而默认 token 的上下文不属于任何 chat、
+   永远未授权。于是显式写入被拒，理由对默认上下文是真的、对这段对话是错的。
+   改为每对话 token，顺带修掉真实并发隐患：两个 chat 是两个线程，
+   共享轮次状态会让一个 chat 的写落到另一个的 job 上。
+2. 无工具的结构化轮拿到了带工具清单的提示，等于告诉模型它能查库而其实不能。
+   现在两条路径各有提示，并有测试断言两者不同。
+3. `_conversations` 从不回收，活的 node 进程数随 chat 数只增不减。
+   每个 100~200 MB 且占多个 task，症状会是某天「新对话起不来」而不是明显的泄漏。
+   改为按 TTL 惰性清扫。
+
+**生产验证**（真实数据、真实模型）：库存查询 1 次工具且答案正确；跨类型问题
+3 次工具且无写入；显式加书调用 propose_write 并如实转述幂等回执（且仍区分
+「已提交」与「已入库」）；「值得收吗」7 次只读工具、无写入；注入不产生任何写入。
+六个页面全 200，关闭后无孤儿 pi 进程，空载 19.4 MB。
+
+### 阶段 3 原始清单（供对照）
 
 1. `curator/agent_api.py`：仅 `127.0.0.1`，启动生成 secret 经 `env` 传给 extension；
    端点 `query_library` / `lookup_online` / `book_reviews` / `counts` /