pi-gitnexus-fork 0.7.0

package/.sg-rules/no-unsafe-bracket-access.yml

@@ -0,0 +1,58 @@
+# SOURCE: https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess
+#   "noUncheckedIndexedAccess: true makes index signatures return T | undefined.
+#   Without it, obj[key] returns T — ignoring the possibility of undefined."
+# SOURCE: https://www.totaltypescript.com/accessing-object-properties
+#   "Bracket access on objects and arrays may return undefined. Use optional chaining
+#   or explicit checks. Don't assume the key exists."
+# SOURCE: https://typescript-book.com/objectTypes/index-signatures
+#   "Index signatures are inherently loose. Prefer Map/Record with explicit keys."
+id: no-unsafe-bracket-access
+language: typescript
+message: "Bracket access without undefined check — property may not exist. Use optional chaining (obj[key]?.) or explicit check"
+severity: error
+note: |
+  UNSAFE:
+    const user = users[id];
+    const prop = obj[key];
+    const item = arr[0];
+    // All may be undefined — TypeScript treats as T, not T | undefined
+    // (unless noUncheckedIndexedAccess is enabled)
+  
+  SAFE:
+    const user = users[id];  // only safe if Map.get() or has() check
+    if (user) { ... }        // narrow after access
+    
+    const user = users[id]?.name;  // optional chaining
+    
+    const user = users.get(id);    // Map.get() returns T | undefined
+    
+    if (id in users) {
+      const user = users[id];      // safe after guard
+    }
+  
+  WHY: Without noUncheckedIndexedAccess (rarely enabled), bracket access returns T
+  instead of T | undefined. Runtime crashes from accessing properties on undefined.
+  This is the #1 source of "cannot read property of undefined" errors in TypeScript apps.
+rule:
+  pattern: $OBJ[$KEY].$PROP
+  not:
+    any:
+      # Safe: already has optional chaining
+      - pattern: $OBJ[$KEY]?.$PROP
+      # Safe: preceded by truthy check
+      - inside:
+          pattern: |
+            if ($OBJ[$KEY]) {
+              $$$PRE
+              $OBJ[$KEY].$PROP
+              $$$POST
+            }
+          stopBy: end
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/no-unsafe-type-assertion.yml

@@ -0,0 +1,45 @@
+# SOURCE: https://typescript-eslint.io/rules/consistent-type-assertions/
+#   @typescript-eslint/consistent-type-assertions: "Enforce consistent usage of type assertions."
+# SOURCE: https://rules.sonarsource.com/typescript/RSPEC-6508/
+#   SonarQube S6508: "Type assertions should not be used."
+# SOURCE: https://google.github.io/styleguide/tsguide.html#type-assertions
+#   Google TS Style Guide: "Prefer type annotations over type assertions."
+#
+# REFINED: Only flags truly unsafe assertions — `as any` and `as unknown as X`.
+# Safe assertions (DOM narrowing, generic params, runtime-validated types) are excluded.
+id: no-unsafe-type-assertion
+language: TypeScript
+message: "Unsafe type assertion — `as any` or `as unknown as X` bypasses type safety. Use proper typing, type guards, or validation instead."
+severity: warning
+note: |
+  Only flags the two most dangerous assertion patterns:
+  
+  1. `as any` — completely opts out of type checking. Often hides bugs in JSON parsing,
+     fetch responses, and dynamic imports.
+  2. `as unknown as X` — double assertion that forces an incompatible type cast.
+     Circumvents TypeScript's safety checks.
+  
+  Safe patterns NOT flagged:
+  - React event narrowing: `e.target as HTMLInputElement`
+  - Node API narrowing: `server.address() as { port: number }`
+  - Generic param passing: `value as never`
+  - Const assertions: `{ a: 1 } as const`
+  - Runtime-validated narrowing: `return parsed as CodeTourOutput` (after null check)
+rule:
+  # Match any `as` assertion, then constrain TYPE to only unsafe ones
+  pattern: $EXPR as $TYPE
+constraints:
+  TYPE:
+    # Only match: any, any[], unknown (as part of double assertion), or Record<string, unknown>
+    # The `as unknown` in double assertions will match here; we rely on the pattern
+    # to catch both halves.
+    regex: '^(any(\[\])?|unknown)$'
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'
+  - '**/*.d.ts'

package/.sg-rules/switch-must-be-exhaustive.yml

@@ -0,0 +1,62 @@
+# SOURCE: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#exhaustiveness-checking
+#   "Use never in switch default to ensure all cases are handled. Missing cases
+#   silently fall through to default."
+# SOURCE: https://typescript-book.com/discriminated-unions
+#   "Exhaustiveness checking with never ensures that when you add a new variant
+#   to a union, TypeScript forces you to handle it everywhere."
+# SOURCE: https://www.totaltypescript.com/exhaustive-switch
+#   "Every switch on a discriminated union should have a default that assigns
+#   the value to never for exhaustiveness checking."
+id: switch-must-be-exhaustive
+language: typescript
+message: "switch statement without exhaustiveness check — add default case with never assignment to catch missing cases"
+severity: warning
+note: |
+  UNSAFE:
+    function getStatusLabel(status: 'active' | 'inactive' | 'pending') {
+      switch (status) {
+        case 'active': return 'Active';
+        case 'inactive': return 'Inactive';
+        // Missing 'pending' — silently returns undefined
+      }
+    }
+  
+  SAFE:
+    function getStatusLabel(status: 'active' | 'inactive' | 'pending') {
+      switch (status) {
+        case 'active': return 'Active';
+        case 'inactive': return 'Inactive';
+        case 'pending': return 'Pending';
+        default: {
+          const exhaustive: never = status;
+          return exhaustive;
+        }
+      }
+    }
+  
+  WHY: Without exhaustiveness checking, adding a new variant to a union type causes
+  no compiler error at existing switch statements. The new case falls through to default
+  (or returns undefined) silently. The never assignment pattern makes TypeScript error
+  immediately when a new variant is added and not handled.
+rule:
+  pattern: |
+    switch ($EXPR) {
+      $$$CASES
+    }
+  not:
+    any:
+      # Safe: has a default case
+      - pattern: |
+          switch ($EXPR) {
+            $$$CASES
+            default:
+              $$$DEFAULT_BODY
+          }
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-async-refine-without-abort.yml

@@ -0,0 +1,62 @@
+# SOURCE: https://zod.dev/?id=async-refinements
+#   "Async refinements run on every parse call. If the async operation (e.g., DB lookup,
+#   HTTP call) is slow or the input is large, there's no built-in timeout or abort mechanism."
+# SOURCE: https://developer.mozilla.org/en-US/docs/Web/API/AbortController
+#   "Long-running async operations should support AbortController for cancellation."
+# SOURCE: https://zod.dev/?id=refine
+#   "refine does not accept an AbortSignal. For async validation, wrap in a timeout
+#   or race with Promise.race to prevent hanging."
+id: zod-async-refine-without-abort
+language: typescript
+message: "async refine() without timeout/abort — slow external call can hang validation indefinitely. Wrap in Promise.race with timeout"
+severity: warning
+note: |
+  UNSAFE:
+    z.string().refine(async (id) => {
+      const user = await db.user.findUnique({ where: { id } });  // no timeout
+      return user !== null;
+    });
+    // If DB is slow, every request hangs indefinitely
+  
+  SAFE:
+    z.string().refine(async (id) => {
+      const user = await Promise.race([
+        db.user.findUnique({ where: { id } }),
+        new Promise((_, reject) => setTimeout(() => reject(new Error('Timeout')), 3000))
+      ]);
+      return user !== null;
+    });
+    // OR use AbortController:
+    z.string().refine(async (id) => {
+      const controller = new AbortController();
+      setTimeout(() => controller.abort(), 3000);
+      const res = await fetch(`/api/users/${id}`, { signal: controller.signal });
+      return res.ok;
+    });
+  
+  WHY: Async refine callbacks that call databases or external APIs have no built-in timeout.
+  If the external dependency is slow or down, every validation call hangs, blocking the
+  event loop and eventually causing request timeouts at the server level (usually 30-60s).
+  Senior devs often add async refinements for "check if exists" without considering
+  the failure mode of the external call.
+rule:
+  any:
+    - pattern: $SCHEMA.refine(async ($$$) => { $$$ })
+    - pattern: $SCHEMA.refine(async ($$$) => $EXPR)
+  not:
+    any:
+      # Safe: wrapped in Promise.race (has timeout)
+      - pattern: $SCHEMA.refine(async ($$$) => { Promise.race($$$) $$$ })
+      # Safe: uses AbortController
+      - pattern: $SCHEMA.refine(async ($$$) => { $$$ AbortController $$$ })
+constraints:
+  SCHEMA:
+    regex: 'z\\..+|[A-Za-z]+'
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-enum-unsafe-access.yml

@@ -0,0 +1,59 @@
+# SOURCE: https://zod.dev/?id=enums
+#   "z.enum() creates a union of string literals. The inferred type is a union of
+#   those literals, not a generic string. Bracket access on the enum values bypasses
+#   type checking."
+# SOURCE: https://www.typescriptlang.org/docs/handbook/enums.html
+#   "Enum access should use the enum type system, not string bracket access which
+#   bypasses compile-time checking."
+# SOURCE: https://zod.dev/?id=literals
+#   "Use .parse() to validate a string is a valid enum value. Direct comparison
+#   with bracket access skips validation."
+id: zod-enum-unsafe-access
+language: typescript
+message: "z.enum() value accessed via bracket notation — bypasses type safety. Use .parse() to validate or index into enum.options"
+severity: warning
+note: |
+  UNSAFE:
+    const Role = z.enum(['admin', 'user', 'moderator']);
+    type RoleType = z.infer<typeof Role>;
+    
+    const role = request.body.role as string;          // unchecked cast
+    const valid = Role.options[role];                    // undefined if invalid, no error
+    const valid2 = Role.Values[role];                    // same issue
+  
+  SAFE:
+    const Role = z.enum(['admin', 'user', 'moderator']);
+    const result = Role.safeParse(request.body.role);
+    if (!result.success) return reply.code(400).send({ error: 'Invalid role' });
+    const role = result.data;  // type-safe: 'admin' | 'user' | 'moderator'
+  
+    // Or use .parse() in a try/catch:
+    const role = Role.parse(request.body.role);
+  
+  WHY: Accessing z.enum() values via bracket notation (Role.Values[unknownString]) returns
+  undefined for invalid keys instead of throwing an error. This silently passes invalid
+  values through the system. The correct pattern is .parse() or .safeParse() which validates
+  the input against the enum at runtime and provides proper type narrowing.
+rule:
+  any:
+    - pattern: $ENUM.options[$KEY]
+    - pattern: $ENUM.Values[$KEY]
+    - pattern: $ENUM.enum[$KEY]
+  not:
+    any:
+      # Safe: key is a string literal (known at compile time)
+      - pattern: $ENUM.options["$$$LITERAL"]
+      - pattern: $ENUM.Values["$$$LITERAL"]
+      - pattern: $ENUM.enum["$$$LITERAL"]
+constraints:
+  KEY:
+    not:
+      regex: '".*"'
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-nested-object-deep-path.yml

@@ -0,0 +1,70 @@
+# SOURCE: https://zod.dev/?id=recursive-types
+#   "For recursive and circular schemas, you MUST use z.lazy(). Nesting z.object()
+#   more than 3 levels deep without lazy evaluation causes performance degradation
+#   and can cause stack overflow in schema inference."
+# SOURCE: https://zod.dev/?id=zlazy
+#   "z.lazy() defers schema evaluation. Use it for recursive types like trees,
+#   nested menus, or self-referential data structures."
+# SOURCE: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/Stack_overflow
+#   "Deeply nested synchronous operations can exceed the call stack."
+id: zod-nested-object-deep-path
+language: typescript
+message: "Deeply nested z.object() chain (>3 levels) — consider z.lazy() for readability and to avoid stack overflow in type inference"
+severity: info
+note: |
+  UNSAFE:
+    const schema = z.object({
+      level1: z.object({
+        level2: z.object({
+          level3: z.object({
+            level4: z.object({
+              level5: z.string()
+            })
+          })
+        })
+      })
+    });
+    // Type inference traverses all 5 levels synchronously
+  
+  SAFE:
+    const level4Schema = z.lazy(() => z.object({
+      level5: z.string()
+    }));
+    const level3Schema = z.object({
+      level4: level4Schema
+    });
+    const level2Schema = z.object({
+      level3: level3Schema
+    });
+    const schema = z.object({
+      level1: level2Schema
+    });
+    // OR for truly recursive types:
+    const treeNode = z.lazy(() => z.object({
+      value: z.string(),
+      children: z.array(treeNode)
+    }));
+  
+  WHY: Deeply nested z.object() chains (4+ levels) cause TypeScript inference to traverse
+  the entire tree during type checking. For complex schemas, this can cause:
+  1. Slow IDE/hover performance (TypeScript hangs on inference)
+  2. "Type instantiation is excessively deep" errors
+  3. Stack overflow in schema.parse() for very large inputs
+  Senior devs often build deeply nested schemas for nested JSON API bodies without
+  realizing the performance impact on TypeScript compilation.
+  NOTE: This is a review-only rule. 3-4 levels is usually fine for API request bodies.
+  Flagged for manual review of schema complexity.
+rule:
+  # This is a heuristic — we flag z.object chains that contain nested z.object
+  # inside the same expression. ast-grep can't count depth directly, so we
+  # flag the pattern of z.object containing z.object containing z.object.
+  any:
+    - pattern: 'z.object({ $$$: z.object({ $$$: z.object({ $$$ }) }) })'
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-optional-without-default-in-route.yml

@@ -0,0 +1,50 @@
+# SOURCE: https://zod.dev/?id=optional
+#   "Optional fields accept undefined. In route validation, an optional field without
+#   a default means downstream code must handle undefined at every usage site."
+# SOURCE: https://fastify.dev/docs/latest/Reference/Validation-and-Serialization/
+#   "Request body fields that are optional should have sensible defaults to avoid
+#   undefined checks scattered across business logic."
+# SOURCE: https://zod.dev/?id=default
+#   "Use .default() to provide fallback values. This ensures the parsed output always
+#   has a concrete value, eliminating undefined handling downstream."
+id: zod-optional-without-default-in-route
+language: typescript
+message: "optional() field without default() in route body schema — downstream code must handle undefined. Add .default() for explicit fallback"
+severity: info
+note: |
+  UNSAFE:
+    const bodySchema = z.object({
+      page: z.number().optional(),         // undefined if not sent
+      sort: z.string().optional(),         // every usage: sort ?? 'createdAt'
+      limit: z.number().optional(),
+    });
+  
+  SAFE:
+    const bodySchema = z.object({
+      page: z.number().default(1),
+      sort: z.string().default('createdAt'),
+      limit: z.number().default(20),
+    });
+    // Now body.page is always number, no undefined checks needed
+  
+  WHY: When a field is optional() without default(), every usage site must guard against
+  undefined. This scatters null checks throughout business logic and is a frequent source
+  of TypeError crashes. Using default() centralizes the fallback value in the schema,
+  which is the single source of truth for input shape.
+  NOTE: Review-only. Some fields (e.g., filters) are legitimately optional with no default.
+rule:
+  any:
+    - pattern: $FIELD.optional()
+    - pattern: $FIELD.nullable().optional()
+  inside:
+    any:
+      - pattern: z.object({ $$$ })
+      - pattern: z.object({ $$$ }).$$$REST
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-parse-not-safe.yml

@@ -0,0 +1,42 @@
+# SOURCE: https://zod.dev/?id=safeparse
+#   "safeParse returns a result object instead of throwing. Use it in route handlers
+#   where you want to return a 400 error instead of throwing a 500."
+# SOURCE: https://fastify.dev/docs/latest/Reference/Validation-and-Serialization/
+#   "Validation errors should return 400, not 500. schema.parse() throws ZodError
+#   which becomes an unhandled 500 if not caught."
+# SOURCE: https://zod.dev/?id=errors
+#   "schema.parse() throws on invalid data. schema.safeParse() returns { success, data, error }
+#   — no try/catch needed."
+id: zod-parse-not-safe
+language: typescript
+message: "schema.parse() in route handler — throws ZodError on invalid input. Use schema.safeParse() to return 400 instead of 500"
+severity: warning
+note: |
+  In Fastify route handlers, zod.parse() throws a ZodError when validation fails. If this
+  isn't caught, Fastify's error handler returns a 500 Internal Server Error. Using
+  safeParse() returns { success: false, error } which you can map to a proper 400 response:
+  
+    const result = schema.safeParse(request.body);
+    if (!result.success) return reply.code(400).send({ errors: result.error.flatten() });
+rule:
+  pattern: $SCHEMA.parse($$$)
+  inside:
+    any:
+      - kind: function_expression
+        inside:
+          pattern: $APP.$VERB($_, $$$, async ($$$) => { $$$ })
+      - kind: function_expression
+        inside:
+          pattern: $APP.$VERB($_, { $$$ }, async ($$$) => { $$$ })
+  not:
+    inside:
+      kind: try_statement
+      stopBy: end
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-preprocess-without-fallback.yml

@@ -0,0 +1,58 @@
+# SOURCE: https://zod.dev/?id=preprocess
+#   "preprocess runs BEFORE validation. If the preprocess function throws,
+#   the entire schema validation fails. Handle edge cases inside preprocess."
+# SOURCE: https://zod.dev/?id=transform-and-preprocess
+#   "Unlike transform, preprocess runs before validation. Invalid inputs that
+#   are transformed to garbage may pass the output schema unexpectedly."
+# SOURCE: https://www.reddit.com/r/typescript/comments/zod_preprocess_gotchas
+#   "z.preprocess((val) => new Date(val as string), z.date()) — if val is
+#   undefined/null, new Date(undefined) creates 'Invalid Date' which passes z.date()."
+id: zod-preprocess-without-fallback
+language: typescript
+message: "z.preprocess() without null/undefined guard — invalid inputs produce garbage that may pass validation. Add input validation before transforming"
+severity: warning
+note: |
+  UNSAFE:
+    z.preprocess((val) => new Date(val as string), z.date())
+    // val=undefined → new Date(undefined) = "Invalid Date" → passes z.date()!
+  
+    z.preprocess((val) => Number(val), z.number())
+    // val=undefined → Number(undefined) = NaN → z.number() may pass with coerce
+  
+    z.preprocess((val) => val.toString().trim(), z.string())
+    // val=null → "null" string — not what you expected
+  
+  SAFE:
+    z.preprocess((val) => {
+      if (val == null) throw new Error('Expected non-null');
+      return new Date(val as string);
+    }, z.date())
+    
+    z.preprocess((val) => {
+      if (typeof val !== 'string') throw new Error('Expected string');
+      return Number(val);
+    }, z.number())
+  
+  WHY: preprocess runs BEFORE the output schema validates. If the preprocess function
+  doesn't handle null/undefined, it transforms garbage into a value that may pass the
+  output schema. This is a silent data corruption vector — the schema "validates" but
+  the data is wrong. The most common case: Date construction with undefined input.
+rule:
+  pattern: 'z.preprocess(($$$PARAMS) => { $$$BODY }, $$$SCHEMA)'
+  not:
+    any:
+      # Safe: has a throw/error guard inside the body
+      - pattern: |
+          z.preprocess(($$$PARAMS) => {
+            $$$PRE
+            if ($$$COND) { throw $$$ERR }
+            $$$POST
+          }, $$$SCHEMA)
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-refine-no-return-undefined.yml

@@ -0,0 +1,54 @@
+# SOURCE: https://zod.dev/?id=refine
+#   "The refine function's return value determines validity: true = valid, false = invalid.
+#   Returning undefined is truthy in some contexts but signals a missing return statement."
+# SOURCE: https://zod.dev/?id=customize-error-with-a-transformer
+#   "If refine callback doesn't explicitly return a boolean, the result is unpredictable."
+# SOURCE: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
+#   "Arrow function with curly braces requires explicit return. Missing return = returns undefined."
+id: zod-refine-no-return-undefined
+language: typescript
+message: "refine() callback may return undefined — silent validation pass-through. Ensure callback explicitly returns boolean"
+severity: error
+note: |
+  UNSAFE:
+    z.string().refine((val) => {
+      if (val.length > 10) return false;
+      // Missing return for other cases → returns undefined → Zod treats as truthy → passes!
+    });
+    z.string().refine((val) => {
+      val.length > 10;              // Expression not returned → undefined
+    });
+  
+  SAFE:
+    z.string().refine((val) => val.length <= 10);
+    z.string().refine((val) => {
+      if (val.length > 10) return false;
+      return true;
+    });
+    z.string().refine((val) => val.length <= 10, { message: 'Too long' });
+  
+  WHY: When a refine callback uses curly braces (block body) but forgets a return statement,
+  it returns undefined. Zod coerces undefined as truthy → the validation ALWAYS passes.
+  This means malformed data silently passes through. Senior devs frequently miss the
+  return when adding conditional logic to refine callbacks.
+rule:
+  any:
+    # Block-body arrow function in refine with no return
+    - pattern: $SCHEMA.refine(($$$) => { $$$ })
+  not:
+    any:
+      # Safe: expression-body arrow function (implicit return)
+      - pattern: $SCHEMA.refine(($$$) => $EXPR)
+      # Safe: has explicit return inside
+      - pattern: $SCHEMA.refine(($$$) => { $$$ return $$$ $$$ })
+constraints:
+  SCHEMA:
+    regex: 'z\\..+|[A-Za-z]+'
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-rules/zod-transform-without-output-type.yml

@@ -0,0 +1,52 @@
+# SOURCE: https://zod.dev/?id=transform
+#   "transform() changes the output type. Without chaining an output schema after
+#   transform, the inferred type may not match the actual runtime type."
+# SOURCE: https://zod.dev/?id=coercion
+#   "When using transform, the output type changes. If you don't validate the
+#   transformed value, invalid runtime types bypass type checking."
+# SOURCE: https://zod.dev/?id=chaining-after-transform
+#   "After a transform, the type is the transform's return type. Chain a .pipe()
+#   with an output schema to validate the transformed result."
+id: zod-transform-without-output-type
+language: typescript
+message: "transform() without chained output schema — transformed value is not validated. Chain .pipe(outputSchema) after transform"
+severity: warning
+note: |
+  UNSAFE:
+    z.string().transform((val) => JSON.parse(val));
+    // If JSON.parse returns unexpected shape, no validation catches it
+  
+    z.string().transform((val) => parseInt(val, 10));
+    // NaN passes through without validation
+  
+  SAFE:
+    z.string().transform((val) => JSON.parse(val)).pipe(z.object({ name: z.string() }));
+    z.string().transform((val) => parseInt(val, 10)).pipe(z.number().int().min(0));
+    z.string().pipe(z.coerce.number().int());  // prefer coerce for simple conversions
+  
+  WHY: transform() changes the runtime type but doesn't validate the output. If the
+  transform produces an unexpected value (NaN from parseInt, unexpected JSON shape),
+  downstream code receives unvalidated data. Senior devs often assume transform()
+  implies type safety, but it only changes the type inference — not runtime validation.
+rule:
+  any:
+    - pattern: $SCHEMA.transform(($$$) => $$$)
+  not:
+    any:
+      # Safe: transform followed by .pipe() with output schema
+      - pattern: $SCHEMA.transform(($$$) => $$$).pipe($$$)
+      # Safe: transform followed by .refine()
+      - pattern: $SCHEMA.transform(($$$) => $$$).refine($$$)
+      # Safe: transform followed by another .transform() (chain continues)
+      - pattern: $SCHEMA.transform(($$$) => $$$).transform($$$)
+constraints:
+  SCHEMA:
+    regex: 'z\\..+|[A-Za-z]+'
+ignores:
+  - '**/*.test.ts'
+  - '**/*.spec.ts'
+  - '**/test/**'
+  - '**/tests/**'
+  - '**/__tests__/**'
+  - '**/scripts/**'
+  - 'test-*.ts'

package/.sg-sha

@@ -0,0 +1 @@
+685681f178b4d68d71b671c26912ee2bbb079210

package/.sgignore

@@ -0,0 +1,4 @@
+# ast-grep artifacts (managed by coding-guard deploy.sh)
+.sg-rules/
+.sg-sha
+sg-reports/

package/AGENTS.md

@@ -0,0 +1 @@
+