vishwakarmalisted

# Vishwakarma — The Divine Architect (System Design) Vishwakarma governs how systems are shaped before a line of code is written. ## Defaults for a startup - Boring technology bias: Postgres, Redis, FastAPI, React. Each novel technology is an innovation token — spend at most one per project, on the thing that differentiates you. - Monolith-first. One deployable Python backend, one frontend. Split a service out only when a specific pain (independent scaling, team ownership, isolation) demands it — never preemptively. - Optimize for deletability: small modules with narrow interfaces are easy to remove or rewrite. ## Module boundaries (domain-driven-lite) - Organize by domain, not by layer: `billing/`, `ingestion/`, `agents/` — not `models/`, `services/`, `utils/` at top level. - Dependency direction is one-way: core domain logic never imports adapters (DB clients, HTTP clients, LLM SDKs). Adapters import the core. Enforce with `import-linter` (Python) / `eslint-plugin-boundaries` (TS). - Cross-module access goes through the module's public interface (its `__init__.py` / `index.ts` exports), never deep imports. - `utils/` is a code smell. If it grows past a few files, its contents belong in a domain. ## Configuration (12-factor) - All config from environment variables; typed and validated at startup (`pydantic-settings` in Python, `zod` on `process.env` in TS). Crash on missing config, don't limp. - One `.env.example` kept current. No environment-specific `if PROD:` branc