This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
Always use Bazel — never go test or go build directly.
bazel test //... # run all tests
bazel test //cli/cmd/api:api_test # run unit tests only
bazel test //cli:cli_test # run integration tests only
bazel test //... --test_output=all # show full test output
bazel build //cli # build the binaryCredentials must be in the environment for integration tests (//cli:cli_test). They are loaded automatically from .envrc via direnv, and forwarded to Bazel's sandbox via .bazelrc.
The CLI is a Cobra application with three layers:
cli/cmd/api/ — pure HTTP client package. Split across three files: api.go (types, Client struct, constructors), user.go (user endpoint methods), lego.go (LEGO catalog endpoint methods). Uses resty. NewClient(apiKey, authToken) is the public constructor; newClientWithBaseURL(apiKey, authToken, baseURL) is used in tests to inject a mock server.
cli/cmd/sets.go — Cobra command definitions wired to api.Client methods. All set and setlist commands live here. newAPIClient(cmd) extracts auth from the command context set by the login middleware.
cli/cmd/user.go — Login middleware via PersistentPreRunE on the user command. Calls POST /users/_token/ and stores user_token and api_key in the command context so all subcommands can access them.
Every user * command triggers PersistentPreRunE in user.go, which reads REBRICKABLE_USERNAME, REBRICKABLE_PASSWORD, REBRICKABLE_API_KEY from env, calls the login endpoint, and stores the resulting token in cmd.Context() under the keys AuthToken and ApiKey.
- Add a method to
Clientincli/cmd/api/user.go(user endpoints) orcli/cmd/api/lego.go(catalog endpoints) following the existing pattern. - Add a corresponding
*cobra.Commandvar incli/cmd/sets.goand register it in the appropriate*Commands()init function. - Add unit tests in
cli/cmd/api/api_test.gousinghttptest.NewServer+newClientWithBaseURL. - Add a txtar integration test in
testdata/only if the operation is idempotent and self-cleaning (i.e. uses stable IDs like set numbers). Resources with auto-generated IDs (setlists, part lists) are not suitable for txtar tests — cover with unit tests only.
See requirements.md for the full list of unimplemented endpoints from openapi.spec.json.