kylon-cli 0.3.10 → 0.4.0-next.714

package/README.md

@@ -79,8 +79,8 @@ blocks scheduled tasks) the daemon runs in the foreground until `Ctrl+C`, and
 ### `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:
+workspace from the Claude Code or Codex 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
@@ -90,18 +90,71 @@ 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.
 
+Which agent it builds from is decided first, and never by guessing twice:
+`--provider claude-code|codex` decides outright; otherwise, when only one of
+the two has anything on this machine, that one is used; when both do, you are
+asked. A run that cannot ask — `--yes`, `--json`, or the hosted installer's
+non-TTY pipe — uses Claude Code, which is what the command has always meant, and
+says so when it passed over Codex.
+
 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.
+named from its `origin` repository when available and otherwise from its
+directory), the instruction files, and the skill packages each agent loads.
+
+For **Claude Code** that is the `CLAUDE.md` instruction files (project,
+`.claude/`, and user-level), the user's Claude Code skill directory, the
+project's memory entries, and direct child skill packages under these exact
+repository locations:
+
+- `.claude/skills`
+- `.agents/skills`
+- `.github/skills`
+- `agent_resources/skills`
+- `skills`
+
+For **Codex** it is `AGENTS.md`, walked the way Codex walks it:
+`$CODEX_HOME/AGENTS.md` first, then one file in **every** directory from the
+repository root down to the working directory, deepest last, because that is
+the order Codex applies them in and the order the persona is joined in. Its
+skills come from `.agents/skills` in every directory from the working directory
+up to the repository root, plus `$CODEX_HOME/skills` and `$HOME/.agents/skills`;
+the nearest directory wins a name contest, and Codex's own `.system` built-ins
+are left alone. `AGENTS.override.md` is never uploaded, for the same reason
+`CLAUDE.local.md` is not: Codex documents it as a temporary machine-local
+override, removed to restore the shared guidance, so it is one machine's
+private amendment rather than the instruction set a workspace should inherit.
+When the instruction chain is longer than the five-file cap, the global layer,
+the repository root, and the directories nearest the working directory are kept
+and the dropped middle is reported. There is a length budget as well as a file
+count: the agent's instructions are held to a character limit that the server
+applies by trimming the *end* of the joined text, which for Codex is the most
+specific layer. So when the combined files are too long, the broadest ones are
+dropped here instead — and named — so the instructions closest to your working
+directory are the ones that survive.
+
+Each skill package must be a direct child directory with a top-level
+`SKILL.md`. Discovery checks only the listed roots; it does not recursively
+search the repository for directories named `skills`. Roots are processed in
+the listed order, duplicate package names keep the first match, and an
+unusually large root is skipped before any packages inside it are read.
+
+Codex memory is **not** uploaded unless you pass `--include-memory`. Claude
+Code keeps memory per project, so onboarding one project uploads only that
+project's entries; Codex keeps a single store under `$CODEX_HOME/memories`
+covering every repository the machine has worked on, and sending all of it to a
+new workspace is a choice rather than a detail. With the flag, the entries and
+the compact `memory_summary.md` are uploaded; the `MEMORY.md` routing index and
+Codex's derived working state (`raw_memories.md`, `rollout_summaries/`) are not.
+
+Env files, credential-shaped content, binaries, empty files, oversized files,
+and symlinks are never uploaded. Its terminal summary shows the semantic
+project name and its source separately from the physical checkout root. It then
+asks once (Enter confirms) and 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.
@@ -129,9 +182,9 @@ 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
+applies the same one-connection rule as a fresh one. `--json` never starts the
+provider's interactive sign-in; a signed-out Claude Code or Codex 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
@@ -139,7 +192,9 @@ 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,
+`--project-name` overrides the detected project and suggested Room name;
+unless `--workspace-name` is also given, it becomes the workspace name too.
+`--workspace-name` and `--agent-name` override those 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.

package/dist/kylon-bundle.manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.3.10",
-  "fingerprint": "2ca7a16642dc49b8fb33d9906063da7af1fae3e86e5acdf00cf44962bb53d877",
-  "source_commit": "c474eeb5ea80bff7f26c4c2d9ccbe27febe4ebe8"
+  "version": "0.4.0-next.714",
+  "fingerprint": "49f262687539d8324488ff754db6d893b6dcff0df84d5491f97ba4b88ab843e2",
+  "source_commit": "99b6d7826fe83cd409423ad77ac663cf444fdd70"
 }