Dentolize · Dynamic Clinic Seeder Walkthrough
On this pageBusiness viewTechnical view

For Stakeholders

Business view

Why this matters

Preview environments are only as useful as the data inside them. An empty preview tells a reviewer almost nothing; a preview with a full, believable clinic lets them judge a change in seconds. This PR turns every branch preview into a realistic, year-old clinic — the difference between "the login works" and "I can see the invoice list render correctly with real numbers."

The payoff is faster, higher-confidence reviews and demos at effectively zero per-use cost: the data builds itself, deterministically, every time.

The strategic bet: merge-safety with the accounting module

The most important design decision here isn't visible in the UI. The entire seeder was copied byte-for-byte from the in-flight accounting branch, leaving out only the accounting-specific files. It behaves fully on its own today, and when the accounting module merges later, the accounting/HR/general-ledger behavior slots back in through a pre-built extension point ("the hook seam") with no merge conflicts.

In plain terms: this PR lets us land the shared demo-seeding infrastructure now, on the main line, without waiting for — or fighting with — the larger accounting work. The two branches stay in lockstep by construction.

Risk profile — deliberately low

  • No production surface. The seeder is a dev/CI script. It is not wired into

any customer request path.

  • Additive only. It creates a new company; it never edits or deletes existing

tenants during a normal run (config.js:5).

  • Guarded target. It refuses to touch a non-local database without an explicit

confirmation flag (config.js:105).

  • Idempotent. Redeploying a preview refreshes the login instead of stacking

duplicate clinics (index.js:71).

  • Synthetic data only. No real PII is generated or stored.

The two genuinely production-adjacent changes are small and backward-compatible:

  • S3 uploads gained optional support for S3-compatible stores (MinIO in the

sandbox). When the new env vars are unset — as in production — behavior is identical to before. See S3-compatible uploads.

  • A feature-flag seeder import-path fix.

What it unlocks next

  • Sandbox Ops and Sandbox QA automation workflows land alongside the

seeder: reseed/reset/redeploy/destroy a preview, and run an AI QA agent that can plan and file test "stories." These build directly on having rich, predictable data. See Sandbox & CI wiring.

  • A clean path to enable full accounting + payroll demo data the moment the

accounting module merges — no extra integration work.

Technical view

  • Merge invariant: the shared files must stay byte-identical across branches;

accounting behavior may enter only through accountingHooks.js via the hook seam (index.js:18-21, hooks.js:12-13). The generic build tolerates the accounting file's absence and fails loudly on any other load error (hooks.js:156-165).

  • Scope of change: 21 files. The bulk is the new, self-contained

dynamicSeed/ module and three CI workflow files; the only edits to existing server runtime code are s3.js, authMutations.js (upload URL/bucket), and a one-line import fix in seedFeatureFlags.js.

  • Determinism / auditability: fixed SEED, all randomness funneled through one

module (rng.js); the PR reports fixed-SEED journal md5-stability on the accounting branch as the regression gate.

  • Cost: no runtime cost to the product; CI cost is one seed run per preview

plus the optional detached docs/QA agents.

Pre-release framing. This is infrastructure on a feature branch. There is no customer rollout to plan; the decision in front of stakeholders is whether to merge shared demo-seeding infrastructure ahead of the accounting module.