## [mirendev/runtime#1424](https://github.com/mirendev/runtime/pull/1424)

`63c6033` fixes the credential regression that was blocking this, and I think the PR is ready for human review.

**Credential failures now stay out of routing.** `routedOptions` resolves the bearer token once, before it builds the routing closure (`routing.go:79-82`). `attempt` reuses that token for direct and cloud alike. So an expired or rate-limited login fails while the State is being built, and that has three effects:
- The remembered route isn't deleted.
- Nothing is probed, and sign-in isn't retried.
- The error goes back through `unusableClusterError`.

Two tests pin this down:
- `TestRPCClientRoutingCredentialErrors` covers a refresh that returns 429 and one that returns 401. It asserts exactly one sign-in, the "too many sign-ins / Retry in" or `miren login` guidance, no `miren doctor`, and that `CloudRateLimitError` / `ErrLoginRequired` still unwrap.
- `TestSuccessfulClusterRoutes` checks that a credential failure leaves the cached direct route and the recovered CA in place.

The `token.go` change that turns a refresh 429 into `CloudRateLimitError` (`:106-107`) is what makes the rate-limit message reachable. It applies to every caller that refreshes a token, not only routed clusters, and I think that's correct. The token is still resolved once per State, which is how `directRPCOptions` already worked, so long-lived States aren't any worse off.

**Docs and description match the code.** "Only connection setup is retried" and the new paragraph on credentials both describe what `routedOptions` does. The PR description describes remembering the last route that worked, a cloud TTL that doesn't extend on reuse, and resolving credentials first.

**Open items a reviewer should know about:**
- The `cluster list --format json` ambiguity (`cluster.go:104`) is still open. The description calls it out of scope, so I'm treating it as your call.
- The first command after leaving a network takes about 8s. The description acknowledges this.
- Lifecycle polling during `cluster restart` doesn't pin its route (phinze's thread). The description acknowledges this too.

I'm not recommending approval. This is a large change to connection setup and to how TLS trust is established for remotely added clusters. phinze is still reviewing it, and the route caching and CA recovery in `routing.go` should get a human sign-off.

## Replies to existing threads

_Posted to the PR's comment threads when you submit._

- _(reply & resolve: addressed)_ I checked this at `63c6033`. `routedOptions` now resolves the bearer token before routing starts (`routing.go:79-82`), and `attempt` only wraps dial options around that token. So a sign-in failure comes back from `RPCOptions`/`State` before any route is touched, and it reaches `unusableClusterError`.

`TestRPCClientRoutingCredentialErrors` covers both 429 and 401. It asserts a single refresh call, the rate-limit or `miren login` guidance with no `miren doctor`, and that the typed errors still unwrap. `TestSuccessfulClusterRoutes` shows the cached direct route and recovered CA survive an auth failure. That's the fix I asked for. Resolving.
- _(reply)_ This is unchanged at `63c6033`. The PR description now lists it as out of scope for the routing and diagnostics work, so I'm treating it as your accepted tradeoff and not a blocker. It's still a real gap for scripts that read `cluster list --format json`, so I'll leave the thread open for you or a reviewer to close, or to track as a follow-up.

---

**Verdict:** ready