Say what tools trash really does: delete or disable, never trash

Merged
JE
12d ago
+117-23

basecamp tools trash said it would "permanently trash a dock tool" and remove "the tool and all its content", and then reported "Tool N trashed". Basecamp does neither. DELETE /dock/tools/:id takes one of two paths, and neither one uses the trash (bc3 API docs, "Trash a tool", corrected in basecamp/bc3#13973):

  • Deleted: an external link, or a tool that is empty while the project has another tool of the same type. Items already in the trash don't count as content, archived and draft items do, and a Card Table counts only its cards. A deleted tool is destroyed with everything inside it about five days later. Until then, a deleted external link can be restored in the web app.
  • Disabled: every other tool, such as the only tool of its type or one with content. This is the same as tools disable, and tools enable brings it back.

Both outcomes return 204. A customer saw this through the MCP server: the project's original To-dos, Docs & Files and Chat were reported as trashed and restorable, but they had only been disabled. basecamp/basecamp-mcp-server#273 fixes the MCP reply.

Changes

  • The tools trash help now describes both outcomes and says how to tell them apart: run tools show <id>, and a deleted tool has status "deleted". The tools agent notes say the same in one line.
  • The summary now reads "Tool N removed from the dock (deleted or disabled)". A first breadcrumb points to basecamp tools show <id>.
  • The data key stays {"trashed": true}, so scripts that read it keep working. A comment at the call site explains why.
  • TestToolsTrashSummaryDoesNotClaimTrash pins the summary and the breadcrumb. It fails on main, where it gets "Tool 557 trashed" and no show breadcrumb.

Not in this PR

  • Reading the tool back to report which outcome happened. That is a behaviour change, and the MCP server made it in #273. The CLI could follow the same way.

MCP model sync (follow-up commits)

basecamp/basecamp-sdk#1031 is merged as d69e9669. This PR now pins the SDK at that commit with scripts/bump-sdk.sh, a pseudo-version since no Go release has been cut. It re-vendors internal/mcpserver/model from the commit with scripts/sync-mcp-model.sh, so the built-in MCP server's delete_tool now describes both outcomes. The catalog snapshot is regenerated, and nix/package.nix's vendorHash is updated for the new modules. The bump also brings in basecamp/basecamp-sdk#1028, which reads a pixel dimension one ulp off an integer as that integer. That is the SDK's only other Go change since v0.27.0.

Review

Our Codex review (gpt-6.1-sol, high) of the sync commit found nothing.

Codex (gpt-6.1-sol, high) made two findings, and both are taken. "Empty" now carries bc3's Card Table rule, so a table with columns and no cards counts as empty and gets deleted. The blanket "can't be restored" is gone, because a deleted external link can be restored in the web app until it's destroyed.