Queued Can Change; Taken Cannot
Queued work still belongs to intake. The requester may fix a typo, replace an attachment, change a brain hint, or withdraw the delegation entirely. Those mutations are legitimate because no executor has accepted the premises yet.
Take is the transfer point. A live session claims the work, and the package becomes evidence about what that session was authorized to do. Editing notes or attachments afterward would create two histories: what the author actually saw and what the database now says they saw.
The safest API makes the rule structural. Mutation endpoints check status and return a conflict once the delegation is taken, landed, or abandoned. The UI disables controls as a convenience, but the engine is the authority; stale tabs and direct clients cannot bypass the transition.
Correction after take requires a new recorded event. Depending on product policy, abandon and requeue, or create a superseding delegation linked to the first. The original package remains intact so reviewers can explain why work stopped.
The Race at Take
A status check and mutation must happen under one writer transaction. If edit reads queued while take commits concurrently, only one operation may win. The loser receives the new state and chooses a visible next action.
Test this with two clients, not only sequential calls. The invariant is not “edit usually happens first”; it is “no successful mutation occurs after a successful take,” regardless of scheduling.