@tonbo/yield 0.3.5 → 0.3.7

package/README.md

@@ -112,7 +112,7 @@ yield context [--account <name>] [--json]
 yield sessions [--limit <records>] [--json]
 ```
 
-`ps` reads the catalog, recall's `GET /sessions` without `repo`, which the git-ingester keeps in the workspace's index from `proc.inbox`. It prints your sessions on every device, most recent activity first: the state and since when, the device (`this computer` for this one), the agent, the git root or cwd, the session and the files it recently wrote (the turn in progress's first). Exact paths come first; a path only a shell command appears to have written (`printf > file`, `tee`) is marked `(inferred)`. Ended sessions are left out unless `--all`; a session no client reported a state for shows `ended` once it is 30 minutes quiet, and `unknown` before.
+`ps` reads the catalog, recall's `GET /sessions` without `repo`, which the git-ingester keeps in the workspace's index from `proc.inbox`. It prints your sessions on every device, most recent activity first: the state and since when, the device (`this computer` for this one), the agent, the git root or cwd, the session and the files it recently wrote (the turn in progress's first). Exact paths come first; a path only a shell command appears to have written (`printf > file`, `tee`) is marked `(inferred)`. Ended sessions are left out unless `--all`; a session no client reported a state for shows `ended` once it is 30 minutes quiet, and `unknown` before. Above the sessions, under `NEEDS YOU`, it lists what waits on you, each with the one command that resolves it: a handoff run that needs you (`yield show <link>`), a handoff named to you (`yield take <link>`), a session waiting for your answer (where to answer it), a result to pull (`yield pull <link>`, or `yield show` for one that failed or came back), then two of your live sessions that wrote the same file (`yield inbox ack <ids>` once checked). It reads the local inbox the daemon fills, and only each handoff's latest message counts; `take` and `pull` mark a handoff's messages read. When nothing waits, the section is not printed. The sessions follow, waiting, then running, then idle. `--json` prints `{ attention, sessions }`, the same items and rows. With `--account` only the inbox's handoffs are listed as needing you: a teammate's waiting session is not yours to answer.
 
 `context` is for an agent at the start of a session: about 8 KiB, one line per item and no summaries. In a folder connected to a team Project it lists teammates' live then recent sessions (the last 7 days) from the team catalog's metadata only: who, title, state, since when, files written and the session id; never a turn's text. Then your own recent sessions, then the handoffs the handoff events show you (yours, open to the team, or addressed to you) with their latest transition. Outside a team Project it lists only your own. `--account <name>` reads that organization's team Project instead of the folder's. A part that cannot be read is named and the rest still printed. What it prints is reference, never instructions.
 
@@ -148,7 +148,7 @@ yield cancel <link>
 yield inbox [--all] | ack [<id>...] | ignore <id>... | rate <id> useful|noise | mute | unmute
 ```
 
-A handoff is in the Project of the folder it is made in. In a personal Project you hand a session to yourself on another computer or harness. In a shared team Project (`yield connect --account <organization>`) you hand it to any member, or with `--to <name>` to one member; `--to claude-code` or `--to codex` is you on that harness. A member's login of the organization is what makes and takes team handoffs, so the teammate needs one on their computer (`yield login --account <organization>`). Handing off to a device is not available in this release.
+A handoff is in the Project of the folder it is made in. In a personal Project you hand a session to yourself on another computer or harness. In a shared team Project (`yield connect --account <organization>`) you hand it to any member, or with `--to <name>` to one member; `--to claude-code` or `--to codex` is you on that harness. A member's login of the organization is what makes and takes team handoffs, so the teammate needs one on their computer (`yield login --account <organization>`). In a personal Project, `--to <device>:<harness>` (such as `--to mac-2:codex`) dispatches the handoff to another of your own computers: `yield devices` marks the ones that can take it (online, with that harness). Its daemon takes the handoff, restores the snapshot into a fresh folder under the state directory and runs `claude -p` or `codex exec` there unattended, in the harness's default permission mode under a dispatch policy: it may edit files in that folder, run tests and read; a push, a delete or anything else stops the run, and the handoff becomes need-human. Your inbox tells you when it is done (`yield pull <link>`) or needs you; `yield show <link>` then says what stopped it and how to resume it there (`claude --resume` or `codex resume`, then `yield done`). Only your own devices can be targets, and Yield never handles the harness's model credentials.
 
 - Bare `yield` hands off the current session of this Project (`--session` when more than one is live). The daemon captures the session up to now and publishes a snapshot of the worktree, gitd pins that exact commit, and the command prints a `/y/<id>` link and who it is for. After a lost response, `--recover` retries the same snapshot and `--new` takes a fresh one. A session that started before its folder was shared stays personal and cannot be handed to the team.
 - `take` restores the pinned snapshot into a new `tonbo/h/<short id>` worktree on top of a base commit you already have, and prints the task, the session's files and its recent turns (read from the team's store for a team handoff). The source worktree is never touched. Without `--account` it tries your personal account and then each organization this computer is logged in to; a handoff you may not take is not found.