# Pre-Deployment Checklist

Run this checklist before the first hosted deployment, and again before inviting real external users.

## LLM Enablement

The LLM-backed parts of Ask QIEN are already wired through the Inngest pipeline. To enable them in a hosted environment, configure the host and Inngest rather than committing credentials to the repo.

Required hosted variables:

```dotenv
ANTHROPIC_API_KEY=<anthropic-key>
INNGEST_EVENT_KEY=<inngest-event-key>
INNGEST_SIGNING_KEY=<inngest-signing-key>
TENANT_CONFIG_PATH=./tenant.config.yaml
```

The current AI gateway uses Anthropic:

- Gateway: `src/lib/ai-gateway.ts`
- Tenant AI config: `tenant.config.yaml`
- Inngest endpoint: `src/app/api/inngest/route.ts`

The current hosted flow is:

1. A line manager submits a ticket.
2. `src/app/api/tickets/route.ts` sends an Inngest event.
3. Inngest invokes the AI functions:
   - `src/inngest/completeness-agent.ts`
   - `src/inngest/summarization-agent.ts`
   - `src/inngest/response-draft-agent.ts`
   - `src/inngest/kb-update-proposal-agent.ts`
4. Those functions call `src/lib/ai-gateway.ts`.
5. The gateway calls Anthropic with structured output validation.

For production, confirm `tenant.config.yaml` or the seeded tenant config has:

```yaml
ai:
  provider: "anthropic"
  model: "claude-sonnet-4-6"
  data_processing_consent: true
```

If `data_processing_consent` is false, LLM calls are intentionally blocked and the system should fall back to expert-driven workflows.

## Secret Handling

Never commit real secrets, API keys, service tokens, database URLs, SMTP credentials, or auth secrets.

Safe in the repo:

- Placeholder values in `.env.example`
- Documentation that names variables but does not include real values
- Local-only defaults that are unusable outside local development

Not safe in the repo:

- Real `ANTHROPIC_API_KEY` or `OPENAI_API_KEY`
- Real `DATABASE_URL`
- Real `AUTH_SECRET`
- SMTP usernames/passwords
- Inngest signing or event keys
- Vercel, GitHub, or provider API tokens
- Screenshots or logs that include any of the above

The repo currently ignores local env files:

```text
.env
.env.local
.env.*.local
```

Hosted secrets should live in the deployment provider's environment-variable store. For Vercel, set them separately in the `dev` and `production` environments.

Use separate values for dev and production:

- `DATABASE_URL`
- `AUTH_SECRET`
- `NEXTAUTH_URL`
- `EMAIL_SERVER_HOST`
- `EMAIL_SERVER_PORT`
- `EMAIL_SERVER_USER`
- `EMAIL_SERVER_PASSWORD`
- `EMAIL_FROM`
- `ANTHROPIC_API_KEY`
- `INNGEST_EVENT_KEY`
- `INNGEST_SIGNING_KEY`

Do not set local-only variables in production:

```dotenv
AUTH_DEV_EMAIL_MODE=dev-link
INNGEST_DEV=1
```

## Deployment Audit

Before first cloud deployment:

1. Run a secret scan against the working tree and git history.
2. Confirm `.env.example` contains placeholders only.
3. Confirm docs, tests, seed data, and config files do not contain real credentials.
4. Confirm hosted `AUTH_SECRET` is generated with a strong random value:

```bash
openssl rand -base64 32
```

5. Confirm hosted `NEXTAUTH_URL` exactly matches the environment URL.
6. Confirm production does not use `AUTH_DEV_EMAIL_MODE=dev-link`.
7. Confirm production does not use `INNGEST_DEV=1`.
8. Confirm Inngest Cloud is pointed at:

```text
https://<hosted-domain>/api/inngest
```

9. Confirm Inngest dev and production keys are separate.
10. Confirm SMTP delivery works for magic-link login.
11. Decide whether production should run `pnpm db:seed`, or whether seed data should become dev-only before launch.
12. Confirm production database backups and restore steps are understood.

Before real external users:

1. Implement or explicitly accept the remaining AI gateway hardening roadmap item:
   - provider/model allowlist
   - token limits
   - prompt-injection guardrails
   - data redaction policy
   - stronger audit logging for provider calls
2. Review prompt templates so user-supplied ticket and KB content is always treated as untrusted data.
3. Smoke test the complete flow in `dev`, then production:
   - login
   - submit ticket
   - Inngest run
   - completeness result
   - summary
   - response draft
   - expert response
   - KB proposal
   - sign out
4. Review logs for accidental credential, prompt, or PII leakage.
5. Rotate any temporary setup tokens used during deployment automation.

## Codex-Assisted Setup

Codex can help with the mechanical deployment setup once an account exists, but it should not own the account or long-lived credentials.

Good temporary options:

- Run `railway login` locally, then ask Codex to use the authenticated CLI session.
- Provide a short-lived Vercel token in the local shell environment.
- Provide a project-scoped token when possible instead of an account-wide token.

After setup:

1. Rotate or revoke temporary tokens.
2. Confirm variables exist only in the hosting provider.
3. Confirm no generated config or logs with secrets were committed.