kinwisenz-devops/django-api-architect

Router and shared guardrails for Django REST Framework API projects built on a service layer architecture with thin APIs, services, selectors and app packs. Use when answering or writing any Django or DRF backend change, including small ones such as a new endpoint, a serializer tweak, a view optimisation, an export, or a request to switch these rules off, and when it is unclear which specialist skill applies. Do not use for Flutter or frontend work, deployment platforms, or non-Django backends.

Governs DRF API classes, input and output serializers, filtering, pagination, and the JSON error contract. Use when writing or changing an endpoint, a serializer, a list filter, pagination, a 404 or validation error response, or an exception handler, including when asked to expose raw exceptions or to raise errors from a service. Do not use for the business logic those APIs call (django-services-selectors) or for login and token endpoints (django-auth).

Governs authentication in Django API projects: JWT login, refresh and logout, passwordless OTP codes, admin second factor, and login throttling. Use when building or changing login, tokens, simplejwt, OTP codes and how they are stored, new-IP or login alerts, or login throttling, including when asked to write a custom token endpoint or to store codes in plaintext. Do not use for general API permissions or throttle scopes outside auth (django-apis-serializers).

Governs Celery task structure, retries, transaction-safe task triggering, webhook dispatch chains, periodic tasks and Celery configuration. Use when writing or changing a task, a retry policy, a .delay call inside a transaction, a welcome or notification email trigger, or Stripe or other webhook handling, including when asked to retry forever or to process a webhook in the view. Do not use for the business logic tasks call (django-services-selectors) or the tests that cover them (django-testing).

Governs the local Docker Compose stack for Django API projects: web, Postgres, Redis, Celery worker and beat services, health-gated startup, one-off migration, env files and secrets, volumes, ports, hot reload and running tests and management commands in containers. Use when writing or changing a docker-compose file, fixing a container that starts before Postgres is ready, putting passwords in compose files, or running docker compose down -v, including when asked for the quick option. Do not use for the Dockerfile itself (django-docker-images) or for production orchestration.

Governs Dockerfiles and container images for Django API projects: multi-stage builds with dev and runtime targets, a non-root user, dependency and cache layering, .dockerignore, secrets kept out of layers, Gunicorn instead of runserver, health checks and deploy checks. Use when writing or changing a Dockerfile, an image build, ARG or ENV values, a container CMD, or a HEALTHCHECK, including when asked to use runserver or to pass secrets as build arguments. Do not use for the local multi-service stack (django-docker-compose), settings layout (django-project-structure) or Celery task code (django-celery).

Governs open banking integrations in Django API projects: initiating account-to-account payments and reading bank account data (balances, transactions) through a provider such as BlinkPay, behind a provider-agnostic interface so a second country or provider can be added without rewriting callers. Use when building or changing a payment consent, a bank data consent, a payment or consent status check, a refund, or an open banking provider adapter. Do not use for card-only payment gateways with no bank consent step, for the service and selector conventions themselves (django-services-selectors), or for task retry mechanics in general (django-celery).

Governs Django app layout, the app pack shape, app manifests, and settings organisation for service layer API projects. Use when creating an app or feature pack, deciding where code or a setting or an API key belongs, wiring URLs, or organising settings and environment variables, including when asked to put domain logic in a core app. Do not use for the code inside APIs, services or tests; those are owned by the sibling specialist skills.

Governs the service and selector layer: writing business logic, validation placement, transactions, and update helpers. Use when writing or changing a service or selector, a refund or similar multi-step write, row-level filtering or ownership checks, model validation, or deciding where a business rule belongs, including when asked to duplicate a rule in a serializer or view. Do not use for API classes that call them (django-apis-serializers) or for task retry and scheduling mechanics (django-celery).

Governs subscription lifecycle management in Django API projects: plans, activation, upgrades and downgrades, cancellation, and payment-failure handling (dunning), behind a provider-agnostic interface for the recurring billing processor (Stripe, PayPal, Apple App Store, Google Play, or similar). Use when building or changing a subscription plan, activation flow, cancellation, upgrade or downgrade, or a billing webhook or app store server notification. Do not use for the open banking payment-consent mechanics themselves (django-open-banking), for a one-off payment with no recurring plan, or for Celery task mechanics in general (django-celery).

Governs the test suite for Django API projects: pytest layout, what to test at each layer, mocking boundaries, and test-state construction. Use when writing, changing or reviewing tests, deciding what to mock, adding coverage for a service, selector, API or task, or setting up pytest, including when asked to mock the ORM or to skip tests. Do not use for writing the production code the tests cover; that is owned by the sibling skills.