failproofai 1.0.1-beta.0 → 1.0.1

package/.next/standalone/docs-old/cli/audit.mdx

@@ -0,0 +1,188 @@
+---
+title: Audit past sessions (beta)
+description: "Count how often the agent did wasteful or risky things across past transcripts"
+---
+
+<Note>
+  **Beta feature.** The audit ships as beta while we collect early feedback.
+  The detector catalog and report format may change before the next stable
+  cut. Please open an issue if anything looks off.
+</Note>
+
+The audit replays your past agent-CLI transcripts through failproofai's policy
+engine and renders a shareable, visual report on the **`/audit` dashboard
+page** — your agent's archetype, a 0–100 score, and exactly which policies
+would have caught what.
+
+## Run it
+
+Three ways in — all land on the same `/audit` report.
+
+<CodeGroup>
+
+```bash npx (no install)
+npx -y failproofai audit
+```
+
+```bash failproofai audit
+failproofai audit
+```
+
+```bash failproofai (dashboard)
+failproofai
+```
+
+</CodeGroup>
+
+<CardGroup cols={3}>
+  <Card title="No install" icon="bolt">
+    `npx -y failproofai audit` fetches failproofai, runs the scan, and opens the
+    dashboard for you — nothing to install first.
+  </Card>
+  <Card title="From the CLI" icon="terminal">
+    `failproofai audit` runs the scan in your terminal, then opens
+    `localhost:8020/audit` automatically when it finishes.
+  </Card>
+  <Card title="From the dashboard" icon="gauge">
+    Run `failproofai` and click **Audit** in the navbar (between Policies and
+    Projects), or open `/audit` directly.
+  </Card>
+</CardGroup>
+
+<Tip>
+  Run `failproofai audit -h` (or `--help`) to see usage. A bare `failproofai
+  audit` needs **no account**, and **nothing from your sessions leaves this
+  machine** — anonymous usage counts still apply unless you set
+  `FAILPROOFAI_TELEMETRY_DISABLED=1`. The dashboard keeps serving until you stop
+  it with `Ctrl+C`. [Scheduled audits](#scheduled-audits) are the one exception:
+  they can email you what a scan finds, and you opt into that explicitly.
+</Tip>
+
+The dashboard scans past agent CLI transcripts on this machine (Claude Code, Codex, Copilot, Cursor, OpenCode, Pi) and reports how often the agent did things failproofai is built to stop — env-var checks, force pushes, redundant `cd <cwd>` prefixes, sleep-polling loops, re-reading files just edited, and more.
+
+For each transcript, every tool-use event is replayed through the 39 builtin policies **and** through 8 audit-only detectors that catch patterns not yet covered by runtime policies. Counts are aggregated per policy / detector across all sessions.
+
+## What you get
+
+The `/audit` page is a single-screen, shareable **poster** followed by four below-the-fold sections:
+
+1. **Poster** — your agent's identity at a glance: its **archetype** (one of 8 — `optimist`, `cowboy`, `explorer`, `goldfish`, `paranoid architect`, `precision builder`, `hammer`, `ghost`), its persona keywords, how rare that archetype is, and a **0–100 score** with a tier band (`S` down to `bottom tier`). Built to share — post to X or LinkedIn, or download it as a PNG.
+2. **`// strengths`** — what your agent already does well, as real numbers from the scan (e.g. clean-tool-call %, `0` push-to-main attempts), shown only where the relevant policy has a clean record.
+3. **`// quirks`** — what slipped through: a ranked table of behaviors failproofai would have caught — *when* it last happened, *what slipped* (and the builtin that would have blocked it), its *severity*, and how often it was *seen* (`new` / `recurring` / `N× seen`).
+4. **`// how to improve`** — the prescribed fix list: one row per policy with a copy-paste `failproofai policy add <slug>`, plus an **install all** button that enables every recommendation at once and shows your **projected score** if you did.
+5. **`// come back better`** — build the habit: set a re-audit email **reminder** (`3d` / `7d` / `14d` / `30d`) or re-audit now, and **invite a friend** to run their own audit (sent from failproof.ai, Cc'd to you). Reminders and invites require sign-in.
+
+## Scheduled audits
+
+If you run the **failproofaid daemon** (see [`failproofai config`](/cli/install-policies)),
+it can re-run the audit for you on a schedule and refresh the `/audit` report in
+the background. It is **off by default**, because the scan reads the *contents*
+of every agent session transcript on this machine — nothing scans on a timer
+until you ask for it.
+
+Turn it on from the terminal — this works on a headless box, and it is the
+only path that also sets up the email digest:
+
+```bash
+failproofai audit --schedule 7 --email you@yourdomain.com
+```
+
+| Command | What it does |
+|---|---|
+| `failproofai audit --schedule [days]` | Scan on a timer (default 7, clamped 1–90). Signs you in the first time, because the digest needs somewhere to go. |
+| `failproofai audit --schedule [days] --email you@yourdomain.com` | Same, answering the address up front so you go straight to entering the emailed code. |
+| `failproofai audit --no-schedule` | Stop scanning on a timer. Leaves you signed in. |
+| `failproofai audit --status` | Whether scheduling is on, where reports go, the daemon's state, and when the next scan is due. |
+
+The same controls live on the dashboard's **/settings** page. Both write the
+same `~/.failproofai/config.json` through the same function, so the two are
+always in step.
+
+### What a digest sends
+
+A scheduled scan can email you when it finds something harmful. That email is
+the **only** thing that leaves your machine, and it carries:
+
+- **finding counts** per builtin policy,
+- **redacted example commands** — real command lines with secrets masked and
+  home paths shortened to `~/…/<file>`,
+- **this machine's name** (its hostname) and platform, so a digest from a
+  fleet says which box it came from.
+
+Custom-policy names and examples are never included, and an example never
+carries tool output or file contents.
+
+<Warning>
+  Redaction is pattern-based: it masks known credential shapes and `KEY=value`
+  assignments whose name says credential, but it reduces exposure rather than
+  eliminating it. If a machine's transcripts must never leave it, leave
+  scheduled digests off — the local scan and its dashboard work exactly the
+  same without them.
+</Warning>
+
+You can also set the keys directly in `~/.failproofai/config.json`:
+
+```json
+{
+  "audit": {
+    "auto": true,
+    "interval_days": 7
+  }
+}
+```
+
+| Key | Meaning |
+|---|---|
+| `auto` | `true` enables the scheduled scan. Anything else — absent, `false`, `"yes"` — is off. |
+| `interval_days` | Days between scans. Clamped to 1–90; `0`, a negative or a non-number falls back to `7`. |
+| `reports_consented_at` | Written **only** by `--schedule` or the settings toggle, when you sign in and are shown the list above. Emails are sent only if it is present, so hand-editing `auto` on its own gives you the local timer and no digest. |
+
+<Note>
+  Upgrading from a release before digests existed? `auto` used to mean "scan
+  locally on a timer" and nothing more. Machines that already had it keep
+  scanning and send **nothing** until you opt in again with
+  `failproofai audit --schedule` or the settings toggle — your old setting is
+  not read as consent to email.
+</Note>
+
+- The schedule is **wall-clock**, so it survives suspend and reboots: a laptop
+  that was asleep past its due time runs **once** on wake, never a backlog.
+- Each run is a separate, low-priority (`nice 19`) process — never the daemon's
+  hook path, which stays free to answer tool calls.
+- A scan is skipped if `failproofai audit` or the dashboard's re-run is already
+  in flight; it is retried shortly afterwards rather than treated as a failure.
+- Progress is written to `~/.failproofai/audit/schedule.json` (last run, next
+  due). The daemon owns that file — change the cadence with
+  `failproofai audit --schedule <days>`, on /settings, or in `config.json`.
+
+<Note>
+If you enabled this on a machine set up by an older failproofai, run
+`failproofai config` once. The daemon's service definition needs one extra
+entry before it can launch the CLI, and the refresh is part of that command.
+</Note>
+
+## Audit-only detectors
+
+These detect "stupid behavior" patterns not (yet) enforced in real time. They run only during the audit and never block a live tool call.
+
+| Detector | What it counts |
+|---|---|
+| `redundant-cd-cwd` | Bash commands starting with `cd <cwd> && …` even though commands already run in `cwd`. |
+| `prefer-edit-over-read-cat` | `cat`/`head`/`tail`/`less`/`more` on a single source file — use the `Read` tool. |
+| `prefer-edit-over-sed-awk` | `sed -i` / `awk … > file` in-place edits — use the `Edit` tool. |
+| `prefer-write-over-heredoc` | Heredoc / multi-line `echo > file` writing files — use the `Write` tool. |
+| `sleep-polling-loop` | Long `sleep N` (≥ 30s) or `while …; sleep …; done` polling loops. |
+| `find-from-root` | `find /`, `find /home`, `find /usr`, etc. — scope to `cwd` instead. |
+| `git-commit-no-verify` | `git commit … --no-verify` / `-n`, skipping hooks. |
+| `reread-after-edit` | `Read` of a file that was just `Edit`/`Write` in the same session. |
+
+## Caches
+
+- **Per-transcript cache** at `~/.failproofai/cache/audit/<sha1>.json` keyed by `(mtime, size, engineVersion, detectorVersion)` — invalidates automatically when the transcript or the policy/detector code changes. Each entry also stores a `cachedAt` timestamp as **TTL metadata** (not part of the cache key); entries older than **7 days** are rejected on read so long-lived results don't outlive evolving detector intent.
+- **Whole-result cache** at `~/.failproofai/audit-dashboard.json` (mode 0600). Lets the dashboard render instantly on navigation without re-running. Also rejected on read past the **7-day TTL** — `/audit` then falls through to its empty state and prompts a fresh run. Click `[ re-audit now ]` near the bottom of the report to refresh — re-audit sends `noCache: true`, so it bypasses the per-transcript cache and re-scans every transcript instead of returning the cached result; the run streams progress via a sticky top strip and swaps the result in place on success (no page reload; a failed re-audit keeps the previous report).
+
+## Notes
+
+- **No mutation.** The audit replays in read-only mode. `warn-repeated-tool-calls` is skipped because its per-session sidecar would otherwise be modified.
+- **Workflow policies skipped.** `require-*-before-stop` policies fire only on `Stop` events and `execSync` against the live git state — they have no meaningful "what would have happened in 2025" interpretation, so they don't appear in audit counts.
+- **Custom policies skipped.** User-supplied custom hooks are not replayed (they may have changed since the original session).

package/.next/standalone/docs-old/cli/dashboard.mdx

@@ -0,0 +1,29 @@
+---
+title: View sessions
+description: "Launch the dashboard to browse agent sessions and manage policies"
+---
+
+```bash
+failproofai
+```
+
+Starts the web dashboard at `http://localhost:8020`.
+
+## Options
+
+| Flag | Description |
+|------|-------------|
+| `--port <number>` | Port to listen on (default: `8020`) |
+| `--allowed-origins <origins>` | Comma-separated hosts/IPs allowed to access dev resources |
+
+To point the dashboard at a non-default Claude project folder, set the `CLAUDE_PROJECTS_PATH` environment variable when launching.
+
+## Examples
+
+```bash
+# Launch on a different port
+failproofai --port 9000
+
+# Use a custom Claude projects path via environment variable
+CLAUDE_PROJECTS_PATH=~/my-claude-projects failproofai
+```

package/.next/standalone/docs-old/cli/environment-variables.mdx

@@ -0,0 +1,75 @@
+---
+title: Environment variables
+description: "Configure failproofai behavior with environment variables"
+---
+
+## Dashboard
+
+| Variable | Description |
+|----------|-------------|
+| `PORT` | Dashboard port (default: `8020`) |
+| `CLAUDE_PROJECTS_PATH` | Override where Claude Code project folders are found |
+| `FAILPROOFAI_DISABLE_PAGES=policies,projects` | Comma-separated dashboard pages to hide |
+| `FAILPROOFAI_ALLOWED_DEV_ORIGINS` | Hosts/IPs allowed to access dev resources. Same as `--allowed-origins`. |
+
+## Logging
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_LOG_LEVEL=info\|warn\|error` | Server log level (default: `warn`) |
+| `FAILPROOFAI_HOOK_LOG_FILE` | Custom hook log file path, or `true` for default (`~/.failproofai/logs/hooks.log`) |
+
+## Telemetry
+
+failproofai reports anonymous usage telemetry by default. There are two ways to
+turn it off, and they resolve to whichever is more restrictive — an environment
+variable can never re-enable something the config file switched off.
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_TELEMETRY_DISABLED=1` | Disable anonymous usage telemetry for this process |
+
+To disable it permanently for the machine, add this to `~/.failproofai/config.json`:
+
+```json
+{
+  "telemetry": {
+    "enabled": false
+  }
+}
+```
+
+<Note>
+The config file is the option to use if you run the **failproofaid daemon**.
+The daemon is a system-scope service, and its environment does not include
+variables exported from your shell — so `FAILPROOFAI_TELEMETRY_DISABLED` cannot
+reach it. `[telemetry] enabled = false` is read by both the CLI and the daemon.
+</Note>
+
+The daemon reports its own **lifecycle** only: that it started (and whether the
+previous run exited cleanly), that it stopped, when its evaluation worker was
+spawned or restarted, when a collector task failed, and the outcome of a
+cloud-policy pull. These carry low-cardinality values and counts — never a file
+path, a command, a policy, a prompt, or anything read out of a transcript. There
+is no per-tool-call event.
+
+## Authentication
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOF_API_URL` | Override the api-server base URL used by the dashboard auth dialog. Defaults to `https://api.befailproof.ai`; set to `http://localhost:8080` (or wherever) when running a local api-server. |
+| `FAILPROOFAI_AUTH_DIR` | Override where `auth.json` is stored (default: `~/.failproofai`). Mostly useful for isolated tests. |
+
+## First-run prompt
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_NO_FIRST_RUN=1` | Skip the prompt that offers to install policies on the first bare `failproofai` invocation |
+
+## LLM (for policy evaluation)
+
+| Variable | Description |
+|----------|-------------|
+| `FAILPROOFAI_LLM_BASE_URL` | LLM API endpoint (default: `https://api.openai.com/v1`) |
+| `FAILPROOFAI_LLM_API_KEY` | API key for LLM-powered policies |
+| `FAILPROOFAI_LLM_MODEL` | Model name (default: `gpt-4o-mini`) |

package/.next/standalone/docs-old/cli/hook.mdx

@@ -0,0 +1,30 @@
+---
+title: Hook handler (internal)
+description: "The subprocess Claude Code calls on each tool event"
+---
+
+```bash
+failproofai --hook <EventType>
+```
+
+This is the command registered in Claude Code's `settings.json` by `failproofai policies --install`. You don't normally call this directly.
+
+Reads a JSON payload from stdin, evaluates all enabled policies, and exits with a code indicating the decision:
+
+| Exit code | Decision | Effect |
+|-----------|----------|--------|
+| `0` | `allow` | Permit the action |
+| `1` | `deny` | Block the action - Claude sees the denial reason |
+| `2` | `instruct` | Inject guidance into Claude's context |
+
+### Supported event types
+
+| Category | Events |
+|----------|--------|
+| **Tool execution** | `PreToolUse`, `PostToolUse`, `PostToolUseFailure`, `PermissionRequest`, `PermissionDenied` |
+| **Session lifecycle** | `SessionStart`, `SessionEnd`, `Stop`, `StopFailure` |
+| **User interaction** | `UserPromptSubmit`, `Notification`, `Elicitation`, `ElicitationResult` |
+| **Subagents & tasks** | `SubagentStart`, `SubagentStop`, `TaskCreated`, `TaskCompleted`, `TeammateIdle` |
+| **Configuration** | `InstructionsLoaded`, `ConfigChange`, `CwdChanged` |
+| **File system** | `FileChanged`, `WorktreeCreate`, `WorktreeRemove` |
+| **Context** | `PreCompact`, `PostCompact` |

package/.next/standalone/docs-old/cli/install-policies.mdx

@@ -0,0 +1,57 @@
+---
+title: Install policies
+description: "Enable policies so they run on every agent tool call"
+---
+
+```bash
+failproofai policies --install [policy-names...] [options]
+```
+
+Writes hook entries into your installed agent CLI's settings file (Claude Code, OpenAI Codex, or GitHub Copilot CLI _(beta)_) so failproofai intercepts tool calls.
+
+Aliases: `failproofai p -i`
+
+## Options
+
+| Flag | Description |
+|------|-------------|
+| `--cli claude\|codex\|copilot` | Agent CLI(s) to install for; space-separated (e.g. `--cli claude codex copilot`) or repeated. Omit to detect installed CLIs and prompt. |
+| `--scope user` | Install into the user-scope settings file (Claude: `~/.claude/settings.json`; Codex: `~/.codex/hooks.json`; Copilot: `~/.copilot/hooks/failproofai.json`). Default. |
+| `--scope project` | Install into the project-scope settings file (Claude: `<cwd>/.claude/settings.json`; Codex: `<cwd>/.codex/hooks.json`; Copilot: `<cwd>/.github/hooks/failproofai.json`). |
+| `--scope local` | Claude only — installs into `<cwd>/.claude/settings.local.json`. Codex and Copilot do not have a `local` scope. |
+| `--custom <path>` / `-c` | Path to a JS file containing custom hook policies |
+
+## Behavior
+
+- **No policy names** - opens an interactive prompt to select policies
+- **Specific names** - enables those policies (added to any already enabled)
+- **`all`** - enables every available policy
+
+Installation is additive: running `--install` again adds new policies without removing existing ones.
+
+## Examples
+
+```bash
+# Install all default policies globally (interactive)
+failproofai policies --install
+
+# Install specific policies for the current project
+failproofai policies --install block-sudo sanitize-api-keys --scope project
+
+# Enable all policies at once
+failproofai policies --install all
+
+# Install with a custom policies file
+failproofai policies --install --custom ./my-policies.js
+
+# Install for OpenAI Codex (project scope)
+failproofai policies --install --cli codex --scope project
+
+# Install for GitHub Copilot CLI (beta) for the current project
+failproofai policies --install --cli copilot --scope project
+
+# Install for all three CLIs at once
+failproofai policies --install --cli claude codex copilot
+```
+
+When `--custom <path>` is provided, the file is validated immediately - it must call `customPolicies.add()` at least once. The resolved path is saved to `policies-config.json` as `customPoliciesPath`.

package/.next/standalone/docs-old/cli/list-policies.mdx

@@ -0,0 +1,31 @@
+---
+title: List policies
+description: "See which policies are enabled, their parameters, and custom policies"
+---
+
+```bash
+failproofai policies
+```
+
+Shows all policies with their status, configured parameters, and custom policies.
+
+## Sample output
+
+```text
+Failproof AI Hook Policies (user)
+
+  Status  Name                          Description
+  ──────  ──────────────────────────────────────────────────────────────
+  ✓       block-sudo                    Block sudo commands
+            allowPatterns: ["sudo systemctl status"]
+  ✓       block-rm-rf                   Block recursive deletions
+  ✗       block-curl-pipe-sh            Block curl|bash patterns
+  ✓       sanitize-api-keys             Redact API keys from output
+            additionalPatterns: [{ regex: "MY_TOKEN_...", label: "..." }]
+
+  ── Custom Policies (/home/alice/myproject/my-policies.js) ──────────────
+  ✓       require-jira-ticket           Block commits without ticket
+  ✓       approval-gate                 Approval gate for destructive ops
+```
+
+Unknown keys in `policyParams` are flagged here so you can catch typos early.

package/.next/standalone/docs-old/cli/migrate.mdx

@@ -0,0 +1,117 @@
+---
+title: Migrate the home directory
+description: "Bring ~/.failproofai up to the layout this version speaks, and see what would happen first"
+---
+
+```bash
+failproofai migrate --dry-run   # print the plan, change nothing
+failproofai migrate             # run it
+```
+
+Most people never type this. It runs by itself on the first command after an
+upgrade, and [`failproofai update`](/cli/update) includes it. Reach for it
+directly when you want to see the plan before it happens, or to run the migration
+on its own.
+
+## Keyed on the layout, not the version
+
+`~/.failproofai/VERSION` records a **layout** number — the shape of the directory,
+not the release that wrote it. Migrations are keyed on that number, which is what
+makes a long gap cheap:
+
+- npm versions change on every release, dozens of them between two layouts.
+- So a machine that skips thirty releases with **no layout change** runs **zero**
+  migrations, not thirty no-ops.
+- And a machine that skips several layouts at once runs each step in order, each
+  step knowing only its own two ends.
+
+That matters because npm cannot update an installed package on its own. A machine
+sitting on one version for months and then jumping several layouts is the normal
+case, not the exotic one.
+
+## The dry run
+
+`--dry-run` prints the exact chain and the files that would be saved first, and
+changes nothing at all — no migration, no backup, no ledger entry:
+
+```
+Layout 2 on disk; this build speaks 3.
+1 step(s) would run:
+  2 → 3  layout 2 → 3: carry config.toml and credentials.toml into JSON, move
+         custom-policies/ back up into policies/, nest the policy config at the root
+
+These would be copied to ~/.failproofai/migrations/backup-layout2 first:
+  VERSION
+  config.toml
+  credentials.toml
+```
+
+## What is carried, and what is rebuilt
+
+Every path in the home declares what kind of data it holds, and that decides
+whether a migration may throw it away. The rule: **derived and re-fetchable may be
+dropped; anything you typed, anything not yet delivered, and anything that
+identifies the machine is carried.**
+
+| Carried | Rebuilt or re-fetched |
+|---|---|
+| `config.json` — settings, `daemon.configured`, extra capture paths | The audit cache |
+| `credentials.json` — your cloud enrolment | Cloud-managed deployments (re-fetched and digest-verified on the next poll) |
+| `policies-config.json` — your policy selection and params | Daemon scratch state |
+| `policies/` — your own policy files and the helpers they import | |
+| `hook-activity/` — the decision log the dashboard reads | |
+| Undelivered events still queued for upload | |
+| `cursors/` — collector watermarks | |
+| The daemon binary in `bin/` | |
+
+<Note>
+  Undelivered events are carried rather than dropped because the loss would be
+  permanent, not slow: the collector's watermark has already advanced past
+  anything sitting in the spool, so nothing would ever read that range of a
+  transcript again. The migration also asks the daemon to deliver what is spooled
+  as soon as it finishes, so the usual outcome is that there is nothing left to
+  carry.
+</Note>
+
+Keys a *newer* version wrote into `config.json`, `credentials.json` or
+`policies-config.json` are preserved too, rather than dropped by an older reader.
+
+## The record it leaves
+
+```
+~/.failproofai/migrations/
+  applied.json                 one entry per step: layout, CLI, timestamp, duration, result
+  backup-layout<n>/            copies of the irreplaceable files, taken before the first step
+```
+
+`applied.json` is what answers "what has this machine actually been through" — the
+first question worth asking when something looks wrong after an upgrade. Attach it
+to a bug report.
+
+The backup is deliberately small rather than a copy of the whole directory: the
+migration no longer deletes anything irreplaceable by design, so what is worth
+insuring against is a *defect in a step*, and these few files are where such a
+defect would hurt.
+
+## If a step fails
+
+The chain stops there. `VERSION` is stamped only by a step that completed, so the
+home stays marked with its old layout and the next command retries it — a home is
+never marked current on the strength of a partial migration. The step is recorded
+in `applied.json` with `"ok": false`, and the backup is where it was taken.
+
+## A newer home is refused, not migrated
+
+If `~/.failproofai/` was written by a **newer** failproofai than the one you are
+running, the command stops and tells you to upgrade instead. That data is fine and
+a newer CLI reads it; migrating "forward" from it is not a thing that exists, and
+resetting it would destroy something recoverable.
+
+```
+This machine's failproofai directory was written by a newer version (layout 4;
+this build speaks 3). Upgrade rather than migrate:
+  npm install -g failproofai@latest
+```
+
+The daemon applies the same rule: `failproofaid` refuses to start against a layout
+it does not speak, rather than reading and writing paths that have moved.

package/.next/standalone/docs-old/cli/remove-policies.mdx

@@ -0,0 +1,43 @@
+---
+title: Uninstall policies
+description: "Remove hook entries from Claude Code's settings"
+---
+
+```bash
+failproofai policies --uninstall [policy-names...] [options]
+```
+
+Removes failproofai hook entries from Claude Code's `settings.json`.
+
+Aliases: `failproofai p -u`
+
+## Options
+
+| Flag | Description |
+|------|-------------|
+| `--scope user` | Remove from global settings (default) |
+| `--scope project` | Remove from project settings |
+| `--scope local` | Remove from local settings |
+| `--scope all` | Remove from all scopes at once |
+| `--custom` / `-c` | Clear the `customPoliciesPath` from config |
+
+## Behavior
+
+- **No policy names** - removes all failproofai hook entries from the settings file
+- **Specific names** - disables those policies but keeps hooks installed
+
+## Examples
+
+```bash
+# Remove all hooks globally
+failproofai policies --uninstall
+
+# Disable a specific policy (keeps hooks installed)
+failproofai policies --uninstall block-sudo
+
+# Remove hooks from every scope
+failproofai policies --uninstall --scope all
+
+# Clear custom policies path
+failproofai policies --uninstall --custom
+```

package/.next/standalone/docs-old/cli/update.mdx

@@ -0,0 +1,94 @@
+---
+title: Update after an upgrade
+description: "Finish the half of an upgrade npm cannot do: migrate the home and match the daemon"
+---
+
+```bash
+npm install -g failproofai@latest && failproofai update
+```
+
+That is the whole upgrade. `npm` replaces the CLI; `failproofai update` does the
+rest.
+
+## Why a second command exists
+
+`npm install -g` replaces one thing — the CLI. Two other pieces of a failproofai
+install live outside the package on purpose, and neither moves when npm runs:
+
+- **`~/.failproofai/`**, your settings, cloud enrolment, policy selection and
+  history. A new version may organise it differently, and the reorganisation has
+  to be done by code that knows both shapes.
+- **The `failproofaid` daemon binary**, at
+  `~/.failproofai/bin/failproofaid-<version>`. It is deliberately *not* inside
+  `node_modules`: an upgrade that swapped the file under a running service would
+  repoint a live daemon at a binary built from different source, and removing the
+  package would delete it out from under a service that then crash-loops at every
+  boot.
+
+So after `npm install -g` alone, the CLI is new and the daemon is not.
+`failproofaid` refuses to start against a home layout it does not speak — the loud
+version of that mismatch rather than the silent one — so the two halves need
+bringing together. `failproofai update` is that step.
+
+## What it does
+
+<Steps>
+  <Step title="Runs any pending layout migrations">
+    Reads the layout recorded in `~/.failproofai/VERSION` and runs the steps that
+    bring it to the one this version speaks. Usually none — see
+    [`failproofai migrate`](/cli/migrate).
+  </Step>
+  <Step title="Puts the matching daemon binary in place">
+    From the platform package npm already downloaded where possible (no network),
+    otherwise from the release asset for this exact version, SHA-256 verified
+    before it is used.
+  </Step>
+  <Step title="Restarts the service and confirms it came back">
+    Probed rather than assumed — a service manager reports a process active the
+    moment it forks, which is not the same as it working.
+  </Step>
+</Steps>
+
+## Options
+
+| Flag | Effect |
+|------|--------|
+| `--no-daemon` | Migrate the home only, leaving the daemon at its current version. |
+
+<Warning>
+  `--no-daemon` leaves a version-skewed daemon in place. On a machine configured
+  to require the daemon, every hook event **fails closed** if the daemon cannot
+  answer — and a daemon that refuses to start against a migrated home cannot
+  answer. Prefer letting the daemon half run.
+</Warning>
+
+## If something goes wrong
+
+The command exits non-zero and says which half failed. Two cases worth knowing:
+
+- **A migration step did not finish.** The home is left marked with its *old*
+  layout, so the next command retries it — no home is ever marked current on the
+  strength of a partial migration. Copies of your settings and enrolment were
+  saved before anything ran, in `~/.failproofai/migrations/backup-layout<n>/`.
+- **The daemon could not be restarted without a password.** `sudo -n` is used
+  deliberately, so nothing ever prompts from under a progress display. The
+  command prints the exact line to run yourself.
+
+<Note>
+  Nothing here needs the interactive setup wizard. Your settings, cloud
+  enrolment and policy selection survive an upgrade, so a migrated machine
+  enforces exactly as it did before — which matters most on the machines with
+  nobody sitting at them: a CI runner, a fleet box, a headless gateway.
+</Note>
+
+## Automating it
+
+`failproofai update` is non-interactive and safe to run when there is nothing to
+do — it reports "no migration was needed" and exits 0. Putting it after every
+upgrade in a provisioning script or Dockerfile is the intended use:
+
+```dockerfile
+RUN npm install -g failproofai@latest && failproofai update --no-daemon
+```
+
+(`--no-daemon` in an image build, where there is no service to restart yet.)