@intutic/gate 1.10.1

package/dist/harness.d.ts

@@ -0,0 +1,482 @@
+/**
+ * `@ai-sdk/harness` adapter: `intuticApprovalResponder()`, `intuticSubmitApprovals()`,
+ * `intuticStaticApprovals()`, `recommendedHarnessSettings()`, and
+ * `intuticSandboxBootstrap()`.
+ *
+ * `@intutic/gate/harness` — the same idea `vercel.ts` implements for the base
+ * `ai` package (wrap the framework's own veto point around this package's
+ * `Gate.guard()`), reshaped for Vercel's sandboxed coding-agent runtime,
+ * whose veto surface is materially different from `generateText`'s.
+ *
+ * ## Confirmed against a real install
+ *
+ * `@ai-sdk/harness@1.0.75` (plus `@ai-sdk/harness-claude-code@1.0.78` and
+ * `@ai-sdk/harness-grok-build@1.0.12`) were installed and their shipped
+ * `.d.ts`/compiled source read directly (not inferred from docs alone):
+ *
+ * 1. **The `toolApproval` setting is STATIC.** `HarnessAgentSettings.toolApproval`
+ *    is `HarnessAgentToolApprovalConfiguration = Readonly<Record<string,
+ *    ToolApprovalStatus>>` (`dist/agent/index.d.ts`), whose own doc comment says
+ *    it mirrors "AI SDK `toolApproval` object configuration for host-executed
+ *    tools, **without callback support**". `vercel.ts`'s callback-shaped
+ *    `intuticToolApproval()` therefore does NOT apply here — there is no place
+ *    to hang a function. Per-call gating instead goes through the approval
+ *    FLOW: mark tools `'user-approval'` (see {@link intuticStaticApprovals}),
+ *    let the turn pause, and answer each pending approval with the gate
+ *    (see {@link intuticApprovalResponder}).
+ * 2. **The portable answer path is continuation-based.**
+ *    `HarnessAgentToolApprovalContinuation` carries `{ approvalResponse,
+ *    toolCall }`; `continueTurn`/`continueGenerate`/`continueStream` accept
+ *    `toolApprovalContinuations` (dist/agent/index.d.ts). The adapter-session
+ *    method `session.submitToolApproval?({approvalId, approved, reason})` is
+ *    OPTIONAL (`dist/index.d.ts` — `HarnessV1PromptControl`), and support
+ *    genuinely varies per adapter: `@ai-sdk/harness-claude-code@1.0.78`
+ *    implements it; `@ai-sdk/harness-grok-build@1.0.12` does not (zero
+ *    occurrences in its shipped dist). This module therefore builds the
+ *    responder on the continuation path and treats `submitToolApproval` as an
+ *    optimization when present ({@link intuticSubmitApprovals}).
+ * 3. **Built-in sandbox tools are NOT governed by `toolApproval` at all.**
+ *    They are governed only by `permissionMode: 'allow-reads' | 'allow-edits'
+ *    | 'allow-all'`, which **defaults to `'allow-all'`** — the shipped doc
+ *    comment says so verbatim: "Defaults to `'allow-all'`, preserving the
+ *    existing bypass-permissions behavior unless users opt in." A HarnessAgent
+ *    with default settings runs read/write/edit/bash/glob/grep in the sandbox
+ *    with no approval step this gate could hook.
+ *    {@link recommendedHarnessSettings} exists to steer callers off that
+ *    default.
+ * 4. **Execution is server-side, in a sandbox.** The agent's tools run inside
+ *    a microVM (`@ai-sdk/sandbox-vercel` and friends), NOT on the machine
+ *    where the Intutic proxy runs — the laptop proxy cannot see sandbox
+ *    egress. The only egress control available at this layer is the sandbox's
+ *    own `HarnessV1NetworkPolicy` (`{mode:'allow-all'|'deny-all'} | {mode:
+ *    'custom', allowedHosts/allowedCIDRs/deniedCIDRs}`), applied via the
+ *    sandbox session's optional `setNetworkPolicy?.()`. That is coarse
+ *    host-level filtering, not Intutic DLP — stated plainly in
+ *    `apps/docs/integrations/ai-sdk-harness.md` rather than oversold.
+ *
+ * ## What this module does NOT import
+ *
+ * Deliberately no runtime dependency on `@ai-sdk/harness` — the structural
+ * types below capture only the shapes this adapter touches, matching the
+ * convention `vercel.ts`/`mastra.ts`/`dsh.ts` established. The real package
+ * is a devDependency used by `__tests__/harness.test.ts` to (a) structurally
+ * check these types against the shipped ones and (b) run this responder's
+ * output through the REAL `collectHarnessAgentToolApprovalContinuations`
+ * machinery.
+ *
+ * @module
+ */
+import { type Gate, type ToolInput } from './gate.js';
+/** Structural copy of `ai`'s `ToolApprovalResponse` prompt part (re-exported
+ *  from `@ai-sdk/provider-utils@5.0.27` — confirmed field-for-field). This is
+ *  the part a `role: 'tool'` message carries to answer an approval request. */
+export interface HarnessToolApprovalResponse {
+    type: 'tool-approval-response';
+    approvalId: string;
+    approved: boolean;
+    reason?: string;
+    providerExecuted?: boolean;
+}
+/** Structural copy of the `toolCall` member of `@ai-sdk/harness`'s
+ *  `HarnessAgentToolApprovalContinuation` (dist/agent/index.d.ts). */
+export interface HarnessToolCallPart {
+    readonly type: 'tool-call';
+    readonly toolCallId: string;
+    readonly toolName: string;
+    readonly input: unknown;
+    readonly providerExecuted?: boolean;
+}
+/** Structural copy of `@ai-sdk/harness`'s `HarnessAgentToolApprovalContinuation`
+ *  — the element type of the `toolApprovalContinuations` array
+ *  `continueGenerate`/`continueStream` accept. */
+export interface HarnessToolApprovalContinuation {
+    readonly approvalResponse: HarnessToolApprovalResponse;
+    readonly toolCall: HarnessToolCallPart;
+}
+/**
+ * One pending tool-approval request, in the shape this responder consumes.
+ *
+ * Covers BOTH places a HarnessAgent surfaces one:
+ *
+ *   - the `tool-approval-request` stream/message parts of a running turn
+ *     (paired with their `tool-call` parts — `input` is the parsed value), and
+ *   - `HarnessAgentPendingToolApproval` rows from a suspended session, where
+ *     `input` is a JSON **string** (confirmed: `HarnessV1PendingToolApproval.
+ *     input: string` in `@ai-sdk/harness@1.0.75`'s dist/index.d.ts). String
+ *     inputs are JSON-parsed before the gate evaluates them — see
+ *     {@link renderHarnessToolInput}.
+ */
+export interface HarnessApprovalRequest {
+    readonly approvalId: string;
+    readonly toolCallId: string;
+    readonly toolName: string;
+    /** Parsed input object, or the JSON string a pending-approval row carries. */
+    readonly input: unknown;
+    readonly providerExecuted?: boolean;
+}
+/** Structural copy of `@ai-sdk/harness`'s `HarnessV1PermissionMode`. */
+export type HarnessPermissionMode = 'allow-reads' | 'allow-edits' | 'allow-all';
+/** Structural copy of `@ai-sdk/harness`'s `HarnessV1NetworkPolicy`. The two
+ *  `custom` branches of the real union each require at least one allow field;
+ *  this single structural branch keeps both optional and relies on the test
+ *  suite's assignability check against the real (stricter) type for the
+ *  values this module itself constructs. */
+export type HarnessNetworkPolicy = {
+    mode: 'allow-all';
+} | {
+    mode: 'deny-all';
+} | {
+    mode: 'custom';
+    allowedHosts?: readonly string[];
+    allowedCIDRs?: readonly string[];
+    deniedCIDRs?: readonly string[];
+};
+/** The slice of `@ai-sdk/harness`'s adapter-session control surface this
+ *  module touches — `submitToolApproval` is OPTIONAL in the real
+ *  `HarnessV1PromptControl` too, and per-adapter support varies (see module
+ *  doc point 2). */
+export interface HarnessSessionLike {
+    submitToolApproval?(input: {
+        approvalId: string;
+        approved: boolean;
+        reason?: string;
+    }): PromiseLike<void>;
+}
+export interface IntuticApprovalResponderOptions {
+    /** Overrides the process-wide installed gate (`install(new Gate(...))`). */
+    gate?: Gate;
+}
+/**
+ * Render a pending approval's `input` as the `tool_input` object
+ * {@link Gate.guard} evaluates.
+ *
+ * Mirrors `dsh.ts`'s `renderDshToolInput`, plus one harness-specific case: a
+ * `HarnessAgentPendingToolApproval` carries its input as a JSON **string**,
+ * so strings are parsed first. A string that does not parse (or parses to a
+ * non-object) falls back to `{ args: [...] }` so the gate still has
+ * something to evaluate rather than throwing on a shape it does not
+ * recognise.
+ */
+export declare function renderHarnessToolInput(input: unknown): ToolInput;
+/**
+ * Build an approval responder: a function that evaluates each pending
+ * tool-approval request via `Gate.guard()` and produces the
+ * `toolApprovalContinuations` array for the continue-turn call —
+ * `agent.continueGenerate({ session, toolApprovalContinuations })` /
+ * `continueStream(...)`:
+ *
+ * ```ts
+ * import { HarnessAgent } from '@ai-sdk/harness/agent'
+ * import { Gate, install } from '@intutic/gate'
+ * import {
+ *   intuticApprovalResponder,
+ *   intuticStaticApprovals,
+ *   recommendedHarnessSettings,
+ * } from '@intutic/gate/harness'
+ *
+ * install(new Gate({ workspaceId: process.env.INTUTIC_WORKSPACE_ID }))
+ *
+ * const agent = new HarnessAgent({
+ *   harness,
+ *   sandbox,
+ *   tools,
+ *   ...recommendedHarnessSettings(),           // permissionMode: 'allow-edits'
+ *   toolApproval: intuticStaticApprovals(tools), // every custom tool -> 'user-approval'
+ * })
+ *
+ * const respond = intuticApprovalResponder()
+ * // ...run a turn; when it pauses awaiting approval, collect the pending
+ * // tool-approval requests (stream parts or suspended-session rows), then:
+ * const toolApprovalContinuations = await respond(pendingApprovals)
+ * await agent.continueGenerate({ session, toolApprovalContinuations })
+ * ```
+ *
+ * Decision mapping, per request:
+ *
+ *   - gate allows              -> `approved: true`
+ *   - `IntuticGateRefusal`     -> `approved: false`, `reason` = the
+ *     `[Intutic Governance] BLOCKED: ...` message (the runtime submits an
+ *     `execution-denied` result to the model in place of a tool result)
+ *   - any OTHER throw          -> `approved: false` with a "gate crashed"
+ *     reason — **fail closed**, same posture as `dsh.ts`'s listener: this
+ *     responder's output is a decision list consumed by a paused turn, and a
+ *     deny is deliverable and auditable where an escaped throw could leave
+ *     the turn suspended with no answer at all.
+ *
+ * Requires a `Gate` — either passed via `{ gate }`, or installed process-wide
+ * with `install(new Gate(...))`. A call with neither rejects before
+ * evaluating anything, refusing to answer approvals unguarded.
+ */
+export declare function intuticApprovalResponder(opts?: IntuticApprovalResponderOptions): (requests: readonly HarnessApprovalRequest[]) => Promise<HarnessToolApprovalContinuation[]>;
+export interface IntuticSubmitApprovalsResult {
+    /** The evaluated decisions, always produced — pass these to
+     *  `continueGenerate`/`continueStream` when `submitted` is false. */
+    continuations: HarnessToolApprovalContinuation[];
+    /** True when the session supported `submitToolApproval` and every decision
+     *  was delivered through it; false when the caller must use the
+     *  continuation path instead. */
+    submitted: boolean;
+}
+/**
+ * Evaluate pending approvals and deliver the decisions through
+ * `session.submitToolApproval` when the adapter supports it.
+ *
+ * `submitToolApproval` is an OPTIONAL adapter-session method and per-adapter
+ * support varies (`harness-claude-code` implements it, `harness-grok-build`
+ * does not — see module doc point 2). This helper treats it as an
+ * optimization: when present, every decision is submitted directly (the turn
+ * resumes in place); when absent, nothing is submitted and the caller passes
+ * the returned `continuations` to `continueGenerate`/`continueStream` — the
+ * portable path — instead. Either way the SAME evaluated decisions are
+ * returned, so the caller never re-runs the gate for one delivery mechanism
+ * vs. the other.
+ */
+export declare function intuticSubmitApprovals(session: HarnessSessionLike, requests: readonly HarnessApprovalRequest[], opts?: IntuticApprovalResponderOptions): Promise<IntuticSubmitApprovalsResult>;
+export interface IntuticStaticApprovalsOptions {
+    /** Tool names to mark `'denied'` unconditionally instead of
+     *  `'user-approval'` — for tools that should never run under this agent
+     *  regardless of what the gate would say about a specific call. */
+    deny?: readonly string[];
+}
+/**
+ * Build the static `toolApproval` record for `HarnessAgentSettings`.
+ *
+ * The record shape is `Readonly<Record<string, ToolApprovalStatus>>` — STATIC
+ * per-tool statuses "without callback support" (the shipped doc comment's own
+ * words), so a per-call gate function cannot be expressed here at all. What a
+ * static record CAN express is deny-by-default **routing**: every listed tool
+ * is marked `'user-approval'`, which pauses the turn on every call to it, and
+ * {@link intuticApprovalResponder} then answers each pause with a real
+ * per-call `Gate.guard()` verdict. `'denied'` is deliberately NOT the default
+ * here — it would refuse every call to the tool unconditionally, without the
+ * gate ever seeing the arguments; use `{ deny: [...] }` for tools where that
+ * is actually what you want.
+ *
+ * Two scope limits, stated plainly:
+ *
+ *   - This covers CUSTOM host-executed tools only. Built-in sandbox tools
+ *     (read/write/edit/bash/...) never consult `toolApproval` — they are
+ *     governed solely by `permissionMode`, which defaults to `'allow-all'`.
+ *     See {@link recommendedHarnessSettings}.
+ *   - A tool absent from this record has status `undefined` =
+ *     "not-applicable" and runs WITHOUT any approval pause. Pass the same
+ *     `tools` record you give the agent (or every tool name), not a subset.
+ */
+export declare function intuticStaticApprovals(tools: readonly string[] | Record<string, unknown>, opts?: IntuticStaticApprovalsOptions): Readonly<Record<string, 'user-approval' | 'denied'>>;
+export interface RecommendedHarnessSettingsOptions {
+    /** `'allow-reads'` is stricter (built-ins can read but not write); the
+     *  default recommendation is `'allow-edits'` (read + write inside the
+     *  sandbox, but not the unrestricted `'allow-all'` the framework itself
+     *  defaults to). `'allow-all'` is deliberately not accepted here — asking
+     *  this function for the framework's own bypass default would make the
+     *  helper's name a lie. */
+    permissionMode?: 'allow-reads' | 'allow-edits';
+    /** Hosts sandbox egress should be limited to. When omitted, the
+     *  recommended policy is `{ mode: 'deny-all' }` — deny-by-default until
+     *  the caller decides what the sandbox legitimately needs to reach. */
+    allowedHosts?: readonly string[];
+    /**
+     * Whether to also recommend excluding the sandbox's native `bash` builtin
+     * from the tool set entirely, via `HarnessAgentSettings.inactiveTools`.
+     * Defaults to `true` — see {@link RecommendedHarnessSettings.inactiveTools}
+     * for what this does and does not guarantee (TD-415).
+     */
+    filterBash?: boolean;
+}
+/** The exact policy shapes {@link recommendedHarnessSettings} constructs —
+ *  narrower than {@link HarnessNetworkPolicy} so the value is assignable to
+ *  the REAL `HarnessV1NetworkPolicy` union (whose `custom` branches each
+ *  require an allow field) without a cast; the test suite pins that
+ *  assignability against the shipped type. */
+export type RecommendedNetworkPolicy = {
+    mode: 'deny-all';
+} | {
+    mode: 'custom';
+    allowedHosts: readonly string[];
+    deniedCIDRs: readonly string[];
+};
+export interface RecommendedHarnessSettings {
+    /** Spread into `HarnessAgentSettings`. */
+    permissionMode: 'allow-reads' | 'allow-edits';
+    /**
+     * NOT a `HarnessAgentSettings` field — apply it to the sandbox session via
+     * its optional `setNetworkPolicy?.()` (e.g. from `sandboxConfig.onSession`),
+     * or configure the equivalent on the sandbox provider. Optional-call it:
+     * providers without a local enforcement primitive omit the method, and a
+     * missing implementation means NO egress policy is applied at all — check
+     * for `undefined` and treat that as an uncovered surface, not a silent ok.
+     */
+    networkPolicy: RecommendedNetworkPolicy;
+    /**
+     * Spread into `HarnessAgentSettings.inactiveTools` — `undefined` when
+     * `filterBash: false` was passed. TD-415, resolved with a corrected
+     * understanding: `HarnessV1BuiltinToolFiltering` (the same package's own
+     * type, `dist/index.d.ts`/`dist/agent/index.d.ts`) genuinely CAN drop
+     * `bash` at config time, confirmed against real shipped `dist/index.js`
+     * for both harnesses TD-417 discusses (not just their `.d.ts` — the
+     * behaviour lives in compiled logic no type file states):
+     *
+     *   - `@ai-sdk/harness-claude-code@1.0.78` sets BOTH
+     *     `supportsBuiltinToolApprovals: true` AND
+     *     `supportsBuiltinToolFiltering: true` on its adapter object, and its
+     *     `doStart`/`doContinueTurn` forward `builtinToolFiltering` verbatim
+     *     onto the bridge `start`/`continue` message — true native exclusion,
+     *     enforced by the wrapped Claude Agent SDK inside the sandbox itself,
+     *     not merely a framework-side veto. `bash` never becomes callable.
+     *   - `@ai-sdk/harness-grok-build@1.0.12` sets neither flag directly, but
+     *     is built on `@ai-sdk/harness-acp@1.0.13` (its exact pinned
+     *     dependency, confirmed via `npm pack`), which sets
+     *     `supportsBuiltinToolApprovals: true` (and
+     *     `supportsBuiltinToolFiltering: false`) — so Grok Build gets the
+     *     FRAMEWORK's own fallback instead: `@ai-sdk/harness/agent`'s compiled
+     *     `resolveHarnessAgentToolFiltering` (`dist/agent/index.js`) routes
+     *     every inactive-builtin call through the approval path and
+     *     auto-denies it before execution. Different mechanism, same practical
+     *     outcome — `bash` is still never executed.
+     *   - Confirmed further: if an adapter supported NEITHER flag, the
+     *     framework does not silently ignore `inactiveTools` for a builtin —
+     *     `HarnessAgent`'s constructor throws `HarnessCapabilityUnsupportedError`
+     *     (`dist/agent/index.js`) rather than accepting a setting it cannot
+     *     honour. So this recommendation is never a silent no-op for any
+     *     adapter that accepts it at all.
+     *
+     * What this does NOT close: TD-415's original per-call gap. This is a
+     * coarse, all-or-nothing exclusion decided once at session-construction
+     * time — never a `Gate.guard()`-evaluated verdict per call, and a
+     * workspace that genuinely needs `bash` available cannot use this
+     * filtering and is back to the original `permissionMode` gap for it.
+     */
+    inactiveTools?: readonly ['bash'];
+}
+/**
+ * The settings posture this integration recommends, as a value callers can
+ * spread/apply rather than prose they have to transcribe:
+ *
+ *   - `permissionMode: 'allow-edits'` (or `'allow-reads'`) — because the
+ *     framework's own default is `'allow-all'`, under which built-in sandbox
+ *     tools (including `bash`) run with no approval surface this gate can
+ *     reach. There is no per-call gate for built-ins at ANY permissionMode;
+ *     the mode itself is the entire control, which is why steering it off
+ *     `'allow-all'` matters.
+ *   - a `networkPolicy` for the sandbox — `{ mode: 'deny-all' }` by default,
+ *     or a `custom` allow-list (with the cloud-metadata CIDR denied) when
+ *     `allowedHosts` is given. This is the honest egress-governance story for
+ *     server-side sandbox execution: the Intutic proxy on the developer's
+ *     machine never sees sandbox traffic, and host-level filtering is what
+ *     the sandbox layer actually offers. It is coarse — no DLP, no
+ *     per-request policy — and the integration docs say so.
+ */
+export declare function recommendedHarnessSettings(opts?: RecommendedHarnessSettingsOptions): RecommendedHarnessSettings;
+/** Structural copy of `@ai-sdk/provider-utils`'s `SandboxSession`, narrowed
+ *  to the one method {@link intuticSandboxBootstrap}'s `onBootstrap` calls.
+ *  Confirmed field-for-field against `@ai-sdk/provider-utils@5.0.27`'s
+ *  shipped `dist/index.d.ts` (`WriteFileOptions<string>` plus its own
+ *  `encoding` addition on `writeTextFile`). */
+export interface SandboxWriteSession {
+    writeTextFile(options: {
+        path: string;
+        content: string;
+        encoding?: string;
+    }): PromiseLike<void>;
+}
+/** Structural copy of `@ai-sdk/harness/agent`'s
+ *  `HarnessAgentSandboxConfig['onBootstrap']` parameter shape
+ *  (`dist/agent/index.d.ts`), narrowed to the fields this module reads. */
+export interface SandboxBootstrapCallbackOptions {
+    readonly session: SandboxWriteSession;
+    readonly workDir: string;
+    readonly abortSignal?: AbortSignal;
+}
+export interface IntuticSandboxBootstrap {
+    /** Pass through unchanged to `HarnessAgentSettings.sandboxConfig.bootstrapHash`
+     *  — required alongside `onBootstrap` by the real type. Deterministic: the
+     *  same options always produce the same hash, and a snapshot-capable
+     *  sandbox provider uses it to decide whether `onBootstrap` needs to run
+     *  again. Computed the same way `snapshot.ts` computes the policy-snapshot
+     *  digest — `createHash('sha256')` over the recipe content, this module's
+     *  own existing hashing convention, not a new one. */
+    readonly bootstrapHash: string;
+    /** Pass through unchanged to `HarnessAgentSettings.sandboxConfig.onBootstrap`. */
+    readonly onBootstrap: (opts: SandboxBootstrapCallbackOptions) => Promise<void>;
+}
+export interface IntuticSandboxBootstrapOptions {
+    /**
+     * Compiled `.rules` text — the SAME artifact format `snapshot.ts` reads
+     * (`~/.intutic/hooks/policy-snapshot.rules` on a laptop). Copy the file
+     * content in, e.g. by reading it from the host running the orchestrator
+     * code before constructing this bootstrap. Omit to ship a hook script that
+     * loads zero rules (still present as a channel, evaluating nothing) —
+     * never silently skipped, so a missing snapshot shows up as an empty file
+     * inside the sandbox rather than a missing one.
+     */
+    policySnapshotRules?: string;
+    /** Embedded in the recipe hash only (so a workspace switch invalidates a
+     *  cached snapshot) — this module does not otherwise use it, matching
+     *  `snapshot.ts`'s reader, which also treats workspace id as an integrity
+     *  check rather than a lookup key. */
+    workspaceId?: string;
+    /** Directory inside the sandbox (relative to `workDir`) the hook script
+     *  and its rules file are written under. Defaults to `.intutic/hooks`,
+     *  the same relative location the laptop writer uses. */
+    bootstrapDir?: string;
+}
+declare function sandboxJoin(workDir: string, relative: string): string;
+/**
+ * Self-contained (zero-`require`) hand-port of `snapshot.ts`'s
+ * `normalise`/`evaluate` — Tier A1 only. See the module-level comment above
+ * for what this deliberately does and does not cover, and
+ * `__tests__/harness.test.ts` for the behavioural-parity check against the
+ * real `snapshot.evaluate()` this port is pinned to.
+ *
+ * Contract matches the laptop's `claude-code-check.js`
+ * (`services/sync-daemon/src/harness/claudeCodeHooks.ts`) deliberately:
+ * Claude Code's PreToolUse hook stdin carries `{tool_name, tool_input,
+ * session_id}` (this reads both the snake_case and camelCase field names,
+ * same as the laptop script); exit `2` blocks the call, exit `0` allows it;
+ * any parse/read error fails CLOSED (exit `2`), the same posture
+ * `emitJsFailClosedPrelude` documents for the laptop's version.
+ */
+declare function renderSandboxGateScript(rulesFileName: string): string;
+/**
+ * Compiles the `.claude/settings.json` content that registers the generated
+ * hook script — same matcher set and hook shape as the laptop writer's
+ * `hookEntry()` (`services/sync-daemon/src/harness/claudeCodeHooks.ts`):
+ * `Bash`, `Edit`, `Write`, `MultiEdit`, and `mcp__.*`.
+ */
+declare function renderSandboxClaudeSettings(hookScriptSandboxPath: string): string;
+/**
+ * Builds `{ bootstrapHash, onBootstrap }` for
+ * `HarnessAgentSettings.sandboxConfig` — the channel TD-417 identified as
+ * existing but unused:
+ *
+ * ```ts
+ * import { HarnessAgent } from '@ai-sdk/harness/agent'
+ * import { intuticSandboxBootstrap, recommendedHarnessSettings } from '@intutic/gate/harness'
+ *
+ * const agent = new HarnessAgent({
+ *   harness,
+ *   sandbox,
+ *   ...recommendedHarnessSettings(),
+ *   sandboxConfig: intuticSandboxBootstrap({
+ *     policySnapshotRules: fs.readFileSync(snapshotPath(), 'utf-8'),
+ *     workspaceId: process.env.INTUTIC_WORKSPACE_ID,
+ *   }),
+ * })
+ * ```
+ *
+ * Writes two files under `<workDir>/<bootstrapDir>` (default
+ * `.intutic/hooks`) — the rules text verbatim, and a self-contained hook
+ * script implementing Tier A1 against it (see
+ * {@link renderSandboxGateScript}) — plus `.claude/settings.json` at
+ * `<workDir>/.claude/settings.json` registering that script as a
+ * `PreToolUse` hook. See the module-level comment above this section for
+ * what this does and does not cover, and why.
+ */
+export declare function intuticSandboxBootstrap(opts?: IntuticSandboxBootstrapOptions): IntuticSandboxBootstrap;
+export declare const _internal: {
+    renderSandboxGateScript: typeof renderSandboxGateScript;
+    renderSandboxClaudeSettings: typeof renderSandboxClaudeSettings;
+    sandboxJoin: typeof sandboxJoin;
+};
+export {};
+//# sourceMappingURL=harness.d.ts.map

package/dist/harness.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"harness.d.ts","sourceRoot":"","sources":["../src/harness.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmEG;AAGH,OAAO,EAAwB,KAAK,IAAI,EAAE,KAAK,SAAS,EAAE,MAAM,WAAW,CAAA;AAG3E;;+EAE+E;AAC/E,MAAM,WAAW,2BAA2B;IAC1C,IAAI,EAAE,wBAAwB,CAAA;IAC9B,UAAU,EAAE,MAAM,CAAA;IAClB,QAAQ,EAAE,OAAO,CAAA;IACjB,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,gBAAgB,CAAC,EAAE,OAAO,CAAA;CAC3B;AAED;sEACsE;AACtE,MAAM,WAAW,mBAAmB;IAClC,QAAQ,CAAC,IAAI,EAAE,WAAW,CAAA;IAC1B,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAA;IAC3B,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAA;IACzB,QAAQ,CAAC,KAAK,EAAE,OAAO,CAAA;IACvB,QAAQ,CAAC,gBAAgB,CAAC,EAAE,OAAO,CAAA;CACpC;AAED;;kDAEkD;AAClD,MAAM,WAAW,+BAA+B;IAC9C,QAAQ,CAAC,gBAAgB,EAAE,2BAA2B,CAAA;IACtD,QAAQ,CAAC,QAAQ,EAAE,mBAAmB,CAAA;CACvC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,WAAW,sBAAsB;IACrC,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAA;IAC3B,QAAQ,CAAC,UAAU,EAAE,MAAM,CAAA;IAC3B,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAA;IACzB,8EAA8E;IAC9E,QAAQ,CAAC,KAAK,EAAE,OAAO,CAAA;IACvB,QAAQ,CAAC,gBAAgB,CAAC,EAAE,OAAO,CAAA;CACpC;AAED,wEAAwE;AACxE,MAAM,MAAM,qBAAqB,GAAG,aAAa,GAAG,aAAa,GAAG,WAAW,CAAA;AAE/E;;;;4CAI4C;AAC5C,MAAM,MAAM,oBAAoB,GAC5B;IAAE,IAAI,EAAE,WAAW,CAAA;CAAE,GACrB;IAAE,IAAI,EAAE,UAAU,CAAA;CAAE,GACpB;IACE,IAAI,EAAE,QAAQ,CAAA;IACd,YAAY,CAAC,EAAE,SAAS,MAAM,EAAE,CAAA;IAChC,YAAY,CAAC,EAAE,SAAS,MAAM,EAAE,CAAA;IAChC,WAAW,CAAC,EAAE,SAAS,MAAM,EAAE,CAAA;CAChC,CAAA;AAEL;;;oBAGoB;AACpB,MAAM,WAAW,kBAAkB;IACjC,kBAAkB,CAAC,CAAC,KAAK,EAAE;QAAE,UAAU,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,OAAO,CAAC;QAAC,MAAM,CAAC,EAAE,MAAM,CAAA;KAAE,GAAG,WAAW,CAAC,IAAI,CAAC,CAAA;CAC1G;AAED,MAAM,WAAW,+BAA+B;IAC9C,4EAA4E;IAC5E,IAAI,CAAC,EAAE,IAAI,CAAA;CACZ;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,sBAAsB,CAAC,KAAK,EAAE,OAAO,GAAG,SAAS,CAahE;AAcD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,wBAAgB,wBAAwB,CACtC,IAAI,GAAE,+BAAoC,GACzC,CAAC,QAAQ,EAAE,SAAS,sBAAsB,EAAE,KAAK,OAAO,CAAC,+BAA+B,EAAE,CAAC,CA8C7F;AAED,MAAM,WAAW,4BAA4B;IAC3C;yEACqE;IACrE,aAAa,EAAE,+BAA+B,EAAE,CAAA;IAChD;;qCAEiC;IACjC,SAAS,EAAE,OAAO,CAAA;CACnB;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAsB,sBAAsB,CAC1C,OAAO,EAAE,kBAAkB,EAC3B,QAAQ,EAAE,SAAS,sBAAsB,EAAE,EAC3C,IAAI,GAAE,+BAAoC,GACzC,OAAO,CAAC,4BAA4B,CAAC,CAcvC;AAED,MAAM,WAAW,6BAA6B;IAC5C;;uEAEmE;IACnE,IAAI,CAAC,EAAE,SAAS,MAAM,EAAE,CAAA;CACzB;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,sBAAsB,CACpC,KAAK,EAAE,SAAS,MAAM,EAAE,GAAG,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAClD,IAAI,GAAE,6BAAkC,GACvC,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,eAAe,GAAG,QAAQ,CAAC,CAAC,CAQtD;AAED,MAAM,WAAW,iCAAiC;IAChD;;;;;+BAK2B;IAC3B,cAAc,CAAC,EAAE,aAAa,GAAG,aAAa,CAAA;IAC9C;;2EAEuE;IACvE,YAAY,CAAC,EAAE,SAAS,MAAM,EAAE,CAAA;IAChC;;;;;OAKG;IACH,UAAU,CAAC,EAAE,OAAO,CAAA;CACrB;AAED;;;;8CAI8C;AAC9C,MAAM,MAAM,wBAAwB,GAChC;IAAE,IAAI,EAAE,UAAU,CAAA;CAAE,GACpB;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,YAAY,EAAE,SAAS,MAAM,EAAE,CAAC;IAAC,WAAW,EAAE,SAAS,MAAM,EAAE,CAAA;CAAE,CAAA;AAEvF,MAAM,WAAW,0BAA0B;IACzC,0CAA0C;IAC1C,cAAc,EAAE,aAAa,GAAG,aAAa,CAAA;IAC7C;;;;;;;OAOG;IACH,aAAa,EAAE,wBAAwB,CAAA;IACvC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAsCG;IACH,aAAa,CAAC,EAAE,SAAS,CAAC,MAAM,CAAC,CAAA;CAClC;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,0BAA0B,CACxC,IAAI,GAAE,iCAAsC,GAC3C,0BAA0B,CAgB5B;AAkHD;;;;+CAI+C;AAC/C,MAAM,WAAW,mBAAmB;IAClC,aAAa,CAAC,OAAO,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,CAAA;KAAE,GAAG,WAAW,CAAC,IAAI,CAAC,CAAA;CAChG;AAED;;2EAE2E;AAC3E,MAAM,WAAW,+BAA+B;IAC9C,QAAQ,CAAC,OAAO,EAAE,mBAAmB,CAAA;IACrC,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAA;IACxB,QAAQ,CAAC,WAAW,CAAC,EAAE,WAAW,CAAA;CACnC;AAED,MAAM,WAAW,uBAAuB;IACtC;;;;;;0DAMsD;IACtD,QAAQ,CAAC,aAAa,EAAE,MAAM,CAAA;IAC9B,kFAAkF;IAClF,QAAQ,CAAC,WAAW,EAAE,CAAC,IAAI,EAAE,+BAA+B,KAAK,OAAO,CAAC,IAAI,CAAC,CAAA;CAC/E;AAED,MAAM,WAAW,8BAA8B;IAC7C;;;;;;;;OAQG;IACH,mBAAmB,CAAC,EAAE,MAAM,CAAA;IAC5B;;;0CAGsC;IACtC,WAAW,CAAC,EAAE,MAAM,CAAA;IACpB;;6DAEyD;IACzD,YAAY,CAAC,EAAE,MAAM,CAAA;CACtB;AAED,iBAAS,WAAW,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,MAAM,CAG9D;AAED;;;;;;;;;;;;;;GAcG;AACH,iBAAS,uBAAuB,CAAC,aAAa,EAAE,MAAM,GAAG,MAAM,CA+F9D;AAED;;;;;GAKG;AACH,iBAAS,2BAA2B,CAAC,qBAAqB,EAAE,MAAM,GAAG,MAAM,CAmB1E;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,wBAAgB,uBAAuB,CAAC,IAAI,GAAE,8BAAmC,GAAG,uBAAuB,CAiC1G;AAGD,eAAO,MAAM,SAAS;;;;CAAwE,CAAA"}