docs: stop asking which environment, everyone is on production

Second thing the real run found, and this one I caused fixing the first. Making the assistant
report the environment turned into making it ask, and "production or dev?" is a decision nobody
outside the platform team has ever made. It arrives as the very first question, from an assistant
that is supposed to be guiding, about a distinction the user has no way to evaluate.

Production is the answer. The plain `thatopen login --token <TOKEN>` is already correct, and the
guide now says not to ask. Dev is folded away behind a details block for the people building the
platform, who know who they are and will say so unprompted.

What survives is the part that was actually useful: read `apiUrl` rather than trusting a "Logged
in successfully" that never names the environment — and then say nothing when it reads
production, because there is no decision to report. Only a machine unexpectedly pointed at dev
is worth a sentence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: agviegas

docs/platform-token.md

@@ -26,36 +26,48 @@ a `.thatopen` file in the project instead, which is what a scaffolded project us
 You do not need an npm account or an npm token for the private packages. The CLI derives access to
 them from this one.
 
-## Production and dev are separate worlds
+## Everyone is on production
+
+**Do not ask the user which environment they want.** Production is the answer, it is the default,
+and the plain command above is already correct. Asking turns a decision nobody has into a question
+they cannot answer, at the worst possible moment — the first thing you say to them.
+
+There is a `dev` platform, and it exists for the people building That Open Platform itself. If the
+user is one of them they already know, and they will tell you without being asked.
+
+Everything below this line is for that case only. If nothing has mentioned dev, skip it.
+
+<details>
+<summary>Dev, for the platform team</summary>
 
 Two platforms, not two views of one. Separate accounts, separate tokens, separate projects. A token
-from one is refused by the other, and a model published to the wrong one is somewhere the user's
+from one is refused by the other, and a model published to the wrong one lands somewhere the user's
 team cannot see — while every command reports success.
 
-| | |
-|---|---|
-| **Production** | `https://platform.thatopen.com` — the default, and what almost everybody wants |
-| **Dev** | `https://dev.platform.thatopen.com` — only if the user's team works there |
-
 ```bash
-thatopen login --token <TOKEN>                                          # production
-thatopen login --token <TOKEN> --api-url https://dev.platform.thatopen.com   # dev
+thatopen login --token <TOKEN> --api-url https://dev.platform.thatopen.com
 ```
 
-The dashboard for dev is the same page on that host:
-`https://dev.platform.thatopen.com/dashboard/data`.
+Its dashboard is the same page on that host: `https://dev.platform.thatopen.com/dashboard/data`.
+
+</details>
+
+## Check, do not ask
+
+**`login` prints "Logged in successfully" and does not name the environment**, so nothing on screen
+would contradict a wrong assumption. Read `apiUrl` from `~/.thatopen/config.json` yourself.
+
+If it says production — which it will — say nothing about it and carry on. There is no decision to
+report.
 
-## Say which one you are on
+**Only if it says dev**, and the user has not told you they work there, is there anything to say:
 
-**`login` prints "Logged in successfully" and does not name the environment.** Nothing on screen
-will contradict a wrong assumption, so make the statement yourself: read `apiUrl` from
-`~/.thatopen/config.json` and tell the user in plain words — *"you are on production"* or *"you are
-on dev"*.
+> "This machine is pointed at the dev platform, which is the one the That Open team builds on. I'll
+> move it to production — that will need a token from **https://platform.thatopen.com/dashboard/data**,
+> since dev tokens are not accepted there."
 
-Do this **even when the machine is already logged in**, and especially then. A saved login is
-whoever used this machine last, not an answer to a question you have asked. If you find dev, offer
-production before going any further; moving needs a **production** token, so the user has to create
-one on the production dashboard first.
+Check this **even when the machine is already logged in**, and especially then. A saved login is
+whoever used this machine last, not an answer to a question you have asked.
 
 ## When it fails
 

docs/revit-collab-quickstart.md

@@ -104,12 +104,16 @@ Do **not** ask for the access token yet. That is Step 1.
    thatopen login --token <TOKEN>
    ```
 
-   **Read [Logging in to That Open Platform](./platform-token.md) before you run that** — it is
-   short, and it covers the two things that go wrong here rather than later: production and dev are
-   separate worlds, and `login` does not tell you which one you just saved.
+   That command is already right: **it logs in to production, which is where everybody is.** Do not
+   ask the user to choose an environment — there is a dev platform, it is for the people building
+   That Open Platform, and they will say so without being asked.
 
-   In particular: **log in even if the machine is already logged in**, and say out loud which
-   environment you ended up on. Never print the token back.
+   **Log in even if the machine is already logged in.** A saved login is whoever used this machine
+   last. Never print the token back.
+
+   [Logging in to That Open Platform](./platform-token.md) is the short page for when this does not
+   go smoothly: what to do if the machine turns out to be pointed at dev, and why `Unauthorized` and
+   `403` mean different things.
 
 **Log in before Step 2**, not after: installing the add-in downloads a private package and needs
 these credentials.