Cleanup confirms and refreshes; projects switch sessions in place; explain verify.sh, headroom and Mouse-1

docs/NEXT.md

@@ -32,6 +32,12 @@ The cheap version first: a `t` entry that opens `~/.pi/paperclips` in Yazi, and
 `Agents>agents` that reads the JSONL directly. `GET /api/agents/{id}/task-sessions` maps a task
 to its session file, so neither version has to guess.
 
+## Done: Project>projects — switching project
+
+`bin/office` records each adopted project; the tab lists session, machine and folder; `enter`
+asks once and switches the client with `tuios call switch-session`, including to a session on
+another machine when that machine is in the client's `[hosts]` table. See `docs/SESSIONS.md`.
+
 ## 3. Project>projects — switching project
 
 A tab listing every adopted project from a small local registry
@@ -98,8 +104,9 @@ step; a switch is only worth adding after one agent has been run both ways and m
 
 ## 9. MOUSE-1
 
-The key is in the environment; the software is not installed. The old project's policy stands:
-triage only, never a gate, never a permit. It would order `Board>needs`, never decide a merge.
+Corrected: Mouse-1 is a hosted API, not software to install. `MOUSE_API_KEY` is present; what is
+missing is a client call from our side. The old project's policy stands: triage only, never a
+gate, never a permit — it could order `Board>needs`, never decide a merge.
 
 ## Unproven, and worth a test
 

docs/PLAN-INTERFACE.md

@@ -575,3 +575,53 @@ minutes of work and neither invents anything.
 A transcript tab inside `Agents>agents` is the integration option: read the JSONL, draw the
 messages, no second process. Worth doing only if the file browser feels like a detour after a
 week of use. Recommendation: do the cheap one now, decide later.
+
+## verify.sh, plainly
+
+`.harness/verify.sh` is a shell script in the project folder. Its only job is to answer one
+question: **is this project's work finished?** It exits 0 when the answer is yes.
+
+- It is **not** Paperclip's. Paperclip has no such concept; an agent sets a task's status.
+- It is **our** convention, from the old project, and `bin/office` now writes a template:
+
+  ```sh
+  #!/bin/sh
+  echo "no verify command agreed for this project"
+  exit 0
+  ```
+
+  As it stands it says yes to everything, which is honest: there is no agreed check. Replace
+  the body with the project's real tests when they exist:
+
+  ```sh
+  exec go test ./...
+  ```
+
+- `bin/merge` runs it in the task's worktree, and again on the base branch after merging.
+- A task may carry its own command in its description; that one wins for that task only.
+
+So: a per-project default, a per-task override, both optional. If neither exists, the merge
+says so and lets the `ocr` review decide.
+
+## Headroom, and whether it is good for a project
+
+Headroom is a **compression proxy**: requests pass through it and long prompts are shortened
+before they reach the model. It is running here at `192.168.20.13:8787` (v0.24.0, healthy,
+memory backend disabled, compression on).
+
+It is good where prompts are long and repetitive — a big repository, a long thread, many tool
+results. It is pointless for a small task whose prompt is already short, and it adds a hop and a
+failure mode.
+
+The lever is per **agent**, not per project, because a Paperclip agent's provider is configured
+on the agent. `adapterConfig.env` accepts variables, so an agent can be pointed at the proxy
+without touching anything else. That is why the interface offers a read-out first: until one
+agent has run both ways and you have compared cost and quality, "good for some projects" stays
+a hypothesis rather than a setting.
+
+## Mouse-1, corrected
+
+Earlier notes in this file said "software is not installed". That was wrong: Mouse-1 is a
+**hosted API**, not a program. What exists here is `MOUSE_API_KEY`; what is missing is a client
+integration — an HTTP call like any other. No install is needed, and nothing has to run locally.
+The old project's policy still applies: triage only, never a gate, never a permit.

docs/SESSIONS.md

@@ -71,3 +71,24 @@ on.
 - `factory`, `office-test-1` and the `harness-demo-*` sessions have one pane each and are
   detached — they *are* the junk, but they are indistinguishable from a deliberately parked
   session by age alone. Hence the pattern, and hence the confirmation.
+
+## Switching sessions, and what "on another machine" means
+
+A session lives on a daemon, and a daemon runs on one machine. Where you *sit* does not matter:
+a client on `.27` can drive a session whose daemon is on `.13`, and that is exactly what happens
+here. So the phrase "a project on another machine" really means "a session on another daemon".
+
+TUIOS has a verb for moving an attached client:
+
+```
+tuios call switch-session '{"name":"office","host":"nixos-desktop"}'
+```
+
+- `name` is the session to show.
+- `host` may be omitted for the local daemon, or named for a machine in the client's `[hosts]`
+  table. A machine that is not in that table cannot be reached this way; attach by hand then.
+
+`Project>project` → **projects** now uses this. Every adopted project is listed with its
+session, machine and folder; `enter` asks once and then switches the client in place. A
+project whose session is on a daemon your client does not know is still listed, and the
+confirmation says which machine it needs.