Restructure Docs for Sails Integration (#116)

Co-authored-by: AndrePanin <[email protected]>

docs/about/about.mdx

@@ -51,9 +51,9 @@ The primary features of the most popular games include exciting game mechanics t
 
 However, many modern blockchain platforms struggle to meet these fundamental requirements independently. Their applications often demand users to install specialized wallet programs, create accounts, buy in-game currency, and engage in transaction signing, leading to inconveniences. To overcome these issues, these platforms resort to employing centralized components, the malfunction of which can render the entire application inoperative. Such practices are a far cry from achieving true decentralization.
 
-By utilizing [delayed messages](/docs/build/delayed-messages), developers can implement optimizations that may not directly affect the user experience but ultimately yield a positive impact on the application's performance and cost for end users. For instance, in a gaming scenario where certain session data needs storing, employing delayed messages allows for timely clearance of completed data. This prevents excessive growth in program memory and reduces the expense associated with storing information on the blockchain.
+By utilizing [delayed messages](/docs/build/gstd/delayed-messages), developers can implement optimizations that may not directly affect the user experience but ultimately yield a positive impact on the application's performance and cost for end users. For instance, in a gaming scenario where certain session data needs storing, employing delayed messages allows for timely clearance of completed data. This prevents excessive growth in program memory and reduces the expense associated with storing information on the blockchain.
 
-The Gear Protocol provides a developer-friendly [framework](/docs/build/introduction) for creating fully on-chain games and deploying them on a decentralized network, such as Vara. Features like continuous automation (via delayed messages), payless and signless transactions, [gas reservation](/docs/build/gas-reservation), and more serve as essential tools for developers striving to craft successful games within the Vara decentralized network.
+The Gear Protocol provides a developer-friendly [framework](/docs/build/introduction) for creating fully on-chain games and deploying them on a decentralized network, such as Vara. Features like continuous automation (via delayed messages), payless and signless transactions, [gas reservation](/docs/build/gstd/gas-reservation), and more serve as essential tools for developers striving to craft successful games within the Vara decentralized network.
 
 Game creators have realized the benefits of this technology and increasingly use it as one of the essential parts of their game architecture. Since transactions on Vara are very fast and cheap, it fits perfectly for highly loaded gaming applications with a huge number of transactions.
 

docs/about/features/message-automation.md

@@ -11,11 +11,11 @@ One of the well-known drawbacks of other platforms' smart contracts is that they
 
 While classic smart contract logic may rely on users to initiate transactions and awaken the contract, many cases require a trigger when certain conditions are met, such as reaching a specific point in time or the occurrence of a particular event. In the past, this has either limited the capabilities of smart contracts or required developers to introduce a centralized service to trigger smart contracts.
 
-Now thanks to Gear Protocol's support for asynchronous messaging, program developers can implement arbitrary logic with [delayed messages](/build/delayed-messages.md) that can wake the program after a specified period of time or in response to certain events. This enables a much more extensive range of use cases for programs, unlocks new decentralized functionality, and unlocks more value for users in the blockchain ecosystem.
+Now thanks to Gear Protocol's support for asynchronous messaging, program developers can implement arbitrary logic with [delayed messages](/build/gstd/delayed-messages.md) that can wake the program after a specified period of time or in response to certain events. This enables a much more extensive range of use cases for programs, unlocks new decentralized functionality, and unlocks more value for users in the blockchain ecosystem.
 
 ## Continuing messaging automation
 
-The execution of any messages in Vara, including the [system messages](/build/system-signals.md), consumes "gas". The Gear Protocol introduces the concept of [gas reservation](/build/gas-reservation.md), which allows for the creation of gas pools that can be used by programs for further execution. Each pool is unique to the program that creates it, and the gas from the pool can be consumed by the program if its "gas_available" is not sufficient.
+The execution of any messages in Vara, including the [system messages](/build/gstd/system-signals.md), consumes "gas". The Gear Protocol introduces the concept of [gas reservation](/build/gstd/gas-reservation.md), which allows for the creation of gas pools that can be used by programs for further execution. Each pool is unique to the program that creates it, and the gas from the pool can be consumed by the program if its "gas_available" is not sufficient.
 
 One of the key benefits of the gas reservation is the ability to send **delayed messages** that can be triggered automatically at a specific time in the future. These messages, like any other message in Vara, can invoke another program in the network or appear in the user's mailbox.
 
@@ -46,7 +46,7 @@ Overall, the ability to update NFTs dynamically opens up a wide range of possibi
 
 Everyone knows that the most successful games are those that are exciting, that you play with pleasure.
 
-The success of such games depends on the right game mechanics established by the developers. The Gear Protocol offers a tool for developing such games and running them on [Vara](https://vara.network/). Features such as [delayed messages](/build/delayed-messages.md), [gasless and signless transactions](/docs/api/vouchers.md), and [gas reservation](/build/gas-reservation.md) become essential tools for developers aiming to create successful games on the Vara Network.
+The success of such games depends on the right game mechanics established by the developers. The Gear Protocol offers a tool for developing such games and running them on [Vara](https://vara.network/). Features such as [delayed messages](/build/gstd/delayed-messages.md), [gasless and signless transactions](/docs/api/vouchers.md), and [gas reservation](/build/gstd/gas-reservation.md) become essential tools for developers aiming to create successful games on the Vara Network.
 
 Here are a few of the many examples where such functionality would be useful:
 

docs/api/read-state.md

@@ -26,7 +26,7 @@ await api.programState.read(
 );
 ```
 
-2. If using custom functions to query only specific parts of the program state ([see more](/docs/build/metadata#generate-metadata)), call the `api.programState.readUsingWasm` method:
+2. If using custom functions to query only specific parts of the program state ([see more](/docs/build/gstd/metadata#generate-metadata)), call the `api.programState.readUsingWasm` method:
 
 ```javascript
 import { getStateMetadata } from '@gear-js/api';

docs/build/build.mdx

@@ -8,7 +8,13 @@ This Wiki, along with the [Vara Educational Hub](https://vara.network/education-
 
 For a quick overview of writing and running programs on Vara, refer to [this guide](/docs/getting-started-in-5-minutes.md). It walks through writing a program, compiling it to Wasm, and deploying it to the Vara Network within just 5 minutes.
 
-## Gear Protocol's Library
+## Sails Library (High-Level Development)
+
+The [Sails library](./sails) is the recommended starting point for developing applications on the Vara Network. It eliminates the need to write low-level boilerplate code with `gstd`, enabling developers to concentrate on solving business problems.
+
+Additionally, Sails provides developers with automatically generated client code in Rust or TypeScript, making it easier to interface with their deployed Vara applications.
+
+## Gear Library (Low-Level Development)
 
 Messages are the main interface for communications between Actors (users and programs). Each Vara program contains code for processing incoming messages. During message processing, programs can send messages to other programs and users, including replies to the initial message.
 

docs/build/gstd/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "Gear Library (Low-Level)",
+    "position": 3
+}

docs/build/delayed-messages.md → docs/build/gstd/delayed-messages.md

@@ -9,7 +9,7 @@ Smart contracts on other blockchains typically rely on external, centralized res
 
 The external transaction serves as a "poke" to activate the smart contract and initiate its logic. For instance, someone can start an auction by sending a message to the auction contract. When the auction time has passed, the contract will need to process the result of the auction. However, this will not happen until someone sends the appropriate message to the contract to trigger this action.
 
-Gear Protocol solves this issue by introducing delayed messaging functionality. Programs in Vara Network can execute themselves an **unlimited** number of blocks, as long as enough gas for execution is kept available. The [gas reservation](/docs/build/gas-reservation.md) option ensures this. As a result, the need for including centralized components in dApps is eliminated, allowing them to function **totally on-chain**.
+Gear Protocol solves this issue by introducing delayed messaging functionality. Programs in Vara Network can execute themselves an **unlimited** number of blocks, as long as enough gas for execution is kept available. The [gas reservation](/docs/build/gstd/gas-reservation.md) option ensures this. As a result, the need for including centralized components in dApps is eliminated, allowing them to function **totally on-chain**.
 
 The [`msg::send_delayed`](https://docs.gear.rs/gstd/msg/fn.send_delayed.html) function allows sending a message after a specified delay. The function takes the following parameters:
 

docs/build/gas-reservation.md → docs/build/gstd/gas-reservation.md

@@ -8,7 +8,7 @@ Gas reservation is a powerful feature of the Gear Protocol that enables a new ap
 
 Briefly, a program can send a message using gas that was reserved beforehand instead of using gas from the currently processing message.
 
-One of the key advantages of this feature is the ability to send [messages delayed](/docs/build/delayed-messages.md) in time automatically to any actor in the network, whether it is a user, another program, or even **itself**. In fact, a program can execute itself **an unlimited** number of blocks, provided that enough gas for execution is kept available.
+One of the key advantages of this feature is the ability to send [messages delayed](/docs/build/gstd/delayed-messages.md) in time automatically to any actor in the network, whether it is a user, another program, or even **itself**. In fact, a program can execute itself **an unlimited** number of blocks, provided that enough gas for execution is kept available.
 
 A program developer can provide a special function in the program's code that takes a defined amount of gas from the amount available to the program and reserves it. A reservation gets a unique identifier that can be used by the program to retrieve this reserved gas and use it later.
 

docs/build/gstd.md → docs/build/gstd/gstd.md

@@ -2,7 +2,7 @@
 sidebar_position: 3
 ---
 
-# Gear Library
+# Gear Library (Low-Level)
 
 The Gear Protocol’s library `gstd` provides all the necessary and sufficient functions and methods for developing programs.
 

docs/build/system-signals.md → docs/build/gstd/system-signals.md

@@ -13,7 +13,7 @@ First of all, it can be useful to free up resources occupied by the program. A c
 
 In this case, `Futures` remain in memory pages forever. Other messages are not aware of `Futures` associated with other messages. Over time, `Futures` accumulate in the program's memory so eventually a large amount of Futures limits the max amount of space the program can use.
 
-In case a message has been removed from the waitlist due to gas constraints, the system sends a system message (signal) that is baked by an amount of [reserved gas](/build/gas-reservation.md), which informs the program that it’s message was removed from the waitlist. Based on this info, a program can clean up its used system resources (`Futures`).
+In case a message has been removed from the waitlist due to gas constraints, the system sends a system message (signal) that is baked by an amount of [reserved gas](/build/gstd/gas-reservation.md), which informs the program that it’s message was removed from the waitlist. Based on this info, a program can clean up its used system resources (`Futures`).
 
 The `gstd` library provides a separate [`exec::system_reserve_gas`](https://docs.gear.rs/gstd/exec/fn.system_reserve_gas.html) function for reserving gas specifically for system signal messages. It cannot be used for sending other regular cross-actor messages:
 
@@ -27,7 +27,7 @@ If a signal message appears, it uses gas specifically reserved for such kinds of
 
 If gas has been reserved but no system messages occur during the current execution, then this gas returns back from where it was taken. The same relates to gas reserved for non-system messages - gas returns back after a defined number of blocks or by the program’s command.
 
-`handle_signal` has a default implementation if the program has `async init` or/and `async main` functions (see [Asynchronous Programming](/docs/build/async-programing.md) for more details about async entry points). To define a custom signal handler, use the [`gstd::async_init`](https://docs.gear.rs/gstd/attr.async_init.html) or [`gstd::async_main`](https://docs.gear.rs/gstd/attr.async_main.html) macro with the specified `handle_signal` argument. For example:
+`handle_signal` has a default implementation if the program has `async init` or/and `async main` functions (see [Asynchronous Programming](/docs/build/gstd/async-programing.md) for more details about async entry points). To define a custom signal handler, use the [`gstd::async_init`](https://docs.gear.rs/gstd/attr.async_init.html) or [`gstd::async_main`](https://docs.gear.rs/gstd/attr.async_main.html) macro with the specified `handle_signal` argument. For example:
 
 ```rust
 #[gstd::async_main(handle_signal = my_handle_signal)]

docs/build/introduction.md

@@ -73,7 +73,7 @@ The reply message is similar to the ordinary message, but it has some difference
 
 There are a lot of imported functions that can be used by the Vara program. They are called API functions. These functions are provided by the runtime that executes the Gear program. The most convenient way to use these functions is to use the Gear standard library called [`gstd`](https://docs.gear.rs/gstd/). It is a set of high-level functions that are implemented on top of the low-level API functions.
 
-More details about the Gear Protocol's standard library can be found in the [Gear Library](/docs/build/gstd.md) section.
+More details about the Gear Protocol's standard library can be found in the [Gear Library](/docs/build/gstd) section.
 
 ## Basic stages of the Vara program lifecycle
 
@@ -157,7 +157,7 @@ This function is stored in the blockchain in the same Wasm blob with `handle()`
 
 The data returned by the `state()` function can be converted to any convenient representation by using a state-conversion program. This is a separate program compiled into Wasm and dedicated to being executed on the off-chain runner. It should contain a set of meta-functions that accept the data returned by the `state()` function and return the data in a convenient format. There is a dedicated [`read_state_using_wasm`](https://docs.gear.rs/pallet_gear_rpc/trait.GearApiServer.html#tymethod.read_state_using_wasm) RPC call for reading the program state using the state-conversion program.
 
-More details about state functions can be found in the [State Functions](/docs/build/state.md) section.
+More details about state functions can be found in the [State Functions](/docs/build/gstd/state.md) section.
 
 ### Asynchronous programming
 
@@ -183,7 +183,7 @@ async fn init() {
 }
 ```
 
-More details about asynchronous programming can be found in the [Asynchronous Programming](/docs/build/async-programing.md) section.
+More details about asynchronous programming can be found in the [Asynchronous Programming](/docs/build/gstd/async-programing.md) section.
 
 ### Creating programs from programs
 
@@ -193,21 +193,21 @@ The only prerequisite is that the code of the program should be stored in the bl
 
 There are several helper functions for creating programs from programs in the [`gstd::prog`](https://docs.gear.rs/gstd/prog/) module.
 
-More details about creating programs from programs can be found in the [Create Program](/docs/build/create.md) section.
+More details about creating programs from programs can be found in the [Create Program](/docs/build/gstd/create.md) section.
 
 ### Gas reservation
 
 Vara programs use gas for measuring the complexity of the program execution. The user pays a fee for the gas used by the program. Some part of the gas limit may be reserved during the current execution to be spent later. This gas reserving mechanism can be used to shift the burden of paying for program execution from one user to another. Also, it makes it possible to run some deferred actions using delayed messages described below.
 
-You can find more details about gas reservation in the [Gas Reservation](/docs/build/gas-reservation.md) section.
+You can find more details about gas reservation in the [Gas Reservation](/docs/build/gstd/gas-reservation.md) section.
 
 ### Delayed messages
 
 Vara's programs can send messages to other actors during the current execution and after some time. This mechanism can be used to implement deferred actions.
 
 Use functions with `*_delayed` suffix from [`gstd::msg`](https://docs.gear.rs/gstd/msg/index.html) module to send a delayed message to a program or user. The message will be sent after the specified number of blocks.
 
-More details about delayed messages can be found in the [Delayed Messages](./delayed-messages.md) section.
+More details about delayed messages can be found in the [Delayed Messages](/docs/build/gstd/delayed-messages.md) section.
 
 ### System signals
 
@@ -221,12 +221,12 @@ extern "C" fn handle_signal() {
     // Handle system signal here
 }
 ```
-You can find more details about system signals in the [System Signals](./system-signals.md) section.
+You can find more details about system signals in the [System Signals](/docs/build/gstd/system-signals.md) section.
 
 ### Reply deposit
 
 Usually, the reply sender pays a gas fee for the reply message execution. However, sometimes it is more convenient to shift this burden to the program that receives the reply. This can be done by using the reply deposit mechanism.
 
 The reply deposit is a part of the gas limit reserved during the current execution to be spent later. The reserved gas can be used to pay for the reply message execution. To do this, the program should call the [`gstd::exec::reply_deposit`](https://docs.gear.rs/gstd/exec/fn.reply_deposit.html) function. This function provides a gas deposit from the current message to handle the reply message on the given message ID. This message ID should be sent within the execution. Once the destination actor or system sends a reply to it, the gas limit is ignored; if the program provides a deposit, only it will be used for the execution of `handle_reply`.
 
-More details about reply deposit can be found in the [Reply Deposit](/docs/build/reply-deposit.md) section. 
+More details about reply deposit can be found in the [Reply Deposit](/docs/build/gstd/reply-deposit.md) section. 

docs/build/sails/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "Sails Library (High-Level)",
+    "position": 2
+}