Onboarding, safer imports, and user management

What changed in this cycle (before vs now)

flowchart LR subgraph Now G[Sign up] --> H[Profile setup email verification walkthrough] I[Import program] --> J[Link-or-confirm enforced server-side exercise scope isolated] K[Remove user] --> L[Soft delete session revoked invitations cancelled restorable] end subgraph Before A[Sign up] --> B[App access no guided setup] C[Import program] --> D[Unsafe paths no server validation] E[Remove user] --> F[No clean exit data leaks possible] end

Between v2.40.1 and v2.43.3, the focus shifted from visibility to correctness.

The previous cycle was about making Synergym easier to operate: admin dashboards, user management views, and better completion history. This cycle was about closing the gaps that show up when real users start using the product: a trainer who imports their programs, a new user who doesn't know where to start, and an admin who needs to remove someone without losing data.

Safer program import

The import wizard existed before this cycle. What it didn't have was enough safety on the edges.

flowchart LR A[Upload CSV/XLSX] --> B[Parse: detect days and exercises] B --> C[Preview screen] C --> D{Each exercise} D -->|Found in library| E[Green: auto-linked] D -->|Not found| F[Amber: confirm or link manually] F -->|Unresolved| G[Submit blocked] E --> H[Create Program] F -->|Resolved| H

A trainer uploading a program file now sees a clear two-color preview: green for exercises matched to the library, amber for anything unresolved. Submitting with unresolved amber rows is blocked. Not warned. Blocked. The server enforces the same rule independently of the client, so the constraint holds even without JavaScript.

Several edge cases that could silently produce bad data are now closed: exercise lookups are scoped to trainer-visible exercises only, variant creation is guarded against modifying the standard library, duplicate program names surface a warning before the trainer commits, and superset grouping IDs use proper UUIDs to avoid race conditions during preview.

The parser also got more reliable: single-line day headers are now detected correctly, tempo notation takes priority over pyramid notation, and exercise names that include SET UP as part of a movement name no longer get stripped.

Real onboarding

Before this cycle, signing up meant landing in the app with no structured introduction. The profile was incomplete by default, the email was unverified, and there was no guide for where to start.

flowchart LR A[Sign up or OAuth] --> B[Profile setup name + role + photo] B --> C[Email verification required before full access] C --> D[Guided walkthrough first steps by role] D --> E[Settings page preferences + account] E --> F[Resume banner if setup incomplete]

New users now go through a structured setup: profile columns (name, role, profile photo), email verification before full app access, and a guided walkthrough that varies by role. If setup is interrupted, a resume banner reappears the next time the user logs in.

Google OAuth signup now requires explicit privacy consent. The checkbox cannot be skipped.

This was the most visible change in this cycle. The goal was not gamified progress bars or tooltips. It was removing the dead-end of landing in the app with nothing configured and no signal about what to do next.

User soft-delete

Removing a user from the platform used to be a hard delete. That creates cleanup problems: dangling assignments, broken invitation chains, and no way to recover if a removal was a mistake.

Admins can now soft-delete trainers and athletes. The deletion is immediate from the user's perspective: their session is revoked, active assignments are paused, pending invitations are cancelled, and their invite links are disabled. But the record is kept, and an admin can restore the user if needed.

The last-admin guard (which prevents removing the only admin account) is now enforced with a database lock, not an application-level check. That removes a race condition where two concurrent delete requests could both pass the guard.

Behind the scenes

This cycle also included a significant CI investment: cyclomatic complexity checks, Codex auto-fix on every PR, ERBLint, and Brakeman running as pre-commit hooks. Most of that won't be visible in normal use, but it means new code has tighter quality gates before it reaches the main branch.

If you want the full commit history, that belongs in the changelog.

v2.44.0 is about closing the gaps that real usage exposes: trainers who import their programs now get a safer flow, new users get a real first experience, and admins have a clean way to manage user lifecycle without losing data.

See you in the next release.