failproofai 1.0.0-beta.5 → 1.0.0-beta.7

package/bin/failproofai.mjs

@@ -124,13 +124,13 @@ if (hookIdx >= 0) {
     // machine until `failproofai config` has installed failproofaid AND
     // written the daemonConfigured marker (Stage 4). Until then this is
     // byte-for-byte the same handleHookEvent(...) call below.
-    const { isDaemonConfigured, tryDaemonHook } = await import("../src/hooks/daemon-client");
+    const { isDaemonConfigured, attemptDaemonHook } = await import("../src/hooks/daemon-client");
     if (isDaemonConfigured()) {
       const { readStdinPayload } = await import("../src/hooks/read-stdin");
       const { evaluateHookEvent } = await import("../src/hooks/handler");
       const stdinRead = await readStdinPayload();
 
-      const daemonResult = await tryDaemonHook({
+      const attempt = await attemptDaemonHook({
         hookEvent: eventType,
         cli,
         stdin: stdinRead.payload,
@@ -140,21 +140,40 @@ if (hookIdx >= 0) {
         cwd: process.cwd(),
       });
 
-      // No silent fallback to in-process evaluation here: this machine was
-      // explicitly configured to run through the daemon, so an unreachable
-      // daemon fails closed instead — a loud, correctly-shaped deny (real
-      // per-CLI response shaping, not a generic denial) rather than a
-      // silent downgrade. See the plan's "Confirmed scope decisions".
-      const result =
-        daemonResult ??
-        (await evaluateHookEvent(eventType, cli, stdinRead.payload, {
-          forceDecision: {
-            decision: "deny",
-            reason:
-              "failproofaid could not be reached. This machine is configured to run hooks through it " +
-              "— check the daemon (see `failproofai config`) rather than retrying blindly.",
-          },
-        }));
+      // On a daemon-configured machine the daemon is the ONLY evaluator. Every
+      // way of not getting an answer from it denies, and in-process evaluation
+      // is never reached from this branch — that is what "all enforcement is
+      // routed through the daemon" means, and a fallback here would be a second
+      // policy engine reachable by breaking the first.
+      //
+      // The two failures still differ in what the USER has to do, so they are
+      // told apart in the message and nowhere else:
+      //
+      //   protocol-mismatch: a daemon answered, so it is alive; the CLI and the
+      //     daemon are different versions, which is what an `npm update` that
+      //     has not been followed by `failproofai config` looks like. The remedy
+      //     is an upgrade, and naming it is the difference between a one-command
+      //     fix and a support ticket. `daemonVersionSkew()` has already been
+      //     hinting this on every CLI command.
+      //
+      //   unreachable: nothing answered. A stopped service, a deleted socket and
+      //     deliberate tampering are indistinguishable from here — and a machine
+      //     where stopping one service silently disables every guardrail is not
+      //     a guarded machine.
+      let result;
+      if (attempt.ok) {
+        result = attempt.response;
+      } else {
+        const reason =
+          attempt.failure === "protocol-mismatch"
+            ? "failproofaid is running a different protocol version than this CLI, so it " +
+              "cannot evaluate this call. Run `failproofai config` to update the daemon."
+            : "failproofaid could not be reached. This machine is configured to run hooks through it " +
+              "— check the daemon (see `failproofai config`) rather than retrying blindly.";
+        result = await evaluateHookEvent(eventType, cli, stdinRead.payload, {
+          forceDecision: { decision: "deny", reason },
+        });
+      }
 
       if (result.stdout) process.stdout.write(result.stdout);
       if (result.stderr) process.stderr.write(result.stderr);
@@ -191,18 +210,8 @@ if (hookIdx >= 0) {
  * Error     → unexpected; shows message only, exits 2
  */
 async function runCli() {
-  // Report a fresh install / upgrade. Deliberately here rather than at module
-  // scope: everything above this point is the --hook fast path, which runs on
-  // every tool call. No-ops after the first run on a given version.
-  try {
-    const { maybeReportInstall } = await import("../lib/install-check");
-    await maybeReportInstall(version);
-  } catch {
-    // never block a command on reporting
-  }
-
   // --help / -h  (only when not inside a subcommand that handles its own --help)
-  const SUBCOMMANDS = ["policies", "policy", "auth", "audit", "config"];
+  const SUBCOMMANDS = ["policies", "policy", "audit", "config"];
   if ((args.includes("--help") || args.includes("-h")) && !SUBCOMMANDS.includes(args[0])) {
     const extraArgs = args.filter((a) => a !== "--help" && a !== "-h");
     if (extraArgs.length > 0) {
@@ -243,12 +252,6 @@ COMMANDS
 
   policies --help, -h            Show this help for the policies command
 
-  auth                           Sign in / out of FailproofAI from the CLI.
-    login                          Email + OTP flow; writes ~/.failproofai/auth.json
-    logout                         Revoke this session and remove auth.json
-    whoami                         Print the currently authenticated identity
-  auth --help, -h                Show this help for the auth command
-
   audit                          Audit your agent's behavior, then open the
                                  dashboard at http://localhost:8020/audit
   audit --help, -h               Show this help for the audit command
@@ -301,6 +304,112 @@ LINKS
     process.exit(0);
   }
 
+  // First-run onboarding — before any subcommand runs its own work.
+  //
+  // On a machine that has never been set up, the first thing the user typed is
+  // almost never the thing they need first, so we run the wizard and then let
+  // their original command proceed. Exemptions matter more than the rule:
+  //
+  //   --hook            never reaches here (it exits above) — it runs on every
+  //                     tool call, and a wizard on that path would hang an agent
+  //   --version/--help  answering "what is this" must not require setup
+  //   config            IS the wizard
+  //   policies/policy   explicit configuration actions. Intercepting these would
+  //                     fight the intent the user just stated, and would break
+  //                     non-interactive scripts that call them to do setup.
+  //
+  // `maybeFirstRunConfigure` is itself a no-op on a configured machine, on a
+  // non-TTY, and under sudo — so this is a cheap check, not a second gate.
+  // Layout check, before onboarding decides anything. A home written by an
+  // older layout is reset here — visibly, in a real command the user typed —
+  // rather than from a hook, which runs unattended once per tool call. A home
+  // written by a NEWER layout stops the command instead: that data is fine and
+  // an upgrade would read it, so deleting it would destroy something
+  // recoverable.
+  //
+  // `audit --scheduled` is the exception, and it takes the HOOK's branch: it is
+  // spawned by failproofaid on a timer, so "visibly, in a real command the user
+  // typed" is exactly what it is not. `checkLayoutForCli()` deletes
+  // config.toml and credentials.toml (see `resettablePaths`), so letting a
+  // background process reach it would silently revoke a user's
+  // `[telemetry] enabled = false`, erase their cloud enrolment, and switch off
+  // `[audit] auto` — the setting that scheduled the run — with the explanation
+  // going only to the service journal. Reachable on every machine at the next
+  // LAYOUT_VERSION bump, when a home carrying `auto = true` is by definition
+  // stale. Verified live: one scheduled tick took a home's whole config.
+  //
+  // `--help` / `--version` take the same exemption `first-run-gate.ts` gives
+  // them, and for a stronger reason. Those two answer "what is this / how do I
+  // use it"; the subcommands that parse their own help (`policies --help`) fall
+  // past the help block above and reach here, so without this a user typing
+  // `failproofai policies --help` had their home reset by a question. The
+  // adjacent, far less destructive first-run gate exempted help from the start.
+  let layoutWasReset = false;
+  {
+    const isHelpOrVersion =
+      args.includes("--help") || args.includes("-h") || args.includes("--version") || args.includes("-v");
+    if (args[0] === "audit" && args.includes("--scheduled")) {
+      const { layoutWarningForHook } = await import("../src/hooks/fp-reset");
+      const warning = layoutWarningForHook();
+      if (warning) {
+        // Exit 1, not 75: 75 means "another audit holds the lock" and is retried
+        // in fifteen minutes, which here would just re-warn four times an hour
+        // forever. A stale home is a real failure that `failproofai config`
+        // fixes, so it is reported and retried at the ordinary cadence.
+        console.error(warning);
+        process.exit(1);
+      }
+    } else if (!isHelpOrVersion) {
+      const { checkLayoutForCli } = await import("../src/hooks/fp-reset");
+      const check = await checkLayoutForCli();
+      for (const line of check.lines) console.error(line);
+      if (check.fatal) process.exit(1);
+      layoutWasReset = check.didReset;
+    }
+  }
+
+  // Report a fresh install / upgrade. AFTER the layout check above, never
+  // before: this writes the `last-version` marker, and while that file lived at
+  // the root of the home it was one of the landmarks `detectLayout()` reads as
+  // "layout 1". Running first meant the CLI created the file and then read it
+  // back as evidence of an old layout, so every genuinely fresh machine had its
+  // very first command open with "failproofai reorganised … Removed 1 item(s)
+  // from the old layout." Nothing was lost — there was nothing there — but
+  // training every new user to ignore that banner is expensive given what it
+  // says on a real layout-1 home. The file has also moved under `state/`, so
+  // the two are independent now; the order is kept because it is the correct
+  // one regardless.
+  //
+  // Deliberately not at module scope: everything above the CLI entry is the
+  // --hook fast path, which runs on every tool call. No-ops after the first run
+  // on a given version.
+  try {
+    const { maybeReportInstall } = await import("../lib/install-check");
+    await maybeReportInstall(version);
+  } catch {
+    // never block a command on reporting
+  }
+
+  const { shouldOfferFirstRun } = await import("../src/hooks/first-run-gate");
+  if (shouldOfferFirstRun(args) || layoutWasReset) {
+    try {
+      const { maybeFirstRunConfigure } = await import("../src/hooks/configure-wizard");
+      // `audit` runs its own scan immediately after this returns; firing the
+      // post-setup audit too would scan the whole history twice in a row.
+      //
+      // `force` after a reset: the home's policy config is gone, but the agent
+      // CLIs' settings files were deliberately left alone, so `isConfigured()`
+      // still reads true off `hasGlobalHooks` and setup would be skipped —
+      // leaving hooks firing against no policies, silently and permanently.
+      await maybeFirstRunConfigure(
+        {},
+        { postSetupAudit: args[0] !== "audit", force: layoutWasReset },
+      );
+    } catch {
+      // Onboarding is never allowed to block the command the user actually typed.
+    }
+  }
+
   // policies [--install|-i|--uninstall|-u|--help|-h] [names...] [--scope] [--beta] [--custom|-c <path>]
   if (args[0] === "policies") {
     const subArgs = args.slice(1);
@@ -566,19 +675,6 @@ EXAMPLES
     process.exit(0);
   }
 
-  // auth — email-OTP login flow against the FailproofAI api-server.
-  if (args[0] === "auth") {
-    lastSubcommand = "auth";
-    const { runAuthCli } = await import("../src/auth/cli");
-    await runAuthCli(args.slice(1));
-    await track("cli_auth_invoked", {
-      args_count: args.length - 1,
-      subcommand: args[1] ?? "help",
-      exit_code: process.exitCode ?? 0,
-    });
-    process.exit(process.exitCode ?? 0);
-  }
-
   // audit — scan local agent-CLI history, then launch the dashboard at /audit.
   if (args[0] === "audit") {
     lastSubcommand = "audit";
@@ -772,7 +868,7 @@ WHAT IT DOES
 FAILPROOF CLOUD
   failproofai config --connect <url> --token <key> [--machine-id <id>]
                                     Connect this machine to Failproof Cloud
-                                    [--send-transcripts] also send full session transcripts
+                                    [--no-transcripts] decisions only, no transcripts
   failproofai config --disconnect   Stop pulling policy and sending activity
   failproofai config --status       Show connection and pause state
 
@@ -786,8 +882,10 @@ FAILPROOF CLOUD
   that file is world-readable. Connecting needs no sudo, and the machine id
   defaults to this host's name.
 
-  Session transcripts carry prompts, file contents and whatever was pasted into
-  a terminal, so they are NEVER sent unless --send-transcripts is passed.
+  Connecting sends BOTH policy decisions and full session transcripts. A
+  transcript carries prompts, file contents and whatever was pasted into a
+  terminal — that is the point of connecting, and it is stated here rather than
+  buried behind a flag nobody finds. Use --no-transcripts for decisions only.
 
 PAUSING ENFORCEMENT (one session, always time-boxed)
   failproofai config --pause         Pause this directory's newest agent session (30m)
@@ -839,11 +937,15 @@ PAUSING ENFORCEMENT (one session, always time-boxed)
           url: valueAfter("--connect"),
           token: valueAfter("--token"),
           machineId: valueAfter("--machine-id"),
+          machineLabel: valueAfter("--machine-label"),
           defaultMachineId: hostname(),
-          // Opt-in only. A transcript carries prompts, file contents and
-          // whatever was pasted into a terminal, so it can never be a side
-          // effect of connecting.
-          sessions: args.includes("--send-transcripts"),
+          // Transcripts are what connecting is FOR, so they default on and the
+          // disclosure is made at the point of connection rather than hidden
+          // behind an opt-in flag most people never discover — a dashboard
+          // showing only decisions is the empty-dashboard problem in a
+          // different costume. --no-transcripts is the explicit way out, and
+          // `failproofai config --status` always says which is in effect.
+          sessions: !args.includes("--no-transcripts"),
         });
       }
       for (const line of result.lines) {
@@ -888,6 +990,9 @@ PAUSING ENFORCEMENT (one session, always time-boxed)
       if (wantsStatus) {
         const { connectionStatusLines } = await import("../src/hooks/cloud-enrollment-cli");
         for (const line of connectionStatusLines()) console.log(line);
+        // Always printed, including where reports can never work: "why am I
+        // not getting them?" is the question --status exists to answer, and an
+        // omitted line answers it with silence.
         console.log("");
       }
       for (const line of result.lines) {
@@ -907,10 +1012,36 @@ PAUSING ENFORCEMENT (one session, always time-boxed)
     const result = await runConfigureWizard();
     await track("cli_configure_invoked", {
       applied: result.applied,
-      scope: result.scope ?? null,
+      // `target` and `scopes`, not `scope`: the wizard rework replaced that
+      // field and nothing caught it, because `.mjs` is outside the tsconfig
+      // include so `tsc --noEmit` never type-checks this file. Every
+      // `cli_configure_invoked` since has reported `scope: null`.
+      target: result.target ?? null,
+      scopes: result.scopes ?? [],
       cli_count: result.clis?.length ?? 0,
+      abort: result.abort ?? null,
     });
-    process.exit(0);
+    // `abort` is the field `WizardAbort` exists to expose, and exiting 0
+    // regardless discarded it: a fleet script could not tell "the user pressed
+    // Esc" from "this machine could not install the required daemon and is
+    // unconfigured". Cancelling is not a failure; the other two are.
+    await exitAfterFlush(!result.applied && result.abort && result.abort !== "cancelled" ? 1 : 0);
+    return;
+  }
+
+  // Shared by both "unknown thing" guards below, so a mistyped SUBCOMMAND gets
+  // the same nearest-match treatment a mistyped flag already got.
+  function levenshtein(a, b) {
+    const m = a.length, n = b.length;
+    const dp = Array.from({ length: m + 1 }, (_, i) =>
+      Array.from({ length: n + 1 }, (_, j) => (i === 0 ? j : j === 0 ? i : 0))
+    );
+    for (let i = 1; i <= m; i++)
+      for (let j = 1; j <= n; j++)
+        dp[i][j] = a[i - 1] === b[j - 1]
+          ? dp[i - 1][j - 1]
+          : 1 + Math.min(dp[i - 1][j], dp[i][j - 1], dp[i - 1][j - 1]);
+    return dp[m][n];
   }
 
   // Unknown flag guard — must appear after all known-flag branches
@@ -918,20 +1049,7 @@ PAUSING ENFORCEMENT (one session, always time-boxed)
   const unknownFlag = args.find(a => a.startsWith("-") && !knownFlags.includes(a));
 
   if (unknownFlag) {
-    function levenshtein(a, b) {
-      const m = a.length, n = b.length;
-      const dp = Array.from({ length: m + 1 }, (_, i) =>
-        Array.from({ length: n + 1 }, (_, j) => (i === 0 ? j : j === 0 ? i : 0))
-      );
-      for (let i = 1; i <= m; i++)
-        for (let j = 1; j <= n; j++)
-          dp[i][j] = a[i - 1] === b[j - 1]
-            ? dp[i - 1][j - 1]
-            : 1 + Math.min(dp[i - 1][j], dp[i][j - 1], dp[i - 1][j - 1]);
-      return dp[m][n];
-    }
-
-    const primary = ["--version", "--help", "--hook", "policies", "policy", "auth", "audit"];
+    const primary = ["--version", "--help", "--hook", "policies", "policy", "audit"];
     const closest = primary.reduce((best, flag) => {
       const dist = levenshtein(unknownFlag, flag);
       return dist < best.dist ? { flag, dist } : best;
@@ -947,29 +1065,27 @@ PAUSING ENFORCEMENT (one session, always time-boxed)
   // Unknown subcommand guard (non-flag args that aren't a known subcommand)
   const unknownSubcommand = args.find(a => !a.startsWith("-") && !SUBCOMMANDS.includes(a));
   if (unknownSubcommand) {
+    // Nearest match rather than a hardcoded "policies", which was wrong for
+    // every input that was not a typo of it. `auth` made that concrete: it was
+    // a real subcommand until this release, so an old script or plain muscle
+    // memory lands here, and answering "did you mean policies?" sends someone
+    // to the one command that has nothing to do with what they typed.
+    const nearest = SUBCOMMANDS.reduce(
+      (best, name) => {
+        const dist = levenshtein(unknownSubcommand, name);
+        return dist < best.dist ? { name, dist } : best;
+      },
+      { name: SUBCOMMANDS[0], dist: Infinity },
+    );
     throw new CliError(
       `Unknown command: ${unknownSubcommand}\n` +
-      `Did you mean: failproofai policies?\n` +
+      `Did you mean: failproofai ${nearest.name}?\n` +
       `Run \`failproofai --help\` for usage details.`
     );
   }
 
-  // First-run onboarding — on the first bare `failproofai` invocation, run the
-  // configure wizard (which also fires the post-setup audit) BEFORE the
-  // dashboard. Unlike before, we then fall through to launch the dashboard, so a
-  // fresh user gets: setup → audit → dashboard, and every later `failproofai`
-  // goes straight to the dashboard. Best-effort: any error must not block launch.
-  if (args.length === 0) {
-    try {
-      const { maybeFirstRunConfigure } = await import("../src/hooks/configure-wizard");
-      await maybeFirstRunConfigure();
-    } catch {
-      // First-run onboarding is non-critical; fall through to the dashboard.
-    }
-  }
-
   // Dashboard launch — always production mode. Runs on every bare `failproofai`
-  // (after first-run onboarding, if any).
+  // (first-run onboarding, if any, already ran above).
   const { launch } = await import("../scripts/launch");
   launch("start");
 }