spinuptui 1.3.0-alpha.1 → 1.3.0-alpha.2

package/CHANGELOG.md

@@ -11,6 +11,17 @@ version; such changes are called out here.
 
 ## [Unreleased]
 
+## [1.3.0-alpha.2] - 2026-10-26
+
+A pre-release, published on npm's `next` tag (`bun add -g spinuptui@next --no-cache`). `@latest` and Homebrew stay on 1.2.0.
+
+### Added
+- **Scheduler: follow-ups that run themselves.** Queue a job for later (`spinuptui scheduler add verify-410s --kind spinuptui --when "2026-10-21 08:00" --expires 2026-10-28 --created-by "…" -- incidents example.com`) and this machine runs it at that time, writes a report, and sends you the result through Beacon. Jobs can be a SpinupTUI command, a shell script, or a prompt for an agent CLI (Claude Code or Codex, read-only by default). They can be one-offs or recurring (`every 30m`, `weekdays 08:00`, `mon,thu 08:00`), and every job carries an expiry date so a forgotten one stops on its own. Jobs and reports live in `~/SpinupTUI/scheduler/`, a visible folder of your own. Make `~/SpinupTUI/` a git repository and Scheduler pulls it before each run and commits and pushes the reports, so you can queue a job from any machine with a commit. Only one machine runs a repository's jobs: the first station to tick it claims it, so a second machine with a dispatcher can't run them twice. `scheduler source claim` and `release` move them between machines. A job can say what happens when the station reaches it late (`--late run`, `skip`, or a grace window like `2h`). A skipped job is paged, not dropped silently. `scheduler list`, `show`, `run`, `cancel` and `validate` round it out. See [docs/scheduler.md](docs/scheduler.md).
+- **`spinuptui scheduler install --plan|--apply`** sets up the one LaunchAgent everything runs on: a tick at login and every five minutes, with the PATH a bare launchd environment lacks written into it. `--apply` doesn't report success until a tick has actually run under launchd. `uninstall` removes it and keeps your jobs and reports. Scheduler shows up live on the Modules tab (`6`), where `⏎` shows the same plan and installs it on confirm, and in `spinuptui modules`, which reports how long ago the last tick ran. Modules will declare their own recurring work for Scheduler to run, so a station needs only this one unit. The design is in [docs/2026-10-20_scheduler-spec.md](docs/2026-10-20_scheduler-spec.md).
+
+### Changed
+- **Headless commands start about three times faster.** `beacon send`, `incidents`, `ssh-exec`, `scheduler` and the rest no longer load the dashboard's renderer before looking at their arguments, which matters for something started every five minutes.
+
 ## [1.3.0-alpha.1] - 2026-10-21
 
 A pre-release, published on npm's `next` tag (`bun add -g spinuptui@next --no-cache`). `@latest` and Homebrew stay on 1.2.0. It continues `1.2.0-alpha.1` under a new number, because stable 1.2.0 shipped without the modules: it has Beacon and the Modules tab (see [1.2.0-alpha.1]) plus everything in [1.2.0]. The stable 1.3.0 will roll these notes up with the next modules.
@@ -1506,7 +1517,8 @@ Initial tagged release.
 ### Notes
 - Read-only release: works with a SpinupWP **Read Only** API token.
 
-[Unreleased]: https://github.com/mwender/spinupwp-tui/compare/v1.3.0-alpha.1...HEAD
+[Unreleased]: https://github.com/mwender/spinupwp-tui/compare/v1.3.0-alpha.2...HEAD
+[1.3.0-alpha.2]: https://github.com/mwender/spinupwp-tui/compare/v1.3.0-alpha.1...v1.3.0-alpha.2
 [1.3.0-alpha.1]: https://github.com/mwender/spinupwp-tui/compare/v1.2.0...v1.3.0-alpha.1
 [1.2.0]: https://github.com/mwender/spinupwp-tui/compare/v1.1.2...v1.2.0
 [1.2.0-alpha.1]: https://github.com/mwender/spinupwp-tui/compare/v1.1.2...v1.2.0-alpha.1

package/README.md

@@ -82,6 +82,11 @@
   pages you on Telegram from any cron job, watcher or agent, with retries, long
   messages split instead of dropped, and a send log. A guided setup creates the
   bot connection for you. → [docs/beacon.md](docs/beacon.md)
+  Then **Scheduler**: follow-ups that run themselves. Queue "check this
+  tomorrow at 8" from any session, and the result arrives through Beacon. Jobs
+  and reports live in `~/SpinupTUI/scheduler/`; make that folder a git
+  repository to queue from any machine. One LaunchAgent ticks every
+  5 minutes and is the clock the other modules run on. → [docs/scheduler.md](docs/scheduler.md)
 - **Non-interactive CLI subcommands for external tooling** — `spinuptui ssh <domain>`
   resolves a domain to a live SSH target with a live connectivity probe;
   `spinuptui ssh-exec <domain> -- <command>` runs a command over SSH, but only
@@ -375,7 +380,7 @@ These can be set in `config.json` or via an environment variable:
 | `w` | Open the selected server/site in the SpinupWP web app |
 | `/` | Jump to global search |
 | `A` | Accounts — switch, add, rename, or remove SpinupWP accounts (from anywhere) |
-| `⏎` / `s` | Set up the selected module — Beacon opens its guided Telegram setup (Modules tab) |
+| `⏎` / `s` | Set up the selected module — Beacon opens its guided Telegram setup, Scheduler its install plan (Modules tab) |
 | `t` | Send a test page through Beacon (Modules tab, once Beacon is set up) |
 | `r` | Refresh data from the API |
 | `i` | Explain the current screen (what each pane and key does) |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spinuptui",
-  "version": "1.3.0-alpha.1",
+  "version": "1.3.0-alpha.2",
   "description": "SpinupTUI — a terminal dashboard for browsing, monitoring, and managing your SpinupWP servers and sites.",
   "type": "module",
   "bin": {

package/src/config.ts

@@ -109,6 +109,12 @@ export interface AppConfig {
   // it relies on the file's 600 mode. The env channel (SPINUPTUI_BEACON_*) is
   // resolved in lib/beacon.ts, not here, so this is only what's stored.
   beacon: BeaconStored | null
+  // Scheduler's sources and installed dispatcher (lib/scheduler*.ts,
+  // docs/2026-10-20_scheduler-spec.md). Machine-level: a station runs one clock.
+  scheduler: SchedulerStored | null
+  // Where modules put the user's work (Scheduler's jobs and reports…); null =
+  // the default, ~/SpinupTUI. SPINUPTUI_HOME overrides. See modules/contract.ts.
+  homeDir: string | null
 }
 
 export interface BeaconTelegramChannel {
@@ -126,6 +132,18 @@ export interface BeaconStored {
   channels?: Record<string, BeaconChannel>
 }
 
+export interface SchedulerStored {
+  // Named job sources beyond the built-in `local` one: directories holding
+  // jobs/ and runs/, pulled and pushed when they are git repositories.
+  sources?: Record<string, { path: string }>
+  defaultSource?: string
+  // Git sources this machine only queues to: it never claims or runs them
+  // (set by `scheduler source release`, cleared by `claim`).
+  queueOnly?: string[]
+  // Written by `scheduler install --apply`, cleared by uninstall.
+  dispatcher?: { label: string; unitPath: string; bin: string; installedAt: string }
+}
+
 export interface ServerProviderRef {
   id: number
   databaseProviderId?: number
@@ -224,6 +242,8 @@ export interface StoredConfig {
   kumaMonitors?: Record<string, KumaMonitorRef>
   lastSeenVersion?: string
   beacon?: BeaconStored
+  scheduler?: SchedulerStored
+  homeDir?: string
 }
 
 // ---- Accounts (profiles) -------------------------------------------------------
@@ -510,6 +530,8 @@ export function loadConfig(): AppConfig {
     kumaMonitors: stored.kumaMonitors ?? {},
     lastSeenVersion: stored.lastSeenVersion?.trim() || null,
     beacon: stored.beacon ?? null,
+    scheduler: stored.scheduler ?? null,
+    homeDir: stored.homeDir?.trim() || null,
   }
 }
 

package/src/index.tsx

@@ -1,22 +1,15 @@
 #!/usr/bin/env bun
-// Entry point. Handles a few non-interactive CLI subcommands, then boots the
-// OpenTUI renderer and mounts either the first-run onboarding wizard (no token
-// yet) or the main app wrapped in the data store.
+// Entry point. Handles the non-interactive CLI subcommands, then hands off to
+// the dashboard (ui/main.tsx).
 
 // First, before any config read or spawn: keep a site checkout's .env from
 // leaking into child processes (see the module).
 import "./lib/cwdDotenv.ts"
-import { useCallback, useMemo, useState } from "react"
-import { createCliRenderer } from "@opentui/core"
-import { createRoot } from "@opentui/react"
+// Nothing UI-related is imported statically: headless commands (the Scheduler
+// tick every 5 minutes, beacon send, incidents…) never load the renderer or
+// React. The dashboard is a dynamic import at the bottom.
 import pkg from "../package.json" with { type: "json" }
-import { hasToken, configPath, loadConfig, pinActiveProfile, setActiveProfile, listProfiles } from "./config.ts"
-import { StoreProvider } from "./ui/store.tsx"
-import { App } from "./ui/App.tsx"
-import { AccountsContext, type AccountsApi } from "./ui/accounts.tsx"
-import { resetWpCoreJobs } from "./ui/wpCoreJobs.tsx"
-import { Onboarding } from "./ui/Onboarding.tsx"
-import { isDevMode } from "./dev/devMode.ts"
+import { configPath, loadConfig, listProfiles } from "./config.ts"
 import { SpinupWPClient } from "./api/client.ts"
 import { resolveSshAccess } from "./lib/cliSsh.ts"
 import { resolveIncidents } from "./lib/cliIncidents.ts"
@@ -25,6 +18,7 @@ import { execSshCommand } from "./lib/sshExec.ts"
 import { runPullFiles, runPullDb } from "./lib/cliPull.ts"
 import { runBeacon, runModules } from "./lib/cliBeacon.ts"
 import { runOffline, runOnline } from "./lib/cliOffline.ts"
+import { runScheduler } from "./lib/cliScheduler.ts"
 
 const args = process.argv.slice(2)
 const positionals = args.filter((a) => !a.startsWith("-"))
@@ -113,6 +107,11 @@ Usage:
                        Add a channel from a file holding TELEGRAM_BOT_TOKEN and
                        TELEGRAM_CHAT_ID; sends a test message before saving.
   spinuptui beacon test | status | remove <name>
+  spinuptui scheduler add <id> --kind spinuptui|script|agent --when <time> | --every <schedule>
+                       --expires <date> --created-by <who> -- <body>
+                       Queue a follow-up for this station to run later and report
+                       on through Beacon (\`spinuptui scheduler\` for the rest)
+  spinuptui scheduler list | status | install --plan|--apply
   spinuptui modules    List SpinupTUI's modules and their status (--json)
   spinuptui --version  Print the version
   spinuptui --help     Show this help
@@ -313,31 +312,11 @@ if (command === "modules") {
   process.exit(await runModules(args.slice(1)))
 }
 
-// `spinuptui login` forces the onboarding wizard even when a token already exists,
-// so the token can be (re)saved to the config file for global use.
-const forceLogin = command === "login"
-
-function Root() {
-  const [configured, setConfigured] = useState(isDevMode() ? true : forceLogin ? false : hasToken())
-  // The store is keyed by account: switching remounts it (see ui/accounts.tsx).
-  const [account, setAccount] = useState(() => pinActiveProfile())
-  const switchAccount = useCallback(async (id: string) => {
-    await setActiveProfile(id)
-    resetWpCoreJobs()
-    setAccount(id)
-  }, [])
-  const accounts = useMemo<AccountsApi>(() => ({ switchAccount }), [switchAccount])
-  if (!configured) {
-    return <Onboarding onComplete={() => setConfigured(true)} />
-  }
-  return (
-    <AccountsContext.Provider value={accounts}>
-      <StoreProvider key={account}>
-        <App />
-      </StoreProvider>
-    </AccountsContext.Provider>
-  )
+if (command === "scheduler") {
+  process.exit(await runScheduler(args.slice(args.indexOf("scheduler") + 1)))
 }
 
-const renderer = await createCliRenderer()
-createRoot(renderer).render(<Root />)
+// `spinuptui login` forces the onboarding wizard even when a token already exists,
+// so the token can be (re)saved to the config file for global use.
+const { startDashboard } = await import("./ui/main.tsx")
+await startDashboard({ forceLogin: command === "login" })