chore: small writing improvements

sites/wonderland/docs/processes/github/git-environment.md

@@ -1,12 +1,12 @@
 # Git Enviroment
 
 :::tip
-The most secure approach is to create a separate user account on your computer for your anonymous profile, completely isolating it from your one. **This provides the strongest separation of concerns and security.**
+The most secure approach is to create a separate user account on your computer for your anonymous profile, completely isolating it from your existing one. **This provides the strongest separation of concerns and security.**
 :::
 
 The following guide describes how to configure both profiles under a single user account if you choose not to create a separate user. However, be aware that this is less secure than full user isolation.
 
-This guide walks you through setting up dual Git environments on WSL2 - one for personal use and another for anonymous DeFi use. You'll learn how to:
+This guide walks you through setting up dual Git environments on WSL2 - one for personal use and another for anonymous (anon, if you're a cool kid) use. You'll learn how to:
 
 - Configure separate Git profiles with different identities
 - Generate and manage SSH keys for each profile
@@ -21,11 +21,11 @@ This guide walks you through setting up dual Git environments on WSL2 - one for
 
 ## Directory Structure Setup
 
-Create separate directories for personal and DeFi development:
+Create separate directories for personal and anon development:
 
 ```bash
 mkdir ~/personal
-mkdir ~/defi
+mkdir ~/anon
 ```
 
 ## Git Profile Configuration
@@ -49,10 +49,10 @@ Add the following configuration (replace with your details):
         gpgsign = true
 ```
 
-### Create DeFi Profile
+### Create anon Profile
 
 ```bash
-nano ~/.gitconfig-defi
+nano ~/.gitconfig-anon
 ```
 
 Add the following configuration:
@@ -72,7 +72,7 @@ Add the following configuration:
 
 ```bash
 mkdir -p ~/.ssh/personal
-mkdir -p ~/.ssh/defi
+mkdir -p ~/.ssh/anon
 ```
 
 ### Generate personal SSH key
@@ -86,15 +86,15 @@ When prompted:
 - Save to: `/home/your_user/.ssh/personal/id_ed25519`
 - Set passphrase (optional)
 
-### Generate DeFi SSH key
+### Generate anon SSH key
 
 ```bash
 ssh-keygen -t ed25519 -C "[email protected]"
 ```
 
 When prompted:
 
-- Save to: `/home/your_user/.ssh/defi/id_ed25519`
+- Save to: `/home/your_user/.ssh/anon/id_ed25519`
 - Set passphrase (optional)
 
 ### Add SSH keys to GitHub
@@ -103,8 +103,8 @@ When prompted:
 # View personal key
 cat ~/.ssh/personal/id_ed25519.pub
 
-# View DeFi key
-cat ~/.ssh/defi/id_ed25519.pub
+# View anon key
+cat ~/.ssh/anon/id_ed25519.pub
 ```
 
 Add each public key to the corresponding GitHub account under Settings → SSH Keys.
@@ -142,7 +142,7 @@ Add the output to GitHub under Settings → GPG Keys.
 
 ### Update your Git configs with the GPG key ID:
 
-- Edit both `~/.gitconfig-personal` and `~/.gitconfig-defi`
+- Edit both `~/.gitconfig-personal` and `~/.gitconfig-anon`
 - Add the key ID to the `signingkey` field
 
 ## Profile Integration
@@ -158,8 +158,8 @@ Add:
 ```
 [includeIf "gitdir:~/personal/"]
         path = .gitconfig-personal
-[includeIf "gitdir:~/defi/"]
-        path = .gitconfig-defi
+[includeIf "gitdir:~/anon/"]
+        path = .gitconfig-anon
 [program]
         pgp = /usr/bin/gpg
 [core]
@@ -175,11 +175,11 @@ nano ~/.ssh/config
 Add:
 
 ```
-Host github-defi
+Host github-anon
         HostName github.com
         User git
         IdentitiesOnly yes
-        IdentityFile ~/.ssh/defi/id_ed25519
+        IdentityFile ~/.ssh/anon/id_ed25519
 
 Host github.com
         HostName github.com
@@ -204,10 +204,10 @@ For personal repos:
 git clone [email protected]:owner/repo.git
 ```
 
-For DeFi repos:
+For anon repos:
 
 ```bash
-git clone git@github-defi:owner/repo.git
+git clone git@github-anon:owner/repo.git
 ```
 
 ### Verifying Setup
@@ -218,8 +218,8 @@ Test SSH connection:
 # Personal
 ssh -T [email protected]
 
-# DeFi
-ssh -T git@github-defi
+# anon
+ssh -T git@github-anon
 ```
 
 Test GPG signing:
@@ -260,12 +260,12 @@ echo "test" | gpg --clearsign
 ```bash
 eval $(ssh-agent -s)
 ssh-add ~/.ssh/personal/id_ed25519
-ssh-add ~/.ssh/defi/id_ed25519
+ssh-add ~/.ssh/anon/id_ed25519
 ```
 
 2. Verify key permissions:
 
 ```bash
 chmod 600 ~/.ssh/personal/id_ed25519
-chmod 600 ~/.ssh/defi/id_ed25519
-```
+chmod 600 ~/.ssh/anon/id_ed25519
+```

sites/wonderland/docs/processes/project-lifecycle.md

@@ -37,7 +37,7 @@ All our partners have a front-row seat to the action through a real-time view of
 
 We strive to follow strict [code quality and style guidelines](/development/solidity/coding-style.md) while accommodating our partners’ preferred coding style to the best of our capacity. We will also contribute suggestions for code-base improvements, even if they exceed the project’s defined scope.
 
-- **More than 100% test coverage:** All agreed test suites from the tech design must be completed. Sometimes, 100% coverage isn’t enough, so we include fuzzing, E2E edge cases, and invariant tests. Here’s an example: https://github.com/allo-protocol/allo-v2/tree/v2.1/test
+- **More than 100% test coverage:** All agreed test suites from the tech design must be completed. For smart contracts 100% test coverage is _just the starting point_, so we include fuzzing, E2E edge cases, and invariant tests. Here’s an example: https://github.com/allo-protocol/allo-v2/tree/v2.1/test
 - **Automated alerts & monitoring dashboards:** Every metric outlined in the tech design is tracked via a dashboard, for example, [Dune](https://dune.com/defi_wonderland/mev-bots) or [Grafana](https://snapshots.raintank.io/dashboard/snapshot/pdIYOBrhqixu0lpidVXH4dsEF1iwclMO?orgId=2). We’ll help set up any required infrastructure if needed, and alerts will be configured to speed up issue response times.
 - **Code standards:** We use [custom Solhint rules](https://github.com/solhint-community/solhint-community) to ensure consistent code quality and accurate reviews. The code must comply with the standard linting and code-quality rules in the tech design.
 - **Deployment scripts:** Automated deployment scripts ensure precise and reliable deployments to all required networks.
@@ -47,16 +47,16 @@ We strive to follow strict [code quality and style guidelines](/development/sol
 
 ## Advanced Testing Campaign 🧪 
 
-As mentioned before, we take our work seriously. Testing at Wonderland is a continuous process that begins before the first line of code is written and extends throughout the entire development lifecycle. Our testing framework reflects years of experience in securing infrastructure.
+As mentioned before, we take testing seriously. Testing at Wonderland is a continuous process that begins before the first line of code is written and extends throughout the entire development lifecycle. Our testing framework reflects years of experience in securing infrastructure.
 
-During development, each Solidity developer is responsible for writing unit and integration tests. These tests aim to cover all major branches and paths of the logic, ensuring every segment of code works as intended. Meanwhile, integration tests validate how different parts of the system interact, often running on network forks to replicate real-world behavior. This _QA phase_ ensures continuous monitoring and improvement of the protocol as it evolves.
+During development, every Solidity developer is responsible for writing unit and integration tests. The former aim to cover all major branches and paths of the business logic, ensuring every segment of code works as intended. Meanwhile, integration tests validate how different parts of the system interact, often running on forked environments replicating real-world behavior. This _QA phase_ ensures continuous monitoring and improvement of the protocol as it evolves.
 
-Once development is complete, the project undergoes an internal review and more advanced testing, led by a specialized team. This team focuses on invariants, formal verification methods, and advanced fuzzing using tools like Echidna and Medusa. Detailed properties (documented in a `PROPERTIES.md` file) guide this phase to ensure nothing is missed. This step confirms that the system meets higher-level correctness standards and can handle unexpected scenarios, finalizing the testing process before the protocol moves into production.
+Once development is complete, the project undergoes an internal review and more advanced testing, led by a specialized team. This team focuses on invariants, formal verification methods, and advanced fuzzing using tools like Echidna and Medusa. Detailed properties (documented in a `PROPERTIES.md` file, and agreed upon in the tech design phase) guide this phase to ensure nothing is missed. This step confirms that the system meets higher-level correctness standards and can handle unexpected scenarios, finalizing the testing process before the protocol moves into production.
 For further reading on how we do testing, see [Testing Campaign Processes](/testing/campaign-processes.md) and [Unit and Integration Testing](/testing/unit-integration.md).
 
 ## Internal Reviews 🔍 
 
-Millions of dollars rely on the security of on-chain code, and history proves that even a single oversight can cause devastating losses. At Wonderland, we treat every codebase as critical infrastructure, reinforcing the mantra that security must be present at each phase of development—from ideation, design, and coding, right through to deployment and beyond. We prioritise security by having developers adopt a “break it” mentality in internal reviews, so any potential flaws are discovered before an external audit or public launch. This ensures we don’t lean solely on third-party auditors for final protection and keeps _lazy_ code or testing from slipping through.
+Millions of dollars rely on the security of on-chain code, and history proves that even a single oversight can cause devastating losses. At Wonderland, we treat every codebase as critical infrastructure, reinforcing the mantra that security must be present at each phase of development—from ideation, design, and coding, right through to deployment and beyond. We prioritise security by deliberately tasking OCD-ridden animals to break our designs & implementations in an explicit development phase we call 'internal review', so any potential flaws are discovered before an external audit or public launch. This ensures we don’t lean solely on third-party auditors for final protection and keeps _lazy_ code or testing from slipping through.
 
 Our internal review process kicks in once development is finished and the code is _frozen._ A specialized Security Team (or developers who switch to an attacking mindset) meticulously examines the code for bugs, logic flaws, and opportunities to improve best practices and security. If critical issues are found, we conduct internal post-mortems to learn how they went unnoticed, then immediately fix and recheck before delivering the revised code to external auditors. This multi-layered approach—coupled with thoughtful fix management, code-based complexity estimates, and thorough post-review analysis—helps us produce robust and resilient protocols.
 
@@ -82,6 +82,8 @@ We apply:
 
 The Emergency Plan provides a step-by-step guide for handling emergencies (e.g., exploits, active hacks). Partners can immediately report an incident by using the form available on their Partner page on our Notion. The plan also includes a ready-to-use Discord template —https://discord.new/aPnYUdJM6mkc or https://discord.new/CkADqy5aWsAH— for quickly creating a **War Room** where trusted members can coordinate actions in real time.
 
+<!-- TODO: shill how our offchain tools could proactively detect & notify about the emergency? -->
+
 Once the War Room is set up, a checklist ensures every critical step is covered:
 
 - Assign key roles such as Operations, Strategy Lead, etc

sites/wonderland/docs/security/multisig/hardware-requirements.md

@@ -1,7 +1,7 @@
 # Hardware Requirements for Signers
 
 :::tip
-- **DOs:**
+- **DO:**
     - Use an isolated device **solely** for signing transactions.
     - Enable biometric verification (face ID, fingerprint).
     - Set up remote wipe/lock features.
@@ -62,4 +62,4 @@ Wi-Fi. Using device with a 3G/4G connection via eSIM significantly reduces the a
 
 To be honest, 
 
-Any device with **face** or **fingerprint** **id**, and bluetooth or usb adaptator that works with the hardware wallet will be enough. Also touch ID / fingerprint could be added as an external device too.
+Any device with **face** or **fingerprint** **id**, and bluetooth or usb adaptator that works with the hardware wallet will be enough. Also touch ID / fingerprint could be added as an external device too.