Create Field Work Record

Record work done on one paddock that is not an input: cultivation, harvest, hay or silage cutting, slashing or mowing, rolling, burning or irrigation. Creates the one task that is the record, with its typed field-work child, and answers with that task exactly as GET /tasks/{id} would. The server sets the producer from the farm's owner, operation_type to fieldwork, capture_source to agent and operator from the signed-in user. area_ha defaults to the paddock's area. date defaults to today; a future date creates the open task instead of a completed record.

kind is cultivate, harvest, hay_silage, slash, roll, burn or irrigate. outcomes is one block per kind: harvest (crop, tonnes, yield_t_ha, moisture_pct, protein_pct, grade), hay_silage (bales, bale_type), irrigate (ml). Figures are numbers except crop, bale_type and grade; a figure the kind does not carry is refused. products is optional (a hay preservative).

Field work has no withholding of its own and never changes a paddock's status, but it is checked: the task's warnings say when a harvest is before a harvest withholding period ends, or hay or silage is cut before a grazing one ends (the fodder then carries that interval for a vendor declaration). A warning never blocks the write; read it from the response and tell the farmer. A field work record belongs to a paddock; a mob id is a 404 here.

Before calling, check listTasks with this paddock's asset_id and filter[status][]=completed for a same-date duplicate, and confirm the summary with the farmer. The MCP tool is refused until it is called again with confirm: true. If the call errors or times out, read the paddock's records back before retrying: a 502 or 504 can arrive after the write succeeded. Do not send broadcast or share_scope. Needs a grant that allows writing in the paddock's business. A 403 whose code is insufficient_access is that refusal; its detail names the business and the access that is missing. Photos. A file on disk is staged with createImageUpload, whose curl_example PUTs the bytes, and attached with image_upload_ids. Never base64-encode a local photo into a tool call. A public http(s) URL: pass image_urls. Only a tiny generated image (under about 100 KB decoded) uses image_base64s. One upload can be attached to several records until it expires. On update, image_mode defaults to append (add to the existing photos); replace swaps them all out; remove_image_ids deletes specific ones. If any image fails, the whole create or update is rolled back. The attaching call still needs confirm: true. createImageUpload and its PUT do not.