feat(subtasks): add the Subtasks service and repin to bc3 5daa0911d3

AGENTS.md

@@ -27,7 +27,7 @@ Paths are from the repository root, since that is where you will be working.
 | **Python** | httpx via `HttpClient` | `python/src/basecamp/generated/services/*.py` |
 | **Rust** | reqwest via `HttpClient` trait | `rust/basecamp-sdk/src/generated/services/*.rs` |
 
-All `265` operations across the ~50-service per-SDK layer are generated. Hand-written code is limited to infrastructure: <!-- @operation-count -->
+All `273` operations across the ~50-service per-SDK layer are generated. Hand-written code is limited to infrastructure: <!-- @operation-count -->
 
 | Purpose | Location |
 |---------|----------|
@@ -94,7 +94,7 @@ Pull the andon cord when you see:
 
 All new API coverage starts in `spec/basecamp.smithy`. Before writing SDK code, add operations and shapes to the spec.
 
-`spec/basecamp.smithy` holds `265` worked operations. <!-- @operation-count --> Copy the nearest one rather than
+`spec/basecamp.smithy` holds `273` worked operations. <!-- @operation-count --> Copy the nearest one rather than
 working from a skeleton here: it shows the live conventions for naming, `@http` URIs,
 pagination traits and shape reuse, and it cannot drift from itself.
 

COORDINATION.md

@@ -9,7 +9,7 @@ live BC5 by the #11629 tooling. The historical server-side audit lived on the
 
 The SDK's conformance baseline is the pin in
 [`spec/api-provenance.json`](spec/api-provenance.json) — `bc3` `master`
-`c680233ba0` as of the 2026-09-02 sync. <!-- @bc3-pin -->
+`5daa0911d3` as of the 2026-09-15 sync. <!-- @bc3-pin -->
 That file is the only authority; quote it here rather than a remembered SHA.
 `make sync-api-version` now rewrites the marked line above from it, and
 `make doc-constants-check` fails if the two disagree — this sentence sat two

MIGRATING.md

@@ -11,6 +11,25 @@ what wrong behaviour you get if you ignore one. This file is that half.
 
 ---
 
+# Unreleased
+
+### Card steps: `RepositionCardStep`'s `position` is 1-based, and Go rejects 0
+
+bc3's `card_table_steps.md` said the reposition `position` was "Zero indexed"
+until BC3 #12659 corrected it to 1-based (1 = top); the server always counted
+from 1 through the same `reposition_to` a to-do uses, so nothing changed on
+the wire. The Smithy member doc now says so in every SDK, and Go's
+`CardStepsService.Reposition` refuses `position < 1` with a usage error where
+it used to refuse only negatives. A caller that sent `0` meaning "first" was
+sending a value outside the documented range all along; send `1`.
+
+The same PR is why there is a new `Subtasks` service (`ListSubtasks`,
+`GetSubtask`, `CreateSubtask`, `UpdateSubtask`, `CompleteSubtask`,
+`UncompleteSubtask`, `RepositionSubtask`, `DeleteSubtask`) and why `Todo`,
+`Card` and `Recording` carry `subtasks_count`, `subtasks_completed_count` and
+`subtasks_url`. Both are additive: a subtask is a `CardStep` on the wire, and
+the `CardSteps` operations keep working at their legacy card-scoped paths.
+
 # v0.20.0
 
 ### `listLineupMarkers` moves from the Automation service to the Lineup service

README.md

@@ -243,12 +243,12 @@ All SDKs provide:
 | Category | Services |
 |----------|----------|
 | **Projects** | Projects, Templates, Tools, People |
-| **To-dos** | Todos, Todolists, Todosets, TodolistGroups |
+| **To-dos** | Todos, Todolists, Todosets, TodolistGroups, Subtasks |
 | **Messages** | Messages, MessageBoards, MessageTypes, Comments |
 | **Chat** | Campfires (lines, chatbots) |
 | **Scheduling** | Schedules, Timeline, Lineup, Checkins |
 | **Files** | Vaults, Documents, Uploads, Attachments |
-| **Card Tables** | CardTables, Cards, CardColumns, CardSteps, Wormholes |
+| **Card Tables** | CardTables, Cards, CardColumns, CardSteps, Subtasks, Wormholes |
 | **Client Portal** | ClientApprovals, ClientCorrespondences, ClientReplies |
 | **Automation** | Webhooks, Subscriptions, Events |
 | **Reporting** | Search, Reports, Timesheets, Recordings |

SECURITY.md

@@ -203,14 +203,14 @@ tracing::info!(?safe, "response headers");
 ## Retry Behavior
 
 Retry eligibility is decided per *operation*, not per HTTP method. `behavior-model.json` classifies
-all `265` operations: the 130 GETs are retryable by method, and 92 mutations are flagged <!-- @operation-count -->
-`idempotent: true` — all 53 PUTs, all 27 DELETEs, and 12 POSTs (`CompleteTodo`, `PauseQuestion`,
+all `273` operations: the 132 GETs are retryable by method, and 97 mutations are flagged <!-- @operation-count -->
+`idempotent: true` — all 55 PUTs, all 29 DELETEs, and 13 POSTs (`CompleteTodo`, `PauseQuestion`,
 `SubscribeToCardColumn`, `Subscribe`, `EnableCardColumnOnHold`, `CreateBookmark`, `PrioritizeAssignment`,
-`SpotlightRecording`, `RecordProjectVisit`, `CreateBubbleUp`, `EnableProjectClients`, `CreateStreamTicket`). The other 43 POSTs are attempted exactly once. SPEC.md §7 specifies the
+`SpotlightRecording`, `RecordProjectVisit`, `CreateBubbleUp`, `EnableProjectClients`, `CreateStreamTicket`, `CompleteSubtask`). The other 44 POSTs are attempted exactly once. SPEC.md §7 specifies the
 three-gate algorithm and the per-SDK divergences.
 
 - **Reads (GET)**: retried with exponential backoff on 429/503 in every SDK. (HEAD is idempotent by method too, but Ruby's transport gates on `method == :get` specifically, so a HEAD would not retry there. The API surface has no HEAD operations today, so this is theoretical.)
-- **Naturally-idempotent mutations (PUT/DELETE) and the 12 flagged POSTs**: *are* retried on 429/503
+- **Naturally-idempotent mutations (PUT/DELETE) and the 13 flagged POSTs**: *are* retried on 429/503
   by Go (generated operation path), Python, TypeScript, Kotlin, Swift, and Rust. Retrying these cannot
   duplicate a resource, which is why the gate is idempotency rather than "is it a mutation".
   One PUT narrows its own set: `UpdateProjectClientAccess` declares `retry_on: [503]`, because its