feat: add product commands and a gh-style api command

[alukach]

Part of #21, stacked on the login-session PR. Builds on the product endpoints in source-cooperative/source.coop#651.

source-coop product list | view | create | edit | delete over /api/v1/products. As #21 asks, the CLI checks nothing itself and shows the API's errors field by field.

• Auth: requests carry the login session's access token, or SOURCE_TOKEN if set. Without either they run signed out, which is enough to read public products, and a 401 says to run source-coop login.
• Reading: list follows paging up to -L (default 30). Reads take --json, and view --web opens the product page.
• Input: create and edit take fields as flags, from a JSON object with -F/--from-file (- for stdin), or both, with flags winning.
• Prompts: when stdin and stderr are terminals (and SOURCE_PROMPT_DISABLED is unset), the CLI asks for whatever is still missing:
  • create: a title defaulting to one made from the ID, a data connection from those the account can use, and only the visibilities that connection allows.
  • Descriptions: typed on one line, or written in $VISUAL/$EDITOR by answering e, as in gh.
  • edit with no flags: asks which fields to change, and starts each from its current value.
  • delete: asks whether to keep the data, then for the product name typed back. Without a terminal it needs --yes.
• Asking again: when the API rejects fields a person can answer (product ID, title, description, visibility, data connection), the CLI shows the API's message and asks for just those fields, keeping every other answer, then resends. Any other rejection is an error, as before.
• Output: list prints a header and aligned columns on a terminal, and tab-separated rows without a header when piped. create and edit print the product URL on stdout and their message on stderr.
• Errors: a request that gets no response says why (DNS, TLS, refused connection), not just which URL.

source-coop api PATH sends any /api/v1 request as the signed-in user, for whatever the other commands don't cover yet:

• gh-style flags: -X for the method, -f key=value for a string, -F key=value for a JSON boolean, null or number, and --input FILE.
• Fields go in the query string for GET and a JSON body otherwise, and the method defaults to POST when fields are given.
• It prints the response and exits non-zero on an error status.

Follow-ups, not in this PR:

• --jq.
• Generating argument help and types from the OpenAPI document.
• An endpoint listing the data connections an account may use for a product. The picker currently filters the legacy /data-connections route itself, and doesn't know about connections that require an account flag.

Deploying: needs the login-session PR, and source.coop#651 deployed. See the runbook in {{CLI_LOGIN_PR}}, steps 4 and 6.

Testing

• cargo fmt --check, cargo clippy --all-targets -- -D warnings and cargo test (58 passed) all pass.
• Product and api tests run against wiremock, using the request shapes from #651's routes. They include asking again for just the rejected field, a rejection of another field staying an error, the field picker, the piped table format, and api's query and body handling.
• The binary, run against a local stand-in API:
  • product list and api sent the session's refreshed access token.
  • api exited 1 on a 404.
  • An unreachable host reported "Connection refused".
• Not run against a live deployment: #651 isn't deployed yet.

Related

• Login session, this PR's base: {{CLI_LOGIN_PR}}
• API side: {{API_PR}}
• Product endpoints: feat(api): product list, create, view, edit and delete source.coop#651
• Deployment runbook: in {{CLI_LOGIN_PR}}

🤖 Generated with Claude Code

https://claude.ai/code/session_017poyHYEyxWEJct9X8Q71qF

[claude]

Claude finished @alukach's task in 22s —— View job

---

✅ No blocking issues — safe to merge.

I read src/api.rs, src/api_cmd.rs and the diffs to cache.rs, session.rs and Cargo.toml, and looked at how main.rs wires the token and URL. I did not read product.rs, prompt.rs, picker.rs or draft.rs in depth. I did not build or run the tests.

• Token handling: Client::resolve rejects any URL whose origin isn't the API's, so the bearer token can't be pointed at another host through api PATH.
• Cache files: cache::write_file now creates files as 0600 before writing, so a refresh token is never briefly world-readable.

Minor, not blocking:

• src/api_cmd.rs:53: api -X GET --input f.json puts -F/-f fields in the query string, but the --input body is still sent on the GET. Either drop it for GET or reject the combination.
• src/api_cmd.rs:44: -X is uppercased, so a lowercase method works, but a custom method like PROPFIND is accepted silently. Harmless.
• .env.staging and main.rs:85,101 use SOURCE_API_URL. AGENTS.md says environments come from --proxy-url / SOURCE_PROXY_URL via cache::env. Check that the login session and cached credentials are keyed per environment when only SOURCE_API_URL differs.

Simplify (ponytail)

• Cargo.toml: dialoguer is pulled in with only the editor feature, while picker.rs already hand-rolls a console-based picker and text prompt. Consider whether dialoguer can go entirely, using console plus $EDITOR through std::process::Command.
• src/product.rs (2849 lines) and src/prompt.rs: the Prompter trait, Step/Next loop and Draft machinery are a lot of abstraction. AGENTS.md asks for most of it, so this is advisory only.
• src/api.rs: Client::get and Client::request overlap with Client::send. The request generics could collapse if get is the only caller.

---

💰 Estimated review cost: $0.16 · 0m22s · 6 turns

[alukach]

Superseded by #45 (shared foundation + the api command) and #47 (product commands), with the auth login move now in #46. The work was split so auth and products don't depend on each other; the branch is kept.