Hardening, release & known gaps

The pre-production hardening checklist, the release gate, and a candid list of what is not yet in the app, so nothing surprises you in production.

Security hardening checklist

#	Action	Owner
1	Set a fixed random `SESSION_SECRET` (64 hex)	app config
2	`AUTH_COOKIE_SECURE=true` + HTTPS everywhere	app config + edge
3	Restrict `CORS_ORIGINS` from `["*"]` to known origins	app config
4	Terminate TLS + HSTS at the reverse proxy	edge
5	Add general rate limiting / WAF at the gateway (app throttles login only)	edge
6	Set per-request timeouts at the gateway	edge
7	Keep providers `mock` unless egress is intended; scope keys minimally	app config
8	Run the container as non-root (default `appuser`); read-only FS where possible	infra
9	Keep `CC_PBKDF2_ITERATIONS` at ≥ 100000 (never lower in prod)	app config
10	Rotate API keys / `SESSION_SECRET` on a schedule	ops
11	Put fine-grained authorization (RBAC/SSO) at the gateway, session tier has none yet	edge
12	Persist + back up `DB_PATH`; store copies off-host	infra
13	Ship stdout/stderr JSON logs to a central aggregator; alert on ERROR/CRITICAL	infra
14	Never commit `.env`; inject secrets via a secret manager	ops

Release checklist

Tests green: python -m pytest tests/ -q matches the known baseline (no new failures).
Build clean: python _build.py succeeds and the artifact contains no .env (only .env.example).
Version: confirm the package version (pyproject.toml) and that /health reports the expected service version.
Config diff: review env changes; confirm production settings (SESSION_SECRET, AUTH_COOKIE_SECURE, CORS_ORIGINS).
DB safety: back up DB_PATH and apply any pending migrations before serving traffic.
Smoke: run the smoke tests against the deployed instance.
Rollback ready: keep the previous image tag + pre-upgrade DB backup.

Known production gaps

Documented honestly so you can compensate at the right layer. None of these is a bug, each is a deliberate current boundary.

Gap	Current behavior	Mitigation / owner
Backup / restore I/O	metadata records only, no actual backup or restore is performed	run real backups of `DB_PATH`; see resilience (infra)
Disaster recovery	no automated DR / failover	define RPO/RTO via your backup cadence + hosting (infra)
General rate limiting	enforced on `/api/auth/login` only (per-IP)	rate-limit all traffic at the gateway
Authorization (RBAC)	session tier is authentication-gated; no role enforcement (fields reserved)	enforce authz at the gateway / IdP
Federated identity	self-hosted sessions + API keys; no OAuth/OIDC/SSO/MFA	add SSO at the gateway
Trust registry durability	in-memory; lost on restart (rebuilds from observations)	expected, re-observe; persist via the store if durability is needed
Datastore scale	single-node SQLite by default (single writer)	use `DATABASE_URL` Postgres for multi-node/HA
Request timeouts	no app-level wall-clock timeout (only the upstream provider call is bounded)	set timeouts at gateway/client
Managed control plane	none, fully self-hosted	you own the deployment lifecycle
SDK distribution	Python/TS SDKs are in-repo, not published to PyPI/npm	vendor from `sdk/` or publish internally

Operational responsibilities

The full app-vs-infrastructure responsibility split is on the operations overview. In short: VerifAIer owns the deterministic evidence path, honest status reporting and secret hygiene; you own the edge (TLS, throttling, authz), durability (backup/restore/DR) and scale. Close each gap above at the layer named, and the deployment is production-sound.