Improve docs

docs/monitor.md

@@ -102,10 +102,10 @@ Specify settings for issue management in the `issue_options` variable.
 
 Parameters:
 - `model_id_key`: A key that uniquely identifies each issue, such as an ID column in a database. The configured key references the field in the issues data returned by the `search` and `update` functions that will identify the unique id for the issue.
-- `solvable`: Indicates if an issue can be resolved automatically. Issues set as non-solvable require manual intervention. Defaults to `true`.
+- `solvable`: Indicates if an issue can reach a solved state automatically. Issues set as non-solvable require manual intervention by solving the alert. Defaults to `true`.
 - `unique`: Ensures that only one instance of a given issue (based on the `model_id_key`) is created. Non-solvable issues are often set as unique to avoid duplicate entries. Defaults to `false`.
 
-The `solvable` and `unique` settings can be nuanced to understand, so an example is helpful. Consider a monitor that detects users deactivating their accounts. This state, once detected, is permanent. If an user deactivates their account, it will always be considered a problem (as the monitor is configured to do so). In this case, the issue is **not solvable** since nothing will alter this state for that particular user.
+The `solvable` and `unique` settings can be nuanced to understand, so an example is helpful. Consider a monitor that detects users deactivating their accounts. This state, once detected, is permanent. If a user deactivates their account, it will always be considered a problem (as the monitor is configured to do so). In this case, the issue is **not solvable** since nothing will alter this state for that particular user.
 
 In scenarios like this, the recommended configuration for `solvable` and `unique` settings is as follows:
 - Set `solvable` to `False` because the state of what’s being monitored is final and cannot change, unable to reach a "solved" state.
@@ -114,7 +114,7 @@ In scenarios like this, the recommended configuration for `solvable` and `unique
 > **Note**: This example is solely for illustrating how these settings operate. The problem presented here should not be monitored in this exact way as there're better ways to do it.
 
 ### Example
-Considering the monitor is implemented to monitor user registration data, it's expected that the issues are `solvable`, as the registration data can be corrected. Additionally, the issue is not `unique` because a user may have invalid registration data, fix it, and later have it changed incorrectly again, indicating a new issue must be created.
+Considering the monitor is implemented to monitor user registration data, it's expected that the issues are `solvable`, as the registration data can be corrected and Sentinela can detect when the issue is solved. Additionally, the issue is not `unique` because a user may have invalid registration data, fix it, and later have it changed incorrectly again, indicating a new issue must be created.
 
 ```python
 issue_options = IssueOptions(
@@ -250,11 +250,11 @@ async def update(issues_data: list[IssueDataType]) -> list[IssueDataType] | None
 ```
 
 ## Is solved function
-The **is solved function** is a synchronous function that determines if an issue is resolved based on its data.
+The **is solved function** is a synchronous function that determines if an issue is solved based on its data.
 - The function must be **sync** and takes an active issue data as its argument.
 - It returns `True` if the issue is considered solved and `False` if it is unresolved.
 
-This function not only checks the resolution status of existing issues but also validates issues returned by the **search function**. Issues where `is_solved` returns `True` are discarded, preventing the creation of issues that are already resolved.
+This function not only checks the solved status of existing issues but also validates issues returned by the **search function**. Issues where `is_solved` returns `True` are discarded, preventing the creation of issues that are already solved.
 
 ### Example
 The is solved function should check if the user's `name` is not `None`. If the name is not `None`, the issue is considered solved.

docs/monitor_validating.md

@@ -1,5 +1,5 @@
 # Validating a monitor
-Validating a monitor is a important step before registering it. This process ensures that the monitor code is correct and can be executed by Sentinela. This is useful when using a deployment pipeline to ensure that the monitor is correctly implemented before being deployed.
+Validating a monitor is an important step before registering it. This process ensures that the monitor code is correct and can be executed by Sentinela. This is useful when using a deployment pipeline to ensure that the monitor is correctly implemented before being deployed.
 
 ## Validation Process
 ```

docs/plugins/slack.md

@@ -74,9 +74,9 @@ Parameters:
 - `min_priority_to_mention`: Minimum alert priority that triggers a mention. Mentions will occur if the alert is not acknowledged at the current priority level and it's is greater than or equal to this setting. Defaults to `moderate` (P3).
 - `issue_show_limit`: Maximum number of issues to show in the notification. If the limit is reached, the message `XXX more...` will be shown at the and of the issues list, where `XXX` is the number of issues that are not being shown. Defaults to 10.
 
-The Slack message will show the alert and it's issues information. The notification will persist and will be updated until the alert is solved, even if it's priority falls to P5.
+The Slack message will show the alert and its issues information. The notification will persist and will be updated until the alert is detected as solved, even if its priority falls to P5.
 
-The notification also includes buttons to interact with the alert, allowing it to be acknowledged, locked or solved. The latest is only included if the issues setting was set as **not solvable**.
+The notification also includes buttons to interact with the alert, allowing it to be acknowledged, locked or marked as solved. The last is only included if the issues setting was set as **not solvable**.
 
 ```python
 notification_options = [

docs/sample_monitor.md

@@ -1,5 +1,5 @@
 # Sample monitor
-This documentation explains the processes executed by the Sentinela monitoring platform, focusing on searching for issues, updating their data, and identifying when issues are resolved. The provided [Sample Monitor](../sample_monitors/test_monitor/test_monitor.py) serves as an example implementation to understand these processes.
+This documentation explains the processes executed by the Sentinela monitoring platform, focusing on searching for issues, updating their data, and identifying when issues are solved. The provided [Sample Monitor](../sample_monitors/test_monitor/test_monitor.py) serves as an example implementation to understand these processes.
 
 ## Issue options and issue data type
 Each issue is expected to have two fields:
@@ -18,7 +18,7 @@ Example of returned issues data:
 - `{"id": 23, "value": 3}`
 - `{"id": 34, "value": 1}`
 
-Sentinela filters out issues considered solved. An issue is solved if its `value` meets the resolution criteria (e.g., `value = 1` in this case). Remaining issues data are used to create **Issue** objects, assigned a `model_id` equal to the `id` of each issue data, and stored in the database.
+Sentinela filters out issues considered solved. An issue is considered solved if its `value` meets the resolution criteria (e.g., `value = 1` in this case). Remaining issues data are used to create **Issue** objects, assigned a `model_id` equal to the `id` of each issue data, and stored in the database.
 
 In the example:
 - Issues with data `{"id": 12, "value": 10}` and `{"id": 23, "value": 3}` are created.
@@ -29,23 +29,23 @@ In the example:
 
 Sentinela retrieves the **issues data** for all active issues in the Monitor. This data includes the `id` and `value` fields for each active issue.
 
-The **update** function updates the data accordingly and return it. Sentinela will, then, use this information to update the **Issues**.
+The **update** function updates the data accordingly and returns it. Sentinela will, then, use this information to update the **Issues**.
 
 Example of updates:
 - `{"id": 12, "value": 10}` is updated to `{"id": 12, "value": 4}`
 - `{"id": 23, "value": 3}` is updated to `{"id": 23, "value": 1}`
 
-Sentinela maps the updated **issues data** to their respective **Issue** objects by their `model_id` and the `id` field in the daat. The corresponding Issues are updated in the database with the new `value`.
+Sentinela maps the updated **issues data** to their respective **Issue** objects by their `model_id` and the `id` field in the data. The corresponding Issues are updated in the database with the new `value`.
 
 ## Solve process
 ![Solve process](./images/solve_example.png)
 
 Similar to the update process, Sentinela retrieves **issues data** for all active issues.
 
-The `is_solved` function is executed for each issue data to determine whether it is resolved.
+The `is_solved` function is executed for each issue data to determine whether it is solved.
 
 Example of resolution checks:
 - For `{"id": 12, "value": 4}`, the function returns `False`.
 - For `{"id": 23, "value": 1}`, the function returns `True`.
 
-Any issue considered as solved (i.e., `is_solved` returns `True`) has its status changed to `solved`, and it is no longer considered as active.
+Any issue detected as solved (i.e., `is_solved` returns `True`) has its status changed to `solved`, and it is no longer considered as active.

sample_monitors/test_monitor/test_monitor.py

@@ -67,7 +67,7 @@ def is_solved(issue_data: IssueDataType) -> bool:
 notification_options = [
     SlackNotification(
         channel=os.environ["SAMPLE_SLACK_CHANNEL"],
-        title="Test module",
+        title="Test monitor",
         issues_fields=["id", "value"],
         mention=os.environ["SAMPLE_SLACK_MENTION"],
     )