For Stakeholders

Why it matters

The PR's underlying motivation is legitimate: sandbox preview environments (one per active branch, ~19 active at a time per the PR description) are a recurring disk-space and build-time cost on the hosting infrastructure, and trimming unnecessary weight from those images is worthwhile ongoing hygiene work, not a one-off. This PR is labeled "Phase A" of that broader initiative.

Risk

Very low, and effectively self-verified. The change:

• Touches one line, one file, no application logic.
• Doesn't change a resolved dependency version, so the shared

yarn.lock is untouched — no re-install surprises for other branches or developers.

• Doesn't affect any runtime code path — the server only ever imports

@prisma/client, a separate, already-correct dependency declaration.

• Doesn't affect deploy-host tooling (pro, rollout.sh), which does a

full install regardless of dependency section.

The only real risk is reputational to the initiative's tracking: if the "~2.1 GB saved" figure is reported upward as delivered, that overstates progress. See below.

Impact — the honest number

The PR description estimates ~38 MB × 3 images × ~19 branches ≈ ~2.1 GB steady-state savings. Verified against the current Dockerfile and a live sandbox build of this exact PR (see Walkthrough and Feature breakdown):

• server image: 0 MB saved today. The build stage that produces it

(Dockerfile:288-308) deliberately doesn't use yarn install --production — a documented, intentional tradeoff already in the Dockerfile for install correctness on this repo's Yarn 1 + workspaces setup. Without --production, devDependencies install anyway, so relabeling prisma doesn't remove it. Confirmed live: the running server container in this PR's own sandbox still has prisma at 41 MB in node_modules.

• whatsapp-official image: 0 MB saved, but for an unrelated

reason — that build stage never copies packages/server/package.json into its context at all, so this PR's edit can't affect it either way.

• auth-api image: doesn't exist on this branch (the Dockerfile

explicitly dropped that target — no auth-server package present). There's nothing for this PR to affect there.

So: correct, low-risk, worth merging as a prerequisite step — but it does not deliver the disk savings stated in the PR description by itself, on the current Dockerfile. A follow-up change to server-runtime-deps (making --production reliable, or an explicit prune step) would be needed to realize the savings this PR is framed as delivering. Recommend tracking "Phase A" as "dependency hygiene landed" rather than "disk savings landed," and opening a follow-up for the actual image-size reduction.