refactor: docs path updates

.github/workflows/deploy-docs.yml

@@ -39,9 +39,9 @@ jobs:
           npm install -g npm@8.5.5
           make build-docs
 
-      - name: Deploy 🚀
-        uses: JamesIves/github-pages-deploy-action@v4.4.3
-        with:
-          branch: gh-pages
-          folder: ~/output
-          single-commit: true
+      # - name: Deploy 🚀
+      #   uses: JamesIves/github-pages-deploy-action@v4.4.3
+      #   with:
+      #     branch: gh-pages
+      #     folder: ~/output
+      #     single-commit: true

UPGRADING.md

@@ -498,7 +498,7 @@ This allows you to remove the replace directive `replace github.com/gogo/protobu
 
 Please use the `ghcr.io/cosmos/proto-builder` image (version >= `0.11.5`) for generating protobuf files.
 
-See which buf commit for `cosmos/cosmos-sdk` to pin in your `buf.yaml` file [here](./proto/README.md).
+See which buf commit for `cosmos/cosmos-sdk` to pin in your `buf.yaml` file [here](https://github.com/cosmos/cosmos-sdk/blob/main/proto/README.md).
 
 #### Gogoproto Import Paths
 
@@ -533,7 +533,7 @@ Here are the following replacements that you need to perform on your proto files
 
 Please also check that in your own app's proto files that there are no single-word names for those two proto annotations. If so, then replace them with fully-qualified names, even though those names don't actually resolve to an actual protobuf entity.
 
-For more information, see the [encoding guide](./docs/docs/core/05-encoding.md).
+For more information, see the [encoding guide](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/develop/advanced/05-encoding.md).
 
 ### Transactions
 

docs/.gitignore

@@ -2,7 +2,8 @@
 /node_modules
 
 # Production
-/build
+build
+!docs/build
 
 # Generated files
 .docusaurus
@@ -21,8 +22,9 @@ docs/docs/core/17-autocli.md
 docs/docs/packages/01-depinject.md
 docs/docs/packages/02-collections.md
 docs/docs/packages/03-orm.md
-docs/run-node/04-rosetta.md
-docs/migrations/02-upgrading.md
+docs/user/run-node/04-rosetta.md
+docs/build/migrations/02-upgrading.md
+docs/develop/advanced/17-autocli.md
 
 # Misc
 .DS_Store

docs/architecture/adr-033-protobuf-inter-module-comm.md

@@ -20,7 +20,7 @@ service definitions defined in [ADR 021](./adr-021-protobuf-query-encoding.md) a
 
 ## Context
 
-In the current Cosmos SDK documentation on the [Object-Capability Model](../core/10-ocap.md), it is stated that:
+In the current Cosmos SDK documentation on the [Object-Capability Model](../../develop/advanced/10-ocap.md), it is stated that:
 
 > We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules.
 

docs/architecture/adr-063-core-module-api.md

@@ -90,7 +90,7 @@ slower than more fast moving projects.
 ### Core Services
 
 The following "core services" are defined by the core API. All valid runtime module implementations should provide
-implementations of these services to modules via both [dependency injection](./adr-057-app-wiring-1.md) and
+implementations of these services to modules via both [dependency injection](./adr-057-app-wiring.md) and
 manual wiring. The individual services described below are all bundled in a convenient `appmodule.Service`
 "bundle service" so that for simplicity modules can declare a dependency on a single service.
 

docs/docs/README.md → docs/docs/Introduction.md

@@ -9,19 +9,19 @@ Cosmos SDK is the world’s most popular framework for building application-spec
 
 Read all about the SDK or dive straight into the code with tutorials.
 
-* [**Introductions to the Cosmos SDK**](./intro/00-overview.md) - Learn about all the parts of the Cosmos SDK.
+* [**Introductions to the Cosmos SDK**](develop/intro/00-overview.md) - Learn about all the parts of the Cosmos SDK.
 * [**SDK Tutorials**](https://tutorials.cosmos.network) - Build a complete blockchain application from scratch.
 
 ## Explore the SDK
 
 Get familiar with the SDK and explore its main concepts.
 
-* [**Introduction**](./intro/00-overview.md) - High-level overview of the Cosmos SDK.
-* [**Basics**](./basics/00-app-anatomy.md) - Anatomy of a blockchain, transaction lifecycle, accounts and more.
-* [**Core Concepts**](./core/00-baseapp.md) -  Read about the core concepts like baseapp, the store, or the server.
-* [**Building Modules**](./building-modules/01-intro.md) -  Discover how to build modules for the Cosmos SDK.
-* [**Running a Node**](./run-node/00-keyring.md) - Running and interacting with nodes using the CLI and API.
-* [**Modules**](./modules/README.md) - Explore existing modules to build your application with.
+* [**Introduction**](develop/intro/00-overview.md) - High-level overview of the Cosmos SDK.
+* [**Basics**](develop/beginner/00-app-anatomy.md) - Anatomy of a blockchain, transaction lifecycle, accounts and more.
+* [**Core Concepts**](develop/advanced/00-baseapp.md) -  Read about the core concepts like baseapp, the store, or the server.
+* [**Building Modules**](build/building-modules/01-intro.md) -  Discover how to build modules for the Cosmos SDK.
+* [**Running a Node**](user/run-node/00-keyring.md) - Running and interacting with nodes using the CLI and API.
+* [**Modules**](./build/modules/README.md) - Explore existing modules to build your application with.
 
 ## Explore the Stack
 

docs/docs/building-apps/02-app-mempool.md → docs/docs/build/building-apps/02-app-mempool.md

@@ -15,7 +15,7 @@ Notably it introduces the `PrepareProposal` and `ProcessProposal` steps of ABCI+
 
 :::note Pre-requisite Readings
 
-* [BaseApp](../core/00-baseapp.md)
+* [BaseApp](../../develop/advanced/00-baseapp.md)
 
 :::
 

docs/docs/building-modules/01-intro.md → docs/docs/build/building-modules/01-intro.md

@@ -10,18 +10,18 @@ Modules define most of the logic of Cosmos SDK applications. Developers compose
 
 :::note Pre-requisite Readings
 
-* [Anatomy of a Cosmos SDK application](../basics/00-app-anatomy.md)
-* [Lifecycle of a Cosmos SDK transaction](../basics/01-tx-lifecycle.md)
+* [Anatomy of a Cosmos SDK application](../../develop/beginner/00-app-anatomy.md)
+* [Lifecycle of a Cosmos SDK transaction](../../develop/beginner/01-tx-lifecycle.md)
 
 :::
 
 ## Role of Modules in a Cosmos SDK Application
 
-The Cosmos SDK can be thought of as the Ruby-on-Rails of blockchain development. It comes with a core that provides the basic functionalities every blockchain application needs, like a [boilerplate implementation of the ABCI](../core/00-baseapp.md) to communicate with the underlying consensus engine, a [`multistore`](../core/04-store.md#multistore) to persist state, a [server](../core/03-node.md) to form a full-node and [interfaces](./09-module-interfaces.md) to handle queries.
+The Cosmos SDK can be thought of as the Ruby-on-Rails of blockchain development. It comes with a core that provides the basic functionalities every blockchain application needs, like a [boilerplate implementation of the ABCI](../../develop/advanced/00-baseapp.md) to communicate with the underlying consensus engine, a [`multistore`](../../develop/advanced/04-store.md#multistore) to persist state, a [server](../../develop/advanced/03-node.md) to form a full-node and [interfaces](./09-module-interfaces.md) to handle queries.
 
 On top of this core, the Cosmos SDK enables developers to build modules that implement the business logic of their application. In other words, SDK modules implement the bulk of the logic of applications, while the core does the wiring and enables modules to be composed together. The end goal is to build a robust ecosystem of open-source Cosmos SDK modules, making it increasingly easier to build complex blockchain applications.
 
-Cosmos SDK modules can be seen as little state-machines within the state-machine. They generally define a subset of the state using one or more `KVStore`s in the [main multistore](../core/04-store.md), as well as a subset of [message types](./02-messages-and-queries.md#messages). These messages are routed by one of the main components of Cosmos SDK core, [`BaseApp`](../core/00-baseapp.md), to a module Protobuf [`Msg` service](./03-msg-services.md) that defines them.
+Cosmos SDK modules can be seen as little state-machines within the state-machine. They generally define a subset of the state using one or more `KVStore`s in the [main multistore](../../develop/advanced/04-store.md), as well as a subset of [message types](./02-messages-and-queries.md#messages). These messages are routed by one of the main components of Cosmos SDK core, [`BaseApp`](../../develop/advanced/00-baseapp.md), to a module Protobuf [`Msg` service](./03-msg-services.md) that defines them.
 
 ```text
                                       +
@@ -75,16 +75,16 @@ As a result of this architecture, building a Cosmos SDK application usually revo
 While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them:
 
 * **Composability**: Cosmos SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](./06-keeper.md).
-* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../core/10-ocap.md) of the Cosmos SDK.
+* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../../develop/advanced/10-ocap.md) of the Cosmos SDK.
 * **Capabilities**: Most modules need to read and/or write to the store(s) of other modules. However, in an open-source environment, it is possible for some modules to be malicious. That is why module developers need to carefully think not only about how their module interacts with other modules, but also about how to give access to the module's store(s). The Cosmos SDK takes a capabilities-oriented approach to inter-module security. This means that each store defined by a module is accessed by a `key`, which is held by the module's [`keeper`](./06-keeper.md). This `keeper` defines how to access the store(s) and under what conditions. Access to the module's store(s) is done by passing a reference to the module's `keeper`.
 
 ## Main Components of Cosmos SDK Modules
 
 Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` module will be defined in the `./x/bank` folder). They generally share the same core components:
 
 * A [`keeper`](./06-keeper.md), used to access the module's store(s) and update the state.
-* A [`Msg` service](./02-messages-and-queries.md#messages), used to process messages when they are routed to the module by [`BaseApp`](../core/00-baseapp.md#message-routing) and trigger state-transitions.
-* A [query service](./04-query-services.md), used to process user queries when they are routed to the module by [`BaseApp`](../core/00-baseapp.md#query-routing).
+* A [`Msg` service](./02-messages-and-queries.md#messages), used to process messages when they are routed to the module by [`BaseApp`](../../develop/advanced/00-baseapp.md#message-routing) and trigger state-transitions.
+* A [query service](./04-query-services.md), used to process user queries when they are routed to the module by [`BaseApp`](../../develop/advanced/00-baseapp.md#query-routing).
 * Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module.
 
 In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](./01-module-manager.md).