Demo activity

Demo activity keeps a sales demo studio looking alive. An hourly job invents believable trainee behaviour for every studio flagged as a demo: app opens, workouts, cardio, weigh-ins, meals, water, steps, check-in form answers, coach feedback and open tasks. This module has no HTTP routes. Nothing in modules/index.ts mounts it. It is a library called by a worker and by two scripts. Source: backend/apps/core-api/src/modules/demo-activity/.

File	Role
`demo-activity.service.ts`	Entry point `runDemoActivity`
`demo-mode.ts`	`DEMO_MODE_KEY` and `isDemoStudio`
`demo-activity.loader.ts`	Loads demo studios, their clients and exercise names
`demo-calendar.ts`	Builds the list of days to generate
`demo-persona.ts`	Assigns each trainee a persona and a platform
`demo-day.ts`	Builds one trainee’s rows for one day
`demo-workout.ts`, `demo-nutrition.ts`, `demo-metrics.ts`	Build the workout, meal and metric rows
`demo-plan.ts`	Reads training and nutrition plan JSON into a small shape
`demo-activity.writer.ts`	Writes the day rows
`demo-forms.ts`, `demo-answers.ts`	Fill check-in forms and mark older ones handled
`demo-tasks.ts`	Tops up open showcase tasks
`demo-random.ts`	Seeded hash helpers and the demo id prefix
`demo-types.ts`	Shared types and time helpers

Which studios are demo studios

A studio is in demo mode when Studio.settings.demoMode is exactly true. loadDemoStudios queries with a JSON path filter on settings.demoMode and re-checks each row with isDemoStudio. There is no endpoint that sets the flag. The script apps/core-api/src/scripts/setup-demo-studio.ts writes it as the last step of preparing the demo studio.

Callers

Caller	When	Options
`workers/demo-activity-scheduler.ts`	Hourly, and once at every server start	Defaults
`scripts/run-demo-activity.ts`	Run by hand	`--days=N` sets `backfillDays`. Defaults to `DEFAULT_BACKFILL_DAYS`
`scripts/setup-demo-studio.ts`	After the demo setup transaction commits	`backfillDays: 21`

The setup helpers under scripts/demo-setup/ (assign.ts, copy-source.ts) also import readTrainingPlan, demoId and DEMO_ID_PREFIX from this module. No route handler and no other domain module calls runDemoActivity. The module itself calls into two task modules:

createFormFilledTask from modules/tasks/form-filled.ts, after it fills a form.
AUTOMATION_DEFAULTS from modules/task-automations/task-automations.schema.ts and CONTENT from modules/tasks/task-content.ts, to build showcase tasks.

See Tasks and Automation.

The scheduler

startDemoActivityScheduler(ctx) is called from server.ts and closed on shutdown. It uses the BullMQ queue PerformQueue.DEMO_ACTIVITY (demo-activity).

A repeatable job named hourly with job id demo-activity-hourly runs every DEMO_ACTIVITY_EVERY_MS (60 minutes).
A one-off job named boot is added at every start, so a deploy does not wait an hour for fresh data.
The worker runs with concurrency 1, a 10 minute lock, a 5 minute stalled check and maxStalledCount: 1.
Completed jobs are removed. The last 50 failures are kept.
The run summary is logged only when at least one demo studio exists.

On an environment with no demo studio the job runs, finds nothing and returns { "studios": 0, "results": [] }.

What a run does

runDemoActivity(prisma, logger?, { now?, backfillDays? })

backfillDays defaults to 2 and has a minimum of 1. For each demo studio, runForStudio:

Loads the eligible clients.
Loads the names of the exercises in their training plans.
Builds day contexts for today and the previous backfillDays days, in the studio’s timezone.
Builds rows for every client and day with buildDemoDay.
Writes the rows with writeDemoDays.
Fills and handles check-in forms with runDemoForms.
Tops up showcase tasks with topUpShowcaseTasks.

Studios are processed one after another.

Eligible clients

loadDemoClients takes clients of the studio that are ACTIVE, not deleted, and have at least one subscription with status ACTIVE. For each it reads:

stepsGoal, waterGoalMl, weightKg, lastCheckInAt.
The newest active TRAINING program and the newest active NUTRITION program. File plans (pdfUrl set) are skipped.
A weight baseline: the latest real WeightEntry (one whose id does not start with the demo prefix), or else Client.weightKg, or else 75 kg.
The latest real body measurements from DailyMetric.measurements, limited to waist, chest, arm, hips and thigh.

Both baseline queries exclude rows whose id starts with the demo prefix, so generated weights are never used as the baseline.

Deterministic output

Nothing uses Math.random. Every decision comes from hash(seed) in demo-random.ts, an FNV-style hash of a string such as <clientId>:<date>:train. The same client and day always produce the same rows, which is what makes a rerun safe.

Personas

personaOf(clientId, dayIndex) gives each trainee a persona for a 28 day block. The block start is offset per client, and the persona is re-rolled each block.

Persona	Share	Opens app	Trains	Eats to plan	Fills forms
`committed`	50%	0.97	0.92	0.90	0.95
`steady`	30%	0.85	0.72	0.70	0.80
`slipping`	13%	0.45	0.30	0.30	0.25
`quiet`	7%	0.03	0	0	0

platformOf(clientId) fixes each trainee to ios (78%) or android.

Today is generated up to the current time

Past days are generated in full. For today, clockMinutes holds the current minute of the day in the studio’s timezone, and hasPassed drops anything scheduled later. A workout that would finish at 18:40 appears only in a run after 18:40. This is why the job runs hourly.

Rows written per trainee and day

buildDemoDay first decides whether the trainee opened the app that day, at a time between 06:30 and 09:30. If not, or if that time has not passed yet, nothing is written for that trainee and day.

Model	When	Content
`ClientAppDay`	Every generated day	`date`, `platform`, `createdAt` at the open time
`WorkoutLog`	A training weekday, the persona roll passes, and the workout has finished	The plan day’s exercises with sets, reps and weights, `durationSec` of 45 to 75 minutes, `completed: true`
`CardioLog`	With a workout, when the plan day has cardio minutes, or on a 30% roll for 15 to 40 minutes	`activity` from walking, running, cycling, stairs. `source: "WORKOUT"`
`WeightEntry`	Two fixed weekdays per trainee, at 07:15	`weightKg` from the trend, `source: "APP"`
`MealLog`	18% of days, at 16:30, never for the `quiet` persona	One off-plan meal from a fixed list of six, `source: "FREE_TEXT"`, with macros
`DailyMetric`	Every generated day	`steps`, `waterMl`, `waterLogs`, and `measurements` every second week on a weigh-in day
`NutritionDayLog`	When at least one plan meal was eaten	A day snapshot whose `eaten` map marks the eaten item ids

Details worth knowing:

Training days. trainingWeekdays spreads the plan’s workoutsPerWeek over fixed weekdays. Plan days rotate week by week.
Weights. Each exercise gets a base weight from 10 kg in 2.5 kg steps, plus one step every four weeks in a 16 week cycle. From the third set on, a set has a 30% chance of one missed rep.
Weight trend. weightOn drifts from the baseline at a per-trainee rate between -0.45 and +0.15 kg a week, flattening over a 12 week horizon, with up to 0.3 kg of daily noise either way.
Steps. Between 55% and 130% of the goal (plan stepsDaily, then Client.stepsGoal, then 8000), scaled by how much of the day has passed.
Water. 500 ml cups at up to six fixed times, sized against the goal (Client.waterGoalMl, then the plan’s water target, then 2500 ml).
Nutrition plan. Only the first day of the nutrition plan is read.

Client.lastCheckInAt and Client.lastCheckInPlatform are moved forward to the latest generated activity, and Client.weightKg is set to the latest generated weigh-in.

Forms and coach feedback

runDemoForms works on check-in forms only. Filling. fillPending looks at FormAssignment rows with status PENDING, a CHECK_IN form template, and a creation time at least 2 hours ago. For each:

The persona’s fillsForm rate decides whether the trainee fills it.
If not, and the assignment is older than 6 days, it is set to CANCELLED.
If yes, a submit time 2 to 22 hours after the assignment is chosen. Once that time has passed, the job creates a FormResponse with generated answers and sets the assignment to COMPLETED.
It then calls createFormFilledTask, the same hook a real submission triggers, so the studio’s form-filled task automations create their tasks. The created task’s createdAt is moved back to the submit time.

Answers come from buildAnswers, by field type: range and rating follow the persona’s mood, number is 5 to 9, weight is the trainee’s current weight, text picks a Hebrew note that matches the mood, dropdown picks an option, and checkbox_confirmation is true. Other field types are left unanswered. Handling. handleOlder takes up to 200 fabricated responses, submitted between 30 hours and 14 days ago, that are not handled yet. For each it picks an active coach of the studio and a handling time: 4 to 28 hours after the submit for 75% of responses, 60 to 110 hours for the rest. Once that time has passed, in one transaction it:

Creates a CheckinReview with a note, a message and channels: ["push"].
Stamps handledById, handledByName, handledAt and handledNote on the FormResponse.
Marks the matching open form-filled tasks DONE.
Creates a ClientActivity of type CHECKIN_FEEDBACK_SENT.

No push is sent. The review only records that one was.

Showcase tasks

topUpShowcaseTasks keeps the tasks board populated. For every task automation type in AUTOMATION_DEFAULTS, plus MANUAL, it counts the studio’s open InboxItem rows of that type and creates enough to reach two. New rows use the type’s title, detail and priority from CONTENT, have source: "manual", an empty coachIds, and are attached to a trainee. Form related types are linked to one of the studio’s latest form responses or assignments through metadata.

How fabricated rows are marked

Rows created by the day generator and the form filler have a deterministic id with the prefix dm_ (DEMO_ID_PREFIX), built by demoId(kind, ...parts).

Kind	Model	Id pattern
`ad`	`ClientAppDay`	`dm_ad_<clientId>_<yyyymmdd>`
`wl`	`WorkoutLog`	`dm_wl_<clientId>_<yyyymmdd>`
`cl`	`CardioLog`	`dm_cl_<clientId>_<yyyymmdd>`
`we`	`WeightEntry`	`dm_we_<clientId>_<yyyymmdd>`
`ml`	`MealLog`	`dm_ml_<clientId>_<yyyymmdd>`
`dm`	`DailyMetric`	`dm_dm_<clientId>_<yyyymmdd>`
`nd`	`NutritionDayLog`	`dm_nd_<clientId>_<yyyymmdd>`
`fr`	`FormResponse`	`dm_fr_<assignmentId>`

isDemoId(id) tests for the prefix. The fixed ids are also what makes reruns idempotent: inserts use createMany with skipDuplicates: true. Some writes are not marked with the prefix:

CheckinReview, ClientActivity and showcase InboxItem rows get ordinary generated ids.
Tasks created through createFormFilledTask are ordinary tasks.
Updates to existing rows (Client, FormAssignment, FormResponse handled fields, InboxItem status) carry no marker.

Removing demo data by id prefix alone therefore leaves these behind.

Live days and settled days

The writer treats the last two generated days as live. For those, DailyMetric and NutritionDayLog are upserted on clientId and date, so steps, water and eaten meals grow through the day as the hourly job reruns. Older days are settled and only inserted when missing.

The live-day upsert matches on clientId and date, not on the demo id. If a demo trainee has a real DailyMetric or NutritionDayLog row for today or yesterday, the job overwrites its steps, water and snapshot data. Keep real usage out of a studio that has demo mode on.

Run summary

runDemoActivity returns one result per demo studio.

{
  "studios": 1,
  "results": [
    {
      "studioId": "cma9s2k1t0000abcd1234efgh",
      "clients": 48,
      "appDays": 31,
      "workouts": 12,
      "cardio": 5,
      "weighIns": 9,
      "meals": 4,
      "metrics": 96,
      "nutritionDays": 71,
      "clientsTouched": 28,
      "filled": 3,
      "cancelled": 0,
      "handled": 2,
      "showcaseTasks": 1
    }
  ]
}

appDays, workouts, cardio, weighIns and meals count rows actually inserted. metrics and nutritionDays add the settled inserts to the number of live-day upserts, so they are never zero on an active studio.

Running it by hand

scripts/run-demo-activity.ts runs one pass against the configured database and prints the summary as JSON. Pass --days=N to backfill more history.

The script writes to whatever database DATABASE_URL points at. It only touches studios with settings.demoMode set to true.

API basics

Trainees

Plans and libraries

Tracking

Imports

Forms

Tasks and automation

Communication

Studio and billing

Admin and internal services

Trainee app API

Partner and automation

Public, internal and auth

Which studios are demo studios

Callers

The scheduler

What a run does

Eligible clients

Deterministic output

Personas

Today is generated up to the current time

Rows written per trainee and day

Forms and coach feedback

Showcase tasks

How fabricated rows are marked

Live days and settled days

Run summary

Running it by hand

​Which studios are demo studios

​Callers

​The scheduler

​What a run does

​Eligible clients

​Deterministic output

​Personas

​Today is generated up to the current time

​Rows written per trainee and day

​Forms and coach feedback

​Showcase tasks

​How fabricated rows are marked

​Live days and settled days

​Run summary

​Running it by hand

Which studios are demo studios

Callers

The scheduler

What a run does

Eligible clients

Deterministic output

Personas

Today is generated up to the current time

Rows written per trainee and day

Forms and coach feedback

Showcase tasks

How fabricated rows are marked

Live days and settled days

Run summary

Running it by hand