Put review before incompatible code exists

Late review turns a design question into a negotiation about sunk effort. By the time a large pull request reveals a changed contract, the implementation may include migrations, tests and interface work that all assume the new behaviour. Reviewers face pressure to accept it or ask for expensive rework.

Bring shared decisions into review when the shape of the change is known but implementation options are still open. This can happen in a short proposal attached to the work item. The proposal should name the existing decision, the requested change, affected components, migration concerns and unresolved questions.

Match review depth to consequence. A small compatible extension may need asynchronous confirmation from one owner. A state model change used by several systems benefits from a working session with the consumers. A change involving permissions, financial records or irreversible migration needs explicit evidence and approval from the roles responsible for those consequences.

Reviewers should test the proposal against concrete cases. What happens to existing records? Can old and new versions operate during deployment? How does a consumer distinguish the change? What will support staff see? What happens if one component deploys and another does not? These questions find integration problems earlier than a general judgement that the design looks sound.

Time-box the review path and expose its status. A proposal waiting without an owner encourages teams to proceed quietly. State who must respond, which concerns are blocking and when the decision will be revisited. Silence should not count as approval for a consequential change.

Keep implementation review connected to the accepted decision. The code review should link the record and show how tests cover the promised behaviour. This catches drift between an approved design and the version that was easiest to build.

Review can also confirm that no shared decision is involved. That is a useful result. The owning team can proceed locally without returning for central permission at each step. Record this only when the boundary is likely to be questioned again; otherwise ordinary pull-request history is enough.

Check whether affected teams see a contract change while there is still room to alter it, and whether the resulting decision is available to the next person who works in that area. Counting approvals does not answer either question.