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,19 @@
+import fetchApi from "@moduletrace/twui/utils/fetch/fetchApi";
+import type { APIResponseObject } from "@moduletrace/bunext/types";
+import type { HookProposalDecision } from "@/src/types";
+
+type Params = {
+    proposal_id: number;
+    decision: "confirm" | "reject";
+};
+
+/**
+ * Confirms or rejects a hook proposal from its card, returning it as it
+ * now stands and, for a new hook called at a URL, its token (shown once).
+ */
+export default async function decideHookProposal({ proposal_id, decision }: Params) {
+    return await fetchApi<{ proposal_id: number }, APIResponseObject<HookProposalDecision>>(
+        `/api/admin/hook-proposals/${decision}-proposal`,
+        { method: "POST", body: { proposal_id } },
+    );
+}