DDP_backend

When computing a value, status, or derived property of a domain entity (KPI, metric, alert, chart, dashboard, etc.) from outside that entity's own service module, ask the owning service instead of rebuilding the logic. Use when writing a feature that touches another domain's data, fixing a bug whose root cause is parallel implementations drifting, or reviewing code that copies SQL/query-builder patterns from another module.

Prefer typed Pydantic/Ninja schemas over generic dicts when passing structured data through Dalgo backend code. Use when writing or modifying functions whose parameters represent a known shape (configs, payloads, deserialized JSONField values, frontend payloads). Skip for genuinely free-form / variable-shape data.

Scaffold and ship a new HTTP endpoint in the Django/Ninja backend using the API → Core → Schema → Exceptions layout. Use when adding a new route, creating a new module's routes, or extending an existing router with another verb.

Python coding standards for the DDP_backend covering service-layer function signatures (payload + orguser shape), exception chaining with `raise ... from err`, and import placement (top-of-file only). Use when writing or refactoring service-layer code, reviewing a diff or PR, asking "is this the right pattern", or finalizing code.

Write and run pytest tests for the Django/Ninja backend — service-level tests, API endpoint tests with mocked requests, fixture conventions, and mocking external services (Airbyte, Prefect, warehouses, Redis). Use when writing tests, adding tests, debugging test failures, or asked to test an endpoint or service.

Connect to a client's warehouse (Postgres or BigQuery) from service-layer code using `WarehouseFactory.get_warehouse_client(org_warehouse)`. Use when the code needs to read or write a client's data, execute SQL against their warehouse, inspect schema, or work with `OrgWarehouse`. Never use the legacy `old_client` namespace.