Merge branch 'main' into tdj/device_app_update

pages/docs/device-app/architecture.mdx

@@ -1,6 +1,5 @@
 import { Cards, Card } from 'nextra/components'
 
-#
-
 This chapter talks about key concept of what a Personnal Security Device (PSD) is and why it is needed, the design of
 such a device, and more specific high-level consideration on the Ledger PSDs: UI, BOLOS and such.
+

pages/docs/device-app/architecture/psd/application-isolation.mdx

@@ -18,7 +18,7 @@ When an application performs a syscall, the Secure Element switches to Superviso
 ## Accessing secrets
 
 The access that applications have to cryptographic secrets managed by the operating system can be configured when
-loading an application onto the device (this is actually [a required metadata for an application to be deployed](../../deliver/requirements/security#derivation-path)).
+loading an application onto the device (this is actually [a required metadata for an application to be deployed](../../develop/requirements/security#derivation-path)).
 Instead of accessing secrets like the device's master seed directly, applications instead have to use syscalls, i.e to
 request the operating system to derive a node from the master seed by providing the operating system with a path to the
 requested node. When the application is loaded, the BIP 32 paths that the application is permitted to derive nodes from

pages/docs/device-app/deliver/deliverables/ui-flow-video.mdx

@@ -61,4 +61,4 @@ If blind signing is implemented:
 - Sign a blind signed transaction while setting is disabled
 - Sign a blind signed transaction while setting is enabled
 
-*Reminder : Blind signed operations must only be accessible behind a setting that must be disabled by default ([see blind signing section](../design#blind-signing))*
+*Reminder : Blind signed operations must only be accessible behind a setting that must be disabled by default ([see blind signing section](../../develop/requirements/security#blind-signing))*

pages/docs/device-app/deliver/maintenance.mdx

@@ -6,7 +6,7 @@ Since Ledger will not update your device app code, you are responsible for all s
 
 Application updates must be submitted alongside:
 - functional tests, and
-- a  [Security Audit](./requirements/security#security-audit)
+- a  [Security Audit](./deliverables/security-audit)
 
 Afterwards you will submit a new form where you can pick and choose the parts of the App that have been updated.
 

pages/docs/device-app/develop.mdx

@@ -7,4 +7,4 @@ the SDK.
 
 Whereas the ["Deliver"](./deliver) chapter was intended to be focused on mandatory subjects with little
 further specification, you should find in this one more detailed information (or links to detailed information) and
-explanations.
+explanations.

pages/docs/device-app/develop/environment.mdx

@@ -40,7 +40,7 @@ It includes the following capabilities:
 
 Ledger provides several workflows to ease the integration of applications into the GitHub CI.
 
-[Some of them are mandatory for an application to be deployed](../deliver/requirements/development#workflows), but
+[Some of them are mandatory for an application to be deployed](./requirements/development#workflows), but
 the others can still be useful.
 
 <Callout type="info">

pages/docs/device-app/develop/faq.mdx

@@ -10,7 +10,7 @@ title: Frequently Asked Questions
 | What is the maximum size of a message that can be sent in a single APDU?  | The length of the data part is 255 bytes and the whole message sent in a single APDU is 260 bytes with the blocks cla, ins, p1, p2 and one extra byte that encodes the length of the data that follows. |
 | The Ledger team can not fork a repo which is already a fork on LedgerHQ *(e.g. ledger-panacea is a clone of ledger-cosmos but LedgerHQ has already a fork of ledger-cosmos)*. | This is a limitation of GitHub and the only solution for this is to break the link between the repository and the upstream one. This is done like in this [tutorial](https://ralphjsmit.com/unfork-github-repo).  |
 | Can I freely choose the CLA in my embedded app as long as it is one byte or is there eanything I need to be aware of? | Apart from not using a few CLAs that are reserved for the SDK, OS, etc, developers are free to choose. For example, `0xB0` is for SDK.  |
-| How can I load an app without Ledger Live on my ledger nano S or S+?  | Here are the links [to the documentation](./develop/quickstart#build--load-an-application). |
+| How can I load an app without Ledger Live on my ledger nano S or S+?  | Here are the links [to the documentation](./quickstart#build--load-an-application). |
 | When I build the application, I have this error message: `No targets specified and no makefile found`. | You need to go down one level in the repo to the app subfolder and then run the `make` command. You must have launched your ledger-app-builder before. |
 | I'm getting the error message `Ledger device: CLA_NOT_SUPPORTED`. | Many reasons could occur this error: the embedded app does not support the functionality you are implementing yet, you opened the wrong embedded app, or the CLA byte is not correctly set.|
 | How do I verify that my product is genuine (in CLI)? | You can check it by connecting your hardware wallet and executing the following commands in this [documentation](https://support.ledger.com/hc/en-us/articles/4404382029329-Check-hardware-integrity?support=true). |

pages/docs/device-app/develop/sdk.mdx

@@ -1,21 +1,21 @@
 import { Cards, Card } from 'nextra/components'
 
 
-<Cards>
+<Cards num={2}>
   <Card
     title="Permissions, derivation path"
-    href="/docs/device-app/sdk/flags"
+    href="/docs/device-app/develop/sdk/flags"
   />
   <Card
     title="Memory constraints"
-    href="/docs/device-app/sdk/memory"
+    href="/docs/device-app/develop/sdk/memory"
   />
   <Card
     title="IO architecture"
-    href="/docs/device-app/sdk/io"
+    href="/docs/device-app/develop/sdk/io"
   />
   <Card
     title="UI guidelines"
-    href="/docs/device-app/sdk/ui"
+    href="/docs/device-app/develop/sdk/ui"
   />
 </Cards>

pages/docs/device-app/develop/sdk/ui/ledger-nano-display.mdx

@@ -1,20 +1,16 @@
 import { Cards, Card } from 'nextra/components'
 
-<Cards num={2}>
+<Cards>
   <Card
     title="Interface"
-    href="/docs/device-app/coding-guidelines/ledger-nano-display/design-requirements"
+    href="/docs/device-app/develop/sdk/ui/ledger-nano-display/design-requirements"
   />
   <Card
     title="Display Management Design"
-    href="/docs/device-app/coding-guidelines/ledger-nano-display/display-management-design"
+    href="/docs/device-app/develop/sdk/ui/ledger-nano-display/display-management-design"
   />
   <Card
     title="Low-level display management"
-    href="/docs/device-app/coding-guidelines/ledger-nano-display/low-level-display-management"
-  />
-  <Card
-    title="Ledger Nano Graphic Library"
-    href="/docs/device-app/coding-guidelines/ledger-nano-display/graphic-lib"
+    href="/docs/device-app/develop/sdk/ui/ledger-nano-display/low-level-display-management"
   />
 </Cards>

pages/docs/device-app/develop/sdk/ui/ledger-nano-display/low-level-display-management.mdx

@@ -49,7 +49,7 @@ See [the sample apps](https://github.com/LedgerHQ/ledger-sample-apps) for exampl
 
 ## BOLOS UX
 
-The BOLOS UX is the implementation of the device-wide user interface; it is a component of the [dashboard application](../../bolos#dashboard). Applications delegate certain jobs to the BOLOS UX in order to retain consistency across all apps for certain UI components, as well as to allow the operating system to override the application's UI when necessary (for example, when locking the screen). The application interfaces with the BOLOS UX using `os_ux(...)`, which is a system call. However, applications don't need to call this function as it is automatically called by the display interaction helpers (the `UX_` macros).
+The BOLOS UX is the implementation of the device-wide user interface; it is a component of the [dashboard application](../../../../architecture/bolos#dashboard). Applications delegate certain jobs to the BOLOS UX in order to retain consistency across all apps for certain UI components, as well as to allow the operating system to override the application's UI when necessary (for example, when locking the screen). The application interfaces with the BOLOS UX using `os_ux(...)`, which is a system call. However, applications don't need to call this function as it is automatically called by the display interaction helpers (the `UX_` macros).
 
 Applications should delegate **Events** like **Button Push Events** to the BOLOS UX (in this case, using `UX_BUTTON_PUSH_EVENT(...)`) instead of handling them directly, in case the BOLOS UX needs to override the application's UI. If the event is consumed by the BOLOS UX (for example, a pressed button while the user is unlocking the screen) then the event is not passed on to the application.
 

pages/docs/device-app/develop/tools.mdx

@@ -33,7 +33,7 @@ high-level graphical interactions. It is widly used to write functional tests co
 Ledgered is a Python package which goal is to be a collection of small, autonomous utilitaries and libraries.
 
 For now, it only contains a tool (`ledger-manifest`) allowing to check `ledger_app.toml` manifest files (which are a
-[requirement](../deliver/requirements/development#manifest) for an application to be deployed).
+[requirement](./requirements/development#manifest) for an application to be deployed).
 
 <Callout type="info">
     Sources and documentation can be found [in the Ledgered repository](https://github.com/ledgerhq/ledgered).

pages/docs/device-app/develop/tutorials.mdx

@@ -7,18 +7,18 @@ need:
 <Cards num={2}>
   <Card
     title="The C app boilerplate"
-    href="/docs/device-app/dev-environment/boilerplate"
+    href="./tutorials/c"
   />
   <Card
     title="The plugin boileplate"
-    href="/docs/device-app/develop/tutorials/plugin/boilerplate-plugin"
+    href="./tutorials/plugin"
   />
   <Card
     title="The Rust app boileplate"
-    href="/docs/device-app/dev-environment/rust"
+    href="./tutorials/rust"
   />
   <Card
     title="Cloning an existing app"
-    href="/docs/device-app/dev-environment/clone"
+    href="./tutorials/clone"
   />
 </Cards>

pages/docs/device-app/develop/tutorials/clone.mdx

@@ -37,7 +37,7 @@ For any other clone type, use the [main Device App process](../quickstart/).
 
 #### Update an existing clone
 
-If your Bitcoin clone was included in the Bitcoin Deice App and you need to update it, please start a [new Device App process](../introduction/).
+If your Bitcoin clone was included in the Bitcoin Deice App and you need to update it, please start a [new Device App process](../../introduction/).
 
 ## A - Using the 44/60 path
 
@@ -68,7 +68,7 @@ Add your chain ID, chain name and Ticker to [network.c](https://github.com/Ledge
 ### 2. Add an icon for Ledger Stax
 
 Add your 64x64px gif icon in the `glyphs` folder following this naming convention: `stax_yourchainid_64px.gif`.
-Use the template provided [here](../deliverables/icons#stax-template).
+Use the template provided [here](../../deliver/deliverables/icons#stax-template).
 
 ### 3. Add your Network to Chainlist.org and SLIP-0044
 
@@ -124,11 +124,11 @@ APPNAME = "WaltonChain"
 
 - Add your 16x16px Nanos , 14x14px Nano S Plus / Nano X and 32x32 Stax gif icons in the `icons` folder following these naming conventions: `nanos_app_chain_yourchainid.gif`, `nanox_app_chain_yourchainid.gif`, `stax_app_chain_yourchainid.gif`
 - Add your 64x64px gif icon in the `icons` folder following this naming convention: `stax_yourchainid_64px.gif`.
-Use the template provided [here](../deliverables/icons#stax-template).
+Use the template provided [here](../../deliver/deliverables/icons).
 
 ### 3. Build the application
 
-To build the clone application, [follow these guidelines](../quickstart/build-load/).
+To build the clone application, [follow these guidelines](../quickstart).
 1. First run the `make` command for the Ethereum App and run `make load`
 2. Run `make clean`
 2. Load the Device App clone with the name of your chain. E.g: `make load CHAIN=tomochain`
@@ -146,4 +146,4 @@ Please get in touch with our team on the [Ledger's Discord server](https://devel
 
 ### Publishing the application
 
-If you want to publish a clone application, follow the process in [Publishing an application](../submission/requirements).
+If you want to publish a clone application, follow the process in [Publishing an application](../../deliver).

pages/docs/device-app/develop/tutorials/plugin.mdx

@@ -43,5 +43,3 @@ Ledger designed and implemented Paraswap, the first Ethereum plugin.
 We will walk through the plugin Boilerplate example, which is a DApp Plugin for Ethereum. This will help you code your plugin.
 
 Remember, the plugin gets called repeatedly by the Ethereum Application and answers with the appropriate message status.
-
-The complete interaction is detailed in the [reference flow](./plugin/flow/).

pages/docs/device-app/develop/tutorials/plugin/boilerplate-plugin.mdx

@@ -18,7 +18,7 @@ cd app-ethereum
 
 ## Build the Ethereum App
 
-You can easily build the Ethereum app by following these [instructions](../../device-app/develop/quickstart).
+You can easily build the Ethereum app by following these [instructions](../../quickstart).
 
 Once you've successfully compiled the Ethereum app you are ready to walk through the Boilerplate plugin example.
 
@@ -37,10 +37,11 @@ git clone --recurse-submodules https://github.com/LedgerHQ/app-plugin-boilerplat
 
 There is no need to build it right now, only after adding tests. For now, in `app-plugin-boilerplate/` there are these folders:
 - `ethereum-plugin-sdk`: This repository contains information shared by the Ethereum app and your plugin, such as structure definitions, utility functions, etc.
-- `icons` and `glyphs` : plugin icons as displayed on the device. We will get to it later, but you can read about it [here](../../device-app/deliverables/icons/#device-icon).
+- `icons` and `glyphs` : plugin icons as displayed on the device. We will get to it later, but you can read about it [here](../../../deliver/deliverables/icons/#device-icon).
 - `src`: the actual source code (in C).
 - `tests`: the test folder (using the Ragger testing framework).
-- `.github/workflows` : the CI workflows which are a requirement to submit your plugin. To have more details you can refer to this [section](../../device-app/quickstart/framework/#ci).
+- `.github/workflows` : the CI workflows which are a requirement to submit your plugin. To have more details you can refer to this [section](../../environment#github-workflows).
+
 
 ## Change the plugin info
 

pages/docs/device-app/develop/tutorials/plugin/selectors.mdx

@@ -59,5 +59,5 @@ typedef enum {
 
 ## handlers
 
-Now we have to implement a handler for each case condition as described in the [reference flow](./flow). They must all have a corresponding `handle_*.c` located in `src/`.
+Now we have to implement a handler for each case condition. They must all have a corresponding `handle_*.c` located in `src/`.
 

pages/docs/device-app/introduction/clones.mdx

@@ -17,11 +17,11 @@ You don't need to follow all the coding guidelines. Only follow the steps below:
 
 |                                                                      | Eth Clones |
 -----------------------------------------------------------------------|:----------:|
-| [Blind Signing](../deliver/requirements/design#blind-signing)        | Depends    |
-| [Icon](../deliver/requirements/deliverables/icons/)                  | **Yes**    |
-| [Documentation](../deliver/requirements/deliverables/documentation/) | Depends    |
-| [Functional Tests](../deliver/requirements/development)              | **Yes**    |
-| [Warranty / Liability acceptance](../deliver/requirements/legal)     | **Yes**    |
+| [Blind Signing](../develop/requirements/security#blind-signing)        | Depends    |
+| [Icon](../deliver/deliverables/icons/)                  | **Yes**    |
+| [Documentation](../deliver/deliverables/documentation/) | Depends    |
+| [Functional Tests](../develop/requirements/development)              | **Yes**    |
+| [Warranty / Liability acceptance](../deliver/deliverables/legal)     | **Yes**    |
 
 
 ### 2. Build & Load and use the Ledger framework

pages/docs/exchange/integration.mdx

@@ -32,7 +32,7 @@ Test end-to-end your integration as much as possible with some tools we provide,
 *: Not needed for BUY.
 
 In the following pages, you will find:
-- [Backend](integration/providers-endpoints): details on the main endpoints needed for the chosen operation, the payload, the signature, and your public/private key.
+- [Backend](integration/providers-backend): details on the main endpoints needed for the chosen operation, the payload, the signature, and your public/private key.
 - [LiveApp](integration/providers-liveapp): details on your LiveApp specifities, such as the deeplink's format, or the use of Exchange SDK instead of the Wallet API.
 - [Test & Submit](integration/providers-test-and-submit): details on how to use the Ledger Live Developer Mode and other tools (coming soon) to test your integration end-to-end, as well as how to submit it. 
 - [[Reference] Advanced Flows](integration/flow): Details on advanced flows and architecture diagrams.

pages/docs/exchange/integration/flow.mdx

@@ -4,7 +4,7 @@ import 'react-medium-image-zoom/dist/styles.css'
 
 # Detailled Technical Flows
 
-For high-level flows, refer to the [flow-breakdown](../flow/flow-breakdown) section.
+For high-level flows, refer to the [flow-breakdown](../flow) section.
 
 ## Swap
 

pages/docs/exchange/integration/providers-liveapp.mdx

@@ -15,7 +15,7 @@ Your LiveApp must:
 
 ## Ledger's exchange SDK
 
-To learn how to create (or embed if already existing) your user interface for the swap/sell/buy/fund, please follow the [Discover documentation](../../../discover).
+To learn how to create (or embed if already existing) your user interface for the swap/sell/buy/fund, please follow the [Discover documentation](../../discover).
 
 Your LiveApp will interact with Ledger Live, through the [ExchangeSDK](https://github.com/LedgerHQ/exchange-sdk), with the corresponding method.
 
@@ -141,4 +141,4 @@ Your [LiveApp manifest](../../../../APIs/wallet-api/appendix/manifest) should co
 
 ## Flow/UX requirements
 
-Please refer to the [Flow Breakdown](../flow/flow-breakdown) section for more information. 
+Please refer to the [Flow Breakdown](../flow) section for more information. 

pages/docs/exchange/integration/providers-test-and-submit.mdx

@@ -29,14 +29,14 @@ After testing your LiveApp and making sure it works with the Exchange App, you s
 <Steps>
 ### Your API
 
-Adapt your API to interact with our Backend, with some specifities. Details in [Backend](providers-endpoints) section.
+Adapt your API to interact with our Backend, with some specifities. Details in [Backend](providers-backend) section.
 
 ### Your LiveApp's Manifest
 
 It's a bit more complex than the regular LiveApp's Manifest of the Discover section. Details in [LiveApp](providers-liveapp) section.
 
 ### Your Public key
 
-Make sure your private key is secured, and send us your public key. Details in [Backend](providers-endpoints) section.
+Make sure your private key is secured, and send us your public key. Details in [Backend](providers-backend) section.
 
 </Steps>