Really depends on your engineering processes, but this is why you want to enforce good processes.

- Every change beyond the most insignificant package bump should be ticketed, and specifically tickets should document the business why.

- Every PR should include a high-level description of the change, and should document any technical whys. It should also link to the ticket.

- Code comments should be used where appropriate to document code-level whys and hows.

- For significant architectural changes ADRs should written up to document why the architectural change was made.

Failure for your team to do this results in the problem you're experiencing now.