docs: the backend endpoint is pinned to production

docs/e2e-live-harness.md

@@ -156,8 +156,10 @@ E2E_LIVE=1 OPENROUTER_API_KEY=sk-or-… make e2e-live
 
 - `E2E_LIVE=1`: required; the deliberate opt-in.
 - `OPENROUTER_API_KEY`: required; billed per token.
-- `MEDULLA_STAGING=1`: the default. Targeting production additionally needs
-  `E2E_ALLOW_PROD=1`.
+- `E2E_ALLOW_PROD=1`: required. The binary's endpoint is pinned to production, so
+  this suite can only run against production. `MEDULLA_STAGING` no longer does
+  anything, and the harness refuses outright if it is set rather than letting a
+  stale invocation believe it is safely on staging.
 - `LIVE_MODEL`: defaults to a cheap small model.
 - `MEDULLA_LINK_FORWARDER`, `MEDULLA_LINK_HOME_<name>`,
   `MEDULLA_LINK_OWNER_DIR_<name>`: the transport prerequisites above.

gitbooks/developers/configuration.md

@@ -21,10 +21,9 @@ marker and without changing it. That is also how you reach the pre-login home
 again (`MEDULLA_USER=local`).
 
 `medulla logout` clears the *session* and leaves the marker alone, so subsequent
-commands still resolve that account's home. That is deliberate: the account's
-`config.toml` is where a staging or self-hosted `backend.baseUrl` lives, and
-forgetting which account was active would offer the next login a production
-endpoint the operator never configured.
+commands still resolve that account's home. That is deliberate: an account's
+directory holds its own config and state, and forgetting which account was active
+would strand the next login somewhere the operator never chose.
 
 Signing in as a different account moves the marker, never the data: the previous
 account's directory stays where it is, and signing back in returns to it. A
@@ -52,13 +51,13 @@ A `.env` file in the current directory is loaded at startup, before anything rea
 
 Config is merged from lowest to highest precedence (highest wins):
 
-1. Built-in defaults (production endpoints; `MEDULLA_STAGING` flips the default URLs).
+1. Built-in defaults (production endpoints).
 2. User-global `<home>/config.toml`.
 3. Project-local `./.medulla/config.toml` (else `./medulla.toml`).
-4. Environment variables (`MEDULLA_API_URL`, `MEDULLA_TOKEN` via `tokenEnv`, `MEDULLA_STAGING`, `MEDULLA_STATE_DIR`, and the `MEDULLA_*` harness knobs, whose old `TINYPLACE_*` spelling is deprecated but still read).
+4. Environment variables (`MEDULLA_TOKEN` via `tokenEnv`, `MEDULLA_STATE_DIR`, and the `MEDULLA_*` harness knobs, whose old `TINYPLACE_*` spelling is deprecated but still read). The backend endpoint is not among them — see [Endpoints](#endpoints).
 5. CLI flags.
 
-Files are merged field-by-field (a recursive table merge), so a project-local file can override just `backend.baseUrl` without discarding the rest of a global file. [TOML](https://toml.io/) is the primary format; `--config <path>` still accepts either `.toml` or `.json` (parser chosen by extension) and bypasses file discovery, but env vars and CLI flags still override it. The Config tab shows the merged effective config and lists the source files that contributed.
+Files are merged field-by-field (a recursive table merge), so a project-local file can override just `backend.tokenEnv` without discarding the rest of a global file. [TOML](https://toml.io/) is the primary format; `--config <path>` still accepts either `.toml` or `.json` (parser chosen by extension) and bypasses file discovery, but env vars and CLI flags still override it. The Config tab shows the merged effective config and lists the source files that contributed.
 
 ### The sections
 
@@ -101,21 +100,30 @@ See [`config.example.toml`](https://github.com/tinyhumansai/medulla/blob/main/co
 
 ## Endpoints
 
-The backend base URL defaults to production, `https://api.tinyhumans.ai`. Set `MEDULLA_STAGING=1` (or `true`, case-insensitive) to switch it to `https://staging-api.tinyhumans.ai`.
+The backend base URL is **pinned to production**, `https://api.tinyhumans.ai`. It is
+a constant in the binary: no environment variable, config key, or flag moves it.
 
-The link forwarder has no endpoint of its own: it is served by the same backend, so `link.forwarderUrl` defaults to whatever `backend.baseUrl` resolved to and moves with it. Set it explicitly only for a deliberately split deployment.
+This is a change. `MEDULLA_API_URL` and `MEDULLA_STAGING` were both honoured, as was
+a `backend.baseUrl` key in the config file. All three are now ignored. A config that
+still carries `backend.baseUrl` parses without complaint and the key does nothing —
+it is even written back out with the endpoint the binary actually uses, so a config
+you dump will never disagree with where your traffic goes. Reaching any other
+deployment means editing the constant and rebuilding.
 
-Base-URL precedence, highest first:
+The link forwarder is a different service and is still configurable: it is normally
+served by the same backend, so `link.forwarderUrl` defaults to the pinned backend URL.
+Set it explicitly only for a deliberately split deployment.
 
-* Backend: `MEDULLA_API_URL` env var, then config-file `backend.baseUrl`, then the staging or production default.
-* Link forwarder: config-file `link.forwarderUrl`, then the resolved backend base URL.
+Base-URL precedence, such as remains of it:
 
-Override the base URL (and the token env var name) in the config file, for example to point at a local backend:
+* Backend: the pinned constant. Nothing else.
+* Link forwarder: config-file `link.forwarderUrl`, then the pinned backend URL.
+
+The token env var name is still config's to set:
 
 ```json
 {
   "backend": {
-    "baseUrl": "http://localhost:5000",
     "tokenEnv": "MEDULLA_TOKEN"
   }
 }

gitbooks/developers/environment-variables.md

@@ -25,10 +25,13 @@ these can be set either way. Truthy values are `1` and `true`, case-insensitive.
 
 ## Backend and authentication
 
+The backend endpoint is **not** configurable. It is compiled into the binary as
+`https://api.tinyhumans.ai`, and no environment variable moves it. `MEDULLA_API_URL`
+and `MEDULLA_STAGING` used to, and no longer do — setting either has no effect at
+all rather than an error, because there is no longer a setting to be wrong about.
+
 | Variable | What it does | Default |
 | --- | --- | --- |
-| `MEDULLA_API_URL` | Backend base URL. Beats config-file `backend.baseUrl` and the built-in default. | unset |
-| `MEDULLA_STAGING` | Truthy flips the built-in default base URL from production to staging. | unset |
 | `MEDULLA_TOKEN` | The bearer JWT, named by the default `backend.tokenEnv`. Config can point `tokenEnv` at a different variable. | unset |
 
 ## Halves of the process

gitbooks/developers/testing.md

@@ -310,7 +310,7 @@ It fails closed on every axis, so it cannot start by accident:
 | --- | --- |
 | `E2E_LIVE=1` | Required; the deliberate opt-in. |
 | `OPENROUTER_API_KEY` | Required; billed per token. |
-| `MEDULLA_STAGING=1` | The default. Targeting production additionally needs `E2E_ALLOW_PROD=1`. |
+| `E2E_ALLOW_PROD=1` | Required. The endpoint is pinned to production, so this suite has nowhere else to run; `MEDULLA_STAGING` no longer exists and the harness refuses if it is set. |
 | `LIVE_MODEL` | Defaults to a cheap small model. |
 | `MEDULLA_LINK_FORWARDER` | A deployed forwarder implementing section 5 of the [link protocol](host-link-protocol.md#5-forwarder-rules). |
 | `MEDULLA_LINK_HOME_<name>`, `MEDULLA_LINK_OWNER_DIR_<name>` | Provisioned `node.json` identity directories. |

gitbooks/developers/troubleshooting.md

@@ -87,9 +87,9 @@ rather than saving one nothing would read, so a login that reports this is
 telling you which source to remove.
 
 A stored session is also scoped to the deployment that issued it: it records its
-own `baseUrl` and is only offered to a `backend.baseUrl` with a matching origin.
-If you have repointed the config at a different deployment, sign in again against
-that one.
+own `baseUrl` and is only offered to a backend with a matching origin. A session
+minted against another deployment — by an older build, back when the endpoint was
+configurable — will not be offered to the pinned one; sign in again.
 
 Older installs kept a separate `credentials.json`, which could report success
 while the runtime stayed signed out. `login` now adopts that file — verifying its
@@ -106,8 +106,9 @@ home. See [Medulla home](configuration.md#medulla-home).
 Readiness is three states, not two, because a host answers each differently: run,
 sign in, or stop. Reachable but signed out opens the login flow. No backend URL
 at all reports that error instead, because a login screen cannot fix a missing
-base URL. Check `backend.baseUrl` in the config, or `MEDULLA_API_URL`, and
-whether `MEDULLA_STAGING` is pointing you somewhere you did not intend.
+base URL. The endpoint is pinned into the binary now, so this is no longer
+something a config or environment variable can get wrong — a build that reports it
+is a build whose constant is empty, which is a bug worth filing.
 
 To get a working interface with no backend at all, ask for the mock runtime:
 `medulla --mock`. The login screen deliberately does not offer it — a failed