Create Sowing Record

Record a crop sown on one paddock. "Sown with super" is ONE record: a seed line and a fertiliser line, plus a seed-treatment and an inoculant line when used. Creates the one task that is the record, with its typed sowing 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 sow, 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.

Each products line has a role: seed (variety, seed source, lot, germination, thousand-grain weight, rate), fertiliser (with placement with_seed or banded), seed_treatment (with grazing_whp_days and esi_days), inoculant (with inoculant_group, batch, expiry). A seed treatment's grazing interval sets the paddock's grazing status exactly like a spray does; fertiliser and inoculant lines never do. Completing a sowing sets the paddock's current crop to the seed line's variety, else crop. Never invent a variety, batch or withholding period.

Type each rate as the farmer said it in rate ("80 kg/ha", "400 mL / 100 kg seed"); it is kept verbatim and split into rate_value, rate_unit and rate_basis. A rate with a number and no unit is refused (422). A completed sowing with no seed line is refused (422, "A sowing needs a seed line"). A sowing 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.