@anuma/sdk 6.33.1 → 6.34.0

package/dist/tools/selection/index.cjs

@@ -1025,8 +1025,6 @@ async function embedOne(text, options, outer) {
       (signal) => postApiV1Embeddings({
         baseUrl,
         body: {
-          // Mask PII from the request body only — the cache above still keys on
-          // the original `text`, so callers keep their original values.
           input: options.maskInput ? options.maskInput(text) : text,
           model: model ?? DEFAULT_API_EMBEDDING_MODEL
         },
@@ -1060,19 +1058,20 @@ async function embedOne(text, options, outer) {
 }
 var DEFAULT_EMBEDDING_BATCH_SIZE = 100;
 var DEFAULT_EMBEDDING_BATCH_CONCURRENCY = 3;
-async function generateEmbeddingsBatch(texts, headers, baseUrl, model, onUsage, maskInput, timeoutMs) {
+async function generateEmbeddingsBatch(texts, headers, baseUrl, model, onUsage, maskInput, timeoutMs, outer) {
   const response = await withEmbeddingRetry(
     () => withDeadline(
       (signal) => postApiV1Embeddings({
         baseUrl,
-        // Mask PII from the request body only; cache/order still key on originals.
         body: { input: maskInput ? texts.map(maskInput) : texts, model },
         headers,
         ...signal && { signal }
       }),
       timeoutMs,
-      "embedding batch request"
-    )
+      "embedding batch request",
+      outer
+    ),
+    outer
   );
   if (response.error) {
     throw embeddingErrorFrom(response);
@@ -1090,6 +1089,11 @@ async function generateEmbeddingsBatch(texts, headers, baseUrl, model, onUsage,
 }
 async function generateEmbeddings(texts, options) {
   if (texts.length === 0) return [];
+  const total = options.totalTimeoutMs;
+  if (total === void 0) return embedMany(texts, options, void 0);
+  return withDeadline((signal) => embedMany(texts, options, signal), total, "embedding batch");
+}
+async function embedMany(texts, options, outer) {
   const { baseUrl = BASE_URL, model, batchSize, cache } = options;
   const timeoutMs = options.timeoutMs ?? DEFAULT_EMBEDDING_REQUEST_TIMEOUT_MS;
   const chunkSize = batchSize ?? DEFAULT_EMBEDDING_BATCH_SIZE;
@@ -1110,7 +1114,8 @@ async function generateEmbeddings(texts, options) {
   if (uncachedTexts.length === 0) {
     return results;
   }
-  const headers = await resolveAuthHeaders(options);
+  const headers = await resolveAuthHeaders(options, outer);
+  if (outer?.aborted) throw outer.reason;
   const embeddingModel = model ?? DEFAULT_API_EMBEDDING_MODEL;
   let newEmbeddings;
   if (uncachedTexts.length <= chunkSize) {
@@ -1121,7 +1126,8 @@ async function generateEmbeddings(texts, options) {
       embeddingModel,
       options.onUsage,
       options.maskInput,
-      timeoutMs
+      timeoutMs,
+      outer
     );
   } else {
     const chunks = [];
@@ -1132,6 +1138,7 @@ async function generateEmbeddings(texts, options) {
     let nextIndex = 0;
     const worker = async () => {
       while (nextIndex < chunks.length) {
+        if (outer?.aborted) throw outer.reason;
         const idx = nextIndex++;
         allEmbeddings[idx] = await generateEmbeddingsBatch(
           chunks[idx],
@@ -1140,7 +1147,8 @@ async function generateEmbeddings(texts, options) {
           embeddingModel,
           options.onUsage,
           options.maskInput,
-          timeoutMs
+          timeoutMs,
+          outer
         );
       }
     };
@@ -1151,6 +1159,7 @@ async function generateEmbeddings(texts, options) {
     await Promise.all(workers);
     newEmbeddings = allEmbeddings.flat();
   }
+  if (outer?.aborted) throw outer.reason;
   for (let i = 0; i < uncachedIndices.length; i++) {
     const f32Embedding = Float32Array.from(newEmbeddings[i]);
     results[uncachedIndices[i]] = Array.from(f32Embedding);
@@ -1668,9 +1677,7 @@ function clientToolToResponsesFormat(tool) {
     type: "function",
     name: func.name,
     description: func.description,
-    // Handle both 'parameters' and 'arguments' field names
     parameters: func.parameters ?? func.arguments,
-    // Preserve executor functions for client-side execution
     ...toolConfig.executor && { executor: toolConfig.executor },
     ...toolConfig.skipContinuation !== void 0 && {
       skipContinuation: toolConfig.skipContinuation
@@ -1706,7 +1713,6 @@ function clientToolToCompletionsFormat(tool) {
       ...restFunc,
       parameters: args ?? { type: "object", properties: {} }
     },
-    // Preserve executor functions for client-side execution
     ...toolConfig.executor && { executor: toolConfig.executor },
     ...toolConfig.skipContinuation !== void 0 && {
       skipContinuation: toolConfig.skipContinuation
@@ -1869,17 +1875,7 @@ function scoreTools(promptEmbeddings, tools) {
 var BUILT_IN_TOOL_SETS = [
   {
     name: "app-generation",
-    // Appended to the base prompt (not replacing it) whenever this set
-    // activates, so the App Builder guidance — including the window.app.complete
-    // runtime-AI contract — rides in with the app-gen tools via the same
-    // semantic selection that includes them. Collected by toolSetSystemPrompts.
     systemPrompt: APP_BUILDER_PROMPT,
-    // Must stay in sync with APP_FILE_TOOL_NAMES in src/tools/appGeneration.ts.
-    // If a new app-gen tool ships there but isn't added here, semantic
-    // selection will exclude it on every request — the model literally
-    // doesn't see it. The quality tools (audit_design / critique_design /
-    // verify_app) are non-obvious to a user prompt ("build me a kanban")
-    // and rely entirely on set expansion to reach the model.
     members: [
       "create_file",
       "patch_file",
@@ -1890,52 +1886,20 @@ var BUILT_IN_TOOL_SETS = [
       "critique_design",
       "verify_app"
     ],
-    // Anchors stay limited to the primary entry-point tools. Users phrase
-    // app intent as "build / make / fix" → semantic match on create_file
-    // or patch_file → full set pulled in. The quality tools fire later in
-    // the workflow and don't anchor on their own; including them as
-    // anchors would risk pulling the set in on unrelated "audit my code"
-    // prompts that have nothing to do with app generation.
     anchors: ["create_file", "patch_file"],
-    // 0.55: above the global filter floor (0.53) so a barely-relevant match
-    // can't pull in the whole toolkit, but no higher — and we tried higher.
-    // create_file scores chitchat ("what's up" ~0.56, "...about programming"
-    // ~0.57) in the SAME band as legitimate app-EDIT prompts: "Edit the app to
-    // change the background…" measured create_file 0.56 on one e2e run. Raising
-    // the floor to 0.575 to exclude the chitchat therefore also stripped the
-    // file tools from real edit requests — leaving the model unable to touch the
-    // app at all. The bands genuinely overlap; there is no clean cut. So we keep
-    // 0.55 (max recall) and rely on two safety nets instead: APP_BUILDER_PROMPT
-    // is conditional (it no-ops unless the user is actually asking for an app),
-    // and very short greetings ("hey") are filtered out earlier by the
-    // MIN_CONTENT_LENGTH_FOR_TOOLS length gate before embeddings even run.
     anchorMinSimilarity: 0.55
   },
   {
     name: "slides",
     members: ["plan_deck", "add_slide", "read_slides", "patch_slides"],
     anchors: ["plan_deck", "patch_slides"],
-    // Match the client-tool floor (0.53). Short colloquial prompts like
-    // "make me a powerpoint about X" score plan_deck around 0.535 — above
-    // the global floor but inside any anchor gap. plan_deck and patch_slides
-    // are specific enough names that 0.53 won't false-positive in practice.
     anchorMinSimilarity: 0.53
   },
   {
     name: "documents",
-    // Conditional rider (no-ops unless the user actually asks for a document),
-    // attached so the Document Builder guidance rides in with the document
-    // tools via the same semantic selection that includes them.
     systemPrompt: DOCUMENT_BUILDER_PROMPT,
     members: ["create_document", "read_document", "patch_document"],
-    // Entry-point tools anchor; read_document rides in via set expansion.
     anchors: ["create_document", "patch_document"],
-    // 0.53: match the client-tool floor. "draft me a contract", "write a cover
-    // letter", "make a memo" should pull the set in. Like app-gen's create_file,
-    // document intent ("write me X") overlaps generic chitchat in this band, so
-    // the same two safety nets apply: DOCUMENT_BUILDER_PROMPT is conditional and
-    // the MIN_CONTENT_LENGTH_FOR_TOOLS gate drops bare greetings before
-    // embeddings run. Tune empirically against the tool-selection parity suite.
     anchorMinSimilarity: 0.53
   },
   {
@@ -1944,11 +1908,6 @@ var BUILT_IN_TOOL_SETS = [
     anchors: ["github_api"],
     anchorMinSimilarity: 0.55
   },
-  // Connector sets (#587). Connector chat tools belong to no set, so per-message
-  // semantic filtering silently prunes them on vague prompts ("check my email").
-  // Grouping each connector's tools behind a search/action anchor keeps the
-  // whole connector reachable once any one of its tools matches. Mirrors github:
-  // no systemPrompt rider — per-set prompt guidance is a follow-up.
   {
     name: "gmail",
     members: [
@@ -2005,9 +1964,6 @@ var BUILT_IN_TOOL_SETS = [
       "slack_get_thread_replies",
       "slack_post_message"
     ],
-    // search is the primary entry point; list_channels also anchors so "what
-    // channels am I in" reaches the set without going through search. post_message
-    // anchors too so post-only prompts surface the write tool past the cutoff.
     anchors: ["slack_search_messages", "slack_list_channels", "slack_post_message"],
     anchorMinSimilarity: 0.53
   },
@@ -2018,15 +1974,6 @@ var BUILT_IN_TOOL_SETS = [
     anchorMinSimilarity: 0.53
   },
   {
-    // Server tools, so this set does its work through
-    // withActiveToolSetServerTools: once any restaurant tool has run, terse
-    // follow-ups ("okay", "same as before", "cancel it") keep every restaurant
-    // tool — discovery, booking and cancelling. Each tool still reaches a fresh
-    // request on its own description.
-    // Anchors are deliberately empty (like the client's Nearby set): the set
-    // is only for stickiness, not a new way to activate on a prompt.
-    // prompt_user_confirm is left out of members: autoFilterClientTools always
-    // sends it, and as a member any unrelated confirmation would pin this set.
     name: "restaurant-booking",
     members: [
       "AnumaPaymentsMCP-anuma_find_restaurant",
@@ -2039,10 +1986,6 @@ var BUILT_IN_TOOL_SETS = [
     anchors: []
   },
   {
-    // What a confirmed booking card narrows the rest of the turn to (see
-    // CONFIRMED_ACTION_TOOL_SETS): the booking chain only, without the
-    // discovery and cancel tools that restaurant-booking keeps sticky.
-    // Anchors are empty for the same reason as restaurant-cancel below.
     name: "restaurant-book",
     members: [
       "AnumaPaymentsMCP-anuma_find_restaurant",
@@ -2052,12 +1995,6 @@ var BUILT_IN_TOOL_SETS = [
     anchors: []
   },
   {
-    // What a confirmed cancel card narrows the rest of the turn to (see
-    // CONFIRMED_ACTION_TOOL_SETS). Anchors are empty for the same reason as
-    // restaurant-booking: anchors here are scored against client tools only,
-    // so a server-tool anchor could never fire. The "cancel brings list"
-    // edge on a fresh prompt is restaurant-cancel-lookup in
-    // SERVER_TOOL_DEPENDENCY_SETS.
     name: "restaurant-cancel",
     members: [
       "AnumaPaymentsMCP-anuma_list_reservations",
@@ -2181,11 +2118,6 @@ function createServerToolsFilter(options = {}) {
 var DEFAULT_EXCLUDED_SERVER_TOOLS = [
   "AnumaVisionMCP-anuma_analyze_image",
   "OpenMeteoMCP-weather_forecast",
-  // Same native-capability argument as the vision tool: modern models reason
-  // step-by-step natively (and reasoning-mode models do it structurally), so
-  // a server-side sequential-thinking tool is a redundant hop. Its broad
-  // description also embeds near virtually every prompt — observed live
-  // riding into news-search, scheduling, and chitchat requests.
   "AnumaSequentialThinkingMCP-sequentialthinking"
 ];
 var DEFAULT_SERVER_TOOLS_MATCH_OPTIONS = {
@@ -2194,10 +2126,6 @@ var DEFAULT_SERVER_TOOLS_MATCH_OPTIONS = {
 };
 var SERVER_TOOL_DEPENDENCY_SETS = [
   {
-    // search finds links; reading them is always the next step. The reader now
-    // lives on the search server — Jina's read_url / parallel_read_url were
-    // removed in favour of anuma_scrape_url, which takes a batch of URLs — so
-    // this edge deliberately spans two MCP servers.
     name: "web-research",
     members: [
       "AnumaJinaMCP-search_web",
@@ -2205,22 +2133,9 @@ var SERVER_TOOL_DEPENDENCY_SETS = [
       "AnumaJinaMCP-parallel_search_web"
     ],
     anchors: ["AnumaJinaMCP-search_web"],
-    // Activation floor = the selection floor (0.5), not the 0.6 ToolSet
-    // default. A dependency edge has different semantics from a persona-style
-    // tool set: if the entry tool is plausibly offered at all, the chain must
-    // ride along — "Search the web for recent news…" scores search_web in the
-    // 0.5–0.6 band, and shipping search without read would dead-end the model.
     anchorMinSimilarity: 0.5
   },
   {
-    // Every OpenMeteo data tool requires latitude/longitude (verified in the
-    // catalog schemas), but users speak in place names — geocoding is the
-    // mandatory first hop. Members deliberately contain ONLY the dependency:
-    // the anchor that fired is already in the semantic matches, and pulling
-    // sibling data tools in would re-create vendor-suite over-inclusion.
-    // Excluded tools (e.g. weather_forecast under the default filter) can't
-    // anchor this set — createServerToolsFilter drops them before expansion —
-    // but the non-weather data tools still deliver geocoding when they match.
     name: "openmeteo-geocode",
     members: ["OpenMeteoMCP-geocoding"],
     anchors: [
@@ -2235,10 +2150,6 @@ var SERVER_TOOL_DEPENDENCY_SETS = [
     anchorMinSimilarity: 0.5
   },
   {
-    // The cancel tool takes its resy_token and the other values only from a
-    // live anuma_list_reservations result in the same turn, never from
-    // memory, so the list tool must ride in whenever cancel is offered.
-    // Members hold only the dependency, like openmeteo-geocode.
     name: "restaurant-cancel-lookup",
     members: ["AnumaPaymentsMCP-anuma_list_reservations"],
     anchors: ["AnumaPaymentsMCP-anuma_cancel_reservation"],
@@ -2445,11 +2356,6 @@ async function autoFilterClientTools(clientTools, promptEmbeddings, cache, embed
     limit: MAX_CLIENT_TOOLS_AFTER_FILTER,
     minSimilarity: CLIENT_TOOLS_MIN_SIMILARITY,
     filterAmbiguous: true,
-    // See CLIENT_TOOLS_RELEVANCE_RATIO: 0.75 admits the second intent of a
-    // multi-intent prompt (which lands ~75-80% of the dominant match), while
-    // still trimming the loose tail. The earlier 0.9 made a second intent
-    // structurally unselectable; the anchorMinSimilarity gates (0.53-0.55)
-    // remain the guard against borderline anchors activating a whole set.
     relevanceRatio: CLIENT_TOOLS_RELEVANCE_RATIO
   });
   const matchedNames = new Set(matches.map((m) => m.tool.name));
@@ -2478,12 +2384,10 @@ async function autoFilterClientTools(clientTools, promptEmbeddings, cache, embed
 
 // src/lib/tools/toolCatalog.ts
 var TOOL_CATALOG = {
-  // Gmail (src/tools/gmail.ts)
   gmail_search_messages: { label: "Search emails", provider: "gmail", connector: "Gmail" },
   gmail_get_message: { label: "Read an email", provider: "gmail", connector: "Gmail" },
   gmail_create_draft: { label: "Draft a reply", provider: "gmail", connector: "Gmail" },
   gmail_send_message: { label: "Send an email", provider: "gmail", connector: "Gmail" },
-  // Google Calendar (src/tools/googleCalendar.ts)
   google_calendar_list_events: {
     label: "Search calendar events",
     provider: "gcalendar",
@@ -2499,7 +2403,6 @@ var TOOL_CATALOG = {
     provider: "gcalendar",
     connector: "Calendar"
   },
-  // Google Drive (src/tools/googleDrive.ts)
   google_drive_search: { label: "Search files", provider: "gdrive", connector: "Drive" },
   google_drive_list_recent: { label: "List recent files", provider: "gdrive", connector: "Drive" },
   google_drive_get_content: { label: "Read file content", provider: "gdrive", connector: "Drive" },
@@ -2513,7 +2416,6 @@ var TOOL_CATALOG = {
     provider: "gdrive",
     connector: "Drive"
   },
-  // Notion (src/tools/notion.ts)
   "notion-search": { label: "Search", provider: "notion", connector: "Notion" },
   "notion-fetch": { label: "Read page", provider: "notion", connector: "Notion" },
   "notion-create-pages": { label: "Create page", provider: "notion", connector: "Notion" },
@@ -2534,17 +2436,14 @@ var TOOL_CATALOG = {
     connector: "Notion"
   },
   "notion-get-teams": { label: "List teamspaces", provider: "notion", connector: "Notion" },
-  // GitHub (src/tools/github.ts)
   github_api: { label: "Use GitHub", provider: "github", connector: "GitHub" },
   github_get_authenticated_user: {
     label: "Read GitHub profile",
     provider: "github",
     connector: "GitHub"
   },
-  // X / Twitter (src/tools/x.ts)
   x_get_me: { label: "Get my X profile", provider: "x", connector: "X" },
   x_get_my_posts: { label: "Read my recent posts", provider: "x", connector: "X" },
-  // Dropbox (src/tools/dropbox.ts)
   dropbox_list_folders: { label: "List files", provider: "dropbox", connector: "Dropbox" },
   dropbox_get_file_content: {
     label: "Read file content",
@@ -2552,7 +2451,6 @@ var TOOL_CATALOG = {
     connector: "Dropbox"
   },
   dropbox_search: { label: "Search files", provider: "dropbox", connector: "Dropbox" },
-  // Slack (src/tools/slack.ts)
   slack_get_me: { label: "Get my Slack profile", provider: "slack", connector: "Slack" },
   slack_list_channels: { label: "List channels", provider: "slack", connector: "Slack" },
   slack_list_dms: { label: "List direct messages", provider: "slack", connector: "Slack" },
@@ -2723,8 +2621,6 @@ var CREATION_INTENT_CLIENT_FACTORIES = {
   document: FULL_GENERATIVE_CLIENT_FACTORIES,
   "web-search": FULL_GENERATIVE_CLIENT_FACTORIES,
   "deep-research": FULL_GENERATIVE_CLIENT_FACTORIES,
-  // Builder modes: restrict to their own toolkit; a `saved` toolkit rides
-  // along on app builds (parity with web's app branch).
   app: ["app", "saved"],
   slides: ["slides"]
 };

package/dist/tools/selection/index.d.mts

@@ -77,13 +77,6 @@ type ToolConfig = LlmapiChatCompletionTool & {
     dependsOn?: string[];
 };
 
-/**
- * Server-side tools caching module
- *
- * Fetches and caches tools from /api/v1/tools endpoint
- * with configurable expiration and localStorage persistence.
- */
-
 /** Tool parameters schema */
 interface ToolParameters {
     properties: Record<string, unknown>;
@@ -808,23 +801,6 @@ interface SelectServerSideToolsOptions {
  */
 declare function selectServerSideTools(options: SelectServerSideToolsOptions): Promise<Array<Record<string, unknown>>>;
 
-/**
- * Client-tool selection — the per-turn semantic filter over a client-tool
- * catalog.
- *
- * Extracted out of `../../react/useChatStorage` (a `"use client"` React +
- * WatermelonDB file) so the identical selection can run anywhere the engine
- * runs: the standalone council path that bypasses the hook, Node unit tests,
- * and the node/RN-safe `@anuma/sdk/tools/selection` subpath. The hook re-imports
- * these — behavior is unchanged from when they lived inline.
- *
- * Dependency-safe by construction: `generateEmbeddings` comes from the db-free
- * `../memoryEngine/generate` core, `RECALL_TOOL_NAME` from the
- * dependency-free `../memory/recallConstants`, and `CONFIRM_TOOL_NAME` from the
- * dependency-free `../../tools/confirmConstants`, so nothing here drags in the
- * WatermelonDB data layer.
- */
-
 /** Typed accessor for client tool name (handles function-call style and flat). */
 declare function getToolName(t: LlmapiChatCompletionTool): string;
 /** Typed accessor for client tool description. */
@@ -868,35 +844,6 @@ noEmbeddingsReason?: "short-prompt" | "error"): Promise<{
     matchedSetNames: ReadonlySet<string>;
 }>;
 
-/**
- * Connector tool catalog + denied-tools system-prompt rider.
- *
- * Granular connector access works by ALLOW/DENY-ing individual SDK tools.
- * Denying a tool means it's never handed to the model that turn, so it
- * physically can't be called — bypass-proof at the model layer.
- *
- * Consumer contract (this PR ships the foundation only — it does NOT wire
- * anything into runtime filtering or the client; those are later phases):
- *
- *   1. Hide the denied tools from the model — pass the denied tool names as
- *      `createServerToolsFilter({ excludeTools })` so they're dropped from the
- *      toolset before it reaches the LLM.
- *   2. Tell the user how to re-enable — append `buildDeniedToolsRider(denied)`
- *      to the system prompt. Because the tool is absent, the model can't name
- *      it on its own and would give a generic "I don't have access". The rider
- *      gives it the specific capability names (grouped by connector) so it can
- *      tell the user to re-enable that exact tool in Connected Apps settings.
- *
- * `TOOL_CATALOG` is the single source of truth for connector tool → friendly
- * label + provider. `provider` is the canonical logical-provider identifier the
- * portal and SDK already key on (matches `internal/oauth/providers.go` and the
- * `createConnectorTokenGetter` call sites) — Phase 2/3 use it to group and
- * persist per-tool denial. `connector` is the human-facing UI display string.
- * Consumers (portal, client) read this on a version bump rather than re-encoding
- * tool names. Labels are placeholders that will be refined later — keep them
- * sensible.
- */
-
 interface ToolCatalogEntry {
     label: string;
     /** Canonical logical-provider id (e.g. "gmail", "gcalendar", "gdrive"). */
@@ -956,22 +903,6 @@ interface ConnectorGuidance {
  */
 declare function buildConnectorGuidance(input: ConnectorGuidanceInput): ConnectorGuidance;
 
-/**
- * `deriveActiveToolSets` — event-shape-agnostic sticky tool-set derivation
- * (issue #702, Phase 4).
- *
- * Web derived sticky sets by scanning `ChatMessage[]` for two web-specific
- * signals: synthetic tool-result user messages (`Tool "<name>" returned: …`)
- * and `ActivityPhase.id`s shaped `server-tool-<name>-<n>`. This module keeps the
- * exact matching logic but keys on a neutral {@link ToolActivationEvent[]}, so
- * both apps feed it through a tiny adapter that maps their own message/activity
- * store to events. That closes the terse-follow-up gap on mobile: a 3-char
- * "yes" inside a slide conversation keeps the slide toolkit because the set
- * stays sticky.
- *
- * Pure and node/RN-safe.
- */
-
 /**
  * A neutral activation signal derived from conversation history.
  *
@@ -1004,26 +935,6 @@ declare function deriveActiveToolSets(events: ToolActivationEvent[], sets?: read
  */
 declare function mergeActiveToolSets(current: string[], derived: string[]): string[];
 
-/**
- * Tool-selection vocabulary — the neutral, product-agnostic types that let the
- * SDK own the "which tools this turn" orchestration both `apps/web` and
- * `apps/mobile` previously hand-duplicated (see issue #702).
- *
- * The split of ownership is deliberate:
- *
- * - The SDK owns the neutral {@link CreationIntent}→client-factory mapping
- *   ({@link CREATION_INTENT_CLIENT_FACTORIES}) and the send-policy rules.
- * - Each app owns its UI→{@link ToolIntentDescriptor} mapper and injects a
- *   {@link ServerToolCatalog} (built from its own static server-tool lists) and
- *   {@link ../assembleClientTools.ToolSelectionAdapters | adapters}. The SDK
- *   never imports the app's tool lists — the dependency direction stays
- *   app→SDK.
- *
- * This module has no runtime dependency on React, the DOM, WatermelonDB, or the
- * generated HTTP client, so it is safe to import from the node/RN-safe
- * `@anuma/sdk/tools/selection` subpath.
- */
-
 /**
  * Which orchestration path a turn runs through.
  *
@@ -1223,27 +1134,6 @@ declare const CREATION_INTENT_CLIENT_FILTER: Record<CreationIntent, ClientToolsF
  */
 declare const CREATION_INTENT_TOOL_SET: Partial<Record<CreationIntent, string>>;
 
-/**
- * `assembleClientTools` — capability-gated client-tool assembly (issue #702,
- * Phase 3). Given a resolved plan's `clientFactories` and a set of adapters, it
- * instantiates only the factories whose adapter is present and concatenates
- * them in a canonical order.
- *
- * The presence of an adapter GATES its factory — the generalization of
- * `createDocumentTools` returning `[]` when `displayDocument` is absent
- * (src/tools/document/index.ts). This is what lets ONE unified plan produce
- * web's full toolkit and mobile's subset automatically: web wires every
- * builder, mobile wires only the ones its RN surface supports, and the absent
- * ones contribute nothing.
- *
- * The SDK deliberately owns the GATING, ORDER, and filter application — not the
- * per-factory wiring. Each app's factory instantiation (slide auto-display,
- * app-lineage tracking, RN-vs-web storage, logging instrumentation) is
- * genuinely app-specific and stays app-side, expressed as a builder here.
- *
- * Pure and node/RN-safe.
- */
-
 /** Minimal logger the assembler uses when a builder throws. */
 interface SelectionLogger {
     warn(message: string, context?: unknown): void;
@@ -1300,18 +1190,6 @@ declare function filterAssembledClientTools<TTool = ToolConfig>(tools: TTool[],
     getName?: (t: TTool) => string;
 }): TTool[] | Promise<TTool[]>;
 
-/**
- * `resolvePlan` — the single source of truth for "which tools this turn"
- * (issue #702, Phase 2). Given a neutral {@link ToolIntentDescriptor} and an
- * app-injected {@link ServerToolCatalog}, it produces a fully-resolved
- * {@link ToolPlanSpec} that both web and mobile consume, replacing each app's
- * hand-written per-mode switch.
- *
- * Pure and node/RN-safe. The plan is data — the host feeds `clientFactories`
- * into `assembleClientTools`, and `serverTools`/`toolChoice`/`maxToolRounds`/
- * `thinkingMode` into its send layer.
- */
-
 /** Context for {@link resolvePlan}: the injected catalog plus host defaults. */
 interface ResolvePlanContext {
     /** The app-built per-intent/-lane server-tool catalog. */
@@ -1343,23 +1221,6 @@ interface ResolvePlanContext {
  */
 declare function resolvePlan(descriptor: ToolIntentDescriptor, ctx: ResolvePlanContext): ToolPlanSpec;
 
-/**
- * Council tool resolution (issue #702, Phase 6).
- *
- * The council path bypasses the per-mode chat switch: each worker sees the full
- * semantic server-tool filter and its OWN per-worker memory tools (built from
- * that worker's model so a private-capable model sees `['private','shared']`
- * and a standard model sees `['shared']` only). The aggregation ("unify")
- * worker must never persist — its `memory_vault_save` is dropped.
- *
- * This module composes each worker's client-tool candidate array and runs it
- * through the SAME `autoFilterClientTools` the chat hook uses, so council and
- * chat share one selection. Building this on the exported selector is what lets
- * mobile council gain per-worker memory tools without re-implementing anything.
- *
- * Pure and node/RN-safe.
- */
-
 /**
  * Resolve the council/aggregation server-tool plan. This is the chat resolver's
  * council-lane path: a semantic server-tool filter, no per-mode client toolkit,
@@ -1414,16 +1275,6 @@ declare function selectCouncilClientTools<TTool extends LlmapiChatCompletionTool
     activatedSetNames?: ReadonlySet<string>;
 }>;
 
-/**
- * Send-policy primitives — the per-turn `tool_choice` / `maxToolRounds` /
- * thinking-mode / coerced-memory-write rules, unified so web and mobile stop
- * hand-duplicating them (issue #702, Phase 1).
- *
- * These were previously spread across web's `useChatSetup` + `useChatSubmitHandler`
- * + `webChatSendMessage` and mobile's `chatModeRouting`. They are pure and
- * node/RN-safe.
- */
-
 /** The vault-save tool name — the one client tool stripped on a coerced turn. */
 declare const MEMORY_SAVE_TOOL_NAME = "memory_vault_save";
 /**
@@ -1465,16 +1316,6 @@ declare function getThinkingMode(entry: ServerToolCatalogEntry | undefined, fall
  */
 declare function stripCoercedMemoryWrite<T extends LlmapiChatCompletionTool>(clientTools: T[], toolChoice: ToolChoice): T[];
 
-/**
- * Server-tools policy — resolve the concrete server-tools filter for a turn
- * from the app-injected {@link ServerToolCatalog} (issue #702, Phase 2).
- *
- * The catalog is opaque to the SDK: each app builds it from its own static
- * server-tool lists (`IMAGE_SERVER_TOOLS`, `SLIDE_SERVER_TOOLS`, …) and passes
- * it in. This module only knows how to pick the right entry and, when the entry
- * is an attachment-aware factory, apply it with the turn's context.
- */
-
 /**
  * Look up the catalog entry for a descriptor. Chat turns key on the creation
  * intent; council/aggregation turns key on the lane.