# Installation and bootstrap

Production initialization and synthetic development seeding are separate.
Neither readiness nor migration generates business master data automatically.

## Production bootstrap

1. Prepare PostgreSQL, the virtual environment and pinned production requirements.
   Use the existing deployment configuration and strong independent secrets.
   Keep `.env` untracked; never put passwords in command arguments or chat.
   Existing settings read DB_PASSWORD exclusively from the local `.env` without
   interpolation. Provision that file through your deployment secret process.
   Configure explicit allowed hosts, trusted origins and HTTPS for production.
2. Select `config.settings.production` explicitly. Validate configuration, then
   apply existing migrations; do not fake, edit or reset historical migrations.
3. Create the first real staff superuser interactively. There are no default
   administrator credentials. Log in to `/admin/` or `/login/` and use `/settings/`.
4. Create the real company, region and service center in that order; configure
   company departments only where needed. Use existing lifecycle actions.
5. Create staff accounts only for intended Admin responsibilities. Create normal
   operational users, organizational assignments, role permission memberships,
   then role assignments. Set primary assignments explicitly. Groups/native
   permissions/staff status alone do not create business scope. Review each role
   against the actual company/region/center/department responsibilities.
6. Configure product brands, categories and models (variants where needed), then
   deliberate device identification policies. Configure real service taxonomy
   and Product Category applicability. Do not invent a Complaint → ServiceCategory
   relationship or an Unknown RootCause record.
7. Configure parts/compatibility and inventory locations if needed. Receive real
   opening stock through supported inventory workflows with real evidence; never
   seed balances, synthetic serials or ledger rows. Configure appointment slots,
   notification templates and SLA policies if those features are used.
8. Configure communication adapters and their secrets outside ordinary database
   settings. Verify the actual provider separately before authorized dispatch.
   This phase does not supply a live vendor adapter, scheduler or credentials.
9. Run installation readiness, address REQUIRED gaps, and review recommendations
   and optional feature coverage. Follow the existing deployment/system checks;
   readiness is not a production certification or a full regression audit.

PowerShell examples (with production environment configuration already prepared):

```powershell
python manage.py check --settings=config.settings.production
python manage.py migrate --settings=config.settings.production
python manage.py createsuperuser --settings=config.settings.production
python manage.py check_installation_readiness --settings=config.settings.production
```

Readiness returns nonzero when REQUIRED setup is missing. Use `--json` for
structured results. An empty migrated database is expected to fail until real
organization, administrator and catalog configuration is supplied. Customer and
device data are created during real operations, not invented to pass readiness.

## Development/demo bootstrap

Use only a **disposable local development/test database** with the existing
development settings and DEBUG=True:

```powershell
python manage.py migrate --settings=config.settings.development
python manage.py seed_demo_data --confirm-development --settings=config.settings.development
```

The command requires the exact existing development settings module, DEBUG=True,
PostgreSQL on localhost/127.0.0.1/::1, and explicit development confirmation.
Production settings are rejected even if DEBUG was manually set true. Remote
database hosts and unknown settings modules are refused. These guards do not
identify the business purpose of a localhost database: the operator must select
a disposable database, never a production database behind a local proxy.

The seed creates one reserved `CCARE-DEMO` chain:

- company, region, service center and department;
- non-staff, non-superuser `ccare-demo-operator`, company-wide demo assignment,
  explicit operational permission bundle and role assignment;
- one demo brand/category/model and a serial-required, IMEI-not-applicable policy;
- one complaint, fault diagnosis and repair action applicable only to that demo
  product category; **no fabricated RootCause**;
- a demo part/category with model-wide compatibility and one empty store;
- `Synthetic Demo Customer` using `customer@ccare-demo.invalid`, one device with
  reserved synthetic serial `CCARE-DEMO-SERIAL-0001`, and recorded ownership;
- one RECEIVED walk-in case with a complaint and an immutable SLA enrollment;
- one email template and one center SLA policy, neither auto-dispatched.

The example case was accepted at **2025-01-01 09:00 UTC**. Its one-day elapsed SLA
is intentionally an old/overdue demonstration, not a representation of a newly
received production job. The deterministic fixture adds no appointment slots
that become stale every day; configure actual demonstration dates through the
Configuration Center. It posts no stock, quotation, invoice, payment or outbound
message and grants no communications-send permission. No superuser is created.

New demo accounts have an **unusable password** by default. To enable or explicitly
reset only that demo login, run:

```powershell
python manage.py seed_demo_data --confirm-development --set-password --settings=config.settings.development
```

The command prompts twice without echo and uses existing Django password
validators. There is no fixed demo password, password argument or password
printed to output. Subsequent runs without `--set-password` do not change an
existing password. Use an independently created local superuser to exercise
global Admin configuration. The demo operator can use scoped operations and
slot/template/SLA configuration; it cannot administer global users/RBAC/catalogs.

## Idempotency, conflicts and history

The fixture has deterministic reserved identities/natural keys; generated domain
UUIDs and number sequences remain owned by existing services. It is one atomic
transaction, with a PostgreSQL transaction advisory lock serializing seed runs.
All creation uses existing validated models or supported domain services. No raw
INSERT/UPDATE, signal disabling, history rewrites or artificial ledger writes are
used. Repeated commands verify existing records and do not duplicate the chain.

The seed does not repair manually changed configuration, restore inactive
records or silently regrant changed role permissions. Reserved-code/identifier
collisions fail without overwriting data. A failure rolls back the entire seed
transaction, including an explicitly requested password change. Existing demo
case lifecycle progress (including cancellation) is preserved on repeat runs.
If demo configuration has intentionally changed, keep it and stop reseeding; use
a separate disposable database for a fresh demonstration, not a destructive
reset command. No reset/clean command is supplied.

For an optional local administrative check:

```powershell
python manage.py check_installation_readiness
```

Demo data alone does not create the required initial administrative login.
Readiness may also recommend a usable operator password and show optional
appointment/provider gaps. That is intentional; it must not fabricate setup or
weaken frozen requirements to report success.

## Verification and limits

Focused tests use isolated synthetic PostgreSQL databases. Development seeds are
not run against the working application database as part of implementation.
Production refusal, idempotency, collision rollback, lifecycle preservation,
configuration scope and concurrent seed execution are tested. This phase does
not perform a full audit, import live business data, configure external providers
or certify production hosting. See SYSTEM_CONFIGURATION.md for inventory and
the exact readiness criteria.