chore: monthly docs defragmentation

src/pages/arcade/marketplace.md

@@ -7,6 +7,7 @@ description: Learn how to set up your game's Marketplace
 # Marketplace
 
 The Cartridge Marketplace brings onchain assets directly to your players, enabling richer and more complex game experiences.
+The marketplace works closely with [starter packs](./starter-packs) to distribute assets to players.
 
 ## Adding Assets
 

src/pages/arcade/overview.md

@@ -31,7 +31,7 @@ When you register a game or an edition, an NFT representing its ownership is min
 This NFT grants you admin rights over the game or edition.
 You can update the metadata of your game or any edition at any time --- including name, description, icon, image gallery, video, and more.
 
-For technical setup and configuration details, see [Arcade Setup](./setup).
+For technical setup and configuration details, see [Arcade Setup](./setup). For information on marketplace features and asset ownership, see [Arcade Marketplace](./marketplace).
 
 ![Register Game](/arcade-register-game.png)
 
@@ -57,10 +57,10 @@ No permission is required to register an edition in an existin game, meaning any
 ### 🚀 Publish and whitelist an Edition
 
 As the edition owner you have the ability to publish your edition once created.
-Once published, the game owner has the ability to whitelist you Edition to make it public.
+Once published, the game owner has the ability to whitelist you edition to make it public.
 
 :::info
-Any update within the Edition will turn off both the publish and the whitelist, the process should be repeat to make it public again
+Any update within the edition will turn off both the publish and the whitelist, the process should be repeat to make it public again
 :::
 
 ![Publish Edition](/arcade-publish-edition.png)

src/pages/arcade/setup.md

@@ -8,7 +8,7 @@ description: Learn how to register, configure, and index your game with Arcade,
 
 ## Torii Configuration
 
-To provide a rich user experience in Arcade, we recommend enhancing your Torii configuration to enable live activity feeds, asset indexing, and leaderboards. This configuration also supports marketplace functionality for asset display.
+To provide a rich user experience in Arcade, we recommend enhancing your Torii configuration to enable live activity feeds, asset indexing, and leaderboards. This configuration also supports [marketplace](/arcade/marketplace) functionality for asset display.
 
 ### ⚡️ Activity Feed
 

src/pages/arcade/starter-packs.md

@@ -7,15 +7,15 @@ description: Create and register starter packs on the Arcade registry to distrib
 # Starter Packs
 
 Starter packs let you bundle game assets and distribute them to players through a purchase flow integrated with [Cartridge Controller](/controller/starter-packs).
-The Arcade starter pack registry is a permissionless onchain system — anyone can register a starter pack by deploying an implementation contract and calling `register`.
+The Arcade starter pack registry is a permissionless onchain system --- anyone can register a starter pack by deploying an implementation contract and calling `register`.
 
 ## How It Works
 
 The registry follows a two-contract pattern:
 
-1. **Implementation contract** — a contract you deploy that implements the `IStarterpackImplementation` interface.
+1. **Implementation contract** --- a contract you deploy that implements the `IStarterpackImplementation` interface.
 When a player purchases your starter pack, the registry calls your contract's `on_issue` function to distribute assets.
-2. **Registry contract** — the Arcade registry where you register your implementation, set pricing, and configure options.
+2. **Registry contract** --- the Arcade registry where you register your implementation, set pricing, and configure options.
 
 ```
 Player purchases → Registry collects payment → Registry calls on_issue → Your contract distributes assets
@@ -100,8 +100,8 @@ The returned ID is what players use to purchase the starter pack via [`controlle
 
 Controls whether the same player can purchase the starter pack more than once.
 
-- `false` — each player can only purchase once, and `quantity` is forced to 1
-- `true` — players can purchase multiple times with any quantity
+- `false` --- each player can only purchase once, and `quantity` is forced to 1
+- `true` --- players can purchase multiple times with any quantity
 
 ### `referral_percentage`
 
@@ -113,7 +113,7 @@ Self-referrals (referrer == payer) are ignored.
 
 Where the base price (minus any referral fee) is sent.
 If `None`, payment goes to the starter pack owner (the address that called `register`).
-If `Some(address)`, payment goes to that address instead — useful for treasury contracts or revenue sharing.
+If `Some(address)`, payment goes to that address instead --- useful for treasury contracts or revenue sharing.
 
 ### `conditional`
 
@@ -146,17 +146,17 @@ let metadata = MetadataTrait::new(
 
 After registration, the owner can manage the starter pack:
 
-- **`update`** — change implementation, pricing, referral percentage, or other parameters
-- **`update_metadata`** — update the display metadata
-- **`pause`** / **`resume`** — temporarily disable or re-enable purchases
+- **`update`** --- change implementation, pricing, referral percentage, or other parameters
+- **`update_metadata`** --- update the display metadata
+- **`pause`** / **`resume`** --- temporarily disable or re-enable purchases
 
 ## Payment Flow
 
 When a player purchases a starter pack, the registry handles payment distribution:
 
-1. **Referral fee** — if a referrer is provided, their percentage is deducted from the base price and sent to them
-2. **Protocol fee** — a fee is added on top of the base price and sent to the Arcade fee receiver
-3. **Owner payment** — the remaining base price (after referral fee) is sent to the `payment_receiver` or owner
-4. **Asset distribution** — the registry calls `on_issue` on the implementation contract
+1. **Referral fee** --- if a referrer is provided, their percentage is deducted from the base price and sent to them
+2. **Protocol fee** --- a fee is added on top of the base price and sent to the Arcade fee receiver
+3. **Owner payment** --- the remaining base price (after referral fee) is sent to the `payment_receiver` or owner
+4. **Asset distribution** --- the registry calls `on_issue` on the implementation contract
 
 If `price` is zero, all payment steps are skipped and `on_issue` is called directly.

src/pages/controller/achievements.md

@@ -243,7 +243,7 @@ AchievableComponent.progress(
 
 ### Controller Configuration
 
-For policy configuration details, see [Sessions](./sessions).
+For configuration details including `slot` parameter, see [Configuration](./configuration).
 
 ```typescript
 new ControllerConnector({

src/pages/controller/booster-packs.md

@@ -169,7 +169,7 @@ Asset eligibility is typically determined by:
 
 ## Differences from Starter Packs
 
-While both use Merkle Drop technology, booster packs differ from starter packs in key ways:
+While both use Merkle Drop technology, booster packs differ from [starter packs](./starter-packs) in key ways:
 
 | Feature | Booster Packs | Starter Packs |
 |---------|---------------|---------------|

src/pages/controller/configuration.md

@@ -155,7 +155,7 @@ Without policies, transactions will fail because Katana does not support the pay
 :::
 
 Common issues to check:
-- **Missing policies**: Controller requires session policies when used with Katana. See [session configuration](/controller/sessions) for details.
+- **Missing policies**: Controller requires session policies when used with Katana. See the [Sessions](/controller/sessions) guide for details.
 - **RPC URL**: Katana defaults to `http://localhost:5050`. If you've configured a different port, update accordingly.
 - **Native currency address**: The STRK token address must match the token deployed on your Katana instance.
 
@@ -189,7 +189,7 @@ await controller.connect(); // Iframe is created and mounted now
 
 ### Propagate Session Errors
 
-The `propagateSessionErrors` option controls how contract execution errors are handled when using session-based transactions. When enabled, errors are returned directly to your application instead of showing the manual approval modal in the keychain.
+The `propagateSessionErrors` option controls how contract execution errors are handled when using session-based transactions. When enabled, errors are returned directly to your application instead of showing the manual approval modal in the keychain. For detailed information about session configuration, see the [Sessions](/controller/sessions) guide.
 
 **Example:**
 ```typescript
@@ -308,7 +308,7 @@ The configuration options are organized into several categories:
 
 ## Error Display Modes
 
-Controller provides configurable error handling through the `errorDisplayMode` option, allowing you to control how transaction and execution errors are presented to users. This gives you fine-grained control over the user experience during error scenarios.
+Controller provides configurable error handling through the `errorDisplayMode` option, allowing you to control how transaction and execution errors are presented to users. This gives you fine-grained control over the user experience during error scenarios. For more information about configuring error notifications, see the [Toast Notifications](/controller/toast-notifications) guide.
 
 ### Available Modes
 
@@ -456,32 +456,34 @@ try {
 
 ## When to Use Policies
 
-**Policies are optional** in Cartridge Controller. Choose based on your application's needs:
+**Session policies are optional** in Cartridge Controller. Choose based on your application's needs:
 
-### Use Policies When:
+### Use Session Policies When:
 - Building games that need frequent, seamless transactions
 - You want gasless transactions via Cartridge Paymaster
 - Users should not be interrupted with approval prompts during gameplay
 - You need session-based authorization for better UX
 
-### Skip Policies When:
+### Skip Session Policies When:
 - Building simple applications with occasional transactions
 - Manual approval for each transaction is acceptable
 - You don't need gasless transaction capabilities
 - You want minimal setup complexity
 
 ```typescript
-// Without policies - simple setup, manual approvals
+// Without session policies - simple setup, manual approvals
 const simpleController = new Controller();
 
-// With policies - session-based, gasless transactions
+// With session policies - session-based, gasless transactions
 const sessionController = new Controller({
   policies: {
     // ... policy definitions
   }
 });
 ```
 
+For detailed information about configuring session policies, see the [Sessions](/controller/sessions) guide.
+
 ## Dynamic Authentication Options
 
 Controller supports dynamic authentication configuration on a per-connection basis. This enables multiple branded authentication flows while using a single Controller instance.
@@ -590,7 +592,7 @@ controller.openPurchaseCredits();
 
 ### openStarterPack(starterpackId: string)
 
-Opens the starterpack purchase interface for a specific bundle.
+Opens the starter pack purchase interface for a specific bundle.
 
 ```typescript
 controller.openStarterPack("starterpack-id-123");

src/pages/controller/examples/cli.md

@@ -139,7 +139,7 @@ controller marketplace buy --order-id 42 --collection 0x123... --token-id 1 --ch
 
 ### Calldata formats
 
-Calldata values support multiple formats:
+`calldata` values support multiple formats:
 
 | Format | Example | Description |
 |--------|---------|-------------|
@@ -187,14 +187,14 @@ controller session auth --file <policy_file> --chain-id SN_MAIN --expires 1day
 | `--overwrite` | Overwrite existing session without confirmation | off |
 | `--expires` | Session expiration duration (e.g., `1min`, `1hr`, `1day`, `7days`, `1week`, `1year`) | `7days` |
 
-**Presets:** Popular games/apps have pre-defined policies:
+**Presets:** Popular games/apps have pre-defined session policies:
 - `loot-survivor` --- Loot Survivor game
 - `influence` --- Influence space strategy
 - `realms` --- Realms world
 - `pistols` --- Pistols at Dawn
 - `dope-wars` --- Dope Wars
 
-See all presets at [github.com/cartridge-gg/presets](https://github.com/cartridge-gg/presets/tree/main/configs).
+See [Sessions](/controller/sessions) for more information on policy structure and the complete list of available presets.
 
 ### `session status`
 
@@ -294,7 +294,7 @@ controller username
 
 ### `lookup`
 
-Resolves Cartridge controller usernames to addresses or vice versa.
+Resolves Cartridge Controller usernames to addresses or vice versa.
 
 ```bash
 # Look up addresses for usernames
@@ -498,10 +498,10 @@ Common errors and how to fix them:
 | `NoSession` | No keypair found | Run `session auth` |
 | `SessionExpired` | Session has expired | Run `session auth` again |
 | `InvalidSessionData` | Corrupted session data | Run `session clear` and start over |
-| `TransactionFailed` | Execution failed | Check policies and calldata |
+| `TransactionFailed` | Execution failed | Check policies and `calldata` |
 | `CallbackTimeout` | Authorization timed out | Run `session auth` again |
 | `ManualExecutionRequired` | No authorized session for this transaction | Register session with appropriate policies |
-| `InvalidInput` | Invalid input parameters | Check command syntax and calldata |
+| `InvalidInput` | Invalid input parameters | Check command syntax and `calldata` |
 
 When using `--json`, errors return structured responses with machine-readable codes and recovery hints:
 

src/pages/controller/examples/node.md

@@ -85,6 +85,8 @@ main().catch(console.error);
 
 ### Using Manual Policies
 
+For detailed information about session policy structure and configuration options, see [Sessions](../sessions).
+
 ```typescript
 import SessionProvider, {
   ControllerError,

src/pages/controller/examples/react.md

@@ -352,9 +352,11 @@ export function HeadlessLogin() {
 ```
 
 :::warning
-Headless mode requires that the user already has the specified signer (passkey, OAuth account, EVM wallet) associated with their Cartridge username. For new user registration, use the regular `connect()` flow which opens the UI.
+Headless mode requires that the user already has the specified `signer` (passkey, OAuth account, EVM wallet) associated with their Cartridge username. For new user registration, use the regular `connect()` flow which opens the UI.
 :::
 
+For more details on session policies and authentication options, see the [Sessions documentation](/controller/sessions).
+
 ### 5. Performing Transactions
 
 Execute transactions using the `account` object from `useAccount` hook:
@@ -425,7 +427,7 @@ export const TransferEth = () => {
 }
 ```
 
-### 4. Username Lookup
+### 6. Username Lookup
 
 The Controller provides a `lookupUsername` method that allows you to check if a username exists and see what authentication options are available for existing accounts. This is particularly useful for headless flows where you want to determine login vs signup flows:
 
@@ -548,7 +550,7 @@ Available `AuthOption` values include:
 - `"rabby"` - Rabby wallet
 - `"phantom-evm"` - Phantom wallet (EVM)
 
-### 5. Add Components to Your App
+### 7. Add Components to Your App
 
 ```typescript
 import { StarknetProvider } from './context/StarknetProvider'

src/pages/controller/examples/rust.md

@@ -57,10 +57,10 @@ async fn main() {
         chain_id,
     );
 
-    // Deploy the controller
+    // Deploy the Controller
     controller.deploy().await.unwrap();
 
-    // Interact with the controller
+    // Interact with the Controller
     // For example, execute a transaction
     let call = your_function_call(); // Define your function call
     controller.execute(vec![call], None).await.unwrap();

src/pages/controller/examples/svelte.md

@@ -10,19 +10,19 @@ description: Learn how to integrate the Cartridge Controller into your Svelte ap
 
 :::code-group
 
-```bash \[npm]
+```bash [npm]
 npm install @cartridge/controller starknet
 ```
 
-```bash \[pnpm]
+```bash [pnpm]
 pnpm install @cartridge/controller starknet
 ```
 
-```bash \[yarn]
+```bash [yarn]
 yarn add @cartridge/controller starknet
 ```
 
-```bash \[bun]
+```bash [bun]
 bun add @cartridge/controller starknet
 ```
 
@@ -63,6 +63,8 @@ let controller = new Controller({
 });
 ```
 
+For detailed information about session policy configuration and syntax, see [Sessions](../sessions).
+
 ### Connecting a Wallet
 
 Use the `connect` method to establish a connection:

src/pages/controller/getting-started.mdx

@@ -193,7 +193,7 @@ There are two providers, each with a different security and signing model.
 > ControllerProvider is the recommended provider for web applications.
 
 The default `ControllerProvider` (often exported as `Controller`) embeds the Cartridge keychain in a sandboxed iframe.
-Both the owner signer and a **session key** live inside the iframe, employing a trust model similar to any injected wallet (e.g. MetaMask, Argent).
+Both the owner `signer` and a **session key** live inside the iframe, employing a trust model similar to any injected wallet (e.g. MetaMask, Argent).
 
 When your app calls `execute()`, the request is forwarded to the iframe via `postMessage`.
 The keychain first tries to sign with the session key.
@@ -211,12 +211,12 @@ The `SessionProvider` is designed for environments where an iframe cannot be use
 Instead of embedding the owner key in an iframe, it:
 1. Opens a browser to the Cartridge keychain for one-time user authentication
 2. Generates an ephemeral session keypair locally
-3. **Registers the session key onchain** with the approved policies compiled into a merkle root
+3. **Registers the session key onchain** with the approved `policies` compiled into a merkle root
 4. Stores the session private key locally (in `localStorage` or on the filesystem)
 
 After registration, transactions are signed with the session key and executed via `executeFromOutside()` --- no further UI is needed.
-Because the session key is not the owner key, **policies are enforced onchain** --- every transaction must include a merkle proof showing the call matches the registered policies.
-The owner key is never exposed through this provider, so there is no fallback for calls outside the approved policies.
+Because the session key is not the owner key, **`policies` are enforced onchain** --- every transaction must include a merkle proof showing the call matches the registered `policies`.
+The owner key is never exposed through this provider, so there is no fallback for calls outside the approved `policies`.
 
 > For a visual comparison of how each provider authenticates and signs, see the [Architecture](/controller/architecture#auth-flows) page.