chore(guides): update guides

apps/docs/content/guides/environment-variables.mdx

@@ -87,20 +87,21 @@ services:
 
 ## Project Variables -- Auto-Inherited
 
-Project variables are **automatically available** in every service. They are injected as OS env vars at container start in every service's **runtime** container and are shell-visible in **build** containers too — but with a caveat: inside zerops.yaml YAML interpolation, project vars are referenced through the same `${RUNTIME_VAR_NAME}` prefix you use to lift any service runtime var into build context.
+Project variables are **automatically available in every service, in both runtime AND build containers**. The platform injects them as OS env vars at container start in every service's runtime container and also in every service's build container during the build phase. From zerops.yaml's point of view they are referenced **directly by name** with `${VAR_NAME}` — **no `RUNTIME_` prefix in either scope**. The `RUNTIME_` prefix is reserved for a different use case: lifting a single service's service-level runtime variable into that same service's build context. Project-scope vars are broader than service-scope and do not need lifting.
 
-**In shell commands** (buildCommands, initCommands) project vars are directly readable:
+**In shell commands** (buildCommands, initCommands, start) project vars are directly readable:
 ```yaml
 build:
   buildCommands:
-    - echo "building for $STAGE_API_URL"    # shell reads the OS env var
+    - echo "building for $STAGE_API_URL"          # shell reads the OS env var
+    - VITE_API_URL=$STAGE_API_URL npm run build    # or pass it forward by shell prefix
 ```
 
-**In `build.envVariables` YAML** (to compose a derived var that the bundler consumes), project vars are lifted with the `RUNTIME_` prefix — the same way any runtime-scope var is lifted into build:
+**In `build.envVariables` YAML** (to compose a derived var that the bundler consumes) reference the project var directly without prefix:
 ```yaml
 build:
   envVariables:
-    VITE_API_URL: ${RUNTIME_STAGE_API_URL}   # project var STAGE_API_URL read into build as VITE_API_URL
+    VITE_API_URL: ${STAGE_API_URL}   # project var STAGE_API_URL read as-is, NO RUNTIME_ prefix
 ```
 
 **In `run.envVariables` YAML** (to forward a project var under a framework-conventional name without creating a shadow), reference directly without prefix:
@@ -134,7 +135,7 @@ project:
     STAGE_FRONTEND_URL: https://appstage-${zeropsSubdomainHost}.prg1.zerops.app
 ```
 
-The platform resolves `${zeropsSubdomainHost}` when injecting the value into services at container start. The frontend consumes `STAGE_API_URL` via `${RUNTIME_STAGE_API_URL}` in `build.envVariables` (baking it into the bundle), and the API consumes `STAGE_FRONTEND_URL` via `${STAGE_FRONTEND_URL}` in `run.envVariables` (for CORS allow-list). The same names must be set on the workspace project via `zerops_env project=true action=set` after provision, so workspace verification doesn't see literal `${STAGE_FRONTEND_URL}` strings.
+The platform resolves `${zeropsSubdomainHost}` when injecting the value into services at container start. The frontend consumes `STAGE_API_URL` via plain `${STAGE_API_URL}` in `build.envVariables` (baking it into the bundle at compile time) — **no `RUNTIME_` prefix**. The API consumes `STAGE_FRONTEND_URL` via plain `${STAGE_FRONTEND_URL}` in `run.envVariables` (for CORS allow-list). The same names must be set on the workspace project via `zerops_env project=true action=set` after provision, so workspace verification doesn't see literal `${STAGE_FRONTEND_URL}` strings.
 
 ## Secret Variables