For Quality

What to test

This PR's own test plan lists three checks, none marked done in the PR at the time of this writing:

1. yarn install --production in packages/server no longer copies

prisma into node_modules/.bin/.

1. Runtime bootstrap (node packages/server/build/index.js) starts

successfully — no missing-module errors.

1. yarn workspace @dentolize/server run pro still works on a deploy

host (full install).

1. Existing CI passes.

Where the edges actually are

Checks 2–4 above should pass trivially — nothing in the runtime code path or the deploy-host scripts changed behavior (see Feature breakdown). The interesting one is #1, and it needs to be read carefully:

• **Testing packages/server in isolation with `yarn install

--production will show the fix "working"** — prisma won't be copied into node_modules/.bin/, because outside of a workspace context, --production` does filter by section correctly. This is a true but incomplete result.

• That is not what actually happens when the sandbox image is built.

The server Docker image is built via a workspace-wide yarn install (Dockerfile:288-308) that never passes --production at all — the stage's own comment explains this is deliberate, because --production is unreliable under this repo's Yarn 1 + workspaces setup. A test that only runs yarn install --production inside packages/server alone, disconnected from the actual multi-package workspace install the Dockerfile performs, will pass without proving the sandbox image actually shrank.

• The real check is to build (or inspect) the actual server image

target and look for node_modules/prisma. This was done live against this PR's own sandbox — see Walkthrough: prisma is still present, still ~41 MB, in the running server container after this change. If a future PR changes server-runtime-deps to actually filter dev dependencies, re-run this same check to confirm the image actually shrinks before crediting any disk-savings number.

Regression surface

Effectively none for product behavior — there's no code path exercised differently. The regression surface that matters is build/deploy tooling:

• Confirm yarn workspace @dentolize/server run pro still resolves and

runs prisma:migrate:deploy / prisma:generate on a full-install deploy host (unaffected per this PR, since pro runs a full yarn install with dev dependencies included).

• Confirm yarn studio / prisma db push (dev-only commands) still

work for a developer who has done a normal, non-production install — they will, since dev dependencies are always installed in a normal yarn install.

• There is no need to test any clinic-facing screen, API response, or

data path — none are reachable from this change.

Suggested test-plan correction

Recommend the PR's test plan be amended to test the actual Docker build target (docker build --target server) rather than an isolated yarn install --production inside packages/server, since the latter doesn't reflect how the image is really built on this branch.