In your comment you say you want to use SOLID "in the right way".
The only thing in SOLID I know might be your problem is Open/Closed principle. Making code open towards a change is a strategic design decision. Making code open towards specific change often requires creating specific abstractions, so that change can be by just adding new code, often in form of new module/library/plugin. And making code open towards one change frequently makes it closed towards other changes. And code closed towards a change makes that change much more difficult.
In your specific case, you decided to use a Strategy pattern. This pattern makes the code open towards adding new strategies. But it makes it closed towards changing what parameters are passed to the strategies. So your problem of adding new parameter became much more complicated if you didn't add the strategy pattern. Simplest solution is to just change the abstraction and fix all the broken strategy implementations. As you control the whole project, that shouldn't be too hard. There are ways to minimize impact of this change, like IDEs with refactoring support or automated tests (that you should have written). If this strategy abstraction was published one (eg. used by projects not under your control), then that would be much more difficult.