# ADR 0001: Django foundation and identifiers

Status: Accepted

## Context

The system will cover multiple after-sales domains but currently requires only a
secure, testable foundation. Authentication and identifiers must be decided before
initial migrations.

## Decisions

- Use a modular Django monolith with domain apps under apps/. This keeps deployment
  and transactions simple while leaving room for explicit domain boundaries.
- Use PostgreSQL through psycopg. No SQLite fallback, even for tests.
- Introduce accounts.User extending AbstractUser before the first migration.
  Keep Django groups, permissions, staff flags, password handling, and UserAdmin.
- Use UUID v4 primary keys for User and as the default policy for future business
  entities. Declare UUIDField explicitly on each such model. Any domain exception
  requires a documented decision. UUIDs are identifiers, not authorization tokens.
- Retain Django-owned models' native numeric keys and BigAutoField for implicit
  framework/join tables. This is an intentional boundary, not arbitrary mixing.
- UUIDs allow identifiers to be created without coordinating a sequence and reduce
  enumeration. Costs include larger indexes, less convenient manual inspection,
  and poorer insertion locality than ordered keys. UUID v4 is standard-library
  supported and sufficient at this stage; no identifier abstraction is needed.
- Split common, development, and production settings. Keep production strict and
  default deployed entry points to it; local management defaults to development.
- Load local secrets through python-dotenv; never commit .env. Fail on missing
  required secrets. Production requires a separate strong key and explicit hosts.

## Consequences

Changing User identifiers later would be costly, so the initial migration fixes
this choice now. Framework-native authentication minimizes custom security code.
Business RBAC, organizational scope, audit, and timestamp abstractions are deferred
until concrete requirements justify them.