[alukach]

source-coop member list fails with a 404 on staging. #57 calls /accounts/{id}/members, but source.coop#679 replaced that endpoint, along with /products/{account}/{product}/members and /memberships/{id}/accept, /reject and /revoke, with one /memberships resource:

$ sc member list developmentseed --verbose
[verbose] GET https://staging.source.coop/api/v1/accounts/developmentseed/members (bearer)
[verbose] -> HTTP 404

The commands look and behave as before. Only the requests underneath change:

Command	Request
member list ORG[/PRODUCT]	GET /memberships?membership_account_id=ORG[&product_id=PRODUCT], every page
invitation list, member leave	GET /memberships?account_id=YOU&state=…, with your account from /whoami
member invite	POST /memberships with membership_account_id, product_id, account_id and role
member edit	PATCH /memberships/{id} {role} (unchanged)
accept, then reject / revoke / leave	PATCH /memberships/{id} {"state": "member"}, then {"state": "revoked"}

• Product memberships: they're named by product_id. repository_id is still read from older servers. The README's JSON field list says product_id.
• Production: it serves neither the old nor the new endpoints yet (both 404), so nothing that works there breaks.

This was pushed to #57's branch after #57 merged, so it's here instead.

Testing

• cargo fmt, cargo clippy --all-targets -- -D warnings, cargo test and cargo test --features staging pass (140 tests). The mocks now use the new paths and the paged responses.
• Against staging: checked against staging's OpenAPI spec, and with a signed-out GET /memberships?membership_account_id=developmentseed, which returns the page the CLI reads. Listing has been tried signed in. Invites, role changes and accepting are covered by mocked tests only.

🤖 Generated with Claude Code

[claude]

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

---

✅ No blocking issues — safe to merge.

The diff matches the PR description. I read it but did not run the build or tests.

• every_page uses the existing api::Page, which has items and next_cursor, and follows cursors to the end.
• list_url and invite send membership_account_id, plus product_id when a product is named.
• act_on now sends PATCH /memberships/{id} with {"state": ...}.
• my_memberships reads the account ID from /whoami and returns an error if it is missing.
• The README's JSON field list now says product_id.

Not covered by the diff: invites, role changes and accepting are only tested against mocks, as the PR notes, so check them on staging when you can.

Simplify (ponytail)

• src/member.rs members(): the Scope::of(m) == *scope filter is dead if the API filters by membership_account_id and product_id. Your ponytail: comment already says this. Cut it once staging confirms the API filters correctly.
• src/member.rs act_on(verb: &str): it turns a string verb into a state with if verb == "accept". Callers could pass the target state ("member" or "revoked") directly, which removes the verb-to-state mapping.

---

💰 Estimated review cost: $0.13 · 0m11s · 5 turns