Put a mob in a paddock.

A move is a record, not a field. There is no writable location anywhere on a mob: this endpoint writes one completed move_stock record carrying the origin, the destination and the composed line "Moved the merino wethers from Middle Run to Top 40", and current_paddock_id is derived from that record. So the property's diary can never disagree with its map, reopening the record un-places the mob, and removing the destination paddock un-places it too.

A POST rather than a PUT because it creates something. The origin is resolved server-side from wherever the mob is now, and may be none — the first move of a mob that has never been placed is the prototype's "Put in a paddock", and its sentence simply omits the "from" clause.

The response is the mob at its derived placement, with its counters already updated. The record itself is read back with the mob's board (a task read), which is what a client refetches anyway.

completed_at records a move after the fact. The record is always written, but the placement is still whatever the newest completed record says — so back-dating a move behind an existing newer one files the diary entry and leaves the pin where it was. The rejection below compares against the mob's placement today, not its placement on the supplied date.

The destination must be a live paddock on the mob's own property, and not the one the mob is currently in. Requires organization edit rights.

{
  "data": {
    "type": "mob"
  }
}