failproofai 1.0.7 → 1.0.8

package/.next/standalone/app/actions/update-jev-config.ts

@@ -0,0 +1,569 @@
+"use server";
+
+/**
+ * Write side of the /settings "Jev" section — the dashboard's half of
+ * `failproofai jev setup` / `failproofai jev remove`.
+ *
+ * ## One file, one writer, one validator
+ *
+ * The file is `~/.failproofai/jev.json`, written through the same
+ * `writeJsonAtomically` the CLI's `jev setup` calls, with the same
+ * `{ mode: 0o600, dirMode: 0o700 }`, after the same `validateJevConfig` the
+ * loader itself runs. Nothing here re-states a rule that lives in
+ * `jev-config.ts`: not the URL scheme, not "plain http only in shadow mode",
+ * not "cloudflare needs an account id". A second copy of those rules is how the
+ * dashboard ends up writing a file the hooks then refuse — the exact failure
+ * mode this module exists to avoid.
+ *
+ * ## Cross-origin writes
+ *
+ * The dashboard is an unauthenticated local web server, so a page on any other
+ * site can POST to it from the victim's own browser. That matters more here
+ * than anywhere else on the surface: a cross-site write could point the
+ * evaluator at the attacker's endpoint — which then sees a redacted envelope
+ * for every command failproofai judges — or switch Jev on in enforce mode,
+ * where its answers can clear a deny.
+ *
+ * `proxy.ts` already refuses cross-origin mutating requests and non-loopback
+ * `Host` headers for the whole dashboard, and a Server Action is a POST, so it
+ * is covered. The check is repeated HERE, against the same
+ * `lib/dashboard-host` helpers so the two cannot diverge on what "loopback"
+ * or "same origin" means, because this is the one write on the dashboard whose
+ * payload is a credential and whose effect is the destination that credential
+ * is sent to. Two layers that read the same rule from one place cost a header
+ * lookup; one layer costs the whole feature if the middleware matcher is ever
+ * narrowed.
+ *
+ * ## The token
+ *
+ * It arrives, it is validated, it is written at 0600, and it is never returned.
+ * Both actions answer with a `JevSettingsView`, which carries a presence flag
+ * and no part of the key itself — see `get-jev-config.ts`.
+ *
+ * A stored token is KEPT only when the provider and the base URL are both
+ * unchanged and the file was owner-only. Anything else — a new provider, a
+ * moved endpoint, or a file other users could have written — asks for it
+ * again, because a key issued for one gateway must not be sent to another
+ * unasked. That is the CLI's rule, applied slightly more strictly: the CLI
+ * carries a key back to the provider's own API, and this surface does not,
+ * because a form with a blank field is a weaker statement of intent than a
+ * typed command.
+ *
+ * That rule is about a key MOVING, so it only applies where there is one to
+ * move. A config written by `jev setup --key-from-env` stores no key — a hook
+ * reads `FAILPROOFAI_JEV_API_KEY` at the moment it runs — and its endpoint,
+ * provider and mode are therefore editable here with the token field left
+ * blank: nothing travels anywhere it had not already been sent, and the key
+ * stays where its owner put it, outside the file. Asking for a token instead
+ * would be asking them to abandon that choice in order to change an endpoint,
+ * and the refusal did it while naming "the stored token" — a thing that
+ * deliberately does not exist in such a file.
+ *
+ * That includes a file the loader called too open. Re-saving it is the only
+ * remedy the panel has for those permissions — the write is 0600 and it
+ * tightens the directory — and there is no stored key to withhold, so refusing
+ * would leave the file broken and buy nothing: the endpoint that gets written is
+ * the one in the form, which the person can see and change, above the loader's
+ * own warning about the file. For a file that DOES store a key the refusal
+ * stands, because re-typing the token is what says "this key, for this
+ * endpoint".
+ *
+ * `--key-from-env` is inferred from the file being updated rather than asked
+ * for again, which is the one place this path is laxer than `jev setup`: the CLI
+ * makes you re-state `--key-from-env` when the provider changes. A form that
+ * offers no such flag would have no way to say it.
+ *
+ * ## What a save does NOT touch
+ *
+ * Only the fields the panel sends. Every other field in the file — `model`, a
+ * `timeoutMs` set from the CLI, anything a newer failproofai wrote — is carried
+ * over untouched. This is not a nicety. `model` decides which model id the
+ * request names, and a self-hosted or gateway endpoint that must be told its
+ * model stops answering anything at all once it is dropped — while the panel,
+ * whose write passed validation, reports success. A form must not be able to
+ * delete a field it does not show.
+ *
+ * The merge below is `jev setup`'s, field for field: spread the existing file
+ * when the provider is unchanged, carry `mode` and `timeoutMs` across when it
+ * is not, and set only what was named — `setOrClear` in `src/hooks/jev-cli.ts`,
+ * where a flag that was not given leaves its field alone. It is written out
+ * again here rather than called because that path is a terminal command
+ * (`argv` in, rendered lines out, its own key prompt) that lives in the hook
+ * bundle, and because this surface's key rule is deliberately stricter. What
+ * keeps the two from drifting is a test that runs both over the same file and
+ * compares the bytes: `__tests__/actions/update-jev-config.test.ts`, "agrees
+ * with `jev setup` about what an update keeps". Extracting one shared merge
+ * would be better still, and needs `src/hooks/semantic/jev-config.ts` to own
+ * it.
+ */
+
+import { chmodSync, existsSync, statSync, unlinkSync } from "node:fs";
+import { dirname } from "node:path";
+import { headers } from "next/headers";
+import { writeJsonAtomically } from "@/lib/atomic-write";
+import {
+  hostnameFromHostHeader,
+  isLoopbackHostname,
+  resolveDashboardHost,
+} from "@/lib/dashboard-host";
+import {
+  JEV_CLOUD_PROVIDER,
+  JEV_PROVIDER_KINDS,
+  baseUrlWithoutQuery,
+  endpointGivenAsBase,
+  jevConfigPath,
+  providerHostConflict,
+  readJevConfigFileForUpdate,
+  validateApiKey,
+  validateBaseUrl,
+  validateJevConfig,
+} from "@/src/hooks/semantic/jev-config";
+import { endpointAsBaseReason } from "@/src/hooks/semantic/jev-client";
+import { getJevSettingsAction, type JevSettingsView } from "./get-jev-config";
+
+/**
+ * What the panel sends — the four fields the form owns, and the token.
+ *
+ * Every field is a string; "" means "not set". There is deliberately no `model`:
+ * the form does not show one, so it has nothing to say about it, and a field
+ * this type does not carry is a field `saveJevConfigAction` cannot clear.
+ */
+export interface JevConfigInput {
+  provider: string;
+  /** "" routes to the provider's own API. */
+  baseUrl: string;
+  /** Cloudflare only. */
+  accountId: string;
+  /** "off" | "shadow" | "enforce". */
+  mode: string;
+  /** "" keeps the key where it is: the stored one, or the environment's. */
+  token: string;
+}
+
+export type JevWriteResult =
+  | { ok: true; view: JevSettingsView }
+  /**
+   * Returned, never thrown. Next masks a thrown server-action error before the
+   * browser sees it — the client gets an opaque digest and no message — so a
+   * validation problem the user could act on would arrive as "something went
+   * wrong". The same reasoning as `SetAutoAuditResult` next door.
+   */
+  | {
+      ok: false;
+      problem: string;
+      /** The one failure whose remedy is "type the token again", so the panel can say so on the field. */
+      needsToken?: true;
+    };
+
+/**
+ * The refusal text for every cross-origin shape, deliberately identical.
+ *
+ * Naming which check failed is a probing aid on an unauthenticated surface, and
+ * the legitimate caller — the dashboard's own page — can never see this string.
+ */
+const CROSS_ORIGIN_REFUSAL =
+  "this request did not come from the dashboard in your browser, so nothing was written.";
+
+/** Validation-only placeholder for a config whose key comes from the environment. Never written. */
+const ENV_KEY_STAND_IN = "env-key-stand-in";
+
+/**
+ * Refuse anything that is not a same-machine, same-origin call.
+ *
+ * A transcription of `proxy.ts`'s rule, built from the same
+ * `lib/dashboard-host` helpers rather than its own idea of loopback:
+ *
+ *   - on a loopback bind the `Host` must be loopback (this is what defeats DNS
+ *     rebinding, whose whole trick is arriving with an attacker-controlled Host
+ *     that its own Origin then matches);
+ *   - a mutating call with an `Origin` must have one whose full authority
+ *     equals that Host — another app on localhost:3000 is a different origin;
+ *   - no `Origin` at all is a non-browser caller, allowed only on a loopback
+ *     bind, where it is necessarily a local process that could edit
+ *     `jev.json` directly anyway. On a deliberately non-loopback bind
+ *     (`--host`, `FAILPROOFAI_DASHBOARD_HOST`) that describes every curl on the
+ *     network segment, so it is refused.
+ */
+async function crossOriginRefusal(): Promise<string | null> {
+  let h: Headers;
+  try {
+    h = await headers();
+  } catch {
+    // No request context at all. Nothing legitimate reaches these actions that
+    // way, and a write of a credential is not the place to assume otherwise.
+    return CROSS_ORIGIN_REFUSAL;
+  }
+  const bindHost = resolveDashboardHost(undefined, process.env.FAILPROOFAI_DASHBOARD_HOST);
+  const boundToLoopback = isLoopbackHostname(bindHost);
+  const hostHeader = h.get("host");
+
+  if (boundToLoopback) {
+    if (!hostHeader || !isLoopbackHostname(hostnameFromHostHeader(hostHeader))) {
+      return CROSS_ORIGIN_REFUSAL;
+    }
+  }
+
+  const origin = h.get("origin");
+  if (!origin) return boundToLoopback ? null : CROSS_ORIGIN_REFUSAL;
+
+  let originHost: string | null = null;
+  try {
+    // "null" (sandboxed iframes, some redirects) is a real Origin value; the
+    // URL constructor throws on it, which is the behaviour we want.
+    originHost = new URL(origin).host.toLowerCase();
+  } catch {
+    originHost = null;
+  }
+  return originHost && originHost === (hostHeader ?? "").toLowerCase() ? null : CROSS_ORIGIN_REFUSAL;
+}
+
+/** A base URL reduced to the thing that decides whether a key may travel: its origin. */
+function originOf(raw: string): string | null {
+  if (!raw) return null;
+  const r = validateBaseUrl(raw);
+  if (!r.ok) return null;
+  try {
+    const o = new URL(r.value).origin;
+    return o === "null" ? null : o;
+  } catch {
+    return null;
+  }
+}
+
+/**
+ * The base URL to WRITE for a submitted one.
+ *
+ * The panel is never sent a stored query string (`baseUrlView` in
+ * `get-jev-config.ts`), so what comes back from an untouched field is the stored
+ * URL with its query removed. Writing that verbatim would delete a query the
+ * person never saw — `?api-version=`, which some proxies route on — on any save
+ * that only meant to change the mode. So a submission that is exactly the
+ * stored URL minus its query keeps the stored one, and anything else is a URL
+ * they actually typed and is written as typed.
+ *
+ * Only a stored query the LOADER accepts is carried back. One it refuses is a
+ * credential in a base URL (`validateBaseUrl`), which is the very thing the
+ * person is on this page to repair: dropping it is the repair, and re-saving the
+ * file is the only way the panel has to perform it.
+ */
+function baseUrlToStore(submitted: string, stored: unknown): string {
+  if (typeof stored !== "string" || stored === "") return submitted;
+  const keep = validateBaseUrl(stored);
+  if (!keep.ok) return submitted;
+  const shown = baseUrlWithoutQuery(keep.value);
+  if (!shown.hadQuery) return submitted;
+  const typed = validateBaseUrl(submitted);
+  return typed.ok && typed.value === shown.url ? keep.value : submitted;
+}
+
+/**
+ * `~/.failproofai` at the umask is group-writable on a umask-002 machine, and a
+ * directory others can write into defeats the file's 0600 — they unlink it and
+ * leave their own, which every check on the file then passes. The one command
+ * that puts a key there takes those bits off, so the one PAGE that does must
+ * too. Exactly the write bits the loader refuses and no more.
+ */
+function tightenConfigDir(path: string): void {
+  if (process.platform === "win32") return;
+  const dir = dirname(path);
+  try {
+    const before = statSync(dir).mode & 0o777;
+    if ((before & 0o022) !== 0) chmodSync(dir, before & ~0o022);
+  } catch {
+    // Not fatal: the loader reports a directory it will not read from, and the
+    // panel shows that reason.
+  }
+}
+
+/**
+ * Save the Jev configuration, exactly as `failproofai jev setup` would.
+ *
+ * Returns the re-read view on success rather than echoing the input, so the
+ * panel confirms against what is actually on disk — including the permissions,
+ * the resolved endpoint and the provider default model it did not type.
+ */
+export async function saveJevConfigAction(input: JevConfigInput): Promise<JevWriteResult> {
+  const refusal = await crossOriginRefusal();
+  if (refusal) return { ok: false, problem: refusal };
+
+  const provider = input.provider.trim();
+  if (!(JEV_PROVIDER_KINDS as readonly string[]).includes(provider)) {
+    return { ok: false, problem: `provider must be one of ${JEV_PROVIDER_KINDS.join(", ")}` };
+  }
+  if (provider === JEV_CLOUD_PROVIDER) {
+    // Its endpoint and key come from this machine's FailproofAI Cloud
+    // connection, not from a form: `config --token` writes both, and the only
+    // thing this page may change about it is the mode (`setJevModeAction`).
+    return {
+      ok: false,
+      problem:
+        "FailproofAI Cloud's Jev is turned on by connecting this machine (failproofai config --token <key>), and switched with the mode control — not saved from this form.",
+    };
+  }
+
+  // Refused, as `setJevModeAction` and `jev setup --mode` refuse it — not
+  // skipped, which kept the old mode or wrote none (and none loads as enforce).
+  if (input.mode !== "off" && input.mode !== "shadow" && input.mode !== "enforce") {
+    return { ok: false, problem: 'mode must be "off", "shadow" or "enforce".' };
+  }
+
+  const baseUrl = input.baseUrl.trim();
+  // Checked here, before anything is decided about the token, so an
+  // unparseable URL is reported as an unparseable URL rather than as "that
+  // endpoint is not the one the token was given for" — which is what a URL
+  // that resolves to no origin would otherwise look like below.
+  const url = baseUrl ? validateBaseUrl(baseUrl) : null;
+  if (url && !url.ok) return { ok: false, problem: url.problem };
+
+  const existingFile = readJevConfigFileForUpdate();
+  const existing = existingFile?.raw ?? null;
+  const sameProvider = existing !== null && existing.provider === provider;
+
+  // `jev setup`'s refusal of an endpoint where a base belongs (`…/v1/models`):
+  // every call would go to `<that>/systemone` and 404 back to regex. Only for a
+  // URL typed here, as the CLI checks only a `--base-url` it was given — an
+  // older file whose base already ends in `/systemone` routes correctly and the
+  // loader takes it, so re-saving it untouched (a mode switch) must still work.
+  if (url?.ok) {
+    const stored = validateBaseUrl(existing?.baseUrl);
+    const untouched =
+      sameProvider && stored.ok && baseUrlWithoutQuery(stored.value).url === baseUrlWithoutQuery(url.value).url;
+    const conflict = untouched ? null : providerHostConflict(provider, url.value);
+    if (conflict) return { ok: false, problem: `${conflict}.` };
+    const asEndpoint = untouched ? null : endpointGivenAsBase(url.value);
+    if (asEndpoint) {
+      return {
+        ok: false,
+        problem: `that url is an endpoint, not an api base — its path ends in ${asEndpoint.suffix}. ${endpointAsBaseReason(url.value)} Use ${baseUrlWithoutQuery(asEndpoint.base).url} instead.`,
+      };
+    }
+  }
+
+  // Same provider: update in place, keeping every field not named here —
+  // `model`, a `timeoutMs` set from the CLI, and ones a newer failproofai wrote,
+  // none of which this form knows about or may drop. A different provider starts
+  // over: a key, model or URL for one gateway means nothing to another. Mode and
+  // timeout are provider-neutral, so they carry across, exactly as `jev setup`
+  // carries them.
+  const next: Record<string, unknown> = sameProvider ? { ...existing } : {};
+  if (!sameProvider && existing) {
+    if (existing.mode !== undefined) next.mode = existing.mode;
+    if (existing.timeoutMs !== undefined) next.timeoutMs = existing.timeoutMs;
+  }
+  next.provider = provider;
+
+  if (baseUrl) next.baseUrl = baseUrlToStore(baseUrl, existing?.baseUrl);
+  else delete next.baseUrl;
+
+  // `model` is NOT touched here, and that is the point: `JevConfigInput` has no
+  // model, so the spread above is the whole story for it. The CLI's `setOrClear`
+  // clears a field only for `--model default`, which is a thing a person typed;
+  // an empty input from a form that never offered the field is not.
+
+  const accountId = input.accountId.trim();
+  if (provider === "cloudflare") {
+    if (accountId) next.accountId = accountId;
+    else delete next.accountId;
+  } else {
+    // An account id means nothing anywhere else, and leaving a stale one behind
+    // would show up in `jev status` as a field this provider ignores.
+    delete next.accountId;
+  }
+
+  next.mode = input.mode;
+
+  // Where the key may travel. Unchanged provider AND unchanged origin, from a
+  // file only its owner could have written — anything else asks again.
+  const routeHeld =
+    sameProvider &&
+    existingFile?.tooOpen !== true &&
+    originOf(baseUrl) === originOf(typeof existing?.baseUrl === "string" ? existing.baseUrl : "");
+
+  /** Whether the file has a key in it at all. */
+  const storesKey = typeof existing?.apiKey === "string" && existing.apiKey !== "";
+
+  /**
+   * Whether the file being updated is one whose owner chose to keep the key OUT
+   * of it — `jev setup --key-from-env`, which the loader reports as
+   * `key-missing`, or as `ok` with `keySource: "env"` where the variable is set.
+   *
+   * Every refusal below is about a STORED key being carried somewhere it was not
+   * issued for, and there is none here: a hook reads
+   * `FAILPROOFAI_JEV_API_KEY` at the moment it runs, so the endpoint, the
+   * provider and the mode can all be edited with the token field left blank and
+   * nothing moves.
+   *
+   * It is the loader's own validator that decides, with a stand-in in the one
+   * slot that is deliberately empty — so a file that is merely BROKEN, and a
+   * machine with no file at all, are not mistaken for a deliberate choice and
+   * silently saved without any key. Those still ask for the token.
+   */
+  const keyFromEnvConfig =
+    existing !== null && !storesKey && validateJevConfig(existing, ENV_KEY_STAND_IN).ok;
+
+  const token = input.token.trim();
+  if (token) {
+    const bad = validateApiKey(token);
+    if (bad) return { ok: false, problem: bad, needsToken: true };
+    next.apiKey = token;
+  } else if (!routeHeld && !keyFromEnvConfig) {
+    return {
+      ok: false,
+      needsToken: true,
+      problem: !storesKey
+        ? // Nothing stored to carry and no deliberate absence to preserve: the
+          // only thing missing is a key, and no sentence here may imply there
+          // is one on disk.
+          "enter the token for this provider."
+        : sameProvider && existingFile?.tooOpen === true
+          ? // The loader's "someone else may have chosen this endpoint" case. The
+            // stored token is not carried anywhere from a file other users could
+            // have written, whatever endpoint it names.
+            `${jevConfigPath()} was open to other users, so the endpoint it names may not be one you chose and its stored token is not reused. check the endpoint above, then enter the token for it.`
+          : sameProvider
+            ? "that endpoint is not the one the stored token was given for, so it is not sent there. enter the token for it."
+            : "enter the token for this provider.",
+    };
+  }
+  // Otherwise the key stays exactly where it is: a stored one is carried over by
+  // the spread above, and a config that takes it from the environment keeps
+  // taking it from the environment.
+
+  // A config with no stored key takes it from `FAILPROOFAI_JEV_API_KEY` when a
+  // hook runs. That is a shape `jev setup --key-from-env` writes and this
+  // surface preserves but never creates, so the rest of the file still has to
+  // be checked — hence a stand-in in the one slot that is deliberately empty.
+  // It is never written and never sent.
+  const keyFromEnv = next.apiKey === undefined;
+  const checked = validateJevConfig(next, keyFromEnv ? ENV_KEY_STAND_IN : null);
+  if (!checked.ok) {
+    return {
+      ok: false,
+      problem: checked.problem,
+      ...(checked.missingKey === true ? { needsToken: true as const } : {}),
+    };
+  }
+
+  const path = jevConfigPath();
+  try {
+    writeJsonAtomically(path, next, { mode: 0o600, dirMode: 0o700 });
+  } catch (err) {
+    return {
+      ok: false,
+      problem: `could not write ${path} (${(err as NodeJS.ErrnoException).code ?? "error"}).`,
+    };
+  }
+  tightenConfigDir(path);
+
+  return { ok: true, view: await getJevSettingsAction() };
+}
+
+/**
+ * Switch Jev's mode — `off`, `shadow` or `enforce` — and change NOTHING else.
+ *
+ * This is the on/off switch for FailproofAI Cloud's Jev, whose `jev.json` the
+ * page must not delete: its endpoint and key are not this page's to re-enter,
+ * so "off" by deletion would be off until the owner re-ran `config --token`
+ * with the key in hand. `off` keeps the file and runs no Jev at all
+ * (`loadJevConfig` returns null for it), which is the switch this needs.
+ * It works on a BYOK file too, where it keeps the key.
+ *
+ * What "nothing else" means, precisely: the existing object is spread and only
+ * `mode` is set — no field is added, dropped or normalised, and the key, the
+ * endpoint and the provider are exactly what they were. It is written the way
+ * every other write here is (`writeJsonAtomically`, 0600, owner-only
+ * directory), after the loader's own validator has checked the result with
+ * stand-ins in the key slots, so `enforce` is refused where the loader would
+ * refuse it (plain http to localhost) rather than written and then ignored.
+ *
+ * Refused for a file the loader calls too open: someone else may have written
+ * the endpoint it names, and re-saving it at 0600 would start trusting that
+ * endpoint. Jev is already off for such a file; the page shows why and how.
+ */
+export async function setJevModeAction(mode: string): Promise<JevWriteResult> {
+  const refusal = await crossOriginRefusal();
+  if (refusal) return { ok: false, problem: refusal };
+  if (mode !== "off" && mode !== "shadow" && mode !== "enforce") {
+    return { ok: false, problem: 'mode must be "off", "shadow" or "enforce".' };
+  }
+
+  const existingFile = readJevConfigFileForUpdate();
+  if (existingFile === null) {
+    return {
+      ok: false,
+      problem: `there is no readable ${jevConfigPath()} to switch. connect this machine (failproofai config --token <key>) or set up your own endpoint below.`,
+    };
+  }
+  if (existingFile.tooOpen) {
+    return {
+      ok: false,
+      problem: `${jevConfigPath()} is open to other users, so Jev is already off and the endpoint it names is not trusted. fix its permissions first (chmod 600, and chmod 700 on its directory).`,
+    };
+  }
+
+  const next: Record<string, unknown> = { ...existingFile.raw, mode };
+
+  // The file as the loader would judge it, keys aside: a stored key is checked
+  // for real, a missing one (key-from-env, or the Cloud's) gets a stand-in —
+  // whether this machine is connected right now is not what a mode switch is
+  // about, and the page says so separately.
+  const cloud = next.provider === JEV_CLOUD_PROVIDER;
+  const checked = validateJevConfig(
+    next,
+    cloud || typeof next.apiKey === "string" ? null : ENV_KEY_STAND_IN,
+    cloud ? { url: originOrEmpty(next.baseUrl), key: ENV_KEY_STAND_IN } : null,
+  );
+  if (!checked.ok) return { ok: false, problem: checked.problem };
+
+  const path = jevConfigPath();
+  try {
+    writeJsonAtomically(path, next, { mode: 0o600, dirMode: 0o700 });
+  } catch (err) {
+    return {
+      ok: false,
+      problem: `could not write ${path} (${(err as NodeJS.ErrnoException).code ?? "error"}).`,
+    };
+  }
+  tightenConfigDir(path);
+  return { ok: true, view: await getJevSettingsAction() };
+}
+
+/** A stored base URL's origin, for a stand-in credential; "" when it has none. */
+function originOrEmpty(raw: unknown): string {
+  if (typeof raw !== "string") return "";
+  try {
+    return new URL(raw).origin;
+  } catch {
+    return "";
+  }
+}
+
+/**
+ * Delete `~/.failproofai/jev.json`. Hooks go back to the regex engine on the
+ * very next tool call — the loader reads the file per event, so there is
+ * nothing to restart and nothing to un-cache.
+ *
+ * Removing a file that is not there succeeds: the user asked for Jev to be off,
+ * and it is.
+ *
+ * The BYOK "turn jev off". The FailproofAI Cloud route is switched off with
+ * `setJevModeAction("off")` instead — see there for why deleting its file is
+ * the wrong switch.
+ */
+export async function removeJevConfigAction(): Promise<JevWriteResult> {
+  const refusal = await crossOriginRefusal();
+  if (refusal) return { ok: false, problem: refusal };
+
+  const path = jevConfigPath();
+  if (existsSync(path)) {
+    try {
+      unlinkSync(path);
+    } catch (err) {
+      return {
+        ok: false,
+        problem: `could not remove ${path} (${(err as NodeJS.ErrnoException).code ?? "error"}).`,
+      };
+    }
+  }
+  return { ok: true, view: await getJevSettingsAction() };
+}

package/.next/standalone/app/components/jev-notices.tsx

@@ -0,0 +1,96 @@
+"use client";
+
+/**
+ * The activity view's rendering of what Jev (the two-tier evaluator) did on a
+ * row.
+ *
+ * Only the rows where Jev changed or could have changed something get a pill:
+ * a clear (a regex deny Jev overruled), a fallback (Jev's answer was not used —
+ * unavailable, truncated or mismatched — and the regex policies decided alone),
+ * and a shadow-mode row where Jev disagreed with what was enforced. A fallback
+ * where Jev did answer (the call was truncated to fit the envelope) and its
+ * unapplied verdict was stricter than what was enforced gets a louder fallback
+ * pill; the collector ships that row on its own for the same reason.
+ *
+ * An ordinary Jev allow gets none — on a configured machine
+ * that is nearly every row, and a pill on all of them marks nothing. Nor does a
+ * hard deny Jev was never consulted on, or a call no semantic policy applied
+ * to: the detail panel says so, but the row is an ordinary regex result.
+ */
+import { describeJevActivity, jevOutcome, sanitizeJevActivity, type JevActivityFields } from "@/src/hooks/jev-activity";
+
+type JevRow = JevActivityFields & { decision?: string };
+
+const SEVERITY: Record<string, number> = { allow: 0, instruct: 1, deny: 2 };
+
+/** Which pill a row gets, if any. Exported for tests. */
+export function jevPillKind(
+  item: JevRow,
+): "cleared" | "would-clear" | "fallback" | "fallback-stricter" | "shadow-stricter" | null {
+  const e = sanitizeJevActivity(item);
+  const outcome = jevOutcome(e);
+  if (outcome === null || outcome === "not-consulted" || outcome === "no-request") return null;
+  const jevWasStricter = () => (SEVERITY[e.jevDecision ?? "allow"] ?? 0) > (SEVERITY[item.decision ?? "allow"] ?? 0);
+  if (outcome === "fallback") return e.jevDecision !== undefined && jevWasStricter() ? "fallback-stricter" : "fallback";
+  const cleared = (e.jevCleared ?? []).length > 0;
+  if (e.jevMode === "shadow") {
+    if (cleared) return "would-clear";
+    return jevWasStricter() ? "shadow-stricter" : null;
+  }
+  return cleared ? "cleared" : null;
+}
+
+const PILLS = {
+  cleared: {
+    label: "jev cleared",
+    title: "Jev reviewed a reviewable policy's block and cleared it",
+    className: "border-sky-500/40 bg-sky-500/10 text-sky-600 dark:text-sky-400",
+  },
+  "would-clear": {
+    label: "jev shadow",
+    title: "Shadow mode: Jev would have cleared a block here; the regex result was enforced",
+    className: "border-sky-500/30 bg-sky-500/5 text-sky-600/80 dark:text-sky-400/80",
+  },
+  "shadow-stricter": {
+    label: "jev shadow",
+    title: "Shadow mode: Jev would have been stricter here; the regex result was enforced",
+    className: "border-sky-500/30 bg-sky-500/5 text-sky-600/80 dark:text-sky-400/80",
+  },
+  "fallback-stricter": {
+    label: "jev fallback",
+    title: "Jev answered but its answer was not applied (e.g. the call was truncated); it would have been stricter than the regex result",
+    className: "border-amber-500/40 bg-amber-500/10 text-amber-600 dark:text-amber-400",
+  },
+  fallback: {
+    label: "jev fallback",
+    title: "Jev's answer was not used for this call (unavailable, truncated or mismatched); the regex policies decided alone",
+    className: "border-muted-foreground/30 bg-muted/40 text-muted-foreground",
+  },
+} as const;
+
+/** Marks a row where Jev cleared, fell back, or (in shadow mode) disagreed. */
+export function JevPill({ item }: { item: JevRow }) {
+  const kind = jevPillKind(item);
+  if (!kind) return null;
+  const pill = PILLS[kind];
+  return (
+    <span
+      title={pill.title}
+      className={`ml-1.5 inline-flex items-center rounded px-1.5 py-0.5 text-[0.6rem] font-medium uppercase tracking-wide border ${pill.className}`}
+    >
+      {pill.label}
+    </span>
+  );
+}
+
+/** The detail-panel line: what Jev said, cleared, or why it fell back. */
+export function JevNote({ item }: { item: JevRow }) {
+  const facts = describeJevActivity(item);
+  if (!facts) return null;
+  return (
+    <div className="sm:col-span-2 lg:col-span-3">
+      <span className="text-muted-foreground">Semantic review: </span>
+      <span className="font-mono text-foreground">{facts.join(" · ")}</span>
+    </div>
+  );
+}