ci: Manual fixes in documentation, fixing links. Add some closing ) (#…

…547)

packages/contracts/docs/developer-portal/01-how-it-works/01-core/01-dao/index.md

@@ -32,7 +32,7 @@ In the future, more advanced asset management and finance functionality can be a
 
 ### 3. Upgradeability
 
-Your DAO contract has the ability to be upgraded to a newer version (see [Upgrade your DAO](../../../02-how-to-guides/01-dao/03-protocol-upgrades.md) if a new version of Aragon OSx is released in the future. These upgrades allow your DAO to smoothly transition to a new protocol version unlocking new features.
+Your DAO contract has the ability to be upgraded to a newer version (see [Upgrade your DAO](../../../02-how-to-guides/01-dao/03-protocol-upgrades.md)) if a new version of Aragon OSx is released in the future. These upgrades allow your DAO to smoothly transition to a new protocol version unlocking new features.
 
 <!-- Add a subsection explaining how to upgrade your dao -->
 

packages/contracts/docs/developer-portal/01-how-it-works/02-framework/01-dao-creation/index.md

@@ -28,9 +28,9 @@ The `DAOFactory` create the `DAO` in four steps and interacts with the `DAORegis
 
 2. Registers the new contract in the [`DAORegistry`](#daoregistry).
 
-3. Installs the plugins using the `PluginSetupProcessor` (see also the section about [the plugin setup process](../02-plugin-management/02-plugin-setup/index.md).
+3. Installs the plugins using the `PluginSetupProcessor` (see also the section about [the plugin setup process](../02-plugin-management/02-plugin-setup/index.md)).
 
-4. Sets the [native permissions](../../01-core/02-permissions/index.md/#permissions-native-to-the-dao-contract) of the `DAO` and revokes its own ownership.
+4. Sets the [native permissions](../../01-core/02-permissions/index.md#permissions-native-to-the-dao-contract) of the `DAO` and revokes its own ownership.
 
 For more details visit the [`DAOFactory` reference guide entry](../../../03-reference-guide/framework/dao/DAOFactory.md).
 

packages/contracts/docs/developer-portal/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/01-plugin-repo-creation.md

@@ -39,7 +39,7 @@ function createPluginRepoWithFirstVersion(
 
 It also registers the plugin in the Aragon OSx `PluginRepoRegistry`contract with an [ENS subdomain](../../03-ens-names.md) under the `plugin.dao.eth` domain managed by Aragon.
 
-Additional to the information required by the [`createVersion` function discussed earlier](./index.md/#the-pluginrepo-contract), it receives:
+Additional to the information required by the [`createVersion` function discussed earlier](./index.md#the-pluginrepo-contract), it receives:
 
 - A valid ENS `_subdomain` unique name composed of letters from a-z, all in lower caps, separated by a `-`. For ex: `token-voting-plugin`.
 - The address of the plugin repo maintainer who ends up having the `ROOT_PERMISSION_ID`, `MAINTAINER_PERMISSION_ID`, and `UPGRADE_REPO_PERMISSION_ID` permissions. These permissions enable the maintainer to call the internal `PermissionManager`, the `createVersion` and `updateReleaseMetadata` functions as well as upgrading the plugin contract.

packages/contracts/docs/developer-portal/01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md

@@ -12,7 +12,7 @@ Different versions might contain:
 - new features
 - breaking changes
 
-`PluginRepo` contracts themselves, each associated with a different plugin, are registered in the Aragon OSx [`PluginRepoRegistry`](./01-plugin-repo-creation.md/#the-pluginreporegistry-contract) and carry their own [ENS name](../../03-ens-names.md) that the creator chooses. The [`PluginRepoRegistry` contract](./01-plugin-repo-creation.md/#the-pluginreporegistry-contract) is described in the upcoming subsection.
+`PluginRepo` contracts themselves, each associated with a different plugin, are registered in the Aragon OSx [`PluginRepoRegistry`](./01-plugin-repo-creation.md#the-pluginreporegistry-contract) and carry their own [ENS name](../../03-ens-names.md) that the creator chooses. The [`PluginRepoRegistry` contract](./01-plugin-repo-creation.md#the-pluginreporegistry-contract) is described in the upcoming subsection.
 
 <div class="center-column">
 

packages/contracts/docs/developer-portal/01-how-it-works/02-framework/02-plugin-management/02-plugin-setup/01-security-risk-mitigation.md

@@ -29,7 +29,7 @@ that might be carelessly or intentionally caused, a malicious plugin can hide **
 
 #### Permissions
 
-Examples for elevated permissions, are the [permissions native to the DAO contract](../../../01-core/02-permissions/index.md/#permissions-native-to-the-dao-contract) such as
+Examples for elevated permissions, are the [permissions native to the DAO contract](../../../01-core/02-permissions/index.md#permissions-native-to-the-dao-contract) such as
 
 - `ROOT_PERMISSION_ID`
 - `EXECUTE_PERMISSION_ID`

packages/contracts/docs/developer-portal/01-how-it-works/02-framework/03-ens-names.md

@@ -4,7 +4,7 @@ title: ENS Names
 
 ## Unique DAO and Plugin Repo Names
 
-To make DAOs and plugin repositories easily identifiable in the Aragon OSx ecosystem, we assign unique ENS names to them upon registration during the [DAO creation](./01-dao-creation/index.md/) and [plugin publishing](./02-plugin-management/01-plugin-repo/01-plugin-repo-creation.md) processes.
+To make DAOs and plugin repositories easily identifiable in the Aragon OSx ecosystem, we assign unique ENS names to them upon registration during the [DAO creation](./01-dao-creation/index.md) and [plugin publishing](./02-plugin-management/01-plugin-repo/01-plugin-repo-creation.md) processes.
 
 :::info
 You can skip registering an ENS name for your DAO under the `dao.eth` by leaving the [`DAOSettings.subdomain` field](../../03-reference-guide/framework/dao/DAOFactory.md#public-struct-daosettings) empty when calling the [`createDao`](../../03-reference-guide/framework/dao/DAOFactory.md#external-function-createdao) function.

packages/contracts/docs/developer-portal/02-how-to-guides/01-dao/02-action-execution.md

@@ -54,7 +54,7 @@ function exampleGrantCall(
 }
 ```
 
-Here we use the selector of the [`grant` function](../../03-reference-guide/core/permission/PermissionManager.md/#external-function-grant). To revoke the permission, the selector of the [`revoke` function](../../03-reference-guide/core/permission/PermissionManager.md/#external-function-revoke) must be used.
+Here we use the selector of the [`grant` function](../../03-reference-guide/core/permission/PermissionManager.md#external-function-grant). To revoke the permission, the selector of the [`revoke` function](../../03-reference-guide/core/permission/PermissionManager.md#external-function-revoke) must be used.
 
 If the caller possesses the [`ROOT_PERMISSION_ID` permission](../../01-how-it-works/01-core/02-permissions/index.md#permissions-native-to-the-dao-contract) on the DAO contract, the call becomes simpler and cheaper:
 

packages/contracts/docs/developer-portal/02-how-to-guides/02-plugin-development/06-meta-tx-plugins.md

@@ -7,7 +7,7 @@ title: Meta Transactions
 Our plugins are compatible with the [ERC-2771 (Meta Transaction)](https://eips.ethereum.org/EIPS/eip-2771) standard, which allows users to send gasless transactions, also known as meta transactions.
 This is possible because we use `_msgSender` and `_msgData` context from OpenZeppelin's `Context` and `ContextUpgradeable` in our `Plugin`, `PluginCloneable`, and `PluginUUPSUpgradeable` classes.
 
-To support meta transactions, your implementation contract must inherit and override the `Context` implementation with the `_msgSender` and `_msgData` functions provided in OpenGSN's `BaseRelayRecipient`, and use the [DAO's trusted forwarder](../../01-how-it-works/01-core/01-dao/index.md#6-meta-transaction-compatibility).
+To support meta transactions, your implementation contract must inherit and override the `Context` implementation with the `_msgSender` and `_msgData` functions provided in OpenGSN's `BaseRelayRecipient`, and use the DAO's trusted forwarder.
 
 Below we show for the example of the `TokenVoting` plugin how you can make an existing plugin contract meta-transaction compatible.
 

packages/contracts/docs/developer-portal/02-how-to-guides/02-plugin-development/07-publication/02-metadata.md

@@ -17,11 +17,11 @@ Currently, two kinds of metadata exist:
 
 ### Release Metadata
 
-The release metadata is a `.json` file stored on IPFS with its IPFS CID published for each release in the [PluginRepo](../../../01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md) (see also the section about [versioning](../07-publication/01-versioning.md/#)).
+The release metadata is a `.json` file stored on IPFS with its IPFS CID published for each release in the [PluginRepo](../../../01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md) (see also the section about [versioning](../07-publication/01-versioning.md#)).
 
 The intention is to provide an appealing overview of each releases functionality.
-It can be updated with each call to [`createVersion()`](../../../03-reference-guide/framework/plugin/repo/IPluginRepo.md/#external-function-createversion) in `IPluginRepo` by the repo maintainer.
-It can be replaced at any time with [`updateReleaseMetadata()`](../../../03-reference-guide/framework/plugin/repo/IPluginRepo.md/#external-function-updatereleasemetadata) in `IPluginRepo` by the repo maintainer.
+It can be updated with each call to [`createVersion()`](../../../03-reference-guide/framework/plugin/repo/IPluginRepo.md#external-function-createversion) in `IPluginRepo` by the repo maintainer.
+It can be replaced at any time with [`updateReleaseMetadata()`](../../../03-reference-guide/framework/plugin/repo/IPluginRepo.md#external-function-updatereleasemetadata) in `IPluginRepo` by the repo maintainer.
 
 The `release-metadata.json` file consists of the following entries:
 
@@ -43,10 +43,10 @@ The `release-metadata.json` file consists of the following entries:
 
 ### Build Metadata
 
-The build metadata is a `.json` file stored on IPFS with its IPFS CID published for each build **only once** in the [PluginRepo](../../../01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md) (see also the section about [versioning](../07-publication/01-versioning.md/#)).
+The build metadata is a `.json` file stored on IPFS with its IPFS CID published for each build **only once** in the [PluginRepo](../../../01-how-it-works/02-framework/02-plugin-management/01-plugin-repo/index.md) (see also the section about [versioning](../07-publication/01-versioning.md#)).
 
 The intention is to inform about the changes that were introduced in this build compared to the previous one and give instructions to the App frontend and other users on how to interact with the plugin setup and implementation contract.
-It can be published **only once** with the call to [`createVersion()`](../../../03-reference-guide/framework/plugin/repo/IPluginRepo.md/#external-function-createversion) in `IPluginRepo` by the repo maintainer.
+It can be published **only once** with the call to [`createVersion()`](../../../03-reference-guide/framework/plugin/repo/IPluginRepo.md#external-function-createversion) in `IPluginRepo` by the repo maintainer.
 
 | Key         | Type        | Description                                                                                               |
 | ----------- | ----------- | --------------------------------------------------------------------------------------------------------- |