Approval-path and step statuses use inconsistent legacy wording internally (WAIT, ACTIVE, SUCCESS, FAIL) that does not match the decision language users see in the product. This standardises the Postgres enums, the domain model and the internal templates on a single set of values:

• steps: WAITING, IN_PROGRESS, APPROVED, REJECTED, SKIPPED

• approval path: IN_PROGRESS, INCOMPLETE, APPROVED, REJECTED

No existing JSON response changes. The domain enums pin their serialized names, so v1, v2's status field and the internal Forge REST payloads stay byte-identical. The frontend therefore needs no changes and there is no lockstep backend/Forge deploy.

What changed

API

• v2 gains a decisionStatus field carrying the new values, on the approval and on all 7 status-bearing step types. The existing status field is kept, marked deprecated, and still returns the old values.

• v1 responses are unchanged.

• v2 request bodies accept both the old and the new spellings for status inputs (Definition.pageChangeReApprovalStatuses, CreateApprovalRequest), so existing integrations that POST SUCCESS/FAIL keep working.

Webhooks (contract change)

• stepStatus changes for non-terminal states only: WAIT becomes WAITING and ACTIVE becomes IN_PROGRESS. APPROVED and REJECTED were already being emitted and are unchanged.

Product surfaces

• Jira issue comments, Confluence page content and watcher notification emails move to the new vocabulary (internal Freemarker templates).

• The standalone web dashboard displayed a literal SUCCESS next to an already-migrated REJECTED; both now read APPROVED / REJECTED.

• The React UI is unaffected: it already rendered "Approved" / "Rejected" / "In progress" from a label map, independently of the enum spelling.

AI (behaviour change)

• The AI prompt context now describes statuses as Approved / Rejected / Waiting / In progress instead of Success / Fail / Wait / Active. The shipped system prompt is corrected to match. A tenant's own stored prompt template that branches on the old strings will silently take the else-branch; this degrades a prompt, it does not corrupt data.

Unchanged

• CSV export wording and Jira custom-field display text.

• Chart status bucket keys stay on the legacy values, because gadget drilldown is keyed on them.

Data

• Two Liquibase changesets rename the step_status and approval_path_status enum values. This is metadata-only: Postgres resolves enum literals by OID, so existing rows, column defaults and partial index predicates all follow the rename automatically. No row is rewritten and no approval or step changes its effective status.

Out of scope

• Removing the deprecated status field from v2 (a later cleanup once integrators migrate).

• Renaming the step-filter values (ACTIVE, SUCCESS, FAIL in StepsFilterStatus). These are a filter-mode enum rather than a status enum, they are not exposed on any public API, and their values are persisted untyped in the ap-saved-filters app property with no migration path. Step filtering continues to use the old names.

• Renaming the frontend FilterStepStatus enum, for the same reason.

Acceptance criteria

• Step and approval statuses are displayed with the new vocabulary throughout the product UI.

• v2 returns decisionStatus with the new values and still returns the old values in the deprecated status field.

• v1 responses are unchanged, and every existing JSON payload is byte-identical to before.

• v2 request bodies accept both old and new status spellings.

• Webhook payloads emit the canonical status values.

• Existing data is preserved: no approval or step changes its effective status as a result of the rename.

• No regression in existing integrations relying on the current status field.