@catalyst-cloud/cli 0.15.1 → 0.15.3

package/dist/setup.js

@@ -19,6 +19,7 @@ import { Readable, Writable } from "node:stream";
 import { VERB_USAGE } from "./args.js";
 import { plainSetupLine, SetupEventStream, } from "./setup-events.js";
 import { createSetupRenderer, } from "./setup-render.js";
+import { setupPartHeading } from "./setup-onboard-copy.js";
 const MACHINE_TITLES = {
     1: "Install the catalyst command",
     2: "Add the Catalyst skills",
@@ -107,7 +108,7 @@ function planRenderer(r) {
         },
         more(text) {
             if (!hidden)
-                r.line(`       ${text}`);
+                r.line(`      ${text}`);
         },
         close() {
             open = false;
@@ -238,7 +239,9 @@ async function runEngine(engine, args, flags, ctx, deps) {
                 }
                 if (!deps.onboard ||
                     !["What’s left", "What\'s left"].includes(event.text))
-                    r.heading(event.text === "Setting up" ? "This computer" : event.text);
+                    r.heading(event.text === "Setting up"
+                        ? setupPartHeading(1, r.traits.unicode)
+                        : event.text);
                 return;
             case "plan":
                 plan.plan(event.number, event.title, event.text);
@@ -399,7 +402,7 @@ async function runEngine(engine, args, flags, ctx, deps) {
                 return await deps.onboard(r, flags);
             }
             catch {
-                errors.line("catalyst setup: onboarding could not finish. Run catalyst onboard to try again.");
+                errors.line("catalyst setup: onboarding could not finish. Run catalyst setup to try again.");
                 if (flags.json)
                     deps.writeJson(`${JSON.stringify({ schema: "catalyst-install-last-run/1", state: "failed", exitCode: 10, steps: [] })}\n`);
                 return 10;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@catalyst-cloud/cli",
-  "version": "0.15.1",
-  "description": "Customer skill bundle for Catalyst Cloud, named from the executive's seat \u2014 get set up, see what is happening, see what needs you, run a project, unstick what is stuck \u2014 plus the catalyst CLI that reads through the Catalyst Cloud SDK, writes through the agent proxy, and connects your machine to your cloud account with one command. The skills directory is the roster; this line never counts it.",
+  "version": "0.15.3",
+  "description": "Set up Catalyst Cloud, check your tickets and manage your account from the command line.",
   "license": "MIT",
   "type": "module",
   "publishConfig": {

package/skills/catalyst-github/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Catalyst's GitHub: show a ticket's pull request with its checks, reviews and review threads, say whether it is mergeable under this repository's policy, and explain what a PR accumulates as the ticket moves (the branch, the draft, the rewrite, the force-pushes, the labels, the queue). Use when someone asks "show me the PR", "what are the checks saying", "why hasn't it merged", "what does the queue need", "what does that label mean", or wants the branch and merge conventions Catalyst follows.
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # Catalyst's GitHub
 

package/skills/catalyst-linear/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Catalyst's view of Linear on the customer's own cloud account. Reads a ticket with its comments, relations, labels, linked pull requests and agent sessions inline, from the cloud API by default, with local replica reads available as an explicit opt-in, always naming the source; searches tickets, PRs, projects and initiatives; writes comments, card moves, labels and new tickets through the account's agent proxy as the app actor, with every route, stage id, label id and marker read from the account's contract. Knows what a ticket accumulates as Catalyst works it (phase-outcome comments, the document per phase, the agent session, the labels, the single blocks relation, the bookkeeping marker, the eyes acknowledgement). Use when a person says "show me the ticket", "what did Catalyst write on it", "comment on it", "move it", "label it" or "file a ticket". Not for raising a decision for a human (what-needs-me) and not for pull requests (catalyst-github).
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # Catalyst Linear
 

package/skills/catalyst-onboard/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Set up Catalyst Cloud and say whether setup is working. Walks a person from nothing to their first ticket running, one step at a time: the coding account, the project, the integrations and connected accounts, each repository's settings file, then one real ticket moving. Also logs this machine in, reads the readiness verdict with who can fix each failure, and checks the optional local replica. Use when someone says "set me up", "onboard me", "I just signed up", "get me started", "what do I do first", "log me in", "which account is this machine on", "am I set up", "what is missing", "why does nothing happen" or "is the replica running", when a login expired, or when a skill script exits 2 saying this machine is not connected. Does every step a key can do through the catalyst CLI, hands over the exact page for the steps only a browser can do, and never claims a step it did not watch succeed.
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # Onboard me
 
@@ -14,9 +14,9 @@ Guide setup through the same `catalyst onboard` flow that the installer runs. Th
 
 1. Run `catalyst capabilities --json`. If its `onboard` entry is available and advertises `bootstrapHandoff: true`, use this path. If absent, use the older step-by-step references below and name the CLI update needed for the continuous flow.
 2. For a requested setup, run `catalyst onboard`. To inspect first, run `catalyst onboard --dry-run --json`. Resume with `catalyst onboard`; the command rechecks saved results. Do not ask the person to confirm completed browser steps or add a separate approval before the command's plan question.
-3. In a terminal, the command shows the verified person, workspace and plan before approval. Without terminal input, or with `--json`, use `--yes` only when the person has accepted the displayed defaults; otherwise setup waits with exit 11 and keeps the saved connection and receipt. JSON keeps progress, identity, the plan and quota disclosure on stderr and returns one result on stdout. A supplied key needs `catalyst login` before onboarding; browser sign-in does not replace it.
+3. In a terminal, the command shows the verified person, workspace and plan before approval. Without terminal input, or with `--json`, use `--yes` only when the person has accepted the displayed defaults; otherwise setup waits with exit 11 and keeps the saved connection and receipt. JSON keeps progress, identity and the plan on stderr and returns one result on stdout. A supplied key needs `catalyst login` before onboarding; browser sign-in does not replace it.
 4. For the current onboarding checks, run `catalyst ready --onboarding --json`. A failed check needs attention. An unknown check needs evidence. Report observed project work separately from incomplete setup; an unknown setup check does not prove work stopped.
-5. Exit 0 completes the requested scope. For a full run, exit 0 means work can start. If the receipt's `complete` is false, repository settings, local values, the daily update or the first ticket are still open, and the command lists them under "Next, when you want". Exit 10 means a failed step, 11 means waiting, and 12 means a guard refused the action. A successful `--only` step does not mean onboarding is complete. Keep the command's safe fix and supported resume command in your reply.
+5. Exit 0 completes the requested scope. For a full run, exit 0 means work can start. If the receipt's `complete` is false, a repository value or the first ticket is still open, and the command lists it under "Next, when you want". The daily update never keeps `complete` false, and neither do repository settings this computer cannot review (no checkout here, or not yet approved); a settings review that timed out or could not keep its draft does. Only a person at a terminal picks the first ticket; `--yes`, `--json` and headless runs leave it waiting with an action. Exit 10 means a failed step, 11 means waiting, and 12 means a guard refused the action. A successful `--only` step does not mean onboarding is complete. Keep the command's safe fix and supported resume command in your reply.
 
 Use cloud reads for ordinary workstation setup checks. Offer local sync for local SQL or sustained local reads inside the plan review. Local sync does not promise offline browsing. It is optional; do not make an absent replica a setup failure. Browser approval belongs to the person. Missing bearer capabilities stay unfinished; never call a session-only route from the CLI or invent a command.
 

package/skills/catalyst-onboard/references/replacing-a-credential.md

@@ -1,25 +1,19 @@
-# Replacing a coding account's credential
+# Replacing an AI account's credential
 
 When the script prints "<provider> account <slot> needs a new credential" (quarantined, expired, revoked, or three or more polls failed on the credential), replace that account's credential on its own page. Do not enroll a second account. It would be a duplicate beside the dead one. A workspace owner or admin does it in the browser, from the link the script prints; the person copies and pastes the credential, and you never read, print or paste it.
 
-## Codex
+## The steps
 
-The person runs these steps on their own machine:
+For an API key, billed per token by its provider:
 
-1. Run `codex login` and choose "Sign in with ChatGPT".
-2. The login writes `~/.codex/auth.json`, or `$CODEX_HOME/auth.json` when `CODEX_HOME` is set. On macOS, `pbcopy < ~/.codex/auth.json` copies it.
-3. In the browser, open Settings → AI accounts, then that Codex account.
-4. Paste the file into "Replacement auth.json contents", then press Replace credential.
+1. The person creates a new key in the provider's console, under the same provider account the AI account was made from.
+2. In the browser, they open Settings → AI accounts, then that account.
+3. They paste the new key into the replacement field and press Replace credential.
+4. Once the account reads healthy, they can revoke the old key in the provider's console if nothing else uses it.
 
-Say plainly that Catalyst takes over this login: its refresh token is single-use, so the local copy stops working once Catalyst uses it, and to use Codex locally they sign in to Codex again, separately, after the replacement.
+If the account's page asks for something other than a key, follow the steps the page shows. When the page names the login the account belongs to, the new credential must come from that same login: one from another login would put a live account onto the wrong record. If a tool on the person's machine mints the credential, have them confirm it is signed in to the login the page names before minting; such tools mint for whoever is signed in, not for the account. When the page says Catalyst takes over the login, say so before the paste, and that the person signs in again locally afterwards.
 
-## Claude
-
-The field is "Replacement setup token". `claude setup-token` mints a token for whichever account the terminal is logged into, not for the slot, so match them first: compare the slot's email on the AI accounts page with what `/status` in `claude` shows, and log in to the slot's account if they differ. Then run `claude setup-token`, paste the token, and press Replace credential.
-
-## Any other provider
-
-The same page, with the credential it asks for. A cancelled or ended account is not a credential problem, and no token revives it.
+A cancelled or ended account is not a credential problem, and no new credential revives it.
 
 ## Afterwards
 

package/skills/catalyst-onboard/references/what-a-phase-needs.md

@@ -4,20 +4,13 @@ A phase needs the `coding accounts` and `host` parts of `node scripts/where-am-i
 
 ## Coding accounts
 
-One coding account is enough to start. A second, on another provider or plan, gives the router somewhere to go at a limit; offer it later.
+One coding account is enough to start. A second gives the router somewhere to go at a limit; offer it later.
 
 ### The kinds, and enrolling
 
-| they say | kind | the page asks for |
-| -- | -- | -- |
-| "Claude Pro or Max", "I use Claude Code" | Claude setup token | what `claude setup-token` prints, after `/status` in `claude` shows the account they mean |
-| "ChatGPT", "Codex" | Codex auth file | `~/.codex/auth.json` after `codex login` (steps in `references/replacing-a-credential.md`) |
-| "a GLM key", "Z.ai" | GLM API key | the key from the provider's console |
-| "a Qwen key", "Alibaba Model Studio" | Qwen API key | the key from the provider's console |
-
-A plain Anthropic or OpenAI API key cannot be enrolled; say so and ask whether they have one of these. Before a Codex paste, say Catalyst takes over that login: its refresh token is single-use, so they sign in to Codex again locally afterwards.
+Settings → AI accounts lists the providers this workspace can connect and what each one asks for; an API key is billed per token by its provider. Do not promise a provider. Ask the person to open Settings → AI accounts and choose from the providers it lists; if the one they name is not there, say so and ask whether they have a key from one that is.
 
-Enrolling is a browser step by construction: on Settings → AI accounts, an owner or admin picks the provider, labels the account, and pastes the credential into a write-only field. Call an account by its label, else its email, else its slot (`displayName` in `catalyst accounts --json`).
+Enrolling is a browser step by construction: on Settings → AI accounts, an owner or admin picks the provider, labels the account, and pastes the key into a write-only field. If the page says Catalyst takes over a login, say so before the paste. Call an account by its label, else its email, else its slot (`displayName` in `catalyst accounts --json`).
 
 ### The states
 
@@ -30,7 +23,7 @@ Enrolling is a browser step by construction: on Settings → AI accounts, an own
 | `inactive` | every account is out of rotation | reactivate one on its page, never enrol another |
 | `unread` | the cloud could not read them | it is not "no accounts"; read again later |
 
-**A cancelled or ended account** stays for reporting, unused, and does not hold setup up; say so in one clause. It keeps its own login: a token from another login would put a live account onto a dead slot. It stays enrolled rather than retired or deleted, and a returning subscription reactivates it on its page.
+**A cancelled or ended account** stays for reporting, unused, and does not hold setup up; say so in one clause. It keeps its own login: a token from another login would put a live account onto a dead slot. It stays enrolled rather than retired or deleted, and is reactivated on its page only if it can run again.
 
 ## Host
 

package/skills/catalyst-onboard/scripts/where-am-i.mjs

@@ -140,7 +140,8 @@ const field = (name) => {
   const line = statusLines.find((l) => l.startsWith(`${name}:`));
   return line ? line.slice(name.length + 1).trim() : null;
 };
-const tenant = field("Tenant");
+// A newer CLI prints "Catalyst workspace:"; an older one prints "Tenant:".
+const tenant = field("Catalyst workspace") ?? field("Tenant");
 const api = field("API");
 const connected = tenant !== null && tryLoadConfig() !== null;
 // The app and the API share an origin; the base URL is whatever this machine was connected to, so
@@ -752,7 +753,7 @@ if (!connected) {
         retirable.length === 0
           ? []
           : [
-              `${retirable.length} account(s) cancelled or ended (${retirable.map((a) => `${who(a) ?? a.displayName ?? a.accountSlot ?? "?"} (${a.provider ?? "unknown provider"})`).join(", ")}): kept for reporting, not used, and not counted here. Never replace their credential; reactivate one on the AI accounts page only if its subscription is live again.`,
+              `${retirable.length} account(s) cancelled or ended (${retirable.map((a) => `${who(a) ?? a.displayName ?? a.accountSlot ?? "?"} (${a.provider ?? "unknown provider"})`).join(", ")}): kept for reporting, not used, and not counted here. Never replace their credential; reactivate one on the AI accounts page only if it can run again.`,
             ];
       retireNote = retireLine[0] ?? null;
       if (rows === null) {

package/skills/run-this-project/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Own one Catalyst Cloud project end to end until it closes. Use when the person says "run this project for me", "own this until it ships", "keep this moving", or hands you a project id or a set of tickets to drive. Subscribes to the account's event stream for the scope through the catalyst CLI, reacts to each change in the same turn, makes tickets ready and moves them to dispatch, parks what should stop, chases stalls, escalates inward, and keeps one status summary current. Writes to Linear as the app actor; never polls.
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # Run this project
 
@@ -15,7 +15,7 @@ You are the steward: the single-threaded owner of ONE project or ticket set unti
 Scripts are run, never read. Each prints `--help`, and exits 2 when this machine is not connected (`catalyst login`), 1 when its own check fails.
 
 1. `node scripts/scope-status.mjs --project <id>` (or `--team <key>`): tickets by stage, what is running and queued in scope, and stalls against the local policy. Run it to take the scope, and again after a resync.
-2. `node scripts/watch-scope.mjs --project <id>`: the subscription. In Claude Code, arm a monitor on it and react to each printed line in the same turn; elsewhere add `--exec <command>` so a reaction runs per frame.
+2. `node scripts/watch-scope.mjs --project <id>`: the live watch. In Claude Code, arm a monitor on it and react to each printed line in the same turn; elsewhere add `--exec <command>` so a reaction runs per frame.
 3. `node scripts/make-ready.mjs <ticket>` dispatches; `--park` stops; `--note <why>` records it.
 4. `catalyst explain <ticket>` whenever a ticket is not moving.
 

package/skills/unstick/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Get a stuck Catalyst Cloud ticket moving again. Use when the person asks "why is this parked and can you release it?", "unpark this", "get things flowing again", "the outage is over, retry what failed", or hands you a ticket that is not moving. Reads why nothing runs and what holds the ticket through the catalyst CLI, decides whether the recorded cause is fixed, previews the release, releases every governor holding the ticket the right way (or one failure class across a team), and raises an ask only for what a person has to do. Never releases a cause it cannot show changed without saying so.
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # Unstick
 

package/skills/what-needs-me/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   The human's decision inbox on Catalyst Cloud, and the one way an agent raises a decision on their behalf. Use when the person asks "what needs me?", "what am I blocking?", or when active work is gated on a choice only they can make. Lists open asks ranked by how much open work each one holds, files an ask through the cloud's ask route with the account's own template, and records the answer so the held work releases. Never answers as the human, never duplicates an open ask.
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # What needs me
 

package/skills/what-this-repo-needs/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   What environment variable names does this repository need, and where does each one come from? Scans the repository offline (no login, no network) and lists the names in three groups (build/test, deploy-only, bindings), each with where it was found, what uses it, and where a local value would come from. Never reads a value or prints one. Also checks the environment variable table in `.catalyst/catalyst.toml` offline. Use when someone asks "what does catalyst.env.json mean", "what env vars does this repo need", "why does the container need this", or before reviewing or writing the declaration.
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # What this repository needs
 

package/skills/whats-happening/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Use for "what's happening?", "where are we?", "why is that stuck?", "what closed?", "what's next?", "how does this work?", "why did it do that?", "how does it prioritise?" and "what does this setting do, where is it set?" in Catalyst Cloud, or asks for something to be done rather than known. Reads the contract via catalyst CLI. Read-only: route work/decisions, never answer as the human.
 allowed-tools: Bash(catalyst:*) Bash(npx -p @catalyst-cloud/cli catalyst:*)
 ---
-<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.1 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.15.3 — written in this repository for customer accounts -->
 
 # What's happening
 
@@ -27,7 +27,7 @@ Comments/relations: catalyst-linear. PRs: catalyst-github. Readiness: catalyst-o
 | request or decision? | references/routing-work.md |
 | phases or Done? | references/the-ladder.md |
 | columns or slots? | references/stages-and-mapping.md |
-| accounts, windows, quarantine or provider? | references/coding-accounts.md |
+| accounts, limits, quarantine or provider? | references/coding-accounts.md |
 | setting, screen, route or role? | references/settings-and-where-they-live.md |
 | which command answers it from the cloud? | references/reading-from-the-cloud.md |
 | local SQL? only if `catalyst replica status --json` says `configured: true` | references/local-replica.md |

package/skills/whats-happening/references/coding-accounts.md

@@ -6,6 +6,6 @@ Slots identify credentials, not emails. Claude/GLM/Qwen use Claude CLI, Codex us
 
 Declared state is operator-set active/disabled. Observed health is healthy/degraded/unknown, polled every five minutes for active slots and daily for disabled ones. Credential conflicts/auth mismatches quarantine; Replace credential on the account's page clears it.
 
-Subscriptions have 5-hour and 7-day windows. Walls kill sessions; phase burn must fit headroom. Claude slots allow concurrent phases up to a cap; Codex permits one because refresh tokens are single-use. Vendor status does not reveal account windows.
+Providers can limit how much one account runs in a period. An account at its limit (walled) is left alone until it can run again. Hitting a limit mid-phase ends that phase's session. Where the provider reports an account's usage, a phase is offered only to an account with room to finish it. Some accounts take several phases at once up to a cap; others take one. A provider's status page does not show one account's limits.
 
 When idle, explain. routing_unavailable or no_eligible_account_slot points here. Read --accounts: empty means no enrolment; inspect walled, quarantined and reason. Silence proves nothing.

package/skills/whats-happening/scripts/snapshot.mjs

@@ -23,7 +23,7 @@ const SPEC = {
   },
   accounts: {
     value: false,
-    help: "also include the coding accounts: provider, state, usage windows, walls, quarantine (never a credential)",
+    help: "also include the coding accounts: provider, state, usage limits, walls, quarantine (never a credential)",
   },
   replica: {
     value: false,