- consolidate API ownership and remove dead vendor code
- add Stripe billing, learning paths, and public CV hardening
- add migration, recovery, security, audit, and browser gates
Closes the three operational blockers from the production readiness review.
deploy.sh now takes a database backup before it builds, stops or replaces
anything, and aborts the deploy if the backup fails — so no deploy proceeds
without a restore point. Dumps are gzipped and timestamped into
/opt/job-tracker/backups (override with BACKUP_DIR), so one deploy never
overwrites an earlier backup. Credentials come from the existing connection
string and travel via MYSQL_PWD, never on the command line, so they cannot reach
the process list or the deploy log. A dump that is empty or missing CREATE TABLE
is rejected, because a truncated file that looks like a restore point is worse
than none. SQLite deployments get their data volume tarred instead. Nothing is
ever deleted automatically; retention is documented as manual.
deploy/README.md documents backup creation, location, retention, database
restore, application rollback, and when to use which — restore and rollback kept
distinct, because a bad deploy usually needs only the rollback and restoring
would discard everything written since the dump.
Health checks now cover backend and frontend, which previously had none. GET
/health is anonymous, cheap, and deliberately does not touch the database: a
health check that queried MariaDB would restart a healthy backend whenever the
database blipped, and would hand out an unauthenticated way to probe database
availability. The backend image gains curl on the existing chromium apt layer,
since the aspnet runtime ships neither curl nor wget. frontend now waits for
backend to be healthy rather than merely started, because nginx proxies /api and
refuses to start when the upstream cannot be resolved.
Verified against real containers, no production data: backup from a seeded
MariaDB 11; restore into a clean MariaDB 11 with rows identical; bad credentials
and a missing connection string both abort non-zero and leave no partial file;
SQLite volume backup produces a readable archive; backend and frontend both
reach healthy; and a backend pointed at an unreachable database exits and is
reported unhealthy, so a broken deploy cannot present as a running stack.
Incidentally confirmed the earlier authorization work: with Auth:Require unset,
/health returns 200 while /api/jobapplications returns 401.
393 backend tests pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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