Reorg tutorials to match nav, and update links

docs/concepts/transactions/finality-of-results/look-up-transaction-results.md

@@ -446,7 +446,7 @@ Most other transactions create a specific type of ledger entry and [adjust the s
     - [Finality of Results](index.md)
     - [Reliable Transaction Submission](../reliable-transaction-submission.md)
 - **Tutorials:**
-    - [Monitor Incoming Payments with WebSocket](../../../tutorials/get-started/monitor-incoming-payments-with-websocket.md)
+    - [Monitor Incoming Payments with WebSocket](../../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
 - **References:**
     - [Ledger Entry Types Reference](../../../references/protocol/ledger-data/ledger-entry-types/index.md) - All possible fields of all types of ledger entries
     - [Transaction Metadata](../../../references/protocol/transactions/metadata.md) - Summary of the metadata format and fields that appear in metadata

docs/concepts/transactions/index.md

@@ -65,7 +65,7 @@ Sending a transaction to the XRP Ledger involves several steps:
 5. The servers apply those transactions to the previous ledger in a canonical order and share their results.
 6. If enough [trusted validators](../networks-and-servers/rippled-server-modes.md#validators) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](../../references/protocol/transactions/transaction-results/transaction-results.md) in that ledger are immutable.
 
-See [Send XRP](../../tutorials/get-started/send-xrp.md) for an interactive tutorial in sending XRP payments.
+See [Send XRP](../../tutorials/tasks/send-xrp.md) for an interactive tutorial in sending XRP payments.
 
 
 ### Example Unsigned Transaction
@@ -207,9 +207,9 @@ Example response from the `tx` command:
     - [Payment Types](../payment-types/index.md)
 - **Tutorials:**
     - [Set Up Secure Signing](secure-signing.md)
-    - [Send XRP](../../tutorials/get-started/send-xrp.md)
+    - [Send XRP](../../tutorials/tasks/send-xrp.md)
     - [Look Up Transaction Results](finality-of-results/look-up-transaction-results.md)
-    - [Monitor Incoming Payments with WebSocket](../../tutorials/get-started/monitor-incoming-payments-with-websocket.md)
+    - [Monitor Incoming Payments with WebSocket](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
     - [Cancel or Skip a Transaction](finality-of-results/canceling-a-transaction.md)
     - [Reliable Transaction Submission](reliable-transaction-submission.md)
 - **References:**

docs/concepts/transactions/reliable-transaction-submission.md

@@ -170,7 +170,7 @@ The difference between the two transaction failure cases (labeled (1) and (2) in
 
         **Tip:** The [`AccountTxnID` field](../../references/protocol/transactions/common-fields.md#accounttxnid) can help prevent redundant transactions from succeeding in this situation.
 
-    - A malicious actor may have used your secret key to send a transaction. If this is the case, [rotate your key pair](../../tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md) if you can, and check for other transactions sent. You should also audit your network to determine if the secret key was part of a larger intrusion or security leak. When you successfully rotate your key pair and are certain that the malicious actor no longer has access to your accounts and systems, you can resume normal activities.
+    - A malicious actor may have used your secret key to send a transaction. If this is the case, [rotate your key pair](../../tutorials/tasks/manage-account-settings/change-or-remove-a-regular-key-pair.md) if you can, and check for other transactions sent. You should also audit your network to determine if the secret key was part of a larger intrusion or security leak. When you successfully rotate your key pair and are certain that the malicious actor no longer has access to your accounts and systems, you can resume normal activities.
 
 
 #### Ledger Gaps

docs/concepts/transactions/secure-signing.md

@@ -47,7 +47,7 @@ In this configuration, you run `rippled` on the machine that generates the trans
 
     The [example config file](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073) listens for connections on the local loopback network (127.0.0.1), with JSON-RPC (HTTP) on port 5005 and WebSocket (WS) on port 6006, and treats all connected clients as admin.
 
-    **Caution:** Using the [commandline API](../../references/http-websocket-apis/api-conventions/request-formatting.md#commandline-format) for signatures is less secure than [using the Websocket or JSON-RPC APIs](../../tutorials/get-started/get-started-using-http-websocket-apis.md) through non-commandline clients. When using the commandline syntax, your secret key may be visible to other users in the system's process listing, and your shell history may save the key in plain text.
+    **Caution:** Using the [commandline API](../../references/http-websocket-apis/api-conventions/request-formatting.md#commandline-format) for signatures is less secure than [using the Websocket or JSON-RPC APIs](../../tutorials/http-websocket-apis/get-started.md) through non-commandline clients. When using the commandline syntax, your secret key may be visible to other users in the system's process listing, and your shell history may save the key in plain text.
 
 3. Maintain the server to keep it running, updated, and in sync with the network while you're using it.
 
@@ -140,7 +140,7 @@ To use this configuration, follow the steps for [running `rippled` on a private
     - [Multi-Signing](../accounts/multi-signing.md)
 - **Tutorials:**
     - [Install rippled](../../infrastructure/installation/index.md)
-    - [Assign a Regular Key Pair](../../tutorials/manage-account-settings/assign-a-regular-key-pair.md)
+    - [Assign a Regular Key Pair](../../tutorials/tasks/manage-account-settings/assign-a-regular-key-pair.md)
     - [Reliable Transaction Submission](reliable-transaction-submission.md)
     - [Enable Public Signing](../../infrastructure/configuration/enable-public-signing.md)
 - **References:**

docs/concepts/transactions/source-and-destination-tags.md

@@ -42,12 +42,12 @@ Assigning tags in numerical order provides less privacy to customers. Since all
 
 ## Requiring Tags
 
-For an XRP Ledger address that may receive payments intended for several customer accounts, receiving a payment _without_ a destination tag can be a problem: it is not immediately obvious which customer to credit, which can require a manual intervention and a discussion with the sender to figure out who was the intended recipient. To reduce cases like this, you can [enable the `RequireDest` setting](../../tutorials/manage-account-settings/require-destination-tags.md). That way, if a user forgets to include a destination tag in a payment, the XRP Ledger rejects their payment instead of giving you money you don't know what to do with. The user can then send the payment again, using the tag as they should have.
+For an XRP Ledger address that may receive payments intended for several customer accounts, receiving a payment _without_ a destination tag can be a problem: it is not immediately obvious which customer to credit, which can require a manual intervention and a discussion with the sender to figure out who was the intended recipient. To reduce cases like this, you can [enable the `RequireDest` setting](../../tutorials/tasks/manage-account-settings/require-destination-tags.md). That way, if a user forgets to include a destination tag in a payment, the XRP Ledger rejects their payment instead of giving you money you don't know what to do with. The user can then send the payment again, using the tag as they should have.
 
 
 ## See Also
 
-- [Require Destination Tags](../../tutorials/manage-account-settings/require-destination-tags.md)
+- [Require Destination Tags](../../tutorials/tasks/manage-account-settings/require-destination-tags.md)
 - [Payment Types](../payment-types/index.md)
 
 {% raw-partial file="/docs/_snippets/common-links.md" /%}

docs/concepts/transactions/transaction-cost.md

@@ -53,7 +53,7 @@ This divides transactions into roughly three categories:
 
 ## Local Load Cost
 
-Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](../../tutorials/get-started/get-started-using-http-websocket-apis.md), the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive [the consensus process](../consensus-protocol/index.md) unless its `Fee` value meets the requirements of a majority of servers.
+Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](../../tutorials/http-websocket-apis/get-started.md), the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive [the consensus process](../consensus-protocol/index.md) unless its `Fee` value meets the requirements of a majority of servers.
 
 ## Open Ledger Cost