kylon-cli 0.3.10-next.702 → 0.3.10-next.703

package/README.md

@@ -76,6 +76,74 @@ service can be installed (a source build, or a Windows machine whose policy
 blocks scheduled tasks) the daemon runs in the foreground until `Ctrl+C`, and
 `connect` says so.
 
+### `kylon onboard`
+
+`kylon onboard` is the terminal-first way to start: it creates a **new**
+workspace from the Claude Code context already on this machine. Run it from
+your project directory, or install and onboard in one line:
+
+```bash
+curl -fsSL https://api.kylon.io/install.sh | sh -s -- onboard
+```
+
+The installer hands `kylon onboard` the controlling terminal for its one local
+question; on a machine without one (CI, a headless box) it passes `--yes` and
+the browser confirmation is the only gate.
+
+It detects, offline and read-only, the project (the nearest `.git` ancestor,
+whose directory name becomes the workspace name), the `CLAUDE.md` instruction
+files (project, `.claude/`, and user-level), the skill directories under
+`.claude/skills/` that carry a `SKILL.md`, and the project's Claude Code memory
+entries. Env files, credential-shaped content, binaries, empty files, oversized
+files, and symlinks are never uploaded. It prints what it found, asks once
+(Enter confirms), then opens your browser: you sign in or sign up, review the
+proposal, rename or untick anything, and press one button. The workspace, its
+Rooms, the agent, its persona, its skills, and its memory are created there;
+the terminal then connects this computer's agent and starts the local runtime.
+Nothing durable exists until you press that button — an abandoned run leaves
+only expiring server-side state.
+
+It never attaches to an existing workspace. For that, use `kylon login` and
+create the agent in the Web UI.
+
+A computer can currently be connected to one workspace at a time, so `onboard`
+refuses when this installation already holds a connection — run
+`kylon disconnect` first. It also refuses once this machine holds credentials
+for five workspaces on the same server. (The one-connection rule is interim;
+multi-workspace binding is a planned change.)
+
+If the run is interrupted after the browser has confirmed (a dropped connection,
+a provider update that failed, a closed terminal), the workspace exists but the
+agent is not yet bound. Run `kylon onboard` again: it finds the resume record it
+left in `~/.kylon/onboard-pending.json` (mode `0600`, holding the request's
+device code and PKCE verifier) and finishes binding that workspace instead of
+creating another. A record the server has since dropped is discarded and the
+run starts over, while a record whose workspace was already created is kept with
+instructions (`kylon login --workspace <id>`, then connect the agent from its
+profile in the browser) until you pass `--discard-pending` to start a different
+workspace on purpose. Discarding a request the browser has not answered yet is
+refused while it is still open (cancel it on the browser page or wait for it to
+expire), because a tab left open on it could still create a workspace this
+computer would then have no way to reach; a record that has become unreadable
+also stops the run until it is repaired or discarded, and so does a damaged
+`computer-session.json`, which is read strictly at the one-connection check. One `kylon onboard` runs per computer at a time (a
+second concurrent run is refused up front; a run that was paused for minutes
+while another took its place stops rather than continuing), and a resumed run
+applies the same one-connection rule as a fresh one. `--json` never starts Claude Code's interactive sign-in; a
+signed-out Claude Code fails with the command to run, and stdout stays one JSON
+document. A workspace credential that cannot be saved locally is revoked
+server-side rather than left live.
+
+For agent-driven runs, `--yes` skips the local prompt and `--json` (which
+requires `--yes`) prints
+`{ ok, server_url, workspace_id, workspace_name, agent_id, agent_name, room_id, workspace_url, credentials_path }`
+on stdout — never the API key or the link token — while the browser URL and
+user code go to stderr so a human can still complete the confirmation.
+`--workspace-name` and `--agent-name` override the detected names,
+`--cwd <dir>` detects somewhere other than the working directory, `--no-start`
+connects without starting the runtime, and `--no-modify-path` leaves shell
+profiles untouched.
+
 The dist-tag tracks the environment: production uses `@latest`, dev uses
 `@next` (newest prerelease). To pin a specific build, use `kylon-cli@X.Y.Z`.
 

package/dist/kylon-bundle.manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.3.10-next.702",
-  "fingerprint": "24b363bc5005b7016ae5e9d3d6920416698649bc833845a706666ba5ee8d5c04",
-  "source_commit": "6c1ad428f3793d9ce23c89172144cb93aebd27a5"
+  "version": "0.3.10-next.703",
+  "fingerprint": "64b934e335dd36d865de3dbc82643f73a4777eef8c2639c9fcb1d6399c49a4e0",
+  "source_commit": "f806762e15e25bb3c6db8556ae1b41695e0547d4"
 }