@tonbo/cli 0.1.2 → 0.3.0

package/README.md

@@ -12,11 +12,11 @@ The CLI deploys an Agent directly from a local directory without requiring Git o
 ```console
 tonbo login
 tonbo init
-No Harness-specific configuration was found in this project.
+No Harness-specific configuration was found in this agent.
 ? Which supported Harness should Tonbo use?
-❯ PI (`pi`)  Run this project with the pi command.
+❯ PI (`pi`)  Run this agent with the pi command.
 ? How should this Agent connect to Tonbo?
-❯ Create a new project  Create it only after you confirm the complete configuration.
+❯ Create a new agent  Create it only after you confirm the complete configuration.
   Use an existing agent
   Set up later
 ? Agent name [my-agent]:
@@ -26,11 +26,11 @@ Tonbo Agent configuration:
   Harness:       PI
   Execution:     PI CLI (`pi`)
   Model:         claude-sonnet-4-5
-? Create project and .tonbo with this configuration?
-❯ Create project and .tonbo
-  Edit configuration  Change the project, Harness, execution mode, model, or SDK entrypoint.
+? Create agent and .tonbo with this configuration?
+❯ Create agent and .tonbo
+  Edit configuration  Change the agent, Harness, execution mode, model, or SDK entrypoint.
   Cancel
-Created project my-agent and .tonbo.
+Created agent my-agent and .tonbo.
 Agent: my-agent (my-agent-my-account.tonbo.sh)
 Organization: my-account
 Application: https://my-agent-my-account.tonbo.sh
@@ -39,7 +39,7 @@ Mode: PI CLI
 Next: tonbo deploy
 ```
 
-Use the arrow keys and Enter to select a supported Harness and either create or select the one Agent owned by this source tree. Agent creation and file writes wait until the final review; cancelling leaves both local and cloud state unchanged. `AGENTS.md` is Harness-neutral and never identifies PI by itself. When `.pi/settings.json` exists, the shared source inspector identifies the PI Harness and reports its workspace-local packages. A regular PI project defaults to the native PI CLI; choose `Edit configuration` only when changing the Agent, execution mode, model, or another setting. Unsupported and planned Harnesses are not shown.
+Use the arrow keys and Enter to select a supported Harness and either create or select the one Agent owned by this source tree. Agent creation and file writes wait until the final review; cancelling leaves both local and cloud state unchanged. `AGENTS.md` is Harness-neutral and never identifies PI by itself. When `.pi/settings.json` exists, the shared source inspector identifies the PI Harness and reports its workspace-local packages. A regular PI agent defaults to the native PI CLI; choose `Edit configuration` only when changing the Agent, execution mode, model, or another setting. Unsupported and planned Harnesses are not shown.
 
 The generated `.tonbo` is TOML:
 
@@ -59,14 +59,14 @@ kind = "native"
 model = "claude-sonnet-4-5"
 ```
 
-The immutable full Agent hostname is the only durable Agent authority in the source tree; it is not a credential. This keeps Agents with the same name in different Organizations unambiguous. `deploy`, `run`, `ssh` and `secret` refuse an unbound declaration. `tonbo agent use <name-hostname-or-id>` accepts any convenient selector, resolves it through the signed-in account and writes the selected `project-organization.tonbo.sh` hostname into `.tonbo`; rebinding an existing declaration requires interactive confirmation or `--force`. UUIDs remain internal API identities and are never committed by the CLI.
+The immutable full Agent hostname is the only durable Agent authority in the source tree; it is not a credential. This keeps Agents with the same name in different Organizations unambiguous. `deploy`, `run`, `ssh` and `secret` refuse an unbound declaration. `tonbo agent use <name-hostname-or-id>` accepts any convenient selector, resolves it through the signed-in account and writes the selected `agent-organization.tonbo.sh` hostname into `.tonbo`; rebinding an existing declaration requires interactive confirmation or `--force`. UUIDs remain internal API identities and are never committed by the CLI.
 
 The default inference model is written without prompting. Override it explicitly with `--model`. Headless initialization makes Harness and driver choices explicit and may bind the resulting declaration with `agent use`:
 
 ```console
 tonbo init --harness pi --driver native
 tonbo init --harness pi --driver command --agent-entry dist/agent.mjs
-tonbo agent use my-project-my-account.tonbo.sh
+tonbo agent use my-agent-my-account.tonbo.sh
 ```
 
 After interactive initialization, deploy the current contents:
@@ -88,12 +88,12 @@ Every `tonbo deploy` creates one immutable Deployment: the uploaded source, the
 
 ```console
 $ tonbo deploy
-Deployed project my-project.
+Deployed agent my-agent.
 Organization: my-account
 Deployment: Fix greeting (0f3a7c21)
 Source: 0123456 · main
 Production: promoting (generation 4)
-Application: https://my-project-my-account.tonbo.sh
+Application: https://my-agent-my-account.tonbo.sh
 
 Agent process: starts with the first turn and stays warm while the runtime is active.
 
@@ -101,7 +101,7 @@ Start the Agent:
   tonbo run "<prompt>"
 
 Connect with SSH:
-  ssh my-project.my-account@tonbo.sh
+  ssh my-agent.my-account@tonbo.sh
 ```
 
 When the new Deployment has the same contents as the Production Deployment it replaces, `deploy` says so; the record is still created. `tonbo deploy --no-promote` creates the Deployment without moving Production, for example to stage a build and promote it later:
@@ -120,7 +120,7 @@ tonbo deployments rollback 9b8c1d22    # or to a named one
 Use `tonbo agent show` to rediscover the username, application address and SSH command later. `tonbo login` registers public keys found at the conventional `~/.ssh/id_ed25519.pub`, `id_ecdsa.pub` and `id_rsa.pub` paths. Register a key at another path with `tonbo ssh-key add <path.pub>` and revoke a lost or retired key with `tonbo ssh-key remove SHA256:...`. The CLI is not part of the SSH connection; ordinary OpenSSH, `scp` and `rsync` connect directly:
 
 ```console
-ssh my-project.my-account@tonbo.sh
+ssh my-agent.my-account@tonbo.sh
 ```
 
 The SSH user name is the Agent qualified by its username; the signed public key identifies the Tonbo user and is checked against membership and IAM at connection time. The CLI resolves the Agent name in `.tonbo` and prints the server-authoritative destination, so users never need to remember or assemble a username. The shell and HTTP turns may coexist on the singleton runtime, allowing the shell to observe the Agent while it works. Session writer fencing protects durable conversation history; ordinary workspace files retain Linux process concurrency semantics.
@@ -131,11 +131,11 @@ The platform injects scoped inference access and owns PI Session capture. Do not
 
 Deploy snapshots regular files under `.tonbo`, excluding `.git`, `node_modules`, PI package caches, local environment files and patterns in `.tonboignore`. Coding tools start in the persistent Artifacts workspace, while `AGENTS.md` and trusted `.pi` extensions, skills, prompts and settings load from the Deployment's uploaded source.
 
-## Supported PI project shapes
+## Supported PI agent shapes
 
 ### 1. Agent-local Agent
 
-Keep the normal PI project layout. Tonbo runs the same `AGENTS.md`, `.pi/APPEND_SYSTEM.md`, `.pi/settings.json`, `.pi/extensions`, `.pi/skills` and `.pi/prompts` that local `pi` loads:
+Keep the normal PI agent layout. Tonbo runs the same `AGENTS.md`, `.pi/APPEND_SYSTEM.md`, `.pi/settings.json`, `.pi/extensions`, `.pi/skills` and `.pi/prompts` that local `pi` loads:
 
 ```console
 pi
@@ -144,9 +144,9 @@ tonbo deploy
 tonbo run "Start the task."
 ```
 
-### 2. PI Package project
+### 2. PI Package agent
 
-Use PI's project-local package declaration as the single source of truth. A package is a PI resource, not another Tonbo execution mode: `tonbo init` recognizes `.pi/settings.json`, then the native PI driver loads the packages. Install an immutable package reference locally, verify it with PI, and deploy the project; Tonbo excludes `.pi/npm` and `.pi/git` caches and restores packages inside the isolated runtime:
+Use PI's agent-local package declaration as the single source of truth. A package is a PI resource, not another Tonbo execution mode: `tonbo init` recognizes `.pi/settings.json`, then the native PI driver loads the packages. Install an immutable package reference locally, verify it with PI, and deploy the agent; Tonbo excludes `.pi/npm` and `.pi/git` caches and restores packages inside the isolated runtime:
 
 ```console
 pi install -l npm:@acme/my-pi-agent@1.2.3
@@ -196,8 +196,8 @@ Node.js 22 or newer is required. Human OAuth tokens are stored at `${XDG_CONFIG_
 - [Design documentation map](../../docs/design/README.md)
 - [Agent source inspection and onboarding](../../docs/design/agent-source-onboarding.md)
 - [Shared source inspector](../../packages/agent-source-inspector/README.md)
-- [Agent resource model](../../docs/design/project-resource-model.md)
-- [Agent Deployments, Production and Rollouts](../../docs/design/project-deployments.md)
+- [Agent resource model](../../docs/design/agent-resource-model.md)
+- [Agent Deployments, Production and Rollouts](../../docs/design/agent-deployments.md)
 - [ADR-0008: Tonbo CLI onboarding and credential boundaries](../../apps/user-center/docs/decisions/adr-0008-tonbo-cli-onboarding.md)
 - [Management API v1](../../contracts/management/openapi-v1.yaml)
 
@@ -217,4 +217,4 @@ tonbo --json machine release <machine-uuid>
 
 Only one active Agent binding per Machine and one Machine per Agent are currently supported. Unbinding drains execution and completes physical deletion, final usage settlement and storage credential revocation before the Machine becomes available. Wait for `available: true` in `machine show` before rebinding. Cross-Agent reassignment resets rootfs; the destination mounts its own Agent Workspace and Sessions. Hidden pause/resume within the same Agent retains rootfs and process state. Release also drains an existing binding automatically; it does not delete Agent files or Sessions.
 
-`tonbo agent list` lists accessible Agents without requiring a local `.tonbo` file. JSON command output uses `agent` for one Agent and `agents` for the list; there is no duplicate `project` output alias.
+`tonbo agent list` lists accessible Agents without requiring a local `.tonbo` file. JSON command output uses `agent` for one Agent and `agents` for the list; there is no duplicate `agent` output alias.