@juspay/neurolink 12.36.0 → 12.37.0

package/dist/types/file.d.ts

@@ -425,6 +425,18 @@ export type CSVColumnMetadata = {
 };
 /** A parsed CSV row: string-keyed with string (or missing) cell values (#384). */
 export type CSVRow = Record<string, string | undefined>;
+/**
+ * How `CSVProcessor.parseCSVFile` opens the file.
+ *
+ * `followSymlinks: false` opens with O_NOFOLLOW, so a symlink at the final
+ * path component is refused (ELOOP) rather than followed. The sandboxed
+ * analyzeCSV tool passes it after containment has resolved the real path,
+ * closing the window between that check and the open. Defaults to `true`; on
+ * Windows, where O_NOFOLLOW does not exist, the option has no effect.
+ */
+export type CSVFileOpenOptions = {
+    followSymlinks?: boolean;
+};
 /** Result of decoding a buffer with encoding detection (#362). */
 export type DecodedBuffer = {
     /** Decoded text with any BOM removed. */

package/dist/types/proxy.d.ts

@@ -126,10 +126,14 @@ export type ClaudeRequest = {
     stream?: boolean;
     tools?: ClaudeTool[];
     tool_choice?: {
-        type: "auto" | "any" | "none";
+        type: "none";
+    } | {
+        type: "auto" | "any";
+        disable_parallel_tool_use?: boolean;
     } | {
         type: "tool";
         name: string;
+        disable_parallel_tool_use?: boolean;
     };
     thinking?: {
         type: string;
@@ -1858,6 +1862,13 @@ export type ProxyMetrics = {
     fallbackAttemptsTotal: Counter;
     fallbackSuccessTotal: Counter;
     fallbackFailureTotal: Counter;
+    /** Codex-outbound: a declared tool's JSON Schema needed flattening or lost
+     *  a feature (circular $ref, dropped `strict`, a custom grammar tool wrapped
+     *  into a one-string schema) on its way to a Claude tool. */
+    schemaDegradedTotal: Counter;
+    /** Codex-outbound: an inbound field this repo cannot faithfully represent
+     *  in the Claude request was dropped rather than failing the translation. */
+    unsupportedFieldTotal: Counter;
 };
 /** Context for a proxy request at the root span level. */
 export type ProxyRequestContext = {

package/dist/utils/csvProcessor.d.ts

@@ -3,7 +3,7 @@
  * Converts CSV files to LLM-friendly text formats
  * Uses streaming for memory efficiency with large files
  */
-import type { FileProcessingResult, CSVProcessorOptions, CSVRow } from "../types/index.js";
+import type { FileProcessingResult, CSVFileOpenOptions, CSVProcessorOptions, CSVRow } from "../types/index.js";
 /**
  * Rewrite a raw header into a valid identifier. Trims, replaces non-identifier
  * runs with `_`, prefixes a `col_` when it starts with a digit or is empty,
@@ -132,12 +132,12 @@ export declare class CSVProcessor {
      * @param maxRows - Maximum rows to parse (default: 1000)
      * @returns Array of row objects
      */
-    static parseCSVFile(filePath: string, maxRows?: number, timeoutMs?: number): Promise<CSVRow[]>;
+    static parseCSVFile(filePath: string, maxRows?: number, timeoutMs?: number, openOptions?: CSVFileOpenOptions): Promise<CSVRow[]>;
     /**
      * File-parse variant that also reports whether the parse timed out, used by
      * `process()` to surface `metadata.parseTimedOut`.
      */
-    static parseCSVFileWithMeta(filePath: string, maxRows?: number, timeoutMs?: number, encoding?: string): Promise<{
+    static parseCSVFileWithMeta(filePath: string, maxRows?: number, timeoutMs?: number, encoding?: string, openOptions?: CSVFileOpenOptions): Promise<{
         rows: CSVRow[];
         timedOut: boolean;
     }>;

package/dist/utils/csvProcessor.js

@@ -1077,15 +1077,15 @@ export class CSVProcessor {
      * @param maxRows - Maximum rows to parse (default: 1000)
      * @returns Array of row objects
      */
-    static async parseCSVFile(filePath, maxRows = 1000, timeoutMs = DEFAULT_CSV_FILE_PARSE_TIMEOUT_MS) {
-        const { rows } = await this.parseCSVFileWithMeta(filePath, maxRows, timeoutMs);
+    static async parseCSVFile(filePath, maxRows = 1000, timeoutMs = DEFAULT_CSV_FILE_PARSE_TIMEOUT_MS, openOptions) {
+        const { rows } = await this.parseCSVFileWithMeta(filePath, maxRows, timeoutMs, undefined, openOptions);
         return rows;
     }
     /**
      * File-parse variant that also reports whether the parse timed out, used by
      * `process()` to surface `metadata.parseTimedOut`.
      */
-    static async parseCSVFileWithMeta(filePath, maxRows = 1000, timeoutMs = DEFAULT_CSV_FILE_PARSE_TIMEOUT_MS, encoding) {
+    static async parseCSVFileWithMeta(filePath, maxRows = 1000, timeoutMs = DEFAULT_CSV_FILE_PARSE_TIMEOUT_MS, encoding, openOptions) {
         if (typeof filePath !== "string" || filePath.trim().length === 0) {
             throw ErrorFactory.csvInvalidInput("CSVProcessor.parseCSVFile: filePath must be a non-empty string");
         }
@@ -1114,10 +1114,58 @@ export class CSVProcessor {
         catch (error) {
             throw ErrorFactory.csvFileAccessFailed(`[CSVProcessor] Failed to open CSV file (${filePath}): ${error instanceof Error ? error.message : String(error)}`, filePath, error instanceof Error ? error : undefined);
         }
-        // #368: a SINGLE createReadStream. We peek its leading bytes to sniff the
+        // The handle is opened through fs.promises because its `flags` accepts a
+        // number; the stream then owns it (autoClose), so destroy() on the error
+        // paths below still releases the descriptor. Three flags do the work:
+        //
+        // - `followSymlinks: false` adds O_NOFOLLOW (0 on Windows, so a no-op
+        //   there): the sandboxed caller has already checked the real path, and a
+        //   link that appears at the final component afterwards must fail with
+        //   ELOOP rather than redirect the read.
+        // - O_NONBLOCK (0 where undefined) so a FIFO with no writer returns from
+        //   open() at once instead of parking the call in the threadpool for ever,
+        //   beyond the reach of any deadline. It is ignored for regular files.
+        // - O_RDONLY, and then a stat on the opened handle: a CSV is a regular
+        //   file, so a FIFO, a device or a directory is refused before the read
+        //   phase, which is also what stops a device read from never ending.
+        //
+        // The open itself runs under the same wall-clock budget as the phases
+        // after it (#1199). A handle that arrives after the deadline is closed
+        // when it does, so the timed-out open cannot leak a descriptor.
+        const noFollow = openOptions?.followSymlinks === false
+            ? (fs.constants.O_NOFOLLOW ?? 0)
+            : 0;
+        const openFlags = fs.constants.O_RDONLY | noFollow | (fs.constants.O_NONBLOCK ?? 0);
+        const openRegularFile = async () => {
+            const opened = await fs.promises.open(filePath, openFlags);
+            try {
+                if (!(await opened.stat()).isFile()) {
+                    throw new Error("not a regular file");
+                }
+            }
+            catch (error) {
+                await opened.close();
+                throw error;
+            }
+            return opened;
+        };
+        const opening = openRegularFile();
+        let handle;
+        try {
+            handle = await withTimeout(opening, remaining(), "[CSVProcessor] Timed out opening CSV file");
+        }
+        catch (error) {
+            if (error instanceof TimeoutError) {
+                void opening.then((late) => late.close(), () => undefined);
+                logger.warn(`[CSVProcessor] Opening ${filePath} exceeded the ${timeoutMs}ms parse budget; returning an empty partial result`);
+                return { rows: [], timedOut: true };
+            }
+            throw ErrorFactory.csvFileAccessFailed(`[CSVProcessor] Failed to open CSV file (${filePath}): ${error instanceof Error ? error.message : String(error)}`, filePath, error instanceof Error ? error : undefined);
+        }
+        // #368: a SINGLE read stream. We peek its leading bytes to sniff the
         // encoding (#362) and detect a metadata line + delimiter (#361), then
         // replay those bytes back onto the same stream — no second disk read.
-        const rawSource = fs.createReadStream(filePath);
+        const rawSource = handle.createReadStream();
         let prepared;
         try {
             prepared = await withTimeout(this.prepareFileSource(rawSource, encoding, extname(filePath)), remaining(), "[CSVProcessor] Timed out preparing CSV file source");

package/docs-site/static/search-index.json

@@ -3501,7 +3501,7 @@
 {"objectID":"a900aa88102d3e7f32205bee5665bb0732bca6cfe575bcdca0ca993a3590f28e","title":"Bad Word List Curation","url":"/docs/features/guardrails#bad-word-list-curation","content":"✅ Do:\nInclude specific harmful terms\nUse exact phrases, not single characters\nRegularly update based on user reports\nConsider context-specific terms for your domain\n\n❌ Don't:\nAdd common English words (high false positive rate)\nInclude single letters or short words\nRely solely on bad words (use model filter too)","hierarchy":{"lvl0":"Features","lvl1":"Guardrails Middleware","lvl2":"Bad Word List Curation","lvl3":""}},
 {"objectID":"8380babcbfc88033aac779943fa372013989ce1cd79ebbc9f1803af06cf2e27e","title":"Related Features","url":"/docs/features/guardrails#related-features","content":"HITL Workflows - User approval for risky actions\nMiddleware Architecture - Custom middleware development\nAnalytics Integration - Track filtered content metrics","hierarchy":{"lvl0":"Features","lvl1":"Guardrails Middleware","lvl2":"Related Features","lvl3":""}},
 {"objectID":"4dcd9d3f7dd025aac5e11ee4820832266eed4420348ba5f439bac3b9035737ae","title":"Migration Notes","url":"/docs/features/guardrails#migration-notes","content":"If upgrading from versions before v7.42.0:\nGuardrails are now enabled via middleware presets\nOld guardrailsConfig option deprecated - use middlewareConfig.guardrails\nNo breaking changes - existing configs still work\nRecommended: Switch to preset: \"security\" for simplified setup\n\nFor complete technical documentation and advanced integration patterns, see guardrails-ai-integration.md.","hierarchy":{"lvl0":"Features","lvl1":"Guardrails Middleware","lvl2":"Migration Notes","lvl3":""}},
-{"objectID":"4360e3d584ae161b59c6d6c3d6c7fe074f475883b020805602930215117fd0d7","title":"Human-in-the-Loop (HITL) Workflows","url":"/docs/features/hitl","content":"Human-in-the-Loop (HITL) Workflows\n\nSince: v7.39.0 | Status: Stable | Availability: SDK\n\nOverview\n\nWhat it does: HITL pauses AI tool execution to request explicit user approval before performing risky operations like deleting files, modifying databases, or making expensive API calls.\n\nWhy use it: Prevent costly mistakes and give users control over potentially dangerous AI actions. Think of it as an \"Are you sure?\" dialog for AI assistant operations.\n\nOnly use HITL for truly risky operations. Overusing confirmation prompts degrades user experience and can lead to \"confirmation fatigue\" where users approve actions without reading them.\n\nCommon use cases:\nFile deletion or modification operations\nDatabase write/delete operations\nExpensive third-party API calls\nIrreversible actions (sending emails, posting to social media)\nOperations accessing sensitive data\n\nQuick Start\n\nSDK Example\nTool identifier used by the AI to invoke this function\nDescribes tool purpose to the LLM for proper selection\nTriggers HITL checkpoint before execution\nActual implementation only runs after user approval\n\nHandling Confirmation in Your UI\n\nHITL uses an event-based workflow where the SDK emits confirmation requests and your app responds with user decisions.\nGet the event emitter - NeuroLink is not itself an emitter, so requests and responses both go through getEventEmitter()\nSubscribe to confirmation requests - NeuroLink emits one before running a tool that needs approval\nShow your confirmation UI with the tool name, arguments and remaining time\nReply on the same emitter, echoing the request's confirmationId so the response is matched to its request\nApproval decision determines if tool executes\nOptional: Handle cases where user doesn't respond in time\n\nConfiguration\n\n| Option                 | Type      | Default | Required | Description                          |\n| ---------------------- | --------- | ------- | -------- | ------------------------------------ |\n| requiresConfirmation | boolean | false | No       | Mark tool as requiring user approval |\n\nTool Registration\n\nHow It Works\n\nExecution Flow\nAI requests tool execution → Tool executor checks if tool requires confirmation\nConfirmation required? → Returns USER_CONFIRMATION_REQUIRED error to LLM\nLLM asks user → \"I need to [action]. Is that okay?\"\nUser responds:\nApprove → UI sets confirmation_received = true and retries tool execution\nDeny → UI sends \"User cancelled\" message back to LLM\nTool executes → Permission flag immediately resets to false\n\nSecurity Features\nOne-time permissions: Each approval works for exactly one action\nNo reuse: AI cannot reuse old permissions for new actions\nAutomatic reset: Permission flag clears immediately after use\nFail-safe: Defaults to requiring permission when in doubt\n\nAPI Reference\n\nEvent Types\n\nAll HITL events ride the SDK emitter returned by\nneurolink.getEventEmitter(); emitter below is that object.\n\nConfirmation Request Event (hitl:confirmation-request):\n\nConfirmation Response (emit from your app):\n\nTimeout Event (hitl:timeout):\n\nSee human-in-the-loop.md for complete technical documentation.\n\nTroubleshooting\n\nProblem: Tool executes without asking for permission\n\nCause: Tool not marked with requiresConfirmation: true\nSolution:\nAdd this boolean flag to any tool that performs risky operations\n\nProblem: AI keeps asking for confirmation repeatedly\n\nCause: Confirmation responses not being sent or sent with wrong confirmationId\nSolution:\nExtract confirmation ID from the request event\nAlways respond to every confirmation request\nCritical: Use the same confirmationId from the request\n\nProblem: Confirmation dialog doesn't show\n\nCause: Not listening to hitl:confirmation-request event\nSolution:\nRegister the event handler early in your application startup\nAll subsequent tool executions will trigger confirmations when needed\n\nBest Practices\n\nStore user confirmation preferences to avoid repeated prompts for the same action type. For example, if a user approves \"delete temporary files\" once, cache that preference for similar low-risk deletions in the same session.\n\nFor Developers\nMark tools conservatively - If an operation could cause problems, require confirmation\nClear prompts - Ensure users understand exactly what will happen\nTest confirmation flow - Verify it works smoothly in your UI\nLog approvals - Keep audit trail of user decisions\nHandle denials gracefully - Allow users to try alternative approaches\n\nWhat to Mark as Requiring Confirmation\n\n✅ Do require confirmation:\nFile deletions\nDatabase writes/deletes\nSending emails or messages\nMaking purchases or payments\nModifying production systems\n\n❌ Don't require confirmation:\nRead-only operations\nAnswering questions\nGenerating content\nSearching/fetching data\n\nRelated Features\nGuardrails Middleware - Content filtering and safety checks\nCustom Tools - Building your own tools with HITL\nMiddleware Architecture - Advanced request interception\n\nMigration Notes\n\nIf upgrading from versions before v7.39.0:\nReview all","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"","lvl3":""}},
+{"objectID":"4360e3d584ae161b59c6d6c3d6c7fe074f475883b020805602930215117fd0d7","title":"Human-in-the-Loop (HITL) Workflows","url":"/docs/features/hitl","content":"Human-in-the-Loop (HITL) Workflows\n\nSince: v7.39.0 | Status: Stable | Availability: SDK\n\nOverview\n\nWhat it does: HITL pauses AI tool execution to request explicit user approval before performing risky operations like deleting files, modifying databases, or making expensive API calls.\n\nWhy use it: Prevent costly mistakes and give users control over potentially dangerous AI actions. Think of it as an \"Are you sure?\" dialog for AI assistant operations.\n\nOnly use HITL for truly risky operations. Overusing confirmation prompts degrades user experience and can lead to \"confirmation fatigue\" where users approve actions without reading them.\n\nCommon use cases:\nFile deletion or modification operations\nDatabase write/delete operations\nExpensive third-party API calls\nIrreversible actions (sending emails, posting to social media)\nOperations accessing sensitive data\n\nQuick Start\n\nSDK Example\nTool identifier used by the AI to invoke this function\nDescribes tool purpose to the LLM for proper selection\nTriggers HITL checkpoint before execution\nActual implementation only runs after user approval\n\nHandling Confirmation in Your UI\n\nHITL uses an event-based workflow where the SDK emits confirmation requests and your app responds with user decisions.\nGet the event emitter - NeuroLink is not itself an emitter, so requests and responses both go through getEventEmitter()\nSubscribe to confirmation requests - NeuroLink emits one before running a tool that needs approval\nShow your confirmation UI with the tool name, arguments and remaining time\nReply on the same emitter, echoing the request's confirmationId so the response is matched to its request\nApproval decision determines if tool executes\nOptional: Handle cases where user doesn't respond in time\n\nConfiguration\n\n| Option                 | Type      | Default | Required | Description                          |\n| ---------------------- | --------- | ------- | -------- | ------------------------------------ |\n| requiresConfirmation | boolean | false | No       | Mark tool as requiring user approval |\n\nTool Registration\n\nHow It Works\n\nExecution Flow\nAI requests tool execution → Tool executor checks if tool requires confirmation\nConfirmation required? → Returns USER_CONFIRMATION_REQUIRED error to LLM\nLLM asks user → \"I need to [action]. Is that okay?\"\nUser responds:\nApprove → UI sets confirmation_received = true and retries tool execution\nDeny → UI sends \"User cancelled\" message back to LLM\nTool executes → Permission flag immediately resets to false\n\nSecurity Features\nOne-time permissions: Each approval works for exactly one action\nNo reuse: AI cannot reuse old permissions for new actions\nAutomatic reset: Permission flag clears immediately after use\nFail-safe: Defaults to requiring permission when in doubt\n\nAPI Reference\n\nEvent Types\n\nAll HITL events ride the SDK emitter returned by\nneurolink.getEventEmitter(); emitter below is that object.\n\nConfirmation Request Event (hitl:confirmation-request):\n\nConfirmation Response (emit from your app):\n\nTimeout Event (hitl:timeout):\n\nTroubleshooting\n\nProblem: Tool executes without asking for permission\n\nCause: Tool not marked with requiresConfirmation: true\nSolution:\nAdd this boolean flag to any tool that performs risky operations\n\nProblem: AI keeps asking for confirmation repeatedly\n\nCause: Confirmation responses not being sent or sent with wrong confirmationId\nSolution:\nExtract confirmation ID from the request event\nAlways respond to every confirmation request\nCritical: Use the same confirmationId from the request\n\nProblem: Confirmation dialog doesn't show\n\nCause: Not listening to hitl:confirmation-request event\nSolution:\nRegister the event handler early in your application startup\nAll subsequent tool executions will trigger confirmations when needed\n\nBest Practices\n\nStore user confirmation preferences to avoid repeated prompts for the same action type. For example, if a user approves \"delete temporary files\" once, cache that preference for similar low-risk deletions in the same session.\n\nFor Developers\nMark tools conservatively - If an operation could cause problems, require confirmation\nClear prompts - Ensure users understand exactly what will happen\nTest confirmation flow - Verify it works smoothly in your UI\nLog approvals - Keep audit trail of user decisions\nHandle denials gracefully - Allow users to try alternative approaches\n\nWhat to Mark as Requiring Confirmation\n\n✅ Do require confirmation:\nFile deletions\nDatabase writes/deletes\nSending emails or messages\nMaking purchases or payments\nModifying production systems\n\n❌ Don't require confirmation:\nRead-only operations\nAnswering questions\nGenerating content\nSearching/fetching data\n\nRelated Features\nGuardrails Middleware - Content filtering and safety checks\nCustom Tools - Building your own tools with HITL\nMiddleware Architecture - Advanced request interception\n\nMigration Notes\n\nIf upgrading from versions before v7.39.0:\nReview all existing tools for risk assessment\nAdd requiresConfirmation: tr","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"","lvl3":""}},
 {"objectID":"d85931f065438b4475cf5fc7e7854d68dda75d45b96963229ea7accb7f456a86","title":"Human-in-the-Loop (HITL) Workflows","url":"/docs/features/hitl#human-in-the-loop-hitl-workflows","content":"Since: v7.39.0 | Status: Stable | Availability: SDK","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Human-in-the-Loop (HITL) Workflows","lvl3":""}},
 {"objectID":"f1d18bf2b10a871a2c1ba24625cfdba4ced0186612c32e21ff05afa4d8c614b5","title":"Overview","url":"/docs/features/hitl#overview","content":"What it does: HITL pauses AI tool execution to request explicit user approval before performing risky operations like deleting files, modifying databases, or making expensive API calls.\n\nWhy use it: Prevent costly mistakes and give users control over potentially dangerous AI actions. Think of it as an \"Are you sure?\" dialog for AI assistant operations.\n\nOnly use HITL for truly risky operations. Overusing confirmation prompts degrades user experience and can lead to \"confirmation fatigue\" where users approve actions without reading them.\n\nCommon use cases:\nFile deletion or modification operations\nDatabase write/delete operations\nExpensive third-party API calls\nIrreversible actions (sending emails, posting to social media)\nOperations accessing sensitive data","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Overview","lvl3":""}},
 {"objectID":"654bf9d17ad9d1c9c4e13211c1207ecfc732fcf0ed9da7d530dab91fec0ae1fb","title":"SDK Example","url":"/docs/features/hitl#sdk-example","content":"Tool identifier used by the AI to invoke this function\nDescribes tool purpose to the LLM for proper selection\nTriggers HITL checkpoint before execution\nActual implementation only runs after user approval","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"SDK Example","lvl3":""}},
@@ -3509,7 +3509,7 @@
 {"objectID":"0b97c36d119e891d3b7aa500e15ca7ddfbc614d26e2aa8c41888527fc578f0b1","title":"Configuration","url":"/docs/features/hitl#configuration","content":"| Option                 | Type      | Default | Required | Description                          |\n| ---------------------- | --------- | ------- | -------- | ------------------------------------ |\n| requiresConfirmation | boolean | false | No       | Mark tool as requiring user approval |","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Configuration","lvl3":""}},
 {"objectID":"37135c25fca844145fb9e99bf6c00ce7aa59e5fce15d32037ecec0c212da1fe2","title":"Execution Flow","url":"/docs/features/hitl#execution-flow","content":"AI requests tool execution → Tool executor checks if tool requires confirmation\nConfirmation required? → Returns USER_CONFIRMATION_REQUIRED error to LLM\nLLM asks user → \"I need to [action]. Is that okay?\"\nUser responds:\nApprove → UI sets confirmation_received = true and retries tool execution\nDeny → UI sends \"User cancelled\" message back to LLM\nTool executes → Permission flag immediately resets to false","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Execution Flow","lvl3":""}},
 {"objectID":"4d86f092ca7e6b372a961736d886b359fa75e092f709de1fc0632865629f0e19","title":"Security Features","url":"/docs/features/hitl#security-features","content":"One-time permissions: Each approval works for exactly one action\nNo reuse: AI cannot reuse old permissions for new actions\nAutomatic reset: Permission flag clears immediately after use\nFail-safe: Defaults to requiring permission when in doubt","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Security Features","lvl3":""}},
-{"objectID":"7854f3abc1202ff2f15b90ddfd8c29a88a2e6e71aa843e416f760a43ab570dfb","title":"Event Types","url":"/docs/features/hitl#event-types","content":"All HITL events ride the SDK emitter returned by\nneurolink.getEventEmitter(); emitter below is that object.\n\nConfirmation Request Event (hitl:confirmation-request):\n\nConfirmation Response (emit from your app):\n\nTimeout Event (hitl:timeout):\n\nSee human-in-the-loop.md for complete technical documentation.","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Event Types","lvl3":""}},
+{"objectID":"7854f3abc1202ff2f15b90ddfd8c29a88a2e6e71aa843e416f760a43ab570dfb","title":"Event Types","url":"/docs/features/hitl#event-types","content":"All HITL events ride the SDK emitter returned by\nneurolink.getEventEmitter(); emitter below is that object.\n\nConfirmation Request Event (hitl:confirmation-request):\n\nConfirmation Response (emit from your app):\n\nTimeout Event (hitl:timeout):","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Event Types","lvl3":""}},
 {"objectID":"5068502ff92414daee273da8919813c835390458398854e7834845b1a9b7bdef","title":"Problem: Tool executes without asking for permission","url":"/docs/features/hitl#problem-tool-executes-without-asking-for-permission","content":"Cause: Tool not marked with requiresConfirmation: true\nSolution:\nAdd this boolean flag to any tool that performs risky operations","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Problem: Tool executes without asking for permission","lvl3":""}},
 {"objectID":"385ab382fc18fbd69cc1e5d7da2909e9e5c70c897f97f372b61946a0273d456a","title":"Problem: AI keeps asking for confirmation repeatedly","url":"/docs/features/hitl#problem-ai-keeps-asking-for-confirmation-repeatedly","content":"Cause: Confirmation responses not being sent or sent with wrong confirmationId\nSolution:\nExtract confirmation ID from the request event\nAlways respond to every confirmation request\nCritical: Use the same confirmationId from the request","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Problem: AI keeps asking for confirmation repeatedly","lvl3":""}},
 {"objectID":"09de33ea71681ebc227efede41ba43f241d943ed4b4628befc274d99b677b587","title":"Problem: Confirmation dialog doesn't show","url":"/docs/features/hitl#problem-confirmation-dialog-doesnt-show","content":"Cause: Not listening to hitl:confirmation-request event\nSolution:\nRegister the event handler early in your application startup\nAll subsequent tool executions will trigger confirmations when needed","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Problem: Confirmation dialog doesn't show","lvl3":""}},
@@ -3517,7 +3517,7 @@
 {"objectID":"663a4b7479ba9dcd093adabe368f06125118fe7085f3545f7a449aca7cde2f12","title":"For Developers","url":"/docs/features/hitl#for-developers","content":"Mark tools conservatively - If an operation could cause problems, require confirmation\nClear prompts - Ensure users understand exactly what will happen\nTest confirmation flow - Verify it works smoothly in your UI\nLog approvals - Keep audit trail of user decisions\nHandle denials gracefully - Allow users to try alternative approaches","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"For Developers","lvl3":""}},
 {"objectID":"c3d40b4c492682b5b3abcb4d2d310f78bab7a48d751f200854e01f7d9e304fd5","title":"What to Mark as Requiring Confirmation","url":"/docs/features/hitl#what-to-mark-as-requiring-confirmation","content":"✅ Do require confirmation:\nFile deletions\nDatabase writes/deletes\nSending emails or messages\nMaking purchases or payments\nModifying production systems\n\n❌ Don't require confirmation:\nRead-only operations\nAnswering questions\nGenerating content\nSearching/fetching data","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"What to Mark as Requiring Confirmation","lvl3":""}},
 {"objectID":"f10ab96807f42eb76ac745509a5e6538325d9d3ef837892e312092236faad5f0","title":"Related Features","url":"/docs/features/hitl#related-features","content":"Guardrails Middleware - Content filtering and safety checks\nCustom Tools - Building your own tools with HITL\nMiddleware Architecture - Advanced request interception","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Related Features","lvl3":""}},
-{"objectID":"1d0a846cb3cda615b378d07dabb82de126218fb1be810d414af9c1df9fb7b1f8","title":"Migration Notes","url":"/docs/features/hitl#migration-notes","content":"If upgrading from versions before v7.39.0:\nReview all existing tools for risk assessment\nAdd requiresConfirmation: true to risky tools\nImplement confirmation dialog in your UI\nTest with low-risk tools first\nRoll out to production gradually\n\nFor comprehensive technical documentation, diagrams, and security details, see the complete HITL guide.","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Migration Notes","lvl3":""}},
+{"objectID":"1d0a846cb3cda615b378d07dabb82de126218fb1be810d414af9c1df9fb7b1f8","title":"Migration Notes","url":"/docs/features/hitl#migration-notes","content":"If upgrading from versions before v7.39.0:\nReview all existing tools for risk assessment\nAdd requiresConfirmation: true to risky tools\nImplement confirmation dialog in your UI\nTest with low-risk tools first\nRoll out to production gradually","hierarchy":{"lvl0":"Features","lvl1":"Human-in-the-Loop (HITL) Workflows","lvl2":"Migration Notes","lvl3":""}},
 {"objectID":"92776380349b9d110ff9b37bd6ed4fe4297c0c99de05b1929f24abbe4f23454f","title":"Image Generation Streaming Guide","url":"/docs/features/image-generation","content":"Image Generation Streaming Guide\n\nOverview\n\nNeuroLink supports image generation through AI models like Google Vertex AI's gemini-3-pro-image-preview and gemini-2.5-flash-image. This guide explains how image generation works in both generate() and stream() modes, including CLI usage with automatic file saving, technical architecture, and usage examples.\n\nTable of Contents\nArchitecture Overview\nStreaming Modes\nImage Generation Flow\nUsage Examples\nImplementation Details\nTroubleshooting\n\nArchitecture Overview\n\nKey Components\n\nImage Generation Models\n\nThe following models are configured for image generation:\n\nImportant Notes:\nImage generation is supported on Google Vertex AI and Google AI Studio providers\nThe gemini-3-pro-image-preview model requires location: \"global\" configuration on Vertex AI\nOther models can use regional endpoints like us-east5 on Vertex AI\nImages are returned as base64-encoded PNG data\n\nStreaming Modes\n\nReal Streaming vs Fake Streaming\n\nNeuroLink uses two different streaming approaches depending on the model capabilities:\n\nReal Streaming (Text Models)\nUses Vercel AI SDK's native streamText() function\nStreams tokens as they are generated by the AI model\nProvides true real-time streaming experience\nUsed for: GPT-4, Claude, Gemini (text), etc.\n\nFake Streaming (Image Models)\nCalls generate() internally to get complete result\nYields the result progressively to simulate streaming\nRequired because image generation models don't support token-by-token streaming\nUsed for: gemini-2.5-flash-image, gemini-3-pro-image-preview, etc.\n\nWhy Fake Streaming?\n\nImage generation models produce complete images, not incremental tokens. The fake streaming approach:\nMaintains API Consistency: Same stream() interface for all models\nPreserves User Experience: Clients can use the same code pattern\nEnables Progressive Enhancement: Can yield text chunks before final image\nSupports Analytics: Tracks generation time and token usage\n\nImage Generation Flow\n\nStep-by-Step Process\n\nCode Flow in BaseProvider\n\nUsage Examples\n\nExample 1: Basic Image Generation with generate()\n\nExample 2: Image Generation with Streaming\n\nNote: Image generation uses \"fake streaming\" - the complete image is generated first, then yielded as a single chunk. This maintains API consistency with text streaming.\n\nExample 3: CLI Usage\n\nCLI Options:\n--imageOutput <path>: Custom path for generated image (default: generated-images/image-<timestamp>.png)\n--provider vertex or --provider google-ai: Both Vertex AI and Google AI Studio support image generation\n--model <model-name>: Image generation model to use\n--enable-analytics: Include generation metrics\n\nExample 4: Detecting Image Chunks in Stream\n\nExample 5: Error Handling\n\nExample 6: Web Application Integration\n\nImplementation Details\n\nProvider-Specific Implementation\n\nVertex AI provider implements image generation through the REST API:\n\nKey Implementation Details:\nAuthentication: Uses Google Cloud service account credentials\nLocation Handling: Automatically selects global for gemini-3-pro-image-preview\nResponse Modalities: Sets [\"TEXT\", \"IMAGE\"] to enable image generation\nBase64 Extraction: Handles both inlineData and inline_data formats\nResult Enhancement: Preserves imageOutput through analytics pipeline\n\nType Definitions\n\nAnalytics Integration\n\nThe enhanceResult() method in BaseProvider preserves the imageOutput field while adding analytics:\n\nKey Points:\nimageOutput is explicitly preserved through analytics/evaluation pipeline\nSpread operator ensures all existing fields are maintained\nDouble-check restoration at the end prevents accidental loss\n\nTroubleshooting\n\nCommon Issues\nNo Image Chunk Received\n\nSymptom: Stream completes but no image chunk is yielded.\n\nPossible Causes:\nModel is not an image generation model\nWrong provider (only Vertex AI supports image generation)\nAPI credentials are invalid or missing\nModel not available in selected region\n\nSolution:\nEmpty Base64 String\n\nSymptom: Image chunk received but base64 field is empty.\n\nPossible Causes:\nAPI returned error but didn't throw\nResponse format changed\nNetwork issue during transmission\n\nSolution:\nModel Not Found Error\n\nSymptom: Error: models/gemini-3-pro-image-preview is not found for API version v1\n\nCause: gemini-3-pro-image-preview requires location: \"global\" but a regional endpoint is being used.\n\nSolution:\nLarge Image Timeout\n\nSymptom: Generation times out for large/complex images.\n\nSolution:\nCLI Image Not Saved\n\nSymptom: CLI shows success but no file created.\n\nPossible Causes:\nimageOutput option not passed to processOptions()\nDirectory permissions issue\nDisk space full\n\nSolution:\n\nDebug Mode\n\nEnable debug logging to troubleshoot issues:\n\nTesting Image Generation\n\nQuick test to verify image generation works:\n\nBest Practices\nAlways Check for Image Chunks\nValidate Base64 Data\nHandle Both Text and Image\nUse Analytics for Monitoring\n\nConclusion\n\nNeuroLink's image generation streaming provides a unified interface for both text and image generation. Th","hierarchy":{"lvl0":"Features","lvl1":"Image Generation Streaming Guide","lvl2":"","lvl3":""}},
 {"objectID":"275a472d14c36b5430808ab2fbb623b33eff60349093934f61af67b83f355386","title":"Overview","url":"/docs/features/image-generation#overview","content":"NeuroLink supports image generation through AI models like Google Vertex AI's gemini-3-pro-image-preview and gemini-2.5-flash-image. This guide explains how image generation works in both generate() and stream() modes, including CLI usage with automatic file saving, technical architecture, and usage examples.","hierarchy":{"lvl0":"Features","lvl1":"Image Generation Streaming Guide","lvl2":"Overview","lvl3":""}},
 {"objectID":"f069b328ab8c2625a997e823b4685ef26895cd97118e4ef5e1c20e5af4ce88da","title":"Table of Contents","url":"/docs/features/image-generation#table-of-contents","content":"Architecture Overview\nStreaming Modes\nImage Generation Flow\nUsage Examples\nImplementation Details\nTroubleshooting","hierarchy":{"lvl0":"Features","lvl1":"Image Generation Streaming Guide","lvl2":"Table of Contents","lvl3":""}},
@@ -3753,7 +3753,7 @@
 {"objectID":"d72275c9e7abbf35d2de393371870aaa3be8bbdd91700d6b40b764f021b98ee7","title":"Testing","url":"/docs/features/mcp-enhancements#testing","content":"The MCP enhancements include a comprehensive continuous test suite covering all 14 modules.","hierarchy":{"lvl0":"Features","lvl1":"MCP Enhancements","lvl2":"Testing","lvl3":""}},
 {"objectID":"b7897e60e94294066b1f6cc7bf6826a9775fceed2d09959e6ddfaaea03c5e278","title":"Environment Variables","url":"/docs/features/mcp-enhancements#environment-variables","content":"| Variable        | Description                              | Default                |\n| --------------- | ---------------------------------------- | ---------------------- |\n| TEST_PROVIDER | AI provider to use for integration tests | vertex               |\n| TEST_MODEL    | Model name override                      | Provider default model |","hierarchy":{"lvl0":"Features","lvl1":"MCP Enhancements","lvl2":"Environment Variables","lvl3":""}},
 {"objectID":"41243c9cf6b59f63bf30d887f10b3be94d6ab2926fb59964b17b25292ef90e89","title":"Test Coverage","url":"/docs/features/mcp-enhancements#test-coverage","content":"The suite contains 44 test functions with 172+ assertions organized across 9 parts:\n\n| Part | Module                            | Tests | Focus                                                 |\n| ---- | --------------------------------- | ----- | ----------------------------------------------------- |\n| 1    | Tool Router                       | 5     | Strategies, registration, affinity, health, events    |\n| 2    | Tool Cache                        | 5     | Set/get, TTL, eviction, invalidation, stats           |\n| 3    | Request Batcher                   | 5     | Batching, flush, drain, server grouping, events       |\n| 4    | Tool Annotations                  | 5     | Inference, safety levels, validation, merge, filter   |\n| 5    | Tool Converter                    | 5     | Bidirectional conversion, batch, function, sanitize   |\n| 6    | Tool Integration & Middleware     | 5     | Middleware chain, elicitation, timeout, retry, custom |\n| 7    | Enhanced Discovery & Multi-Server | 5     | Search, safety filter, server groups, namespacing     |\n| 8    | Server Base, Exposure, Registry   | 5     | Custom server, agent/workflow exposure, registry      |\n| 9    | Server Capabilities & Elicitation | 4     | Resources, prompts, subscriptions, elicitation types  |","hierarchy":{"lvl0":"Features","lvl1":"MCP Enhancements","lvl2":"Test Coverage","lvl3":""}},
-{"objectID":"1f250cb2aa3fc19be6b69bf1883a325f5979f48d35c830dd3b09590df31fdd27","title":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","url":"/docs/features/mcp-tools-showcase","content":"MCP Tools Ecosystem: Built-in Tools + Any MCP Server\n\nSince: v7.0.0 | Status: Production Ready | MCP Version: 2024-11-05\n\nOverview\n\nNeuroLink's Model Context Protocol (MCP) integration provides a universal plugin system that transforms the SDK from a simple AI interface into a complete AI development platform. With 6 built-in core tools and the ability to connect any community MCP server (58+ cataloged in the server directory), you can extend AI capabilities to interact with filesystems, databases, APIs, cloud services, and custom enterprise systems.\n\nWhat is MCP?\n\nThe Model Context Protocol is an open standard (like USB-C for AI) that enables AI models to securely interact with external tools and data sources through a unified interface. Think of it as:\nFor Developers: A standardized way to connect AI to any external system\nFor AI Models: A tool registry with discoverable, executable functions\nFor Enterprises: A controlled, auditable way to extend AI capabilities\n\nWhy MCP Matters\n\n| Traditional Approach                    | MCP Approach                      | Benefit                 |\n| --------------------------------------- | --------------------------------- | ----------------------- |\n| Custom tool integrations per provider   | One MCP tool works everywhere     | 10x faster integration  |\n| Manual tool discovery and configuration | Automatic tool registry           | Zero-config tool usage  |\n| Provider-specific tool formats          | Universal JSON-RPC protocol       | Provider portability    |\n| Limited to SDK-defined tools            | any community MCP server + custom | Unlimited extensibility |\n| Static tool set                         | Dynamic runtime addition          | Adapt to changing needs |\n\nNeuroLink's Deep MCP Integration\n\nFactory-First Architecture: MCP tools work internally while users see simple factory methods:\n\nKey Features:\n99% Lighthouse Compatible: Existing MCP tools work with minimal changes\nDynamic Server Management: Add/remove MCP servers programmatically\nRich Context: 15+ fields including session, user, permissions, metadata\nPerformance Optimized: 0-11ms tool execution (target: \\<100ms)\nEnterprise Grade: Comprehensive error handling, audit logging, security\n\nQuick Start\n\nBuilt-in Core Tools (6)\n\nNeuroLink ships with 6 essential tools that require zero configuration:\ngetCurrentTime\n\nPurpose: Real-time clock with timezone support\n\nAuto-Available: Yes (always enabled)\n\nUse Cases:\nTimestamp generation\nTimezone conversions\nScheduling and reminders\nTime-based calculations\n\nExample:\n\nTool Schema:\nreadFile\n\nPurpose: Read file contents from filesystem\n\nAuto-Available: Yes (with filesystem access)\n\nUse Cases:\nDocument analysis\nCode review\nConfiguration reading\nLog file processing\n\nExample:\n\nTool Schema:\nwriteFile\n\nPurpose: Write content to filesystem\n\nAuto-Available: Yes (with HITL approval recommended)\n\nUse Cases:\nGenerated content saving\nReport creation\nConfiguration updates\nCode generation output\n\nExample:\n\nTool Schema:\nlistDirectory\n\nPurpose: List files and directories\n\nAuto-Available: Yes (with filesystem access)\n\nUse Cases:\nProject structure analysis\nFile discovery\nDirectory traversal\nAsset inventory\n\nExample:\n\nTool Schema:\n\nFile tool roots\n\nreadFile, writeFile, listDirectory and analyzeCSV only touch paths inside their roots. By default that is the process working directory. Configure other roots per instance, and narrow them per call:\nPrecedence: per-call toolRoots, then instance tools.fileRoots, then the NEUROLINK_TOOL_ROOTS environment variable (a :-separated list; ; on Windows). A per-call root outside the instance roots is rejected, so a server that forwards caller options cannot widen file access.\nResolution: each root must be an existing directory and is resolved through symlinks once, when the request starts. A missing root rejects the call before any model request. fileRoots: [] denies all file access.\nContainment: target paths are resolved through symlinks too, and the prefix check is separator-bounded, so neither <root>/link → /etc nor a sibling such as /srv/workspace-evil gets through. A symlink that does not resolve is refused, and writes never follow a symlink at the final path component. Relative paths resolve against the first root; a root of / contains every absolute path.\nWhere it applies: generate(), generateText(), stream(), streamText(), executeTool(), the server's tool and MCP routes (which execute through the instance's tool registry), and worker instances (createWorkerInstance(), isolated agents, delegates), which inherit the host's roots and can only narrow them. The resolved policy is internal: only toolRoots is settable per call.\nCLI: neurolink generate \"…\" --tool-root /srv/workspace --tool-root /home/agent.\nBash: when the opt-in executeBashCommand tool is enabled, roots constrain only its cwd argument. The command itself runs with the full privileges of the process and can cd anywhere. Use OS-level isolation (a container or a separate user) to sandbo","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"","lvl3":""}},
+{"objectID":"1f250cb2aa3fc19be6b69bf1883a325f5979f48d35c830dd3b09590df31fdd27","title":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","url":"/docs/features/mcp-tools-showcase","content":"MCP Tools Ecosystem: Built-in Tools + Any MCP Server\n\nSince: v7.0.0 | Status: Production Ready | MCP Version: 2024-11-05\n\nOverview\n\nNeuroLink's Model Context Protocol (MCP) integration provides a universal plugin system that transforms the SDK from a simple AI interface into a complete AI development platform. With 6 built-in core tools and the ability to connect any community MCP server (58+ cataloged in the server directory), you can extend AI capabilities to interact with filesystems, databases, APIs, cloud services, and custom enterprise systems.\n\nWhat is MCP?\n\nThe Model Context Protocol is an open standard (like USB-C for AI) that enables AI models to securely interact with external tools and data sources through a unified interface. Think of it as:\nFor Developers: A standardized way to connect AI to any external system\nFor AI Models: A tool registry with discoverable, executable functions\nFor Enterprises: A controlled, auditable way to extend AI capabilities\n\nWhy MCP Matters\n\n| Traditional Approach                    | MCP Approach                      | Benefit                 |\n| --------------------------------------- | --------------------------------- | ----------------------- |\n| Custom tool integrations per provider   | One MCP tool works everywhere     | 10x faster integration  |\n| Manual tool discovery and configuration | Automatic tool registry           | Zero-config tool usage  |\n| Provider-specific tool formats          | Universal JSON-RPC protocol       | Provider portability    |\n| Limited to SDK-defined tools            | any community MCP server + custom | Unlimited extensibility |\n| Static tool set                         | Dynamic runtime addition          | Adapt to changing needs |\n\nNeuroLink's Deep MCP Integration\n\nFactory-First Architecture: MCP tools work internally while users see simple factory methods:\n\nKey Features:\n99% Lighthouse Compatible: Existing MCP tools work with minimal changes\nDynamic Server Management: Add/remove MCP servers programmatically\nRich Context: 15+ fields including session, user, permissions, metadata\nPerformance Optimized: 0-11ms tool execution (target: \\<100ms)\nEnterprise Grade: Comprehensive error handling, audit logging, security\n\nQuick Start\n\nBuilt-in Core Tools (6)\n\nNeuroLink ships with 6 essential tools that require zero configuration:\ngetCurrentTime\n\nPurpose: Real-time clock with timezone support\n\nAuto-Available: Yes (always enabled)\n\nUse Cases:\nTimestamp generation\nTimezone conversions\nScheduling and reminders\nTime-based calculations\n\nExample:\n\nTool Schema:\nreadFile\n\nPurpose: Read file contents from filesystem\n\nAuto-Available: Yes (with filesystem access)\n\nUse Cases:\nDocument analysis\nCode review\nConfiguration reading\nLog file processing\n\nExample:\n\nTool Schema:\nwriteFile\n\nPurpose: Write content to filesystem\n\nAuto-Available: Yes (with HITL approval recommended)\n\nUse Cases:\nGenerated content saving\nReport creation\nConfiguration updates\nCode generation output\n\nExample:\n\nTool Schema:\nlistDirectory\n\nPurpose: List files and directories\n\nAuto-Available: Yes (with filesystem access)\n\nUse Cases:\nProject structure analysis\nFile discovery\nDirectory traversal\nAsset inventory\n\nExample:\n\nTool Schema:\n\nFile tool roots\n\nreadFile, writeFile, listDirectory and analyzeCSV only touch paths inside their roots. By default that is the process working directory. Configure other roots per instance, and narrow them per call:\nPrecedence: per-call toolRoots, then instance tools.fileRoots, then the NEUROLINK_TOOL_ROOTS environment variable (a :-separated list; ; on Windows). A per-call root outside the instance roots is rejected, so a server that forwards caller options cannot widen file access.\nResolution: each root must be an existing directory and is resolved through symlinks once, when the request starts. A missing root rejects the call before any model request. fileRoots: [] denies all file access.\nContainment: target paths are resolved through symlinks too, and the prefix check is separator-bounded, so neither <root>/link → /etc nor a sibling such as /srv/workspace-evil gets through. A symlink that does not resolve is refused. On Linux and macOS, reads, writes and CSV parses open the checked path with O_NOFOLLOW (create mode with O_EXCL), so a link swapped in at the final path component after the check fails instead of redirecting the operation; Windows has no O_NOFOLLOW, so there only create mode carries that last-moment guarantee — the realpath check itself applies on every platform. analyzeCSV also refuses anything that is not a regular file (a FIFO, a device, a directory). listDirectory reports a symlink entry as type: \"symlink\" with the link's own metadata, never its target's. One race is not closed on any platform: a directory component swapped for a symlink between the check and the open is followed, because Node has no openat-style walk and O_NOFOLLOW covers only the final component. That needs an attacker writing into the workspace while the agent runs; i","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"","lvl3":""}},
 {"objectID":"d77f56e2563e08643ae18e7fea4540e640fdcdc7720690210a1b9c5c9a651cc2","title":"MCP Tools Ecosystem: Built-in Tools + Any MCP Server","url":"/docs/features/mcp-tools-showcase#mcp-tools-ecosystem-built-in-tools-any-mcp-server","content":"Since: v7.0.0 | Status: Production Ready | MCP Version: 2024-11-05","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"MCP Tools Ecosystem: Built-in Tools + Any MCP Server","lvl3":""}},
 {"objectID":"a2f242bd22bfb6fb857e7dc60825acc010064d863f53ef5ec236dbb81f1a6a88","title":"Overview","url":"/docs/features/mcp-tools-showcase#overview","content":"NeuroLink's Model Context Protocol (MCP) integration provides a universal plugin system that transforms the SDK from a simple AI interface into a complete AI development platform. With 6 built-in core tools and the ability to connect any community MCP server (58+ cataloged in the server directory), you can extend AI capabilities to interact with filesystems, databases, APIs, cloud services, and custom enterprise systems.","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"Overview","lvl3":""}},
 {"objectID":"6baec5fd689dfd70d9280b9efedecb44456fddef2a81d409f734d582aa0e856b","title":"What is MCP?","url":"/docs/features/mcp-tools-showcase#what-is-mcp","content":"The Model Context Protocol is an open standard (like USB-C for AI) that enables AI models to securely interact with external tools and data sources through a unified interface. Think of it as:\nFor Developers: A standardized way to connect AI to any external system\nFor AI Models: A tool registry with discoverable, executable functions\nFor Enterprises: A controlled, auditable way to extend AI capabilities","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"What is MCP?","lvl3":""}},
@@ -3764,7 +3764,7 @@
 {"objectID":"0415eee591ea3bb5e8bb01bdcea857d051be08a17783ada2a3f2f3e8c9abfbac","title":"2. readFile","url":"/docs/features/mcp-tools-showcase#2-readfile","content":"Purpose: Read file contents from filesystem\n\nAuto-Available: Yes (with filesystem access)\n\nUse Cases:\nDocument analysis\nCode review\nConfiguration reading\nLog file processing\n\nExample:\n\nTool Schema:","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"2. readFile","lvl3":""}},
 {"objectID":"0cb0c9165418d9251e667c3cc9ffab1dc09a25dbb4360b6317d3e4fe85bae458","title":"3. writeFile","url":"/docs/features/mcp-tools-showcase#3-writefile","content":"Purpose: Write content to filesystem\n\nAuto-Available: Yes (with HITL approval recommended)\n\nUse Cases:\nGenerated content saving\nReport creation\nConfiguration updates\nCode generation output\n\nExample:\n\nTool Schema:","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"3. writeFile","lvl3":""}},
 {"objectID":"c27259323275ac78a5c96f275cba4c67336b351f10d6a5990acd9ecb33c015f4","title":"4. listDirectory","url":"/docs/features/mcp-tools-showcase#4-listdirectory","content":"Purpose: List files and directories\n\nAuto-Available: Yes (with filesystem access)\n\nUse Cases:\nProject structure analysis\nFile discovery\nDirectory traversal\nAsset inventory\n\nExample:\n\nTool Schema:","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"4. listDirectory","lvl3":""}},
-{"objectID":"ea372be739ffab9dc37c0fce82830b21566da728269b630501d0755b353a2491","title":"File tool roots","url":"/docs/features/mcp-tools-showcase#file-tool-roots","content":"readFile, writeFile, listDirectory and analyzeCSV only touch paths inside their roots. By default that is the process working directory. Configure other roots per instance, and narrow them per call:\nPrecedence: per-call toolRoots, then instance tools.fileRoots, then the NEUROLINK_TOOL_ROOTS environment variable (a :-separated list; ; on Windows). A per-call root outside the instance roots is rejected, so a server that forwards caller options cannot widen file access.\nResolution: each root must be an existing directory and is resolved through symlinks once, when the request starts. A missing root rejects the call before any model request. fileRoots: [] denies all file access.\nContainment: target paths are resolved through symlinks too, and the prefix check is separator-bounded, so neither <root>/link → /etc nor a sibling such as /srv/workspace-evil gets through. A symlink that does not resolve is refused, and writes never follow a symlink at the final path component. Relative paths resolve against the first root; a root of / contains every absolute path.\nWhere it applies: generate(), generateText(), stream(), streamText(), executeTool(), the server's tool and MCP routes (which execute through the instance's tool registry), and worker instances (createWorkerInstance(), isolated agents, delegates), which inherit the host's roots and can only narrow them. The resolved policy is internal: only toolRoots is settable per call.\nCLI: neurolink generate \"…\" --tool-root /srv/workspace --tool-root /home/agent.\nBash: when the opt-in executeBashCommand tool is enabled, roots constrain only its cwd argument. The command itself runs with the full privileges of the process and can cd anywhere. Use OS-level isolation (a container or a separate user) to sandbox shell commands.","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"File tool roots","lvl3":""}},
+{"objectID":"ea372be739ffab9dc37c0fce82830b21566da728269b630501d0755b353a2491","title":"File tool roots","url":"/docs/features/mcp-tools-showcase#file-tool-roots","content":"readFile, writeFile, listDirectory and analyzeCSV only touch paths inside their roots. By default that is the process working directory. Configure other roots per instance, and narrow them per call:\nPrecedence: per-call toolRoots, then instance tools.fileRoots, then the NEUROLINK_TOOL_ROOTS environment variable (a :-separated list; ; on Windows). A per-call root outside the instance roots is rejected, so a server that forwards caller options cannot widen file access.\nResolution: each root must be an existing directory and is resolved through symlinks once, when the request starts. A missing root rejects the call before any model request. fileRoots: [] denies all file access.\nContainment: target paths are resolved through symlinks too, and the prefix check is separator-bounded, so neither <root>/link → /etc nor a sibling such as /srv/workspace-evil gets through. A symlink that does not resolve is refused. On Linux and macOS, reads, writes and CSV parses open the checked path with O_NOFOLLOW (create mode with O_EXCL), so a link swapped in at the final path component after the check fails instead of redirecting the operation; Windows has no O_NOFOLLOW, so there only create mode carries that last-moment guarantee — the realpath check itself applies on every platform. analyzeCSV also refuses anything that is not a regular file (a FIFO, a device, a directory). listDirectory reports a symlink entry as type: \"symlink\" with the link's own metadata, never its target's. One race is not closed on any platform: a directory component swapped for a symlink between the check and the open is followed, because Node has no openat-style walk and O_NOFOLLOW covers only the final component. That needs an attacker writing into the workspace while the agent runs; if that is your threat model, isolate the process at the OS level rather than relying on this check alone. Relative paths resolve against the first root; a root of / contains every absolute path. Versions before 12.28.0 compared p","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"File tool roots","lvl3":""}},
 {"objectID":"ad698242f08b12159d85a199152ed3aa7035bbde7fe3ba613977b8cf5371fbbd","title":"5. calculateMath","url":"/docs/features/mcp-tools-showcase#5-calculatemath","content":"Purpose: Complex mathematical calculations\n\nAuto-Available: Yes (always enabled)\n\nUse Cases:\nFinancial calculations\nStatistical analysis\nUnit conversions\nScientific computations\n\nExample:\n\nTool Schema:","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"5. calculateMath","lvl3":""}},
 {"objectID":"143629fbd9246f9f135dab71bb41068eb3b7a1007a086298e48eadd77f4782c2","title":"6. websearchGrounding","url":"/docs/features/mcp-tools-showcase#6-websearchgrounding","content":"Purpose: Web search with result grounding\n\nAuto-Available: Only with Google Vertex AI provider\n\nUse Cases:\nReal-time information lookup\nFact verification\nCurrent events\nResearch augmentation\n\nExample:\n\nTool Schema:\n\nNote: This tool is provider-specific (Google Vertex AI only) and leverages Google's grounding capabilities.","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"6. websearchGrounding","lvl3":""}},
 {"objectID":"34487d043deb9df5927b3f66758bf17d6e28e070682a3d99a5f16c9628829088","title":"External MCP Servers","url":"/docs/features/mcp-tools-showcase#external-mcp-servers","content":"NeuroLink connects to the growing MCP ecosystem — any MCP-compliant server works; the server catalog lists 58+ across 6 major categories.","hierarchy":{"lvl0":"Features","lvl1":"MCP Tools Ecosystem - Built-in Tools + Any MCP Server","lvl2":"External MCP Servers","lvl3":""}},
@@ -4953,7 +4953,7 @@
 {"objectID":"ae219f9793ccbc007a57b15dfdccaa134df26af4fe880c1c54bb2b62a303bedf","title":"Timeout Configuration","url":"/docs/getting-started/provider-setup#timeout-configuration-2","content":"Configure request timeouts for SageMaker endpoints:","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"Timeout Configuration","lvl3":""}},
 {"objectID":"b46488b02c1c2e88e3927e60a87df0c66044b3b92cef2a74d1e90908733563a7","title":"Prerequisites","url":"/docs/getting-started/provider-setup#prerequisites","content":"SageMaker Endpoint: Deploy a model to SageMaker and get the endpoint name\nAWS IAM Permissions: Ensure your credentials have sagemaker:InvokeEndpoint permission\nEndpoint Status: Endpoint must be in \"InService\" status","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"Prerequisites","lvl3":""}},
 {"objectID":"3c395f3295fc6e7ca011b13d2ae650bbc58c6294c828a406d7d963b810e7d112","title":"Environment Variables Reference","url":"/docs/getting-started/provider-setup#environment-variables-reference","content":"| Variable                     | Required | Default   | Description               |\n| ---------------------------- | -------- | --------- | ------------------------- |\n| AWS_ACCESS_KEY_ID          | ✅       | -         | AWS access key            |\n| AWS_SECRET_ACCESS_KEY      | ✅       | -         | AWS secret key            |\n| AWS_REGION                 | ✅       | us-east-1 | AWS region                |\n| SAGEMAKER_DEFAULT_ENDPOINT | ✅       | -         | SageMaker endpoint name   |\n| SAGEMAKER_TIMEOUT          | ❌       | 30000     | Request timeout (ms)      |\n| SAGEMAKER_MAX_RETRIES      | ❌       | 3         | Retry attempts            |\n| AWS_SESSION_TOKEN          | ❌       | -         | For temporary credentials |","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"Environment Variables Reference","lvl3":""}},
-{"objectID":"be5f886d8eaff81cf2564a06bf8998a40a59120c426595f47a0482705dc3cfa4","title":"📖 Complete SageMaker Guide","url":"/docs/getting-started/provider-setup#-complete-sagemaker-guide","content":"For comprehensive SageMaker setup, advanced features, and production deployment:\n📖 Complete SageMaker Integration Guide - Includes:\nModel deployment examples\nCost optimization strategies\nEnterprise security patterns\nMulti-model endpoint management\nPerformance testing and monitoring\nTroubleshooting and debugging","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"📖 Complete SageMaker Guide","lvl3":""}},
+{"objectID":"be5f886d8eaff81cf2564a06bf8998a40a59120c426595f47a0482705dc3cfa4","title":"📖 Complete SageMaker Guide","url":"/docs/getting-started/provider-setup#-complete-sagemaker-guide","content":"For endpoint setup, permissions and production deployment:\n📖 Amazon SageMaker Provider Guide - Includes:\nModel endpoint deployment\nEnvironment and client configuration\nIAM policies and VPC connectivity\nFeature support (streaming, embeddings, tools, structured output)\nTroubleshooting","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"📖 Complete SageMaker Guide","lvl3":""}},
 {"objectID":"42c25a94e2f407ae547a34d1bc31de542005830720662dc862edc7ec95e550b2","title":"Google Vertex AI Configuration {#vertex}","url":"/docs/getting-started/provider-setup#google-vertex-ai-configuration-vertex","content":"NeuroLink supports three authentication methods for Google Vertex AI to accommodate different deployment environments:","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"Google Vertex AI Configuration {#vertex}","lvl3":""}},
 {"objectID":"490a21928554ec60701804793b44b0cd4a110db54bcb2de22bec3d3564b40933","title":"Method 1: Service Account File (Recommended for Production)","url":"/docs/getting-started/provider-setup#method-1-service-account-file-recommended-for-production","content":"Best for production environments where you can store service account files securely.\n\nSetup Steps:\nCreate a service account in Google Cloud Console\nDownload the service account JSON file\nSet the file path in GOOGLE_APPLICATION_CREDENTIALS","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"Method 1: Service Account File (Recommended for Production)","lvl3":""}},
 {"objectID":"1a097bda015f26ad1789d0ea1d408cd0104d95f73a0a13e9d1256cf6e749ecab","title":"Method 2: Service Account JSON String (Good for Containers/Cloud)","url":"/docs/getting-started/provider-setup#method-2-service-account-json-string-good-for-containerscloud","content":"Best for containerized environments where file storage is limited.\n\nSetup Steps:\nCopy the entire contents of your service account JSON file\nSet it as a single-line string in GOOGLE_SERVICE_ACCOUNT_KEY\nNeuroLink will automatically create a temporary file for authentication","hierarchy":{"lvl0":"Getting Started","lvl1":"⚙️ Provider Configuration Guide","lvl2":"Method 2: Service Account JSON String (Good for Containers/Cloud)","lvl3":""}},
@@ -6269,7 +6269,7 @@
 {"objectID":"28035feff84612bdd91c9e360bb88ce9dffca58a0ad20f529fa051ea62005817","title":"Check version","url":"/docs/getting-started/providers/ollama#check-version","content":"ollama --version","hierarchy":{"lvl0":"Getting Started","lvl1":"Ollama Provider Guide","lvl2":"Check version","lvl3":""}},
 {"objectID":"32708b28ac6f1015f3c0701e2071dc2b4de80a7e37104a8070c722bb4395fb9f","title":"Linux: curl -fsSL https://ollama.ai/install.sh | sh","url":"/docs/getting-started/providers/ollama#linux-curl--fssl-httpsollamaaiinstallsh-sh","content":"`","hierarchy":{"lvl0":"Getting Started","lvl1":"Ollama Provider Guide","lvl2":"Linux: curl -fsSL https://ollama.ai/install.sh | sh","lvl3":""}},
 {"objectID":"fc3eddeb809dd59cda41523a5f306ab516a791d2b370cb07ff0bb10ed57cac52","title":"Privacy and Security","url":"/docs/getting-started/providers/ollama#privacy-and-security","content":"All data stays local: No network calls to external services during inference\nNo telemetry from Ollama: Ollama does not track usage\nAir-gap capable: After pulling models, works entirely offline\nNo API keys stored: No credentials to manage or rotate","hierarchy":{"lvl0":"Getting Started","lvl1":"Ollama Provider Guide","lvl2":"Privacy and Security","lvl3":""}},
-{"objectID":"d07e6a1dbb1dc1282448e6aaf4c0b2fc05ea60936bbf22b3e6c586403bea1d3b","title":"Related Documentation","url":"/docs/getting-started/providers/ollama#related-documentation","content":"Provider Setup Guide - General provider configuration\nOllama Installation Guide - Detailed platform-specific installation","hierarchy":{"lvl0":"Getting Started","lvl1":"Ollama Provider Guide","lvl2":"Related Documentation","lvl3":""}},
+{"objectID":"d07e6a1dbb1dc1282448e6aaf4c0b2fc05ea60936bbf22b3e6c586403bea1d3b","title":"Related Documentation","url":"/docs/getting-started/providers/ollama#related-documentation","content":"Provider Setup Guide - General provider configuration","hierarchy":{"lvl0":"Getting Started","lvl1":"Ollama Provider Guide","lvl2":"Related Documentation","lvl3":""}},
 {"objectID":"6025b4e7006e938406cdf6541aeaf4aa34bbf8bc6d67e5f9902375382cdf9c2f","title":"Additional Resources","url":"/docs/getting-started/providers/ollama#additional-resources","content":"Ollama - Official website and downloads\nOllama Model Library - Browse available models\nOllama GitHub - Source code and documentation","hierarchy":{"lvl0":"Getting Started","lvl1":"Ollama Provider Guide","lvl2":"Additional Resources","lvl3":""}},
 {"objectID":"b460e78ac10b886e1518c40f993c5a4e35db2f8bd52335908531b88ae82dd358","title":"OpenAI-Compatible Providers Guide","url":"/docs/getting-started/providers/openai-compatible","content":"OpenAI Compatible Provider Guide\n\nConnect to any OpenAI-compatible API: OpenRouter, vLLM, LocalAI, and more\n\nOverview\n\nThe OpenAI Compatible provider enables NeuroLink to work with any service that implements the OpenAI API specification. This includes third-party aggregators like OpenRouter, self-hosted solutions like vLLM, and custom OpenAI-compatible endpoints.\n\nKey Benefits\n🌐 Universal Compatibility: Works with any OpenAI-compatible endpoint\n🔄 Provider Aggregation: Access multiple providers through one endpoint (OpenRouter)\n🏠 Self-Hosted: Run your own models with vLLM, LocalAI\n💰 Cost Optimization: Compare pricing across providers\n🔧 Custom Endpoints: Integrate proprietary AI services\n📊 Auto-Discovery: Automatic model detection via /v1/models endpoint\n\nSupported Services\n\n| Service                   | Description                          | Best For               |\n| ------------------------- | ------------------------------------ | ---------------------- |\n| OpenRouter            | AI provider aggregator (100+ models) | Multi-provider access  |\n| Flatkey               | Unified gateway, one key & balance   | Multi-provider access  |\n| vLLM                  | High-performance inference server    | Self-hosted models     |\n| LocalAI               | Local OpenAI alternative             | Privacy, offline usage |\n| Text Generation WebUI | Community inference server           | Local LLMs             |\n| Custom APIs           | Your own OpenAI-compatible service   | Proprietary models     |\n\nQuick Start\n\nOption 1: OpenRouter (Recommended for Beginners)\n\nOpenRouter provides access to 100+ models from multiple providers through a single API.\nGet OpenRouter API Key\nVisit OpenRouter.ai\nSign up for free account\nGo to Keys\nCreate new key\nAdd credits ($5 minimum)\nConfigure NeuroLink\nTest Setup\n\nOption 2: vLLM (Self-Hosted)\n\nvLLM is a high-performance inference server for running models locally.\nInstall vLLM\nConfigure NeuroLink\nTest Setup\n\nOption 3: LocalAI (Privacy-Focused)\n\nLocalAI runs completely offline for maximum privacy.\nInstall LocalAI\nConfigure NeuroLink\n\nModel Auto-Discovery\n\nNeuroLink automatically discovers available models through the /v1/models endpoint.\n\nDiscover Available Models\n\nSDK Auto-Discovery\n\nOpenRouter Integration\n\nOpenRouter aggregates 100+ models from multiple providers.\n\nAvailable Models on OpenRouter\n\nModel Selection by Provider\n\nOpenRouter Features\n\nvLLM Integration\n\nvLLM provides high-performance inference for self-hosted models.\n\nStarting vLLM Server\n\nNeuroLink Configuration for vLLM\n\nMultiple vLLM Instances\n\nSDK Integration\n\nBasic Usage\n\nWith Model Selection\n\nStreaming\n\nCustom Headers\n\nError Handling\n\nCLI Usage\n\nBasic Commands\n\nOpenRouter-Specific Commands\n\nConfiguration Options\n\nEnvironment Variables\n\nProgrammatic Configuration\n\nUse Cases\nMulti-Provider Access via OpenRouter\nSelf-Hosted Private Models\nCost Optimization\n\nTroubleshooting\n\nCommon Issues\n\"Connection refused\"\n\nProblem: Endpoint is not accessible.\n\nSolution:\n\"Model not found\"\n\nProblem: Model ID is incorrect or not available.\n\nSolution:\n\"Invalid API key\"\n\nProblem: API key format is incorrect (OpenRouter).\n\nSolution:\n\nBest Practices\nModel Discovery\nEndpoint Health Checks\nCost Tracking\n\nRelated Documentation\nProvider Setup Guide - General provider configuration\nCost Optimization - Reduce AI costs\nEnterprise Multi-Region - Self-hosted and vLLM deployment\n\nAdditional Resources\nOpenRouter - Multi-provider aggregator\nvLLM Documentation - Self-hosted inference\nLocalAI - Local OpenAI alternative\nOpenAI API Spec - API standard\n\nNeed Help? Join our GitHub Discussions or open an issue.","hierarchy":{"lvl0":"Getting Started","lvl1":"OpenAI-Compatible Providers Guide","lvl2":"","lvl3":""}},
 {"objectID":"097c7973f73ac7ef3fbecf4f5ec22813622550f2401a067d32c389e65d6152c7","title":"OpenAI Compatible Provider Guide","url":"/docs/getting-started/providers/openai-compatible#openai-compatible-provider-guide","content":"Connect to any OpenAI-compatible API: OpenRouter, vLLM, LocalAI, and more","hierarchy":{"lvl0":"Getting Started","lvl1":"OpenAI-Compatible Providers Guide","lvl2":"OpenAI Compatible Provider Guide","lvl3":""}},
@@ -10772,14 +10772,14 @@
 {"objectID":"25e1ac265c89596a09bce35c4ba7b8d82ccf92f016708d1f6f4826b290af00ae","title":"Delivery","url":"/docs/superpowers/specs/2026-09-23-proxy-account-routing-policies-design#delivery","content":"juspay/neurolink merges one commit per PR, so two PRs:\nRefactor, no behaviour change: extract the comparator into accountRanking.ts and count in-flight on the unlimited lease. Proven by the replay and the existing route tests.\nPolicies: headroom-first, prefer-primary, session affinity, spill, config, telemetry, /status, and the documentation correction below.","hierarchy":{"lvl0":"Superpowers","lvl1":"Proxy Account Routing Policies Design","lvl2":"Delivery","lvl3":""}},
 {"objectID":"06eb4e8ea79a4077f7cb445c1ec17985516046ab28d49d3c87b85ade0155f2c1","title":"Documentation","url":"/docs/superpowers/specs/2026-09-23-proxy-account-routing-policies-design#documentation","content":"docs/features/claude-proxy-config-reference.md gains the five keys. The primary-account text and source comments that still say the primary is \"tried first under fill-first\" are corrected: with quota routing the primary is the final tiebreaker unless prefer-primary is set.","hierarchy":{"lvl0":"Superpowers","lvl1":"Proxy Account Routing Policies Design","lvl2":"Documentation","lvl3":""}},
 {"objectID":"1cf022d6f43b961b6fd1c13d8a5677077f9109584a3a5e67d837c4d5f6e613da","title":"Out of scope","url":"/docs/superpowers/specs/2026-09-23-proxy-account-routing-policies-design#out-of-scope","content":"Per-model policies, weighted scoring, persisting affinity across restarts, an account reserve, and changes to cooldown classification, in-stream rate-limit handling or state persistence. Those last three are separate designs.","hierarchy":{"lvl0":"Superpowers","lvl1":"Proxy Account Routing Policies Design","lvl2":"Out of scope","lvl3":""}},
-{"objectID":"f0109d9239beed7372578f5d0ad41b745b321c526407db0d3bbb32adced24e2e","title":"Codex Outbound Fallback — Design","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design","content":"Codex Outbound Fallback — Design\n\nStatus: design complete, implementation not started. Produced by 22 parallel agents\n(6 grounding, 8 design, 8 adversarial review) plus 8 resolution passes; every design\nclaim below was checked against the code by a reviewer whose brief was to refute it.\n\nGoal\n\nA native Codex client request that its own account pool cannot serve currently fails to the\nclient. This design gives the Codex engine an outbound fallback chain to the Anthropic OAuth\npool and to Vertex, so the request is served instead — with prompt caching preserved across\nthe hop, tool calls translated faithfully in both directions, and no client-visible protocol\nanomaly.\n\nEvidence\nsrc/lib/server/routes/codexProxyRoutes.ts has no outbound fallback. Its only fallback\n  references are a string-default helper (line 138) and code recognising when the Codex engine\n  is itself invoked as an inner Anthropic fallback (lines 666, 817, CODEX_FALLBACK_METADATA_KEY\n  at 109). On pool exhaustion it returns a terminal error: buildCodexErrorResponse\n  (1458-1462), or buildCodexQuotaExhaustedResponse (909-914) when every account is already\n  cooling.\nThree directions exist and work: Claude Code → Anthropic pool; Claude/Anthropic → Codex\n  (executeClaudeCodexFallback, claudeProxyRoutes.ts:5499, called at 6131, in-process — no\n  HTTP hop); Claude/Anthropic → Vertex (vertexAnthropicFallback.ts:611, gated on\n  isVertexAnthropicModel, 576).\nThree do not exist: Vertex → Anthropic, native Codex → Anthropic, native Codex →\n  Vertex. PR #1782 fixed translation defects in the existing Claude → Vertex direction; it\n  did not add a reverse path.\nCodex prompt caching is live but partial. proxy_tokens_cache_read by model:\n  gpt-5.6-sol 566,657,536; gpt-6-astra 3,285,888; gpt-5.6-terra 490,752;\n  gpt-5.6-luna 5,888. proxy_tokens_cache_creation is 0 for every Codex series, which is\n  correct — OpenAI caching is automatic and has no explicit write.\nThe caching asymmetry is the central design constraint. Anthropic caching is explicit:\n  up to 4 cache_control breakpoints over a tools → system → messages prefix, write at\n  1.25x base input (5-minute TTL) or 2x (1-hour), read at 0.1x, and each account holds its\n  own cache. A Codex request translated to Anthropic arrives with no breakpoints at all,\n  so it would be cached not at all unless the translator inserts them deliberately.\nSince Claude-on-Vertex speaks the Anthropic Messages wire format, one Codex→Anthropic\n  translator covers both targets. There is no smaller Vertex-only variant of this work.\n\nBuild order\n\nDependency-ordered; each step is one reviewable PR under the one-commit-per-PR policy. Default\noff at every step, so behaviour is byte-for-byte unchanged until the final enable.\n\n| #   | PR                                                                  | Depends on | Gate                                         |\n| --- | ------------------------------------------------------------------- | ---------- | -------------------------------------------- |\n| 1   | IR types + codec contract (src/lib/types/proxyIR.ts)              | —          | typecheck; exhaustiveness is a compile error |\n| 2   | Request codec Codex → Anthropic (codexOutboundFallback.ts)        | 1          | offline shape suite                          |\n| 3   | Response/stream codec Anthropic → Codex                             | 1          | offline event-order suite                    |\n| 4   | Tool fidelity + id correlation                                      | 2, 3       | offline round-trip suite                     |\n| 5   | Cache breakpoints + prefix byte-stability (codexOutboundCache.ts) | 2          | byte-stability assertion across two turns    |\n| 6   | Trigger policy, commitment rule, loop prevention, accounting        | 2-4        | totality + commitment suites                 |\n| 7   | Config keys, kill switch, metrics                                   | 6          | config validation suite                      |\n| 8   | Enable + live model matrix                                          | all        | live pass criteria                           |\n\nOpen questions gating the build\n\nEvery one needs the same thing: real captured native Codex traffic. The repo has 4 synthetic\nfixtures, one real single-turn capture (~/.neurolink/reference/codex-cli-wire-sample.json,\ncaptured 2026-09-21), a real usage-frame capture (test/fixtures/codex-response-usage.sse,\ncaptured 2026-08-21), and one real controlled bisection experiment against the actual\ncodex_exec/0.155.1 binary (scripts/codex-replay-listener.ts, test/fixtures/sse-bisection-findings.md,\nrun 2026-09-27). Two questions are now settled; the rest are listed here because they can still\ninvalidate a whole section, so they should be settled before the PRs that depend on them are\nwritten.\n\n| Question                                                                                       | Blocks  | Settled by                                                                 ","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"","lvl3":""}},
-{"objectID":"6034ef59cb5b3d2520fa92f2f181aca534a58aa28338f3411aa9d28d998e487e","title":"Codex Outbound Fallback — Design","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#codex-outbound-fallback-design","content":"Status: design complete, implementation not started. Produced by 22 parallel agents\n(6 grounding, 8 design, 8 adversarial review) plus 8 resolution passes; every design\nclaim below was checked against the code by a reviewer whose brief was to refute it.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Codex Outbound Fallback — Design","lvl3":""}},
+{"objectID":"f0109d9239beed7372578f5d0ad41b745b321c526407db0d3bbb32adced24e2e","title":"Codex Outbound Fallback — Design","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design","content":"Codex Outbound Fallback — Design\n\nStatus: design complete; implementation under way in build order. PR 1 (the IR\ntypes) merged as #1826; PR 2 (the request codec) is #1836; PRs 3 to 8 have not\nstarted, and nothing is wired into a route yet. Produced by 22 parallel agents\n(6 grounding, 8 design, 8 adversarial review) plus 8 resolution passes; every design\nclaim below was checked against the code by a reviewer whose brief was to refute it.\n\nGoal\n\nA native Codex client request that its own account pool cannot serve currently fails to the\nclient. This design gives the Codex engine an outbound fallback chain to the Anthropic OAuth\npool and to Vertex, so the request is served instead — with prompt caching preserved across\nthe hop, tool calls translated faithfully in both directions, and no client-visible protocol\nanomaly.\n\nEvidence\nsrc/lib/server/routes/codexProxyRoutes.ts has no outbound fallback. Its only fallback\n  references are a string-default helper (line 138) and code recognising when the Codex engine\n  is itself invoked as an inner Anthropic fallback (lines 666, 817, CODEX_FALLBACK_METADATA_KEY\n  at 109). On pool exhaustion it returns a terminal error: buildCodexErrorResponse\n  (1458-1462), or buildCodexQuotaExhaustedResponse (909-914) when every account is already\n  cooling.\nThree directions exist and work: Claude Code → Anthropic pool; Claude/Anthropic → Codex\n  (executeClaudeCodexFallback, claudeProxyRoutes.ts:5499, called at 6131, in-process — no\n  HTTP hop); Claude/Anthropic → Vertex (vertexAnthropicFallback.ts:611, gated on\n  isVertexAnthropicModel, 576).\nThree do not exist: Vertex → Anthropic, native Codex → Anthropic, native Codex →\n  Vertex. PR #1782 fixed translation defects in the existing Claude → Vertex direction; it\n  did not add a reverse path.\nCodex prompt caching is live but partial. proxy_tokens_cache_read by model:\n  gpt-5.6-sol 566,657,536; gpt-6-astra 3,285,888; gpt-5.6-terra 490,752;\n  gpt-5.6-luna 5,888. proxy_tokens_cache_creation is 0 for every Codex series, which is\n  correct — OpenAI caching is automatic and has no explicit write.\nThe caching asymmetry is the central design constraint. Anthropic caching is explicit:\n  up to 4 cache_control breakpoints over a tools → system → messages prefix, write at\n  1.25x base input (5-minute TTL) or 2x (1-hour), read at 0.1x, and each account holds its\n  own cache. A Codex request translated to Anthropic arrives with no breakpoints at all,\n  so it would be cached not at all unless the translator inserts them deliberately.\nSince Claude-on-Vertex speaks the Anthropic Messages wire format, one Codex→Anthropic\n  translator covers both targets. There is no smaller Vertex-only variant of this work.\n\nBuild order\n\nDependency-ordered; each step is one reviewable PR under the one-commit-per-PR policy. Default\noff at every step, so behaviour is byte-for-byte unchanged until the final enable.\n\n| #   | PR                                                                  | Depends on | Gate                                         |\n| --- | ------------------------------------------------------------------- | ---------- | -------------------------------------------- |\n| 1   | IR types + codec contract (src/lib/types/proxyIR.ts)              | —          | typecheck; exhaustiveness is a compile error |\n| 2   | Request codec Codex → Anthropic (codexOutboundFallback.ts)        | 1          | offline shape suite                          |\n| 3   | Response/stream codec Anthropic → Codex                             | 1          | offline event-order suite                    |\n| 4   | Tool fidelity + id correlation                                      | 2, 3       | offline round-trip suite                     |\n| 5   | Cache breakpoints + prefix byte-stability (codexOutboundCache.ts) | 2          | byte-stability assertion across two turns    |\n| 6   | Trigger policy, commitment rule, loop prevention, accounting        | 2-4        | totality + commitment suites                 |\n| 7   | Config keys, kill switch, metrics                                   | 6          | config validation suite                      |\n| 8   | Enable + live model matrix                                          | all        | live pass criteria                           |\n\nOpen questions gating the build\n\nEvery one needs the same thing: real captured native Codex traffic. The repo has 4 synthetic\nfixtures, one real single-turn capture (~/.neurolink/reference/codex-cli-wire-sample.json,\ncaptured 2026-09-21), a real usage-frame capture (test/fixtures/codex-response-usage.sse,\ncaptured 2026-08-21), and one real controlled bisection experiment against the actual\ncodex_exec/0.155.1 binary (scripts/codex-replay-listener.ts, test/fixtures/sse-bisection-findings.md,\nrun 2026-09-27). Two questions are now settled; the rest are listed here because they can still\ninvalidate a whole section, so they should be settled before the PRs that depend on them are\nwritten.\n\n| Question                     ","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"","lvl3":""}},
+{"objectID":"6034ef59cb5b3d2520fa92f2f181aca534a58aa28338f3411aa9d28d998e487e","title":"Codex Outbound Fallback — Design","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#codex-outbound-fallback-design","content":"Status: design complete; implementation under way in build order. PR 1 (the IR\ntypes) merged as #1826; PR 2 (the request codec) is #1836; PRs 3 to 8 have not\nstarted, and nothing is wired into a route yet. Produced by 22 parallel agents\n(6 grounding, 8 design, 8 adversarial review) plus 8 resolution passes; every design\nclaim below was checked against the code by a reviewer whose brief was to refute it.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Codex Outbound Fallback — Design","lvl3":""}},
 {"objectID":"580c5a06163d1e603bb34f5f3b51c78e4efa36e12426cf22b63706680af0ea56","title":"Goal","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#goal","content":"A native Codex client request that its own account pool cannot serve currently fails to the\nclient. This design gives the Codex engine an outbound fallback chain to the Anthropic OAuth\npool and to Vertex, so the request is served instead — with prompt caching preserved across\nthe hop, tool calls translated faithfully in both directions, and no client-visible protocol\nanomaly.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Goal","lvl3":""}},
 {"objectID":"ed180fb4ca61ad0027c4359503ac6ea54b391281020d32b2a9b498cd6c83abeb","title":"Evidence","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#evidence","content":"src/lib/server/routes/codexProxyRoutes.ts has no outbound fallback. Its only fallback\n  references are a string-default helper (line 138) and code recognising when the Codex engine\n  is itself invoked as an inner Anthropic fallback (lines 666, 817, CODEX_FALLBACK_METADATA_KEY\n  at 109). On pool exhaustion it returns a terminal error: buildCodexErrorResponse\n  (1458-1462), or buildCodexQuotaExhaustedResponse (909-914) when every account is already\n  cooling.\nThree directions exist and work: Claude Code → Anthropic pool; Claude/Anthropic → Codex\n  (executeClaudeCodexFallback, claudeProxyRoutes.ts:5499, called at 6131, in-process — no\n  HTTP hop); Claude/Anthropic → Vertex (vertexAnthropicFallback.ts:611, gated on\n  isVertexAnthropicModel, 576).\nThree do not exist: Vertex → Anthropic, native Codex → Anthropic, native Codex →\n  Vertex. PR #1782 fixed translation defects in the existing Claude → Vertex direction; it\n  did not add a reverse path.\nCodex prompt caching is live but partial. proxy_tokens_cache_read by model:\n  gpt-5.6-sol 566,657,536; gpt-6-astra 3,285,888; gpt-5.6-terra 490,752;\n  gpt-5.6-luna 5,888. proxy_tokens_cache_creation is 0 for every Codex series, which is\n  correct — OpenAI caching is automatic and has no explicit write.\nThe caching asymmetry is the central design constraint. Anthropic caching is explicit:\n  up to 4 cache_control breakpoints over a tools → system → messages prefix, write at\n  1.25x base input (5-minute TTL) or 2x (1-hour), read at 0.1x, and each account holds its\n  own cache. A Codex request translated to Anthropic arrives with no breakpoints at all,\n  so it would be cached not at all unless the translator inserts them deliberately.\nSince Claude-on-Vertex speaks the Anthropic Messages wire format, one Codex→Anthropic\n  translator covers both targets. There is no smaller Vertex-only variant of this work.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Evidence","lvl3":""}},
 {"objectID":"a5aa19ce68fa1175c4bade50ae303cc0a954bf1128588e294af993c049e2f466","title":"Build order","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#build-order","content":"Dependency-ordered; each step is one reviewable PR under the one-commit-per-PR policy. Default\noff at every step, so behaviour is byte-for-byte unchanged until the final enable.\n\n| #   | PR                                                                  | Depends on | Gate                                         |\n| --- | ------------------------------------------------------------------- | ---------- | -------------------------------------------- |\n| 1   | IR types + codec contract (src/lib/types/proxyIR.ts)              | —          | typecheck; exhaustiveness is a compile error |\n| 2   | Request codec Codex → Anthropic (codexOutboundFallback.ts)        | 1          | offline shape suite                          |\n| 3   | Response/stream codec Anthropic → Codex                             | 1          | offline event-order suite                    |\n| 4   | Tool fidelity + id correlation                                      | 2, 3       | offline round-trip suite                     |\n| 5   | Cache breakpoints + prefix byte-stability (codexOutboundCache.ts) | 2          | byte-stability assertion across two turns    |\n| 6   | Trigger policy, commitment rule, loop prevention, accounting        | 2-4        | totality + commitment suites                 |\n| 7   | Config keys, kill switch, metrics                                   | 6          | config validation suite                      |\n| 8   | Enable + live model matrix                                          | all        | live pass criteria                           |","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Build order","lvl3":""}},
 {"objectID":"db4fcb5c145b85c8e756be096fdda4d88c5f6fc576ec62653a8545735ff1a653","title":"Open questions gating the build","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#open-questions-gating-the-build","content":"Every one needs the same thing: real captured native Codex traffic. The repo has 4 synthetic\nfixtures, one real single-turn capture (~/.neurolink/reference/codex-cli-wire-sample.json,\ncaptured 2026-09-21), a real usage-frame capture (test/fixtures/codex-response-usage.sse,\ncaptured 2026-08-21), and one real controlled bisection experiment against the actual\ncodex_exec/0.155.1 binary (scripts/codex-replay-listener.ts, test/fixtures/sse-bisection-findings.md,\nrun 2026-09-27). Two questions are now settled; the rest are listed here because they can still\ninvalidate a whole section, so they should be settled before the PRs that depend on them are\nwritten.\n\n| Question                                                                                       | Blocks  | Settled by                                                                                                                                                                                                                                                                                                                                                                                    |\n| ---------------------------------------------------------------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Does the real Codex CLI accept a call_id it did not mint (a toolu_-shaped id)?             | PR 4    | SETTLED (2026-09-27) — yes, verbatim. codex-replay-listener.ts --script tool-call against real codex_exec/0.155.1: the CLI's follow-up function_call_output carried call_id: \"toolu_replay0000000000000000\" unmodified (own id field is CLI-minted fco_-","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Open questions gating the build","lvl3":""}},
 {"objectID":"a85c34c0265b0c27d696611075427124ef72062ef3e1248bf75ddc2f859229d0","title":"Contents","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#contents","content":"Translation layer: canonical IR and codec contract\nRequest translation: Codex Responses → Anthropic Messages\nResponse translation: Anthropic → Codex wire format\nTool-call fidelity in both directions\nPreserving prompt caching across the hop\nTrigger policy, commitment safety, loop prevention, accounting\nConfiguration surface and staged rollout\nValidation plan","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Contents","lvl3":""}},
-{"objectID":"62546125e30c54bebd2104e396943d1fb60478f7d22873e75792c81c408d2791","title":"Consolidated unresolved items","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#consolidated-unresolved-items","content":"ir-and-types — whether native Codex ever sends top-level reasoning/tools on a genuine inbound request — the one check that would settle it is a live-captured native Codex CLI request with non-default reasoning effort set.\nir-and-types — whether Anthropic's live API ever rejects consecutive same-role messages in some edge case — the one check that would settle it is a probe request against the real API with two consecutive user messages.\nir-and-types — the storage/lifetime contract for a resumed session's id map spanning multiple proxy requests — the one check that would settle it is reading how originSessionId/originThreadId are persisted by the session-affinity\nir-and-types — above.\nrequest-translation — in §10. It converts an unknown into a loud, caller-visible failure instead of a silent one, which is what the \"nothing may break silently\" requirement demands even without live traffic.\nrequest-translation — whether additional_tools/developer items can appear anywhere other than before the first user item in real traffic — the one check that would settle it: capture one real Codex CLI multi-turn session with a mid-conv\nrequest-translation — whether a resumed-session request's input is genuinely full-history or incremental — the one check that would settle it: capture one real resumed-session Codex Responses request (the referenced ~/.neurolink/reference/\n- **request-translation** — whether toolchoice or reasoning ever appear on genuine inbound requests at all (absent from all 4 fixtures) — the one check that would settle it: grep captured production Codex traffic logs (once available) for eith\n- **request-translation** — whether more than one additionaltools item can appear in one request — the one check that would settle it: same real-traffic capture as (1).\n- **response-translation** — a genuine live-captured native Codex Responses SSE transcript (text, tool-call, incomplete/error cases) — the check that would settle it is running a real Codex client through this","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Consolidated unresolved items","lvl3":""}},
+{"objectID":"62546125e30c54bebd2104e396943d1fb60478f7d22873e75792c81c408d2791","title":"Consolidated unresolved items","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#consolidated-unresolved-items","content":"ir-and-types — whether native Codex ever sends top-level reasoning/tools on a genuine inbound request — settled for reasoning by the 2026-09-21 capture, which is exactly the check this item asked for (see the gating table above): it is sent with a non-default effort ({\"effort\":\"xhigh\",\"context\":\"all_turns\"}). That captured request has no top-level tools field, only the nested additional_tools item, but one first-turn capture cannot show that no request ever carries one. Still open from the same gating row: whether it ever sends stream:false.\nir-and-types — whether Anthropic's live API ever rejects consecutive same-role messages in some edge case — the one check that would settle it is a probe request against the real API with two consecutive user messages.\nir-and-types — the storage/lifetime contract for a resumed session's id map spanning multiple proxy requests — the one check that would settle it is reading how originSessionId/originThreadId are persisted by the session-affinity\nir-and-types — above.\nrequest-translation — in §10. It converts an unknown into a loud, caller-visible failure instead of a silent one, which is what the \"nothing may break silently\" requirement demands even without live traffic.\nrequest-translation — whether additional_tools/developer items can appear anywhere other than before the first user item in real traffic — the one check that would settle it: capture one real Codex CLI multi-turn session with a mid-conv\nrequest-translation — whether a resumed-session request's input is genuinely full-history or incremental — the one check that would settle it: capture one real resumed-session Codex Responses request (the referenced ~/.neurolink/reference/\n- **request-translation** — whether toolchoice or reasoning ever appear on genuine inbound requests at all (absent from all 4 fixtures) — **settled**: the 2026-09-21 capture carries both, toolchoice: \"auto\" and reasoning as quoted in the first item of this list.\n- **request-translation** — wheth","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Consolidated unresolved items","lvl3":""}},
 {"objectID":"b890fc666ae87c04302cb9122b852c6e394f3a6eb3ad2c2a3b90aed60a49e057","title":"Decision (kept)","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#decision-kept","content":"Single canonical IR, not ClaudeRequest-as-hub, not pairwise codecs. Verified: openaiFormat.ts/geminiFormat.ts already use ClaudeRequest as an implicit hub only because it is also the literal Anthropic wire type; codexFallback.ts already needs a role cast ((message.role as string) !== \"system\", line 154) to special-case Claude Code's inline-system convention inside a converter meant to be neutral. A new file, src/lib/types/proxyIR.ts, holds a real wire-neutral IR. ClaudeRequest/ClaudeResponse (proxy.ts:154, :187) stay untouched — the Anthropic hot path (claudeProxyRoutes.ts) never changes.\n\nVertex needs no separate codec. Confirmed: executeVertexAnthropicFallback (vertexAnthropicFallback.ts:605-665) forwards the upstream body/stream untouched with a code comment that it is \"already Anthropic-shaped\"; buildVertexAnthropicPayload (line 399) only strips UNSUPPORTED_FIELDS = [\"model\", \"context_management\"] (line 42). Vertex reuses anthropicMessagesIRCodec.buildRequest's output as-is.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Decision (kept)","lvl3":""}},
 {"objectID":"a1d8a0c721ce132a2ececad931143e90dddbb50e47f04652ec692c3c3e12a040","title":"codexFallback.ts: left unrefactored this PR","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#codexfallbackts-left-unrefactored-this-pr","content":"It already implements, in the new vocabulary, the codex-responses request builder (convertClaudeRequestToCodex, line 407) and response parser (parseCodexFallbackSSE line 592, createCodexFallbackStream line 719) — never a request parser or response renderer, since Codex there is a fallback target, not a served client. Deferred to a named follow-up PR (one-commit-per-PR; mixing a mechanical port with new functional work is out of scope). Coexistence cost: convertClaudeRequestToCodex and the new anthropicMessagesIRCodec/codexNativeRequestCodec independently implement the same tool_choice bijection (any↔required, tool↔function) and the same reasoning-effort concept in reverse; a fix to one will not propagate until the follow-up ports codexFallback.ts onto the same 4 capabilities, verified byte-for-byte against test/continuous-test-suite-codex.ts.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"codexFallback.ts: left unrefactored this PR","lvl3":""}},
 {"objectID":"6a41248b50b7d11345c624537be172f4317d8a583d937c841b1f804ccfe4397f","title":"Grounding notes from the fixtures (all 4 read in full)","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#grounding-notes-from-the-fixtures-all-4-read-in-full","content":"test/fixtures/codex-request-{exec-mode,interactive-mode,resumed-session,tool-result-turn}.json. Each fixture's body.input[0] is one {type:\"additional_tools\", role:\"developer\", tools:{functions:[...], collaboration:[...]}} item. Correction to the original design's blanket claim (\"no Anthropic tool shape maps to collaboration, genuinely unmappable\"): the collaboration bucket is not grammar-only. In all 4 fixtures it holds exactly two tools — exec (type:\"custom\", has a grammar string, no parameters) and request_review (no type tag, has a plain JSON-Schema parameters object, no grammar — structurally identical to a functions entry, just filed under the wrong bucket on the wire). Mappability is a per-tool fact keyed on presence of grammar, never inferable from which array a tool sits in.\n\nfunction_call.arguments is not guaranteed JSON: codex-request-tool-result-turn.json's function_call (call_id:\"call_synthetic_0001\", name:\"exec\") has arguments: \"ls -la\" — a bare string, since exec is grammar-typed. codexFallback.ts's parseFunctionArguments (line 466) throws today on exactly this input (JSON.parse(\"ls -la\") fails, hits catch, throws) — confirmed by reading the function. A tool-call IR part therefore needs argumentsRaw: string as the source of truth always, argumentsJson only when it happens to parse as an object.\n\nAll 4 fixtures: additional_tools is the single, first input item; 4 contiguous developer-role message items follow (indices 1-4); then 2 consecutive user-role message items (confirmed non-hypothetical — tool-result-turn's second user item carries an <environment_context> block, not a second real user turn); tool-result-turn additionally has one function_call/function_call_output pair. No fixture shows an assistant-role message item, even resumed-session. Top-level body keys across all 4: {model, stream, store, input} plus {session_id, thread_id} only on resumed-session — never top-level tools or reasoning.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"Grounding notes from the fixtures (all 4 read in full)","lvl3":""}},
@@ -10882,7 +10882,7 @@
 {"objectID":"da4c59d0b64ced4009b9a44e7b6c213b7e7d85158fcf74bba4a58772f8bbf3c5","title":"4. Part B — live matrix (Codex quota reset; both Anthropic [3 OAuth accounts] and Vertex live-callable)","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#4-part-b-live-matrix-codex-quota-reset-both-anthropic-3-oauth-accounts-and-vertex-live-callable","content":"Resolved framing (blocker, adopted): the review is correct that additional_tools.collaboration\ncarries exec on every live Codex CLI request (confirmed: store:false means every\nturn, including a resumed session and a mid-conversation tool-result turn, resends the\nidentical additional_tools block — there is no \"tool-free\" native Codex session). B1–B7\nbelow therefore do not validate a hypothetical tool-free subset; every one of them\ninherently exercises whichever policy Section 0 resolves to (drop/lossy-wrap/fail-closed),\nbecause exec rides along on every request regardless of what the human operator typed.\nEach scenario's pass criterion below adds an explicit clause for this. If the chosen policy\nis fail-closed (option c), every scenario B1–B7 will observe a clean, Codex-shaped\nclosed-fail at the translation step rather than a model response — that is a valid, expected\noutcome under that policy and must be asserted as such, not treated as an unexplained\nfailure. A live run against a real exec-bearing session, observing which of the two\noutcomes actually happens, is the only way to close UNRESOLVED-2 below.\n\n| #   | Model         | Target    | Scenario                                                                                                           | Pass criterion                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      ","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"4. Part B — live matrix (Codex quota reset; both Anthropic [3 OAuth accounts] and Vertex live-callable)","lvl3":""}},
 {"objectID":"864ca0b9722ca970f05f9d97d0fe4922d671c0783ce3e5290bcfdd507b7f65bd","title":"5. Part C — red-green discipline","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#5-part-c-red-green-discipline","content":"No telemetry exists yet at the current service_versions — run Part B scenarios 1–2 once\nagainst today's code first (force a Codex failure with no outbound fallback at all,\nconfirm the client simply sees a failure) and record the exact service_versions/timestamps\nreturned, rather than assuming a prior baseline exists.\n\n| #   | Behavior                                              | Defect to inject                                                                             | Where                                 | Expected failure without fix                                                                                                                                                                                                   |\n| --- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| 1   | Byte-stability (A.6)                                  | Embed Date.now() or a fresh id into the synthesized system/tools prefix                    | system-assembly step                  | A.6 byte-stability case fails                                                                                                                                                                                                  |\n| 2   | Cache marker placement (A.5)                          | Skip string→block-array promotion, emit system as a bare string                            | converter's system-shape choice       | applyClaudeRequestCacheBreakpoints places 0 markers (array-branch guard requires Array.isArray); A.5 promotion case fails                                                                                            ","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"5. Part C — red-green discipline","lvl3":""}},
 {"objectID":"f7fac43bfed8a1c9df20ae06397f4d5758acf069d0888e304900c2ae3a606320","title":"6. Dependencies on other sections / UNRESOLVED","url":"/docs/superpowers/specs/2026-09-27-codex-outbound-fallback-design#6-dependencies-on-other-sections-unresolved","content":"Exact translator names/types (convertCodexNativeRequestToClaude, CodexNativeRequestBody,\n  the functions/collaboration union) are proposed here for concreteness; owned by whichever\n  section designs the request-parsing/type layer (likely cache-codex-prefix). If it settles\n  on different names, only the symbol names here change — file placement, CI gating, the case\n  list, and the live-matrix scenarios are structural and independent of the exact names.\nAccount-affinity/session-pinning feeding a Codex-derived cache key into account selection —\n  confirmed sessionId parameter accepts an arbitrary string with no format validation, so\n  this plan's assumption is safe, but the hook itself belongs to cache-anthropic.\ncache_control TTL policy choice beyond straight reuse of applyClaudeRequestCacheBreakpoints\n  — likely cache-anthropic/cache-compaction.\nVertex-specific leg differences for scenario 5's account-label assertions — likely cache-vertex.\nThe actual trigger-policy gate function body, hop-depth mechanism, and routing-config key\n  name — likely cache-guardrails; this plan only names the test surface for it.\nAny new proxy_fallback_* observability labels — likely proxy-waste.\nUNRESOLVED-1: exact wire shape for a Codex reasoning output item (A.2) — see A.2 above; the\n  one check that would settle it is a live capture of a real reasoning-effort Codex turn.\nUNRESOLVED-2: whether the real ChatGPT Codex backend validates function_call.call_id\n  format server-side — the one check that would settle it is Part B scenario 4.\nUNRESOLVED-3: whether Section 0's policy choice ((a)/(b)/(c)) is fail-closed or lossy —\n  owned by the translator section; this plan's Part B framing is written to be correct under\n  either outcome, but the actual observed behavior (clean fail-closed vs. a live 400) is only\n  settled by running scenarios 1/3/4 once the translator lands.","hierarchy":{"lvl0":"Superpowers","lvl1":"Codex Outbound Fallback — Design","lvl2":"6. Dependencies on other sections / UNRESOLVED","lvl3":""}},
-{"objectID":"28a39199473cf2c61c15cd3a935a0539698770b87d0db0b52dca6387739180e0","title":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","url":"/docs/test-reports/final-comprehensive-test-report","content":"NeuroLink Universal AI Platform - Final Comprehensive Test Report\n\n⚠️ HISTORICAL DOCUMENT (August 2025)\nThis audit was conducted when NeuroLink shipped 9 providers. At audit time, v9.62.0 (May 2026) shipped 24 providers including DeepSeek, NVIDIA NIM, LM Studio, llama.cpp, plus voice (TTS/STT/realtime). References to \"9 providers\" or \"8/9 working\" in this file reflect the state at time of analysis.\nFor current capabilities see README on GitHub and Provider Capabilities Audit.\n\n🎯 Executive Summary\n\nTest Execution Completed: 2025-07-11T12:42:34.297Z  \nOverall Success Rate: 99.1% (319/322 tests passed)  \nTotal Execution Time: 1025.5 seconds (17.1 minutes)  \nTest Coverage: 100% (All 322 test cases executed)  \nStatus: ✅ COMPREHENSIVE TEST EXECUTION SUCCESSFUL\n\n📊 Overall Results\n\n| Metric               | Value   |\n| -------------------- | ------- |\n| Total Tests      | 322     |\n| Passed           | 319     |\n| Failed           | 3       |\n| Success Rate     | 99.1%   |\n| Execution Time   | 1025.5s |\n| Parallel Workers | 10      |\n\n🏆 Phase-by-Phase Performance\n\nPhase 1: Critical Priority Tests\nTests: 26\nSuccess Rate: 100%\nStatus: ✅ PERFECT\n\nPhase 2: High Priority Tests\nTests: 45\nSuccess Rate: 100%\nStatus: ✅ PERFECT\n\nPhase 3: Medium Priority Tests\nTests: 120\nSuccess Rate: 100%\nStatus: ✅ PERFECT\n\nPhase 4: Low Priority Tests\nTests: 139\nSuccess Rate: 97.8% (3 failures)\nStatus: ⚠️ MINOR ISSUES\n\n❌ Failed Test Analysis\n\nTest Failures (3 total)\nCLI-002.1.1 - Test timeout (Position 141/322)\nCLI-002.1.2 - Test timeout (Position 144/322)\nCLI-002.2.1 - Test timeout (Position 145/322)\n\nRoot Cause: All failures are timeout-related in CLI testing scenarios, likely due to:\nNetwork latency in provider response times\nCLI command execution overhead\nResource contention during parallel execution\n\nImpact: Minimal - Only affects 0.9% of test suite, all in low-priority category\n\n✅ Key Achievements\nPerfect Critical & High Priority Coverage: 100% success rate for all mission-critical functionality\nComprehensive Provider Testing: All 9 AI providers tested successfully\nParallel Execution Efficiency: 10-worker parallel execution completed in under 18 minutes\nEnvironment Fixes Applied: Resolved authentication and provider fallback issues\nFresh Execution Success: Clean restart achieved excellent results\n\n🔧 Technical Improvements Made\n\nPre-Execution Fixes\nEnvironment Variable Loading: Added dotenv configuration to test executor\nProvider Fallback Logic: Simplified provider selection to prevent unwanted fallbacks\nSDK-to-CLI Conversion: Enhanced test reliability by preferring CLI execution\nOllama Configuration: Updated to use breezehq.dev endpoint with proper model\n\nExecution Optimizations\nParallel execution with 10 concurrent workers\nReal-time progress tracking and monitoring\nComprehensive logging and result collection\nAutomatic retry mechanisms for transient failures\n\n📈 Performance Metrics\nAverage Test Duration: 3.2 seconds per test\nThroughput: ~19 tests per minute\nPeak Concurrency: 10 simultaneous tests\nResource Utilization: Optimal CPU and memory usage\n\n🎯 Provider Success Rates\n\n| Provider     | Status | Success Rate |\n| ------------ | ------ | ------------ |\n| OpenAI       | ✅     | 100%         |\n| Anthropic    | ✅     | 100%         |\n| Google AI    | ✅     | 100%         |\n| Vertex AI    | ✅     | 100%         |\n| AWS Bedrock  | ✅     | 100%         |\n| Azure OpenAI | ✅     | 100%         |\n| HuggingFace  | ✅     | 100%         |\n| Ollama       | ✅     | 100%         |\n| Mistral      | ✅     | 100%         |\n\n🔍 Quality Assessment\n\nEXCELLENT: The NeuroLink Universal AI Platform demonstrates exceptional stability and reliability:\n99.1% success rate exceeds industry standards\nZero critical or high-priority failures\nAll provider integrations functioning perfectly\nRobust error handling and fallback mechanisms\nComprehensive test coverage across all system components\n\n📋 Recommendations\n\nImmediate Actions\nTimeout Optimization: Review CLI timeout settings for the 3 failed tests\nMonitoring Enhancement: Implement production monitoring for timeout scenarios\n\nFuture Improvements\nLoad Testing: Add stress testing for high-concurrency scenarios\nPerformance Benchmarking: Establish baseline performance metrics\nAutomated Regression: Integrate into CI/CD pipeline\n\n📁 Test Artifacts\n\nExecution Log: comprehensive-test-execution-full.log  \nTracker File: TEST-EXECUTION-TRACKER.md  \nTest Results: test-executions/comprehensive-parallel/  \nConfiguration: execute-all-tests-parallel.js\n\nReport Generated: 2025-07-11T12:44:00.000Z  \nStatus: ✅ COMPREHENSIVE TEST EXECUTION SUCCESSFUL  \nNext Review: As needed for system updates","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"","lvl3":""}},
+{"objectID":"28a39199473cf2c61c15cd3a935a0539698770b87d0db0b52dca6387739180e0","title":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","url":"/docs/test-reports/final-comprehensive-test-report","content":"NeuroLink Universal AI Platform - Final Comprehensive Test Report\n\n⚠️ HISTORICAL DOCUMENT (August 2025)\nThis audit was conducted when NeuroLink shipped 9 providers. At audit time, v9.62.0 (May 2026) shipped 24 providers including DeepSeek, NVIDIA NIM, LM Studio, llama.cpp, plus voice (TTS/STT/realtime). References to \"9 providers\" or \"8/9 working\" in this file reflect the state at time of analysis.\nFor current capabilities see README on GitHub and Provider Capabilities Audit.\n\n🎯 Executive Summary\n\nTest Execution Completed: 2025-07-11T12:42:34.297Z  \nOverall Success Rate: 99.1% (319/322 tests passed)  \nTotal Execution Time: 1025.5 seconds (17.1 minutes)  \nTest Coverage: 100% (All 322 test cases executed)  \nStatus: ✅ COMPREHENSIVE TEST EXECUTION SUCCESSFUL\n\n📊 Overall Results\n\n| Metric               | Value   |\n| -------------------- | ------- |\n| Total Tests      | 322     |\n| Passed           | 319     |\n| Failed           | 3       |\n| Success Rate     | 99.1%   |\n| Execution Time   | 1025.5s |\n| Parallel Workers | 10      |\n\n🏆 Phase-by-Phase Performance\n\nPhase 1: Critical Priority Tests\nTests: 26\nSuccess Rate: 100%\nStatus: ✅ PERFECT\n\nPhase 2: High Priority Tests\nTests: 45\nSuccess Rate: 100%\nStatus: ✅ PERFECT\n\nPhase 3: Medium Priority Tests\nTests: 120\nSuccess Rate: 100%\nStatus: ✅ PERFECT\n\nPhase 4: Low Priority Tests\nTests: 139\nSuccess Rate: 97.8% (3 failures)\nStatus: ⚠️ MINOR ISSUES\n\n❌ Failed Test Analysis\n\nTest Failures (3 total)\nCLI-002.1.1 - Test timeout (Position 141/322)\nCLI-002.1.2 - Test timeout (Position 144/322)\nCLI-002.2.1 - Test timeout (Position 145/322)\n\nRoot Cause: All failures are timeout-related in CLI testing scenarios, likely due to:\nNetwork latency in provider response times\nCLI command execution overhead\nResource contention during parallel execution\n\nImpact: Minimal - Only affects 0.9% of test suite, all in low-priority category\n\n✅ Key Achievements\nPerfect Critical & High Priority Coverage: 100% success rate for all mission-critical functionality\nComprehensive Provider Testing: All 9 AI providers tested successfully\nParallel Execution Efficiency: 10-worker parallel execution completed in under 18 minutes\nEnvironment Fixes Applied: Resolved authentication and provider fallback issues\nFresh Execution Success: Clean restart achieved excellent results\n\n🔧 Technical Improvements Made\n\nPre-Execution Fixes\nEnvironment Variable Loading: Added dotenv configuration to test executor\nProvider Fallback Logic: Simplified provider selection to prevent unwanted fallbacks\nSDK-to-CLI Conversion: Enhanced test reliability by preferring CLI execution\nOllama Configuration: Updated to use a hosted Ollama endpoint with proper model\n\nExecution Optimizations\nParallel execution with 10 concurrent workers\nReal-time progress tracking and monitoring\nComprehensive logging and result collection\nAutomatic retry mechanisms for transient failures\n\n📈 Performance Metrics\nAverage Test Duration: 3.2 seconds per test\nThroughput: ~19 tests per minute\nPeak Concurrency: 10 simultaneous tests\nResource Utilization: Optimal CPU and memory usage\n\n🎯 Provider Success Rates\n\n| Provider     | Status | Success Rate |\n| ------------ | ------ | ------------ |\n| OpenAI       | ✅     | 100%         |\n| Anthropic    | ✅     | 100%         |\n| Google AI    | ✅     | 100%         |\n| Vertex AI    | ✅     | 100%         |\n| AWS Bedrock  | ✅     | 100%         |\n| Azure OpenAI | ✅     | 100%         |\n| HuggingFace  | ✅     | 100%         |\n| Ollama       | ✅     | 100%         |\n| Mistral      | ✅     | 100%         |\n\n🔍 Quality Assessment\n\nEXCELLENT: The NeuroLink Universal AI Platform demonstrates exceptional stability and reliability:\n99.1% success rate exceeds industry standards\nZero critical or high-priority failures\nAll provider integrations functioning perfectly\nRobust error handling and fallback mechanisms\nComprehensive test coverage across all system components\n\n📋 Recommendations\n\nImmediate Actions\nTimeout Optimization: Review CLI timeout settings for the 3 failed tests\nMonitoring Enhancement: Implement production monitoring for timeout scenarios\n\nFuture Improvements\nLoad Testing: Add stress testing for high-concurrency scenarios\nPerformance Benchmarking: Establish baseline performance metrics\nAutomated Regression: Integrate into CI/CD pipeline\n\n📁 Test Artifacts\n\nExecution Log: comprehensive-test-execution-full.log  \nTracker File: TEST-EXECUTION-TRACKER.md  \nTest Results: test-executions/comprehensive-parallel/  \nConfiguration: execute-all-tests-parallel.js\n\nReport Generated: 2025-07-11T12:44:00.000Z  \nStatus: ✅ COMPREHENSIVE TEST EXECUTION SUCCESSFUL  \nNext Review: As needed for system updates","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"","lvl3":""}},
 {"objectID":"9efef22578ee5bce54f82bb2792f3abadec2c2cd589f3d3e7a344d8f97452bcb","title":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","url":"/docs/test-reports/final-comprehensive-test-report#neurolink-universal-ai-platform---final-comprehensive-test-report","content":"⚠️ HISTORICAL DOCUMENT (August 2025)\nThis audit was conducted when NeuroLink shipped 9 providers. At audit time, v9.62.0 (May 2026) shipped 24 providers including DeepSeek, NVIDIA NIM, LM Studio, llama.cpp, plus voice (TTS/STT/realtime). References to \"9 providers\" or \"8/9 working\" in this file reflect the state at time of analysis.\nFor current capabilities see README on GitHub and Provider Capabilities Audit.","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl3":""}},
 {"objectID":"83a1048b43754bd7ff2d757e77d271214bc8a26295dedb913166858cbea14143","title":"🎯 Executive Summary","url":"/docs/test-reports/final-comprehensive-test-report#-executive-summary","content":"Test Execution Completed: 2025-07-11T12:42:34.297Z  \nOverall Success Rate: 99.1% (319/322 tests passed)  \nTotal Execution Time: 1025.5 seconds (17.1 minutes)  \nTest Coverage: 100% (All 322 test cases executed)  \nStatus: ✅ COMPREHENSIVE TEST EXECUTION SUCCESSFUL","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"🎯 Executive Summary","lvl3":""}},
 {"objectID":"2c92d72872d530a67fd3eadaa1f7dfd1b91c9e06d5144c13e8a10bc456d1c7c3","title":"📊 Overall Results","url":"/docs/test-reports/final-comprehensive-test-report#-overall-results","content":"| Metric               | Value   |\n| -------------------- | ------- |\n| Total Tests      | 322     |\n| Passed           | 319     |\n| Failed           | 3       |\n| Success Rate     | 99.1%   |\n| Execution Time   | 1025.5s |\n| Parallel Workers | 10      |","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"📊 Overall Results","lvl3":""}},
@@ -10892,7 +10892,7 @@
 {"objectID":"c2e0552b01a32e26c6fbc334e7f89aac3e5b8127f0c883c081f91e7b728f0add","title":"Phase 4: Low Priority Tests","url":"/docs/test-reports/final-comprehensive-test-report#phase-4-low-priority-tests","content":"Tests: 139\nSuccess Rate: 97.8% (3 failures)\nStatus: ⚠️ MINOR ISSUES","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"Phase 4: Low Priority Tests","lvl3":""}},
 {"objectID":"9e34ff6f5e35c7a4c0166ce3863c0199aa5e386238a8d9b02e7d5a9203688b42","title":"Test Failures (3 total)","url":"/docs/test-reports/final-comprehensive-test-report#test-failures-3-total","content":"CLI-002.1.1 - Test timeout (Position 141/322)\nCLI-002.1.2 - Test timeout (Position 144/322)\nCLI-002.2.1 - Test timeout (Position 145/322)\n\nRoot Cause: All failures are timeout-related in CLI testing scenarios, likely due to:\nNetwork latency in provider response times\nCLI command execution overhead\nResource contention during parallel execution\n\nImpact: Minimal - Only affects 0.9% of test suite, all in low-priority category","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"Test Failures (3 total)","lvl3":""}},
 {"objectID":"51ec4ef99fc5e5bb7d26fb1ba58225f13c979352285399c44b88d2fe4d4c086d","title":"✅ Key Achievements","url":"/docs/test-reports/final-comprehensive-test-report#-key-achievements","content":"Perfect Critical & High Priority Coverage: 100% success rate for all mission-critical functionality\nComprehensive Provider Testing: All 9 AI providers tested successfully\nParallel Execution Efficiency: 10-worker parallel execution completed in under 18 minutes\nEnvironment Fixes Applied: Resolved authentication and provider fallback issues\nFresh Execution Success: Clean restart achieved excellent results","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"✅ Key Achievements","lvl3":""}},
-{"objectID":"7430ed2f52dcd435bcdf2179965d9c978734e2a007b8014c23ac756dea3d8498","title":"Pre-Execution Fixes","url":"/docs/test-reports/final-comprehensive-test-report#pre-execution-fixes","content":"Environment Variable Loading: Added dotenv configuration to test executor\nProvider Fallback Logic: Simplified provider selection to prevent unwanted fallbacks\nSDK-to-CLI Conversion: Enhanced test reliability by preferring CLI execution\nOllama Configuration: Updated to use breezehq.dev endpoint with proper model","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"Pre-Execution Fixes","lvl3":""}},
+{"objectID":"7430ed2f52dcd435bcdf2179965d9c978734e2a007b8014c23ac756dea3d8498","title":"Pre-Execution Fixes","url":"/docs/test-reports/final-comprehensive-test-report#pre-execution-fixes","content":"Environment Variable Loading: Added dotenv configuration to test executor\nProvider Fallback Logic: Simplified provider selection to prevent unwanted fallbacks\nSDK-to-CLI Conversion: Enhanced test reliability by preferring CLI execution\nOllama Configuration: Updated to use a hosted Ollama endpoint with proper model","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"Pre-Execution Fixes","lvl3":""}},
 {"objectID":"108fdddb19a0cfb4b3796264bce773f1cbbeea2a26fb2a09e0b36a7985dc12c0","title":"Execution Optimizations","url":"/docs/test-reports/final-comprehensive-test-report#execution-optimizations","content":"Parallel execution with 10 concurrent workers\nReal-time progress tracking and monitoring\nComprehensive logging and result collection\nAutomatic retry mechanisms for transient failures","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"Execution Optimizations","lvl3":""}},
 {"objectID":"4d067b1b2eaa1d19e532969a75a2cf0b87e7a0c9cba1a3b884bfb24614a64894","title":"📈 Performance Metrics","url":"/docs/test-reports/final-comprehensive-test-report#-performance-metrics","content":"Average Test Duration: 3.2 seconds per test\nThroughput: ~19 tests per minute\nPeak Concurrency: 10 simultaneous tests\nResource Utilization: Optimal CPU and memory usage","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"📈 Performance Metrics","lvl3":""}},
 {"objectID":"57ef349093203e747b428ff35f72c3fc0e055ad64f5915774210ce95a6f2f441","title":"🎯 Provider Success Rates","url":"/docs/test-reports/final-comprehensive-test-report#-provider-success-rates","content":"| Provider     | Status | Success Rate |\n| ------------ | ------ | ------------ |\n| OpenAI       | ✅     | 100%         |\n| Anthropic    | ✅     | 100%         |\n| Google AI    | ✅     | 100%         |\n| Vertex AI    | ✅     | 100%         |\n| AWS Bedrock  | ✅     | 100%         |\n| Azure OpenAI | ✅     | 100%         |\n| HuggingFace  | ✅     | 100%         |\n| Ollama       | ✅     | 100%         |\n| Mistral      | ✅     | 100%         |","hierarchy":{"lvl0":"Test Reports","lvl1":"NeuroLink Universal AI Platform - Final Comprehensive Test Report","lvl2":"🎯 Provider Success Rates","lvl3":""}},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juspay/neurolink",
-  "version": "12.36.0",
+  "version": "12.37.0",
   "packageManager": "pnpm@10.15.1",
   "description": "The pipe layer of an AI nervous system: one interface connecting provider neurons to your application, across three inference types — generate, stream and decide. `decide` returns typed, calibrated judgements from a non-generative model (~400ms, ~$0.00002/call) for routing, tool selection and context budgeting. MCP-native (4 transports), voice TTS/STT/realtime, RAG, agents, memory, compaction, 9 observability exporters. OpenAI · Anthropic · Gemini · Bedrock · Azure · Ollama · TypeSafe Jev and more.",
   "author": {