@catalyst-cloud/cli 0.16.40 → 0.16.41

package/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## 0.16.41
+
+A runner's automatic update schedule now applies a newly approved runner release at its next check, instead of waiting for one of four set times of day. An owner who wants set times can still choose them with `catalyst update policy windows <HH:MM,...>`, and `catalyst update policy windows default` goes back to applying at the next check. `catalyst runner update` still applies a release at once, and `catalyst update policy` shows which setting is in effect.
+
 ## 0.16.40
 
 `catalyst flow --repo <owner/name> --period 2w --granularity day` prints a repository's open pull request counts by the day, or by the hour with `--granularity hour`. `--json` prints the same buckets the SDK's `flow.series()` returns.

package/README.md

@@ -346,7 +346,7 @@ The skill files themselves are written by whichever install command you ran, in
 
 The new CLI is installed beside the old one, and your `catalyst` command runs it at the same path. A running local replica restarts on it and keeps its synced data; a stopped one stays stopped. CLI, SDK and image updates keep their existing policy against moving to an older version. Ordinary CLI startup never replaces skills with its bundled copy.
 
-On a machine checking for releases every 15 minutes (`catalyst runner auto-update on`), that check applies the same component policies. Otherwise components move when you run `catalyst update`. That check moves the runner images to a newer release only at set times of day, 03:00, 11:00, 16:00 and 22:00 in the machine's time zone, so a busy machine is not restarted every time a release is approved. `catalyst update policy windows 06:00,18:00 --time-zone America/Chicago` sets your own times, `catalyst update policy windows default` goes back to these, and `catalyst runner update` or `catalyst update` applies a waiting release at once. Each component is on by default; turn one off with `catalyst update policy <component> off` (for example `cli`), and `catalyst update policy` lists every setting. If you turned the installer's daily update off, the CLI and both skills packs start held, and `catalyst update policy cli on` turns the CLI back on.
+On a machine checking for releases every 15 minutes (`catalyst runner auto-update on`), that check applies the same component policies. Otherwise components move when you run `catalyst update`. That check moves the runner images to a newer release as soon as it finds one, with no set times of day. An update does not stop work that is already running: that work finishes on the image it started with. If you want updates only at set times, `catalyst update policy windows 06:00,18:00 --time-zone America/Chicago` sets your own times, `catalyst update policy windows default` goes back to none, and `catalyst runner update` or `catalyst update` applies a waiting release at once. Each component is on by default; turn one off with `catalyst update policy <component> off` (for example `cli`), and `catalyst update policy` lists every setting. If you turned the installer's daily update off, the CLI and both skills packs start held, and `catalyst update policy cli on` turns the CLI back on.
 
 The installer's daily job runs the same release check, so it moves the CLI and the Cloud skills only to the approved release and keeps your holds. Until the development skills join the release, it refreshes them from their repository.
 

package/dist/runner-command.js

@@ -9,7 +9,7 @@ import { dockerFleetUpdateEngine, postRollLines, readPostRollResult, runFleetPos
 import { runUpdate, sharedReleaseRead, updateReportJson, updateReportLines } from "./update.js";
 import { effectivePolicy, readUpdatePolicy, setComponentPolicy } from "./update-policy.js";
 import { resolveClaude } from "./update-plugin.js";
-import { defaultWindows, windowBounds } from "./update-windows.js";
+import { windowBounds } from "./update-windows.js";
 import { cmdRunnerLifecycle, RUNNER_LIFECYCLE_ACTIONS } from "./runner.js";
 /** Set on the re-run, so it never re-runs itself again. */
 export const CUSTODY_RERUN_ENV = "CATALYST_CUSTODY_NODE_RERUN";
@@ -156,16 +156,17 @@ export async function cmdRunner(args, ctx, deps = {}) {
         };
         // An owner's image hold stops this command's image work too, including the schedule's (CTC-6708).
         const hold = check ? null : imageHold(ctx);
-        // The schedule's run takes a newer release only in an update window; an owner's run applies at
-        // once (CTC-6709, update-windows.ts).
+        // The schedule's run takes a newer release at its next check, unless the owner saved update
+        // windows; then only in a window. An owner's own run applies at once (CTC-7465, update-windows.ts).
         if (hold !== null) {
             const retained = { outcome: "retained", detail: hold, generation: readReleaseState(dir()).generation, exitCode: hold === "owner_setting" ? 0 : 1 };
             // Unreadable settings move nothing; a hold leaves the other components to the release check.
             return print(retained, hold === "owner_setting" ? await components(undefined) : null);
         }
+        const ownerWindows = auto && !check && !fleet ? readUpdatePolicy(ctx.home).windows : undefined;
         const result = fleet
             ? await runFleetUpdate(deps.fleetEngine ?? dockerFleetUpdateEngine({ env: ctx.env }), { dir: dir(), check })
-            : await runRunnerUpdate(engine, { dir: dir(), check, ...(auto && !check ? { window: windowBounds(ctx.now().getTime(), readUpdatePolicy(ctx.home).windows ?? defaultWindows()) } : {}) });
+            : await runRunnerUpdate(engine, { dir: dir(), check, ...(ownerWindows ? { window: windowBounds(ctx.now().getTime(), ownerWindows) } : {}) });
         // `runner update --check` also lists every installed component against the approved release, as
         // `catalyst update --check` does. The image fields stay where scripts already read them.
         if (check && !fleet && !auto) {

package/dist/update-command.js

@@ -10,7 +10,7 @@ import { UsageError } from "./errors.js";
 import { dockerRunnerUpdateEngine, runnerDir } from "./runner-update.js";
 import { policyLines, readEffectivePolicy, runUpdate, updateReportJson, updateReportLines } from "./update.js";
 import { applySdkUpdate } from "./update-sdk.js";
-import { DEFAULT_WINDOW_TIMES, isTimeZone, normalizeWindowTimes } from "./update-windows.js";
+import { isTimeZone, normalizeWindowTimes } from "./update-windows.js";
 import { canonicalProject, effectivePolicy, isUpdateComponent, readUpdatePolicy, setComponentPolicy, setProjectSdkPolicy, setWindowPolicy, UPDATE_COMPONENTS, } from "./update-policy.js";
 const USAGE = "catalyst update [--check] [--project <absolute path>] [--dir <runner directory>] [--json] | update sdk --project <absolute path> | update policy [<component> on|off] | update policy sdk on|off --project <absolute path> | update policy windows <HH:MM,...>|default [--time-zone <zone>]";
 /** How each component reads in a sentence. */
@@ -41,7 +41,7 @@ function cmdPolicy(parts, args, ctx) {
             ctx.stdout(JSON.stringify({
                 components: UPDATE_COMPONENTS.map((id) => ({ id, ...effectivePolicy(policy, id) })),
                 projects: policy.projects.map((p) => ({ path: p.path, sdk: p.sdk, source: p.source })),
-                windows: { times: policy.windows?.times ?? [...DEFAULT_WINDOW_TIMES], timeZone: policy.windows?.timeZone ?? null, source: policy.windows ? "owner" : "default" },
+                windows: { times: policy.windows?.times ?? [], timeZone: policy.windows?.timeZone ?? null, source: policy.windows ? "owner" : "default" },
             }));
         else
             for (const line of policyLines(policy))
@@ -81,7 +81,7 @@ function cmdPolicy(parts, args, ctx) {
     return 0;
 }
 /** `update policy windows 03:00,11:00|default [--time-zone <zone>]`: when the schedule may take a
- *  newer runner release. `default` goes back to the four default times in the machine's zone. */
+ *  newer runner release. `default` goes back to no set times: the next check applies it. */
 function cmdWindows(parts, args, ctx) {
     const value = parts[2];
     if (parts.length !== 3 || value === undefined)
@@ -101,12 +101,14 @@ function cmdWindows(parts, args, ctx) {
         setWindowPolicy(ctx.home, { times, timeZone: zone ?? null });
     }
     const saved = readUpdatePolicy(ctx.home).windows;
-    const times = saved?.times ?? [...DEFAULT_WINDOW_TIMES];
+    const times = saved?.times ?? [];
     const timeZone = saved?.timeZone ?? null;
     if (args.json)
         ctx.stdout(JSON.stringify({ windows: { times, timeZone, source: saved ? "owner" : "default" } }));
-    else
+    else if (saved)
         ctx.stdout(`Runner releases now apply at ${times.join(", ")} (${timeZone ?? "this machine's time zone"}). catalyst runner update still applies one at once.`);
+    else
+        ctx.stdout("Runner releases now apply at the next check after one is approved, with no set times. catalyst runner update still applies one at once.");
     return 0;
 }
 async function cmdSdk(parts, args, ctx, deps) {

package/dist/update-policy.js

@@ -202,7 +202,7 @@ export function setProjectSdkPolicy(home, path, sdk) {
     });
     return saved ?? { ...project, sdk, source: "owner" };
 }
-/** Save the owner's update windows, or go back to the defaults with null. */
+/** Save the owner's update windows, or go back to none with null. */
 export function setWindowPolicy(home, windows) {
     return updateUpdatePolicy(home, (policy) => {
         if (windows === null)

package/dist/update-windows.js

@@ -1,15 +1,11 @@
-// update-windows.ts — the set times of day a self-hosted machine takes a new release (CTC-6709).
-// The 15-minute schedule checks often so an owner sees the approved release quickly, but a busy
-// machine restarting its supervisor every time a release lands would interrupt its owner's day as
-// often as releases ship. So the schedule applies a newer release only once a window has opened
-// since the last window a run settled, and an owner's own `catalyst runner update` applies at once.
-// Windows are wall-clock times in the machine's time zone, or the zone its owner saved.
-/** Four windows a day, spread so a release approved at any time waits at most about eight hours. */
-export const DEFAULT_WINDOW_TIMES = ["03:00", "11:00", "16:00", "22:00"];
+// update-windows.ts — the set times of day an owner may choose for a self-hosted machine to take a
+// new release (CTC-6709). By default there are none (CTC-7465): the 15-minute schedule applies a
+// newer release at its next check, because an update restarts only the supervisor, in place, and
+// every running job finishes on the image it started with. An owner who wants set times saves them
+// with `catalyst update policy windows`. The schedule then applies a newer release only once a window
+// has opened since the last window a run settled, and an owner's own `catalyst runner update` still
+// applies at once. Windows are wall-clock times in the machine's time zone, or the zone its owner saved.
 const TIME = /^([01][0-9]|2[0-3]):([0-5][0-9])$/;
-export function defaultWindows() {
-    return { times: [...DEFAULT_WINDOW_TIMES], timeZone: null };
-}
 export function isWindowTime(value) {
     return TIME.test(value);
 }
@@ -60,7 +56,9 @@ function instantOf(year, month, day, hour, minute, timeZone) {
 /** The window before and after `nowMs`. */
 export function windowBounds(nowMs, windows) {
     const timeZone = windows.timeZone ?? machineTimeZone();
-    const times = normalizeWindowTimes(windows.times) ?? [...DEFAULT_WINDOW_TIMES];
+    const times = normalizeWindowTimes(windows.times);
+    if (times === null)
+        throw new Error(`update windows ${JSON.stringify(windows.times)} are not 24-hour times`);
     const today = wallClock(nowMs, timeZone);
     const candidates = [];
     // Two calendar days either side of today's date in the zone. Stepping by date, not by 24 hours,

package/dist/update.js

@@ -21,7 +21,6 @@ import { applyCloudPluginUpdate, CLOUD_PLUGIN_COMMAND } from "./update-plugin.js
 import { onboardStatePath, readOnboardJournal } from "./onboard.js";
 import { effectivePolicy, projectIdentityHolds, readUpdatePolicy, UPDATE_COMPONENTS, withMigratedHolds, } from "./update-policy.js";
 import { applySdkUpdate, inspectSdkProject } from "./update-sdk.js";
-import { DEFAULT_WINDOW_TIMES } from "./update-windows.js";
 import { decideRelease, isRecord, parseDesiredRelease, readReleaseState, RELEASE_COMPONENTS, runRunnerUpdate, updateReport, } from "./runner-update.js";
 export const COMPONENT_LABELS = {
     runner: "Runner",
@@ -597,6 +596,6 @@ export function policyLines(policy) {
     for (const project of policy.projects)
         lines.push(`${cell(`SDK ${project.path}`, 19)}${cell(project.sdk === "auto" ? "on" : "off", 5)}(${project.source}${project.sdk === "notify" ? ", notify only" : ""})`);
     const windows = policy.windows;
-    lines.push(`Runner releases apply at ${(windows?.times ?? DEFAULT_WINDOW_TIMES).join(", ")} (${windows?.timeZone ?? "this machine's time zone"}; ${windows ? "owner" : "default"})`);
+    lines.push(windows ? `Runner releases apply at ${windows.times.join(", ")} (${windows.timeZone ?? "this machine's time zone"}; owner)` : "Runner releases apply at the next check, with no set times (default)");
     return lines;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@catalyst-cloud/cli",
-  "version": "0.16.40",
+  "version": "0.16.41",
   "description": "Set up Catalyst Cloud, check your tickets and manage your account from the command line.",
   "license": "MIT",
   "type": "module",

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.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — 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.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — 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.16.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — 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.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — 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.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — 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.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — 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.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — 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.40 — written in this repository for customer accounts -->
+<!-- vendored-from: @catalyst-cloud/catalyst-skills@0.16.41 — written in this repository for customer accounts -->
 
 # What's happening