More navbar updates

docs/developer-docs/integrations/ledger/introduction_and_overview.md

@@ -1,6 +1,4 @@
-# Introduction and overview
-
-## Overview
+# Overview
 Ledgers are used to record transactions in a chain of blocks. One block references its parent block forming a blockchain that is immutable without changing all previous blocks in the chain. 
 The Internet Computer Protocol utilizes two different types of ledgers. The first ledger is the ICP ledger. It is part of the [NNS](/tokenomics/nns/nns-intro.md) and the canister that implements
 the ICP ledger is running on the NNS subnet. The second type of ledger are the ICRC-1 ledgers. In this overview, both ledger types

docs/developer-docs/production/canister-history.md

@@ -1,4 +1,4 @@
-# Canister history
+# History
 
 ## Overview
 

docs/developer-docs/production/canister-recovery.md

@@ -1,4 +1,4 @@
-# Canister recovery
+# Recovery
 
 ## Overview
 

docs/developer-docs/production/deploying-and-upgrading.md

@@ -1,4 +1,4 @@
-# Deploying and upgrading canisters
+# Development lifecycle
 
 ## Overview
 

docs/developer-docs/production/storage.md

@@ -1,4 +1,4 @@
-# Canister storage
+# Storage
 
 ## Overview
 

docs/developer-docs/setup/build.md

@@ -0,0 +1,19 @@
+# Build
+
+After you have written source code for your project, you need to compile it into a WebAssembly module before deploying it as a canister.
+
+If you are only compiling your project for local debugging, you can generate a locally-defined identifier for your project.
+
+To generate a locally-defined identifier:
+
+- #### Step 1:  Create a project with the configuration settings and program logic to suit your needs.
+
+- #### Step 2:  Start the local canister execution environment, if necessary.
+
+    If you were compiling canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
+
+- #### Step 3:  Generate hard-coded local identifiers for the canisters defined in the `dfx.json` by running the following command:
+
+        dfx build --check
+
+    Note that you must register unique canister identifiers to replace your locally-defined identifier before you can deploy the project on ICP blockchain.

docs/developer-docs/setup/delete.md

@@ -0,0 +1,33 @@
+# Delete
+
+If you want to permanently delete a specific canister or all canisters for a specific project on a given deployment (either local, or remote), you can do so by running the command:
+
+```
+dfx canister delete <canister-name>
+```
+
+Deleting a canister removes the canister identifier, code, and state. Before you can delete a canister, however, you must first stop the canister to clear any pending message requests or replies.
+
+## Delete all canisters
+
+To delete all canisters for a project:
+
+- #### Step 1:  Open a new terminal and navigate to your project directory.
+
+- #### Step 2:  Start the local canister execution environment, if necessary.
+
+    In most cases, this step is only necessary if you are running the canisters locally.
+
+    If you were deleting canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
+
+- #### Step 3:  Check the status of the project canisters running on the local canister execution environment by running the following command:
+
+        dfx canister status --all
+
+- #### Step 4:  Stop all of the project canisters by running the following command:
+
+        dfx canister stop --all
+
+- #### Step 5:  Delete all of the project canisters by running the following command:
+
+        dfx canister delete --all

docs/developer-docs/setup/deploy.md

@@ -0,0 +1,21 @@
+# Deploy
+
+After you have compiled a program, you can install the compiled code in a canister running either on a local canister execution environment or on ICP blockchain.
+
+The canister identifier that was created in advance or during the build process determines where your code is installed during deployment.
+
+To deploy the code for the first time:
+
+- #### Step 1:  Open a new terminal and navigate to your project directory.
+
+- #### Step 2:  Start the local canister execution environment, if necessary.
+
+    In most cases, this step is only necessary if you are running the canisters locally.
+
+    If you were registering canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
+
+- #### Step 3:  Verify you have canister identifiers for all of the canisters you want to deploy.
+
+- #### Step 4:  Deploy all of the canisters by running the following command:
+
+        dfx canister install --all

docs/developer-docs/setup/manage-canisters.md

@@ -1,4 +1,4 @@
-# Interacting with canisters
+# Settings
 
 ## Overview
 
@@ -40,48 +40,6 @@ To obtain a unique identifier for a canister:
 
     The command creates the `.dfx/local` directory and adds the `canister_ids.json` file to that directory for the project.
 
-## Build a canister with a local identifier
-
-After you have written source code for your project, you need to compile it into a WebAssembly module before deploying it as a canister.
-
-If you are only compiling your project for local debugging, you can generate a locally-defined identifier for your project.
-
-To generate a locally-defined identifier:
-
-- #### Step 1:  Create a project with the configuration settings and program logic to suit your needs.
-
-- #### Step 2:  Start the local canister execution environment, if necessary.
-
-    If you were compiling canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
-
-- #### Step 3:  Generate hard-coded local identifiers for the canisters defined in the `dfx.json` by running the following command:
-
-        dfx build --check
-
-    Note that you must register unique canister identifiers to replace your locally-defined identifier before you can deploy the project on ICP blockchain.
-
-## Deploy canisters
-
-After you have compiled a program, you can install the compiled code in a canister running either on a local canister execution environment or on ICP blockchain.
-
-The canister identifier that was created in advance or during the build process determines where your code is installed during deployment.
-
-To deploy the code for the first time:
-
-- #### Step 1:  Open a new terminal and navigate to your project directory.
-
-- #### Step 2:  Start the local canister execution environment, if necessary.
-
-    In most cases, this step is only necessary if you are running the canisters locally.
-
-    If you were registering canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
-
-- #### Step 3:  Verify you have canister identifiers for all of the canisters you want to deploy.
-
-- #### Step 4:  Deploy all of the canisters by running the following command:
-
-        dfx canister install --all
-
 ## Look up a canister ID
 
 All canisters have unique identifiers. You often need to use these identifiers to interact with the canister. For example, if you want to access the frontend canister for a dapp or interact with a service using the Candid web interface, you must specify the appropriate canister identifier.
@@ -178,107 +136,3 @@ To set an identity for a project:
 
         dfx canister call project_backend greet '("Sam")'
 
-## Managing the running state of a canister
-
-After you deploy a canister, it can begin receiving and processing requests from users and from other canisters. Canisters that are available to send requests and receive replies are considered in be in a **Running** state.
-
-Although canisters are normally placed in the Running state by default, there are cases where you might want to temporarily or permanently stop a canister. For example, you might want to stop a canister before upgrading it. Stopping a canister helps to ensure proper handling of any messages that are in progress and need to either run to completion or be rolled back. You might also want to stop a canister to clear its message queue cleanly as a prerequisite to deleting the canister.
-
-You can check the current status of all canisters or a specified canister by running the `dfx canister status` command. For example, to see the status for all canisters running on the local canister execution environment, you would run the following command:
-
-    dfx canister status --all
-
-This command returns output similar to the following if canisters are currently running:
-
-    Canister status_check's status is Running.
-    Canister status_check_assets's status is Running.
-
-You can stop canisters that are currently running by running the `dfx canister stop` command.
-
-    dfx canister stop --all
-
-This command displays output similar to the following:
-
-    Stopping code for canister status_check, with canister_id 75hes-oqbaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q
-    Stopping code for canister status_check_assets, with canister_id cxeji-wacaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q
-
-If you were to rerun the `dfx canister status` command, you might see a status of `Stopped` indicating that there were no pending messages that needed to processed or a status of `Stopping` indicating that there were messages in-flight that needed to be addressed.
-
-To restart a canister-for example, after a successful canister upgrade—you can run the `dfx canister start` command. For example, to restart all of the canisters, you would run the following command:
-
-    dfx canister start --all
-
-This command displays output similar to the following:
-
-    Starting code for canister status_check, with canister_id 75hes-oqbaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q
-    Starting code for canister status_check_assets, with canister_id cxeji-wacaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q
-
-## Upgrade a canister
-
-Unlike a canister reinstall that preserves the canister identifier but no state, a canister upgrade enables you to preserve the state of a deployed canister, and change the code.
-
-For example, assume you have a dapp that manages professional profiles and social connections. If you want to add a new feature to the dapp, you need to be able to update the canister code without losing any of the previously-stored data. A canister upgrade enables you to update existing canister identifiers with program changes without losing the program state.
-
-To preserve state when you are upgrading a canister written in Motoko, be sure to use the `stable` keyword to identify the variables you want to preserve. For more information about preserving variable state in Motoko, see [stable variables and upgrade methods](/motoko/main/upgrades.md). If you are upgrading a canister written in Rust, you should use `pre_upgrade` and `post_upgrade` functions as illustrated in the [Rust CDK asset storage](https://github.com/dfinity/cdk-rs/blob/master/examples/asset_storage/src/asset_storage_rs/lib.rs) example to ensure data is properly preserved after a canister upgrade.
-
-To upgrade a canister:
-
-- #### Step 1:  Open a new terminal and navigate to your project directory.
-
-- #### Step 2:  Start the local canister execution environment, if necessary.
-
-    In most cases, this step is only necessary if you are running the canisters locally.
-
-    If you were registering canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
-
-- #### Step 3:  Verify you have canister identifiers for all of the canisters you want to upgrade.
-
-    Note that your program must identify the variables for which to maintain state by using the `stable` keyword in the variable declaration.
-
-    For more information about declaring stable variables, see the [**Motoko documentation**](../../motoko/main/stablememory.md).
-
-- #### Step 4:  Upgrade all of the canisters by running the following command:
-
-        dfx canister install --all --mode upgrade
-
-## Delete a canister
-
-If you want to permanently delete a specific canister or all canisters for a specific project on a given deployment (either local, or remote), you can do so by running the command:
-
-```
-dfx canister delete <canister-name>
-```
-
-Deleting a canister removes the canister identifier, code, and state. Before you can delete a canister, however, you must first stop the canister to clear any pending message requests or replies.
-
-## Delete all canisters
-
-To delete all canisters for a project:
-
-- #### Step 1:  Open a new terminal and navigate to your project directory.
-
-- #### Step 2:  Start the local canister execution environment, if necessary.
-
-    In most cases, this step is only necessary if you are running the canisters locally.
-
-    If you were deleting canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
-
-- #### Step 3:  Check the status of the project canisters running on the local canister execution environment by running the following command:
-
-        dfx canister status --all
-
-- #### Step 4:  Stop all of the project canisters by running the following command:
-
-        dfx canister stop --all
-
-- #### Step 5:  Delete all of the project canisters by running the following command:
-
-        dfx canister delete --all
-
-## Resources
-
--   [Building on ICP](../../samples/overview.md) to explore sample dapps.
-
--   [Concepts](../../concepts/what-is-ic.md) to learn about different ICP concepts.  
-
--   [ICP glossary](../../references/glossary.md) to learn the definitions of various terms used within ICP. 

docs/developer-docs/setup/pulling-canister-dependencies.md

@@ -1,4 +1,4 @@
-# Import a canister
+# Import
 
 ## Overview
 

docs/developer-docs/setup/state.md

@@ -0,0 +1,34 @@
+# State
+
+After you deploy a canister, it can begin receiving and processing requests from users and from other canisters. Canisters that are available to send requests and receive replies are considered in be in a **Running** state.
+
+Although canisters are normally placed in the Running state by default, there are cases where you might want to temporarily or permanently stop a canister. For example, you might want to stop a canister before upgrading it. Stopping a canister helps to ensure proper handling of any messages that are in progress and need to either run to completion or be rolled back. You might also want to stop a canister to clear its message queue cleanly as a prerequisite to deleting the canister.
+
+You can check the current status of all canisters or a specified canister by running the `dfx canister status` command. For example, to see the status for all canisters running on the local canister execution environment, you would run the following command:
+
+    dfx canister status --all
+
+This command returns output similar to the following if canisters are currently running:
+
+    Canister status_check's status is Running.
+    Canister status_check_assets's status is Running.
+
+You can stop canisters that are currently running by running the `dfx canister stop` command.
+
+    dfx canister stop --all
+
+This command displays output similar to the following:
+
+    Stopping code for canister status_check, with canister_id 75hes-oqbaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q
+    Stopping code for canister status_check_assets, with canister_id cxeji-wacaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q
+
+If you were to rerun the `dfx canister status` command, you might see a status of `Stopped` indicating that there were no pending messages that needed to processed or a status of `Stopping` indicating that there were messages in-flight that needed to be addressed.
+
+To restart a canister-for example, after a successful canister upgrade—you can run the `dfx canister start` command. For example, to restart all of the canisters, you would run the following command:
+
+    dfx canister start --all
+
+This command displays output similar to the following:
+
+    Starting code for canister status_check, with canister_id 75hes-oqbaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q
+    Starting code for canister status_check_assets, with canister_id cxeji-wacaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q

docs/developer-docs/setup/upgrade.md

@@ -0,0 +1,27 @@
+# Upgrade
+
+Unlike a canister reinstall that preserves the canister identifier but no state, a canister upgrade enables you to preserve the state of a deployed canister, and change the code.
+
+For example, assume you have a dapp that manages professional profiles and social connections. If you want to add a new feature to the dapp, you need to be able to update the canister code without losing any of the previously-stored data. A canister upgrade enables you to update existing canister identifiers with program changes without losing the program state.
+
+To preserve state when you are upgrading a canister written in Motoko, be sure to use the `stable` keyword to identify the variables you want to preserve. For more information about preserving variable state in Motoko, see [stable variables and upgrade methods](/motoko/main/upgrades.md). If you are upgrading a canister written in Rust, you should use `pre_upgrade` and `post_upgrade` functions as illustrated in the [Rust CDK asset storage](https://github.com/dfinity/cdk-rs/blob/master/examples/asset_storage/src/asset_storage_rs/lib.rs) example to ensure data is properly preserved after a canister upgrade.
+
+To upgrade a canister:
+
+- #### Step 1:  Open a new terminal and navigate to your project directory.
+
+- #### Step 2:  Start the local canister execution environment, if necessary.
+
+    In most cases, this step is only necessary if you are running the canisters locally.
+
+    If you were registering canisters to run on a remote execution environment, e.g. ICP blockchain, you would include the `--network` command-line option to perform tasks on the environment specified under this parameter.
+
+- #### Step 3:  Verify you have canister identifiers for all of the canisters you want to upgrade.
+
+    Note that your program must identify the variables for which to maintain state by using the `stable` keyword in the variable declaration.
+
+    For more information about declaring stable variables, see the [**Motoko documentation**](../../motoko/main/stablememory.md).
+
+- #### Step 4:  Upgrade all of the canisters by running the following command:
+
+        dfx canister install --all --mode upgrade

plugins/utils/redirects.js

@@ -198,6 +198,7 @@ const redirects = `
   /docs/current/tutorials/ /docs/current/developer-docs/
   /docs/current/developer-docs/backend/eu-subnets /docs/current/developer-docs/backend/subnet-types
   /docs/current/samples/* /docs/current/samples/overview
+  /docs/current/developer-docs/production/deploying-and-upgrading /docs/current/developer-docs/setup/deploy
   `
   .split(/[\r\n]+/)
   .map((line) => line.trim().replace(/^#.*$/, "").trim())