Workflow states and schedules

Read the parent order or process item and select the nested stage/task by its returned ID. Nested task mutations use task.version; stage mutations use stage.version; task creation/reordering uses the containing stage version; stage creation uses the parent version. IDs must match every path parent. See concurrency.

An open task can be completed, pinned/unpinned, edited or explicitly skipped. Complete/reopen and skip/unskip are distinct transitions: completion records work done, while skip marks it not required. Reopen restores work from completion; unskip restores required work. Completed/skipped values may be represented by the resource-specific status enum (do not assume all public DTOs use identical words). Parent lifecycle restrictions still apply: archived work is read-only and must be restored before workflow changes.

Stage completion requires its required tasks to be satisfied; do not force a stage complete merely because one task is done. Reopening/skipping stages can recompute which stage is active and dependent schedules. Invalid transitions return409 state_conflict with no partial edit; reread allowedActions/current state instead of blindly retrying. See 409 recovery.

Add/edit/delete/reorder task operations change only the copied instance workflow. A task can move one position up/down or, for moveOrderTask, into an owned destinationStageId at zero-based position. Do not combine direction with destination fields. A template key is provenance, not permission to edit the shared template.

Schedules use each endpoint's exact enum: none, manual, stage-deadline, shipment-relative and weekly modes have different effects. Read dates for calendar/working-day rules. Manual due dates and clearing use the schema's nullable fields. Shipment changes recompute shipment-relative tasks; stage activation changes inherited deadlines. Process-item recurrence accepts only stopOffsetDays and rejects conflicting schedule options.

Progress and Next Up/Attention are derived, read-only projections. After an action, reread the parent and queues; the response is not a guarantee that another writer has not since changed them. History contains semantic events with actor/request attribution; idempotent replay does not create a second event. See activity.