diff --git a/scripts/build-site.sh b/scripts/build-site.sh
index de38160..b6d29b3 100755
--- a/scripts/build-site.sh
+++ b/scripts/build-site.sh
@@ -64,6 +64,23 @@ for name in ${CLOSURE//,/ }; do
   cp -a "$REPO/plugins/$name" "$OUT/plugins/"
 done
 cp -r "$REPO/frontend/dist" "$OUT/frontend-dist"
+
+# Runtime files a deployable tree needs beyond the Python packages. Without these
+# the staged tree can be imported but not actually run or migrated, so the
+# Windows installer (which consumes this output as its app\ payload) had to
+# assemble them separately - and could assemble a tree whose plugin set did not
+# match the profile it was built from.
+cp "$REPO/wsgi.py" "$REPO/requirements.txt" "$OUT/"
+cp -a "$REPO/migrations" "$OUT/"
+[ -d "$REPO/deploy" ] && cp -a "$REPO/deploy" "$OUT/"
+
+# Stage the profile INTO the tree. This is what makes the set self-describing:
+# `flask plugin apply-profile` at provisioning time reads the same profile the
+# tree was staged from, so the installed plugin set and the shipped plugin code
+# cannot drift. It is also what `flask plugin prune-schema` effectively keys off
+# (via what ends up installed), so a mismatch here would drop the wrong tables.
+cp "$PROFILE" "$OUT/site-profile.json"
+
 find "$OUT" -type d -name '__pycache__' -prune -exec rm -rf {} +
 find "$OUT" -type f -name '*.pyc' -delete
 
@@ -71,3 +88,8 @@ echo ""
 echo "Lean site staged at: $OUT"
 echo "  backend plugins:   $(ls "$OUT/plugins" | tr '\n' ' ')"
 echo "  (a plugin not listed is absent from both the backend tree and the bundle)"
+echo "  profile staged as: $OUT/site-profile.json"
+echo ""
+echo "At provisioning, after 'flask db upgrade' and 'flask plugin upgrade-all':"
+echo "  flask plugin apply-profile site-profile.json"
+echo "  flask plugin prune-schema --yes --force   # ADR-014; BOTH flags required"