fix: remove enforcing hook execution ordering wording

standard/ERCs/erc-6900.md

@@ -528,13 +528,17 @@ During execution uninstallation, the account MUST correctly clear flags and othe
 - the account SHOULD call `onUnInstall` on the execution module to initialize the states and track call success if required by user.
 - the account MUST emit `ExecutionUninstalled` as defined in the interface for all uninstalled executions.
 
+#### Hook execution order
+
+It is RECOMMENDED that an account implementer runs hooks in first installed first executed order. However, an account MAY implement a different execution order.
+
 ### Validation Call Flow
 
 Modular accounts support three different calls flows for validation: user op validation, runtime validation, and signature validation. User op validation happens within the account's implementation of the function `validateUserOp`, defined in the ERC-4337 interface `IAccount`. Runtime validation happens through the dispatcher function `executeWithAuthorization`, or when using direct call validation. Signature validation happens within the account's implementation of the function `isValidSignature`, defined in ERC-1271.
 
 For each of these validation types, an account implementation may specify its own format for selecting which validation function to use, as well as any per-hook data for validation hooks.
 
-Within the implementation of each type of validation function, the modular account MUST check that the provided validation function applies to the given function selector intended to be run. Then, the account MUST execute all validation hooks of the corresponding type associated with the validation function in use. These hooks MUST be executed in the order specified during installation. After the execution of validation hooks, the account MUST invoke the validation function of the corresponding type. If any validation hooks or the validation function revert, the account MUST revert. It SHOULD include the module's revert data within its revert data.
+Within the implementation of each type of validation function, the modular account MUST check that the provided validation function applies to the given function selector intended to be run. Then, the account MUST execute all validation hooks of the corresponding type associated with the validation function in use. After the execution of validation hooks, the account MUST invoke the validation function of the corresponding type. If any validation hooks or the validation function revert, the account MUST revert. It SHOULD include the module's revert data within its revert data.
 
 The account MUST define a way to pass data separately for each validation hook and the validation function itself. This data MUST be sent as the `userOp.signature` field for user op validation, the `authorization` field for runtime validation, and the `signature` field for signature validation.
 
@@ -564,7 +568,7 @@ For all non-view functions within `IModularAccount` except `executeWithAuthoriza
 
 If the caller is not the EntryPoint or the account, the account MUST check access control for direct call validation.
 
-Prior to running the target function, the modular account MUST run all pre execution hooks that apply for the current function call. Pre execution hooks apply if they have been installed to the currently running function selector, or if they are installed as a permission hook to the validation function that was used for the current execution. Pre execution hooks MUST run validation-associated hooks first, in the order they were installed, then selector-associated hooks second, in the order they were installed.
+Prior to running the target function, the modular account MUST run all pre execution hooks that apply for the current function call. Pre execution hooks apply if they have been installed to the currently running function selector, or if they are installed as a permission hook to the validation function that was used for the current execution. Pre execution hooks MUST run validation-associated hooks first, then selector-associated hooks second.
 
 Next, the modular account MUST run the target function, either an account native function or a module-defined execution function.