The SOLID principles are most useful for writing reusable software components, like libraries or frameworks, and the OCPs idea is to create them in a manner to prevent unnecessary changes afterwards, even when requirements are extended or changed.

The Specification Pattern, as far as I understand it, is about creating complex business rules from small rule building blocks. So for this scenario, the reusable parts are the rule building blocks, not the aggregated business rules itself. And as you mentioned by yourself, the spec pattern provides you with a design where the set of rule building blocks can be easily extended without any change to other building blocks or infrastructure, so it follows the OCP.

However, when a complex business rule changes, you obviously have to change something in your system, and that is obviously the part where that business rule is defined. There is no pattern which can prevent the need for changes in the system completely when the rules change.

The only thing you can do here is to design the system in a way that the responsibility of the change is not completely at the developer side, buried somewhere deep inside the code, but to some degree on the users side, or at least moved to a place where it can be done by changing a configuration instead the core code. So the users themselfes can create or change complex business rules from the building blocks you provide for them. The typical approach for this is to create a DSL for this where the DSL elements refer to the elementary rules and the operators you defined using the spec pattern. The DSL code then can be stored in a config file which is maintained or extended by someone who is not the developer of the system, maybe a user or a "power user".

The SOLID principles are most useful for writing reusable software components, like libraries or frameworks, and the OCPs idea is to create them in a manner to prevent unnecessary changes afterwards, even when requirements are extended or changed.

The Specification Pattern, as far as I understand it, is about creating complex business rules from small rule building blocks. So for this scenario, the reusable parts are the rule building blocks, not the aggregated business rules itself. And as you mentioned by yourself, the spec pattern provides you with a design where the set of rule building blocks can be easily extended without any change to other building blocks or infrastructure, so it follows the OCP.

However, when a complex business rule changes, you obviously have to change something in your system, and that is obviously the part where that business rule is defined. There is no pattern which can prevent the need for changes in the system completely when the rules change.

The only thing you can do here is to design the system in a way that the part which need to be changed is not buried somewhere deep inside the code, but moved to a place where it can be edited by changing a separate configuration instead. This allows to shift the responsibility for changing to some degree from the developers to someone else, for example to the user of your system. So users may create or change complex business rules from the building blocks you provide for them. 

The typical approach for this is to create a DSL for this where the DSL elements refer to the elementary rules and the operators you defined using the spec pattern. The DSL code then can be stored in a config file which is maintained or extended by someone who is not the developer of the system, maybe a user or a "power user".