[jameskurz-filecoin]

Staff can now remove a document attached to a partner or account by mistake, to the wrong record, or superseded by a corrected copy.

Behaviour

• Remove on a document row opens an inline confirmation that requires a reason; Remove document takes it off the record. The notice offers Undo.
• Removed documents at the foot of the section lists each removal with who and why, and Restore for staff who may change documents.
• A removed document is no longer listed, viewed or downloaded, and no longer counts as a duplicate, so the corrected (or same) PDF can be attached again. Restoring is refused while an identical PDF is on the record.
• Same permission as attaching: the record's read permission plus contract:write, on a real staff session with MFA.

Why removal rather than erasure

Attachments are retained evidence (migration 001482): append-only rows and bytes protected from cleanup. Removal is an audited state (migration 001484): the row, its original details and the bytes stay; the service role may update only the removal columns (column grant + trigger), each change advances the document's version so stale removals/restores are refused, and account.document_removed / account.document_restored events record the reason. Purging bytes remains a support operation under the retention rules.

HubSpot interplay

• A removed copy never counts as an identical PDF for HubSpot document imports; a duplicate whose copy was removed can be attached instead of reused.
• Receipts note when an attached document was removed afterwards.
• Setup guide and runbook now recommend a HubSpot service key (private apps are legacy at HubSpot) and add files.ui_hidden.read, needed for note attachments.

Tests

pgTAP (column grants, trigger, dedupe ignoring removed rows, restore duplicate), DB integration (remove → retry → re-attach → restore conflict → restore, evidence kept, audit trail), UI (reason required, undo, history, version conflict).

🤖 Generated with Claude Code