Card step updates wholesale-replace fields: `assign --step` wipes due_on; `step update --due` wipes assignees

[jeremy]

Observed on released v0.8.0 against production; still present in v0.8.1.

#496 fixed the 400 on step assignment by carrying the step title over, but
the round-trip stops there — the other mutable fields are still dropped, so any
single-field step mutation silently destroys the rest:

$ basecamp cards step create "Step with title and due date" --card <card> --in <project> --due 2026-08-14
# step: title set, due_on 2026-08-14

$ basecamp assign <step> --step --to me --in <project>
# ok: true — but due_on is now null (title preserved, assignee set)

$ basecamp cards step update <step> --in <project> --due 2026-08-14
# ok: true — due_on restored, but assignees are now [] (title preserved)

Correction: this is Rails-owned, not CLI-owned

This issue originally said "steps#update in BC5 replaces the recordable
wholesale, so the CLI owns preservation." The first half is right and the
second half is wrong. app/controllers/steps_controller.rb:

def update
  @recording.update! recordable: new_step
  @recording.replace_assignees find_assignees, notify: true

new_step is Step.new step_params — a fresh Step built from whatever the
request carried, so an omitted due_on produces one without a due date.
replace_assignees then runs unconditionally; with no assignee_ids key,
assignee_ids falls through to "".split(",") → [], so every assignee is
removed.

Both clears are performed by the server, from the absence of a key.
Omitting a field and explicitly clearing it are the same request on the wire,
so no client change reaches this — including pointerizing
UpdateStepRequest.DueOn in the SDK, since a nil *string is omitted from the
JSON and the controller clears on that omission regardless.

The only client-side workaround is read-modify-write on every mutation, which
is racy against concurrent edits, doubles the request count, and has to be
reimplemented by every API consumer.

Lane

1. BC3 Rails (blocking): make steps#update presence-aware, the way
   cards#update already is for assignees (update_assignees? guards on
   has_key?) and for unmentioned attributes (recordable.changing(...)).
   Filed as a communiqué in Ask BC3 for presence-aware card step updates #608.
2. SDK (dependent follow-up): pointer semantics on UpdateStepRequest,
   mirroring UpdateCardRequest (pointerized in v0.10.0) — what lets a client
   express omit-vs-clear once the server honours the difference. Inert until
   then.
3. CLI: nothing to change. internal/commands/cards.go and
   internal/commands/assign.go stay as they are pending the Rails fix.

A deployed BC3 fix stops the data loss for every already-installed v0.8.x
client, with no CLI or SDK release.

Predicted when #496 was verified (Jul 13); confirmed it survived into v0.8.0
and v0.8.1.

[pradhankukiran]

I confirmed this on the current main branch. I would like to work on a fix that preserves title, due_on, and assignee_ids across step updates. Is this available to take?

[jeremy]

Thanks for confirming. Please hold off on a CLI-side fix: the underlying API update contract is being made presence-aware for both card steps and cards. For JSON updates, omitted fields will remain unchanged; explicit null or [] will clear them, and a step title will become optional on update.

One correction: against current production, an assignee-only step body returns 400 rather than silently wiping fields. The CLI’s existing title carry-over from #496 must remain until the server change reaches production. An SDK compatibility release also has to land before that deployment; cleanup of the preservation reads and title workaround follows afterward.

[jeremy]

Fixed server-side. Both reported data-loss bugs are gone with no client release, and the CLI-side cleanup has now merged as #620 (5760ba3c).

What changed. A BC3 change (bc3#12521) made JSON step and card updates presence-aware: omitting a parameter now leaves it unchanged, an explicit null clears a due date, and an explicit [] still removes every assignee. The public contract is documented in bc3-api#431 — sections/card_table_steps.md now reads "this is a partial update — any parameter you omit is left unchanged," where it previously said the update replaces the step.

Verified against production (QA sandbox project; card created and trashed afterward):

action	request sends	result
assign --step	assignee_ids only	title and due_on survived
cards step update --due	due_on only	title and assignees survived
unassign --step (last assignee)	assignee_ids: []	assignees cleared; title + due_on survived

Rows 1 and 2 are exactly the two failures reported here. Row 3 settles a claim I raised and then withdrew on this thread: unassigning the last person does not silently no-op — the SDK builds its body as a map and guards on req.AssigneeIDs != nil, and the CLI's removeID returns a non-nil empty slice, so assignee_ids: [] does reach the wire.

Also confirmed on a todo-backed subtask, since those were the original report's context: PUT card_tables/steps/:id is one endpoint and one contract for both spellings, and a partial update there preserved title and due date identically.

What #620 did. Removed the title workaround at three call sites, including a dedicated CardSteps().Get in cards step update whose only purpose was fetching a title to send straight back. That echo was the residual bug: an unrelated assign would revert a title someone edited concurrently. It also retired the matching advice in skills/basecamp/SKILL.md, which was still telling agents to resend the title on raw step updates.

The ask that led here was #608.

Not fixed, and out of scope for this issue: the CLI still cannot express an explicit due-date clear — --due "" is indistinguishable from omitting the flag. Separately, SDK v0.12.0 encodes a card's clear by omitting due_on, which under the new semantics means "leave unchanged"; that's fixed upstream in basecamp-sdk#647 and needs an SDK release. Worth its own issue if anyone needs clears.

Closing.