# GE-Enforce client integration (shopdb manifest source + reporting)

This is the client-side contract for the GE-Enforce manifest-store plugin: how a
PC sources its install manifest from shopdb instead of a share file, and how it
reports its enforcement result back. It pairs with the plugin proposal in
`docs/proposals/ge-enforce-plugin.md`.

The reference kit lives in `plugins/geenforce/client/`:

- `ShopdbEnforceClient.psm1` - fetch (with ETag + last-known-good cache),
  shadow compare, and report helpers.
- `Invoke-ShopdbEnforce.ps1` - a reference orchestrator that fetches a manifest,
  runs the UNCHANGED engine against it, and reports the result.

These are site-neutral references, not the live dispatcher. A site adapts them
into its GE-Enforce.ps1 flow. The engine (`Install-FromManifest.ps1`),
detection, self-heal, and SMB payload resolution are untouched - only the source
of the manifest JSON moves, plus a result report.

## What does NOT change

- The engine and its four filters, all detection methods, self-heal, marker
  files, and SMB payload staging.
- Payload transport for `smb` rows: the client still mounts the share and
  resolves `apps/...` paths exactly as today. Only the manifest JSON source moves.
- The fail-safe posture: any error exits 0. A PC is never blocked or broken
  because shopdb is unreachable.

## Configuration

Registry (provisioned by Azure DSC, same channel as the SFLD credentials):

```
HKLM:\SOFTWARE\GE\ShopDB
  BaseUrl   https://shopdb.<site>.geaerospace.net
  ApiToken  <a geenforce.fetch (+ geenforce.report) managed service token>
```

Mint the token in shopdb: Settings > API Tokens, scopes `geenforce.fetch` and
`geenforce.report`. It is a service token (owner must hold those permissions).

## Fetch contract

```
GET /api/geenforce/manifest?pctype=<scope>[&phase=runtime]
    X-API-Key: <token>
    If-None-Match: <cached ETag>     (optional)
```

- `200` - body is the full published manifest JSON for the scope (fat client:
  the engine filters locally, exactly as today). Response headers carry `ETag`
  and `X-Manifest-Version`. Cache the body + ETag + version.
- `304` - your cached copy is current; use it.
- `404` - no such scope, or the scope has no published version yet.
- Network failure - enforce from the last-known-good cached manifest (the kit
  does this automatically) and log a warning.

The served manifest is always the current PUBLISHED snapshot, never a live draft
being edited in shopdb, so a half-finished edit can never reach a PC.

## Report contract

Each enforcement cycle, POST the result (best-effort; a failed report never
fails the cycle):

```
POST /api/geenforce/report
    X-API-Key: <token>
    Content-Type: application/json
{
  "hostname": "WJCMM01",
  "scopename": "gea-shopfloor-cmm",
  "appliedversion": 3,            // the published version you actually ran
  "enforcerversion": "2.6",
  "counts":  { "installed": 1, "skipped": 3, "failed": 0, "filtered": 2 },
  "results": [
    { "name": "PC-DMIS 2019 R2", "action": "installed", "selfhealed": true },
    { "name": "Protect Viewer",  "action": "skipped" },
    { "name": "eDNC",            "action": "failed", "exitcode": 1603,
      "message": "MSI 1603" }
  ]
}
```

- `appliedversion` lets shopdb show which PCs received the latest manifest
  (`receivedlatest` in the fleet view).
- `action` per entry: `installed` (fired - a self-heal when it should already be
  present), `skipped` (detected present), `failed`, `filtered`. `selfhealed`
  marks a drift correction.
- shopdb keeps the latest report per (hostname, scope, phase) plus history, and
  surfaces it under Settings > Enforcement Reports.

The engine already computes these counts (`installed/skipped/failed/pcFiltered`
at the end of its main loop) and knows each entry's action; shape them into the
`results` list at the call site (`New-ShopdbReport` in the kit takes a summary
with `Installed/Skipped/Failed/Filtered` + a `Results` list).

## Cutover (safe, staged)

1. **Configure** the registry values on a canary PC; mint the token.
2. **Shadow mode**: run `Invoke-ShopdbEnforce.ps1 -ShadowMode -ShareManifestPath
   <current share manifest>`. It installs from the SHARE (no behavior change),
   fetches the shopdb manifest, logs any diff, and reports. Watch for zero diffs
   across one PC of every pctype for ~20 cycles.
3. **Read cutover**: drop `-ShadowMode`. The engine now runs against the
   shopdb-sourced manifest; payloads still come from the share. Rollback is a
   one-line revert to the share-sourced call. Keep exporting manifests from
   shopdb to the share (Settings > Imaging PC Types > Export to Share) so the
   share stays a break-glass copy.
4. **Payload migration** (optional, later): move small scripts/configs to
   `http`/`inline` payloads, verified by `payloadsha256`. Big MSIs stay on SMB.

Do not cut a fleet over before the shadow diffs are clean. Preinstall
(`phase=preinstall`) stays share-sourced until its own cutover is planned - it
runs before enrollment provisions a token.

## Security notes

- The client runs as SYSTEM, so shopdb's TLS certificate must be in the machine
  trust store (air-gapped/self-signed sites provision the CA via the same DSC
  step as the token).
- `http`/`inline` payloads are verified against `payloadsha256` before running,
  independent of how the entry detects install state. This is the real integrity
  guarantee and holds even over plain HTTP inside a trusted segment.
- The token is a scoped service token: it can fetch manifests and report, and
  nothing else.