root cause was after_commit :set_references (Article model) firing on the destroy commit: set_references calls reference → from_references.create, and CollectionAssociation#create raises that exact error because the owner is no longer persisted? after destroy. The orphan_strategy: :adopt theory was a red herring (adopt does updates, not creates; #148 was a leaf). Fix is one line: after_commit :set_references, on: [:create, :update] – reference cleanup on destroy is already handled by dependent: :destroy on from_references/to_references. Regression test reproduces the original error (red) and confirms the fix (green); full suite 436 green. No MCP change (the destroy_article tool was already correct – it just now works). Shipped v0.10.24 (prod polled live). The “orphaned article 148” was a false alarm: after_commit runs after the transaction commits, so the destroy! actually succeeded (row deleted) and the callback only raised afterward – the caller saw an error but the row was already gone. Verified on prod post-deploy: article 148 does not exist, 140 articles total (max id 155), zero dangling references rows and zero dangling action_text_rich_texts rows for record 148. Nothing to clean up.
BL-056
Shipped