@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/expo-app/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "eas-build-configuration",
-    "description": "Validate that the skill produces a correct EAS Build configuration with development, preview, and production profiles, proper signing, environment variables, and runtime versioning for OTA update compatibility.",
-    "input": "Configure EAS Build for an Expo SDK 52 app. Create three build profiles: development (with expo-dev-client, internal distribution), preview (for TestFlight/internal testing), and production (for App Store/Play Store). Set up environment variables for API keys that differ per environment. Configure runtime versioning with the fingerprint policy for OTA update compatibility. Include iOS provisioning and Android keystore configuration.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "eas.json",
-        "description": "Must create or reference an eas.json configuration file with build profiles, as EAS Build reads all configuration from this file."
-      },
-      {
-        "type": "contains",
-        "value": "developmentClient",
-        "description": "Development profile must set developmentClient: true to build with expo-dev-client instead of Expo Go, enabling custom native module support."
-      },
-      {
-        "type": "contains",
-        "value": "distribution",
-        "description": "Must configure distribution settings per profile (internal for development/preview, store for production) to control how builds are distributed."
-      },
-      {
-        "type": "contains",
-        "value": "runtimeVersion",
-        "description": "Must configure runtimeVersion with fingerprint or appVersion policy to tie OTA updates to compatible native binaries and prevent crash-on-launch."
-      },
-      {
-        "type": "contains",
-        "value": "env",
-        "description": "Must configure environment variables per build profile to inject different API keys and configuration for development, preview, and production builds."
-      }
-    ]
-  },
-  {
-    "name": "push-notification-setup",
-    "description": "Validate that the skill produces a complete push notification implementation with expo-notifications including permission handling, token registration, foreground and background handlers, and server-side delivery.",
-    "input": "Implement push notifications for an Expo app. Register for push tokens on app launch and send them to the backend. Handle notification permissions on iOS and Android 13+. Display notifications when the app is in the foreground. Handle notification taps to navigate to specific screens using expo-router. Set up a server endpoint that sends push notifications through Expo's push API. Handle token refresh and error responses.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "getExpoPushTokenAsync",
-        "description": "Must use Notifications.getExpoPushTokenAsync to obtain the device's Expo push token for server-side registration."
-      },
-      {
-        "type": "contains",
-        "value": "requestPermissionsAsync",
-        "description": "Must request notification permissions before attempting to register for push tokens, as iOS and Android 13+ require explicit consent."
-      },
-      {
-        "type": "contains",
-        "value": "setNotificationHandler",
-        "description": "Must configure Notifications.setNotificationHandler to control foreground notification display behavior (shouldShowAlert, shouldPlaySound, shouldSetBadge)."
-      },
-      {
-        "type": "contains",
-        "value": "addNotificationResponseReceivedListener",
-        "description": "Must register a notification response listener to handle user taps on notifications and navigate to the appropriate screen."
-      },
-      {
-        "type": "contains",
-        "value": "expo.dev/--/api/v2/push/send",
-        "description": "Server-side push delivery must use Expo's push API endpoint to send notifications with the registered Expo push token."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/express-nodejs/SKILL.md

@@ -1,84 +0,0 @@
----
-name: express-nodejs
-description: "Use when building Express.js services on modern Node.js, including Express 5 routing, async middleware, TypeScript integration, security headers, error handling, and production hardening."
-allowed-tools: Read Grep Glob Bash Edit Write
-user-invocable: true
-argument-hint: "Express route, middleware, or Node.js module to work on"
----
-
-# Express.js with Modern Node.js
-
-## Purpose
-
-Production-grade guidance for building secure, maintainable HTTP APIs and web applications using Express 5.x on modern Node.js (v20+). Covers async middleware patterns, TypeScript-first development, security hardening, structured error handling, and testing strategies that scale from prototypes to high-traffic services.
-
-## When to Use
-
-- Building REST APIs, BFF layers, or server-rendered applications with Express.
-- Composing middleware stacks for authentication, validation, logging, and security headers.
-- Integrating Express with TypeScript for type-safe request/response handling.
-- Implementing async error handling that does not leak stack traces or swallow failures.
-- Hardening Express services with helmet, CORS, rate limiting, and input sanitization.
-- Writing integration tests for Express routes and middleware.
-
-## Instructions
-
-1. **Use Express 5.x with native async/await support** -- Express 5 automatically catches rejected promises in route handlers and passes them to the error handler. This eliminates the need for `express-async-errors` or manual try/catch wrappers in every handler. Verify your version with `express --version` and upgrade if still on Express 4.
-
-2. **Write the application in TypeScript with strict mode** -- enable `strict: true` in `tsconfig.json` and type request handlers as `RequestHandler` from `express`. Define typed interfaces for `req.body`, `req.params`, and `req.query` using generics. This catches shape mismatches at compile time instead of runtime.
-
-3. **Separate app creation from server listening** -- export the Express app from `app.ts` and call `app.listen()` only in `server.ts`. This lets tests import the app without binding a port and avoids `EADDRINUSE` errors during parallel test execution.
-
-4. **Structure middleware in explicit order: security, parsing, logging, auth, routes, errors** -- register `helmet()` first for security headers, then `express.json()` for body parsing, then request logging, then authentication middleware, then route handlers, and finally the error handler. Middleware order is the execution order, and misplacing error handlers before routes makes them unreachable.
-
-5. **Validate request bodies with a schema validation library** -- use `zod`, `joi`, or `ajv` to validate `req.body`, `req.params`, and `req.query` in a reusable validation middleware. Return 400 with structured field-level errors. Do not validate manually inside handlers because it scatters validation logic and produces inconsistent error formats.
-
-6. **Implement a centralized error-handling middleware with four parameters** -- define `(err, req, res, next)` as the last middleware. Map known error classes (validation errors, auth errors, not-found errors) to appropriate HTTP status codes and a consistent JSON envelope. Log unexpected errors with stack traces but never send stack traces to the client. Always call `next(err)` in route handlers instead of sending error responses directly.
-
-7. **Create custom error classes that carry HTTP status codes** -- define `AppError`, `NotFoundError`, `ValidationError`, and `UnauthorizedError` extending `Error` with a `statusCode` property. Throw these from service functions and let the centralized handler format the response. This decouples business logic from HTTP response formatting.
-
-8. **Apply Helmet with explicit directives** -- call `app.use(helmet({ contentSecurityPolicy: { directives: { ... } } }))` with directives appropriate for your content model. The defaults are good but may block inline scripts or CDN resources your frontend needs. Review each directive rather than disabling CSP entirely.
-
-9. **Configure CORS with an allow-list, not a wildcard** -- use the `cors` package with `origin` set to an array of allowed origins or a function that checks against a dynamic list. Set `credentials: true` only if you use cookies. A wildcard origin (`*`) disables credential passing and gives every site access to your API responses.
-
-10. **Rate-limit endpoints with `express-rate-limit`** -- apply a global limiter for general protection and stricter per-route limiters for authentication and password-reset endpoints. Use a Redis or Memcached store in production for distributed rate limiting across instances. The default in-memory store does not share state across processes.
-
-11. **Handle async errors by throwing or passing to `next()`** -- in Express 5, async handlers that throw or return rejected promises automatically trigger the error handler. For Express 4 compatibility or explicit control, call `next(err)`. Never swallow errors with empty catch blocks because it produces silent failures that are impossible to debug in production.
-
-12. **Write integration tests with `supertest` and the separated app** -- import the app module, use `supertest(app)` to make requests without starting a server. Assert on status codes, response headers, JSON body shape, and error envelopes. Test both success and error paths for every endpoint. Use `beforeEach` to reset database state or mocks.
-
-13. **Use `express.Router()` to modularize route registration** -- create one router per resource or domain area, register middleware at the router level, and mount routers on the app with `app.use('/api/v1/users', usersRouter)`. This keeps route files focused and lets each module declare its own middleware requirements.
-
-14. **Set security headers beyond Helmet when needed** -- add `Strict-Transport-Security` with `max-age` and `includeSubDomains` for HSTS, `X-Request-Id` for traceability, and `Cache-Control: no-store` on sensitive endpoints. Remove the `X-Powered-By` header with `app.disable('x-powered-by')` or let Helmet handle it.
-
-15. **Implement graceful shutdown that drains connections** -- listen for `SIGTERM` and `SIGINT`, call `server.close()` to stop accepting new connections, drain in-flight requests with a timeout, close database pools and external connections, then exit. This prevents 502 errors during rolling deploys and keeps load balancer health checks accurate.
-
-16. **Sanitize and limit request input** -- set `express.json({ limit: '100kb' })` to prevent large payload attacks. Use `express-mongo-sanitize` or equivalent if using MongoDB to prevent NoSQL injection. Trim and escape string inputs at the validation layer, not in individual handlers.
-
-17. **Use environment-based configuration with validation** -- load configuration from environment variables using a library like `dotenv` for local development and validate required variables at startup with a schema (zod, joi, or envalid). Fail fast with a clear error message if required config is missing, rather than discovering it at runtime when a request hits the missing value.
-
-18. **Log structured JSON with request context** -- use `pino`, `winston`, or a similar structured logger. Attach request ID, user ID, method, path, and response time to every log line. Use a request-logging middleware that creates a child logger with request context and attaches it to `req.log` for use in handlers and services.
-
-## Output Format
-
-Produces TypeScript source files with Express 5.x handler signatures, typed request/response interfaces, router modules, middleware functions, custom error classes, and supertest-based integration tests. Includes `package.json` dependencies and `tsconfig.json` configuration where applicable.
-
-## References
-
-Load only what the current step needs.
-
-| File | Load when |
-| --- | --- |
-| `references/middleware.md` | Middleware authoring, ordering, composition patterns, or built-in middleware configuration is in scope. |
-| `references/error-handling.md` | Centralized error handler, custom error classes, or async error patterns are needed. |
-| `references/typescript-integration.md` | TypeScript setup, typed handlers, declaration merging, or strict mode config is needed. |
-| `references/security.md` | Helmet, CORS, rate limiting, input sanitization, or HSTS configuration is in scope. |
-| `references/testing.md` | Supertest setup, integration tests, mock strategies, or test organization is needed. |
-
-## Claude Platform Notes
-
-- Use `$ARGUMENTS` to access user-provided arguments passed when the skill is invoked.
-- Reference skill-local files with `${CLAUDE_SKILL_DIR}/references/<file>` for portable paths.
-- When `context: fork` is set, the skill runs in an isolated subagent context; the `agent` field names the fork target.
-- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available for dynamic skill discovery and loading.
-- Use `allowed-tools` in frontmatter to restrict tool access for security-sensitive skills.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/express-nodejs/evals/assertions.md

@@ -1,37 +0,0 @@
-# Express Node.js Eval Assertions
-
-## Eval 1: Secure API with Async Error Handling
-
-### typed-handlers-typescript
-Verifies the response uses TypeScript generics on Express request handlers to type `params`, `body`, and `query` separately. The app must be split into `app.ts` (which exports the configured Express app) and `server.ts` (which calls `app.listen()`). This separation is critical for testing with supertest without port binding. The assertion catches responses that use `any` types, skip TypeScript, or combine app creation and listening in a single file.
-
-### security-headers-config
-Verifies Helmet is configured with explicit CSP directives rather than accepting defaults blindly. CORS must use a specific origin allow-list (not `*`) with `credentials: true`. The rate limiter must use an external store (Redis) for production correctness across multiple server instances. This catches responses that use permissive defaults, wildcard CORS, or in-memory rate limiting that breaks in clustered deployments.
-
-### zod-validation-middleware
-Verifies validation is implemented as a reusable middleware function that takes a zod schema and validates the request before it reaches the handler. Validation errors must be transformed into structured field-level error responses (400) derived from ZodError's `issues` array. This catches responses that validate inside handlers, use manual if-checks instead of schema validation, or return unstructured error strings.
-
-### centralized-error-handler
-Verifies custom error classes carry `statusCode` and are caught by a centralized four-parameter error middleware registered as the last middleware. The handler must distinguish between known error types (returning appropriate status codes) and unexpected errors (returning 500 without stack traces). This catches responses that format errors per-handler, leak stack traces, or forget the four-parameter signature that Express requires for error middleware.
-
-### supertest-integration-tests
-Verifies tests use supertest with the imported app module (not a running server) and cover three distinct scenarios: successful creation (201), validation failure (400 with field errors), and rate limit exhaustion (429). This ensures the test suite validates both happy and error paths and confirms the security middleware actually enforces limits.
-
----
-
-## Eval 2: Middleware Composition
-
-### async-timing-middleware
-Verifies the timing middleware correctly measures handler duration and sets the `X-Response-Time` header. The critical detail is that the header must be set even when the handler throws an error, which requires try/finally around the `await next()` call or listening to the response `finish` event. This catches implementations where errors cause the timing header to be lost.
-
-### jwt-auth-declaration-merging
-Verifies the auth middleware validates JWTs and attaches the decoded payload to `req.user`, with TypeScript declaration merging extending the Express `Request` interface. This is the standard TypeScript pattern for adding custom properties to the request object. The assertion catches responses that use `as any` casts, skip typing entirely, or store the user in a non-standard location.
-
-### role-authorization-factory
-Verifies a higher-order function pattern where `authorize('admin', 'editor')` returns a middleware function. The returned middleware checks `req.user.role` against the allowed roles and returns 403 with a structured error for unauthorized access. Tests must verify both allowed and denied scenarios. This catches responses that hardcode roles or skip the factory pattern.
-
-### async-local-storage-logger
-Verifies the use of Node.js `AsyncLocalStorage` to propagate a request-scoped logger through the async call stack without explicit parameter threading. A middleware must create the storage context with the request ID, and a `getLogger()` helper must retrieve it anywhere in the async chain. This is a modern Node.js pattern that replaces `cls-hooked`. The test must verify the request ID survives across async boundaries (e.g., after an `await`).
-
-### composed-stack-tests
-Verifies the middleware pieces are composed into a reusable stack (array of middleware or a composed function) applied to admin routes, and that end-to-end tests validate the combined behavior. Tests must check: timing header on error responses, expired token handling, role-based rejection, and logger context across async boundaries. This ensures the middleware works together, not just in isolation.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/express-nodejs/evals/evals.json

@@ -1,74 +0,0 @@
-[
-  {
-    "id": "express-secure-api",
-    "prompt": "Build a secure Express 5.x REST API in TypeScript for a user management service. Include: typed route handlers with Request generics for params, body, and query; helmet with explicit CSP directives; CORS with an origin allow-list and credentials; express-rate-limit with Redis store for distributed rate limiting; request validation using zod schemas in a reusable validation middleware; custom error classes (AppError, NotFoundError, ValidationError) with statusCode properties; a centralized four-parameter error-handling middleware that formats all errors consistently; structured JSON logging with pino including request ID propagation; and graceful shutdown with connection draining. Include integration tests with supertest covering successful creation, validation failure, and rate limit triggering.",
-    "assertions": [
-      {
-        "id": "typed-handlers-typescript",
-        "type": "contains_concept",
-        "expected": "Route handlers are typed with Express Request generics specifying params, body, and query types, strict TypeScript is enabled, and the app is separated into app.ts (exported) and server.ts (listening) for testability",
-        "weight": 1.0
-      },
-      {
-        "id": "security-headers-config",
-        "type": "contains_concept",
-        "expected": "Helmet is configured with explicit contentSecurityPolicy directives rather than just helmet() defaults, CORS uses an array of allowed origins with credentials:true, and rate limiter is configured with a Redis or external store rather than the default in-memory store",
-        "weight": 1.0
-      },
-      {
-        "id": "zod-validation-middleware",
-        "type": "contains_concept",
-        "expected": "A reusable validation middleware accepts a zod schema, validates req.body (and optionally req.params and req.query), and returns 400 with structured field-level errors derived from ZodError issues, preventing invalid data from reaching the handler",
-        "weight": 1.0
-      },
-      {
-        "id": "centralized-error-handler",
-        "type": "contains_concept",
-        "expected": "Custom error classes extend Error with a statusCode property, and a four-parameter (err, req, res, next) error-handling middleware registered last maps these classes to appropriate HTTP responses, logs unexpected errors with stack traces, and never sends stack traces to clients",
-        "weight": 1.0
-      },
-      {
-        "id": "supertest-integration-tests",
-        "type": "contains_concept",
-        "expected": "Tests import the app module and use supertest to test creation (201 with body), validation failure (400 with field errors matching the zod schema), and rate limit triggering (429 after exceeding threshold), all without starting a real server",
-        "weight": 1.0
-      }
-    ]
-  },
-  {
-    "id": "express-middleware-composition",
-    "prompt": "Create an Express 5.x middleware composition layer in TypeScript with the following pieces: (1) an async request-timing middleware that measures handler duration and sets X-Response-Time header, (2) an async authentication middleware that validates JWTs from the Authorization header and attaches the decoded user to req.user using declaration merging, (3) a role-based authorization middleware factory that takes allowed roles and returns a middleware checking req.user.role, (4) a request-scoped logger middleware using AsyncLocalStorage to make the logger available without passing it through every function call, (5) compose these into a reusable middleware stack for protected admin routes. Write tests that verify: timing header is set even when handlers throw, auth rejects expired tokens with structured errors, role middleware returns 403 for unauthorized roles, and AsyncLocalStorage logger carries the request ID across async boundaries.",
-    "assertions": [
-      {
-        "id": "async-timing-middleware",
-        "type": "contains_concept",
-        "expected": "Timing middleware records start time, calls next() with await, then sets X-Response-Time header with the computed duration in milliseconds. It wraps next() in a try/finally or uses the response finish event so the header is set even when downstream handlers throw errors",
-        "weight": 1.0
-      },
-      {
-        "id": "jwt-auth-declaration-merging",
-        "type": "contains_concept",
-        "expected": "Auth middleware validates JWT from Bearer token, decodes it, and attaches the payload to req.user. TypeScript declaration merging extends the Express Request interface to include the user property so downstream handlers have type-safe access without casting",
-        "weight": 1.0
-      },
-      {
-        "id": "role-authorization-factory",
-        "type": "contains_concept",
-        "expected": "A factory function like authorize(...roles: string[]) returns a middleware that checks req.user.role against the allowed roles array and calls next() on match or responds with 403 and a structured error on mismatch, with the test verifying both allowed and denied access",
-        "weight": 1.0
-      },
-      {
-        "id": "async-local-storage-logger",
-        "type": "contains_concept",
-        "expected": "A middleware uses Node.js AsyncLocalStorage to store a request-scoped logger instance with the request ID, and downstream code retrieves it via a getLogger() helper without explicit parameter passing. The test verifies the logger carries the request ID across async operations within the same request",
-        "weight": 1.0
-      },
-      {
-        "id": "composed-stack-tests",
-        "type": "contains_concept",
-        "expected": "The middleware stack is composed into a reusable array or function applied to admin routes, and tests verify end-to-end behavior: timing header present on error responses, expired token rejection with structured JSON, 403 for wrong role, and logger context surviving async boundaries in the handler",
-        "weight": 1.0
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/express-nodejs/examples/01-secure-api-typescript.md

@@ -1,226 +0,0 @@
-# Example: Secure TypeScript API
-
-## Prompt
-
-> Build a secure Express 5.x API in TypeScript for user management with helmet, CORS, rate limiting, zod validation, custom error classes, and supertest tests.
-
-## Expected Output
-
-The skill should produce a TypeScript Express application with full security and testing:
-
-### Application Setup (app.ts)
-
-```typescript
-import express, { Request, Response, NextFunction } from 'express';
-import helmet from 'helmet';
-import cors from 'cors';
-import rateLimit from 'express-rate-limit';
-import RedisStore from 'rate-limit-redis';
-import { createClient } from 'redis';
-import pino from 'pino';
-import { pinoHttp } from 'pino-http';
-import { v4 as uuidv4 } from 'uuid';
-import { usersRouter } from './routes/users';
-import { errorHandler } from './middleware/error-handler';
-
-const logger = pino({ level: process.env.LOG_LEVEL || 'info' });
-
-const app = express();
-
-// Security headers with explicit CSP
-app.use(helmet({
-  contentSecurityPolicy: {
-    directives: {
-      defaultSrc: ["'self'"],
-      scriptSrc: ["'self'"],
-      styleSrc: ["'self'", "'unsafe-inline'"],
-      imgSrc: ["'self'", 'data:', 'https:'],
-    },
-  },
-  hsts: { maxAge: 31536000, includeSubDomains: true },
-}));
-
-// CORS with allow-list
-app.use(cors({
-  origin: (process.env.CORS_ORIGINS || '').split(',').filter(Boolean),
-  credentials: true,
-  methods: ['GET', 'POST', 'PUT', 'DELETE'],
-}));
-
-// Body parsing with size limit
-app.use(express.json({ limit: '100kb' }));
-
-// Request logging with ID
-app.use(pinoHttp({
-  logger,
-  genReqId: (req) => req.headers['x-request-id'] as string || uuidv4(),
-}));
-
-// Rate limiting with Redis store
-const limiter = rateLimit({
-  windowMs: 15 * 60 * 1000,
-  max: 100,
-  standardHeaders: true,
-  legacyHeaders: false,
-  store: new RedisStore({
-    sendCommand: (...args: string[]) => redisClient.sendCommand(args),
-  }),
-});
-app.use(limiter);
-
-// Routes
-app.use('/api/v1/users', usersRouter);
-
-// Error handler MUST be last
-app.use(errorHandler);
-
-export { app };
-```
-
-### Custom Error Classes
-
-```typescript
-export class AppError extends Error {
-  public readonly statusCode: number;
-  public readonly code: string;
-
-  constructor(message: string, statusCode: number, code: string) {
-    super(message);
-    this.statusCode = statusCode;
-    this.code = code;
-    Object.setPrototypeOf(this, new.target.prototype);
-  }
-}
-
-export class NotFoundError extends AppError {
-  constructor(resource: string) {
-    super(`${resource} not found`, 404, 'NOT_FOUND');
-  }
-}
-
-export class ValidationError extends AppError {
-  public readonly fields: Array<{ field: string; message: string }>;
-
-  constructor(fields: Array<{ field: string; message: string }>) {
-    super('Validation failed', 400, 'VALIDATION_ERROR');
-    this.fields = fields;
-  }
-}
-```
-
-### Zod Validation Middleware
-
-```typescript
-import { z, ZodSchema } from 'zod';
-import { Request, Response, NextFunction } from 'express';
-
-export function validate(schema: ZodSchema) {
-  return (req: Request, _res: Response, next: NextFunction) => {
-    const result = schema.safeParse(req.body);
-    if (!result.success) {
-      const fields = result.error.issues.map((issue) => ({
-        field: issue.path.join('.'),
-        message: issue.message,
-      }));
-      throw new ValidationError(fields);
-    }
-    req.body = result.data;
-    next();
-  };
-}
-
-const createUserSchema = z.object({
-  email: z.string().email(),
-  name: z.string().min(1).max(100),
-  role: z.enum(['admin', 'editor', 'viewer']),
-});
-```
-
-### Centralized Error Handler
-
-```typescript
-export function errorHandler(
-  err: Error,
-  req: Request,
-  res: Response,
-  _next: NextFunction
-): void {
-  if (err instanceof ValidationError) {
-    res.status(err.statusCode).json({
-      code: err.code,
-      message: err.message,
-      details: err.fields,
-    });
-    return;
-  }
-
-  if (err instanceof AppError) {
-    res.status(err.statusCode).json({
-      code: err.code,
-      message: err.message,
-    });
-    return;
-  }
-
-  // Unexpected error -- log full stack, send generic message
-  req.log.error({ err }, 'Unhandled error');
-  res.status(500).json({
-    code: 'INTERNAL_ERROR',
-    message: 'An unexpected error occurred',
-  });
-}
-```
-
-### Integration Tests
-
-```typescript
-import request from 'supertest';
-import { app } from '../app';
-
-describe('POST /api/v1/users', () => {
-  it('creates a user with valid input', async () => {
-    const res = await request(app)
-      .post('/api/v1/users')
-      .send({ email: 'test@example.com', name: 'Test User', role: 'editor' })
-      .expect(201);
-
-    expect(res.body).toHaveProperty('id');
-    expect(res.body.email).toBe('test@example.com');
-  });
-
-  it('returns 400 with field errors for invalid input', async () => {
-    const res = await request(app)
-      .post('/api/v1/users')
-      .send({ email: 'not-an-email', name: '' })
-      .expect(400);
-
-    expect(res.body.code).toBe('VALIDATION_ERROR');
-    expect(res.body.details).toEqual(
-      expect.arrayContaining([
-        expect.objectContaining({ field: 'email' }),
-        expect.objectContaining({ field: 'name' }),
-      ])
-    );
-  });
-
-  it('returns 429 when rate limit is exceeded', async () => {
-    // Send requests up to the limit
-    for (let i = 0; i < 100; i++) {
-      await request(app).get('/api/v1/users');
-    }
-
-    const res = await request(app).get('/api/v1/users');
-    expect(res.status).toBe(429);
-  });
-});
-```
-
-## Key Observations
-
-- App is exported separately from server listening for testability.
-- Helmet CSP directives are explicit, not just defaults.
-- CORS uses a split-and-filter pattern for environment-based allow-lists.
-- Rate limiter uses Redis store for distributed correctness.
-- Zod validation middleware is reusable across routes.
-- Error handler maps typed errors to structured responses and never leaks stack traces.
-- Tests cover success, validation failure, and rate limiting without a running server.