# Architecture The current developer product is organized into three layers that already exist in the repo. ## Control Plane - apps/developer for docs, dashboard views, and product-facing workflows. - Project, site, environment, API key, policy, and usage surfaces in services/dev-protection. - Authz and gateway routing through services/api-gateway when required. ## Runtime Plane - services/dev-eval serves the six /v1/dev/* runtime evaluator routes. - Emit canonical decision events with correlation ids and policy audit data. - Persist decisions into the same developer decision log used by control-plane analytics. ## SDK Layer - @cosantoir/next, @cosantoir/express, @cosantoir/hono, @cosantoir/fastify, @cosantoir/bun, @cosantoir/deno, @cosantoir/nestjs, and @cosantoir/sveltekit for framework-first installs. - @cosantoir/node for direct runtime calls and custom adapters. - Native SDKs for Go, Python, and Rust services. - Backend-contract integrations for services that already own their middleware stack. ## Request Flow 1. Application traffic enters your protected route or middleware. 2. The SDK adapter derives request context such as path, method, IP, user agent, and correlation id; the backend resolves the site from the runtime API key. 3. services/dev-eval evaluates the configured module policies. 4. The service applies runtime hardening, writes a decision event, and returns headers such as X-RateLimit-*, Retry-After, x-dev-policy-cache, x-dev-billing-cache, and x-dev-replay-status when relevant. 5. The developer dashboard aggregates the resulting usage and analytics state. ## Current Boundary - The SDK contract stays stable even though the control plane and eval plane are now separate services. - Gateway routing keeps /v1/dev/* public paths unchanged while steering control and runtime traffic to different upstreams.