feat: add missing pages in framework

packages/contracts/docs/modules/ROOT/pages/core/index.adoc

@@ -0,0 +1 @@
+TODO

packages/contracts/docs/modules/ROOT/pages/core/permissions.adoc

@@ -83,11 +83,14 @@ function grant(
 To prevent these functions from being called by any address, they are themselves permissioned via the `auth` modifier and require the caller to have the `ROOT_PERMISSION_ID` permission in order to call them.
 
 
-NOTE: Typically, the `ROOT_PERMISSION_ID` permission is granted only to the `DAO` contract itself. Contracts related to the Aragon infrastructure temporarily require it during the xref:how-it-works/framework/dao-creation/index.adoc[DAO creation] and xref:how-it-works/framework/plugin-management/plugin-setup/index.adoc[plugin setup] processes.
+[NOTE]
+====
+Typically, the `ROOT_PERMISSION_ID` permission is granted only to the `DAO` contract itself. Contracts related to the Aragon infrastructure temporarily require it during the xref:how-it-works/framework/dao-creation/index.adoc[DAO creation] and xref:how-it-works/framework/plugin-management/plugin-setup/index.adoc[plugin setup] processes. 
 
 This means, that these functions can only be called through the DAO’s `execute` function that, in turn, requires the calling address to have the `EXECUTE_PERMISSION_ID` permission.
+====
 
-Typically, the `EXECUTE_PERMISSION_ID` permission is granted to governance contracts (such as a majority voting plugin owned by the DAO or a multi-sig). Accordingly, a proposal is often required to change permissions.
+NOTE: Typically, the `EXECUTE_PERMISSION_ID` permission is granted to governance contracts (such as a majority voting plugin owned by the DAO or a multi-sig). Accordingly, a proposal is often required to change permissions.
 Exceptions are, again, the xref:how-it-works/framework/dao-creation/index.adoc[DAO creation] and xref:how-it-works/framework/plugin-management/plugin-setup/index.adoc[plugin setup] processes.
 
 #### Granting Permission with Conditions

packages/contracts/docs/modules/ROOT/pages/framework/index.adoc

@@ -0,0 +1,16 @@
+
+= Framework 
+== The Infrastructure Running the Aragon OSx Protocol
+
+The Aragon OSx protocol is composed of **framework-related contracts** creating and managing the **core contracts**. This includes the
+
+- xref:how-it-works/core/dao/dao-factory-registry.adoc[Creation of DAOs]and initial plugin configuration.
+- xref:how-it-works/core/dao/plugin-factory-registry.adoc[Creation of plugins] and the versioning of different implementations and respective setup contracts.
+- xref:how-it-works/core/dao/plugin-setup-processor.adoc[Installation of plugins] and setting it up on the DAO.
+- xref:how-it-works/core/dao/ens-registrar.adoc[Assignment of ENS Names] to `Plugin` and `DAO` contracts created through the framework.
+
+An overview of the framework and core contracts of the Aragon OSx protocol and their interactions is shown below:
+
+image::../../../../_/images/optimized-svg/framework/aragon-os-infrastructure-core-overview.drawio.svg[ align="center"]
+
+In the following sections, you will learn more about the framework-related contracts of the Aragon OSx protocol.

packages/contracts/docs/modules/ROOT/pages/framework/plugin-repos.adoc

@@ -0,0 +1,99 @@
+= Plugin Repositories
+
+== Plugins
+
+As mentioned earlier, plugins built by Aragon and third-party developers can be added and removed from your DAO to adapt it to your needs.
+
+The management of these plugins is handled for you by the Aragon OSx protocol so that the process of
+
+- Releasing new plugins as well as
+- Installing, updating, and uninstalling them to your DAO
+
+becomes as streamlined as possible.
+
+In the following, we learn what a plugin consists of.
+
+// <!-- Add subgraphic from the framework overview main graphic-->
+
+### What Does a Plugin Consist Of?
+
+An Aragon OSx Plugin consists of:
+
+* The `PluginSetup` contract
+  ** referencing the `Plugin` implementation internally
+  ** containing the setup instruction to install, update, and uninstall it to an existing DAO
+
+* A metadata URI pointing to a `JSON` file containing the
+  ** AragonApp frontend information
+  ** Information needed for the setup ABI
+
+* A version tag consisting of a
+  ** Release number
+  ** Build number
+
+A detailed explanation of the xref:how-to-guides/plugin-development/index.adoc[build and release versioning] is found in the Guides sections in our developer portal.
+
+.A schematic depiction of a plugin bundle consisting of a version tag, the plugin setup contract pointing to the plugin implementation contract, and a metadata URI.
+image::../../../../_/images/optimized-svg/plugins/plugin-version.drawio.svg[align="center"]
+
+
+The `PluginSetup` is written by you, the plugin developer. The processing of the setup is managed by the `PluginSetupProcessor`, the central component of the setup process in the Aragon OSx framework, which is explained in the section xref:framework/repo-factory-registry.adoc[The Plugin Setup Process].
+
+Each plugin with its different builds and releases is versioned inside its own plugin repositories in a `PluginRepo` contract, which is explained in the next section.
+
+
+== Plugin Repositories
+
+
+## What are Plugin Repositories?
+
+Each plugin has its own Plugin Repository, unique ENS name, and on-chain repository contract, the `PluginRepo`, in which different versions of the plugin are stored for reference using version tags constituted by a **release** and **build** number.
+
+Different versions might contain:
+
+- bug fixes
+- new features
+- breaking changes
+
+`PluginRepo` contracts themselves, each associated with a different plugin, are registered in the Aragon OSx `PluginRepoRegistry` and carry their own xref:framework/ens-names.adoc[ENS name] that the creator chooses. The xref:framework/repo-factory-registry.adoc[`PluginRepoRegistry` contract] is described in the upcoming subsection.
+
+
+.Schematic depiction of the versioning taking place in the PluginRepoRegistry.
+image::../../../../_/images/optimized-svg/plugins/plugin-repo-overview.drawio.svg[align="center"]
+
+Overview of the plugin versioning and registry in the Aragon OSx protocol. The `PluginRepoRegistry` contract, which is a curated list of ENS named `PluginRepo` contracts, is shown on the left. Each `PluginRepo` contract maintains a list of versions of the `PluginSetup` contract (internally referencing the `Plugin` implementation contract) and the associated UI building blocks as a URI, exemplarily shown on the right.
+
+
+### The `PluginRepo` Contract
+
+The `PluginRepo` contract versions the releases of a `Plugin`. The first version of a plugin is always published as release 1 and build 1 (version tag `1.1`).
+When you publish the first plugin version, a new plugin repository is automatically created for you by the Aragon OSx protocol in which you 
+are the maintainer. The creation process is described in the xref:framework/repo-factory-registry.adoc[plugin repo creation process] section.
+
+The `PluginRepo` contract is link:https://eips.ethereum.org/EIPS/eip-1822[UUPS upgradeable], inherits from the xref:core/permissions.adoc[`PermissionManager`] and allows the maintainer of the repository to create new versions with the `createVersion` function:
+
+```solidity title="@aragon/framework/repo/PluginRepo.sol"
+/// @notice Creates a new plugin version as the latest build for an existing release number or the first build for a new release number for the provided `PluginSetup` contract address and metadata.
+/// @param _release The release number.
+/// @param _pluginSetupAddress The address of the plugin setup contract.
+/// @param _buildMetadata The build metadata URI.
+/// @param _releaseMetadata The release metadata URI.
+function createVersion(
+  uint8 _release,
+  address _pluginSetup,
+  bytes calldata _buildMetadata,
+  bytes calldata _releaseMetadata
+) external auth(address(this), MAINTAINER_PERMISSION_ID);
+```
+
+The function receives four input arguments:
+
+1. The `_release` number to create the build for. If the release number exists already (e.g., release `1`), it is registered as the latest build (e.g., `1.3` if the previous build was `1.2`). 
+If it is a new release number, the build number is `1` (e.g., `2.1`).
+2. The address of `PluginSetup` contract internally referencing the implementation contract (to copy, proxy, or clone from it) and taking care of xref:framework/plugin-setup-processor.adoc[installing, updating to, and uninstalling] this specific version.
+3. The `_buildMetadata` URI pointing to a JSON file containing the UI data, setup data, and change description for this specific version.
+4. The `_releaseMetadata` URI pointing to a JSON file containing the plugin name, description, as well as optional data such as images to be shown in the aragonApp frontend.
+
+Other functions present in the contract allow you to query previous versions and to update the release metadata. For more details visit the TODO:CLAUDIA[`PluginRepo` reference guide entry](../../../../03-reference-guide/framework/plugin/repo/PluginRepo.md).
+
+The `PluginRepo` is created for you when you publish the `PluginSetup` contract of your first version to the Aragon OSx protocol, which is explained in the next section: xref:framework/repo-factory-registry.adoc[The Plugin Repo Creation Process].

packages/contracts/docs/modules/ROOT/pages/framework/plugin-setup-processor.adoc

@@ -0,0 +1,91 @@
+= Plugin Setup Processor
+
+== Installing Plugins
+
+## The Smart Contracts Behind Plugins
+
+A DAO can be set up and customized by the **installation, update, and uninstallation** of plugins. Plugins are composed of two key contracts:
+
+- **Plugin contract:** contains the plugin's implementation logic; everything needed to extend the functionality for DAOs.
+- **Plugin Setup contract:** contains the instructions needed to install, update, and uninstall the plugin into the DAO. This is done through granting or revoking permissions, enabling plugins to perform actions within the scope of the DAO.
+
+image::../../../../_/images/img/plugins/what_is_a_plugin.png[Aragon OSx Plugins]
+
+How this works:
+
+- Although a Plugin is composed by the `Plugin` and `PluginSetup` contracts, the Aragon OSx protocol only knows of the `PluginSetup` contract.
+- Since the `PluginSetup` contract is the one containing the plugin installation instructions, it is the one in charge of deploying the Plugin instance. Each plugin instance is specific to that DAO, deployed with its own unique parameters. You can review how to build a `PluginSetup` contract xref:guide-develop-plugin/index.adoc[here].
+- The `PluginSetup` contract then interacts with the Aragon OSx framework's `PluginSetupProcessor` contract, which is in charge of applying the installation, update, or uninstallation of a plugin into a DAO.
+- Publishing a Plugin into the Aragon OSx protocol is done through creating the first version of the plugin's `PluginRepo`. The plugin's `PluginRepo` instance stores all plugin versions. You can read more about that xref:guide-develop-plugin/publishing-plugin.adoc[here].
+- Except for the gas costs required, plugins are completely free to install, unless decided otherwise by the developer.
+
+### How are Plugins installed in DAOs?
+
+The `PluginSetup` processing is **security critical** because the permissions it handles are granted to third-party contracts.
+
+**Safety is our top priority in the design of the whole protocol.** We want to make sure that the DAO members know exactly what permissions are granted to whom before any processing takes place.
+
+This is why we see the installation process in two phases:
+
+1. **Preparation:** Defining the parameters to be set on the new plugin instance and helpers, as well as requesting the permissions needed for it to work properly. The `PluginSetup` contains the setup script where developers can perform any unprivileged operations. These will need a privileged confirmation in the next step.
+2. **Application:** The granting or revoking of the plugin's requested permissions (based on the preparation step above). This is a privileged action performed by Aragon's `PluginSetupProcessor` (you can understand it as the "installer"), so that the plugin becomes effectively installed or uninstalled. It gets executed whenever someone with `ROOT` privileges on the DAO applies it (most likely through a proposal).
+
+The `PluginSetupProcessor` is the Aragon contract in charge of invoking the `prepareInstallation()` function from your plugin's `PluginSetup` contract and use it to prepare the installation and (eventually) apply it once it has been approved by the DAO.
+
+#### What happens during the Plugin Preparation?
+
+The preparation of a `PluginSetup` contract proceeds as follows:
+
+1. A DAO builder selects a plugin to install, uninstall, or update.
+
+2. The DAO builder defines the parameters and settings that he/she wants for their DAO. Depending on the case, the `prepareInstallation`, `prepareUpdate`, or `prepareUninstallation` method in the `PluginSetup` contract is called through the `PluginSetupProcessor` (and creates a unique setup ID).
+
+3. The link:https://github.com/aragon/osx/blob/e24d9fa3bd6d5a4c9f5936c14ccda1fe9886c2b0/packages/contracts/src/framework/plugin/setup/PluginSetup.sol[`PluginSetup`] contract deploys all the contracts and gathers addresses and other input arguments required for the installation/uninstallation/upgrade instructions. This can include:
+
+   * deployment of new contracts
+   * initialization of new storage variables
+   * deprecating/decommissioning outdated (helper) contracts
+   * governance settings or other attributes
+   * ...
+
+   Because the addresses of all associated contracts are now known, a static permission list can be emitted, hashed, and stored on-chain.
+
+4. Once the Plugin installation has been prepared, we use it as the parameter of the `applyInstallation()` action. Once encoded, this action is what must be added to the `Action[]` array of the installation proposal. That way, when the proposal passes, the action becomes executable and the plugin can be installed in the DAO using the parameters defined in the prepare installation process. For a plugin to be installed, it needs to be approved by the governance mechanism (plugin) of the organization, passed as the encoded action of a proposal, and executed by a signer.
+
+TIP: The governance plugin can be a simple majority vote, an optimistic process or an admin governance plugin that does not involve a waiting period. It can be any governance mechanism existing within the DAO which has access to the DAO's `execute` permission.
+
+This gives the DAO members the opportunity to check which permissions the `PluginSetup` contract request before granting/revoking them.
+
+Plugin setup proposals must be carefully examined as they can be a potential security risk if the `PluginSetup` contract comes from an untrusted source. 
+To learn more visit the xref:guide-set-up-dao/keep-dao-safe.adoc[Security] section.
+
+// <!-- TODO: add a costs sections
+// Optionally, the proposer can also request refunds for the gas spent for the preparation of the plugin in the proposal.
+// -->
+
+#### What happens during the Preparation Application?
+
+After this initial preparation transaction, the addresses and permissions related to the plugin become apparent. The members of a governance plugin with permissions can decide if the installation proposal should be accepted or denied.
+
+Once the proposal has passed, the actions specified in the `Action[]` array can get executed and the `applyInstallation()` action is used to complete the installation of the plugin into the DAO.
+
+This is processed as follows:
+
+1. The DAO temporarily grants the `ROOT_PERMISSION_ID` permission to the `PluginSetupProcessor`. This is needed so that the processor can modify the DAO's permissions settings to set up the plugin.
+2. This `Action` calls the `applyInstallation`, `applyUpdate`, or `applyUninstallation` method in the `PluginSetupProcessor`, containing the list of requested permissions as argument. The permissions hash is compared with the stored hash to make sure that no permission was changed.
+   In addition to the above, the update process also upgrades the logic contract to which the proxy points too.
+3. If the hash is valid, the list is processed and `PluginSetupProcessor` conducts the requested sequence of `grant`, `grantWithCondition` and `revoke` calls on the owning DAO.
+   Finally, the `PluginSetupProcessor` asks the DAO to revoke the `ROOT_PERMISSION_ID` permission from itself.
+
+TIP: The two-step setup procedure in Aragon OSx is not limited to the setup of only one plugin — you can **setup multiple plugins at once** by first preparing them in a single proposal and then processing the entire setup sequence in one transaction. This is powerful and allows you to **transform your entire DAO in one proposal**, for example, to install a new governance plugin (e.g., a gasless ZK-vote) and finance plugin (e.g., to stream loans to your members), while uninstalling your old ERC20 token vote in one go.
+
+In the next sections, you will learn about how plugins are curated on Aragon's repository.
+
+.a
+image::../../../../_/images/optimized-svg/plugins/plugin-installation.drawio.svg[Schematic depiction of the plugin installation process.]
+.b
+image::../../../../_/images/optimized-svg/plugins/plugin-update.drawio.svg[Schematic depiction of the plugin update process.]
+.c
+image::../../../../_/images/optimized-svg/plugins/plugin-uninstallation.drawio.svg[Schematic depiction of the plugin uninstallation process.]
+
+Simplified overview of the two-transaction plugin *a.* installation, *b.* update, and *c.* uninstallation process with the involved contracts as rounded rectangles, interactions between them as arrows, and relations as dashed lines. The first and second transaction are distinguished by numbering as well as solid and dotted lines, respectively.