[RosieWatson]

Summary

Adds rc checkpoints list. You need a Checkpoint's ID to create a Checkpoint rule, and this is the first way to find one from the CLI.

• Lists each Checkpoint's ID, the identifier the app uses for it (for example app_open), how it was created, and when.
• --limit / --cursor paginate, with the usual next-page hint. --json returns the raw page.

Notes

• GET /projects/{project_id}/checkpoints is development-status (with gatekeeping off), so I added it to v2-beta-overlay.yaml and cli-coverage.yaml. make gen only added pathCheckpoints.
• It needs the project_configuration:targeting_rules:read scope, the same as the Targeting rules endpoints.
• Read-only and experimental: hidden from rc --help until Checkpoint rules roll out, but still runnable and listed in rc commands / rc schema. Grouped under "catalog", where targeting will also go.

Testing

• go test ./internal/api/ ./internal/cli/ (new tests: the pagination query, table output and next-page hint, and the --json shape)
• golangci-lint run, gofmt

---

Note

Low Risk
Read-only list against a development API endpoint; no writes or auth changes, following the same experimental CLI pattern as flows.

Overview
Adds experimental rc checkpoints list so you can discover Checkpoint IDs and app identifiers (e.g. app_open) before creating Checkpoint rules. The command is read-only, supports --limit / --cursor and --json, and is hidden from rc --help until the feature ships (still in rc commands / rc schema under the catalog group).

Wires GET /projects/{project_id}/checkpoints through a new CheckpointsService on the API client, documents the development endpoint in the beta overlay and CLI coverage spec, and adds integration tests for pagination, table output, and JSON shape.

^{Reviewed by Cursor Bugbot for commit 5c24db7. Bugbot is set up for automated code reviews on this repo. Configure here.}