docs/tutorials.md:131

• The section header renders as ## �🌐 Web App Integration (replacement character), which indicates a file encoding/copy-paste issue. Also, the Express example reads req.body.prompt but does not call app.use(express.json()), so req.body will be undefined for JSON requests. Fix the header text and add the JSON body middleware in the snippet.

## �🌐 Web App Integration

### Express.js API

```javascript
const express = require("express");
const { NeuroLink } = require("@juspay/neurolink");
const app = express();
const neurolink = new NeuroLink();

app.post("/api/generate", async (req, res) => {
  const result = await neurolink.generate({
    input: { text: req.body.prompt },
    enableAnalytics: true,

docs/tutorials.md-122-127 (1)

122-127: ⚠️ Potential issue | 🟠 Major

Missing express.json() middleware breaks the example.

The Express.js example accesses req.body.prompt (line 130) but lacks app.use(express.json()) to parse incoming JSON. Users copying this snippet will get undefined for req.body.

Proposed fix

 const express = require("express");
 const { NeuroLink } = require("@juspay/neurolink");
 const app = express();
+app.use(express.json());
 const neurolink = new NeuroLink();

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/tutorials.md` around lines 122 - 127, The example is missing the Express
JSON body-parsing middleware so req.body.prompt will be undefined; add the
middleware by calling app.use(express.json()) after creating the app (after
const app = express()) so incoming JSON is parsed before handlers that access
req.body.prompt and any routes that use the neurolink instance.

test/unit/processors/output/toxicityCheck.test.ts-9-14 (1)

9-14: ⚠️ Potential issue | 🟠 Major

Switch internal type imports to the canonical src/lib/types barrel.

Direct import from ioProcessor.js in a non-src/lib/types file violates the project’s type import rule.

🔧 Proposed fix

 import type {
   InputProcessorData,
   OutputProcessorData,
   ProcessorMetadata,
   ToxicityCheckConfig,
-} from "../../../../src/lib/types/ioProcessor.js";
+} from "../../../../src/lib/types/index.js";

As per coding guidelines: “Code outside src/lib/types/ must import internal types from the barrel (../types/index.js or ../types), never from specific type files.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/processors/output/toxicityCheck.test.ts` around lines 9 - 14, The
test file imports internal types directly from ioProcessor.js; update the import
to use the canonical barrel export instead. Replace the direct import of
InputProcessorData, OutputProcessorData, ProcessorMetadata, ToxicityCheckConfig
from "../../../../src/lib/types/ioProcessor.js" with an import from the types
barrel (e.g., "../../../../src/lib/types" or
"../../../../src/lib/types/index.js") so the test references the same exported
types via the central barrel.

test/unit/processors/input/piiDetection.test.ts-9-14 (1)

9-14: ⚠️ Potential issue | 🟠 Major

Use the canonical type barrel import instead of direct ioProcessor type-file import.

This test imports internal types from a specific file path, which breaks the repository’s type-import boundary rule for non-src/lib/types files.

🔧 Proposed fix

 import type {
   InputProcessorData,
   PIIDetectionConfig,
   ProcessorMetadata,
-} from "../../../../src/lib/types/ioProcessor.js";
+} from "../../../../src/lib/types/index.js";

As per coding guidelines: “Code outside src/lib/types/ must import internal types from the barrel (../types/index.js or ../types), never from specific type files.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/processors/input/piiDetection.test.ts` around lines 9 - 14, The
test imports internal types InputProcessorData, PIIDetectionConfig, and
ProcessorMetadata directly from the ioProcessor type file; change the import to
use the canonical types barrel (the src/lib/types index export) instead of the
specific ioProcessor.js file so the test follows the repo's type-import boundary
rule and still imports InputProcessorData, PIIDetectionConfig, and
ProcessorMetadata from the barrel.

test/processors/integration.test.ts-15-23 (1)

15-23: ⚠️ Potential issue | 🟠 Major

Type imports should come from src/lib/types barrel, not src/lib/processors/types.js.

This path bypasses the canonical type boundary and should be switched to the central types barrel import.

🔧 Proposed fix

 import type {
   InputProcessor,
   OutputProcessor,
   InputProcessorData,
   OutputProcessorData,
   ProcessorMetadata,
   ProcessorResult,
-} from "../../src/lib/processors/types.js";
+} from "../../src/lib/types/index.js";

As per coding guidelines: “Code outside src/lib/types/ must import internal types from the barrel (../types/index.js or ../types), never from specific type files.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/processors/integration.test.ts` around lines 15 - 23, The test is
importing internal types directly from "../../src/lib/processors/types.js" which
bypasses the canonical types barrel; update the import to come from the central
barrel (e.g., "../../src/lib/types" or "../../src/lib/types/index.js") and
import the same symbols InputProcessor, OutputProcessor, InputProcessorData,
OutputProcessorData, ProcessorMetadata, ProcessorResult so the test uses the
approved canonical type boundary.

src/lib/processors/input/piiDetectionProcessor.ts-146-154 (1)

146-154: ⚠️ Potential issue | 🟠 Major

Track matches per source field before redacting.

detectedPII positions are computed against the concatenated textToScan, then reused against data.text and every individual message. Those offsets do not map back to the original strings, so multi-message inputs will miss redactions and can also replace unrelated slices in earlier fields.

Please either detect/redact per field, or store the source plus field-local offsets when building detectedPII.

Also applies to: 226-249

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/input/piiDetectionProcessor.ts` around lines 146 - 154,
The current PII detection builds a single concatenated text (textToScan) and
populates detectedPII offsets against that concatenation, then applies those
offsets back to data.text and each message, which misaligns offsets across
fields; update the logic in piiDetectionProcessor (references: detectedPII,
textToScan, data.text, data.messages) to either (a) run detection separately for
each source field—compute and redact PII per field using field-local offsets—or
(b) when detecting over the concatenated text, record the source identifier and
the field-local start/end for each DetectedPII (e.g., include a
sourceField/messageIndex and local offsets) and use those to apply redactions
back to the correct field; apply the same fix to the later block around the
other occurrence (lines ~226-249) so offsets always map to their original source
before replacing.

src/lib/processors/presets.ts-261-275 (1)

261-275: ⚠️ Potential issue | 🟠 Major

Avoid exposing live mutable preset references.

builtInPresets and getPreset() currently hand out the shared preset objects. Any consumer that tweaks the returned config mutates the global defaults for every later pipeline/test in the same process.

Please return cloned presets and avoid exporting a directly mutable preset array.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/presets.ts` around lines 261 - 275, The builtInPresets
array currently exposes live mutable objects (builtInPresets, defaultPreset,
securityPreset, strictPreset, qualityPreset, minimalPreset) and getPreset(name)
returns references that callers can mutate; stop exporting the raw array and
return cloned presets instead: make the internal array non-exported (or freeze
it) and change getPreset to locate the preset by name from the internal list but
return a deep clone (use structuredClone or your existing deepClone utility) of
the ProcessorPreset before returning; similarly, if you must export a list,
expose a function like listPresets() that returns clones rather than exporting
builtInPresets directly.

src/lib/processors/output/memoryPersistenceProcessor.ts-205-248 (1)

205-248: ⚠️ Potential issue | 🟠 Major

Do not report successful persistence while the store is still a no-op.

storeConversationTurn() currently does nothing, but the caller treats it as a successful write and returns memoryPersisted: true. That means this built-in processor silently drops conversation history while telling consumers it was saved.

Until this is wired to the real memory managers, it should surface skipped/not implemented semantics instead of success.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/output/memoryPersistenceProcessor.ts` around lines 205 -
248, storeConversationTurn currently no-ops but returns success to callers;
change it to surface "not implemented/skipped" semantics by rejecting the
promise with a clear error instead of resolving. Modify the body of
storeConversationTurn to return Promise.reject(new Error('Memory persistence not
implemented: in-memory/redis managers not wired')) (or throw the same Error) so
callers that await storeConversationTurn (e.g., code that sets memoryPersisted)
will see a failure and can mark the operation as skipped; keep the function name
storeConversationTurn and preserve the existing signature.

test/unit/processors/registry.test.ts-9-13 (1)

9-13: 🛠️ Refactor suggestion | 🟠 Major

Import internal processor types from the barrel.

This test pulls internal types from src/lib/types/ioProcessor.js instead of the canonical barrel. Please switch this to src/lib/types/index.js so the test stays aligned with the repo’s type-import boundary.

Proposed change

 import type {
   InputProcessor,
   OutputProcessor,
   ProcessorPreset,
-} from "../../../src/lib/types/ioProcessor.js";
+} from "../../../src/lib/types/index.js";

As per coding guidelines, !(src/lib/types)/**/*.ts: Code outside src/lib/types/ must import internal types from the barrel (../types/index.js or ../types), never from specific type files (../types/rag.js, ../types/mcp.js).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/processors/registry.test.ts` around lines 9 - 13, The test imports
internal types InputProcessor, OutputProcessor, and ProcessorPreset directly
from ioProcessor.js; update the import to use the types barrel (the exported
index for src/lib/types) instead of the specific file so the test follows the
repo's type-import boundary — replace the module specifier for the existing
import of InputProcessor, OutputProcessor, ProcessorPreset to import them from
the types barrel (the index export of src/lib/types) while keeping the same
named type imports.

test/unit/processors/tripwire.test.ts-17-22 (1)

17-22: 🛠️ Refactor suggestion | 🟠 Major

Import internal tripwire types from the barrel.

This test reaches into src/lib/types/ioProcessor.js directly. Please switch it to the canonical src/lib/types/index.js barrel to stay within the repo’s internal type-import contract.

Proposed change

 import type {
   InputProcessorData,
   OutputProcessorData,
   ProcessorMetadata,
   TripwireConfig,
-} from "../../../src/lib/types/ioProcessor.js";
+} from "../../../src/lib/types/index.js";

As per coding guidelines, !(src/lib/types)/**/*.ts: Code outside src/lib/types/ must import internal types from the barrel (../types/index.js or ../types), never from specific type files (../types/rag.js, ../types/mcp.js).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/processors/tripwire.test.ts` around lines 17 - 22, The test imports
internal types (InputProcessorData, OutputProcessorData, ProcessorMetadata,
TripwireConfig) directly from a specific type module; change the import to use
the repository's types barrel (the types index/barrel) instead of the specific
ioProcessor module so the test imports those symbols from the canonical barrel
export; update the import statement in tripwire.test.ts to reference the central
types barrel export and keep the same type names.

src/lib/processors/input/piiDetectionProcessor.ts-181-186 (1)

181-186: ⚠️ Potential issue | 🟠 Major

Validate custom regex patterns for type and safety before execution.

customPatterns are executed directly without runtime validation. Although the type definition declares pattern: RegExp, TypeScript doesn't enforce this at runtime. Non-RegExp values will cause detectPIIWithPattern to fail when accessing .source and .flags. Additionally, unchecked regex patterns can exhibit catastrophic backtracking on large prompts.

Add explicit type validation and reject patterns with nested quantifiers. The codebase already implements similar checks in customScorerUtils.ts and autoresearch/config.ts—use the same pattern: (/(\+|\*|\{)\S*(\+|\*|\{)/) to detect nested quantifiers.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/input/piiDetectionProcessor.ts` around lines 181 - 186,
Validate each custom pattern before calling detectPIIWithPattern: in the loop
over customPatterns (the block creating `detected =
detectPIIWithPattern(textToScan, custom.name, custom.pattern)`), first confirm
`custom.pattern` is an actual RegExp (e.g., instanceof RegExp) and if not,
skip/log an error; then test the pattern's source for nested quantifiers using
the same check used elsewhere (/(\+|\*|\{)\S*(\+|\*|\{)/) and skip/log/reject
any pattern that matches to avoid catastrophic backtracking; only pass safe,
validated RegExp objects into detectPIIWithPattern.

src/lib/processors/output/lengthValidationProcessor.ts-82-90 (1)

82-90: ⚠️ Potential issue | 🟠 Major

Guard retryCount reads when metadata is absent.

Both retry branches dereference data.metadata.custom.retryCount, but this processor is publicly callable with bare OutputProcessorData and the example in this file does exactly that. With action: "retry", this throws before returning a processor result.

🛠️ Proposed fix

-          const currentRetry = (data.metadata.custom.retryCount as number) || 0;
+          const currentRetry = Number(data.metadata?.custom?.retryCount ?? 0);
...
-          const currentRetry = (data.metadata.custom.retryCount as number) || 0;
+          const currentRetry = Number(data.metadata?.custom?.retryCount ?? 0);

Also applies to: 146-154

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/output/lengthValidationProcessor.ts` around lines 82 - 90,
The code dereferences data.metadata.custom.retryCount in the retry branches
(variables: action, data, metadata, custom, retryCount, maxRetries) which will
throw when metadata is absent; update the length validation processor (e.g.,
lengthValidationProcessor/handler) to safely read retryCount using optional
chaining and a numeric fallback (e.g., const currentRetry =
Number(data?.metadata?.custom?.retryCount) || 0) and do the same in the other
retry branch (the one around lines 146-154) so both branches never throw when
metadata or custom is undefined and still increment retryCount properly.

src/lib/processors/output/lengthValidationProcessor.ts-122-125 (1)

122-125: ⚠️ Potential issue | 🟠 Major

Clamp truncation so the result never exceeds maxLength.

If maxLength is smaller than truncationSuffix.length, the current slice() call gets a negative end index and can return a string longer than the configured maximum.

✂️ Proposed fix

-          const truncatedText =
-            responseText.slice(0, maxLength - truncationSuffix.length) +
-            truncationSuffix;
+          const suffix = truncationSuffix.slice(0, maxLength);
+          const keepLength = Math.max(maxLength - suffix.length, 0);
+          const truncatedText = responseText.slice(0, keepLength) + suffix;
...
-          const truncatedText =
-            responseText.slice(0, maxLength - truncationSuffix.length) +
-            truncationSuffix;
+          const suffix = truncationSuffix.slice(0, maxLength);
+          const keepLength = Math.max(maxLength - suffix.length, 0);
+          const truncatedText = responseText.slice(0, keepLength) + suffix;

Also applies to: 158-160

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/output/lengthValidationProcessor.ts` around lines 122 -
125, The truncate branch can produce output longer than maxLength when
truncationSuffix.length > maxLength; in the action === "truncate" block compute
a clamped slice length (e.g., clampLength = Math.max(0, maxLength -
truncationSuffix.length)) and use responseText.slice(0, clampLength) +
truncationSuffix so the final string never exceeds maxLength; apply the same
clamp fix to the other truncate occurrence in this file (the second
truncatedText computation).

src/lib/processors/input/contentModerationProcessor.ts-132-138 (1)

132-138: ⚠️ Potential issue | 🟠 Major

Handle simplified input without messages.

data.messages.filter(...) assumes the array is always present. Other processors in this PR already treat messages as optional, so text-only calls can throw here before moderation starts.

🛠️ Proposed fix

-      const messageTexts = data.messages
+      const messageTexts = (data.messages ?? [])
         .filter((m) => m.role === "user")
         .map((m) => m.content)
         .join("\n");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/input/contentModerationProcessor.ts` around lines 132 -
138, The code assumes data.messages exists and calls data.messages.filter(...)
which throws for text-only inputs; update the logic that builds textToScan so it
safely handles missing or non-array messages (e.g., treat messages as an empty
array when absent). Modify the section that defines messageTexts and textToScan
(the symbols messageTexts and textToScan in contentModerationProcessor) to use a
guarded/messages fallback (or Array.isArray check) before .filter/.map/.join so
text-only calls proceed without error.

src/lib/processors/output/toxicityCheckProcessor.ts-169-178 (1)

169-178: ⚠️ Potential issue | 🟠 Major

Guard retryCount access in the retry path.

data.metadata.custom.retryCount will throw whenever upstream metadata does not initialize custom, so action: "retry" is not actually safe for direct processor use.

🛠️ Proposed fix

-          const currentRetry = (data.metadata.custom.retryCount as number) || 0;
+          const currentRetry = Number(data.metadata?.custom?.retryCount ?? 0);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/output/toxicityCheckProcessor.ts` around lines 169 - 178,
The retry path reads data.metadata.custom.retryCount directly which can throw if
metadata.custom is undefined; update the logic in the retry branch (where action
=== "retry" and currentRetry is computed) to safely access retryCount using
optional chaining or a guarded lookup (e.g., const currentRetry =
((data.metadata && data.metadata.custom && data.metadata.custom.retryCount) as
number) || 0 or initialize data.metadata.custom before reading), and ensure
retryCount, retryCount + 1, and maxRetries are returned consistently so
processors like toxicityCheckProcessor's retry branch never access
data.metadata.custom without first checking/creating it.

src/lib/processors/input/contentModerationProcessor.ts-383-418 (1)

383-418: ⚠️ Potential issue | 🟠 Major

Honor categories in the heuristic fallback.

performHeuristicModeration() ignores the requested category list and always scores violence/harassment. If AI moderation is disabled or unavailable, this can block content for categories the caller did not enable.

🛠️ Proposed fix

-async function performHeuristicModeration(
-  text: string,
-  _categories: ModerationCategory[],
-): Promise<AIModerationResult> {
+async function performHeuristicModeration(
+  text: string,
+  categories: ModerationCategory[],
+): Promise<AIModerationResult> {
   const lowerText = text.toLowerCase();
   let score = 0;
   const flaggedCategories: string[] = [];
   const categoryScores: Record<string, number> = {};

   // Simple heuristics (these serve as a fallback when AI moderation fails)
   const violenceIndicators = ["kill", "murder", "attack", "destroy", "hurt"];
   const harassmentIndicators = ["stupid", "idiot", "dumb", "hate you"];

-  const violenceMatches = violenceIndicators.filter((w) =>
-    lowerText.includes(w),
-  );
-  if (violenceMatches.length > 0) {
+  if (categories.includes("violence")) {
+    const violenceMatches = violenceIndicators.filter((w) =>
+      lowerText.includes(w),
+    );
+    if (violenceMatches.length > 0) {
       const violenceScore = Math.min(0.3 * violenceMatches.length, 1.0);
       score = Math.max(score, violenceScore);
       categoryScores["violence"] = violenceScore;
       if (violenceScore > 0.5) {
         flaggedCategories.push("violence");
       }
     }
   }

-  const harassmentMatches = harassmentIndicators.filter((w) =>
-    lowerText.includes(w),
-  );
-  if (harassmentMatches.length > 0) {
+  if (categories.includes("harassment")) {
+    const harassmentMatches = harassmentIndicators.filter((w) =>
+      lowerText.includes(w),
+    );
+    if (harassmentMatches.length > 0) {
       const harassmentScore = Math.min(0.2 * harassmentMatches.length, 1.0);
       score = Math.max(score, harassmentScore);
       categoryScores["harassment"] = harassmentScore;
       if (harassmentScore > 0.5) {
         flaggedCategories.push("harassment");
       }
     }
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/input/contentModerationProcessor.ts` around lines 383 -
418, performHeuristicModeration currently ignores the _categories parameter and
always evaluates violence/harassment; update the function to respect the
requested categories by only running the violenceIndicators block when
_categories contains the "violence" category and only running the
harassmentIndicators block when _categories contains the "harassment" category
(use a case-insensitive check or match against the ModerationCategory enum
values), and only add entries to categoryScores and flaggedCategories for those
enabled categories so the heuristic fallback only flags categories the caller
requested.

src/lib/processors/output/responseValidationProcessor.ts-125-137 (1)

125-137: ⚠️ Potential issue | 🟠 Major

Retry mode assumes metadata.custom always exists.

data.metadata.custom.retryCount will throw when this processor is used directly with bare OutputProcessorData or when upstream metadata omits custom. That makes retryOnFailure unusable in those cases.

🛠️ Proposed fix

-        const currentRetry = (data.metadata.custom.retryCount as number) || 0;
+        const currentRetry = Number(data.metadata?.custom?.retryCount ?? 0);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/output/responseValidationProcessor.ts` around lines 125 -
137, The code assumes data.metadata.custom always exists and will throw when
metadata or custom is undefined; change the access to use safe checks/optional
chaining and defaults (e.g., const currentRetry = ((data.metadata?.custom as
any)?.retryCount as number) || 0) and when returning the retry action ensure you
do not rely on missing objects (either include retryCount/maxRetries in the
returned object only or create/clone metadata.custom before mutating), and make
the same defensive checks around any other metadata.custom accesses in the
responseValidationProcessor (reference symbols: data.metadata.custom.retryCount,
retryOnFailure, maxRetries, OutputProcessorData).

src/lib/processors/input/messageValidationProcessor.ts-74-95 (1)

74-95: ⚠️ Potential issue | 🟠 Major

requireContent rejects message-only input.

This branch only inspects workingData.text. Calls that supply chat messages without a top-level text field will abort as empty even when user messages contain content.

🛠️ Proposed fix

       if (requireContent) {
-        const trimmedText =
-          typeof workingData.text === "string" ? workingData.text.trim() : "";
-        if (trimmedText.length === 0) {
+        const hasText =
+          typeof workingData.text === "string" &&
+          workingData.text.trim().length > 0;
+        const hasMessageContent = messages.some((message) =>
+          typeof message.content === "string"
+            ? message.content.trim().length > 0
+            : Array.isArray(message.content) && message.content.length > 0,
+        );
+        if (!hasText && !hasMessageContent) {
           return {
             action: "abort",
             feedback: "Message content is empty",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/input/messageValidationProcessor.ts` around lines 74 - 95,
The validation branch using requireContent currently only checks
workingData.text and wrongly aborts when top-level text is absent but chat-style
workingData.messages contains user content; update the requireContent check (in
messageValidationProcessor) to first trim and inspect workingData.text as before
but if empty/absent also scan workingData.messages (an array) for any message
objects with non-empty content (e.g., message.content, message.text, or nested
content fields) and treat that as satisfying content; only return the same abort
object when both the top-level text and all messages are empty or missing.

src/lib/processors/utils/validationUtils.ts-58-155 (1)

58-155: ⚠️ Potential issue | 🟠 Major

validateJsonSchema() accepts invalid structured payloads.

This validator treats null as an "object" and never descends into properties or items, so schemas like { type: "object", properties: { ... } } can pass responses that do not actually match the supplied schema. responseValidationProcessor will then report false positives for structured-output checks.

🛠️ Proposed direction

-    const actualType = Array.isArray(data) ? "array" : typeof data;
+    const actualType =
+      data === null ? "null" : Array.isArray(data) ? "array" : typeof data;
...
+  if (schema.properties && isJsonObject(data)) {
+    for (const [key, propertySchema] of Object.entries(schema.properties)) {
+      errors.push(
+        ...validateJsonSchema(
+          data[key],
+          propertySchema as JsonObject,
+        ).map((error) => `${key}: ${error}`),
+      );
+    }
+  }
+
+  if (schema.items && Array.isArray(data)) {
+    data.forEach((item, index) => {
+      errors.push(
+        ...validateJsonSchema(item, schema.items as JsonObject).map(
+          (error) => `[${index}]: ${error}`,
+        ),
+      );
+    });
+  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/utils/validationUtils.ts` around lines 58 - 155,
validateJsonSchema incorrectly treats null as an object and doesn't validate
nested schemas (properties/items), allowing structured payloads to slip through;
update validateJsonSchema to (1) treat null as its own type (so if schema.type
=== "object" require isJsonObject(data) && data !== null), (2) when schema.type
is "object" or schema.properties is present, descend into schema.properties and
validate each owned property recursively using validateJsonSchema for property
values (use isJsonObject to guard), and (3) when schema.type is "array" or
schema.items is present, validate each element against schema.items recursively;
ensure enum/min/max/length checks still apply at the appropriate primitive
levels and that you reference the existing function name validateJsonSchema, the
schema keys properties and items, and helper isJsonObject when adding these
checks.

src/lib/neurolink.ts-12674-12744 (1)

12674-12744: ⚠️ Potential issue | 🟠 Major

setProcessorsEnabled(false) currently doesn't disable processing.

processInput() and processOutput() only check whether a pipeline exists. Once a pipeline has been created, these methods keep executing processors even after the public toggle is set to false, so the enable/disable API is ineffective.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/neurolink.ts` around lines 12674 - 12744, processInput and
processOutput only check for sdkProcessorPipeline and ignore the
sdkProcessorsEnabled flag, so calling setProcessorsEnabled(false) doesn't stop
processing; update both processInput and processOutput to short-circuit when
this.sdkProcessorsEnabled is false (return the same default
ProcessorPipelineResult shape with processorsExecuted: 0 and preserved
metadataOverrides) before checking/using this.sdkProcessorPipeline, referencing
the methods areProcessorsEnabled, setProcessorsEnabled, processInput,
processOutput and the fields sdkProcessorsEnabled and sdkProcessorPipeline to
locate the logic to change.

src/lib/neurolink.ts-1112-1120 (1)

1112-1120: ⚠️ Potential issue | 🟠 Major

Fail fast on unknown presets in the constructor.

If buildFromPreset() returns undefined, this path still enables processors and creates an empty pipeline. A typo in a safety preset would silently disable the intended guards. Please validate the preset here the same way setProcessorPreset() does.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/neurolink.ts` around lines 1112 - 1120, The constructor currently
calls processorDefaultRegistry.buildFromPreset(config.processors.preset) and
always assigns this.sdkProcessorPipeline = new ProcessorPipeline(...), which
allows unknown presets to silently produce an empty pipeline; replicate the
validation used in setProcessorPreset(): check the return value of
processorDefaultRegistry.buildFromPreset(config.processors.preset) and if it is
undefined or falsy, throw a descriptive error (or call the same validation
helper used by setProcessorPreset()) instead of creating a ProcessorPipeline,
otherwise proceed to construct this.sdkProcessorPipeline with
built.inputProcessors and built.outputProcessors.

src/lib/neurolink.ts-1108-1125 (1)

1108-1125: ⚠️ Potential issue | 🟠 Major

Processor config is not applied to normal generate() / stream() calls.

This class stores the pipeline and exposes manual processInput() / processOutput() helpers, but the request lifecycle never invokes them. As written, config.processors.enabled / preset has no effect on normal SDK generation or streaming, which makes the new constructor config misleading. Based on learnings, src/lib/neurolink.ts is the main SDK entry point that orchestrates all components.

Also applies to: 12682-12744

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/neurolink.ts` around lines 1108 - 1125, The configured processor
pipeline isn't being applied because generate() and stream() never invoke the
stored pipeline; update the request lifecycle in the Neurolink class so that
when sdkProcessorsEnabled is true you run
this.sdkProcessorPipeline.processInput(...) (or the existing processInput
helper) to transform inputs before sending requests and run
this.sdkProcessorPipeline.processOutput(...) (or processOutput helper) on
responses/each streamed chunk before returning/streaming to callers;
specifically, modify the generate and stream methods to branch on
this.sdkProcessorsEnabled / this.sdkProcessorPipeline and call the pipeline
before the network call and after receiving the result (including streaming
chunks), preserving existing error handling and keeping behavior when no
processors are configured.

src/lib/neurolink.ts-12619-12621 (1)

12619-12621: ⚠️ Potential issue | 🟠 Major

Avoid mutating the global registry from instance methods.

getProcessorRegistry() exposes the singleton processorDefaultRegistry, and addInputProcessor() / addOutputProcessor() mutate it with replace: true. Registering a processor on one NeuroLink instance can therefore alter presets and processor resolution for every other instance in the same process.

Also applies to: 12647-12670

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/neurolink.ts` around lines 12619 - 12621, The method
getProcessorRegistry() currently returns the global processorDefaultRegistry,
causing instance methods like addInputProcessor() and addOutputProcessor() to
mutate this shared singleton, which affects all NeuroLink instances. To fix
this, modify NeuroLink to maintain its own instance-specific ProcessorRegistry
instead of referencing the global one. Change getProcessorRegistry() to return
this instance-specific registry, and update addInputProcessor() and
addOutputProcessor() to modify only the instance registry without altering the
global singleton.

src/lib/processors/input/semanticContextProcessor.ts-235-261 (1)

235-261: ⚠️ Potential issue | 🟠 Major

semantic-context is currently a no-op.

searchSemanticContext() always returns an empty array, so this built-in processor never enriches the request regardless of vectorStore, embedFunction, topK, or namespace. Because the processor is exported and registered as part of the feature, users will get silent pass-through behavior instead of semantic context retrieval. Please either wire this to a real/injected search implementation or fail fast when semantic search is configured but unavailable.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/input/semanticContextProcessor.ts` around lines 235 - 261,
searchSemanticContext currently returns [] regardless of configuration causing
silent no-op; update it to detect when semantic search is requested (inspect
SemanticContextConfig.vectorStore, embedFunction, topK, namespace) and either
call an injected search handler (e.g. a provided config.searchFunction or DI
client) to produce SearchResult[] using the embedFunction/default embedding and
vector store query, or throw a clear error when a vector store is configured but
no search client is available; ensure the function returns mapped SearchResult
objects (text, score, metadata) and fails fast if required capabilities are
missing.

src/lib/processors/pipeline.ts-270-289 (1)

270-289: ⚠️ Potential issue | 🟠 Major

stopOnAbort is ignored for normal processor aborts.

Both input and output paths return immediately on result.action === "abort", so stopOnAbort: false only changes exception handling. A processor-requested abort can never be bypassed, which makes the setting misleading and prevents the non-short-circuit mode from working as configured.

Also applies to: 462-481

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/pipeline.ts` around lines 270 - 289, The pipeline
currently short-circuits on any processor-requested abort (result.action ===
"abort") regardless of the stopOnAbort flag; update the abort handling in the
input and output processor blocks (the branches that check result.action ===
"abort", processorsExecuted, and logger.debug) to honor stopOnAbort: if
stopOnAbort is true, return immediately as now, but if stopOnAbort is false, do
not return—accumulate result.feedback into feedback, update processorsExecuted
and currentData.metadata.issues/metadata as needed, log the abort, and continue
processing remaining processors (or set a non-short-circuit aborted marker in
currentData.metadata) so the pipeline does not short-circuit while still
recording the abort event.

src/lib/processors/utils/processorFactory.ts-204-241 (1)

204-241: ⚠️ Potential issue | 🟠 Major

Exhausted retries can still return action: "retry".

If the wrapped processor keeps returning retry, the loop exits and returns lastResult, which is still a retry result. That means the caller can keep retrying forever even though this wrapper has already exhausted maxRetries. The final exhausted retry needs to be converted into an abort.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/utils/processorFactory.ts` around lines 204 - 241, The
loop can exit with lastResult.action === "retry" so ensure exhausted retries
produce an abort: when calling processor.process (in the for loop that uses
maxRetries, retryDelay and processor.process) if you receive a result with
action "retry" and you're at the final attempt (attempt === maxRetries)
convert/return an abort result (include processor.id in feedback and an issues
array similar to the catch branch); also after the loop, if lastResult exists
and lastResult.action === "retry", replace it with a constructed abort object
(feedback mentioning processor.id and retries exhausted and an issues entry)
before returning.

src/lib/processors/pipeline.ts-592-615 (1)

592-615: ⚠️ Potential issue | 🟠 Major

Provider/model-gated processors still run when metadata is missing.

checkConditions() only rejects providers/models when metadata.provider / metadata.model is present. If the caller omits those fields entirely, the condition passes and the processor executes anyway. That defeats provider/model scoping for calls that do not populate metadata up front.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/pipeline.ts` around lines 592 - 615, checkConditions
currently lets processors run when conditions.providers or conditions.models are
specified but metadata.provider or metadata.model is missing; update
checkConditions (in class using ProcessorConditions and ProcessorMetadata) so
that if conditions.providers exists the function returns false unless
metadata.provider is present and included in conditions.providers, and likewise
if conditions.models exists require metadata.model to be present and included in
conditions.models; keep the custom condition check (conditions.custom(metadata))
as-is. Ensure you reference the symbols conditions.providers, conditions.models,
metadata.provider, metadata.model and the method checkConditions when making the
change.

test/processors/integration/io-processors.integration.test.ts-1736-1865 (1)

1736-1865: ⚠️ Potential issue | 🟠 Major

Avoid hard wall-clock budgets in this integration suite.

These <50ms / <100ms / <200ms assertions will flap under CI noise, slower runners, and transient host contention even when the code is correct. Please make these deterministic (for example, assert algorithmic behavior only, gate them behind a benchmark flag, or relax them enough that normal CI variance does not fail the suite).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/processors/integration/io-processors.integration.test.ts` around lines
1736 - 1865, The test uses fragile hard wall-clock assertions (e.g.,
expect(...).toBeLessThan(50)) that will flake in CI; update the tests around
ProcessorPipeline.processInput/processOutput,
createDefaultTripwireEvaluator.evaluate, and ProcessorRegistry lookups to remove
strict timing requirements and make them deterministic by either (a) gating
these timing assertions behind an explicit benchmark flag (check
process.env.RUN_BENCH === "1" and only run the expect(endTime -
startTime).toBeLessThan(...) when set), or (b) replace wall-clock checks with
algorithmic assertions (e.g., assert result.action/result.totalTime is defined,
correct, or that repeated registry.getInputProcessor/getOutputProcessor returns
expected processors) and relax or remove the tight thresholds so CI variance
won't fail the suite.

test/continuous-test-suite-processors.ts-36-42 (1)

36-42: 🛠️ Refactor suggestion | 🟠 Major

Use a type alias instead of an interface here.

This repo forbids interface in TypeScript sources/tests. Replace interface TestResult with type TestResult = { ... }.

As per coding guidelines, "Never use interface. Always use type X = { ... }."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/continuous-test-suite-processors.ts` around lines 36 - 42, Replace the
declared interface TestResult with a type alias: change "interface TestResult {
... }" to "type TestResult = { name: string; category: string; passed: boolean;
duration: number; error?: string }" ensuring the same shape and optional
property are preserved and updating any imports/usages if necessary to reference
the new type name TestResult.

src/lib/processors/utils/processorFactory.ts-75-90 (1)

75-90: ⚠️ Potential issue | 🟠 Major

Composed processors drop issues and metadata from inner processors.

These helpers only carry forward data. Any warnings, metadata, or enrichment emitted by earlier processors disappears before the composed processor returns, which breaks downstream tracing and safety aggregation in the pipeline. Please accumulate and merge issues / metadata across the chain, not just the transformed payload.

Also applies to: 113-128

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/utils/processorFactory.ts` around lines 75 - 90, The
composed processor's async process currently only carries forward result.data
and loses issues/metadata from inner processors; update the loop in process to
accumulate and merge any result.issues (arrays) and result.metadata (objects)
from each processor into aggregate variables (e.g., aggregatedIssues,
aggregatedMetadata) while still updating currentData from result.data, and
return them on exit along with action and data; apply the same merging logic to
the other composed block referenced around lines 113-128 so both composed
processor implementations propagate and merge issues/metadata instead of
dropping them.

test/continuous-test-suite-processors.ts-105-111 (1)

105-111: ⚠️ Potential issue | 🟠 Major

Remove pre-quoting of arguments to spawn().

With shell: false, spawn() treats each array element as a separate argument. Wrapping space-containing args in quotes injects literal " characters into argv, so inputs like Hello world are passed incorrectly as "Hello world" instead of Hello world.

Suggested fix

-    const quotedArgs = args.map((arg) =>
-      arg.includes(" ") ? `"${arg}"` : arg,
-    );
     // Use node directly for faster startup instead of npx
     const cliPath = path.join(process.cwd(), "dist", "cli", "index.js");
-    const proc = spawn("node", [cliPath, ...quotedArgs], {
+    const proc = spawn("node", [cliPath, ...args], {
       cwd: process.cwd(),
       timeout: TEST_CONFIG.timeout,
       shell: false,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/continuous-test-suite-processors.ts` around lines 105 - 111, The code
pre-quotes arguments via quotedArgs before calling spawn, which injects literal
double quotes into argv when using spawn(..., { shell: false }); remove the
pre-quoting step (delete/migrate usage of quotedArgs) and pass the original args
array directly to spawn (i.e., use [cliPath, ...args]) so each space-containing
argument is delivered as a single argv element; keep the cliPath and spawn(...)
invocation but replace quotedArgs with args (or ensure shell: true if you
purposely want shell parsing, but prefer using args as-is).

src/cli/commands/processors.ts-873-876 (1)

873-876: ⚠️ Potential issue | 🟠 Major

Reject array roots in validateProcessorConfig().

typeof [] === "object", so neurolink processor validate currently treats a JSON array as a valid top-level config. Since the result of JSON.parse() at line 748 is cast to Record<string, unknown> at line 777, an array root bypasses the structure check and incorrectly reports validation success.

Suggested fix

-    if (typeof config !== "object" || config === null) {
+    if (typeof config !== "object" || config === null || Array.isArray(config)) {
       errors.push("Configuration must be a JSON object");
       return { valid: false, errors, warnings };
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/cli/commands/processors.ts` around lines 873 - 876,
validateProcessorConfig currently treats arrays as valid because typeof [] ===
"object"; update the initial type check in validateProcessorConfig to also
reject arrays by adding an Array.isArray(config) condition (e.g., if (typeof
config !== "object" || config === null || Array.isArray(config)) ), push the
same "Configuration must be a JSON object" error when an array is provided, and
return { valid: false, errors, warnings } as before so top-level array roots are
correctly rejected.

FEATURE-STATUS.md-4-4 (1)

4-4: ⚠️ Potential issue | 🟡 Minor

Stale "Last Updated" date.

The document shows "January 31, 2026" but this PR is from April 2026. Consider updating to the actual date.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@FEATURE-STATUS.md` at line 4, Update the stale "Last Updated" metadata string
by replacing the literal "**Last Updated:** January 31, 2026" with the correct
current date (e.g., "**Last Updated:** April XX, 2026") in FEATURE-STATUS.md so
the document reflects the PR timing; locate and edit the line containing the
"**Last Updated:**" header and update the date value accordingly.

docs/tutorials.md-118-118 (1)

118-118: ⚠️ Potential issue | 🟡 Minor

Fix garbled character in heading.

The heading contains a mojibake/garbled character (�) before the globe emoji. This appears to be an encoding issue that will render incorrectly in documentation.

Proposed fix

-## �🌐 Web App Integration
+## 🌐 Web App Integration

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/tutorials.md` at line 118, The heading line currently contains a garbled
character "�" in the string "## �🌐 Web App Integration"; remove the invalid
character and replace the heading with a well-encoded version such as "## 🌐 Web
App Integration" (or plain "## Web App Integration" if you prefer to avoid
emoji), ensuring the file is saved with UTF-8 encoding so the globe emoji
renders correctly; update the heading text in the docs/tutorials.md content
where "## �🌐 Web App Integration" appears.

src/lib/processors/output/memoryPersistenceProcessor.ts-90-95 (1)

90-95: ⚠️ Potential issue | 🟡 Minor

Read provider and model from the output result.

This turn metadata is pulling provider/model from data.metadata, but the generated response data lives on data.result. As written, persisted turns will record undefined for both fields.

Proposed change

           metadata: {
             ...customMetadata,
-            provider: data.metadata.provider,
-            model: data.metadata.model,
+            provider: data.result.provider,
+            model: data.result.model,
             requestId: data.metadata.requestId,
           },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/output/memoryPersistenceProcessor.ts` around lines 90 -
95, The metadata block in memoryPersistenceProcessor is pulling provider/model
from data.metadata but the generated response has those fields on data.result;
update the metadata assignment (where provider and model are set) to read
provider and model from data.result (e.g., data.result?.metadata?.provider and
data.result?.metadata?.model), falling back to data.metadata if absent, while
leaving requestId as data.metadata.requestId so persisted turns record the
actual provider/model from the result.

test/fixtures/processors/pipeline-config.json-373-375 (1)

373-375: ⚠️ Potential issue | 🟡 Minor

Use the plural CLI command in the fixture example.

This sample says neurolink processor run, but the new command family is neurolink processors .... Leaving the singular form here will bake the wrong invocation into fixtures/docs.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/fixtures/processors/pipeline-config.json` around lines 373 - 375, The
fixture's usage example uses the old singular CLI invocation; update the "cli"
value under the "usage" object so it uses the new plural command family (change
"neurolink processor run --preset security --input 'text'" to "neurolink
processors run --preset security --input 'text'") so the example and fixtures
reflect the correct command; locate the "usage" object and the "cli" string in
the JSON and modify that string accordingly.

src/lib/processors/output/contentFilteringProcessor.ts-138-138 (1)

138-138: ⚠️ Potential issue | 🟡 Minor

Potential TypeError if data.metadata.custom is undefined.

Accessing data.metadata.custom.retryCount will throw if custom is undefined.

🛡️ Proposed fix

       if (action === "retry") {
-        const currentRetry = (data.metadata.custom.retryCount as number) || 0;
+        const currentRetry = (data.metadata.custom?.retryCount as number) || 0;
         if (currentRetry < maxRetries) {

Also apply at line 170:

             (action === "retry" &&
-              ((data.metadata.custom.retryCount as number) || 0) >= maxRetries),
+              ((data.metadata.custom?.retryCount as number) || 0) >= maxRetries),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/output/contentFilteringProcessor.ts` at line 138, The code
accesses data.metadata.custom.retryCount which can throw if custom is undefined;
change the access to use optional chaining and a safe default (e.g., const
currentRetry = (data.metadata.custom?.retryCount as number) || 0) or ensure
data.metadata.custom is initialized before reading, and apply the same fix to
the other occurrence that reads retryCount later in the file (the second access
of data.metadata.custom.retryCount).

src/lib/processors/utils/metadataUtils.ts-88-100 (1)

88-100: ⚠️ Potential issue | 🟡 Minor

Comment says "deep copy" but implementation is shallow.

The JSDoc claims this returns a "Deep copy of metadata", but the implementation only creates a shallow copy. Nested objects within custom values, or nested properties in issues items, will still share references with the original.

If callers expect true deep copy for safe mutation, this could lead to subtle bugs.

🔧 Proposed fix options

Option 1: Fix the comment to reflect actual behavior:

 /**
  * Clone metadata for safe mutation
  * `@param` metadata - Metadata to clone
- * `@returns` Deep copy of metadata
+ * `@returns` Shallow copy of metadata (top-level arrays/objects are cloned)
  */

Option 2: Implement actual deep copy if needed:

 export function cloneMetadata(metadata: ProcessorMetadata): ProcessorMetadata {
-  return {
-    ...metadata,
-    custom: { ...metadata.custom },
-    issues: [...metadata.issues],
-    processorTrace: [...metadata.processorTrace],
-  };
+  return JSON.parse(JSON.stringify(metadata));
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/processors/utils/metadataUtils.ts` around lines 88 - 100, The JSDoc
for cloneMetadata claims a "Deep copy" but the function only shallow-clones
top-level fields (custom, issues, processorTrace); update cloneMetadata to
produce a true deep clone of ProcessorMetadata (including nested objects inside
custom values and nested properties inside issues and processorTrace) by
replacing the shallow spreads with a deep-cloning approach (e.g., use
structuredClone where available with a safe fallback like
JSON.parse(JSON.stringify(...)) or a project deepClone utility) while preserving
the ProcessorMetadata shape and types in the returned value.

src/lib/types/generate.ts (1)

515-572: 🛠️ Refactor suggestion | 🟠 Major

Same inline-duplication / action optionality mismatch as StreamOptions.

Mirror issue to the one on src/lib/types/stream.ts (lines 552-600):

• Line 521: action?: "redact" | "abort" | "warn" is optional here but required in PiiDetectionConfig (ioProcessor.ts line 28).
• Lines 550-554: inlined customValidator return type drops field?: string from ValidationIssue.
• detectTypes (522-533) re-enumerates PiiType by hand.

Prefer importing the canonical types and referencing them directly — then TextGenerationOptions (lines 1133-1145) can keep its GenerateOptions["piiDetection"] indexed access without the shape drifting behind it.

♻️ Proposed change

-import type { ProcessorPipelineConfig } from "./ioProcessor.js";
+import type {
+  InputValidationConfig,
+  PiiDetectionConfig,
+  ProcessorPipelineConfig,
+  ResponseValidationConfig,
+} from "./ioProcessor.js";

-  piiDetection?: {
-    enabled?: boolean;
-    action?: "redact" | "abort" | "warn";
-    detectTypes?: Array<
-      | "email"
-      …
-      | "driversLicense"
-    >;
-    customPatterns?: RegExp[];
-    allowList?: string[];
-    redactionText?: string;
-  };
-
-  responseValidation?: {
-    …
-  };
-
-  inputValidation?: {
-    …
-  };
+  piiDetection?: PiiDetectionConfig;
+  responseValidation?: ResponseValidationConfig;
+  inputValidation?: InputValidationConfig;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/types/generate.ts` around lines 515 - 572, The piiDetection block in
TextGeneration-related types duplicates and drifts from canonical types: replace
the inline shape with imports of PiiDetectionConfig and PiiType and use them
directly (so detectTypes becomes PiiType[] and action matches the requiredness
in PiiDetectionConfig), and update the customValidator return type to use the
shared ValidationIssue type (preserving optional field?: string) instead of an
ad-hoc inline type; also change any related references (e.g.,
TextGenerationOptions/GenerateOptions["piiDetection"]) to reference the imported
canonical types to prevent future drift.

test/continuous-test-suite-safety.ts (1)

21-27: Exercise the new public exports in this safety suite.

These imports bypass src/lib/index.ts, so the tests won’t catch a broken public export even though this PR adds one. Importing from ../src/lib/index.js here, or adding a small public-entrypoint smoke test, would cover the new API surface.

Suggested import change

-import { detectAndRedactPII } from "../src/lib/utils/piiDetector.js";
-import { validateResponse } from "../src/lib/utils/responseValidator.js";
 import {
+  detectAndRedactPII,
+  validateResponse,
   TripwireEvaluator,
   createDefaultTripwireEvaluator,
   commonTripwires,
-} from "../src/lib/utils/tripwireEvaluator.js";
+} from "../src/lib/index.js";

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/continuous-test-suite-safety.ts` around lines 21 - 27, The test is
importing internal modules directly which skips the package's public entrypoint;
update the imports to exercise the public API by importing detectAndRedactPII,
validateResponse, TripwireEvaluator, createDefaultTripwireEvaluator, and
commonTripwires from the public entrypoint (../src/lib/index.js) instead of
their internal paths, or add a tiny smoke test that imports those symbols from
the public export to ensure the new public export is exercised.

src/lib/types/ioProcessor.ts (1)

14-150: Centralize InputValidationConfig and consider domain prefixes for type names.

Two improvements for this types module:

1. InputValidationConfig is duplicated inline: The shape { trimWhitespace?, minLength?, maxLength?, requireContent? } appears identically in both src/lib/types/stream.ts (lines 592–597) and src/lib/types/generate.ts (lines 562–567). Extracting this as an exported type here would eliminate duplication and mirror PiiDetectionConfig and ResponseValidationConfig, keeping all three safety-related configs in one place.

2. Generic type names lack domain prefixes: ValidationIssue, DetectedPII, and PiiType are generic names without domain prefixes. Per the coding guideline requiring globally unique exported type names in src/lib/types/ (using prefixes like Processor*, Stream*, etc. to disambiguate), consider renaming these to better reflect their domain—e.g., ProcessorValidationIssue, ProcessorDetectedPII, ProcessorPiiType.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/types/ioProcessor.ts` around lines 14 - 150, Extract a shared
exported type InputValidationConfig (shape: trimWhitespace?: boolean;
minLength?: number; maxLength?: number; requireContent?: boolean) into this file
and replace the duplicated inline shapes in src/lib/types/stream.ts and
src/lib/types/generate.ts by importing and using InputValidationConfig; update
any references to the inline anonymous shapes to the new type. Also apply
domain-prefixed renames for the public types: rename PiiType → ProcessorPiiType,
DetectedPII → ProcessorDetectedPII, and ValidationIssue →
ProcessorValidationIssue (and update all references in this file and across the
codebase), while keeping temporary backwards-compatible exports (e.g., export
type PiiType = ProcessorPiiType) if needed to avoid breaking existing imports.
Ensure you update PiiDetectionConfig, ResponseValidationConfig, and any other
types that reference the renamed symbols to reference the new Processor* names.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes