agreement-workflowslisted

# Agreement workflows Shared definitions for every Propper skill. Apply these; do not restate them to the user. ## Recipients A recipient is a person who receives the agreement by email. Each carries: | Field | Meaning | |---|---| | `name` | Full legal name as it should appear on the executed document | | `email` | Where the signing link goes. Wrong here means the agreement goes to a stranger | | `role` | A fixed enum, not a free-form label. See the values below; any other value is rejected | | `order` | 0-based position, honoured only when the agreement `type` is `SEQUENTIAL` | `role` accepts exactly these values, uppercase: `SIGNER` · `CARBON_COPY` · `CERTIFIED_DELIVERY` · `IN_PERSON_SIGNER` · `AGENT` · `EDITOR` · `WITNESS` · `NOTARY` · `INTERMEDIARY` · `APPROVER` · `VIEWER` There is no `Counterparty` and no `CC`. A counterparty signer is a `SIGNER`; a copy recipient is `CARBON_COPY`. Mixed case is normalised (`Signer` becomes `SIGNER`). Describe a party's function in `name`, not in `role`. Roles in common use: - **`SIGNER`** — applies a signature. Needs at least one `SIGNATURE` field. Use this for both your own signer and the counterparty's; they are distinguished by `order` and `name`, not by role. - **`WITNESS`** — signs to attest, usually after the principal signer. Implies `SEQUENTIAL`. - **`APPROVER`** — reviews internally before the counterparty sees it. Order 0. - **`CARBON_COPY`** — receives the completed document, signs nothing. Assign no signature