@@ -23,4 +23,4 @@ Skills-docs: no move in `skills/**`, which teaches no user-assignment verdict; `
 - **New: the hand-over.** `POST /api/v1/security/users/ID/assigned-work/transfer` (`client.security.assignedWork.transfer`) with `{ toUserId, objects? }` moves up to 500 records per call to an active user, each as an ordinary update under the caller's context, and answers per field what moved and what failed, plus how many remain. A banned, unknown or identical `toUserId` is refused before any write. Multi-valued user fields are counted but not transferred. Neither route touches the ban.
 - **`@objectstack/spec`.** `FieldErrorCode` gains `reference_user_banned`, with its message in `en`, `zh-CN`, `ja-JP` and `es-ES`.
 
-**FROM → TO.** A write that sets `assignee: 'BANNED_USER_ID'` → set it to an active user, or hand the banned user's records over with the transfer route first. An integration that reassigns work after a ban → call the transfer route, then repeat while `remaining` is above 0.
+**For a caller.** A write that names a banned user in a user field names an active one instead; the refusal names the field and the user. No stored metadata or row changes, so there is nothing for `objectstack migrate meta` to rewrite. An integration that reassigns work after a ban can call the transfer route and repeat it while `remaining` is above 0.