gcloud: generic TOML filter truncates silently and saves almost nothing on the common commands

gcloud is currently handled by src/filters/gcloud.toml, a generic filter that strips blank lines, clips each line at 120 characters, and keeps the first 30 lines. Measured against a real project, this gives a poor trade between bytes saved and information kept.

Related: #3485 reports that rtk rewrite "gcloud ..." is refused on v0.45.0. This issue is about what the filter does once it is reached. #1128 proposes expanding the TOML, which does not address points 2 and 3 below.

What the filter does today

Bytes are stdout+stderr of one run on develop.

Problems

1. The row cap has no relation to the data. 30 lines is the TOML default. A 113-instance inventory or a 146-bucket listing loses most rows. A recovery hint is appended, but the cap is not a filter decision, it is a coincidence.
2. Line clipping at 120 characters drops columns silently. gcloud's default table is wide. On compute instances list the STATUS column falls past the clip on every row, with no marker. The output looks complete and is not.
3. A user-supplied --format is still truncated. --format=value(...) or --format=json signals the user wants exactly the shape they asked for. The filter caps it at 30 lines anyway. Related to #2400, where --format= handling caused a crash.
4. Where savings are highest, content is lowest. logging read shows 98% saving because 28 of 30 entries are gone. Each entry is 40 to 70 lines of JSON, so 30 lines is not even one full entry in some cases.
5. Nothing on the dense commands. container clusters list and config list pass through unchanged, so no gain where output is already tabular.

Comparison point

aws_cmd.rs handles the equivalent commands by forcing JSON and emitting one compact row per resource, with CAP_LIST (20) for resource lists and CAP_INVENTORY (50) for log events, plus a tail hint. gcloud has the same shape of problem and the same JSON capability, including field projections (--format=json(name,zone,status)) that keep the raw output small. Full --format=json for compute instances list is 12.6 MB on the same project, above the 10 MiB capture cap, so a projection is needed rather than plain JSON.

Proposal to discuss

• Treat gcloud like aws: a small Rust module for the handful of hot commands (compute instances list, container clusters list, run services list, logging read, storage ls, storage cp/rsync/mv), everything else passthrough.
• Respect any explicit --format and pass the command through untouched.
• Use the shared cap classes from src/core/truncate.rs rather than a flat 30 lines.
• Keep stderr visible. gcloud reports partial failures as WARNING: Some requests did not succeed on stderr with exit 0.

Open questions: which columns matter per command (for example PREEMPTIBLE on instances, NODE_VERSION on clusters), and whether gsutil should be in scope.

Read src/filters/gcloud.toml, compare the command handling in aws_cmd.rs, and inspect shared cap classes in src/core/truncate.rs. Use the listed gcloud commands and output measurements as the validation cases; done means explicit formats pass through, hot commands preserve useful structured output within shared caps, and stderr remains visible.