basecamp · jeremy · Jul 25, 2026 · chatgpt-codex-connector · Jul 25, 2026
diff --git a/go/pkg/basecamp/api-provenance.json b/go/pkg/basecamp/api-provenance.json
@@ -1,7 +1,7 @@
 {
   "bc3": {
     "branch": "master",
-    "revision": "ca1d34bcc40d2e2403a08bce9ead0d4b0276b1fa",
+    "revision": "d7bc88dafad61d15ad65a579f7a457037eca2b32",
     "date": "2026-07-24"
   },
   "compatibility": {

diff --git a/ruby/lib/basecamp/generated/metadata.json b/ruby/lib/basecamp/generated/metadata.json
@@ -1,7 +1,7 @@
 {
   "$schema": "https://basecamp.com/schemas/sdk-metadata.json",
   "version": "1.0.0",
-  "generated": "2026-07-23T19:34:23Z",
+  "generated": "2026-07-25T06:42:38Z",
   "operations": {
     "GetAccount": {
       "retry": {

diff --git a/ruby/lib/basecamp/generated/types.rb b/ruby/lib/basecamp/generated/types.rb
@@ -1,7 +1,7 @@
 # frozen_string_literal: true
 
 # Auto-generated from OpenAPI spec. Do not edit manually.
-# Generated: 2026-07-25T04:02:54Z
+# Generated: 2026-07-25T06:42:38Z
 
 require "json"
 require "time"

diff --git a/spec/api-gaps/README.md b/spec/api-gaps/README.md
@@ -71,13 +71,16 @@ making the absorption journey publicly auditable.
 > classification record (Stacks — renamed Folders in the product — are
 > web-only on both `four` and `master`).
 >
-> Provenance pin advanced to `ca1d34bc` (2026-07-24) as part of absorbing the
-> create-time `visible_to_clients` contract. The single commit past #403's
-> `338b7a11` pin — bc3 #12398 ("Disable Vips support for Matlib files":
-> `config/initializers/vips.rb`, its loader-policy test, and `bin/test-in-container`)
-> — is a reviewed no-op for the SDK: an image-loader security policy and a
-> container test script, with no route, controller, doc, or modeled API contract
-> change.
+> Provenance pin advanced to `d7bc88da` (2026-07-24). The `ca1d34bc..d7bc88da`
+> range — 30 commits — is a reviewed no-op for the SDK. The breakdown accounts
+> for all 30: **26** UI/CSS/JS/lexxy commits (including their PR merge commits
+> #12208/#12399/#12400/#12401); the **3** duplicate-cookie migration code
+> commits (`88cb86d2a`, `52f1e9974`, `7d86f1d06`) that touch only
+> `app/controllers/concerns/authenticate/by_cookie.rb` (a session-cookie
+> concern) and its test; and the **1** merge commit of the cookie PR (#12335,
+> `d7bc88da` itself — the tip of the range). None of these makes a route,
+> controller, doc, or modeled API-contract change. The pin date is unchanged
+> (2026-07-24), so no SDK version bump.
 
 The detector also maintains [`allowlist.yml`](allowlist.yml) for routes
 classified as not-an-API-resource or absorbed under another entry. Allowlist

diff --git a/spec/api-gaps/dock-tool-create-contract.md b/spec/api-gaps/dock-tool-create-contract.md
@@ -3,6 +3,7 @@ gap: dock-tool-create-contract
 status: absorbed-in-sdk
 detected: 2026-05-25
 sdk_demand: medium
+bc3_pr: 12366
 smithy_refs:
   - "CreateTool (spec/basecamp.smithy:6874)"
 bc3_refs:
@@ -22,8 +23,9 @@ bc3_refs:
 > this entry records a live BC4→BC5 *contract change* on an existing route,
 > not new BC5 surface awaiting coverage. `absorbed-in-sdk` here means the SDK
 > absorbed the new create-by-type contract (basecamp-sdk#327, merged
-> 2026-07-22); upstream documentation still describes the removed contract
-> (tracked as bc3#12364).
+> 2026-07-22). The upstream doc tail is also closed: bc3#12366
+> (`8f938281`) rewrote `doc/api/sections/tools.md` for the `tool_type`
+> contract (superseding the earlier bc3#12364 tracking note).
 
 ## What's missing
 
@@ -51,9 +53,10 @@ but the request contract flipped between BC4 and BC5:
   the reporter's raw bucket-scoped clone request still succeeded — the
   reporter caught the contract mid-flip.
 
-What's missing, precisely: upstream `doc/api/sections/tools.md` (canonical
-since repatriation `056a356ee0`; synced to bc3-api) still documents the
-removed clone contract. The compatibility posture itself is settled by
+What was missing, precisely: upstream `doc/api/sections/tools.md` (canonical
+since repatriation `056a356ee0`; synced to bc3-api) documented the removed
+clone contract until bc3#12366 (`8f938281`) rewrote it for the `tool_type`
+contract. The compatibility posture itself is settled by
 release: **BC5 replaced BC4 in production, so there is no live BC4 backend**
 — `four` survives as the wire-format reference (`compatibility.bc3-four`)
 for BC4-era clients, not as a server anyone can call.
@@ -104,16 +107,17 @@ release (no live BC4 backend); the remaining tail is documentation.
 
 ## Implementation notes for BC3
 
-One upstream item, standalone (BC3 #11628/#11629 are merged, so this is a
-new follow-up, not an addition to that train): rewrite the create section of
-`doc/api/sections/tools.md` for `tool_type` + optional `title` (syncs to
-bc3-api). The current text documents a contract that 404s on `master` —
-tracked as bc3#12364. (A `four` compatibility shim is moot: BC5 replaced BC4
-at release, so there is no live BC4 backend to shim.)
+The one upstream item is now closed: bc3#12366 (`8f938281`) rewrote the
+create section of `doc/api/sections/tools.md` for `tool_type` + optional
+`title` (syncs to bc3-api), replacing the text that documented a contract
+which 404s on `master` (the earlier bc3#12364 tracking note is superseded).
+(A `four` compatibility shim is moot: BC5 replaced BC4 at release, so there
+is no live BC4 backend to shim.)
 
 ## SDK absorption plan when this lands
 
 Absorbed: basecamp-sdk#327 (CloneTool → CreateTool rename, bucket-scoped
 endpoint, `{tool_type, title?}` body, per-SDK create signatures + tests +
-conformance) merged 2026-07-22. The only remaining tail is the upstream doc
-rewrite (bc3#12364); no further SDK change is needed.
+conformance) merged 2026-07-22. The upstream doc rewrite (bc3#12366,
+`8f938281`) has since landed, closing the last tail; no further SDK change
+is needed.
diff --git a/spec/api-gaps/schedule-recurrence-writes.md b/spec/api-gaps/schedule-recurrence-writes.md
@@ -51,11 +51,14 @@ on the existing create/update endpoints:
   endpoint — it redirects to the entry's first occurrence, like Get a
   schedule entry does.
 
-**Server-hang warning**: never send `week_instance: 0`. BC3 currently spins
-computing occurrences for it (open BC3 **#12362**, "Reject recurrence
-schedules whose occurrences can't be computed", adds the rejection). Until
-#12362 merges, an SDK-side guard or enum constraint must make `0`
-unrepresentable.
+**`week_instance: 0` now rejected server-side**: BC3 **#12362**
+(`ec17b83c`, "Reject recurrence schedules whose occurrences can't be
+computed") merged and now rejects `week_instance: 0` (and other
+uncomputable schedules) at create time — previously it spun a worker
+indefinitely. An SDK-side guard is therefore **no longer mandatory**; `0`
+is a normal validation error on the wire, not a hang. Modeling `frequency`
+as an enum and bounding the recurrence integers remains good hygiene, but
+it is no longer load-bearing for hang avoidance.
 
 ## Why it matters
 
@@ -76,9 +79,10 @@ side already models `recurrence_schedule`).
 ## Implementation notes for BC3
 
 - Shipped in docs — `schedules/entries_controller.rb` handles the params.
-- #12362 (open) is the server-side guard for uncomputable schedules
-  (`week_instance: 0` et al.); silent-discard-on-invalid on create is
-  documented, not a bug.
+- #12362 (`ec17b83c`, merged) is the server-side guard for uncomputable
+  schedules (`week_instance: 0` et al.); it now rejects them at create time.
+  Silent-discard-on-invalid on create for *other* invalid recurrence shapes
+  is documented, not a bug.
 
 ## SDK absorption plan when this lands
 
@@ -87,8 +91,10 @@ side already models `recurrence_schedule`).
   before modeling, probe a live BC5 create with each frequency family and
   diff the echoed `recurrence_schedule` against the doc (the derived-fields
   and silent-discard semantics make doc-only modeling risky).
-- Model `frequency` as an enum (nine values above); constrain or guard
-  `week_instance` so `0` can't be sent while BC3 #12362 is open.
+- Model `frequency` as an enum (nine values above). BC3 #12362
+  (`ec17b83c`) has merged, so `week_instance: 0` is now a server-side
+  validation error rather than a hang; an SDK-side guard is optional
+  hygiene, no longer a hard requirement.
 - Status flips to `absorbed-in-sdk` with the absorption PR (which adds the
   Smithy refs).
 - Pairwise check: BC4 accepts the same create/update routes but recurrence

diff --git a/spec/api-provenance.json b/spec/api-provenance.json
@@ -1,7 +1,7 @@
 {
   "bc3": {
     "branch": "master",
-    "revision": "ca1d34bcc40d2e2403a08bce9ead0d4b0276b1fa",
+    "revision": "d7bc88dafad61d15ad65a579f7a457037eca2b32",
     "date": "2026-07-24"
   },
   "compatibility": {

diff --git a/swift/Sources/Basecamp/Generated/Metadata.swift b/swift/Sources/Basecamp/Generated/Metadata.swift
@@ -228,6 +228,7 @@ enum Metadata {
         "DeleteTemplate",
         "DeleteTool",
         "DeleteWebhook",
+        "DeleteWormhole",
         "DestroyGaugeNeedle",
         "DisableCardColumnOnHold",
         "DisableOutOfOffice",
@@ -285,6 +286,7 @@ enum Metadata {
         "UpdateUpload",
         "UpdateVault",
         "UpdateWebhook",
+        "UpdateWormhole",
     ]
 
     static func isIdempotent(for operationId: String) -> Bool {

diff --git a/typescript/src/generated/metadata.ts b/typescript/src/generated/metadata.ts
@@ -37,7 +37,7 @@ export interface MetadataOutput {
 const metadata: MetadataOutput = {
   "$schema": "https://basecamp.com/schemas/sdk-metadata.json",
   "version": "1.0.0",
-  "generated": "2026-07-23T19:34:22.062Z",
+  "generated": "2026-07-25T06:42:37.878Z",
   "operations": {
     "GetAccount": {
       "retry": {