Audited migrations, reconciler ownership, authentication, authorization, AI
security, file storage, public CV access, backups, logging, error handling and
configuration defaults before the first production deployment after the Phase
4/5 architecture changes.
Verdict: not ready to deploy unattended. The application verifies clean —
fresh MariaDB, populated MariaDB restart, existing SQLite upgrade, 393 backend
tests, 128 frontend tests, both Docker images — but four things stand in the way,
and the review lists them rather than declaring success.
Two are deployment blockers found by this audit. deploy.sh takes no database dump
before bringing the stack down, which is exactly backwards for a first deploy
where the reconciler will create roughly a dozen tables on a database many
commits behind; BackupController offers only an application-level encrypted
export, not an operational dump. And there is no documented restore procedure —
a backup nobody has restored is a hypothesis.
One is an operational gap: compose defines health checks for ai-service and
ollama but not for backend or frontend, so nothing detects a backend that starts
and then goes unhealthy.
One is the standing external blocker: CI is red for an environmental reason, and
deployment is gated on it.
Also recorded as accepted rather than fixed: console-only logging, no global
exception handler, the intentionally anonymous client-error endpoint, and the
fact that nobody has walked the authenticated end-to-end journey.
Includes a ten-step deployment checklist and a rollback plan. Rollback is safe
because every Phase 4/5 migration is a no-op, so reverting the code never leaves
migration state ahead of the schema — but it does not recover data users create
in the new tables during the window, which the review says plainly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
cesnimda
b2b87f39a5