Add "Cancellable by design" principle to documentation; clarify coroutine lifetime management

Author: EdmondDantes

basic.md

@@ -264,32 +264,32 @@ if the **Scheduler** implements a runtime control mechanism similar to `max_exec
 
 Please see [Maximum activity interval](#maximum-activity-interval) for more information.
 
-### Namespace
-
-All functions, classes, and constants defined in this **RFC** are located in the `Async` namespace.
-Extensions for **Scheduler/Reactor** are allowed to extend this namespace with functions and classes,
-provided that they are directly related to concurrency functionality.
-
 ### Cancellable by design
 
-This RFC is based on the principle of **"Cancellable by design"**, which can be described as follows:
+This **RFC** is based on the principle of **"Cancellable by design"**, which can be described as follows:
 
-> By default, coroutines **should be** designed in such a way that their 
+> By default, coroutines **should be** designed in such a way that their
 > cancellation at any moment does not compromise data integrity.
 
 > Coroutines launched without a defined `Scope` or lifetime **must** adhere to the "Cancellable by design" principle.
 
 > If a coroutine’s lifetime needs to be controlled — it **MUST** be done **EXPLICITLY**!
 
-In practice, this means that if a coroutine is created using the expression `spawn <callable>`, 
-the developer treats it as non-critical in terms of data integrity. 
-If the developer needs to manage the coroutine’s lifetime, they will use the expression `spawn with`. 
+In practice, this means that if a coroutine is created using the expression `spawn <callable>`,
+the developer treats it as non-critical in terms of data integrity.
+If the developer needs to manage the coroutine’s lifetime, they will use the expression `spawn with`.
 In other words, the developer must take extra steps to explicitly extend the coroutine's lifetime.
 
-The **Cancellable by design** principle works especially well for server-side applications, 
-but it can conflict with the principles of **structured concurrency**. 
+The **Cancellable by design** principle works especially well for server-side applications,
+but it can conflict with the principles of **structured concurrency**.
 This **RFC** proposes a balance between both approaches.
 
+### Namespace
+
+All functions, classes, and constants defined in this **RFC** are located in the `Async` namespace.
+Extensions for **Scheduler/Reactor** are allowed to extend this namespace with functions and classes,
+provided that they are directly related to concurrency functionality.
+
 ### Coroutine
 
 > A `Coroutine` is an `execution container`, transparent to the code,