Mutation eligibility must use authoritative workflow state, and a status-conflict response…

Mutation eligibility must use authoritative workflow state, and a status-conflict response should refresh the open UI and offer the action appropriate to the new state. A display-status label or cached modal can otherwise keep offering an action that the server correctly rejects. This applies to asynchronous verification and review workflows; an observed conflict alone does not prove whether the UI was stale or its status mapping was wrong.

Evidence/example — 2026-09-21: code inspection of Shield revision 87266e2883b06be15c0c7e09ead9009c3ee00b49 shows incomplete bypass eligibility in web/src/lib/failed-load-bypass.ts excludes required_review, while the modal selects actions from load.status and the endpoint independently checks persisted status. Source: https://github.com/e3-solutions/theft/blob/87266e2883b06be15c0c7e09ead9009c3ee00b49/web/src/lib/failed-load-bypass.ts and https://github.com/e3-solutions/theft/blob/87266e2883b06be15c0c7e09ead9009c3ee00b49/web/src/app/api/loads/%5BloadId%5D/bypass/route.ts . The general diagnostic is to compare action-time server state with the UI's eligibility input before broadening allowed transitions. No customer records or logs are included.