@tonbo/yield 0.3.6 → 0.3.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +3 -3
- package/dist/bin/yield.js +2363 -1184
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -8,7 +8,7 @@ Install it on macOS (arm64, x64) or Linux with glibc (x64, arm64) with one line,
|
|
|
8
8
|
curl -fsSL https://yield.tonbo.io/install.sh | sh
|
|
9
9
|
```
|
|
10
10
|
|
|
11
|
-
The installer, [`install.sh`](install.sh), uses the system `node` when it is 22 or newer and has npm beside it; otherwise it downloads the latest official Node.js 22 build from nodejs.org into `~/.tonbo/runtime/node-<version>`, checked against the release's `SHASUMS256.txt`. It installs `@tonbo/yield` into the private prefix `~/.tonbo/yield`, never a global npm, and writes the launcher `~/.local/bin/yield`, which runs it with that Node.js; when `~/.local/bin` is not on `PATH` it prints the line to add for your shell. On a terminal, a computer with no login yet then runs `yield login`, which signs in and starts capture, so the one line takes you from nothing to captured sessions; without a terminal, or with `YIELD_NO_LOGIN=1`, it prints that step instead. Running it again upgrades in place, and when the capture service is installed it reinstalls the service on the new version (which restarts it) and removes Node.js runtimes it no longer uses. `YIELD_VERSION` pins a version or dist-tag: `curl -fsSL https://yield.tonbo.io/install.sh | YIELD_VERSION=0.2.0 sh`. musl distributions (Alpine), 32-bit systems and Windows are refused with a message; on Windows, install the npm package instead. User Center serves the file at `https://yield.tonbo.io/install.sh` as `text/plain` (that host answers 404 for every other path until the Yield landing page exists) from an embedded copy (`apps/user-center/src/app/install.sh`); after changing `install.sh`, run `pnpm --dir apps/user-center generate:install-script`, or the route's test fails.
|
|
11
|
+
The installer, [`install.sh`](install.sh), uses the system `node` when it is 22 or newer and has npm beside it; otherwise it downloads the latest official Node.js 22 build from nodejs.org into `~/.tonbo/runtime/node-<version>`, checked against the release's `SHASUMS256.txt`. It installs `@tonbo/yield` into the private prefix `~/.tonbo/yield`, never a global npm, and writes the launcher `~/.local/bin/yield`, which runs it with that Node.js; when `~/.local/bin` is not on `PATH` it prints the line to add for your shell. On a terminal, a computer with no login yet then runs `yield login`, which signs in and starts capture, so the one line takes you from nothing to captured sessions; without a terminal, or with `YIELD_NO_LOGIN=1`, it prints that step instead. Running it again upgrades in place, and when the capture service is installed it reinstalls the service on the new version (which restarts it) and removes Node.js runtimes it no longer uses. `YIELD_VERSION` pins a version or dist-tag: `curl -fsSL https://yield.tonbo.io/install.sh | YIELD_VERSION=0.2.0 sh`. musl distributions (Alpine), 32-bit systems and Windows are refused with a message; on Windows, install the npm package instead. User Center serves the file at `https://yield.tonbo.io/install.sh` as `text/plain` (that host also serves the user docs at `https://yield.tonbo.io/docs`, and answers 404 for every other path until the Yield landing page exists) from an embedded copy (`apps/user-center/src/app/install.sh`); after changing `install.sh`, run `pnpm --dir apps/user-center generate:install-script`, or the route's test fails.
|
|
12
12
|
|
|
13
13
|
Or install the public package with Node.js 22 or newer:
|
|
14
14
|
|
|
@@ -112,7 +112,7 @@ yield context [--account <name>] [--json]
|
|
|
112
112
|
yield sessions [--limit <records>] [--json]
|
|
113
113
|
```
|
|
114
114
|
|
|
115
|
-
`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.
|
|
115
|
+
`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.
|
|
116
116
|
|
|
117
117
|
`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.
|
|
118
118
|
|
|
@@ -148,7 +148,7 @@ yield cancel <link>
|
|
|
148
148
|
yield inbox [--all] | ack [<id>...] | ignore <id>... | rate <id> useful|noise | mute | unmute
|
|
149
149
|
```
|
|
150
150
|
|
|
151
|
-
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>`).
|
|
151
|
+
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.
|
|
152
152
|
|
|
153
153
|
- 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.
|
|
154
154
|
- `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.
|