chore: add requirements for IAccountExecute (#180)

Author: howydev

standard/ERCs/erc-6900.md

@@ -444,7 +444,7 @@ interface IExecutionHookModule is IModule {
     /// be more than one.
     /// @param sender The caller address.
     /// @param value The call value.
-    /// @param data The calldata sent.
+    /// @param data The calldata sent. For `executeUserOp` calls, hook modules should receive the full msg.data.
     /// @return Context to pass to a post execution hook, if present. An empty bytes array MAY be returned.
     function preExecutionHook(uint32 entityId, address sender, uint256 value, bytes calldata data)
         external
@@ -512,7 +512,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
+### Hooks
+
+#### Execution Hooks Data Format
+
+For accounts that implement execution hooks, accounts MUST conform to these execution hook formats:
+1. For `executeUserOp` calls, for execution hooks associated with a validation function, accounts MUST send the full `msg.data`, including the `executeUserOp` selector.
+2. For `executeUserOp` calls, for execution hooks associated with a selector, accounts MUST send `PackedUserOperation.callData` for `executeUserOp` calls, excluding `executeUserOp.selector` and the rest of the `PackedUserOperation`.
+3. For `executeWithAuthorization` calls, for all execution hooks, accounts MUST send the inner `data`.
+4. For all other calls, for execution hooks associated with a selector, accounts MUST send over `msg.data`. 
+
+#### 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.
 
@@ -540,7 +550,7 @@ If the selector being checked is `execute` or `executeBatch`, the modular accoun
 
 Installed validations have two flag variables indicating what they may be used for. If a validation is attempted to be used for user op validation and the flag `isUserOpValidation` is set to false, validation MUST revert. If the validation is attempted to be used for signature validation and the flag `isSignatureValidation` is set to false, validation MUST revert.
 
-#### Direct Call Validation.
+#### Direct Call Validation
 
 If a validation function is installed with the entity ID of `0xffffffff`, it may be used as direct call validation. This occurs when a module or other address calls a function on the modular account, without wrapping its call in the dispatcher function `executeWithAuthorization` to use as a selection mechanism for a runtime validation function.