architecturelisted

# Architecture review Contrasts what is being built against what the platform actually supports and what the rest of the field does. **This is not a code review**. It does not look at whether the code is well written, it looks at whether the decisions are the right ones. ## When it applies - When closing a stage, before the decision becomes expensive to change. - **Before replicating a pattern to another domain.** This is the point of highest leverage. A decision copied four times becomes irreversible. - When a decision starts to hurt and it is not clear whether the problem is the decision or the implementation. - When the vendor changes something relevant. ## The rigor rule, non-negotiable Every definitive statement about the platform -- "X cannot be done", "A is better than B", the limits of a feature -- is backed by **official documentation that was read**, citing the date of the page. - A search engine summary tells you **where to look**, never what to cite. - If the documentation does not say it explicitly, declare it as **your own inference or observation**, not as documented behavior. - Never say "here is the link that confirms it" without having read that specific link and checked that it says that. Platform products change often. Nothing known three months ago is settled. ## What to do ### 1. Inventory the decisions in force From architecture documents, contracts and artifact headers. Each one with: - What was decided. - When, and with what informa