# Case Files cook operations

## Local daily schedule

`@oshun/v10-case-files-cook:cook-tomorrow` is a one-shot cron-style target. It
resolves tomorrow in the configured product IANA zone, uses today's local
midnight as the deterministic batch issuance instant, and invokes the same
fail-closed cook and immutable persistence path as the explicit `cook` target.

Provision a root-readable environment file outside the repository (for example
`/etc/oshun/case-files-cook.env`):

```sh
CASE_FILES_TIME_ZONE=America/New_York
CASE_FILES_PRIVATE_KEY_FILE=/run/secrets/case-files-ed25519-private.pem
CASE_FILES_PUBLIC_KEY_FILE=/etc/oshun/case-files-ed25519-public.pem
CASE_FILES_SIGNING_KEY_ID=case-files-prod-2026-01
CASE_FILES_OUT_DIR=/var/lib/oshun/case-files/cooked
```

Then install a single-host cron entry. `flock` prevents overlapping cooks and a
non-zero exit remains visible to cron/monitoring:

```cron
CRON_TZ=America/New_York
15 2 * * * cd /srv/oshun && flock -n /run/lock/oshun-case-files-cook.lock sh -c 'set -a; . /etc/oshun/case-files-cook.env; set +a; exec pnpm exec nx run @oshun/v10-case-files-cook:cook-tomorrow' >>/var/log/oshun/case-files-cook.log 2>&1
```

For a governed backfill or local smoke test, pass an observed instant
explicitly:

```sh
pnpm exec nx run @oshun/v10-case-files-cook:cook-tomorrow -- \
  --now 2026-07-23T12:00:00.000Z
```

## Production deployment seam

The repository target is deliberately a one-shot job, not a claim of deployed
infrastructure. A production scheduler (Kubernetes CronJob with
`.spec.timeZone`, Cloud Scheduler, or the platform's equivalent) should invoke
it once daily with:

- single-job concurrency or a distributed lease;
- private key material mounted from a secret manager, never stored in the image
  or passed as a command-line value;
- a stable key id whose public key is already present in the client trust
  registry;
- a durable, encrypted filesystem mount for `CASE_FILES_OUT_DIR`, followed by
  the platform-owned promotion/upload into immutable object storage;
- captured stdout/stderr, non-zero-exit alerting, and an alert if tomorrow's
  edition is absent after the expected completion window; and
- retention of the canonical cooked JSON as sealed content until the channel
  adapter releases only its time-appropriate projection.

Retries must reuse the same date/zone/key configuration. They report `unchanged`
for identical bytes and fail if an existing edition drifts or has unsafe
permissions. Key rotation changes the signature and therefore requires a new
governed edition/revision rather than overwriting the existing case id.