chore: fixed links and removed versioned-link component

Author: stevedylandev

content/monitor/1.0.x/architecture.mdx

@@ -293,7 +293,7 @@ The architecture includes several resilience mechanisms:
 * ***Retry Logic***: Notification delivery includes configurable retry mechanisms for transient failures
 * ***Graceful Degradation***: Individual component failures don’t cascade to the entire system
 
-For detailed information about RPC logic and network communication, see the [RPC section](/monitor/rpc).
+For detailed information about RPC logic and network communication, see the [RPC section](/monitor/1.0.x/rpc).
 
 ## Configuration Architecture
 
@@ -316,7 +316,7 @@ The system implements comprehensive validation:
 
 
 
-For configuration examples and best practices, see the [Configuration Guidelines](/monitor#configuration-guidelines) section in the user documentation.
+For configuration examples and best practices, see the [Configuration Guidelines](/monitor/1.0.x#configuration-guidelines) section in the user documentation.
 
 
 ## Extensibility Points
@@ -355,8 +355,8 @@ The system implements several security measures:
 
 ## Related Documentation
 
-For detailed information about the project structure, source code organization, and development resources, see the [Project Structure](/monitor/project-structure) guide.
+For detailed information about the project structure, source code organization, and development resources, see the [Project Structure](/monitor/1.0.x/project-structure) guide.
 
-For information about RPC logic and network communication, see the [RPC section](/monitor/rpc).
+For information about RPC logic and network communication, see the [RPC section](/monitor/1.0.x/rpc).
 
-For configuration examples and best practices, see the [Configuration Guidelines](/monitor#configuration-guidelines) section in the user documentation.
+For configuration examples and best practices, see the [Configuration Guidelines](/monitor/1.0.x#configuration-guidelines) section in the user documentation.

content/monitor/1.0.x/contribution.mdx

@@ -200,7 +200,7 @@ RUST_TEST_THREADS=1 cargo test
 * Ensure all tests pass before submitting
 * Maintain or improve code coverage
 
-For detailed testing information, see the [Testing Guide](/monitor/testing).
+For detailed testing information, see the [Testing Guide](/monitor/1.0.x/testing).
 
 ### Commit Message Format
 

content/monitor/1.0.x/index.mdx

@@ -31,7 +31,7 @@ In the rapidly evolving world of blockchain technology, effective monitoring is
 
 
 
-To get started immediately, see [Quickstart](/monitor/quickstart).
+To get started immediately, see [Quickstart](/monitor/1.0.x/quickstart).
 
 
 ## Installation
@@ -658,7 +658,7 @@ A Trigger defines actions to take when monitored conditions are met. Triggers ca
 | `**arguments**` | `Array[String]` | The arguments of the script (optional). |
 | `**timeout_ms**` | `Number` | The timeout of the script is important to avoid infinite loops during the execution. If the script takes longer than the timeout, it will be killed. |
 
-For more information about custom scripts, see [Custom Scripts Section](/monitor/scripts).
+For more information about custom scripts, see [Custom Scripts Section](/monitor/1.0.x/scripts).
 
 
 
@@ -1206,7 +1206,7 @@ You can find the contract specification through Stellar contract explorer tool.
 
 Custom filters allow you to create sophisticated filtering logic for processing monitor matches. These filters act as additional validation layers that determine whether a match should trigger the execution of a trigger or not.
 
-For more information about custom scripts, see [Custom Scripts Section](/monitor/scripts).
+For more information about custom scripts, see [Custom Scripts Section](/monitor/1.0.x/scripts).
 
 
 
@@ -1397,21 +1397,21 @@ Specific Block Mode requires both parameters:
 
 ## Error Handling
 
-The monitor implements a comprehensive error handling system with rich context and tracing capabilities. For detailed information about error handling, see [Error Handling Guide](/monitor/error).
+The monitor implements a comprehensive error handling system with rich context and tracing capabilities. For detailed information about error handling, see [Error Handling Guide](/monitor/1.0.x/error).
 
 ## Important Considerations
 
 ### Performance Considerations
 
 * Monitor performance depends on network congestion and RPC endpoint reliability.
-  * View the [list of RPC calls](/monitor/rpc#list-of-rpc-calls) made by the monitor.
+  * View the [list of RPC calls](/monitor/1.0.x/rpc#list-of-rpc-calls) made by the monitor.
 * The `max_past_blocks` configuration is critical:
   * Calculate as: `(cron_interval_ms/block_time_ms) + confirmation_blocks + 1` (defaults to this calculation if not specified).
   * Example for 1-minute Ethereum cron: `(60000/12000) + 12 + 1 = 18 blocks`.
   * Too low settings may result in missed blocks.
 * Trigger conditions are executed sequentially based on their position in the trigger conditions array. Proper execution also depends on the number of available file descriptors on your system. To ensure optimal performance, it is recommended to increase the limit for open file descriptors to at least 2048 or higher. On Unix-based systems you can check the current limit by running `ulimit -n` and _***temporarily***_ increase it with `ulimit -n 2048`.
 * Since scripts are loaded at startup, any modifications to script files require restarting the monitor to take effect.
-* See performance considerations about custom scripts [here](/monitor/scripts#performance-considerations).
+* See performance considerations about custom scripts [here](/monitor/1.0.x/scripts#performance-considerations).
 
 ### Notification Considerations
 

content/monitor/1.0.x/project-structure.mdx

@@ -203,4 +203,4 @@ The project includes Docker configurations for different environments:
 
 
 
-For detailed information about running the monitor in containers, see the Docker deployment [section](/monitor#docker-installation) in the user documentation.
+For detailed information about running the monitor in containers, see the Docker deployment [section](/monitor/1.0.x#docker-installation) in the user documentation.

content/monitor/1.0.x/quickstart.mdx

@@ -153,7 +153,7 @@ Copy the example environment file and customize it:
 cp .env.example .env
 ```
 
-For detailed configuration options, see [Basic Configuration](/monitor#basic-configuration).
+For detailed configuration options, see [Basic Configuration](/monitor/1.0.x#basic-configuration).
 
 ## Practical Examples
 
@@ -587,13 +587,13 @@ Now that you have OpenZeppelin Monitor running, here are some suggestions for wh
 
 ### Testing and Validation
 
-* [Test your configuration](/monitor#testing-your-configuration) against specific block numbers
+* [Test your configuration](/monitor/1.0.x#testing-your-configuration) against specific block numbers
 * Verify your RPC endpoints are working correctly
 * Test notification channels with small transactions
 
 ### Security and Best Practices
 
-* [Configure secure secret management](/monitor#secret-management) for sensitive data
+* [Configure secure secret management](/monitor/1.0.x#secret-management) for sensitive data
 * Use environment variables or Hashicorp Cloud Vault for credentials
 * Regularly update your RPC endpoints and monitor configurations
 
@@ -606,7 +606,7 @@ Now that you have OpenZeppelin Monitor running, here are some suggestions for wh
 ### Getting Help
 
 * Check the [GitHub Issues](https://github.com/OpenZeppelin/openzeppelin-monitor/issues) for known problems
-* Review the [User Documentation](/monitor) for detailed configuration options
+* Review the [User Documentation](/monitor/1.0.x) for detailed configuration options
 * Join the OpenZeppelin community for support
 
 

content/monitor/1.0.x/scripts.mdx

@@ -434,7 +434,7 @@ This examples script filters EVM transactions based on their block number:
 
 ### Integration
 
-Integrate your custom filter script with the monitor by following the [configuration guidelines](/monitor#trigger-conditions-custom-filters).
+Integrate your custom filter script with the monitor by following the [configuration guidelines](/monitor/1.0.x#trigger-conditions-custom-filters).
 
 
 
@@ -599,7 +599,7 @@ This examples demonstrates how to:
 
 ### Integration
 
-Integrate your custom notification script with the triggers by following the [configuration guidelines](/monitor#custom-script-notifications).
+Integrate your custom notification script with the triggers by following the [configuration guidelines](/monitor/1.0.x#custom-script-notifications).
 
 ## Performance Considerations
 

content/monitor/architecture.mdx

@@ -317,7 +317,7 @@ The architecture includes several resilience mechanisms:
 * ***Retry Logic***: Notification delivery includes configurable retry mechanisms for transient failures
 * ***Graceful Degradation***: Individual component failures don’t cascade to the entire system
 
-For detailed information about RPC logic and network communication, see the [RPC section](rpc).
+For detailed information about RPC logic and network communication, see the [RPC section](/monitor/rpc).
 
 ## Configuration Architecture
 
@@ -379,8 +379,8 @@ The system implements several security measures:
 
 ## Related Documentation
 
-For detailed information about the project structure, source code organization, and development resources, see the [Project Structure](project-structure) guide.
+For detailed information about the project structure, source code organization, and development resources, see the [Project Structure](/monitor/project-structure) guide.
 
-For information about RPC logic and network communication, see the [RPC section](rpc).
+For information about RPC logic and network communication, see the [RPC section](/monitor/rpc).
 
 For configuration examples and best practices, see the [Configuration Guidelines](#configuration-guidelines) section in the user documentation.

content/monitor/contribution.mdx

@@ -232,7 +232,7 @@ RUST_TEST_THREADS=1 cargo test
 * Ensure all tests pass before submitting
 * Maintain or improve code coverage
 
-For detailed testing information, see the [Testing Guide](testing).
+For detailed testing information, see the [Testing Guide](/monitor/testing).
 
 ### Commit Message Format
 

content/monitor/index.mdx

@@ -32,7 +32,7 @@ In the rapidly evolving world of blockchain technology, effective monitoring is
 <Callout>
 
 
-To get started immediately, see [Quickstart](quickstart).
+To get started immediately, see [Quickstart](/monitor/quickstart).
 
 </Callout>
 
@@ -693,7 +693,7 @@ A Trigger defines actions to take when monitored conditions are met. Triggers ca
 | `**arguments**` | `Array[String]` | The arguments of the script (optional). |
 | `**timeout_ms**` | `Number` | The timeout of the script is important to avoid infinite loops during the execution. If the script takes longer than the timeout, it will be killed. |
 
-For more information about custom scripts, see [Custom Scripts Section](scripts).
+For more information about custom scripts, see [Custom Scripts Section](/monitor/scripts).
 
 
 
@@ -1301,7 +1301,7 @@ You can find the contract specification through Stellar contract explorer tool.
 
 Custom filters allow you to create sophisticated filtering logic for processing monitor matches. These filters act as additional validation layers that determine whether a match should trigger the execution of a trigger or not.
 
-For more information about custom scripts, see [Custom Scripts Section](scripts).
+For more information about custom scripts, see [Custom Scripts Section](/monitor/scripts).
 
 
 
@@ -1492,21 +1492,21 @@ Specific Block Mode requires both parameters:
 
 ## Error Handling
 
-The monitor implements a comprehensive error handling system with rich context and tracing capabilities. For detailed information about error handling, see [Error Handling Guide](error).
+The monitor implements a comprehensive error handling system with rich context and tracing capabilities. For detailed information about error handling, see [Error Handling Guide](/monitor/error).
 
 ## Important Considerations
 
 ### Performance Considerations
 
 * Monitor performance depends on network congestion and RPC endpoint reliability.
-  * View the [list of RPC calls](rpc#list-of-rpc-calls) made by the monitor.
+  * View the [list of RPC calls](/monitor/rpc#list-of-rpc-calls) made by the monitor.
 * The `max_past_blocks` configuration is critical:
   * Calculate as: `(cron_interval_ms/block_time_ms) + confirmation_blocks + 1` (defaults to this calculation if not specified).
   * Example for 1-minute Ethereum cron: `(60000/12000) + 12 + 1 = 18 blocks`.
   * Too low settings may result in missed blocks.
 * Trigger conditions are executed sequentially based on their position in the trigger conditions array. Proper execution also depends on the number of available file descriptors on your system. To ensure optimal performance, it is recommended to increase the limit for open file descriptors to at least 2048 or higher. On Unix-based systems you can check the current limit by running `ulimit -n` and _***temporarily***_ increase it with `ulimit -n 2048`.
 * Since scripts are loaded at startup, any modifications to script files require restarting the monitor to take effect.
-* See performance considerations about custom scripts [here](scripts#performance-considerations).
+* See performance considerations about custom scripts [here](/monitor/scripts#performance-considerations).
 
 ### Notification Considerations
 

content/monitor/project-structure.mdx

@@ -205,5 +205,4 @@ The project includes Docker configurations for different environments:
 
 
 
-For detailed information about running the monitor in containers, see the Docker deployment [section](docker-installation) in the user documentation.
-
+For detailed information about running the monitor in containers, see the Docker deployment [section](/monitor#docker-installation) in the user documentation.