# Offline Strategy — Ninja Nexus

## Princip: Offline-first hvor muligt

Ninja Nexus skal fungere i miljøer med ustabil netværk (kontor, hjemmearbejde, feltarbejde, skibe, fabrikker). Windows kører altid lokalt; Nexus skal matche denne forudsigelighed.

---

## Offline-kapabilitetsmatrix

| Funktion | Offline | Grace period | Kræver sync |
|----------|:-------:|:------------:|:-----------:|
| Login (første gang) | ❌ | — | Ja |
| Login (returnerende) | 🟡 | 24–72 timer | Ved udløb |
| Desktop / Shell | ✅ | Ubegrænset | Nej |
| Launcher (cached apps) | ✅ | Ubegrænset | Nej |
| App-start (installerede) | ✅ | Ubegrænset | Nej |
| App install (ny) | ❌ | — | Ja |
| Politik-anvendelse (cached) | ✅ | Ubegrænset | Nej |
| Politik-opdatering | ❌ | — | Ja |
| Inventar-rapportering | 🟡 | Kø lokalt | Ved forbindelse |
| MFA | ❌ | — | Ja |
| Remote support | ❌ | — | Ja |
| Password reset | ❌ | — | Ja |

---

## Lokal datalagring (Agent)

```
%ProgramData%\NinjaNexus\
├── agent.db              # SQLite (encrypted) — policies, queue, inventory
├── cache/
│   ├── policies/         # Seneste policy-sæt
│   ├── packages/         # Downloadede install-pakker
│   └── manifests/        # App catalog snapshot
├── certs/
│   └── device.pfx        # Device certificate (TPM-backed preferred)
└── logs/
    └── agent.log         # Rotating, max 100MB
```

**Kryptering:** SQLite med SQLCipher eller application-level AES-256. Nøgle bundet til TPM hvor muligt.

---

## Lokal datalagring (Shell)

```
%AppData%\NinjaNexus\
├── profile.json          # Brugerprofil, widgets, layout (encrypted)
├── launcher-index.db     # Cached app-liste
├── tokens.enc            # Refresh token (encrypted, short-lived access in memory)
└── assets/               # Baggrunde, ikoner
```

---

## Sync-strategi

### Ved forbindelse genoprettet

```
1. Agent: flush offline queue (FIFO, max 10.000 events)
2. Agent: push inventory delta
3. Agent: pull policy changes (ETag-baseret)
4. Agent: check pending install jobs
5. Shell: refresh profile og app catalog
6. Shell: validate session (refresh token)
```

### Conflict resolution

| Datatype | Strategi |
|----------|----------|
| Politikker | Server wins (altid) |
| Brugerprofil (widgets, layout) | Seneste timestamp wins; merge arrays |
| Inventar | Server merge med agent delta |
| App catalog | Server wins; agent beholder downloaded packages |
| Audit events | Agent queue → server append (ingen conflict) |

---

## Offline login (grace period)

1. Ved succesfuldt online-login gemmes refresh token krypteret lokalt
2. Offline login: Shell validerer lokal token + device trust score
3. Grace period: konfigurerbar (default 48 timer, max 72)
4. Efter grace: tvungen online-login
5. Admin kan revoke sessions remote → næste online-check fejler

**Sikkerhed:** Offline login giver **reduceret** adgang (ingen nye apps, ingen policy-ændringer, evt. read-only apps).

---

## Kø-system (Agent)

```json
{
  "queue_item": {
    "id": "uuid",
    "type": "inventory|compliance|audit|install_status",
    "payload": {},
    "created_at": "ISO8601",
    "retry_count": 0,
    "max_retries": 10
  }
}
```

- Kø persisteres i SQLite
- Ved overflow (>10.000): drop ældste non-kritiske; behold audit og compliance
- Kritiske events prioriteres ved sync

---

## Netværks-detektion

Agent monitorerer:
- Windows network connectivity API
- DNS resolution af Control Center endpoint
- HTTPS health check (HEAD request, timeout 5s)

Tilstande: `online` | `degraded` (latency >2s) | `offline`

Shell abonnerer på Agent-tilstand via IPC.

---

## Testscenarier (Fase 1+)

1. Login online → disconnect 48t → arbejd → reconnect → sync OK
2. Policy push offline → anvendes ved genoprettet forbindelse
3. App install requested offline → kø → install ved forbindelse
4. Session revoke online → offline grace nægtet ved næste check
5. Kø overflow → audit bevares, ældste telemetry droppes

---

*Se også: [DATA_FLOW.md](./DATA_FLOW.md) · [CLIENT_SERVER_ARCHITECTURE.md](./CLIENT_SERVER_ARCHITECTURE.md)*
