Better explanation

TEMPLATES.md

@@ -29,7 +29,7 @@ template-name/
 
 ### 1. config/.template_info.env
 
-Template metadata file that defines the template and its requirements:
+Template metadata file that defines the template and its requirements. This file is managed by the template author and should NOT be modified by users:
 
 ```bash
 # Template identifier - MUST match the directory name
@@ -50,9 +50,11 @@ DATA_VOLUME="${CONTAINER_NAME}_data"
 CONFIG_VOLUME="${CONTAINER_NAME}_config"
 ```
 
+**Important**: This file is replaced when the template is updated. Users should never edit this file.
+
 ### 2. config/service.env
 
-Default service configuration that can be overridden per deployment:
+Default service configuration that **will be modified per installation**. When a user creates a service from this template, they edit this file to customize the deployment:
 
 ```bash
 # Service-specific settings
@@ -66,6 +68,22 @@ SSH_USER="root"
 # (Add any configuration specific to your service)
 ```
 
+**Important**: This is the file users edit to customize each service instance. Different deployments of the same template will have different `service.env` files.
+
+### How Environment Variables Work
+
+When Dropshell runs any template script (install.sh, start.sh, etc.), it:
+
+1. **First loads** all variables from `config/.template_info.env`
+2. **Then loads** all variables from `config/service.env` (which can override template defaults)
+3. **Exports** all these variables to the environment
+4. **Executes** the requested script with these variables available
+
+This means:
+- Scripts can use any variable defined in either file directly (e.g., `$CONTAINER_NAME`, `$IMAGE_TAG`)
+- Variables in `service.env` override those in `.template_info.env` if they have the same name
+- Users customize deployments by editing `service.env`, never `.template_info.env`
+
 ### 3. install.sh
 
 Installation script that sets up the service: