From dc71e16e26787e17c72d13bfe70cb759cd3f825c Mon Sep 17 00:00:00 2001 From: Arda Nakisci Date: Mon, 23 Feb 2026 15:56:41 +0300 Subject: [PATCH] rename gui to builder --- gui.md => builder.md | 26 +++++++++++++------------- metadata-v1.md | 2 +- ob-yaml.md | 8 ++++---- 3 files changed, 18 insertions(+), 18 deletions(-) rename gui.md => builder.md (90%) diff --git a/gui.md b/builder.md similarity index 90% rename from gui.md rename to builder.md index 75b0892..15ecf99 100644 --- a/gui.md +++ b/builder.md @@ -1,17 +1,17 @@ -# GUI Configuration (`gui`) +# Builder Configuration (`builder`) ## Introduction -The `gui` section within the YAML configuration provides metadata specifically tailored for building user interfaces related to Rainlang strategies. It acts as a bridge between the core technical definition of deployments, tokens, orders, etc., and their presentation to an end-user in a graphical application. +The `builder` section within the YAML configuration provides metadata specifically tailored for building user interfaces related to Rainlang strategies. It acts as a bridge between the core technical definition of deployments, tokens, orders, etc., and their presentation to an end-user in a graphical application. This section dictates how strategy deployments are named, described, and how their configurable parameters (bindings, deposits, token selections) should be rendered as interactive UI elements. It allows for user-friendly labels, descriptions, default values, and predefined options (presets) to simplify the user experience. -## Top-Level `gui` Object +## Top-Level `builder` Object -The root of the GUI configuration is the `gui:` key. It contains general information about the strategy or set of deployments described in the file. +The root of the builder configuration is the `builder:` key. It contains general information about the strategy or set of deployments described in the file. ```yaml -gui: +builder: name: Fixed limit description: Fixed limit order strategy short-description: Buy WETH with USDC on Base. @@ -23,10 +23,10 @@ gui: * `name` * **Required**: Yes - * **Description**: The primary, human-readable name for the overall strategy or configuration presented in the GUI. + * **Description**: The primary, human-readable name for the overall strategy or configuration presented in the builder. * `description` * **Required**: Yes - * **Description**: A more detailed description of the strategy or configuration, intended for display in the GUI. + * **Description**: A more detailed description of the strategy or configuration, intended for display in the builder. * `short-description` * **Required**: No * **Description**: An optional, concise description, potentially used in contexts where space is limited (e.g., list views, tooltips). @@ -36,10 +36,10 @@ gui: ## Deployments Map (`deployments`) -The `deployments` field under `gui` holds a map where each key is the name of a deployment (which must correspond to a deployment defined elsewhere in the configuration, e.g., under the top-level `deployments:` key) and the value is an object defining the GUI configuration specific to that deployment. +The `deployments` field under `builder` holds a map where each key is the name of a deployment (which must correspond to a deployment defined elsewhere in the configuration, e.g., under the top-level `deployments:` key) and the value is an object defining the builder configuration specific to that deployment. ```yaml -gui: +builder: # ... name, description ... deployments: : @@ -54,7 +54,7 @@ gui: Each entry within the `deployments` map defines the specific UI elements and text for a single deployment. ```yaml -gui: +builder: # ... deployments: some-deployment: # This key must match a defined deployment @@ -73,7 +73,7 @@ gui: * `name` * **Required**: Yes - * **Description**: The name of this specific deployment variation as it should appear in the GUI. + * **Description**: The name of this specific deployment variation as it should appear in the builder. * `description` * **Required**: Yes * **Description**: A detailed description for this specific deployment variation. @@ -166,7 +166,7 @@ fields: * **Description**: The name of the binding in the associated Rainlang source code that this field provides the value for. * `name` * **Required**: Yes - * **Description**: The human-readable label displayed for this input field in the GUI. + * **Description**: The human-readable label displayed for this input field in the builder. * `description` * **Required**: No * **Description**: An optional, longer description or help text displayed for this field, potentially as a tooltip or helper text. @@ -227,7 +227,7 @@ select-tokens: * **Description**: The key referencing a token defined in the top-level `tokens` section. * `name` * **Required**: No - * **Description**: An optional override for the token's display name specifically within this selection context. If omitted, the GUI would likely use the `label` or `symbol` from the main token definition. + * **Description**: An optional override for the token's display name specifically within this selection context. If omitted, the builder would likely use the `label` or `symbol` from the main token definition. * `description` * **Required**: No * **Description**: An optional description providing context for why this token is selectable here. diff --git a/metadata-v1.md b/metadata-v1.md index e6c8e4e..ad53240 100644 --- a/metadata-v1.md +++ b/metadata-v1.md @@ -259,7 +259,7 @@ decoding and handling. - Consider some JSON ABIv2 document produced by solc then deflated - A contract meta that references parts of the ABI and provides additional data - that a GUI can use to better describe the contract operation to a human, this + that a builder can use to better describe the contract operation to a human, this meta is encoded with cbor but provided as-is uncompressed The broad structure of the meta document would be diff --git a/ob-yaml.md b/ob-yaml.md index bce1d22..4f3e753 100644 --- a/ob-yaml.md +++ b/ob-yaml.md @@ -164,11 +164,11 @@ At the minimum a token is a network, address and decimals. While ERC20 doesn't m > **Note:** The top-level `tokens` field is optional and may be omitted if no tokens need to be predefined. Orders can reference tokens from other sources, including: > - `using-tokens-from` -> - the GUI’s `select-tokens` field under the top-level `gui` section +> - the builder's `select-tokens` field under the top-level `builder` section > > The top-level `tokens` mapping will be populated automatically by these sources when used. -The GUI MAY query the network rpc + address to attempt to populate the optional fields (notably decimals). Note that the ERC20 specification explicitly DOES NOT mandate that tokens implement the metadata methods, including decimals. If the contract query fails, and the relevant optional field has not been specified in the yaml, this MUST be treated as an error for the user to fix. NEVER assume decimal values that haven't been provided by the contract/user. +The builder MAY query the network rpc + address to attempt to populate the optional fields (notably decimals). Note that the ERC20 specification explicitly DOES NOT mandate that tokens implement the metadata methods, including decimals. If the contract query fails, and the relevant optional field has not been specified in the yaml, this MUST be treated as an error for the user to fix. NEVER assume decimal values that haven't been provided by the contract/user. Required fields: @@ -262,7 +262,7 @@ sentry: false ## Front matter yaml -This yaml is NOT arbitrary across the GUI. It only makes sense when coupled to some specific rainlang, which also makes the most sense when provided as frontmatter that can be directly parsed, composed and bound by the `dotrain` tool. +This yaml is NOT arbitrary across the builder. It only makes sense when coupled to some specific rainlang, which also makes the most sense when provided as frontmatter that can be directly parsed, composed and bound by the `dotrain` tool. ### Front matter orders @@ -270,7 +270,7 @@ Top level element `orders` in the front matter. Used to define a set of named orders that can be deployed onchain using `addOrder` on an orderbook contract. -Requires all the deployment components to be defined already somehow in the GUI as per the above yamls. +Requires all the deployment components to be defined already somehow in the builder as per the above yamls. Network will be taken from inputs/outputs token's network, and they must match as well as `deployer` and `orderbook` if they are specified. Required fields: