Running it

Translation, not execution

A finished command becomes a plan: one or more API requests plus a render mode. The plan is sent over plain HTTPS and the response is formatted the way kubectl formats it — per-type table columns, -o wide extras, a small YAML emitter for -o yaml, describe longhand, top quantity parsing, rollout status and history.

Some commands genuinely need more than one request, and the plan covers that: describe fetches the object and its events; rollout history fetches the workload and its ReplicaSets. logs -f becomes a line stream rather than a response.

Writes are flagged as mutating, so the UI can confirm before sending.

The preview strip

The command field carries a live GET /api/v1/… preview of what would be sent. You can see the request take shape as you tap words — which is both a learning aid and a check against sending something you did not mean.

The Raw view

Alongside the formatted response is a Raw pane: the exact request(s) and the API server’s verbatim reply, one card per round trip in send order — so a describe shows both — each block selectable and copyable.

Two deliberate details:

• exchanges are recorded even when a command fails. A command that throws is precisely the one you want to inspect, and a Raw view that only works on success is useless at the moment you need it;
• request headers are not captured. They carry the cluster’s bearer token, and this is a screen people paste into bug reports. The app’s own network console has the full wire detail when you genuinely need it.

On a wide screen

Below about 840dp, a Build / Response / Raw switcher swaps one pane at a time. At or above it, the console splits into two columns — suggestion cards and the free-text input on the left, response or raw on the right with its own toggle — so tapping the next word never hides the output you are working from. The command field spans both. Running again keeps the Raw pane open if that is what you were watching.