rename gui to builder

gui.md → 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:
     <deployment-key-1>:
@@ -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.

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

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,15 +262,15 @@ 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
 
 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: