SONI-remix-new

The product cannot launch in its current state. 55 of 123 findings are launch-blocking. The most urgent are concentrated in security, legal compliance, and AI integration --- these compound each other and require sequenced remediation.

The audit covered ten dimensions of the application and identified 123 findings, of which 55 are launch-blocking. Eighteen findings are at the critical severity level (production-launch blocker), concentrated in three areas: legal documentation (no Privacy Policy and no Terms of Service exist, against a sign-up screen that already claims a user has accepted them), domain compliance (the Biological/Health-age computation crosses the EU Medical Device Regulation Rule 11 threshold, and the app has no age gate to keep minors out), and operational security around the AI coach (an unauthenticated cron endpoint can drain the AI credit balance, the chat endpoint loads a 3,000-token context on every turn, and there is no per-user budget or rate limit). The product as it stands cannot be launched in the EU.

Four clusters carry most of the leverage. The first is the legal-documentation cluster (LEG-001 Privacy Policy, LEG-002 Terms of Service, LEG-008 DPIA, plus the cookie/consent and DSR findings) - fourteen findings reference these as prerequisites. Standing up a real Privacy Policy, Terms of Service, and a documented DPIA closes the single largest block to EU launch and unlocks app-store submission. This cluster is engineer-cheap (mostly hosting a static page) but counsel-expensive (the content needs a privacy lawyer); plan on calendar time, not engineering time.

The second is the medical-device positioning cluster around DOM-001 (Biological-age = Class IIa medical device under MDR Rule 11). This is a decision before it is a fix: launch as a wellness/lifestyle product (which means removing the Biological-age feature or recasting it explicitly as non-diagnostic) or pursue CE marking (12-18 month timeline, six-figure cost). DOM-001 is referenced by ten other findings - the choice flows through to copy, consent text, age gating, AI Act labelling, and the DPIA scope.

The third is the AI cost and abuse cluster (SEC-002 unauthenticated cron, SEC-005 no rate limit, AI-003 no per-user budget, AI-005 single-provider lock-in, SCA-001 prompt bloat, SCA-007 cost runaway). A single attacker with curl can drain the AI credit balance in minutes; a single user with a script can do the same more slowly through the front door. The fix is sequenced: authenticate the cron endpoint, add per-user rate limits and a daily token budget, slim the per-turn coach prompt, then wire a fallback AI provider. Doing this work in order closes seven launch-blockers and removes the single largest unplanned-spend risk.

The fourth is the mobile readiness cluster - four critical and four high findings in this dimension. The product runs as a web SPA today; mobile entry is via screenshot OCR rather than native HealthKit/Health Connect, there is no PWA install prompt, push notifications and offline mode are not implemented, and the touch surface has not been audited for one-handed use. This is a deployment-path decision (PWA, Capacitor wrapper, or native rewrite) before it is a remediation list.

Total estimated effort to launch-readiness, summing only the must-fix findings on the S=1/M=3/L=10-day heuristic, is approximately 207 engineering-days (~41-42 engineer-weeks for one developer, materially shorter with two engineers plus parallel counsel work on the legal cluster). The first-sprint backlog is another 150 engineering-days; the deferrable backlog is 29 days.

The four issue clusters identified above carry the bulk of the launch-blocking risk. Each cluster's top 5 findings are shown below as compact cards. Full technical anatomy — evidence, code locations, fix steps, references — lives in the linked dimension pages of the tech report.

The remaining 118 findings are grouped below by audit theme. Each row links to the full anatomy in the tech report — open any ID for evidence, code locations, and fix steps.

• Choose the regulatory path for the Biological-age feature (DOM-001). Two options: (a) reposition as a wellness/lifestyle product, which means removing or recasting the Biological-age computation so it is plainly non-diagnostic, or (b) pursue CE marking under EU MDR Class IIa, which is a 12-18 month and six-figure engagement with a notified body. This decision gates roughly ten other findings (copy, consent, AI Act labels, DPIA scope).
• Engage privacy counsel to author the Privacy Policy, the Terms of Service, and the DPIA (LEG-001, LEG-002, LEG-008). The product is already showing users a consent-screen that claims these exist. Counsel engagement is the single highest-leverage item in the report - it unlocks the legal cluster (14 findings).
• Decide whether minors can use the product (DOM-004). No age gate exists today. Under GDPR-K, processing data of children under 16 requires verifiable parental consent. Either add an age gate at signup (engineering: small) or document the legal basis for accepting minors (counsel: required).
• Pick a backup AI provider for the coach (AI-005). Currently the entire AI surface depends on the Lovable AI Gateway. Choose a secondary provider (Anthropic, OpenAI direct, Google direct, Bedrock) so the abstraction layer has a target to fall back to.
• Decide data-retention periods per data category (LEG-008, AI-006). Body photos are already auto-purged at 90 days per settings.tsx. The other categories (coach messages, biometrics, profile, AI request logs) need explicit retention periods documented and enforced. This is a counsel + product call, not pure engineering.
• Choose a mobile deployment path (Mobile readiness section). PWA (cheapest, weakest store presence), Capacitor wrapper (medium effort, app-store distribution, partial native APIs), or native rewrite (largest investment, best UX, native HealthKit/Health Connect). The decision shapes 14 findings.
• Pick an error-monitoring and log-aggregation stack (Ops findings). Sentry, Datadog, Better Stack, or self-hosted - the choice affects setup time and recurring cost. Without this, post-launch incident triage is blind.
• Decide on the AI-output-labelling pattern for the EU AI Act (DOM-005). Article 50 obligations apply from 2 August 2026. The fix is small (visible label on AI coach, visible label on AI-generated avatar images, watermark metadata on synthetic media) but the decision on copy and placement belongs to the product owner.

| Severity / Priority | Count | Estimated effort | |---|---|---| | Critical, must-fix | 18 | 81 days | | High, must-fix | 32 | 119 days | | Medium, must-fix | 5 | 7 days | | Low, must-fix | 0 | 0 days | | Total to launch-ready | 55 | 207 days | | First-sprint | 52 | 150 days | | Deferrable | 9 | 29 days |

_Effort heuristic: S = under a day, M = 1-3 days, L = 1-2 weeks._

1. Week 1 - engage counsel and start the legal artefacts. Counsel calendar is the long pole; if work on LEG-001/LEG-002/LEG-008 does not start now it will be the gating item for launch regardless of how fast engineering moves.
2. Week 1-2 - close the AI cost-and-abuse cluster. Authenticate the cron endpoint (SEC-002), add per-user rate limits and daily token budgets (SEC-005, AI-003, SCA-007), slim the coach prompt context (SCA-001), and add the AI request audit log (AI-006). This removes the single largest unplanned-spend risk and closes 7 launch-blockers.
3. Week 2-3 - decide on the medical-device path (DOM-001) and ship the consequence. Either remove/reposition the Biological-age feature (small engineering, large copy and consent rework) or commit to CE marking and pause that surface for launch.
4. Week 3-4 - operations hardening. Set up the chosen error-monitoring stack, write the incident runbook and backup-restore procedure, rotate the discovered secrets, document the deployment process, and verify a real restore from backup.
5. Week 4+ - mobile deployment decision and AI provider abstraction (AI-005). These are first-sprint-after-launch items and can be sequenced after the launch-blockers are closed.

---

This report is generated from structured findings in findings/.json. The companion technical report at tech-report.md includes file-line references and full fix steps for the engineer.*