cli-setu 0.1.0 → 0.2.0

package/README.md

@@ -11,29 +11,29 @@ npm install -g cli-setu
 ## Usage
 
 ```bash
-setu              # bridges the current folder as a plain shell session
-setu --cli claude # same, but runs Claude Code inside the bridged session
-setu --cli codex  # or Codex
+cli-setu              # bridges the current folder as a plain shell session
+cli-setu --cli claude # same, but runs Claude Code inside the bridged session
+cli-setu --cli codex  # or Codex
 ```
 
-The first time you run it, `setu` prints a QR code (and an 8-digit fallback code) - scan it with the CLIसेतु app to pair this computer and start watching the session live.
+The first time you run it, `cli-setu` prints a QR code (and an 8-digit fallback code) - scan it with the CLIसेतु app to pair this computer and start watching the session live.
 
-Once paired, running `setu` in any folder just works - no QR code needed again, unless this is a device you haven't paired before.
+Once paired, running `cli-setu` in any folder just works - no QR code needed again, unless this is a device you haven't paired before.
 
 ## Other commands
 
 ```bash
-setu pair      # pair this computer, without starting a session
-setu status    # show pairing status and any sessions currently running
-setu stop      # stop a running session
-setu --update  # check for and install the latest version
-setu --version # print the installed version
-setu --help    # show all commands
+cli-setu pair      # pair this computer, without starting a session
+cli-setu status    # show pairing status and any sessions currently running
+cli-setu stop      # stop a running session
+cli-setu --update  # check for and install the latest version
+cli-setu --version # print the installed version
+cli-setu --help    # show all commands
 ```
 
 ## How it works
 
-`setu` spawns your real terminal (or Claude Code/Codex) inside a PTY, same as any terminal emulator. Every byte it produces streams live to the CLIसेतु app over a secure relay; anything you type on the phone writes back into that same PTY, exactly like a local keystroke. Permission prompts (file edits, shell commands, etc.) are detected and relayed as structured approve/reject cards instead of raw text, when the adapter for your CLI supports it.
+`cli-setu` spawns your real terminal (or Claude Code/Codex) inside a PTY, same as any terminal emulator. Every byte it produces streams live to the CLIसेतु app over a secure relay; anything you type on the phone writes back into that same PTY, exactly like a local keystroke. Permission prompts (file edits, shell commands, etc.) are detected and relayed as structured approve/reject cards instead of raw text, when the adapter for your CLI supports it.
 
 ## License
 

package/bin/setu.js

@@ -1,20 +1,26 @@
 #!/usr/bin/env node
-// Command dispatcher for the `setu` CLI. Kept deliberately thin - each
+// Command dispatcher for the `cli-setu` CLI. Kept deliberately thin - each
 // real subcommand's logic lives in src/, this file only parses argv and
 // calls the right one.
-const AUTH_SERVER = process.env.CLI_SETU_SERVER || 'https://api.clisetu.com';
+//
+// TEMPORARY: defaults to the DEV server (dev-api.clisetu.com), not
+// production, because only dev-api is live right now. MUST switch back to
+// https://api.clisetu.com and republish before announcing this package to
+// real users as "production ready" - see clisetuapp/backend's deployment
+// guide for when production actually goes live.
+const AUTH_SERVER = process.env.CLI_SETU_SERVER || 'https://dev-api.clisetu.com';
 const AUTH_SERVER_PUBLIC = process.env.CLI_SETU_SERVER_PUBLIC || AUTH_SERVER;
 
 // Real bug found by testing: this used to switch on process.argv[2]
 // directly against the subcommand list (pair/status/stop), with any
-// other value (including a real --flag, e.g. `setu --cli claude`)
+// other value (including a real --flag, e.g. `cli-setu --cli claude`)
 // falling through to "Unknown command" and exiting immediately - the
 // whole multi-CLI feature (claude/codex/shell adapters) was unreachable
-// through the real `setu` command this entire time, only ever testable
+// through the real `cli-setu` command this entire time, only ever testable
 // by calling node src/supervisor.js --cli claude directly. Flags
 // (anything starting with "-") are no longer mistaken for subcommand
-// names - they're checked first, and anything left over (bare `setu`, or
-// `setu --cli claude`/other flags meant for the bridged session itself)
+// names - they're checked first, and anything left over (bare `cli-setu`, or
+// `cli-setu --cli claude`/other flags meant for the bridged session itself)
 // falls through to the same "watch this session" path as before, which
 // still parses --cli on its own further down the line (supervisor.js) -
 // this dispatcher doesn't need to understand every flag supervisor.js
@@ -58,17 +64,17 @@ async function main() {
         return;
       }
       default:
-        console.error(`[setu] Unknown command: ${firstArg}`);
+        console.error(`[cli-setu] Unknown command: ${firstArg}`);
         printHelp();
         process.exit(1);
     }
   }
 
-  // Bare `setu` (or `setu --cli <name>`, `setu --cli <name> <workingDir>`,
+  // Bare `cli-setu` (or `cli-setu --cli <name>`, `cli-setu --cli <name> <workingDir>`,
   // etc. - real flags meant for the bridged session itself, parsed by
   // supervisor.js) - watch the current directory as a session. Real
   // product requirement: a brand-new user should be able to run just
-  // `setu` (no separate `setu pair` step to discover first) and see the
+  // `cli-setu` (no separate `cli-setu pair` step to discover first) and see the
   // QR/8-digit code immediately, the same "first run pairs AND starts
   // watching this session in one step" behavior the original
   // proof-of-concept had. Only pairs if not already paired - an
@@ -83,22 +89,22 @@ async function main() {
 }
 
 function printHelp() {
-  console.log(`[setu] Bridge your terminal to your phone.
+  console.log(`[cli-setu] Bridge your terminal to your phone.
 
 Usage:
-  setu                   Watch this folder as a session (pairs first if needed)
-  setu --cli <name>       Same, but run a specific CLI inside the bridged
+  cli-setu                   Watch this folder as a session (pairs first if needed)
+  cli-setu --cli <name>       Same, but run a specific CLI inside the bridged
                           session instead of the default plain shell
                           (e.g. --cli claude, --cli codex)
-  setu pair               Pair this computer with your phone, nothing else
-  setu status             Show pairing status and any sessions running now
-  setu stop               Stop a running session
-  setu --version, -v      Print the installed version
-  setu --update           Check for and install the latest version
-  setu --help, -h         Show this help`);
+  cli-setu pair               Pair this computer with your phone, nothing else
+  cli-setu status             Show pairing status and any sessions running now
+  cli-setu stop               Stop a running session
+  cli-setu --version, -v      Print the installed version
+  cli-setu --update           Check for and install the latest version
+  cli-setu --help, -h         Show this help`);
 }
 
 main().catch((err) => {
-  console.error('[setu] Error:', err.message);
+  console.error('[cli-setu] Error:', err.message);
   process.exit(1);
 });

package/package.json

@@ -1,10 +1,10 @@
 {
   "name": "cli-setu",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Bridge your terminal to your phone — run and approve Claude Code, Codex CLI and other AI coding agents from anywhere.",
   "type": "commonjs",
   "bin": {
-    "setu": "bin/setu.js"
+    "cli-setu": "bin/setu.js"
   },
   "main": "src/config.js",
   "engines": {

package/src/cli-adapters/index.js

@@ -13,11 +13,11 @@ const KNOWN_ADAPTERS = {
   shell,
 };
 
-// Real product decision (confirmed directly by the PM): bare `setu` with
+// Real product decision (confirmed directly by the PM): bare `cli-setu` with
 // no --cli flag bridges the user's own plain terminal, not Claude Code
 // specifically - the user decides what to run once it's open. Defaulting
 // to 'claude' here silently assumed every user wanted an AI CLI running
-// the instant they typed `setu`, which isn't actually the product's real
+// the instant they typed `cli-setu`, which isn't actually the product's real
 // intent (a genuine remote terminal, not an AI-agent-only bridge).
 function getAdapter(cliName) {
   const normalized = (cliName || 'shell').toLowerCase();

package/src/cli-adapters/shell.js

@@ -1,8 +1,8 @@
-// The default adapter when a user runs plain `setu` with no --cli flag at
-// all - a real gap in the earlier design: `setu` (bare) always launched
+// The default adapter when a user runs plain `cli-setu` with no --cli flag at
+// all - a real gap in the earlier design: `cli-setu` (bare) always launched
 // Claude Code specifically, silently assuming that's what every user
 // wants. The actual product intent (confirmed directly by the PM) is
-// simpler and more honest: `setu` bridges the user's OWN real terminal to
+// simpler and more honest: `cli-setu` bridges the user's OWN real terminal to
 // their phone - a genuine remote shell, nothing AI-specific - and the
 // user decides what to run inside it once it's open (`claude`, `codex`,
 // `npm install`, `git status`, anything). Running an AI CLI inside this
@@ -43,7 +43,7 @@ module.exports = {
   // INSIDE this shell, that CLI's own real adapter (claude.js/codex.js)
   // still isn't active here, since supervisor.js picks exactly one
   // adapter per process/session at startup - a real user wanting
-  // structured approvals for a specific CLI should run `setu --cli
+  // structured approvals for a specific CLI should run `cli-setu --cli
   // claude` (or codex) directly, same as always. This adapter is
   // specifically for "just give me my terminal, I'll decide what to run."
   approvals: null,

package/src/config.js

@@ -15,7 +15,7 @@ function defaultDeviceName() {
   return os.hostname() || 'My Computer';
 }
 
-// Saved once, on the first `setu pair`, so a later OS-level hostname
+// Saved once, on the first `cli-setu pair`, so a later OS-level hostname
 // change (renaming the machine, moving to a new user profile) doesn't
 // silently rename an already-paired device out from under the user - the
 // Devices tab's identity for this machine stays whatever it was when it
@@ -33,7 +33,7 @@ function writeConfig(config) {
   fs.writeFileSync(CONFIG_FILE, JSON.stringify(config, null, 2));
 }
 
-// Called by `setu pair` - creates the config the FIRST time, using the
+// Called by `cli-setu pair` - creates the config the FIRST time, using the
 // auto-detected hostname as the default device name. A config that
 // already exists (this machine has paired before) is left untouched;
 // re-pairing intentionally reuses the same device identity rather than

package/src/hooks.js

@@ -4,7 +4,7 @@
 // that - every user's global install lives at a different path (varies by
 // OS, by nvm/volta version manager, by whether it's a global or local
 // install), and expecting someone to hand-edit JSON before their first
-// `setu` run defeats the entire point of "npm install -g cli-setu" being
+// `cli-setu` run defeats the entire point of "npm install -g cli-setu" being
 // a real, ready-to-use install. This ensures the CURRENT project's
 // .claude/settings.json has the right hook registered, pointing at
 // wherever THIS running copy of cli-setu actually lives on disk right now
@@ -34,7 +34,7 @@ function alreadyRegistered(existingHooksForEvent) {
 
 // Ensures the CURRENT working directory's .claude/settings.json has both
 // hooks pointed at this package's real install location. Called once at
-// the start of every `setu` (bare) run - cheap (a few small file reads/
+// the start of every `cli-setu` (bare) run - cheap (a few small file reads/
 // writes), and self-healing if the package is ever moved/reinstalled at a
 // different path (a stale command string gets overwritten with today's
 // real path automatically, no manual fix needed).
@@ -48,8 +48,8 @@ function ensureHooksRegistered(projectDir) {
   } catch {
     // No settings.json yet, or it's not valid JSON - start fresh rather
     // than crash; an unreadable existing file is left untouched below by
-    // simply not being parsed further, but we still want `setu` itself to
-    // keep working for this session's approval detection.
+    // simply not being parsed further, but we still want `cli-setu` itself
+    // to keep working for this session's approval detection.
   }
 
   settings.hooks = settings.hooks || {};
@@ -73,7 +73,7 @@ function ensureHooksRegistered(projectDir) {
   if (changed) {
     fs.mkdirSync(claudeDir, { recursive: true });
     fs.writeFileSync(settingsPath, JSON.stringify(settings, null, 2));
-    console.log('[setu] Registered the approval-detection hook in .claude/settings.json');
+    console.log('[cli-setu] Registered the approval-detection hook in .claude/settings.json');
   }
 }
 

package/src/pair.js

@@ -11,18 +11,19 @@ async function pair(authServer, authServerPublic) {
   const config = loadOrCreateConfig();
 
   if (config.deviceToken) {
-    console.log(`[setu] "${config.deviceName}" is already paired.`);
+    console.log(`[cli-setu] "${config.deviceName}" is already paired.`);
     return config;
   }
 
-  console.log(`[setu] Pairing as "${config.deviceName}"...`);
-  console.log('[setu] (This is your computer\'s name. Rename it in ~/.cli-setu/config.json before pairing if you want something else.)');
+  console.log(`[cli-setu] Pairing as "${config.deviceName}"...`);
+  console.log('[cli-setu] (This is your computer\'s name. Rename it in ~/.cli-setu/config.json before pairing if you want something else.)');
 
   // qr-start also needs a sessionId up front (mirrors supervisor-qr.js's
   // "the QR both pairs it AND jumps the phone straight to watching THIS
-  // session" behavior) - 'pairing' is a placeholder id here since `setu
-  // pair` itself never streams a terminal; the real per-run session id is
-  // generated fresh by supervisor.js on every `setu` (bare) invocation.
+  // session" behavior) - 'pairing' is a placeholder id here since
+  // `cli-setu pair` itself never streams a terminal; the real per-run
+  // session id is generated fresh by supervisor.js on every `cli-setu`
+  // (bare) invocation.
   const startRes = await fetch(`${authServer}/device/pair/qr-start`, {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
@@ -34,8 +35,8 @@ async function pair(authServer, authServerPublic) {
 
   console.log('');
   qrcode.generate(scanUrl, { small: true });
-  console.log('[setu] Scan this with your phone camera.');
-  console.log(`[setu] (Testing on one PC? Paste this URL into a browser tab instead: ${scanUrl})`);
+  console.log('[cli-setu] Scan this with your phone camera.');
+  console.log(`[cli-setu] (Testing on one PC? Paste this URL into a browser tab instead: ${scanUrl})`);
 
   const codeRes = await fetch(`${authServer}/device/pair/start`, {
     method: 'POST',
@@ -43,8 +44,8 @@ async function pair(authServer, authServerPublic) {
     body: JSON.stringify({ deviceName: config.deviceName }),
   });
   const { code: typedCode, pairId: typedPairId } = await codeRes.json();
-  console.log(`[setu] Or type this code in the app's Devices tab: ${typedCode}`);
-  console.log('[setu] Waiting for scan or code entry...');
+  console.log(`[cli-setu] Or type this code in the app's Devices tab: ${typedCode}`);
+  console.log('[cli-setu] Waiting for scan or code entry...');
 
   let confirmed = false;
   while (!confirmed) {
@@ -56,13 +57,13 @@ async function pair(authServer, authServerPublic) {
       confirmed = true;
       config.deviceToken = status.deviceToken;
       writeConfig(config);
-      console.log(`[setu] ✓ Paired via QR and saved to ~/.cli-setu/config.json`);
+      console.log(`[cli-setu] ✓ Paired via QR and saved to ~/.cli-setu/config.json`);
       break;
     } else if (status.status === 'EXPIRED') {
-      console.error('[setu] QR code expired. Run `setu pair` again to get a new one.');
+      console.error('[cli-setu] QR code expired. Run `cli-setu pair` again to get a new one.');
       process.exit(1);
     } else if (status.status === 'REJECTED') {
-      console.error(`[setu] Pairing rejected: ${status.rejectReason || 'the server declined this pairing.'}`);
+      console.error(`[cli-setu] Pairing rejected: ${status.rejectReason || 'the server declined this pairing.'}`);
       process.exit(1);
     }
 
@@ -72,7 +73,7 @@ async function pair(authServer, authServerPublic) {
       confirmed = true;
       config.deviceToken = typedStatus.deviceToken;
       writeConfig(config);
-      console.log(`[setu] ✓ Paired via typed code and saved to ~/.cli-setu/config.json`);
+      console.log(`[cli-setu] ✓ Paired via typed code and saved to ~/.cli-setu/config.json`);
       break;
     }
   }

package/src/status.js

@@ -1,5 +1,5 @@
-// `setu status` - reports whether this computer is paired, and which
-// sessions (if any) currently have a `setu` process running, using the
+// `cli-setu status` - reports whether this computer is paired, and which
+// sessions (if any) currently have a `cli-setu` process running, using the
 // PID files supervisor.js writes/removes around its own lifetime (see
 // its own comment on why - there was no way to answer this question at
 // all before those existed).
@@ -21,10 +21,10 @@ function isProcessAlive(pid) {
 async function status(authServer) {
   const config = readConfig();
   if (!config || !config.deviceToken) {
-    console.log('[setu] Not paired. Run `setu pair` to get started.');
+    console.log('[cli-setu] Not paired. Run `cli-setu pair` to get started.');
     return;
   }
-  console.log(`[setu] Paired as "${config.deviceName}".`);
+  console.log(`[cli-setu] Paired as "${config.deviceName}".`);
 
   let files;
   try {
@@ -52,11 +52,11 @@ async function status(authServer) {
   }
 
   if (running.length === 0) {
-    console.log('[setu] No sessions currently running. Run `setu` in a project folder to start one.');
+    console.log('[cli-setu] No sessions currently running. Run `cli-setu` in a project folder to start one.');
     return;
   }
 
-  console.log(`[setu] ${running.length} session(s) running:`);
+  console.log(`[cli-setu] ${running.length} session(s) running:`);
   for (const s of running) {
     console.log(`  - ${s.sessionId} · ${s.cwd} · started ${s.startedAt} (pid ${s.pid})`);
   }

package/src/stop.js

@@ -1,4 +1,4 @@
-// `setu stop` - cleanly disconnects every session currently running on
+// `cli-setu stop` - cleanly disconnects every session currently running on
 // this computer. Real gap in the PoC this replaces: the only way to stop
 // a supervisor was closing its terminal window (or Ctrl+C, which only
 // reaches the one you're actually looking at) - this reaches every
@@ -15,7 +15,7 @@ async function stop() {
   }
 
   if (files.length === 0) {
-    console.log('[setu] No sessions currently running.');
+    console.log('[cli-setu] No sessions currently running.');
     return;
   }
 
@@ -35,7 +35,7 @@ async function stop() {
       // PID file. A hard kill would skip all of that and leave the CLI
       // process and the Azure connection to time out on their own.
       process.kill(info.pid, 'SIGINT');
-      console.log(`[setu] Stopped ${info.sessionId} (${info.cwd})`);
+      console.log(`[cli-setu] Stopped ${info.sessionId} (${info.cwd})`);
       stopped++;
     } catch {
       // Already dead - just clean up the stale file.
@@ -44,7 +44,7 @@ async function stop() {
   }
 
   if (stopped === 0) {
-    console.log('[setu] Sessions were already stopped (stale state cleaned up).');
+    console.log('[cli-setu] Sessions were already stopped (stale state cleaned up).');
   }
 }
 

package/src/supervisor.js

@@ -74,24 +74,27 @@ function log(...args) {
 }
 
 // Real config, from pairing (src/pair.js, either via bin/setu.js's own
-// bare-`setu` pairing check or the explicit `setu pair` command) - not
-// argv. bin/setu.js already guarantees this exists before requiring this
-// file for a normal `setu` run; this is a defensive fallback for anyone
-// requiring supervisor.js directly, so a null deviceToken fails with a
-// clear message instead of a confusing crash deep in connectToAzure().
+// bare-`cli-setu` pairing check or the explicit `cli-setu pair` command) -
+// not argv. bin/setu.js already guarantees this exists before requiring
+// this file for a normal `cli-setu` run; this is a defensive fallback for
+// anyone requiring supervisor.js directly, so a null deviceToken fails
+// with a clear message instead of a confusing crash deep in connectToAzure().
 const config = readConfig();
 if (!config || !config.deviceToken) {
-  console.error('[setu] This computer isn\'t paired yet. Run `setu` again, or run `setu pair` directly.');
+  console.error('[cli-setu] This computer isn\'t paired yet. Run `cli-setu` again, or run `cli-setu pair` directly.');
   process.exit(1);
 }
 const DEVICE_NAME = config.deviceName;
 
-const AUTH_SERVER = process.env.CLI_SETU_SERVER || 'https://api.clisetu.com';
+// TEMPORARY: defaults to the DEV server, not production - see bin/setu.js's
+// matching comment. Must switch back to https://api.clisetu.com before
+// treating this package as production-ready for real users.
+const AUTH_SERVER = process.env.CLI_SETU_SERVER || 'https://dev-api.clisetu.com';
 
-// --cli still supported, e.g. `setu --cli codex`, for the same reason it
+// --cli still supported, e.g. `cli-setu --cli codex`, for the same reason it
 // existed before: one paired device can run more than one kind of CLI
 // across different sessions/folders. Real product decision (confirmed
-// directly by the PM): bare `setu` with no --cli flag bridges the user's
+// directly by the PM): bare `cli-setu` with no --cli flag bridges the user's
 // own plain terminal (see cli-adapters/shell.js), not Claude Code by
 // default - the user decides what to run once it's open, same as
 // getAdapter's own default (index.js) - kept in sync here rather than
@@ -105,7 +108,7 @@ const WORKING_DIR = process.cwd();
 // plus the real working directory (not just the folder's basename, which
 // collides the moment two different projects share a folder name like
 // "app" on the same machine) plus a short random suffix so re-running
-// `setu` in the same folder twice at once (e.g. two terminal tabs) never
+// `cli-setu` in the same folder twice at once (e.g. two terminal tabs) never
 // silently shares one session.
 const dirHash = crypto.createHash('sha1').update(WORKING_DIR).digest('hex').slice(0, 8);
 const SESSION_ID = `${os.hostname()}-${dirHash}-${crypto.randomBytes(3).toString('hex')}`;
@@ -121,7 +124,7 @@ console.log(`[supervisor] Using CLI adapter: ${adapter.displayName} (${adapter.i
 log(`Using CLI adapter: ${adapter.displayName} (${adapter.id})`);
 
 // Real bug found by testing: when the spawned adapter is 'shell' (the
-// bare-`setu` default - see cli-adapters/shell.js), the user is expected
+// bare-`cli-setu` default - see cli-adapters/shell.js), the user is expected
 // to freely run `claude` INSIDE that bridged shell whenever they want to.
 // Gating hook registration on "is the spawn-time adapter Claude" (as this
 // used to) meant Claude Code's hooks never got installed into
@@ -141,21 +144,21 @@ const PROCESSED_FILE = path.join(CONFIG_DIR, `processed-requests.${SESSION_ID}.j
 const POLL_INTERVAL_MS = 300;
 
 // Always registered now (see QUEUE_FILE's comment above) - covers both
-// `setu --cli claude` (adapter itself is Claude) and bare `setu` /
-// `setu --cli shell` followed by the user manually running `claude`
+// `cli-setu --cli claude` (adapter itself is Claude) and bare `cli-setu` /
+// `cli-setu --cli shell` followed by the user manually running `claude`
 // inside the bridged shell.
 {
   const { ensureHooksRegistered } = require('./hooks');
   ensureHooksRegistered(WORKING_DIR);
 }
 
-// Real config, from `setu pair` (src/config.js) - not a per-device-name
-// token file. Pairing is now a separate, one-time command (`setu pair`)
+// Real config, from `cli-setu pair` (src/config.js) - not a per-device-name
+// token file. Pairing is now a separate, one-time command (`cli-setu pair`)
 // that must already have succeeded before this ever runs (checked above,
 // where the process exits early if config.deviceToken is missing) - so
 // unlike the PoC's ensurePaired(), there is no QR-pairing fallback here at
 // all. A session watcher's job is to watch a session, not to also be the
-// pairing flow; keeping them separate is what makes `setu` (bare) not
+// pairing flow; keeping them separate is what makes `cli-setu` (bare) not
 // need a QR code/camera every single run.
 let deviceToken = config.deviceToken;
 let deviceId = null;
@@ -585,7 +588,7 @@ function handleAzureDecision(msg) {
 // right of the actual PTY content - not a phone-side rendering bug at
 // all, a genuine laptop-side geometry mismatch. process.stdout.columns/
 // rows reflect the REAL terminal's actual current size at the moment
-// `setu` starts (falling back to the old 120x30 only if those aren't
+// `cli-setu` starts (falling back to the old 120x30 only if those aren't
 // available - e.g. output piped to a file, not a real TTY). Still a
 // FIXED size after this point, same reasoning as before (not read back
 // off ptyProcess after spawn, never resized again - see the
@@ -1236,8 +1239,8 @@ async function main() {
   process.stdin.resume();
   process.stdin.on('data', (data) => ptyProcess.write(data.toString()));
 
-  // Real gap in the PoC this replaces: there was no way for `setu status`
-  // or `setu stop` (both new - see src/status.js, src/stop.js) to know
+  // Real gap in the PoC this replaces: there was no way for `cli-setu status`
+  // or `cli-setu stop` (both new - see src/status.js, src/stop.js) to know
   // whether a session watcher was even running, or on which PID, since
   // supervisor-qr.js was always started and killed by hand in a visible
   // terminal. One small PID file per running session (keyed by

package/src/update.js

@@ -1,4 +1,4 @@
-// `setu --update` - checks the real npm registry for a newer published
+// `cli-setu --update` - checks the real npm registry for a newer published
 // version, and if one exists, runs the real upgrade command on the
 // user's behalf (confirmed directly: don't just tell them what to run,
 // actually run it) so they don't have to remember/type
@@ -35,24 +35,24 @@ function isNewer(latest, current) {
 }
 
 async function update() {
-  console.log(`[setu] Current version: ${pkg.version}`);
-  console.log('[setu] Checking for updates...');
+  console.log(`[cli-setu] Current version: ${pkg.version}`);
+  console.log('[cli-setu] Checking for updates...');
 
   let latest;
   try {
     latest = await fetchLatestVersion();
   } catch (err) {
-    console.error(`[setu] Could not check for updates: ${err.message}`);
+    console.error(`[cli-setu] Could not check for updates: ${err.message}`);
     process.exit(1);
   }
 
   if (!isNewer(latest, pkg.version)) {
-    console.log(`[setu] Already on the latest version (${pkg.version}).`);
+    console.log(`[cli-setu] Already on the latest version (${pkg.version}).`);
     return;
   }
 
-  console.log(`[setu] A newer version is available: ${latest} (you have ${pkg.version}).`);
-  console.log(`[setu] Installing ${pkg.name}@${latest}...`);
+  console.log(`[cli-setu] A newer version is available: ${latest} (you have ${pkg.version}).`);
+  console.log(`[cli-setu] Installing ${pkg.name}@${latest}...`);
   try {
     // execFile (not exec) - no shell involved, consistent with this
     // project's own established convention for anything that runs a
@@ -62,10 +62,10 @@ async function update() {
       shell: process.platform === 'win32', // npm.cmd on Windows needs a shell to resolve; execFile alone can't find it otherwise
     });
     if (stdout) console.log(stdout.trim());
-    console.log(`[setu] ✓ Updated to ${latest}.`);
+    console.log(`[cli-setu] ✓ Updated to ${latest}.`);
   } catch (err) {
-    console.error(`[setu] Update failed: ${err.message}`);
-    console.error(`[setu] You can try running it yourself: npm install -g ${pkg.name}@${latest}`);
+    console.error(`[cli-setu] Update failed: ${err.message}`);
+    console.error(`[cli-setu] You can try running it yourself: npm install -g ${pkg.name}@${latest}`);
     process.exit(1);
   }
 }