…nbook

Closes the KR-D-DAEMON + KR-D-DEPLOY arc. Pure docs; operator-facing.
Joshua can `flyctl deploy` to staging when ready.

## Two deliverables

### `kora_docs/15_status_and_roadmap/kora_runtime_doppler_env_mapping.md` (163 lines)

Single source of truth for which Doppler project owns which secret:

- 3-project table (substrate / anthropic / gateways) with role,
  rotation cadence, owner-of-record
- Secret-by-project tables with required-by listener + example value
  shape:
  - substrate: KORA_SERVICE_TOKEN (wsk_*), KORA_ISOKRON_DSN,
    KORA_DEFAULT_WORKSPACE_ID, KORA_SEA_MCP_ENDPOINT
  - anthropic: CLAUDE_CODE_OAUTH_TOKEN (+ ANTHROPIC_API_KEY /
    ANTHROPIC_AUTH_TOKEN documented as anti-secrets — gate 2 fail-CLOSED)
  - gateways: KORA_MCP_BEARER_TOKEN, KORA_SLACK_SIGNING_SECRET (NEW
    for Phase 2 webhooks), KORA_PUREMAIL_HMAC_SECRET (deferred),
    legacy SLACK_APP_TOKEN/SLACK_BOT_TOKEN/SLACK_SIGNING_SECRET +
    SLACK_GATEWAY_ENABLED toggle
- fly.toml [env] vars (NOT in Doppler): KORA_DEPLOY_ENV, HERMES_HOME,
  KORA_WEB_HOST/PORT
- fly.toml [[services]] exposure table — internal 9119 vs public 9118
- Optional/tunable env vars (KORA_WEBHOOK_RATE_LIMIT,
  KORA_HEALTH_PROBE_CADENCE_SECONDS, etc.)
- **Pre-deploy validator script** — operator runs to confirm all
  required secrets present in each Doppler project; checks
  anti-secrets are absent
- Per-secret rotation procedure cross-references

Notes the env-var dual KORA_SLACK_SIGNING_SECRET vs SLACK_SIGNING_SECRET
(same Slack app, different consumer paths) — operator sets both to
the same value until follow-on refactor consolidates.

### `kora_docs/15_status_and_roadmap/kora_runtime_first_deploy_runbook.md` (317 lines)

Step-by-step operator checklist for the first `flyctl deploy`:

1. App + volume setup (`flyctl apps create kora-runtime-staging` +
   `flyctl volumes create kora_state`)
2. Doppler secrets validation (run the env-mapping validator)
3. Import Doppler → Fly secrets (3-project download + import +
   shred .env.doppler — non-negotiable cleanup)
4. `flyctl deploy --build-only` smoke first
5. `flyctl deploy` live
6. Verify release_command (`hermes doctor`) exited 0
7. Verify daemon boot — exact expected log lines showing 4 listeners
   booting in order (heartbeat → web → mcp → webhooks); failure
   modes documented
8. Operator admin smoke: flyctl proxy 9119 + curl /api/status +
   MCP /mcp/tools/list with bearer
9. Public webhook smoke — TWO paths:
   - Path A: Slack URL-verification handshake via Slack app config
     (PREFERRED — proves end-to-end including TLS cert)
   - Path B: manual curl with operator-signed payload (debugging)
   + /healthz smoke
10. Rollback procedure: `flyctl releases rollback` + Doppler version
    pinning if secrets need to revert
11. Promotion to prod: same sequence with `-a kora-runtime` + `-c prd`,
    only after staging healthy for one day

Plus: known-good first-deploy artifact capture (boot log, release
version + image digest, Slack confirmation) for the audit trail.

## Cross-references woven through

- `docs/deploy-fly-io.md` — R2-era doc; env-mapping section SUPERSEDED
  by this doc for Phase 2; volume + apps-create steps still authoritative
- `kora_docs/15_status_and_roadmap/token_rotation_runbook.md` — wsk_* /
  OAuth rotation procedures (extend to cover new Phase 2 secrets in
  follow-on)
- `kora_docs/00_canonical_current_state/r2_amendments.md` — Amendment 1
  (public webhook port rationale)
- `fly.toml` — [env], [mounts], two [[services]] blocks
- `docker/entrypoint.sh` + `docker/dispatch.sh` — Doppler nested wrap

## §5 ship checklist

- [x] Base `feature/phase2-upgrades` (NOT main)
- [x] Title format `feat(kora): KR-D-DEPLOY STn — <scope>`
- [x] No code changes (pure docs)
- [x] All operator surfaces documented (Doppler / fly.toml / smoke / rollback)
- [x] Staging app naming canonical (`kora-runtime-staging`, per PM Q3)
- [x] Cross-references woven so operator can navigate without re-grepping

## Arc closes

After this PR merges, KR-D-DAEMON (ST1-ST3) + KR-D-DEPLOY (ST1-ST2)
are complete. The kora-runtime daemon is deployable to staging on
Joshua's call. Next: feature-handler buckets (KR-FEAT-EMAIL /
KR-FEAT-SLACK-DM / KR-MCP-RUNTIME-SURFACE) plug in their handler
code; the daemon scaffold + deploy story stays stable.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>