DOCS: fix links and add cli to sidebar (#2830)

* fix links and add cli to sidebar

README.md

@@ -12,7 +12,7 @@
 [![riot.im](https://img.shields.io/badge/riot.im-JOIN%20CHAT-green.svg)](https://riot.im/app/#/room/#cosmos-sdk:matrix.org)
 
 The Cosmos-SDK is a framework for building blockchain applications in Golang.
-It is being used to build `Gaia`, the first implementation of the [Cosmos Hub](https://cosmos.network/docs/),
+It is being used to build `Gaia`, the first implementation of the Cosmos Hub.
 
 **WARNING**: The SDK has mostly stabilized, but we are still making some
 breaking changes.

docs/.vuepress/config.js

@@ -26,12 +26,13 @@ module.exports = {
         children: [
           "/gaia/installation",
           "/gaia/join-testnet",
-          "/gaia/networks",
+          "/gaia/validators/validator-setup",
           "/gaia/validators/overview",
           "/gaia/validators/security",
           "/gaia/validators/validator-faq",
-          "/gaia/validators/validator-setup",
-          "/gaia/ledger"
+          "/gaia/networks",
+          "/gaia/ledger",
+          "/gaia/gaiacli"
         ]
       },
       {

docs/gaia/join-testnet.md

@@ -17,18 +17,18 @@ These instructions are for setting up a brand new full node from scratch.
 First, initialize the node and create the necessary config files:
 
 ```bash
-gaiad init
+gaiad init --moniker <your_custom_moniker>
 ```
 
 ::: warning Note
-Only ASCII characters are supported for the `--name`. Using Unicode characters will render your node unreachable.
+Only ASCII characters are supported for the `--moniker`. Using Unicode characters will render your node unreachable.
 :::
 
-You can edit this `name` later, in the `~/.gaiad/config/config.toml` file:
+You can edit this `moniker` later, in the `~/.gaiad/config/config.toml` file:
 
 ```toml
 # A custom human readable name for this node
-moniker = "<your_custom_name>"
+moniker = "<your_custom_moniker>"
 ```
 
 You can edit the `~/.gaiad/config/gaiad.toml` file in order to enable the anti spam mechanism and reject incoming transactions with less than a minimum fee:

docs/intro/README.md

@@ -8,11 +8,11 @@ It is based on two major principles:
 
 - **Composability:** Anyone can create a module for the Cosmos-SDK, and integrating the already-built modules is as simple as importing them into your blockchain application.
 
-- **Capabilities:** The SDK is inspired by capabilities-based security, and informed by years of wrestling with blockchain state-machines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos-SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on object-cababilities. In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called keepers that can be passed to other modules to grant a pre-defined set of capabilities. For example, if an instance of module A's keepers is passed to module B, the latter will be able to call a restricted set of module A's functions. The capabilities of each keeper are defined by the module's developer, and it's the developer's job to understand and audit the safety of foreign code from 3rd party modules based on the capabilities they are passing into each third party module. For a deeper look at capabilities, jump to [this section](./capabilities.md).
+- **Capabilities:** The SDK is inspired by capabilities-based security, and informed by years of wrestling with blockchain state-machines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos-SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on object-cababilities. In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called keepers that can be passed to other modules to grant a pre-defined set of capabilities. For example, if an instance of module A's keepers is passed to module B, the latter will be able to call a restricted set of module A's functions. The capabilities of each keeper are defined by the module's developer, and it's the developer's job to understand and audit the safety of foreign code from 3rd party modules based on the capabilities they are passing into each third party module. For a deeper look at capabilities, jump to [this section](./ocap.md).
 
 ## Learn more about the SDK
 
-- [SDK application architecture](./design.md)
+- [SDK application architecture](./sdk-app-architecture.md)
 - [SDK security paradigm: ocap](./ocap.md)
 
 ## Creating a new SDK project