For Training

Short version

There is nothing to teach clinic staff, patients, or any product user about this change — it has no user-facing surface. Skip it entirely in any customer- or staff-facing training material.

If this is used as an internal engineering-onboarding example

The change is small enough to be a decent teaching example for new engineers on the team about dependencies vs devDependencies semantics under Yarn 1 workspaces, and about verifying an infrastructure claim against the actual build instead of trusting a PR description. A short walk-through for that audience:

1. Look at the one-line diff in packages/server/package.json:226 —

prisma moves from dependencies to devDependencies.

1. Explain the intended mechanism: Docker image builds that pass

yarn install --production skip devDependencies, so re-filing a dev-only tool there is supposed to shrink production images.

1. Then show the actual mechanism in this repo's Dockerfile

(Dockerfile:303-308): the server image build deliberately skips --production because it's unreliable with this repo's Yarn 1 + workspaces setup. Walk through the live evidence in Walkthrough showing prisma is still installed in the running server container after this PR.

1. Land the lesson: a correct, well-reasoned change (re-filing a

mislabeled dependency) doesn't automatically deliver its intended effect if a downstream build step doesn't use the mechanism that makes the label matter. Always verify against the actual build config, not just the stated intent.

This is a useful case study precisely because the PR description and the actual Dockerfile disagree — see Feature breakdown for the full comparison.