Add @paima/rest documentation

docs/home/0-what-is-paima-engine.md

@@ -90,7 +90,7 @@ Projects may want to allow users to play games with NFTs hosted on chains separa
 
 To enable this, we will enable users to time-lock their NFTs (self-custodial) to project their NFTs directly into the game. Note that thanks to Paima being powered by a Sovereign Rollup architecture, this scheme isn't required for projecting L1 NFTs to L2s (if for example deploying a Paima game as a L3 on top of a L2 like Arbitrum)
 
-You can find more about the idea [here](./7-multichain-support/1-projected-nfts/1-introduction.mdx)
+You can find more about the idea [here](./700-multichain-support/1-projected-nfts/1-introduction.mdx)
 
 ## Non-custodial L2s
 

docs/home/1-setup/1-how-to-use-paima-engine.md

@@ -125,7 +125,7 @@ These logs denote the block height numbers that the game node is syncing from th
 
 Now that your game node is syncing, we recommend testing to ensure that both the contract you deployed and the node itself are all in working order/configured properly.
 
-Simply follow the [posting test game inputs to L2 contract tutorial](../2-read-write-L2-state/4-posting-test-game-inputs.md) and within a couple minutes you'll have experienced the end-to-end loop of using Paima Engine!
+Simply follow the [posting test game inputs to L2 contract tutorial](../200-read-write-L2-state/4-posting-test-game-inputs.md) and within a couple minutes you'll have experienced the end-to-end loop of using Paima Engine!
 
 Of note, the above tutorial teaches you an easy way to manually submit custom-crafted game inputs, which is also useful when implementing new features as you develop your games/apps.
 

docs/home/1-setup/4-environment-config-values.md

@@ -53,7 +53,7 @@ This section includes optional environment variables that have sensible default
 - `DEPLOYMENT`: was used in the past to determine how often new blocks are emitted. It is now _deprecated_ and replaced with `BLOCK_TIME`.
 - `GAME_NODE_VERSION`: defined statically in `@paima/sdk`. Check used to ensure your game node is running with a compatible version of paima-engine. After a major upgrade and necessary adjustments, you should adjust the version on your side.
 - `NATIVE_NFT_SALE_PROXY`: used in the NFT LvlUp template. It represents the contract address for your NFT sale proxy. See [deploying-your-stateful-nft](./3-deploying-your-stateful-nft.md)
-- [Primitive Catalogue](../3-react-to-events/2-primitive-catalogue/1-introduction.md):
+- [Primitive Catalogue](../300-react-to-events/2-primitive-catalogue/1-introduction.md):
   - `DEFAULT_PRESYNC_STEP_SIZE`: number of blocks to process in each step during initial presync phase. If not provided, a value of 1000 is used. Generally no need to change this value.
   - `CDE_CONFIG_PATH`: allows you to specify a custom location for your `extensions.yml` that is used to initialize primitive catalogue entries
 

docs/home/1-setup/5-paima-bacher.md

@@ -16,7 +16,7 @@ Furthermore, batcher support is fully integrated into Paima Engine, including th
 
 Of note, because Paima Engine games are full fledged Sovereign Rollups, this means we have a built-in mechanism for democratization & decentralization of batching (unlike the majority of rollups today). In other words, anyone can run a batcher for any game built with Paima Engine, opening up opportunities for your community & 3rd party developers to create their own web/mobile game clients, tools, websites, and services that provide players with completely novel gameplay experiences!
 
-You can learn more about the architecture of the batcher [here](../2-read-write-L2-state/5-batched-mode.md)
+You can learn more about the architecture of the batcher [here](../200-read-write-L2-state/5-batched-mode.md)
 
 ## Benefits
 

docs/home/2-read-write-L2-state/2-parallelism.md → docs/home/200-read-write-L2-state/2-parallelism.md

@@ -37,7 +37,7 @@ For example, maybe a game needs to update each user's wins/losses/ties record. W
 
 As such, we need a new approach for how we can apply global side effects in a principled manner. Lucky for us, we already have a great piece of functionality implemented in Paima Engine exactly suited for this job: scheduled inputs.
 
-Using scheduled inputs, whenever a global side effect needs to be applied, we simply create a new scheduled input for `[current block height] + 1` (see [passive events](../3-react-to-events/1-scheduled-events.md) to learn more) and ensure that it also carries a state identifier inside. Thus in our grammar, we can simply define a new type of valid (scheduled) game input which specifies that the given user's stats need to be updated with the resulting win/tie/loss:
+Using scheduled inputs, whenever a global side effect needs to be applied, we simply create a new scheduled input for `[current block height] + 1` (see [passive events](../300-react-to-events/1-scheduled-events.md) to learn more) and ensure that it also carries a state identifier inside. Thus in our grammar, we can simply define a new type of valid (scheduled) game input which specifies that the given user's stats need to be updated with the resulting win/tie/loss:
 
 ```typescript
 const myGrammar = `

docs/home/3-react-to-events/1-scheduled-events.md → docs/home/300-react-to-events/1-scheduled-events.md

@@ -20,4 +20,4 @@ Notably, `deleteScheduledData` is very useful to cancel timers. For example, a u
 
 ## 2. Synchronizing access to a shared state
 
-See [parallelism](../2-read-write-L2-state/2-parallelism.md)
+See [parallelism](../200-read-write-L2-state/2-parallelism.md)

docs/home/3-react-to-events/2-primitive-catalogue/1000-create-your-own.md → docs/home/300-react-to-events/2-primitive-catalogue/1000-create-your-own.md

@@ -23,4 +23,4 @@ It depends what you want. If actions in your dApp do no directly tie into the ga
 
 ### Q: All this seems only for reading state. What about writing state?
 
-Primitives are just about reading state from the chain and evolving the game based off of them. For creating transactions from the game frontend, you can use whatever API you prefer for creating the transaction. Do keep in mind that Paima does come with its own [account abstraction framework](https://docs.paimastudios.com/home/multichain-support/wallet-layer) for creating wallets, so if your API for creating transactions is too high-level (ex: if it handles the entire flow from wallet initialization through `window.ethereum` down to creating the transaction) it may be hard to combine with our account abstraction framework.
+Primitives are just about reading state from the chain and evolving the game based off of them. For creating transactions from the game frontend, you can use whatever API you prefer for creating the transaction. Do keep in mind that Paima does come with its own [account abstraction framework](../../700-multichain-support/2-wallet-layer/1-introduction.mdx) for creating wallets, so if your API for creating transactions is too high-level (ex: if it handles the entire flow from wallet initialization through `window.ethereum` down to creating the transaction) it may be hard to combine with our account abstraction framework.

docs/home/350-game-node-api/1-introduction.md

@@ -0,0 +1,11 @@
+# Basic Concepts
+
+Games need to communicate not just with their UI, but also the rest of the web2 world that may want to interact with the game state.
+
+## OpenAPI
+
+To achieve this, Paima Engine comes with support for [OpenAPI](https://www.openapis.org/) so humans can easily interact with the node and can easily generate client libraries for games in a variety of languages. After starting your node, visit `http://localhost:3333/docs/` to see all the endpoints.
+
+To have your game's OpenAPI definition also show up in the docs, simply place an `openapi.json` file inside the `packaged` folder generated by your game, and Paima will automatically detect it.
+
+

docs/home/350-game-node-api/_category_.json

@@ -0,0 +1,3 @@
+{
+    "label": "Game Node API"
+  }

docs/home/4-randomness/index.md → docs/home/400-randomness/index.md

@@ -20,15 +20,15 @@ As such, these are the pieces of data which we can start to build randomness fro
 1. Use `interimSeed` to randomly add in bits of the block like user addresses, nonces and submitted data during that block
 1. Return `base64(sha256([...selectedChainData, latestChainData.blockHash, ...blockSeeds].join(',')))`
 
-The goal of this algorithm including bits of `ChainData` for the block is because Paima may have multiple [funnels](../3-react-to-events/3-funnel-types/1-intro.md) that aggregate data from multiple locations and so this would ensure some parts of every funnel get included in the randomness generation. However, most likely we'll improve this seed generation process in the future.
+The goal of this algorithm including bits of `ChainData` for the block is because Paima may have multiple [funnels](../300-react-to-events/3-funnel-types/1-intro.md) that aggregate data from multiple locations and so this would ensure some parts of every funnel get included in the randomness generation. However, most likely we'll improve this seed generation process in the future.
 
 ## Prando (deterministic stateful randomness generation from a seed)
 
 Seeds such as those stored in blocks can be combined with a utility class called `Prando` for most of the common randomness requirements
 
 `Prando` takes inspiration from the same randomness generation trick [used in old video games](https://www.gamedeveloper.com/programming/how-classic-games-make-smart-use-of-random-number-generation), where actions taken by the player updates internal state of the randomness generator which modifies its subsequent actions. That means calling Prando twice given the same block seed will give different (yet still deterministic) results.
 
-Note this also means that you can to be careful using Prando if your game is leveraging [parallelism](../2-read-write-L2-state/2-parallelism.md) or optimistic updates.
+Note this also means that you have to be careful using Prando if your game is leveraging [parallelism](../200-read-write-L2-state/2-parallelism.md) or optimistic updates.
 
 ```typescript
 import Prando from '@paima/sdk/prando';

docs/home/7-multichain-support/1-projected-nfts/1-introduction.mdx → docs/home/700-multichain-support/1-projected-nfts/1-introduction.mdx

@@ -7,7 +7,7 @@ The Projected NFT Whirlpool system allows existing NFTs to be used in games writ
 
 **Motivation**: many games, due to being data and computation heavy applications, run on sidechains, L2s and appchain as opposed to popular L1 blockchains. This is problematic because popular NFT collections (which people generally want to use in-game) live on the L1 (a different environment). A common solution to this problem is building an NFT bridge, but bridges not only have a bad reputation for fungible tokens which limits usage, the problem is even worse for NFTs where there is also a philosophical disconnect (if a bridge gets hacked, which is the canonical NFT? The one the hacker stole, or the bridged asset?)
 
-**Solution**: instead of bridging NFTs, we instead encourage users to _project_ their NFT directly into the game, allowing them to access their asset in-game without having to bridge it to the game chain. Although the main use-case is projecting a single NFT, we support projecting multiple NFTs at once as well (think of this as an extended version of [Primitives](../../3-react-to-events/2-primitive-catalogue/1-introduction.md)
+**Solution**: instead of bridging NFTs, we instead encourage users to _project_ their NFT directly into the game, allowing them to access their asset in-game without having to bridge it to the game chain. Although the main use-case is projecting a single NFT, we support projecting multiple NFTs at once as well (think of this as an extended version of [Primitives](../../300-react-to-events/2-primitive-catalogue/1-introduction.md)
 
 **No free lunch**: note that using this solution means that running the game requires synchronizing multiple blockchains, as you need to run both the chain the game is hosted on, as well as the game where the NFTs are stored. This only requires checking the state of a single contract though.
 

docs/home/700-multichain-support/1-projected-nfts/3-same-L1.mdx

@@ -0,0 +1,2 @@
+# Same L1
+