Add my assignments API operations (list, completed, due)

[robzolkos]

Summary

• Adds three new /my/assignments API operations to the Smithy spec, matching the BC3 endpoints from #9932
  • GetMyAssignments — GET /my/assignments.json returning priorities and non-priorities
  • GetMyAssignmentsCompleted — GET /my/assignments/completed.json returning completed assignments
  • GetMyAssignmentsDue — GET /my/assignments/due.json?scope= with scope filtering (overdue, due_today, due_tomorrow, due_later_this_week, due_next_week, due_later)
• Regenerates OpenAPI spec, behavior model, and Go generated client
• Adds Go service layer (MyAssignmentsService) with List, Completed, and Due methods
• Registers service on AccountClient via MyAssignments() accessor

New MyAssignment shape is separate from the existing Assignable since the response format differs (uses content instead of title, includes completed, comments_count, has_description, priority_recording_id, children).

---

Summary by cubic

Adds three /my/assignments API operations (list, completed, due) and updates all SDKs (Go, TypeScript, Swift, Kotlin, Ruby) with service methods and models. Regenerates the spec, wires the Go MyAssignmentsService into AccountClient, fixes codegen mappings, reuses Person for assignees, and adds tests.

• New Features

  • Smithy: GetMyAssignments, GetMyAssignmentsCompleted, GetMyAssignmentsDue with scope filter (overdue, due_today, due_tomorrow, due_later_this_week, due_next_week, due_later) and retry (3x on 429/503).
  • Regenerated OpenAPI/behavior model and generated clients across Go/TS/Swift/Kotlin/Ruby; added Reports service methods for my assignments.
  • New MyAssignment shape (separate from Assignable) with content, completed, comments_count, has_description, priority_recording_id, children, and assignees using Person.
  • Go: new MyAssignmentsService with List, Completed, Due(opts); available via AccountClient.MyAssignments().

• Bug Fixes

  • Fixed codegen/tag mappings and method-name overrides for Reports across SDKs.
  • Replaced MyAssignmentPerson with Person for MyAssignment.assignees across SDKs for consistency.
  • Added test coverage for my assignments in Go, TypeScript, and Ruby.

^{Written for commit dedb521. Summary will update on new commits.}

[github-actions]

Spec Change Impact

Changes:

• Added:
  • Operations: listMyAssignments, listCompletedAssignments, listDueAssignments
  • Associated resource types and models for assignments added.

SDK Regeneration:

• All SDKs require regeneration due to the addition of new operations.

Breaking Changes:

• No breaking changes detected (no operations or fields were removed).

SDK Update Checklist:

• Go
• TypeScript
• Ruby
• Kotlin
• Swift

[cubic-dev-ai]

No issues found across 6 files

[Copilot]

Pull request overview

Adds Basecamp “My Assignments” support end-to-end (Smithy → OpenAPI/behavior model → generated Go client) and exposes it via a new Go service on AccountClient, aligning the SDK with the BC3 /my/assignments endpoints.

Changes:

• Extends the Smithy spec with GetMyAssignments, GetMyAssignmentsCompleted, and GetMyAssignmentsDue operations plus MyAssignment shapes.
• Regenerates openapi.json, behavior-model.json, and the Go generated client to include the new endpoints/models.
• Introduces MyAssignmentsService (List, Completed, Due) and registers it via AccountClient.MyAssignments().

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
spec/basecamp.smithy	Adds the three /my/assignments operations and MyAssignment-related shapes to the source spec.
openapi.json	Regenerated OpenAPI containing the new paths, params, and schemas.
behavior-model.json	Regenerated behavior metadata for retries/readonly for the new operations.
go/pkg/generated/client.gen.go	Regenerated Go client interfaces, request builders, response parsers, and models for the new operations.
go/pkg/basecamp/my_assignments.go	New MyAssignmentsService wrapper and clean models, including conversion from generated types.
go/pkg/basecamp/client.go	Adds myAssignments field and MyAssignments() accessor on AccountClient.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 16 out of 40 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jeremy]

Blockers

1. Go service boundary diverges from spec and every other SDK

The Smithy spec tags all three operations as Reports (spec/overlays/tags.smithy:198-200). Every generated SDK places them in ReportsService (TypeScript, Ruby, Swift, Kotlin). But Go creates a brand new MyAssignmentsService (my_assignments.go:11) exposed via AccountClient.MyAssignments() (client.go:1283), with hook labels using Service: "MyAssignments" instead of Service: "Reports".

The existing Go ReportsService (reports.go) already has AssignedTodos, OverdueTodos, UpcomingSchedule — all under Service: "Reports". The new operations belong there too.

Impact: Cross-SDK API drift (Go: client.MyAssignments().List() vs everywhere else: client.reports.myAssignments()), and inconsistent observability labels for the same endpoints.

2. Smithy spec missing BadRequestError on GetMyAssignmentsDue

The upstream BC3 API docs state that an invalid scope value returns 400 Bad Request. The Smithy operation (basecamp.smithy:7496-7499) declares:

errors: [UnauthorizedError, ForbiddenError, RateLimitError, InternalServerError]

BadRequestError is absent. Since this spec is the source of truth, it should declare the documented error. No SDK has test coverage for the invalid-scope path — tests should assert SDK-specific error semantics (error codes, message content), not just 400 status presence.

---

Design decision needed before regeneration

3. MyAssignmentPerson vs Person — source model inconsistency

Commit dedb521e says "Replace MyAssignmentPerson with Person for consistency" but only changed Go's hand-authored SDK layer. The Smithy model still defines MyAssignmentPerson as a narrow three-field shape (basecamp.smithy:7560-7566: id, name, avatar_url). Every generated SDK still exposes this separate type.

The full Person shape (basecamp.smithy:1238) is much broader (~18 fields). Go now uses Person for Assignees but only populates 3 fields, leaving the rest zero-valued.

The decision: should assignees on my-assignments stay narrow (MyAssignmentPerson) or widen to the shared Person type? Either is valid, but all SDKs need to match. This must be decided before regeneration to avoid doing downstream churn twice.

---

Fix checklist

• Move the three methods from MyAssignmentsService into ReportsService (reports.go)
• Remove MyAssignmentsService struct, NewMyAssignmentsService, and AccountClient.MyAssignments() from client.go
• Change hook labels from Service: "MyAssignments" to Service: "Reports" on all three methods
• Add BadRequestError to GetMyAssignmentsDue errors list in basecamp.smithy:7499
• Regenerate OpenAPI and all downstream artifacts
• Add invalid-scope tests in Go, TypeScript, and Ruby (asserting error codes/messages, not just status)
• Decide MyAssignmentPerson vs Person at the Smithy level; make all SDKs match

---

Secondary observations

• MyAssignmentRef dual-purpose struct: Existing ReportsService uses distinct Bucket and Parent types (in Assignable, reports.go:176-187). The new code introduces MyAssignmentRef which collapses both — Name for buckets, Title for parents, the unused field silently empty. If methods move to ReportsService, consider reusing the existing types.
• Go test gaps: Due(ctx, nil) untested; Completed/Due have no error-path tests; zero-value Bucket/Parent guard logic untested. Coverage gaps, not bugs.
• No Swift or Kotlin tests for the new report operations.
• Kotlin myAssignments() returns JsonElement for the grouped {priorities, non_priorities} response rather than a typed wrapper. Consistent with Kotlin generator conventions but weaker than other SDKs.

[robzolkos]

Took another swing at this in #213