cosmos · samricotta · Jul 26, 2023 · Jul 25, 2023 · Jul 25, 2023 · Jul 26, 2023
diff --git a/docs/develop/advanced-concepts/07-cli.md b/docs/develop/advanced-concepts/07-cli.md
@@ -5,7 +5,7 @@ sidebar_position: 1
 # Command-Line Interface
 
 :::note Synopsis
-This document describes how command-line interface (CLI) works on a high-level, for an [**application**](../high-level-concepts/00-overview-app.md). A separate document for implementing a CLI for a Cosmos SDK [**module**](../../integrate/building-modules/01-intro.md) can be found [here](../../integrate/building-modules/09-module-interfaces.md#cli).
+This document describes how command-line interface (CLI) works on a high-level, for an [**application**](../high-level-concepts/00-overview-app.md). A separate document for implementing a CLI for a Cosmos SDK [**module**](../../integrate/building-modules/00-intro.md) can be found [here](../../integrate/building-modules/09-module-interfaces.md#cli).
 :::
 
 ## Command-Line Interface

diff --git a/docs/develop/high-level-concepts/00-overview-app.md b/docs/develop/high-level-concepts/00-overview-app.md
@@ -148,7 +148,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app.go#L731-L738
 
 ## Modules
 
-[Modules](../../integrate/building-modules/01-intro.md) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](../advanced-concepts/00-baseapp.md) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules).
+[Modules](../../integrate/building-modules/00-intro.md) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested within the state-machine. When a transaction is relayed from the underlying CometBFT engine via the ABCI to the application, it is routed by [`baseapp`](../advanced-concepts/00-baseapp.md) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. **For developers, most of the work involved in building a Cosmos SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application**. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the Cosmos SDK's `x/` folder, which contains already-built modules).
 
 ### Application Module Interface
 

diff --git a/docs/integrate/architecture/adr-038-state-listening.md b/docs/integrate/architecture/adr-038-state-listening.md
@@ -20,7 +20,7 @@ This ADR defines a set of changes to enable listening to state changes of indivi
 
 ## Context
 
-Currently, KVStore data can be remotely accessed through [Queries](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/messages-and-queries.md#queries)
+Currently, KVStore data can be remotely accessed through [Queries](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/02-messages-and-queries.md#queries)
 which proceed either through Tendermint and the ABCI, or through the gRPC server.
 In addition to these request/response queries, it would be beneficial to have a means of listening to state changes as they occur in real time.
 

diff --git a/docs/integrate/architecture/adr-040-storage-and-smt-state-commitments.md b/docs/integrate/architecture/adr-040-storage-and-smt-state-commitments.md
@@ -23,7 +23,7 @@ In the current design, IAVL is used for both data storage and as a Merkle Tree f
 * Each edge traversal requires a DB query.
 * Creating snapshots is [expensive](https://github.com/cosmos/cosmos-sdk/issues/7215#issuecomment-684804950). It takes about 30 seconds to export less than 100 MB of state (as of March 2020).
 * Updates in IAVL may trigger tree reorganization and possible O(log(n)) hashes re-computation, which can become a CPU bottleneck.
-* The node structure is pretty expensive - it contains a standard tree node elements (key, value, left and right element) and additional metadata such as height, version (which is not required by the Cosmos SDK). The entire node is hashed, and that hash is used as the key in the underlying database, [ref](https://github.com/cosmos/iavl/blob/master/docs/node/node.md
+* The node structure is pretty expensive - it contains a standard tree node elements (key, value, left and right element) and additional metadata such as height, version (which is not required by the Cosmos SDK). The entire node is hashed, and that hash is used as the key in the underlying database, [ref](https://github.com/cosmos/iavl/blob/master/docs/node/03-node.md
 ).
 
 Moreover, the IAVL project lacks support and a maintainer and we already see better and well-established alternatives. Instead of optimizing the IAVL, we are looking into other solutions for both storage and state commitments.

diff --git a/docs/integrate/building-modules/01-intro.md → docs/integrate/building-modules/00-intro.md b/docs/integrate/building-modules/01-intro.md → docs/integrate/building-modules/00-intro.md
diff --git a/docs/integrate/building-modules/01-module-manager.md b/docs/integrate/building-modules/01-module-manager.md
@@ -12,7 +12,7 @@ Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-m
 
 ### Pre-requisite Readings
 
-* [Introduction to Cosmos SDK Modules](01-intro.md)
+* [Introduction to Cosmos SDK Modules](00-intro.md)
 
 :::
 

diff --git a/docs/integrate/building-modules/02-messages-and-queries.md b/docs/integrate/building-modules/02-messages-and-queries.md
@@ -12,7 +12,7 @@ sidebar_position: 1
 
 ### Pre-requisite Readings
 
-* [Introduction to Cosmos SDK Modules](01-intro.md)
+* [Introduction to Cosmos SDK Modules](00-intro.md)
 
 :::
 

diff --git a/docs/integrate/building-modules/06-keeper.md b/docs/integrate/building-modules/06-keeper.md
@@ -12,7 +12,7 @@ sidebar_position: 1
 
 ### Pre-requisite Readings
 
-* [Introduction to Cosmos SDK Modules](01-intro.md)
+* [Introduction to Cosmos SDK Modules](00-intro.md)
 
 :::
 

diff --git a/docs/integrate/building-modules/09-module-interfaces.md b/docs/integrate/building-modules/09-module-interfaces.md
@@ -12,7 +12,7 @@ This document details how to build CLI and REST interfaces for a module. Example
 
 ### Pre-requisite Readings
 
-* [Building Modules Intro](01-intro.md)
+* [Building Modules Intro](00-intro.md)
 
 :::
 

diff --git a/docs/integrate/spec/addresses/bech32.md b/docs/integrate/spec/addresses/bech32.md
@@ -18,4 +18,4 @@ While all user facing interfaces to Cosmos software should exposed Bech32 interf
 
 To covert between other binary representation of addresses and keys, it is important to first apply the Amino encoding process before Bech32 encoding.
 
-A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/cometbft/cometbft/blob/main/spec/blockchain/encoding.md) to the byte string payload before Bech32 encoding will sufficient for compatible representation.
+A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/cometbft/cometbft/blob/main/spec/blockchain/05-encoding.md) to the byte string payload before Bech32 encoding will sufficient for compatible representation.
diff --git a/docs/integrate/tooling/01-cosmovisor.md b/docs/integrate/tooling/01-cosmovisor.md
@@ -322,7 +322,7 @@ cosmovisor run start
 
 Update app to the latest version (e.g. v0.45).
 
-Next, we can add a migration - which is defined using `x/upgrade` [upgrade plan](https://github.com/cosmos/cosmos-sdk/blob/main/docs/core/upgrade.md) (you may refer to a past version if you are using an older Cosmos SDK release). In a migration we can do any deterministic state change.
+Next, we can add a migration - which is defined using `x/upgrade` [upgrade plan](https://github.com/cosmos/cosmos-sdk/blob/main/docs/advanced-concepts/13-upgrade.md) (you may refer to a past version if you are using an older Cosmos SDK release). In a migration we can do any deterministic state change.
 
 Build the new version `simd` binary:
 

diff --git a/docs/integrate/tooling/03-autocli.md b/docs/integrate/tooling/03-autocli.md
@@ -13,7 +13,7 @@ This document details how to build CLI and REST interfaces for a module. Example
 
 ## Pre-requisite Readings
 
-* [Building Modules Intro](../building-modules/01-intro.md)
+* [Building Modules Intro](../building-modules/00-intro.md)
 
 :::
 

diff --git a/docusaurus.config.js b/docusaurus.config.js
@@ -73,7 +73,7 @@ const config = {
               label: "Develop",
             },
             {
-              to: "/integrate/building-apps/app-go",
+              to: "/integrate/building-modules/intro",
               position: "left",
               label: "Integrate",
             },

diff --git a/versioned_docs/version-0.45/develop/_category_.json b/versioned_docs/version-0.45/develop/_category_.json
@@ -0,0 +1,5 @@
+{
+    "label": "Develop",
+    "position": 0,
+    "link": null
+}