My #1,2, and 3 rules are to get the code in the right place. You could vaguely say that is architecture related--is it in the main app, a library, etc... Those decisions can be tough for junior developers and can often be disputed by seniors (we don't need a library yet.)

"Architecture" is very vague and used a lot of different ways.

To be honest, after reading this document, I believe it contain MUCH more information than just how to conduct a code review.

# This is for a code review which would be well after architecture and be the entirely wrong place to systematically question architecture.

I think that is part of the scrum philosophy: management can question whatever it wants and whenever it wants to; if the timeframe explodes that that is the blame of the developer.