feat: release (#66)

- Fix for social cards (cover images)
- Update star position for better scrolling
- Fix searchbar overlapping wonderland logo
- Several markdown improvements
- Fix 'edit this page' links

Author: th0rOdinson

.github/ISSUE_TEMPLATE/🐞-bug-report.md

@@ -9,7 +9,7 @@ assignees: ''
 ---
 
 Thanks for helping us keep the Wonderland Handbook sharp and functional 🧹  
-If something isn’t behaving the way it should — from broken links to rendering issues — use this template to help us fix it fast.
+If something isn’t behaving the way it should: from broken links to rendering issues, use this template to help us fix it fast.
 
 ---
 

packages/common-config/src/components/HandbookSection/index.tsx

@@ -24,6 +24,7 @@ export interface HandbookSectionProps {
   handbooks: Handbook[];
   title: string;
   description: string;
+  className?: string;
 }
 
 interface HandbookCardProps {
@@ -73,9 +74,12 @@ export default function HandbookSection({
   handbooks,
   title,
   description,
+  className,
 }: HandbookSectionProps): ReactNode {
   return (
-    <section className={styles.handbooksSection}>
+    <section
+      className={`${styles.handbooksSection} ${className ? styles[className] || "" : ""}`}
+    >
       <img
         src="/common/img/star-icon.svg"
         alt=""

packages/common-config/src/components/HandbookSection/styles.module.css

@@ -11,6 +11,30 @@
   max-width: 66rem;
 }
 
+@media (max-width: 1200px) {
+  .handbooksSectionWonderland {
+    padding-top: 0.3rem;
+  }
+}
+
+@media (max-width: 1100px) {
+  .handbooksSectionWonderland {
+    padding-top: 1.5rem;
+  }
+}
+
+@media (max-width: 1024px) {
+  .handbooksSectionWonderland {
+    padding-top: 2.5rem;
+  }
+}
+
+@media (max-width: 996px) {
+  .handbooksSectionWonderland {
+    padding-top: 3rem;
+  }
+}
+
 .handbooksSeparator {
   display: flex;
   align-items: center;

packages/common-config/static/common/styles/global.css

@@ -473,6 +473,7 @@ nav.navbar.navbar--fixed-top + .main-wrapper {
     system-ui,
     -apple-system,
     sans-serif;
+  z-index: 1000;
 }
 
 .navbar__search-input::placeholder {

sites/optimism/docs/governance/bye.md

@@ -6,7 +6,7 @@ sidebar_label: Wrapping up
 
 # Wrapping Up
 
-To wrap up, where the OP Stack defines *how the system runs*, governance defines *how it changes*. It encodes: who can propose, who can vote, and who can veto. And because governance must evolve with the Collective, it’s designed to be both programmable and flexible—via modules, managers, and community experimentation.
+To wrap up, where the OP Stack defines *how the system runs*, governance defines *how it changes*. It encodes: who can propose, who can vote, and who can veto. And because governance must evolve with the Collective, it’s designed to be both programmable and flexible: via modules, managers, and community experimentation.
 
 As you’ve seen, governance isn’t just about casting votes. It’s about trust minimization, fault tolerance, consent, and credible neutrality. The system must balance legitimacy with execution, and decentralization with security.
 

sites/optimism/docs/governance/governance-overview.md

@@ -22,7 +22,7 @@ By the end of this section, you should be able to answer:
 - What’s the difference between an approval and a vote on Optimism?
 - Who can propose? Who can vote? What powers are delegated?
 - How do proposals move through states like Pending → Active → Executed?
-- How is quorum calculated, and what makes a proposal “pass”?
+- How is quorum calculated, and what constitutes “pass”?
 - What is Alligator, and why is delegation logic so complicated?
 - What happens if a delegate tries to push a proposal that violates cycle rules?
 - What is permissionless governance, and what tradeoffs does it introduce?

sites/optimism/docs/governance/governor-walkthrough.md

@@ -6,9 +6,9 @@ sidebar_label: Governor Walkthrough
 
 # The Optimism Governor Walkthrough
 
-The Optimism Governor is based on the OpenZeppelin’s Governor, customized to support Optimism’s governance needs: signaling proposals, customizable voting rules, subdelegations, and so on.
+The Optimism Governor is based on OpenZeppelin’s Governor, customized to support Optimism’s governance needs: signalling proposals, customizable voting rules, subdelegations, and so on.
 
-In the long run anyone should be able to propose changes, but safeguards like delegate approvals, quorum thresholds, and timelocks are required to ensure quality and protect against manipulation.
+In the long run, anyone should be able to propose changes, but safeguards like delegate approvals, quorum thresholds, and timelocks are required to ensure quality and protect against manipulation.
 
 Some useful resources: 
 
@@ -30,7 +30,7 @@ While proposals today are signaling-only for most types (i.e., they do not trigg
 
 - **`admin`**: Owns the proxy and controls upgrades. Does not vote or propose.
 - **`manager`**: Can create proposals, execute them, or update system parameters.
-- **`voters`**: Any address with delegated OP — either directly or through Alligator.
+- **`voters`**: Any address with delegated OP, either directly or through Alligator.
 
 ## Inheritance
 
@@ -64,7 +64,7 @@ propose(...):               // Standard proposal
 proposeWithModule(...):     // Proposal with custom voting module
 ```
 
-Only the `manager` or `timelock()` can call propose. Each proposal is assigned a `proposalType`, which maps to specific quorum/approval thresholds in the `ProposalTypesConfigurator`.
+Only the `manager` or `timelock()` can propose. Each proposal is assigned a `proposalType`, which maps to specific quorum/approval thresholds in the `ProposalTypesConfigurator`.
 
 Voting is handled via:
 - `castVote()`: standard token-based voting
@@ -77,7 +77,7 @@ Proposals are executed via the Timelock contract, using `execute()` or `executeW
 
 ### Alligator - Subdelegations
 
-The Alligator enables partial delegation, a user can split their voting power across multiple delegates using absolute or relative rules. These delegations can be chained (A → B → C) and validated onchain using authority[] arrays.
+The Alligator enables partial delegation; a user can split their voting power across multiple delegates using absolute or relative rules. These delegations can be chained (A → B → C) and validated onchain using authority[] arrays.
 
 The key structures are:
 - `subdelegations[from][to]`: maps delegations
@@ -102,9 +102,9 @@ Proposal thresholds are stored with 1e4 scaling (10000 = 100%). The Governor cal
 
 ## Votable Supply Oracle
 
-Instead of total token supply, quorum is based on votable supply — the total OP that has been delegated. This is retrieved at proposal creation block and used to calculate thresholds dynamically.
+Instead of the total token supply, quorum is based on votable supply — the total OP that has been delegated. This is retrieved at the proposal creation block and used to calculate thresholds dynamically.
 
-- **Fallback**: if `votableSupply()` returns zero, the Governor falls back to total token supply.
+- **Fallback**: if `votableSupply()` returns zero, the Governor falls back to the total token supply.
 
 ## Functions Summary
 
@@ -125,4 +125,4 @@ Instead of total token supply, quorum is based on votable supply — the total O
 
 ## Future Extensions
 
-We are working on an upgrade that is evolving toward permissionless proposals, enforced via `DelegatesProposalValidator` contract, it gates access to `propose()` based on delegate approvals and submission windows, allowing any qualifying participant to propose, while still preserving cycle alignment.
+We are working on an upgrade that is evolving toward permissionless proposals, enforced via `DelegatesProposalValidator` contract, which gates access to `propose()` based on delegate approvals and submission windows, allowing any qualifying participant to propose, while still preserving cycle alignment.

sites/optimism/docs/governance/intro-to-governance.md

@@ -8,13 +8,13 @@ sidebar_label: Governance in a nutshell
 
 Before we get into Optimism-specific contracts, let’s zoom out.
 
-On-chain governance is a mechanism for managing shared infrastructure using verifiable rules. In practice, governance contracts behave similar to multisigs, but with vote weights distributed across token holders rather than multisig signers.
+On-chain governance is a mechanism for managing shared infrastructure using verifiable rules. In practice, governance contracts behave similarly to multisigs, but with vote weights distributed across token holders rather than multisig signers.
 
 At its core, governance is about managing change. A **proposal** is just a transaction (or set of transactions): a list of target addresses, call data, and sometimes ETH values. Token holders vote to approve or reject the proposal. If the vote passes and quorum is met, the transaction can be executed onchain. If it fails, it’s simply discarded.
 
 Voting power is usually determined by the number of tokens an address holds at a specific snapshot block. Most systems also allow **delegation**, meaning you can assign your voting power to another address to vote on your behalf.
 
-Some proposals affect onchain systems directly (e.g. upgrading a contract). Others are **signaling-only** (e.g. changing a community guideline or legal structure). In those cases, proposals still follow the same governance flow, but their “execution” happens through offchain coordination or manual implementation.
+Some proposals affect onchain systems directly (e.g. upgrading a contract). Others are **signalling-only** (e.g. changing a community guideline or legal structure). In those cases, proposals still follow the same governance flow, but their “execution” happens through offchain coordination or manual implementation.
 
 ## Common Terms
 
@@ -33,7 +33,7 @@ These are the core terms used across most governance systems, including Optimism
 While implementations vary, the lifecycle of a proposal usually looks like this:
 
 ```nasm
-Pending ⭢ Active ⭢ Defeated ⭢ Canceled
+Pending ⭢ Active ⭢ Defeated ⭢ Cancelled
 			                 ⮑ Succeeded ⭢ Queued ⭢ Executed
 				                   ⮑----------⮑-------⮑  Expired
 ```
@@ -92,12 +92,12 @@ In particular, the [`GovernorCompatibilityBravo`](https://github.com/OpenZeppeli
 Most governance systems in Ethereum share the same building blocks:
 - A voting mechanism that calculates token-weighted power at a specific block (snapshot).
 - A registry of proposals with metadata like start/end blocks, vote tallies, and actions.
-- A timelock controller that enforces a minimum delay before execution.
+- A time lock controller that enforces a minimum delay before execution.
 - A quorum and approval threshold to ensure decisions are legitimate.
 
-On top of this, each protocol adds its own mechanics: delegation systems, role-based permissions, modular thresholds, and custom voting logic.
+On top of this, each protocol adds its mechanics: delegation systems, role-based permissions, modular thresholds, and custom voting logic.
 
-Some proposals are executable, others are advisory. Some are submitted by anyone, others require approvals. Governance is always opinionated, the trick is making those opinions legible and upgradeable.
+Some proposals are executable, others are advisory. Some are submitted by anyone, others require approval. Governance is always opinionated; the trick is making those opinions legible and upgradeable.
 
 ## Limitations and Responsibilities
 

sites/optimism/docs/governance/our-work/overview.md

@@ -8,7 +8,7 @@ This section documents active governance-related development initiatives led by
 
 ## Why it matters
 
-The governance is designed to evolve. Improvements often arise from practical bottlenecks observed by delegates, contributors, and protocol developers. This section records how those pain points are being addressed—through new contracts, improved interfaces, or procedural upgrades.
+The governance is designed to evolve. Improvements often arise from practical bottlenecks observed by delegates, contributors, and protocol developers. This section records how those pain points are being addressed through new contracts, improved interfaces, or procedural upgrades.
 
 Each entry aims to explain:
 

sites/optimism/docs/governance/our-work/permissionless-proposals.md

@@ -35,7 +35,7 @@ This contract wraps the proposal submission functions (`propose()` and `proposeW
 
 Its responsibilities include:
 
-- **Delegate approvals**: Verifies that the proposal has received enough sign-offs from top 100 delegates. Both the number of signers and their minimum voting power are configurable.
+- **Delegate approvals**: Verifies that the proposal has received enough sign-offs from the top 100 delegates. Both the number of signers and their minimum voting power are configurable.
 - **Window enforcement**: Ensures proposals are submitted within a designated submission window relative to the current voting cycle.
 - **GovernanceType validation**: Each proposal is tagged with a `GovernanceType`, which defines its eligibility rules, proposer constraints, and thresholds. There is no 1:1 mapping between GovernanceType and UI-facing proposal categories—one category (e.g., Protocol Upgrade) may have multiple GovernanceTypes depending on proposer roles and validation logic.
 - **Distribution limit**: Applies to funding proposals—checks that the requested OP does not exceed a configured limit for the cycle.
@@ -64,7 +64,7 @@ Its responsibilities include:
 ## Risks and Uncertainties
 
 - **GovernanceType complexity**: GovernanceTypes may proliferate as the system expands, especially since different proposers (e.g., Foundation vs. delegates) may have different rules for similar proposal categories. Care must be taken to manage and communicate this complexity to avoid confusion.
-- **Subdelegation ambiguity**: The system currently does not account for Alligator-style subdelegation. A delegate may appear in the top 100 due to delegated voting power, which may already be partially committed elsewhere—leading to unclear eligibility.
+- **Subdelegation ambiguity**: The system currently does not account for Alligator-style subdelegation. A delegate may appear in the top 100 due to delegated voting power, which may already be partially committed elsewhere, leading to unclear eligibility.
 - **Centralized configuration authority (MVP)**: Governance parameters are currently set by a single role. Long-term decentralization remains a critical roadmap goal.
 
 :::info reference