There probably needs to be another list for things to check during the demos.

• Check that the correct images are being used

  # Ensure correct product versions are used as well as 0.0.0-dev
  kubectl get pods -n default -o yaml | yq -y '.items[] | .status.containerStatuses[] | .image'
  # Ensure the 0.0.0-dev operators are used.
  kubectl get pods -n stackable-operators -o yaml | yq -y '.items[] | .status.containerStatuses[] | .image'

• Check the demo (duh)

For the release upgrade testing, we would modify it to ensure that the correct product versions are used, and the SDP X.XX version is used (not 0.0.0-dev).

On top of that, I think the demo should be run (according to the docs), and then the upgrade should be done. This mimics a real upgrade where there was data.

Just adding a different perspective to consider...

Tbh, I prefer using the checked out stack files explicitly on the command line.
The same changes get made, as you described, but if there are actual fixes needed, it is a matter of editing the same files and only checking in those changes (and reverting the other ones that get it working with nightly).

Not at all suggesting my way is better, but for me, doing the above, I would forget to unset the variable, or I would run a new shell that doesn't have it set, and invalidate the testing). I use the shell history heavily.