Account abstraction modules

.github/account-abstraction.instructions.md

@@ -0,0 +1,16 @@
+---
+applyTo: "contracts/Session/*.sol"
+---
+
+# Estfor Account Abstraction AI Guide
+
+- Aim of the Session module is to abstract Web3 accounts away so that any user with an email and a passkey can sign transactions without paying for gas or require signing multiple transactions. The architecture for achieving this is as follows:
+
+1. User registers with an email and passkey
+2. A 1 of 1 multi-sig Safe is created where the signer is the user passkey.
+3. User authenticates with their passkey to create a new session - `UsageBasedSessionModule.enableSession` ([contracts/Session/UsageBasedSessionModule.sol](contracts/Session/UsageBasedSessionModule.sol)). The session key passed is a temporary throwaway private key stored in the users browser/device for the duration set.
+4. User uses their session private key to sign game transactions, then passes the arguments via an api to the hot DAO EOA signer that will call `UsageBasedSessionModule.execute`, and thus the designated game action.
+
+- The `UsageBasedSessionModule` contains the logic to restrict overuse and needless gas expense via the subsidised mechanism.
+- `GameRegistry` ([contracts/Session/GameRegistry.sol](contracts/Session/GameRegistry.sol)) contract contains all valid game actions that can be subsidised by the session module.
+- Safe module documentation can be found at https://docs.safe.global/advanced/smart-account-modules

.github/copilot-instructions.md

@@ -24,5 +24,8 @@
 - Do NOT add getter functions for mappings or arrays. Instead, emit events when data is added/updated and read data off-chain via events or direct storage reads. Contract size is more important than on-chain convenience functions.
 - Always follow Checks-Effects-Interactions pattern to prevent reentrancy issues. Update contract state before making any external calls.
 - Contract owners are expected to be Gnosis Safe multisigs. There are some scripts that may still use single EOA accounts as they haven't been updated yet. For new scripts, prefer the proposal pattern using `prepareUpgrade` and use the util function `sendTransactionSetToSafe` in `scripts/utils.ts`.
+- Use openzeppelin libraries for common functionalities like ERC standards, access control, upgradeability, and security features. Avoid reinventing the wheel.
+- Use `pnpm test <file>` to run specific test files during development for faster feedback.
+- Do not use `pnpm hardhat test <file>` as it forces a full recompile which slows down the workflow.
 
 If anything here feels off or incomplete, tell me what to clarify or expand.