failproofai 1.0.0-beta.13 → 1.0.0-beta.15

package/src/hooks/daemon-service.ts

@@ -393,8 +393,25 @@ function systemdUnitName(user: string = serviceUser()): string {
   return `failproofaid@${user}.service`;
 }
 
+/**
+ * The unit directory, redirectable for tests ONLY.
+ *
+ * It was hardcoded, which left a test asserting "a failed install writes
+ * nothing" checking the REAL `/etc/systemd/system` — so it passed in CI, where
+ * nothing is installed, and failed on the machine of anyone who actually uses
+ * failproofai, whose genuine unit file is sitting right there. That is the bug
+ * class `handler.test.ts`'s header already documents: CI is green, so the red is
+ * only ever seen locally, by exactly the people who most need to trust the suite.
+ *
+ * Read through a function rather than captured at module load, because a test
+ * sets it after importing this module.
+ */
+function systemdUnitDir(): string {
+  return process.env.FAILPROOFAI_SYSTEMD_DIR || "/etc/systemd/system";
+}
+
 function systemdUnitPath(user: string = serviceUser()): string {
-  return resolve("/etc/systemd/system", systemdUnitName(user));
+  return resolve(systemdUnitDir(), systemdUnitName(user));
 }
 
 /**

package/src/hooks/fp-config.ts

@@ -242,7 +242,7 @@ export interface FpConfig {
     machineId?: string;
     /**
      * Extra locations to capture per harness, beyond the one each source ships
-     * with — `[collector.sources.<harness>] extra_paths` in `config.toml`.
+     * with — `collector.sources.<harness>.extra_paths` in `config.json`.
      *
      * Each entry is `label=path` or a bare `path`; the label becomes an agent-id
      * namespace (`<label>-<agentId>`), which is what keeps two copies of one

package/src/hooks/fp-home.ts

@@ -269,7 +269,7 @@ export const sessionPauseDir = () => resolve(stateDir(), "sessions");
  * The DAEMON is the sole writer (`crates/failproofaid/src/audit_lane.rs`, which
  * mirrors this path in `paths.rs`) — it owns the schedule, and a second writer
  * racing it could hand a machine two full scans back to back. Everything on this
- * side reads it: the interval itself lives in `config.toml`'s `[audit]` table,
+ * side reads it: the interval itself lives in `config.json`'s `audit` object,
  * which a human edits, while this file is derived state a human never opens,
  * which is why it sits under `state/` rather than beside the audit results.
  */
@@ -285,7 +285,7 @@ export const auditScheduleFile = (home?: string) => resolve(stateDir(home), "aud
  * `x64` where Rust says `x86_64`), and a near-miss there does not fail, it
  * silently files one machine under two PostHog persons — so this file is how the
  * two agree. Derived state a human never opens, hence `state/` rather than
- * beside `config.toml`.
+ * beside `config.json`.
  */
 export const telemetryIdFile = (home?: string) => resolve(stateDir(home), "telemetry-id");
 export const launcherMarker = (home?: string) => resolve(stateDir(home), "launcher-configured");

package/src/hooks/harness-cli.ts

@@ -18,13 +18,13 @@
  * from the feature working.
  *
  * The one thing validated here is the HARNESS NAME, because that failure has no
- * other detector: `[collector.sources.claud]` is valid TOML, parses cleanly,
+ * other detector: `collector.sources.claud` is valid JSON, parses cleanly,
  * captures nothing, and is mentioned nowhere else a user would look.
  *
  * # No restart, and no sudo
  *
  * This writes one file in the user's own home and nothing else. The daemon's
- * collector manager re-reads `config.toml` on an interval and cycles the
+ * collector manager re-reads `config.json` on an interval and cycles the
  * collector whenever the resolved `CollectorConfig` changes — the same path
  * that already picks up `--connect`, a stream being switched off, and a
  * verbosity change. `extra_paths` rides it for free by living inside
@@ -39,7 +39,7 @@ import { readConfig, updateConfig } from "./fp-config";
 import { configFile } from "./fp-home";
 
 /**
- * Harness keys `[collector.sources.<key>]` accepts.
+ * Harness keys `collector.sources.<key>` accepts.
  *
  * MUST stay in step with `HARNESS_KEYS` in `crates/failproofaid/src/main.rs`,
  * which is the side that actually registers the tasks. A name here that the
@@ -124,7 +124,7 @@ function writePaths(harness: string, paths: string[]): void {
 /**
  * No restart, and deliberately no instruction to perform one.
  *
- * The daemon's collector manager re-reads `config.toml` on an interval and
+ * The daemon's collector manager re-reads `config.json` on an interval and
  * cycles the collector whenever the resolved `CollectorConfig` changes — the
  * same path that already picks up `--connect`, a stream being switched off and
  * a verbosity change. `extra_paths` rides that for free because it lives inside
@@ -266,7 +266,7 @@ export function listPaths(harness?: string): HarnessResult {
     }
   }
   // Unknown tables are surfaced here as well as by the daemon: a user who
-  // hand-edited config.toml runs `list` to check it, and that is the moment the
+  // hand-edited config.json runs `list` to check it, and that is the moment the
   // typo is cheapest to find.
   if (unknown.length > 0) {
     if (lines.length === 0) lines.push("No extra capture paths configured for any known harness.");