Ops & Deployability

There is no automated gate between a developer working tree and production. No PR check runs the linter, the single test, a type-check, or builds the worker. Deploys flow through an external Lovable platform with zero artifact in the repo describing branch protections, required checks, environment promotion, or rollback hooks.

A regression introduced at 02:00 ships straight to production users with no automated safety net. Combined with the absence of error tracking (OPS-005), structured logging (OPS-006), runbook (OPS-008), and feature flags (OPS-013), the team cannot tell whether a deploy succeeded, broke something, or quietly degraded a coach flow. For a B2C health-adjacent app launching in EU markets, this is a launch blocker.

The project has no automated checks that run before code goes live. Anyone can push a change and it reaches real users without the linter, type-checker, or tests running first, and there is no record showing how a deploy is supposed to happen or who is supposed to approve it.

Add .github/workflows/ci.yml that runs on every PR: install deps, lint, tsc --noEmit, vitest run, build. Add a deploy workflow gated on push-to-main running wrangler deploy with secrets from GitHub Actions environments. Enable branch protection on main requiring CI to pass.

M — 1–3 days

• https://docs.github.com/en/actions/automating-builds-and-tests
• https://developers.cloudflare.com/workers/wrangler/ci-cd/

There is no client-side error reporter and no server-side error reporter. When a user hits a stack trace in coach chat at 02:00 in Madrid, no telemetry leaves the device, no Worker log line is correlated across the SSE stream, and the operator has no way to learn the error happened until the user emails support.

Mean-time-to-detect for any production bug is effectively infinity. Mean-time-to-resolution depends on a user noticing, finding a contact method (legal LEG-010 imprint absence), and writing in. For an AI-coach health app, silent failures will accumulate user trust damage over weeks before anyone notices.

When the app crashes on a user phone, nothing is sent back to the team to say it crashed. The team can only find out a bug exists if a user writes in and complains -- which is rare enough that most bugs will live in production for weeks or months without ever being seen.

Install @sentry/react (client) and @sentry/cloudflare (Worker). Initialize in src/router.tsx and the server entry. Upload source maps in the build step. Use environment-scoped DSNs. Wrap the default error component to call Sentry.captureException(error). Attach userId (anonymized) and a request correlation id to every event.

M — 1–3 days

• https://docs.sentry.io/platforms/javascript/guides/react/
• https://docs.sentry.io/platforms/javascript/guides/cloudflare/

There is no canonical list of which environment variables the application requires, what they mean, where to obtain them, or which are secret vs public. Onboarding a new engineer requires grepping the codebase for process.env. and import.meta.env. and reverse-engineering the surface from src/integrations/supabase/client*.ts, src/server/push-admin.server.ts, and ~38 AI-using server files.

Bringing a second engineer is a one-day archaeology exercise before they can run vite dev. In a 02:00 incident, a fresh on-call cannot stand up a local repro because they do not know what to put in their .env. Disaster recovery (rebuild on a new Cloudflare account) is similarly blocked.

There is no list of the secret keys and URLs the app needs to run. A new developer would have to read large parts of the source code just to figure out what to put in their configuration file before they can start working.

Create .env.example listing every variable name with a one-line comment per variable: where it is used (server/client/cron), where to obtain it (Supabase dashboard, Lovable, npx web-push generate-vapid-keys), required vs optional. Add a top-level README.md with Local Setup and Deploying sections. Add a CI check that fails if a new process.env.X reference appears without a corresponding line in .env.example.

S — under ½ day

• https://12factor.net/config

There is no way in the current wrangler config to deploy to a separate staging Worker against a separate Supabase project. Development, integration testing and production share the same database, the same service-role key, the same Lovable API key, and the same Worker URL. Combined with absence of feature flags (OPS-013), partial rollout and pre-prod verification are impossible without affecting real users.

Every test against a non-trivial backend interaction (auth, coach chat, body-progress photo upload) lands in production data. A migration that breaks coach_messages cannot be detected on staging before it ships. AI cost experiments run against the same Lovable API cap as production traffic.

There is only one version of the app. There is no separate copy where the team can try out new features safely before real users see them -- every change is tested directly on the live system with real user data.

Add env.staging and env.production blocks to wrangler.jsonc with distinct Worker names. Create a second Supabase project for staging. Update scripts: deploy:staging -> wrangler deploy --env staging; deploy:production -> wrangler deploy --env production. Gate deploy:production behind manual approval.

M — 1–3 days

• https://developers.cloudflare.com/workers/wrangler/configuration/#environments

Whether or not the values in .env are real production credentials, the deployment pipeline has no recorded secret-management discipline. There is no wrangler.jsonc evidence that secrets flow via wrangler secret put, no GitHub Actions secret references, no documented rotation procedure. SEC-001 covers the leak risk; this finding covers the deploy-side gap: no infrastructure-as-code description of how production gets its secrets.

Credential rotation requires editing .env in the repo and pushing a commit. There is no audit trail of when LOVABLE_API_KEY or SUPABASE_SERVICE_ROLE_KEY were last rotated. A leaked secret cannot be revoked at the deploy-platform layer because the deploy platform is not the system of record.

The platform that runs the app (Cloudflare Workers) is not where the secret keys are stored. The keys live in a file in the project itself, which means rotating a leaked key would require editing the project and pushing a change rather than just clicking rotate in a dashboard.

Move every secret out of .env into the Cloudflare Workers secret store via wrangler secret put (per environment). Delete .env from working tree, add .env, .env.*, *.env to .gitignore, git-rm the historical file (cross-ref SEC-001). Replace with .env.example (cross-ref OPS-002). Document secret list and rotation cadence in docs/secrets.md.

M — 1–3 days

• https://developers.cloudflare.com/workers/configuration/secrets/

Production debugging relies on wrangler tail (or whatever the Lovable platform exposes) reading raw console output with no correlation between a single coach-chat request, the AI gateway call inside it, the fact-extraction follow-up AI call, and the Supabase queries that fired alongside. There is no structured logger emitting JSON with requestId, userId, route, level, model, latencyMs fields. There is no log level -- dev-time console.log statements emit at the same priority as console.error.

When an on-call needs to trace a single user-reported coach failure, they must scroll a stream of un-correlated console lines and guess which ones belong to that request. Multi-step failures cannot be reconstructed from logs alone. Combined with no error tracker (OPS-005), debugging time-to-resolution is bounded by guesswork.

The app prints messages to the console like a developer notebook, but nothing in those messages says which user, which request, or which step they belong to. When something breaks, the on-call engineer cannot connect the dots between the user report and the lines in the log.

Add a thin structured logger module at src/lib/log.ts that wraps console.log/error and emits JSON with fields ts, level, msg, requestId, userId?, route?, durationMs?, ...rest. Replace console.log in src/server/* and src/routes/api*.ts with the structured logger. Generate a requestId in auth-middleware.ts and propagate via request context. Enable Worker observability in wrangler.jsonc. Pipe Worker logs to a long-term sink (Cloudflare Logs Engine, Logflare, or Better Stack).

M — 1–3 days

• https://developers.cloudflare.com/workers/observability/logs/
• https://12factor.net/logs

There is no uptime probe configured, no APM emitting latency p50/p95/p99, no error-rate alert, no alert on Lovable API token spend or Supabase connection exhaustion, and no defined alert sink (PagerDuty, Slack, email). For an AI-coach product whose dominant cost driver is a third-party token budget (cross-ref SCA-007 and AI-003), the absence of a spend alert is by itself a financial-risk finding.

An outage at 02:00 will not page anyone. A Lovable API key drained by a runaway user (AI-003) will only be noticed when the next user gets a 429 and complains. Worker latency p95 silently doubling after a deploy will not surface until users report sluggish coach replies.

Nothing is watching the app to see if it is up, fast, or running up a bill. If a service goes down in the middle of the night or someone abuses the AI features and triggers a large invoice, nobody on the team will get a notification -- they will only find out the next time they happen to log in.

1. using UptimeRobot, Better Stack, or Cloudflare Health Checks. Route alerts to a shared Slack channel and an on-call email. Enable Worker observability in wrangler.jsonc and surface error-rate and CPU-time dashboards. Configure a Lovable AI Gateway monthly spend alert at 50/75/90 percent of the cap. Configure a Supabase project usage alert.

M — 1–3 days

• https://uptimerobot.com/
• https://developers.cloudflare.com/workers/observability/

There is no document describing how to deploy, how to roll back a bad deploy, what to verify after deploy, who to escalate to during an incident, or how to handle a partial outage (Worker up but Supabase down, or Worker up but Lovable Gateway throttling). The Lovable platform may provide a redeploy-previous button, but there is no in-repo evidence that anyone has practiced it or documented the smoke-test set that proves a rollback was successful.

During a production incident, the responder must invent procedure on the spot. A bad migration that broke coach_messages cannot be rolled back without ad-hoc SQL invented under pressure (cross-ref DAT-002, DAT-008). The single-engineer bus factor is brutal: a second engineer cannot take over without a verbal handover.

There is no written guide for how to safely release the app, how to undo a release that broke something, or who to call when things go wrong. Every incident becomes a fresh exercise in figuring it out from scratch, which is slow and dangerous.

1. pre-deploy checklist (lint, tests, type-check pass; staging deploy verified); (.
2. deploy command and approval gate; (.
3. smoke-test checklist (sign-in, send a coach message, view bio-twin, log a meal, view weekly report); (.
4. rollback procedure (wrangler rollback or Lovable platform equivalent, plus Supabase point-in-time-restore steps); (.
5. on-call escalation tree with names, phone numbers, and second-on-call. Schedule a quarterly rollback drill.

S — under ½ day

• https://sre.google/sre-book/runbooks/
• https://developers.cloudflare.com/workers/wrangler/commands/#rollback

Scheduled jobs fire on a pg_cron timer, hit unauthenticated or weakly authenticated endpoints (SEC-002, SEC-003), iterate all users sequentially (SCA-006), and either succeed silently or fail silently. There is no per-run row inserted into a cron_run_log table with job, started_at, finished_at, candidate_count, processed_count, error. There is no alert when N consecutive runs fail or when a scheduled run is missed entirely.

If the weekly-report cron breaks on a Sunday at 03:00, no user gets a report and no operator notices until a user complains on Tuesday. If the bio-twin-snapshot cron fails for two weeks running, snapshots silently miss the gap and the coach loses context. Combined with no APM (OPS-007), missed runs are invisible.

The app runs scheduled background jobs (for example generating weekly reports). If one of these jobs fails, nothing is written down anywhere -- the team has no way to find out it stopped working until a user notices their report did not appear.

Create a cron_run_log table with job text, started_at timestamptz, finished_at timestamptz, candidate_count int, processed_count int, error text. Every cron endpoint should INSERT a row on start and UPDATE it on finish/failure. Add a Better Stack heartbeat per cron job that the endpoint pings on success -- missed heartbeats trigger an alert. Surface a cron_health admin view that lists last-run-at + last-success-at per job.

M — 1–3 days

• https://supabase.com/docs/guides/database/extensions/pg_cron
• https://betterstack.com/docs/uptime/heartbeats/

External uptime monitoring (OPS-007) cannot verify the worker plus its critical downstream dependencies (Supabase, Lovable AI Gateway) are healthy because there is no endpoint that probes them. A 200 OK on / only proves the SPA shell loads -- it does not prove that auth, the database, or the AI gateway are reachable.

Even after adding an uptime probe, the probe will only confirm the SPA is served -- it will continue returning 200 OK during a Supabase outage or a Lovable gateway outage. Real user impact (coach chat fails) goes undetected until users complain.

There is no special address that says I am alive and so are all the things I depend on. Even when monitoring is added, it will only check that the home page loads -- not that the database or the AI service is actually working.

1. select 1 from Supabase with a 1500ms timeout; (.
2. HEAD or short OPTIONS against the AI gateway; (.
3. return 503 if any downstream check fails. Point UptimeRobot/Better Stack at this endpoint with a 60s interval.

S — under ½ day

• https://microservices.io/patterns/observability/health-check-api.html

Migration application is undocumented and probably manual. There is no CI step that runs supabase db push or applies migrations from the repo as part of deploy. There is no convention for how to roll back a bad migration -- no down-migration files, no documented point-in-time-restore steps, no canary against staging (cross-ref OPS-003 -- staging does not exist).

A migration that breaks a hot table (e.g. coach_messages) cannot be rolled back via a single command. The only recourse is Supabase point-in-time restore, which (a) is undocumented (DAT-011) and (b) loses any data written after the bad migration applied. For a health-adjacent app under GDPR, the data-loss exposure is regulatory not just operational.

When the team needs to change the database, there is no automated, repeatable way to apply that change to the live system, and no documented way to undo a change that turned out to be wrong. Every database change is a manual procedure invented on the spot.

Add a deploy workflow step that runs supabase db push --linked against the target environment with secrets from the workflow store. Adopt a convention for breaking migrations (add column nullable -> backfill -> set NOT NULL in a later migration). Document the rollback strategy in docs/deploy.md (Supabase PITR steps + which tables to verify after restore). Mirror every destructive migration (DROP COLUMN, DROP TABLE) with an explicit comment block describing the manual undo.

M — 1–3 days

• https://supabase.com/docs/guides/cli/local-development#database-migrations

The Cloudflare Workers dashboard, the npm package name, and the Lovable platform deployment slug all use a generic scaffold name. In an account with multiple Workers (or after a remix into a sibling project), tanstack-start-app is ambiguous. Commit messages of the form Lovable update carry no semantic information for git-bisect during an incident.

During an incident, the responder reading the Cloudflare dashboard cannot tell which Worker belongs to SONI vs other tenants. Searching git log for the change that introduced a regression yields a wall of Lovable update commits. Onboarding a second engineer is harder because every artifact looks like a scaffold.

The app name on the hosting dashboard is still the generic default (tanstack-start-app) and the version-control history entries are all called Lovable update. This makes it hard to tell which project is which when looking at the production dashboard, and hard to figure out which change introduced which bug.

Rename the Worker in wrangler.jsonc to soni-production (and soni-staging when OPS-003 is implemented). Rename the npm package to soni-app in package.json. Adopt a commit-message convention (conventional commits or just human English summaries) for any non-platform commit. Where Lovable controls commit messages, surface a project-side CHANGELOG.md that captures meaningful release notes.

S — under ½ day

• https://www.conventionalcommits.org/

There is no way to ship a feature behind an off-by-default flag, no way to enable a new coach prompt for 10 percent of users before flipping it on for everyone, and no way to kill-switch a misbehaving feature without a redeploy. For an AI-coach product where prompt changes and AI provider changes can have user-visible regressions (cross-ref AI-009, AI-010), a kill-switch is the minimum prudent fallback.

Every feature ships to 100 percent of users at the moment it merges. A bad AI prompt that doubles cost or generates unsafe coach content (cross-ref AI-001 fabricated citations, AI-002 role-injection) cannot be turned off without a code change and a redeploy. There is no way to A/B-test a coach behavior change safely.

There is no switch the team can flip to turn off a broken feature or to release a new feature to only some users first. Every release goes to every user at once, and the only way to undo a problem is another full release.

Adopt a minimum-viable feature-flag layer: a feature_flags Supabase table keyed by key, env, value, rollout_percent, queried at server-function entry with a 60s in-memory cache. Or adopt PostHog feature flags (also gives free analytics, which the project currently lacks). Wire the riskiest surfaces first: coach prompt version, AI provider/model, voice-coach feature, push notifications.

M — 1–3 days

• https://martinfowler.com/articles/feature-toggles.html
• https://posthog.com/docs/feature-flags

Even after CI is added (OPS-001), there is no canonical command to invoke tests. A new contributor running npm test will get no test specified. The vitest binary must be invoked directly via npx vitest run. Combined with the fact that there is only one test file in the entire 86,000-LOC codebase, the project has no testing posture.

The act of formalizing how do we run tests is itself a precondition for the test count ever growing. Without a script, contributors will not add tests; without tests, regressions ship.

There is no shortcut command to run the project tests, and the project currently has only one test for a codebase of about 86,000 lines. Even if the team wanted to add more tests, the basic plumbing for running them is not in place.

Add test: vitest run, test:watch: vitest, and typecheck: tsc --noEmit to package.json scripts. Wire npm test and npm run typecheck into the CI workflow created in OPS-001 as required checks on PRs.

XS

• https://vitest.dev/guide/cli.html

A new release that ships a fixed sw.js will not invalidate clients unless the SW_VERSION string was manually bumped. Forgetting to bump it means users keep the old service worker and the old push handler indefinitely.

Push-notification regressions (and any cached-route regressions) can persist on a user device across deploys until the developer remembers to bump the version. For a notifications-driven habit-coach product, this is a non-trivial UX risk.

The version string for the background worker that handles notifications is updated by hand. If a developer forgets to bump it, users get stuck on the old version even after the team releases an update.

Replace the hard-coded SW_VERSION with a Vite-injected build hash via define: __SW_VERSION__: JSON.stringify(commitSha) in vite.config.ts, or generate sw.js from a template at build time. Add a release-checklist item in docs/deploy.md to verify sw.js version bumped.

S — under ½ day

• https://web.dev/articles/service-worker-lifecycle