For Support
Short version
This change is invisible to end users and to clinic staff. It doesn't touch any screen, workflow, API response, or data. Support should not expect any tickets caused by this PR.
What could theoretically go wrong (and how to tell)
Because this edits a package.json used to build the server runtime image, the only realistic failure mode is a broken deploy — not a broken feature:
- Symptom to watch for: the API fails to start, or a deploy/rollout
fails with a "module not found: prisma" or similar error when running a script that shells out to the prisma CLI in an environment that didn't install dev dependencies.
- Where that could happen: only on a full-install machine that (a)
skips dev dependencies (--production) and (b) tries to run a prisma-CLI-dependent script like studio, push:no:use, or pro from inside packages/server. Per Feature breakdown, the current server sandbox image build doesn't use --production at all, and the deploy-host pro/rollout.sh scripts run a full (non-production) yarn install — so this specific failure mode shouldn't occur on any path this repository currently uses.
- If it does happen: it would look like a build/deploy pipeline
issue, not a runtime bug reachable through the product UI. Escalate to engineering with the exact command and error rather than treating it as a user-facing incident.
What NOT to do
Don't spend time investigating clinic-facing bug reports (missing data, broken screens, slow queries) against this PR — it has no code path that could produce those symptoms. If a ticket seems connected to "something changed in a recent deploy," check other PRs in that deploy first.