`gog sheets raw --sheet <some_tab>`

[gurgeous]

raw returns a lot of data. Let us request a single sheet. I have some big sheets. Real big.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 10, 2026, 7:49 PM ET / 23:49 UTC.

Summary
The requested selector is absent from current main and v0.39.1. This is a bounded, useful Sheets feature; no existing PR was found that owns it.

Reproducibility: not applicable. as a bug reproduction: this requests a new selector, whose absence is confirmed in current source and release documentation.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Share version, platform, channel/provider, and relevant config details.

Next step
This fits one focused feature PR using the existing Sheets request and raw-output infrastructure, with no competing open implementation found.

Review details

Best possible solution:

Add opt-in server-side tab selection while preserving the unfiltered default, raw JSON shape, and existing sensitive-data warnings.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a bug reproduction: this requests a new selector, whose absence is confirmed in current source and release documentation.

Is this the best way to solve the issue?

Yes: an optional selector on the existing raw command is a narrow extension, and server-side filtering addresses payload size better than filtering downloaded JSON.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Google's returned sheet and spreadsheet-level metadata must be checked with and without grid data before promising the precise scope of the filtered response.

Codex review notes: model internal, reasoning medium; reviewed against 29a5adfb3e90.

Label changes

Label changes:

• add P2: A focused improvement would make existing raw reads more practical for large spreadsheets.
• add impact:ux-friction: Users currently receive all tabs when they need only one, increasing output and downstream filtering work.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: A focused improvement would make existing raw reads more practical for large spreadsheets.
• impact:ux-friction: Users currently receive all tabs when they need only one, increasing output and downstream filtering work.

Evidence reviewed

Acceptance criteria:

• go test ./internal/cmd -run TestSheetsRaw
• go test ./internal/sheetsa1 ./internal/outfmt
• make docs-commands
• make ci
• Capture redacted live Google output for selected and unselected multi-tab reads, with and without --include-grid-data.

What I checked:

• Current implementation lacks tab selection: The checkout matches fetched main. SheetsRawCmd exposes only spreadsheet ID, include-grid-data, and pretty; its request supplies no ranges or tab filter. (internal/cmd/sheets.go:688, 29a5adfb3e90)
• Latest release has the same limitation: The v0.39.1 source contains the same unfiltered raw request and no sheet selector. (internal/cmd/sheets.go:688, 6895139ab1b4)
• Existing scoped read pattern: Read-format already passes Ranges to Spreadsheets.Get, but projects formatting records rather than returning the lossless raw response. It supplies a reusable request pattern, not an equivalent user capability. (internal/cmd/sheets_read_format.go:65, 29a5adfb3e90)
• Raw output contract and existing tests: Raw documentation promises the Google response shape. Existing raw tests cover default grid exclusion, explicit inclusion and its warning, API failures, and empty IDs; they contain no tab-selection coverage. (internal/cmd/sheets_raw_test.go:81, 29a5adfb3e90)
• Vision supports a focused extension: VISION.md explicitly welcomes small useful primitives and incremental Sheets capabilities, with tests, documentation, changelog updates, and live Google proof. (VISION.md:13, 29a5adfb3e90)
• Discussion and canonical search: The live issue body matches the supplied request and has no assignee or milestone. REST searches found no open PR for raw Sheets selection. The supplied structural batching, Connected Sheets, Forms, and Docs suggestions requests address different capabilities.

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.