@intutic/shared-types 2.1.0 → 2.3.0

package/dist/gateIdentity.js

@@ -0,0 +1,32 @@
+"use strict";
+/**
+ * Which gate an event came from, for the one harness that installs two.
+ *
+ * A harness is one `HarnessType`: one integration that `intutic connect` sets
+ * up, and the unit the harness count counts. Its gate reports under the same
+ * id, in hook events (`harnessType`), agent reports, the AI inventory and the
+ * SIEM export. `antigravity` is the exception: the integration installs
+ * Google Antigravity's `PreToolUse` gate and Gemini CLI's `BeforeTool` gate,
+ * for two products a machine may have together or apart. Each reports under
+ * its own gate id, `antigravity` and `gemini-cli`, so the silent-gate check
+ * expects only the gate of the product that is there, and the inventory and
+ * SIEM say which product a call came through. The harness, its rules file and
+ * its count stay one.
+ *
+ * @module
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.GEMINI_CLI_GATE_ID = void 0;
+exports.gateIdentitiesOf = gateIdentitiesOf;
+exports.harnessOfGate = harnessOfGate;
+/** The gate id Gemini CLI's gate reports under. */
+exports.GEMINI_CLI_GATE_ID = 'gemini-cli';
+/** The gate ids a harness's gates report under: its own id, or two for `antigravity`. */
+function gateIdentitiesOf(harness) {
+    return harness === 'antigravity' ? ['antigravity', exports.GEMINI_CLI_GATE_ID] : [harness];
+}
+/** The harness a gate id belongs to. */
+function harnessOfGate(gateId) {
+    return gateId === exports.GEMINI_CLI_GATE_ID ? 'antigravity' : gateId;
+}
+//# sourceMappingURL=gateIdentity.js.map

package/dist/gateIdentity.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"gateIdentity.js","sourceRoot":"","sources":["../src/gateIdentity.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;GAeG;;;AAMH,4CAEC;AAGD,sCAEC;AAXD,mDAAmD;AACtC,QAAA,kBAAkB,GAAG,YAAY,CAAA;AAE9C,yFAAyF;AACzF,SAAgB,gBAAgB,CAAC,OAAe;IAC9C,OAAO,OAAO,KAAK,aAAa,CAAC,CAAC,CAAC,CAAC,aAAa,EAAE,0BAAkB,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAA;AACpF,CAAC;AAED,wCAAwC;AACxC,SAAgB,aAAa,CAAC,MAAc;IAC1C,OAAO,MAAM,KAAK,0BAAkB,CAAC,CAAC,CAAC,aAAa,CAAC,CAAC,CAAC,MAAM,CAAA;AAC/D,CAAC"}

package/dist/gateKind.d.ts

@@ -0,0 +1,172 @@
+/**
+ * gateKind.ts — classifies each harness by HOW its tool calls get governed:
+ * for the sync daemon's agent report (`agentReporter.ts`'s `guardrails`
+ * facet) and AI inventory, and for the control plane's silent-gate check,
+ * which expects a gate only from a harness that has one of its own.
+ *
+ * # Why this exists
+ *
+ * `collectAgentReport` used to report `hook_gate: true` unconditionally for
+ * every harness, with the comment "the daemon writes the hook gate for every
+ * harness it supports." That was already false for `langgraph` — which has
+ * no on-disk hook, only the SDK-side `intutic_clawde.gate` — and for `aider`,
+ * whose only NO_GATE-registered mechanism is a post-edit, /run-blind
+ * pre-commit hook (see `aiderConfigMerger.ts`'s NO_GATE row in
+ * `__tests__/harness/gateRegistry.ts`). Wave 1 adds eight more SDK-gated
+ * harnesses, which would have made the lie eight times larger without this
+ * fix.
+ *
+ * # What this does NOT do
+ *
+ * This does not verify that a user actually pip-installed `intutic-clawde`
+ * and wired `guard_tools`/`IntuticMiddleware`/etc. into their process — the
+ * daemon cannot observe another process's imports, the same way it cannot
+ * observe whether a written hook file was left executable. It only reports
+ * which MECHANISM this harness's governance model uses (a file the daemon
+ * itself writes and can verify existence of, vs. an SDK the harness's own
+ * process must import), matching the trust level `hook_gate: true` already
+ * carried for file-based harnesses before this fix.
+ *
+ * # Keeping this in sync with the gate registry
+ *
+ * `services/sync-daemon/__tests__/harness/gateRegistry.ts` (the GATES/NO_GATE
+ * completeness registry exercised by `generatedGateBehaviour.test.ts`) is the
+ * authoritative decision per harness, but it is a test-only module (it
+ * dynamically imports every writer's compiled `.js` from a temp build dir)
+ * and must not be imported from daemon runtime code. `services/sync-daemon/__tests__/harness/gateKind.test.ts`
+ * cross-checks the two lists so this file cannot silently drift from that
+ * registry's own NO_GATE rows: `file: null` harnesses split between 'sdk'
+ * (LangGraph + the Python frameworks — the gate ships in intutic-clawde),
+ * 'delegated' (xirp — the gate is whichever wrapped harness's own gate is
+ * running), and 'bridge' (trueforge-server — the gate runs in a separate
+ * Intutic-operated service, not in any process this repo's writers touch),
+ * and 'none' (roo-code, claude-desktop — no hook system); the one non-null
+ * row (aiderConfigMerger.ts, "no ... exists") is 'none' too.
+ *
+ * @module
+ */
+import { type HarnessType as HarnessTypeT } from './enums.js';
+/**
+ * `'hook'`      — the daemon writes an on-disk hook/config file this harness
+ *                 reads before running a tool call (the 19-harness majority).
+ * `'sdk'`       — the blocking gate ships in `intutic-clawde`, imported into
+ *                 the harness's own Python process; no file for the daemon
+ *                 to write or verify (LangGraph + the eight Wave/Wave-2
+ *                 frameworks).
+ * `'none'`      — no tool-call gate exists for this harness (aider: its only
+ *                 native hook is post-edit and /run-blind; Roo Code and
+ *                 Claude Desktop: no hook system).
+ * `'delegated'` — this harness has no gate mechanism of its own because it
+ *                 does not run tools itself: it wraps OTHER harnesses that
+ *                 are already `'hook'`- or `'sdk'`-gated, and a tool call
+ *                 made inside it is governed by whichever wrapped harness's
+ *                 own gate is running (Xirp, Agentic Orchestrator, and — a
+ *                 different shape of the same idea — AgentCore Runtime,
+ *                 which HOSTS a customer's already-gated framework code
+ *                 rather than spawning it as a subprocess; see
+ *                 gateRegistry.ts's NO_GATE rows for the reasoning this
+ *                 precedent sets for future orchestrator/host-shaped
+ *                 harnesses).
+ *                 Every wrapped backend of the two orchestrators has a gate of
+ *                 its own (Agentic Orchestrator's `opencode` backend through
+ *                 `openCodeHooks.ts`), so `'delegated'`
+ *                 claims exactly what happens. Distinct from
+ *                 `'none'`: `'none'` means no enforcement point exists
+ *                 ANYWHERE for this harness's tool calls; `'delegated'`
+ *                 means one exists, just not one this harness's own row
+ *                 owns or can be credited for independently — reporting it
+ *                 as `'none'` would undercount real coverage, and reporting
+ *                 it as `'hook'` would overclaim a file this daemon never
+ *                 writes for the wrapping harness itself.
+ * `'bridge'`    — the gate runs OUT OF PROCESS, in an Intutic-operated
+ *                 service reacting to the harness's own async
+ *                 approval/event API, rather than a file this daemon writes
+ *                 (`'hook'`), an SDK imported into the harness's own process
+ *                 (`'sdk'`), no enforcement point at all (`'none'`), or
+ *                 governance credited to a wrapped harness's own gate
+ *                 (`'delegated'`) — a fifth, genuinely different shape.
+ *                 TRUEFORGE_SERVER is the first and so far only member: a
+ *                 TrueForge standalone/hosted server is a separate process
+ *                 nobody embeds an Intutic gate into (unlike TRUEFORGE,
+ *                 embedded mode, which IS `'sdk'`-gated — see that row's own
+ *                 doc), so `services/trueforge-bridge` watches its turn/event
+ *                 stream externally and answers pending approvals over HTTP.
+ *                 Distinct from `'delegated'`: a delegated harness's tool
+ *                 calls are governed by ANOTHER HARNESS's own gate running
+ *                 in that other harness's process; a bridge-gated harness's
+ *                 tool calls are governed by a service this repo ships and
+ *                 operates, running in neither the harness's process nor any
+ *                 other harness's. Distinct from `'sdk'`: no code from this
+ *                 repo ever runs inside the governed harness's own process
+ *                 at all — the harness's only obligation is to expose the
+ *                 async approval API the bridge polls/subscribes to.
+ */
+export type GateKind = 'hook' | 'sdk' | 'none' | 'delegated' | 'bridge';
+/**
+ * Harnesses whose blocking gate ships SDK-side, in the harness's own
+ * process — no on-disk hook/config file exists to point a gate at. Mirrors
+ * the `file: null` NO_GATE rows in `gateRegistry.ts`.
+ *
+ * MASTRA, VERCEL_AI_SDK (T2), EVE (A2), and TRUEFORGE (embedded-library mode
+ * only — see its own HarnessType doc) are the JS/TS-native members of this
+ * family: their blocking gate ships in `@intutic/gate/mastra`/
+ * `@intutic/gate/vercel`/`@intutic/gate/eve`/`@intutic/gate/trueforge`
+ * (packages/gate-js) rather than `intutic-clawde`, but the shape is
+ * identical — no on-disk hook/config file, tools run as plain callables in
+ * the harness's own process (for eve, as per-tool/per-connection `approval`
+ * policies attached in the agent directory's own TypeScript; for TrueForge,
+ * as `intuticApprovalResponder()` answering `tool.approval_required`
+ * pauses — see `@intutic/gate/trueforge`'s module doc for why that shape
+ * differs from mastra/vercel's single-callback pattern).
+ *
+ * AI_SDK_HARNESS and AI_SDK_WORKFLOW (A3) are the same `@intutic/gate`
+ * family with one nuance worth naming: the VETO still runs SDK-side in the
+ * caller's own Node.js process (an approval responder / a `needsApproval`
+ * function), which is what `'sdk'` classifies — but for AI_SDK_HARNESS the
+ * tool EXECUTION it vetoes happens server-side in a Vercel Sandbox microVM,
+ * and its built-in sandbox tools have no veto surface at all beyond
+ * `permissionMode` (defaults to 'allow-all'). `'sdk'` describes where the
+ * gate mechanism lives, not a claim that every tool the harness can run
+ * passes through it — see gateRegistry.ts's NO_GATE rows for the honest
+ * scope statement per harness.
+ */
+export declare const SDK_GATED_HARNESSES: ReadonlySet<HarnessTypeT>;
+/**
+ * Harnesses with no tool-call gate of their own: the proxy and the MCP
+ * governance proxy are their enforcement. Mirrors the NO_GATE rows in
+ * `gateRegistry.ts`: aider's only native hook (`--git-commit-verify`) is
+ * opt-in, post-edit, and blind to `/run`; Roo Code and Claude Desktop have no
+ * hook system at all (Claude Desktop's Code tab is Claude Code, gated by the
+ * claude-code gate); Continue's CLI loads PreToolUse hooks but never fires
+ * them, and its IDE extension has none (see the continueConfigMerger.ts row).
+ */
+export declare const NO_GATE_HARNESSES: ReadonlySet<HarnessTypeT>;
+/**
+ * Harnesses that wrap OTHER already-gated harnesses instead of running tools
+ * themselves — no gate of their own, but not ungoverned either. Mirrors the
+ * `file: null` NO_GATE rows for `xirp` and `agentic-orchestrator` in
+ * `gateRegistry.ts`. Xirp was the first entry of this shape; Agentic
+ * Orchestrator (O3) is the second. O2 (QM) is expected to add a third, same
+ * "wraps other harnesses" shape, in a concurrent phase not yet merged as of
+ * this one.
+ */
+export declare const DELEGATED_GATE_HARNESSES: ReadonlySet<HarnessTypeT>;
+/**
+ * Harnesses whose blocking gate runs OUT OF PROCESS, in an Intutic-operated
+ * service reacting to the harness's own async approval/event API — not a
+ * file this daemon writes, and not an SDK imported into the harness's own
+ * process (no process of ours runs inside the harness at all). Mirrors the
+ * `file: null` NO_GATE row for `trueforge-server` in `gateRegistry.ts`.
+ *
+ * TRUEFORGE_SERVER (B3) is the first member: a TrueForge standalone/hosted
+ * server has no in-process host to hang an SDK gate off of (contrast
+ * TRUEFORGE, embedded mode, in `SDK_GATED_HARNESSES` above) — instead
+ * `services/trueforge-bridge` watches its turn/event stream externally and
+ * answers pending `tool.approval_required` pauses over HTTP. See the
+ * `'bridge'` `GateKind` doc above for the full distinction from `'sdk'` and
+ * `'delegated'`.
+ */
+export declare const BRIDGE_GATED_HARNESSES: ReadonlySet<HarnessTypeT>;
+/** How this harness's tool calls get gated. Defaults to `'hook'`. */
+export declare function gateKindForHarness(type: HarnessTypeT): GateKind;
+//# sourceMappingURL=gateKind.d.ts.map

package/dist/gateKind.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"gateKind.d.ts","sourceRoot":"","sources":["../src/gateKind.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8CG;AAEH,OAAO,EAAe,KAAK,WAAW,IAAI,YAAY,EAAE,MAAM,YAAY,CAAA;AAE1E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH,MAAM,MAAM,QAAQ,GAAG,MAAM,GAAG,KAAK,GAAG,MAAM,GAAG,WAAW,GAAG,QAAQ,CAAA;AAEvE;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,eAAO,MAAM,mBAAmB,EAAE,WAAW,CAAC,YAAY,CAkBxD,CAAA;AAEF;;;;;;;;GAQG;AACH,eAAO,MAAM,iBAAiB,EAAE,WAAW,CAAC,YAAY,CAKtD,CAAA;AAEF;;;;;;;;GAQG;AACH,eAAO,MAAM,wBAAwB,EAAE,WAAW,CAAC,YAAY,CAO7D,CAAA;AAEF;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,sBAAsB,EAAE,WAAW,CAAC,YAAY,CAA2C,CAAA;AAExG,qEAAqE;AACrE,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,YAAY,GAAG,QAAQ,CAM/D"}

package/dist/gateKind.js

@@ -0,0 +1,160 @@
+"use strict";
+/**
+ * gateKind.ts — classifies each harness by HOW its tool calls get governed:
+ * for the sync daemon's agent report (`agentReporter.ts`'s `guardrails`
+ * facet) and AI inventory, and for the control plane's silent-gate check,
+ * which expects a gate only from a harness that has one of its own.
+ *
+ * # Why this exists
+ *
+ * `collectAgentReport` used to report `hook_gate: true` unconditionally for
+ * every harness, with the comment "the daemon writes the hook gate for every
+ * harness it supports." That was already false for `langgraph` — which has
+ * no on-disk hook, only the SDK-side `intutic_clawde.gate` — and for `aider`,
+ * whose only NO_GATE-registered mechanism is a post-edit, /run-blind
+ * pre-commit hook (see `aiderConfigMerger.ts`'s NO_GATE row in
+ * `__tests__/harness/gateRegistry.ts`). Wave 1 adds eight more SDK-gated
+ * harnesses, which would have made the lie eight times larger without this
+ * fix.
+ *
+ * # What this does NOT do
+ *
+ * This does not verify that a user actually pip-installed `intutic-clawde`
+ * and wired `guard_tools`/`IntuticMiddleware`/etc. into their process — the
+ * daemon cannot observe another process's imports, the same way it cannot
+ * observe whether a written hook file was left executable. It only reports
+ * which MECHANISM this harness's governance model uses (a file the daemon
+ * itself writes and can verify existence of, vs. an SDK the harness's own
+ * process must import), matching the trust level `hook_gate: true` already
+ * carried for file-based harnesses before this fix.
+ *
+ * # Keeping this in sync with the gate registry
+ *
+ * `services/sync-daemon/__tests__/harness/gateRegistry.ts` (the GATES/NO_GATE
+ * completeness registry exercised by `generatedGateBehaviour.test.ts`) is the
+ * authoritative decision per harness, but it is a test-only module (it
+ * dynamically imports every writer's compiled `.js` from a temp build dir)
+ * and must not be imported from daemon runtime code. `services/sync-daemon/__tests__/harness/gateKind.test.ts`
+ * cross-checks the two lists so this file cannot silently drift from that
+ * registry's own NO_GATE rows: `file: null` harnesses split between 'sdk'
+ * (LangGraph + the Python frameworks — the gate ships in intutic-clawde),
+ * 'delegated' (xirp — the gate is whichever wrapped harness's own gate is
+ * running), and 'bridge' (trueforge-server — the gate runs in a separate
+ * Intutic-operated service, not in any process this repo's writers touch),
+ * and 'none' (roo-code, claude-desktop — no hook system); the one non-null
+ * row (aiderConfigMerger.ts, "no ... exists") is 'none' too.
+ *
+ * @module
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.BRIDGE_GATED_HARNESSES = exports.DELEGATED_GATE_HARNESSES = exports.NO_GATE_HARNESSES = exports.SDK_GATED_HARNESSES = void 0;
+exports.gateKindForHarness = gateKindForHarness;
+const enums_js_1 = require("./enums.js");
+/**
+ * Harnesses whose blocking gate ships SDK-side, in the harness's own
+ * process — no on-disk hook/config file exists to point a gate at. Mirrors
+ * the `file: null` NO_GATE rows in `gateRegistry.ts`.
+ *
+ * MASTRA, VERCEL_AI_SDK (T2), EVE (A2), and TRUEFORGE (embedded-library mode
+ * only — see its own HarnessType doc) are the JS/TS-native members of this
+ * family: their blocking gate ships in `@intutic/gate/mastra`/
+ * `@intutic/gate/vercel`/`@intutic/gate/eve`/`@intutic/gate/trueforge`
+ * (packages/gate-js) rather than `intutic-clawde`, but the shape is
+ * identical — no on-disk hook/config file, tools run as plain callables in
+ * the harness's own process (for eve, as per-tool/per-connection `approval`
+ * policies attached in the agent directory's own TypeScript; for TrueForge,
+ * as `intuticApprovalResponder()` answering `tool.approval_required`
+ * pauses — see `@intutic/gate/trueforge`'s module doc for why that shape
+ * differs from mastra/vercel's single-callback pattern).
+ *
+ * AI_SDK_HARNESS and AI_SDK_WORKFLOW (A3) are the same `@intutic/gate`
+ * family with one nuance worth naming: the VETO still runs SDK-side in the
+ * caller's own Node.js process (an approval responder / a `needsApproval`
+ * function), which is what `'sdk'` classifies — but for AI_SDK_HARNESS the
+ * tool EXECUTION it vetoes happens server-side in a Vercel Sandbox microVM,
+ * and its built-in sandbox tools have no veto surface at all beyond
+ * `permissionMode` (defaults to 'allow-all'). `'sdk'` describes where the
+ * gate mechanism lives, not a claim that every tool the harness can run
+ * passes through it — see gateRegistry.ts's NO_GATE rows for the honest
+ * scope statement per harness.
+ */
+exports.SDK_GATED_HARNESSES = new Set([
+    enums_js_1.HarnessType.LANGGRAPH,
+    enums_js_1.HarnessType.LANGCHAIN,
+    enums_js_1.HarnessType.CREWAI,
+    enums_js_1.HarnessType.AUTOGEN,
+    enums_js_1.HarnessType.AG2,
+    enums_js_1.HarnessType.GOOGLE_ADK,
+    enums_js_1.HarnessType.OPENAI_AGENTS,
+    enums_js_1.HarnessType.PYDANTIC_AI,
+    enums_js_1.HarnessType.SMOLAGENTS,
+    enums_js_1.HarnessType.STRANDS,
+    enums_js_1.HarnessType.AGENT_FRAMEWORK,
+    enums_js_1.HarnessType.MASTRA,
+    enums_js_1.HarnessType.VERCEL_AI_SDK,
+    enums_js_1.HarnessType.EVE,
+    enums_js_1.HarnessType.TRUEFORGE,
+    enums_js_1.HarnessType.AI_SDK_HARNESS,
+    enums_js_1.HarnessType.AI_SDK_WORKFLOW,
+]);
+/**
+ * Harnesses with no tool-call gate of their own: the proxy and the MCP
+ * governance proxy are their enforcement. Mirrors the NO_GATE rows in
+ * `gateRegistry.ts`: aider's only native hook (`--git-commit-verify`) is
+ * opt-in, post-edit, and blind to `/run`; Roo Code and Claude Desktop have no
+ * hook system at all (Claude Desktop's Code tab is Claude Code, gated by the
+ * claude-code gate); Continue's CLI loads PreToolUse hooks but never fires
+ * them, and its IDE extension has none (see the continueConfigMerger.ts row).
+ */
+exports.NO_GATE_HARNESSES = new Set([
+    enums_js_1.HarnessType.AIDER,
+    enums_js_1.HarnessType.ROO_CODE,
+    enums_js_1.HarnessType.CLAUDE_DESKTOP,
+    enums_js_1.HarnessType.CONTINUE,
+]);
+/**
+ * Harnesses that wrap OTHER already-gated harnesses instead of running tools
+ * themselves — no gate of their own, but not ungoverned either. Mirrors the
+ * `file: null` NO_GATE rows for `xirp` and `agentic-orchestrator` in
+ * `gateRegistry.ts`. Xirp was the first entry of this shape; Agentic
+ * Orchestrator (O3) is the second. O2 (QM) is expected to add a third, same
+ * "wraps other harnesses" shape, in a concurrent phase not yet merged as of
+ * this one.
+ */
+exports.DELEGATED_GATE_HARNESSES = new Set([
+    enums_js_1.HarnessType.XIRP,
+    enums_js_1.HarnessType.AGENTIC_ORCHESTRATOR,
+    // B2: AWS Bedrock AgentCore Runtime — hosts a customer's own framework
+    // code unchanged; governed by whichever already-supported framework
+    // adapter that code uses. See tools/cli/src/harness/agentcore.ts.
+    enums_js_1.HarnessType.AGENTCORE_RUNTIME,
+]);
+/**
+ * Harnesses whose blocking gate runs OUT OF PROCESS, in an Intutic-operated
+ * service reacting to the harness's own async approval/event API — not a
+ * file this daemon writes, and not an SDK imported into the harness's own
+ * process (no process of ours runs inside the harness at all). Mirrors the
+ * `file: null` NO_GATE row for `trueforge-server` in `gateRegistry.ts`.
+ *
+ * TRUEFORGE_SERVER (B3) is the first member: a TrueForge standalone/hosted
+ * server has no in-process host to hang an SDK gate off of (contrast
+ * TRUEFORGE, embedded mode, in `SDK_GATED_HARNESSES` above) — instead
+ * `services/trueforge-bridge` watches its turn/event stream externally and
+ * answers pending `tool.approval_required` pauses over HTTP. See the
+ * `'bridge'` `GateKind` doc above for the full distinction from `'sdk'` and
+ * `'delegated'`.
+ */
+exports.BRIDGE_GATED_HARNESSES = new Set([enums_js_1.HarnessType.TRUEFORGE_SERVER]);
+/** How this harness's tool calls get gated. Defaults to `'hook'`. */
+function gateKindForHarness(type) {
+    if (exports.SDK_GATED_HARNESSES.has(type))
+        return 'sdk';
+    if (exports.NO_GATE_HARNESSES.has(type))
+        return 'none';
+    if (exports.DELEGATED_GATE_HARNESSES.has(type))
+        return 'delegated';
+    if (exports.BRIDGE_GATED_HARNESSES.has(type))
+        return 'bridge';
+    return 'hook';
+}
+//# sourceMappingURL=gateKind.js.map

package/dist/gateKind.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"gateKind.js","sourceRoot":"","sources":["../src/gateKind.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8CG;;;AAiKH,gDAMC;AArKD,yCAA0E;AA2D1E;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACU,QAAA,mBAAmB,GAA8B,IAAI,GAAG,CAAC;IACpE,sBAAW,CAAC,SAAS;IACrB,sBAAW,CAAC,SAAS;IACrB,sBAAW,CAAC,MAAM;IAClB,sBAAW,CAAC,OAAO;IACnB,sBAAW,CAAC,GAAG;IACf,sBAAW,CAAC,UAAU;IACtB,sBAAW,CAAC,aAAa;IACzB,sBAAW,CAAC,WAAW;IACvB,sBAAW,CAAC,UAAU;IACtB,sBAAW,CAAC,OAAO;IACnB,sBAAW,CAAC,eAAe;IAC3B,sBAAW,CAAC,MAAM;IAClB,sBAAW,CAAC,aAAa;IACzB,sBAAW,CAAC,GAAG;IACf,sBAAW,CAAC,SAAS;IACrB,sBAAW,CAAC,cAAc;IAC1B,sBAAW,CAAC,eAAe;CAC5B,CAAC,CAAA;AAEF;;;;;;;;GAQG;AACU,QAAA,iBAAiB,GAA8B,IAAI,GAAG,CAAC;IAClE,sBAAW,CAAC,KAAK;IACjB,sBAAW,CAAC,QAAQ;IACpB,sBAAW,CAAC,cAAc;IAC1B,sBAAW,CAAC,QAAQ;CACrB,CAAC,CAAA;AAEF;;;;;;;;GAQG;AACU,QAAA,wBAAwB,GAA8B,IAAI,GAAG,CAAC;IACzE,sBAAW,CAAC,IAAI;IAChB,sBAAW,CAAC,oBAAoB;IAChC,uEAAuE;IACvE,oEAAoE;IACpE,kEAAkE;IAClE,sBAAW,CAAC,iBAAiB;CAC9B,CAAC,CAAA;AAEF;;;;;;;;;;;;;;GAcG;AACU,QAAA,sBAAsB,GAA8B,IAAI,GAAG,CAAC,CAAC,sBAAW,CAAC,gBAAgB,CAAC,CAAC,CAAA;AAExG,qEAAqE;AACrE,SAAgB,kBAAkB,CAAC,IAAkB;IACnD,IAAI,2BAAmB,CAAC,GAAG,CAAC,IAAI,CAAC;QAAE,OAAO,KAAK,CAAA;IAC/C,IAAI,yBAAiB,CAAC,GAAG,CAAC,IAAI,CAAC;QAAE,OAAO,MAAM,CAAA;IAC9C,IAAI,gCAAwB,CAAC,GAAG,CAAC,IAAI,CAAC;QAAE,OAAO,WAAW,CAAA;IAC1D,IAAI,8BAAsB,CAAC,GAAG,CAAC,IAAI,CAAC;QAAE,OAAO,QAAQ,CAAA;IACrD,OAAO,MAAM,CAAA;AACf,CAAC"}

package/dist/gateLimits.d.ts

@@ -0,0 +1,170 @@
+/**
+ * How much a gate will evaluate, and for how long, before it refuses.
+ *
+ * Most harnesses treat a hook that runs past its timeout as having allowed
+ * the call (see {@link HOOK_GATE_TIMEOUTS}), so a gate that is slow on a
+ * crafted call is no gate. Two bounds keep every gate inside its harness's
+ * timeout:
+ *
+ * - **Size.** A command over {@link COMMAND_SIZE_LIMIT} bytes, or tool
+ *   arguments over {@link ARGUMENTS_SIZE_LIMIT} bytes (serialized as compact
+ *   JSON), are refused as `COMMAND_TOO_LARGE` before any rule runs. The limits
+ *   come from 85,314 tool calls in real coding-agent transcripts: the largest
+ *   shell command was 38.5 KB (99.9th percentile 13 KB), the largest file
+ *   write 120 KB, the largest arguments of any tool 418 KB (a plan). So the
+ *   command limit is six times the largest seen and the arguments limit more
+ *   than twice.
+ * - **Time.** Each hook gate stops at {@link gateDeadlineMs} for its harness
+ *   after it starts and refuses with a `GATE_DEADLINE` reason. Every built-in
+ *   rule is linear in the text (sequence.ts, the phrase matcher,
+ *   regexLinearity.ts in the sync daemon), so only a workspace's own WHERE
+ *   patterns can get there.
+ *
+ * Sizes are UTF-8 bytes, which every gate can count the same way.
+ *
+ * @module
+ */
+/** The largest shell command, in UTF-8 bytes, a gate evaluates. */
+export declare const COMMAND_SIZE_LIMIT: number;
+/** The largest tool arguments, in UTF-8 bytes of compact JSON, a gate evaluates. */
+export declare const ARGUMENTS_SIZE_LIMIT: number;
+/**
+ * The timeout `intutic connect` sets on a gate's hook entry, in seconds,
+ * wherever the harness has a key for one. Harness defaults run from 30 s to
+ * 600 s; 10 s keeps a stalled gate from holding the agent for minutes, and is
+ * also the longest any gate runs where the harness sets no limit at all.
+ */
+export declare const HOOK_TIMEOUT_SECONDS = 10;
+/**
+ * How far below its harness's hook timeout a gate refuses.
+ *
+ * The harness starts its clock when it spawns the hook; the gate starts its
+ * own once its interpreter is running (Node's `process.uptime()`, the bash
+ * gate's watchdog), and once its deadline fires it still has to stop its
+ * children, write the refusal and the audit line, and exit, and the harness
+ * has to read the exit. On a 14-core machine running every package's test
+ * suite beside 100 busy threads (load average near 190), a gate's refusal
+ * reached the harness at most 260 ms after its deadline, Node and bash alike.
+ * One second is nearly four times that.
+ */
+export declare const GATE_DEADLINE_MARGIN_MS = 1000;
+/** Who decides the timeout a harness applies to its gate. */
+export type HookTimeoutSetBy = 
+/** `intutic connect` writes it into the hook entry. */
+'connect'
+/** The harness's own value, which no setting changes. */
+ | 'harness'
+/** The harness documents none, so the gate assumes the shortest default of any documented harness that runs a call whose hook timed out: Grok Build's 5 s. */
+ | 'undocumented'
+/** The gate runs in the harness's process, which waits for it without a limit. */
+ | 'none';
+/** The timeout a harness applies to its hook gate. */
+export interface HookGateTimeout {
+    /** In milliseconds; null when the harness waits without a limit. */
+    readonly timeoutMs: number | null;
+    readonly setBy: HookTimeoutSetBy;
+    /** Where the value comes from. */
+    readonly source: string;
+}
+/**
+ * The hook timeout each harness applies to its gate, keyed by the harness id
+ * the gate is emitted for. The one source every gate's deadline is derived
+ * from: the writers set the timeouts marked `connect` from here, and a test
+ * reads each written hook entry back against it.
+ */
+export declare const HOOK_GATE_TIMEOUTS: {
+    readonly 'claude-code': {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) on the hook entry in .claude/settings.json; default 600 s, a call whose hook times out runs (code.claude.com/docs/en/hooks)";
+    };
+    readonly cursor: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) on the hooks.json entry, beside `failClosed: true`; default not stated (cursor.com/docs/agent/hooks)";
+    };
+    readonly windsurf: {
+        readonly timeoutMs: 5000;
+        readonly setBy: "undocumented";
+        readonly source: "hooks.json entries have no timeout key and Windsurf documents no timeout; any exit but 2 runs the call (docs.devin.ai/desktop/cascade/hooks)";
+    };
+    readonly codex: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) on the hooks.json entry; default 600 s (Codex hooks documentation)";
+    };
+    readonly 'muse-code': {
+        readonly timeoutMs: 5000;
+        readonly setBy: "undocumented";
+        readonly source: "Muse Code documents no hook timeout and no key for one (dev.meta.ai/docs/muse-code)";
+    };
+    readonly 'github-copilot': {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) on the hook entry, the Copilot CLI's alias for `timeoutSec` and VS Code's key; default 30 s, a call whose hook times out runs (docs.github.com/en/copilot/reference/hooks-configuration)";
+    };
+    readonly cline: {
+        readonly timeoutMs: 30000;
+        readonly setBy: "harness";
+        readonly source: "HOOK_EXECUTION_TIMEOUT_MS = 30000 in Cline's hook-factory.ts, not configurable; a call whose hook times out runs";
+    };
+    readonly grok: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) on the hook entry; default 5 s, no stated maximum, a call whose hook times out runs (docs.x.ai/build/features/hooks)";
+    };
+    readonly antigravity: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) on the PreToolUse handler in ~/.gemini/config/hooks.json; default 30 s (antigravity.google/docs/hooks)";
+    };
+    readonly 'gemini-cli': {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (milliseconds) on the BeforeTool hook in ~/.gemini/settings.json; default 60 000 (geminicli.com/docs/hooks/reference)";
+    };
+    readonly goose: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) beside `on_failure: \"block\"` in the plugin's hooks.json; default 30 s (goose hooks guide)";
+    };
+    readonly openhands: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) in .openhands/hooks.json; default 60 s, a call whose hook times out runs (openhands-sdk hooks/config.py)";
+    };
+    readonly hermes: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeout` (seconds) beside `fail_closed: true` in ~/.hermes/config.yaml; default 60 s, at most 300 s (hermes-agent shell_hooks.py)";
+    };
+    readonly openclaw: {
+        readonly timeoutMs: number;
+        readonly setBy: "connect";
+        readonly source: "`timeoutMs` on the before_tool_call registration; default 15 s, a timeout blocks the call but cannot interrupt the handler (OpenClaw docs/plugins/hooks/reference.md)";
+    };
+    readonly pi: {
+        readonly timeoutMs: null;
+        readonly setBy: "none";
+        readonly source: "Pi awaits an extension's tool_call handler without a limit (core/extensions/runner.ts)";
+    };
+    readonly opencode: {
+        readonly timeoutMs: null;
+        readonly setBy: "none";
+        readonly source: "OpenCode awaits a plugin's tool.execute.before without a limit (packages/opencode/src/plugin/index.ts)";
+    };
+};
+/** A harness that runs a hook gate. */
+export type HookGateHarness = keyof typeof HOOK_GATE_TIMEOUTS;
+/**
+ * How long a harness's hook gate may decide, from its start, before it
+ * refuses with `GATE_DEADLINE`: {@link GATE_DEADLINE_MARGIN_MS} under the
+ * harness's timeout, and never longer than {@link HOOK_TIMEOUT_SECONDS} minus
+ * that margin, so a gate the harness waits on for 30 s or without limit still
+ * answers as promptly as one connect set a timeout for. On the loaded machine
+ * above, a call at the size limits took the bash gates at most 4.6 s and the
+ * JavaScript gates at most 1.2 s; every 4 s deadline is a JavaScript gate's.
+ * Only a workspace's own pathological WHERE pattern runs this long.
+ */
+export declare function gateDeadlineMs(harness: HookGateHarness): number;
+//# sourceMappingURL=gateLimits.d.ts.map

package/dist/gateLimits.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"gateLimits.d.ts","sourceRoot":"","sources":["../src/gateLimits.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,mEAAmE;AACnE,eAAO,MAAM,kBAAkB,QAAa,CAAA;AAE5C,oFAAoF;AACpF,eAAO,MAAM,oBAAoB,QAAc,CAAA;AAE/C;;;;;GAKG;AACH,eAAO,MAAM,oBAAoB,KAAK,CAAA;AAEtC;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,uBAAuB,OAAO,CAAA;AAE3C,6DAA6D;AAC7D,MAAM,MAAM,gBAAgB;AAC1B,uDAAuD;AACrD,SAAS;AACX,yDAAyD;GACvD,SAAS;AACX,8JAA8J;GAC5J,cAAc;AAChB,kFAAkF;GAChF,MAAM,CAAA;AAEV,sDAAsD;AACtD,MAAM,WAAW,eAAe;IAC9B,oEAAoE;IACpE,QAAQ,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;IACjC,QAAQ,CAAC,KAAK,EAAE,gBAAgB,CAAA;IAChC,kCAAkC;IAClC,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAA;CACxB;AAMD;;;;;GAKG;AACH,eAAO,MAAM,kBAAkB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiBqB,CAAA;AAEpD,uCAAuC;AACvC,MAAM,MAAM,eAAe,GAAG,MAAM,OAAO,kBAAkB,CAAA;AAE7D;;;;;;;;;GASG;AACH,wBAAgB,cAAc,CAAC,OAAO,EAAE,eAAe,GAAG,MAAM,CAG/D"}

package/dist/gateLimits.js

@@ -0,0 +1,96 @@
+"use strict";
+/**
+ * How much a gate will evaluate, and for how long, before it refuses.
+ *
+ * Most harnesses treat a hook that runs past its timeout as having allowed
+ * the call (see {@link HOOK_GATE_TIMEOUTS}), so a gate that is slow on a
+ * crafted call is no gate. Two bounds keep every gate inside its harness's
+ * timeout:
+ *
+ * - **Size.** A command over {@link COMMAND_SIZE_LIMIT} bytes, or tool
+ *   arguments over {@link ARGUMENTS_SIZE_LIMIT} bytes (serialized as compact
+ *   JSON), are refused as `COMMAND_TOO_LARGE` before any rule runs. The limits
+ *   come from 85,314 tool calls in real coding-agent transcripts: the largest
+ *   shell command was 38.5 KB (99.9th percentile 13 KB), the largest file
+ *   write 120 KB, the largest arguments of any tool 418 KB (a plan). So the
+ *   command limit is six times the largest seen and the arguments limit more
+ *   than twice.
+ * - **Time.** Each hook gate stops at {@link gateDeadlineMs} for its harness
+ *   after it starts and refuses with a `GATE_DEADLINE` reason. Every built-in
+ *   rule is linear in the text (sequence.ts, the phrase matcher,
+ *   regexLinearity.ts in the sync daemon), so only a workspace's own WHERE
+ *   patterns can get there.
+ *
+ * Sizes are UTF-8 bytes, which every gate can count the same way.
+ *
+ * @module
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.HOOK_GATE_TIMEOUTS = exports.GATE_DEADLINE_MARGIN_MS = exports.HOOK_TIMEOUT_SECONDS = exports.ARGUMENTS_SIZE_LIMIT = exports.COMMAND_SIZE_LIMIT = void 0;
+exports.gateDeadlineMs = gateDeadlineMs;
+/** The largest shell command, in UTF-8 bytes, a gate evaluates. */
+exports.COMMAND_SIZE_LIMIT = 256 * 1024;
+/** The largest tool arguments, in UTF-8 bytes of compact JSON, a gate evaluates. */
+exports.ARGUMENTS_SIZE_LIMIT = 1024 * 1024;
+/**
+ * The timeout `intutic connect` sets on a gate's hook entry, in seconds,
+ * wherever the harness has a key for one. Harness defaults run from 30 s to
+ * 600 s; 10 s keeps a stalled gate from holding the agent for minutes, and is
+ * also the longest any gate runs where the harness sets no limit at all.
+ */
+exports.HOOK_TIMEOUT_SECONDS = 10;
+/**
+ * How far below its harness's hook timeout a gate refuses.
+ *
+ * The harness starts its clock when it spawns the hook; the gate starts its
+ * own once its interpreter is running (Node's `process.uptime()`, the bash
+ * gate's watchdog), and once its deadline fires it still has to stop its
+ * children, write the refusal and the audit line, and exit, and the harness
+ * has to read the exit. On a 14-core machine running every package's test
+ * suite beside 100 busy threads (load average near 190), a gate's refusal
+ * reached the harness at most 260 ms after its deadline, Node and bash alike.
+ * One second is nearly four times that.
+ */
+exports.GATE_DEADLINE_MARGIN_MS = 1000;
+const CONNECT_MS = exports.HOOK_TIMEOUT_SECONDS * 1000;
+/** Grok Build's default hook timeout, the shortest any documented harness uses; assumed where a harness documents none. */
+const UNDOCUMENTED_ASSUMED_MS = 5000;
+/**
+ * The hook timeout each harness applies to its gate, keyed by the harness id
+ * the gate is emitted for. The one source every gate's deadline is derived
+ * from: the writers set the timeouts marked `connect` from here, and a test
+ * reads each written hook entry back against it.
+ */
+exports.HOOK_GATE_TIMEOUTS = {
+    'claude-code': { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) on the hook entry in .claude/settings.json; default 600 s, a call whose hook times out runs (code.claude.com/docs/en/hooks)' },
+    cursor: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) on the hooks.json entry, beside `failClosed: true`; default not stated (cursor.com/docs/agent/hooks)' },
+    windsurf: { timeoutMs: UNDOCUMENTED_ASSUMED_MS, setBy: 'undocumented', source: 'hooks.json entries have no timeout key and Windsurf documents no timeout; any exit but 2 runs the call (docs.devin.ai/desktop/cascade/hooks)' },
+    codex: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) on the hooks.json entry; default 600 s (Codex hooks documentation)' },
+    'muse-code': { timeoutMs: UNDOCUMENTED_ASSUMED_MS, setBy: 'undocumented', source: 'Muse Code documents no hook timeout and no key for one (dev.meta.ai/docs/muse-code)' },
+    'github-copilot': { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) on the hook entry, the Copilot CLI\'s alias for `timeoutSec` and VS Code\'s key; default 30 s, a call whose hook times out runs (docs.github.com/en/copilot/reference/hooks-configuration)' },
+    cline: { timeoutMs: 30_000, setBy: 'harness', source: 'HOOK_EXECUTION_TIMEOUT_MS = 30000 in Cline\'s hook-factory.ts, not configurable; a call whose hook times out runs' },
+    grok: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) on the hook entry; default 5 s, no stated maximum, a call whose hook times out runs (docs.x.ai/build/features/hooks)' },
+    antigravity: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) on the PreToolUse handler in ~/.gemini/config/hooks.json; default 30 s (antigravity.google/docs/hooks)' },
+    'gemini-cli': { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (milliseconds) on the BeforeTool hook in ~/.gemini/settings.json; default 60 000 (geminicli.com/docs/hooks/reference)' },
+    goose: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) beside `on_failure: "block"` in the plugin\'s hooks.json; default 30 s (goose hooks guide)' },
+    openhands: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) in .openhands/hooks.json; default 60 s, a call whose hook times out runs (openhands-sdk hooks/config.py)' },
+    hermes: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeout` (seconds) beside `fail_closed: true` in ~/.hermes/config.yaml; default 60 s, at most 300 s (hermes-agent shell_hooks.py)' },
+    openclaw: { timeoutMs: CONNECT_MS, setBy: 'connect', source: '`timeoutMs` on the before_tool_call registration; default 15 s, a timeout blocks the call but cannot interrupt the handler (OpenClaw docs/plugins/hooks/reference.md)' },
+    pi: { timeoutMs: null, setBy: 'none', source: 'Pi awaits an extension\'s tool_call handler without a limit (core/extensions/runner.ts)' },
+    opencode: { timeoutMs: null, setBy: 'none', source: 'OpenCode awaits a plugin\'s tool.execute.before without a limit (packages/opencode/src/plugin/index.ts)' },
+};
+/**
+ * How long a harness's hook gate may decide, from its start, before it
+ * refuses with `GATE_DEADLINE`: {@link GATE_DEADLINE_MARGIN_MS} under the
+ * harness's timeout, and never longer than {@link HOOK_TIMEOUT_SECONDS} minus
+ * that margin, so a gate the harness waits on for 30 s or without limit still
+ * answers as promptly as one connect set a timeout for. On the loaded machine
+ * above, a call at the size limits took the bash gates at most 4.6 s and the
+ * JavaScript gates at most 1.2 s; every 4 s deadline is a JavaScript gate's.
+ * Only a workspace's own pathological WHERE pattern runs this long.
+ */
+function gateDeadlineMs(harness) {
+    const timeoutMs = exports.HOOK_GATE_TIMEOUTS[harness].timeoutMs;
+    return Math.min(timeoutMs ?? CONNECT_MS, CONNECT_MS) - exports.GATE_DEADLINE_MARGIN_MS;
+}
+//# sourceMappingURL=gateLimits.js.map