@catalyst-cloud/cli 0.16.25 → 0.16.28

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@catalyst-cloud/cli",
-  "version": "0.16.25",
+  "version": "0.16.28",
   "description": "Set up Catalyst Cloud, check your tickets and manage your account from the command line.",
   "license": "MIT",
   "type": "module",
@@ -53,16 +53,16 @@
     "prepublishOnly": "node scripts/release-train-check.mjs --publish cli"
   },
   "dependencies": {
-    "@catalyst-cloud/sdk": "0.16.11",
+    "@catalyst-cloud/sdk": "0.16.19",
     "@clack/prompts": "1.8.1",
     "fast-string-width": "3.0.2",
     "fast-wrap-ansi": "0.2.2",
     "smol-toml": "^1.7.1",
     "yaml": "^2.9.0",
-    "@catalyst-cloud/sdk-replica-node": "0.16.11"
+    "@catalyst-cloud/sdk-replica-node": "0.16.19"
   },
   "devDependencies": {
-    "@catalyst-cloud/schema": "0.16.9",
+    "@catalyst-cloud/schema": "0.16.16",
     "@types/node": "^26.3.0",
     "@vitest/coverage-v8": "^4.1.11",
     "typescript": "^7.0.2",

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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — 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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — written in this repository for customer accounts -->
 
 # Catalyst Linear
 

package/skills/catalyst-linear/references/reading-from-the-cloud.md

@@ -14,6 +14,8 @@ Cloud reads are the default on every machine. They need no local writer and no l
 | Find a ticket by words | `node scripts/search.mjs <terms>` |
 | What happened to it, event by event? | `catalyst events query --ticket <KEY-123>` |
 | Wait until its phase finishes | `catalyst events wait-for --ticket <KEY-123> --type relay.phase.completed --after <head> --timeout 300` |
+| Wait until its branch or PR changes | `catalyst events wait-for --ref <owner/name:branch> --type pr.* --after <head> --timeout 14400` |
+| What messages were sent to it? | `catalyst messages read --ticket <KEY-123>` |
 
 ## Reading the answer
 
@@ -28,7 +30,9 @@ A smaller read is coming: the cloud will answer a ticket or its execution histor
 `catalyst events` reads the cloud by default and needs no local file.
 
 - `catalyst events query --ticket <KEY-123>` prints the ticket's events, newest first. Add `--type`, `--limit` (up to 200), `--order asc` and `--before` or `--after` to page. An empty page says which sequences the cloud has indexed, so "no match" is not "never happened".
-- To wait for something to happen, first run `catalyst events status --json` and keep its `head`. Then run `catalyst events wait-for --ticket <KEY-123> --type relay.phase.completed --after <head> --timeout 300`. Exit 0 prints the event, exit 1 is a timeout, and exit 4 means the cloud was unreachable.
+- To wait for something to happen, first run `catalyst events status --json` and keep its `head`. Then run `catalyst events wait-for --ticket <KEY-123> --type relay.phase.completed --after <head> --timeout 300`. Exit 0 prints the event, exit 1 is a timeout, exit 2 is a refusal with its reason, and exit 4 means the cloud was unreachable.
+- To wait on a branch, a pull request, a repository, a phase session or messages addressed to you, use `--ref <owner/name:branch>`, `--pr <owner/name#n>`, `--repo <owner/name>`, `--session <KEY-123/phase#n>` or `--to me`, with `--type pr.*` for a family of types. Such a wait prints nothing until a match, so `--timeout 14400` costs nothing while it waits. On a timeout, stderr names the `--after` to resume from.
+- `catalyst messages read --ticket <KEY-123> [--since <sequence>]` prints the messages sent to the ticket, with sender and time.
 - `catalyst events tail --ticket <KEY-123>` stays in the foreground and prints one JSON line per new event.
 
 The ticket filter reads the event's ticket entity, `payload.ticket`, and the lease that caused it. `--from-cache` reads this machine's local event cache instead. It exists only where local sync is on, and it pays off when several agents on one machine share it.

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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — written in this repository for customer accounts -->
 
 # Onboard me
 

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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — written in this repository for customer accounts -->
 
 # Run this project
 

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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — 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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — 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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — 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?", "what machines do we have?", "how much capacity do we have?", "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.16.25 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.28 — written in this repository for customer accounts -->
 
 # What's happening
 

package/skills/whats-happening/references/machines.md

@@ -6,4 +6,4 @@ List each machine's name, whether it is self-hosted or Catalyst's, its teams, sl
 
 Use the response's capacity total. It already counts a cloud machine shared across teams once and excludes stale machines. A machine is stale when its runtime proof has expired or it has not checked in for 15 minutes. A stale machine stays in the list, with its last check-in, but contributes no live capacity. A missing check-in is unknown, not proof that a machine is live. A failed read is inconclusive; never report zero machines or zero capacity from a failure.
 
-For a requested change, an admin can run `catalyst hosts rename <name-or-id> <new-name>` or `catalyst hosts remove <name-or-id>`. Removal asks for confirmation; `--yes` records explicit consent for an unattended invocation. A member can read but cannot change machines. When a name matches more than one machine, use its ID. An admin choosing to run work on a new machine can name it during `catalyst setup`, or pass `--machine-name <name>`.
+For a requested change, an admin can run `catalyst hosts rename <name-or-id> <new-name>` or `catalyst hosts remove <name-or-id>`. Removal asks for confirmation; `--yes` records explicit consent for an unattended invocation. A member can read but cannot change machines. When a name matches more than one machine, use its ID. An admin choosing to run work on a new machine can name it during `catalyst setup`, or pass `--machine-name <name>`. On the machine itself, `catalyst runner stop` pauses it: it takes no new work and keeps its registration, and `catalyst hosts` lists it as `stopped`. `catalyst runner start` resumes it. `catalyst runner uninstall` removes everything setup put on that machine, revokes its registration and key, and lists what it left behind, such as checkouts. Prefer it to `catalyst hosts remove` for a machine you can reach, because removal alone leaves the machine's containers running.

package/skills/whats-happening/references/reading-from-the-cloud.md

@@ -13,9 +13,11 @@ Cloud reads are the default everywhere and need no local writer or database. Eac
 | what changed since a point | `catalyst query changes --since head` |
 | a ticket's events, newest first | `catalyst events query --ticket KEY-123` |
 | wait for a phase to finish | `catalyst events wait-for --ticket KEY-123 --type relay.phase.completed --after <head> --timeout 300` |
+| wait on a branch or PR | `catalyst events wait-for --ref owner/name:branch --type pr.* --after <head> --timeout 14400` |
+| read a ticket's messages | `catalyst messages read --ticket KEY-123` |
 
 A status-only read of a ticket and of its execution history is coming. No CLI flag selects it yet; read the full record.
 
-Events: `catalyst events` reads the cloud by default. `events status --json` gives the `head` to wait after. Exit 4 from `wait-for` is an outage, not a timeout. `--from-cache` reads the local event cache, which exists only where local sync is on.
+Events: `catalyst events` reads the cloud by default. `events status --json` gives the `head` to wait after. Exit 4 from `wait-for` is an outage, not a timeout; exit 2 is a refusal, with the reason. A wait on `--repo`, `--ref`, `--pr`, `--session` or `--to me` prints nothing until a match, so a long timeout costs nothing. `--from-cache` reads the local event cache, which exists only where local sync is on.
 
 Local SQL: `references/local-replica.md`, only when `configured: true`.