NOISSUE - Fix dev-guide nav order and separate legacy services in sidebar

content/docs/dev-guide/authorization.mdx

@@ -16,7 +16,8 @@ image: /img/mg-preview.png
 <Callout type="warn" title="SpiceDB is gone — authorization now runs through Atom">
   No SpiceDB container exists in `docker-compose.yaml`, and the old per-entity relations/permissions
   schema and REST role management API (`/<entity_type>/<entity_id>/roles`) no longer apply.
-  Authorization is now owned entirely by **Atom** — see [Auth](/dev-guide/services/auth).
+  Authorization is now owned entirely by **Atom** — see [Overview](/dev-guide/entities) for its
+  entity model.
 </Callout>
 
 ## The model

content/docs/dev-guide/dev-tools/authentication.mdx

@@ -190,7 +190,7 @@ In most of the cases, HTTPS, WSS, MQTTS or secure CoAP are secure enough. Howeve
 AUTH=x509 docker-compose -f docker/docker-compose.yml up -d
 ```
 
-Mutual authentication includes client-side certificates. Certificates can be generated using the simple script provided in the [SSL Makefile][ssl-makefile]. In order to create a valid certificate, you need to create Magistrala client using the process described in the [provisioning section][provision]. After that, you need to fetch created client secret. Client secret will be used to create x.509 certificate for the corresponding client. To create a certificate, execute the following commands:
+Mutual authentication includes client-side certificates. Certificates can be generated using the simple script provided in the [SSL Makefile][ssl-makefile]. In order to create a valid certificate, you need to create Magistrala client using the process described in the provisioning section. After that, you need to fetch created client secret. Client secret will be used to create x.509 certificate for the corresponding client. To create a certificate, execute the following commands:
 
 ```bash
 cd docker/ssl
@@ -308,7 +308,6 @@ mosquitto_sub -I <client_name> -u <client_id> -P <client_secret> --cafile docker
 [messaging]: /dev-guide/dev-tools/messaging
 [rf5280]: https://tools.ietf.org/html/rfc5280
 [ssl-makefile]: https://github.com/absmach/magistrala/blob/main/docker/ssl/Makefile
-[provision]: /dev-guide/services/provision
 [openssl]: https://www.openssl.org/
 [vault]: https://www.vaultproject.io/
 [oidc]: https://openid.net/connect/

content/docs/dev-guide/edge.mdx

@@ -42,7 +42,7 @@ Agent can be used to control deployed services as well as to monitor their livel
 
 ## Agent
 
-Agent is service that is used to manage gateways that are connected to Magistrala in cloud. It provides a way to send commands to gateway and receive response via mqtt. There are two types of channels used for **Agent** `data` and `control`. Over the `control` we are sending commands and receiving response from commands. Data collected from sensors connected to gateway are being sent over `data` channel. Agent is able to configure itself provided that [bootstrap server][bootstrap] is running, it will retrieve configuration from bootstrap server provided few arguments - `external_id` and `external_key` see [bootstraping][bootstraping].
+Agent is service that is used to manage gateways that are connected to Magistrala in cloud. It provides a way to send commands to gateway and receive response via mqtt. There are two types of channels used for **Agent** `data` and `control`. Over the `control` we are sending commands and receiving response from commands. Data collected from sensors connected to gateway are being sent over `data` channel. Agent is able to configure itself provided that bootstrap server is running, it will retrieve configuration from bootstrap server provided few arguments - `external_id` and `external_key` see bootstrapping.
 
 Agent service has following features:
 
@@ -54,9 +54,9 @@ Agent service has following features:
 
 ### Run Agent
 
-Before running agent we need to provision a client and DATA and CONTROL channel. Client that will be used as gateway representation and make bootstrap configuration. If using Magistrala UI this is done automatically when adding gateway through UI. Gateway can be provisioned with [`provision`][provision] service.
+Before running agent we need to provision a client and DATA and CONTROL channel. Client that will be used as gateway representation and make bootstrap configuration. If using Magistrala UI this is done automatically when adding gateway through UI. Gateway can be provisioned with `provision` service.
 
-When you provisioned gateway as described in [provision][provision] you can check results
+When you provisioned gateway as described in provision you can check results
 
 ```bash
 curl -s -S -X GET http://magistrala-domain.com:9013/clients/bootstrap/<external_id> -H "Authorization: Client <external_key>" -H 'Content-Type: application/json' |jq
@@ -387,7 +387,7 @@ payload := base64.StdEncoding.EncodeToString(b)
 
 ### Using configure script
 
-There is a `configuration.sh` script in a `scripts` directory that can be used for automatic configuration and start up of remotely deployed `export`. For this to work it is presumed that `magistrala-export` and `scripts/export_start` are placed in executable path on remote device. Additionally this script requires that remote device is provisioned following the steps described for [provision][provision] service.
+There is a `configuration.sh` script in a `scripts` directory that can be used for automatic configuration and start up of remotely deployed `export`. For this to work it is presumed that `magistrala-export` and `scripts/export_start` are placed in executable path on remote device. Additionally this script requires that remote device is provisioned following the steps described for provision service.
 
 To run it first edit script to set parameters
 
@@ -406,7 +406,7 @@ MAGISTRALA_USER_PASSWORD='12345678'
 
 ### Edge deployment
 
-The following are steps that are an example usage of Magistrala components to connect edge with cloud. We will start Magistrala in the cloud with additional services [Bootstrap][bootstrap] and [Provision][provision]. Using [Bootstrap][bootstrap] and [Provision][provision] we will create a configuration for use in gateway deployment. On the gateway we will start services [Agent][agent] and [Export][export] using previously created configuration.
+The following are steps that are an example usage of Magistrala components to connect edge with cloud. We will start Magistrala in the cloud with additional services Bootstrap and Provision. Using Bootstrap and Provision we will create a configuration for use in gateway deployment. On the gateway we will start services [Agent][agent] and [Export][export] using previously created configuration.
 
 ## Services in the cloud
 
@@ -583,9 +583,6 @@ magistrala-mqtt   | {"level":"info","message":"Publish - client ID export-88529f
 [agent]: /dev-guide/edge#agent
 [export]: /dev-guide/edge#export
 [magistrala]: /dev-guide/architecture
-[bootstrap]: /dev-guide/services/bootstrap
-[bootstraping]: /dev-guide/services/bootstrap#bootstrapping
-[provision]: /dev-guide/services/provision
 [edgex-repo]: https://github.com/edgexfoundry/edgex-go
 [conftoml]: https://github.com/absmach/export/blob/master/configs/config.toml
 [docker-compose]: https://github.com/absmach/magistrala/blob/main/docker/docker-compose.yaml

content/docs/dev-guide/extensions/twins.mdx

@@ -21,7 +21,7 @@ Any data producer or data consumer - which we refer to here collectively as data
 
 Although this works well, satisfies the requirements of a wide variety of use cases and corresponds to the intended use of Mainlfux IoT platform, this setup can be insufficient in two important ways. Firstly, different clients, channels, and their connections - i.e. Magistrala representations of different data agent structures - are unrelated to each other, i.e. they do not form a **meaningful whole** and, as a consequence, they do not represent a **single unified system**. Secondly, the **semantic** aspect, i.e. the **meaning** of different clients and channels is not transparent and defined by the sole use of Magistrala platform entities (channels and clients).
 
-Certainly, we can try to describe clients and channels connections and relations as well as their meaning - i.e. their role, position, function in the overall system - by means of their [metadata][provision]. Although this might work well - with a proviso of a lot of additional effort of writing the relatively complex code to create and parse metadata - it is not a practical approach and we still don't get - at least not out of the box - a readable and useful overview of the system as a whole. Also, this approach does not enable us to answer a simple but very important question, i.e. what was the detailed state of a complete system at a certain moment in time.
+Certainly, we can try to describe clients and channels connections and relations as well as their meaning - i.e. their role, position, function in the overall system - by means of their metadata. Although this might work well - with a proviso of a lot of additional effort of writing the relatively complex code to create and parse metadata - it is not a practical approach and we still don't get - at least not out of the box - a readable and useful overview of the system as a whole. Also, this approach does not enable us to answer a simple but very important question, i.e. what was the detailed state of a complete system at a certain moment in time.
 
 To overcome these problems, Magistrala comes with a **digital twin service**. The twins service is built on top of the Magistrala platform and relies on its architecture and entities, more precisely, on Magistrala users, clients and channels. The primary task of the twin service is to handle Magistrala digital twins. Magistrala digital twin consists of three parts:
 
@@ -39,7 +39,7 @@ You use an HTTP client to communicate with the twins service. Every request sent
 
 Twins service listens to the message broker server and intercepts messages passing _via_ the message broker. Every Magistrala message contains information about subchannel and topic used to send a message. Twins service compares this info with attribute definitions of twins persisted in the database, fetches the corresponding twins and updates their respective states.
 
-Before we dwell into twin's anatomy, it is important to realize that in order to use Magistrala twin service, you have to [provision Magistrala clients and channels][provision] and you have to connect clients and channels beforehand. As you go, you can modify your clients, channels and connections and you can modify your digital twin to reflect these modifications, but you have to have at least a minimal setup in order to use the twin service.
+Before we dwell into twin's anatomy, it is important to realize that in order to use Magistrala twin service, you have to provision Magistrala clients and channels and you have to connect clients and channels beforehand. As you go, you can modify your clients, channels and connections and you can modify your digital twin to reflect these modifications, but you have to have at least a minimal setup in order to use the twin service.
 
 ## Twin's Anatomy
 
@@ -342,7 +342,6 @@ Normally, you can use the default message broker, NATS, wildcards. In order to l
 Since messages published on message broker are republished on any other protocol supported by Magistrala - HTTP, MQTT, CoAP and WS - you can use any supported protocol client to pick up notifications.
 
 [architecture]: /dev-guide/architecture
-[provision]: /dev-guide/services/provision
 [writer]: /dev-guide/dev-tools/storage
 [senml]: https://tools.ietf.org/html/rfc8428#section-4.3
 [authentication]: /dev-guide/dev-tools/authentication

content/docs/dev-guide/meta.json

@@ -2,18 +2,18 @@
   "title": "Dev Guide",
   "pages": [
     "introduction",
-    "agent",
+    "getting-started",
     "architecture",
     "storage-architecture",
-    "getting-started",
     "entities",
     "cli",
     "services",
     "api",
     "authorization",
     "dev-tools",
-    "edge",
     "certs",
+    "agent",
+    "edge",
     "extensions"
   ],
   "defaultOpen": true