SDK v0.10.0 (adopted in #584) adds EverythingService, reachable via AccountClient.Everything() (basecamp/basecamp-sdk#435, #438). It has 17 methods and no CLI surface today.
The account-wide aggregates it exposes:
- Recording streams:
Messages, Comments, Checkins, Forwards
BoostsFiles (takes an options struct)- Todo rollups:
OpenTodos, CompletedTodos, UnassignedTodos, NoDueDateTodos, OverdueTodos
- Card rollups:
OpenCards, CompletedCards, UnassignedCards, NoDueDateCards, NotNowCards, OverdueCards
Most are paginated by an int32 page and return grouped pages (RecordingsPage, BucketTodosGroupsPage, BucketCardsGroupsPage); the two overdue methods return flat slices instead.
API-COVERAGE.md currently records the family as present-but-unsurfaced and keeps it out of the parity totals, so the matrix isn't claiming coverage it doesn't have. That note should be replaced with real rows once commands exist.
Worth designing rather than translating
A mechanical 1:1 mapping to 17 subcommands would be the wrong shape. These aggregates overlap conceptually with three existing groups:
recordings already browses by type and status across projectsassignments already answers "what's on my plate"search already does cross-project lookup
So the open question is whether this becomes a new everything group, or whether the aggregates become flags/filters on the groups that already own those nouns — for example an account-wide scope on recordings, or overdue/unassigned filters on todos and cards. Note that STYLE.md forbids a new top-level verb that shadows an existing group noun, which constrains some of the options.
Pagination also needs a decision: the CLI's existing list commands mostly hide paging behind bounded defaults, and these methods expose raw page numbers.
Not blocking release N — the bump ships without it.
SDK v0.10.0 (adopted in #584) adds
EverythingService, reachable viaAccountClient.Everything()(basecamp/basecamp-sdk#435, #438). It has 17 methods and no CLI surface today.The account-wide aggregates it exposes:
Messages,Comments,Checkins,ForwardsBoostsFiles(takes an options struct)OpenTodos,CompletedTodos,UnassignedTodos,NoDueDateTodos,OverdueTodosOpenCards,CompletedCards,UnassignedCards,NoDueDateCards,NotNowCards,OverdueCardsMost are paginated by an
int32page and return grouped pages (RecordingsPage,BucketTodosGroupsPage,BucketCardsGroupsPage); the two overdue methods return flat slices instead.API-COVERAGE.mdcurrently records the family as present-but-unsurfaced and keeps it out of the parity totals, so the matrix isn't claiming coverage it doesn't have. That note should be replaced with real rows once commands exist.Worth designing rather than translating
A mechanical 1:1 mapping to 17 subcommands would be the wrong shape. These aggregates overlap conceptually with three existing groups:
recordingsalready browses by type and status across projectsassignmentsalready answers "what's on my plate"searchalready does cross-project lookupSo the open question is whether this becomes a new
everythinggroup, or whether the aggregates become flags/filters on the groups that already own those nouns — for example an account-wide scope onrecordings, or overdue/unassigned filters ontodosandcards. Note thatSTYLE.mdforbids a new top-level verb that shadows an existing group noun, which constrains some of the options.Pagination also needs a decision: the CLI's existing list commands mostly hide paging behind bounded defaults, and these methods expose raw page numbers.
Not blocking release N — the bump ships without it.