failproofai 1.0.7-beta.2 → 1.0.7

package/src/hooks/semantic/types.ts

@@ -1,145 +0,0 @@
-/**
- * Types for the semantic (Jev-backed) evaluator.
- *
- * The regex engine answers "does this string match"; this one asks TypeSafe's
- * Jev a set of typed yes/no questions about the tool call and decides from the
- * probabilities. Everything here is plain data so the decision can be replayed
- * offline from a recorded response — see `decide.ts`.
- */
-
-/** Coarse class of a tool, derived deterministically from its canonical name. */
-export type ToolClass = "shell" | "write" | "read" | "network" | "other";
-
-/** A single yes/no question sent to Jev (the `noul` primitive). */
-export interface NoulQuestion {
-  type: "noul";
-  instructions: string;
-  criteria?: { true: string; false: string };
-}
-
-export interface JevRequest {
-  model: string;
-  state: Record<string, unknown>;
-  questions: Record<string, NoulQuestion>;
-}
-
-export interface JevNoulAnswer {
-  type?: "noul";
-  noul: number;
-}
-
-export interface JevResponse {
-  model: string;
-  answers: Record<string, JevNoulAnswer>;
-  usage?: { input_tokens?: number; output_tokens?: number };
-  /** Set when the provider did not report which Jev version answered (Cloudflare's unversioned alias). */
-  modelUnverified?: boolean;
-}
-
-/** A yes/no probe. A policy fires only when every one of its probes holds. */
-export interface Probe {
-  id: string;
-  instructions: string;
-  criteria?: { true: string; false: string };
-}
-
-export interface SemanticPolicy {
-  /** Short slug; registered as `semantic/<name>` in reasons and logs. */
-  name: string;
-  /** Past-tense, human-readable description of what was caught. */
-  title: string;
-  /** Tool classes this policy is asked about. Unknown/MCP tools get every policy. */
-  appliesTo: ReadonlyArray<ToolClass>;
-  /**
-   * `deny` policies block when the evidence is strong and instruct when it is
-   * moderate; `instruct` policies only ever warn.
-   */
-  mode: "deny" | "instruct";
-  /**
-   * Whether the user's own explicit request may clear this policy. False for
-   * the few things a prompt injection most wants to be approved for.
-   */
-  userCanOverride: boolean;
-  /** Every probe must hold for the policy to fire (conjunction). */
-  probes: ReadonlyArray<Probe>;
-  /** If this holds, the policy does not fire — the documented exceptions. */
-  exempt?: Probe;
-  /** Deterministic precondition over the facts; when false nothing is asked. */
-  precondition?: (facts: Facts) => boolean;
-  /** Shown to the agent when the policy fires. */
-  guidance: string;
-}
-
-export interface PathFact {
-  asWritten: string;
-  resolved: string;
-  relation: "inside_project" | "project_root" | "outside_project_in_home" | "home_root" | "system" | "root";
-}
-
-/** Deterministic facts computed locally, so Jev never has to count or resolve. */
-export interface Facts {
-  toolName: string;
-  toolClass: ToolClass;
-  /** False for tools no canonical map recognised — MCP tools, skills, etc. */
-  toolIsKnown: boolean;
-  cwd: string | null;
-  projectRoot: string | null;
-  currentGitBranch: string | null;
-  paths: PathFact[];
-  permissionMode: string | null;
-}
-
-export interface SemanticInput {
-  eventType: string;
-  toolName: string;
-  toolInput: Record<string, unknown>;
-  cwd?: string;
-  permissionMode?: string;
-  /** What the human typed recently, oldest first. Trusted channel only. */
-  userSaid: string[];
-  /**
-   * The agent's last visible message before the human's latest one — what a
-   * reply like "yes" or "do it" refers to. Agent-written, so it may only ever
-   * explain a human reply; it is never consent on its own.
-   */
-  agentLastMessage?: string | null;
-}
-
-/**
- * How "did the human ask for this?" is put to Jev.
- *
- * - `v0`: one `user_asked` question per policy, phrased as the policy's harm,
- *   plus a global `scope` question. Measured to clear a policy 6 times in
- *   1,332 cases.
- * - `v1`: three task-level questions asked once per call — is this a step
- *   toward the human's task, did they ask for this exact operation, does it
- *   reach beyond what they asked — judged only against the human's own words
- *   with harness-written text removed.
- */
-export type IntentMode = "v0" | "v1";
-
-export interface PolicyOutcome {
-  policy: string;
-  mode: "deny" | "instruct";
-  /** min over probe probabilities — one weak probe spoils the evidence. */
-  evidence: number;
-  exempt: number | null;
-  userAsked: number | null;
-  targetNamedByUser: boolean;
-  /** Fired, and the request also addressed the reviewer — so it was blocked outright. */
-  escalatedByInjection: boolean;
-  verdict: "deny" | "instruct" | "overridden" | "none";
-  /** v1 only: why an override applied, or that a deny was softened to instruct. */
-  intent?: "op-requested" | "task-step" | "downgraded-task-step";
-}
-
-export interface SemanticVerdict {
-  decision: "allow" | "deny" | "instruct";
-  reason: string | null;
-  outcomes: PolicyOutcome[];
-  injectionSuspected: number | null;
-  /** The `scope` answer: does the request stay within what the user asked? null when not asked. */
-  scopeWithinRequest: number | null;
-  /** v1 only: set when the call was flagged for reaching beyond the human's task. */
-  beyondTask?: boolean;
-}

package/src/hooks/semver-precedence.ts

@@ -1,128 +0,0 @@
-/**
- * Semver PRECEDENCE — ordering two version strings — for the one question a
- * pack manifest asks: is the CLI about to run this pack at least the version
- * the pack says it needs?
- *
- * ## Why this is written out rather than reused
- *
- * Nothing in this repo orders two versions. `daemonVersionSkew()` compares them
- * for EQUALITY, which is the right test there — the CLI and the daemon ship
- * from one commit, so anything but identical is skew — and it yields no
- * ordering at all. There is no semver dependency either: this module runs on
- * the hook path, and the loader's rule is that nothing there may pull in a
- * package.
- *
- * ## Why the obvious implementation is wrong here
- *
- * Splitting on dots and comparing numbers gets the release triple right and the
- * PRERELEASE exactly backwards. This package's version is `1.0.7-beta.0`, and
- * the beta cut from that line is the first build that understands
- * `minCliVersion` at all — so it is the build a pack's minimum is aimed at. On
- * numbers alone `1.0.7-beta.0` satisfies a minimum of `1.0.7`, which reads the
- * beta as the newer build when it is the older one, and the pack installs on a
- * CLI that may be missing the feature the minimum exists to require.
- *
- * So precedence follows semver §11 for real:
- *
- *     1.0.6 < 1.0.7-beta.0 < 1.0.7-beta.1 < 1.0.7 < 1.0.8
- *
- * - the release triple is compared numerically, field by field;
- * - a version WITH a prerelease is lower than the same triple without one;
- * - prerelease identifiers are compared left to right, numeric ones
- *   numerically and always below alphanumeric ones, and a longer identifier
- *   list wins when every shared identifier is equal;
- * - build metadata (`+2026.09.24`) is ignored, because it carries no precedence.
- *
- * Anything this cannot order is reported as unorderable rather than guessed at.
- * A caller comparing versions to decide whether to REFUSE something needs to
- * know the difference between "older" and "I cannot tell".
- */
-
-/** A version decomposed far enough to be ordered. Build metadata is dropped. */
-export interface SemVer {
-  major: number;
-  minor: number;
-  patch: number;
-  /** Dot-separated prerelease identifiers, numeric ones as numbers. Empty for a release. */
-  prerelease: ReadonlyArray<string | number>;
-}
-
-/**
- * Strict semver, and strict on purpose. `v1.0.0`, `1.0`, `01.2.3` and
- * `1.0.7-beta.0.` are all things people write and none of them has one
- * unambiguous ordering, so they are refused rather than normalised — a
- * `minCliVersion` nobody can order is a requirement nobody can check.
- */
-const SEMVER_RE =
-  /^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[A-Za-z-][0-9A-Za-z-]*)(?:\.(?:0|[1-9]\d*|\d*[A-Za-z-][0-9A-Za-z-]*))*))?(?:\+([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?$/;
-
-const NUMERIC_ID = /^(?:0|[1-9]\d*)$/;
-
-/** Decompose a version, or `null` when it is not one this can order. */
-export function parseSemver(value: unknown): SemVer | null {
-  if (typeof value !== "string") return null;
-  const m = SEMVER_RE.exec(value);
-  if (!m) return null;
-  return {
-    major: Number(m[1]),
-    minor: Number(m[2]),
-    patch: Number(m[3]),
-    prerelease: m[4] === undefined ? [] : m[4].split(".").map((id) => (NUMERIC_ID.test(id) ? Number(id) : id)),
-  };
-}
-
-const cmp = (a: number, b: number): number => (a < b ? -1 : a > b ? 1 : 0);
-
-/**
- * Compare two prerelease identifier lists. An EMPTY list is a release, and a
- * release outranks every prerelease of the same triple — the rule the naive
- * implementation loses, and the one that decides this release's own case.
- */
-function comparePrerelease(a: ReadonlyArray<string | number>, b: ReadonlyArray<string | number>): number {
-  if (a.length === 0 && b.length === 0) return 0;
-  if (a.length === 0) return 1;
-  if (b.length === 0) return -1;
-  for (let i = 0; i < Math.min(a.length, b.length); i++) {
-    const x = a[i];
-    const y = b[i];
-    if (x === y) continue;
-    const xNum = typeof x === "number";
-    const yNum = typeof y === "number";
-    // "Numeric identifiers always have lower precedence than non-numeric
-    // ones" (semver §11.4.3): `1.0.0-1` is below `1.0.0-alpha`, so an `rc.1`
-    // line and a `1` line never interleave by accident.
-    if (xNum !== yNum) return xNum ? -1 : 1;
-    if (xNum && yNum) return cmp(x as number, y as number);
-    return (x as string) < (y as string) ? -1 : 1;
-  }
-  // Every shared identifier is equal, so the longer list is the later build:
-  // `1.0.0-beta` < `1.0.0-beta.1`.
-  return cmp(a.length, b.length);
-}
-
-/** `-1`, `0` or `1` by semver precedence. */
-export function compareSemver(a: SemVer, b: SemVer): number {
-  return cmp(a.major, b.major) || cmp(a.minor, b.minor) || cmp(a.patch, b.patch) || comparePrerelease(a.prerelease, b.prerelease);
-}
-
-/**
- * `-1` / `0` / `1` for two version STRINGS, or `null` when either one cannot be
- * ordered. Null is deliberately not 0: a caller that treats "unorderable" as
- * "equal" silently accepts the requirement it could not check.
- *
- * There is deliberately NO `meetsMinimum(current, minimum): boolean | null` here.
- * It existed, and it collapsed two situations that need opposite treatment into
- * one value: an ABSENT minimum (every pack published before today has none, so it
- * must satisfy) and a MALFORMED one. A call site reading `=== false` would then
- * ignore a typo'd requirement, and one reading `!== true` would refuse every
- * pre-existing pack — and on an `enforce` pack that means denying every tool call
- * the pack covers. Neither mistake shows up until a user hits it, so the decision
- * is encoded once, where the field lives: `checkPackMinCliVersion` in
- * `pack-manifest.ts`.
- */
-export function compareVersions(a: unknown, b: unknown): number | null {
-  const left = parseSemver(a);
-  const right = parseSemver(b);
-  if (!left || !right) return null;
-  return compareSemver(left, right);
-}