change-processlisted

## Inputs - Frozen document path - Proposed change (reason + details) - User approval ## Outputs - Updated document with revision_history entry (change_process: true) - Scope changes→backlog.json PBI add/modify ## PO Mode (po_mode: "agent") When `.scrum/config.json.po_mode == "agent"`, every PO-approval prompt in the numbered Steps below re-targets to the `product-owner` teammate per `../../rules/scrum-context.md` § PO seat resolution; the ceremony shape is unchanged. The user-approval points are re-targeted as follows: | Step | Phrase in human mode | Agent-mode override | |---|---|---| | 3 | SM presents change request to user in natural language | SM sends `[<scope>] PO_DECISION_REQUEST kind=change_request options=[approve,reject] recommendation=<...>` with the frozen doc path, the proposed delta, the reason, and the affected PBI ids as payload. `<scope>` is `pbi-NNN` when a single PBI is affected, otherwise `sprint-N` or `product`. | | 4 | User approves or rejects | PO judges the request against `docs/product/vision.md` Scope In/Out and the measurable release criteria. Approval requires a concrete tie-back to a brief/vision clause; YAGNI applies otherwise (`../../agents/product-owner.md` § Decision principles). **Both approve and reject** are persisted by the PO via `.scrum/scripts/append-po-decision.sh`, and the resulting `dec_id` is echoed in the `PO_DECISION` reply — this is the PO's responsibility, not the SM's. | | 5 | If approved → update doc + revision_history