Let bots manage their hooks, with the user confirming what widens them

Bots get list_hooks, pause_hook and delete_hook, which act directly since they only take away. A new hook, or a new name, brief or filter, or switching a paused one back on, goes through propose_hook: it stores a hook_proposals row and puts a [hook-proposal:ID] card in the reply, which the user it was proposed to confirms or rejects. The card is read from what Confirm saves, with the bot's reason labelled as its own; confirming checks everything again and saves through the Hooks modal's helpers. A new hook's URL is shown on the card once, to the user only, never in the outcome the bot is told. What calls a hook, its computers and its signing are never proposed. Only chat replies propose, and a hook call's own run gets no hook tools, so a caller's payload can't reach them. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-25 15:18:54 +01:00
parent 045167715d
commit 380d3ebb2f
54 changed files with 1983 additions and 55 deletions
@@ -0,0 +1,52 @@
+import type { BUN_SQLITE_COBBLE_COMPUTERS } from "@/db/types/db";
+import type { HarnessTool } from "../../../types";
+import deleteHookTool from "./delete-hook-tool";
+import listHooksTool from "./list-hooks-tool";
+import pauseHookTool from "./pause-hook-tool";
+import proposeHookTool from "./propose-hook-tool";
+
+type Params = {
+    user_id: number | string;
+    bot_id: number | string;
+    session_id?: number | string;
+    workspace_id?: number | string | null;
+    computers: BUN_SQLITE_COBBLE_COMPUTERS[];
+    /**
+     * The run is a hook call: what started it came from outside, so it
+     * gets no hook tools at all.
+     */
+    hooked?: boolean;
+    /**
+     * Called with each proposal's ref, so the reply carries its card. Only
+     * a chat reply proposes: someone is there to confirm.
+     */
+    onPropose?: (params: { ref: string }) => void;
+};
+
+/**
+ * A bot's tools for the user's hooks it runs: read them, pause or delete
+ * one (that only takes away), and in a chat reply propose a new one or a
+ * change (the user confirms it from a card; a new one's URL goes to them
+ * alone). A hook call's own run gets none, so a caller's payload can never
+ * reach them.
+ */
+export default function grabBotHookTools({
+    user_id,
+    bot_id,
+    session_id,
+    workspace_id,
+    computers,
+    hooked,
+    onPropose,
+}: Params): HarnessTool[] {
+    if (hooked) return [];
+
+    return [
+        listHooksTool({ user_id, bot_id }),
+        pauseHookTool({ user_id, bot_id }),
+        deleteHookTool({ user_id, bot_id }),
+        ...(session_id && onPropose
+            ? [proposeHookTool({ user_id, bot_id, session_id, workspace_id, computers, onPropose })]
+            : []),
+    ];
+}