perf(cli): project recent-results fields in checks get

[thebiglabasky]

Affected Components

• CLI
• Test

Notes for the Reviewer

Now that the backend supports a fields query parameter on GET /v2/check-results/{checkId} (checkly/monorepo#2384, merged), this is a small additive optimization for the human-facing checks get <id> path.

The default checks get screen only renders a narrow recent-results table, yet it was fetching full result bodies (metadata, assets, apiCheckResult, browserCheckResult, …). Asking the API for those wide payloads is unnecessary and can trigger slow paths for result-heavy checks. This change asks the API only for the columns the table actually renders.

What changed

• rest/check-results.ts: added a CheckResultField union matching the backend-supported field names, extended ListCheckResultsParams with fields?: CheckResultField[], and normalized the array to a comma-separated fields=... query string in getAll() rather than relying on Axios array serialization (backend accepts both fields=id,startedAt and repeated params; the comma form is the most predictable across HTTP clients).
• commands/checks/get.ts: passes a fixed internal projection — id, startedAt, runLocation, hasErrors, hasFailures, isDegraded, responseTime — for detail/markdown output. These are exactly what formatResults() and resolveResultStatus() read.

Deliberate product/API choices

• No new public flag. checks get aggregates check details, status, analytics, error groups, and results, so a generic --fields/mode flag would be ambiguous. The projection is internal and fixed. Help output is unchanged.
• JSON output intentionally omits fields so existing --output json consumers keep full results entries (backwards compatibility). Locked in by a test.
• --result <id> drilldown is unchanged — it uses the v1 detail endpoint and needs the full result payload for the detail renderer.
• The --include-attempts window query is also untouched and still requests full payloads.
• Additive and backwards-compatible: the default backend response is unchanged when fields is omitted.

Tests added

• rest/__tests__/check-results.spec.ts — fields array serializes to a comma-separated string; omitted when absent; other params pass through.
• commands/__tests__/checks-get-results-projection.spec.ts — default + markdown request the projection (with limit/nextId unchanged); cursor forwarded; --output json does not send fields; --result uses checkResults.get and never calls getAll.

Verification

• Focused Vitest (new specs + existing checks-get attempts/flags): green.
• eslint, prepare:dist (tsc typecheck), prepack (oclif manifest): all clean.
• checks get --help smoke: no new flag, output intact.
• Not run: a live staging checks get <id> call (needs a real check ID + authenticated request). Suggested manual check: CHECKLY_ENV=staging checkly checks get <id> and confirm the outgoing request includes fields=id,startedAt,runLocation,hasErrors,hasFailures,isDegraded,responseTime while terminal output is unchanged.

🤖 Generated with Claude Code