Campaigns and quests

Campaign and quest definitions can be edited from their list rows. Every save requires a change note, checks the version originally opened by the administrator, preserves the replaced definition as an immutable snapshot, and increments the current version. Two administrators cannot silently overwrite one another.

Campaign names, descriptions, status, and scheduling windows can evolve through normal versions. Quest structure—including its campaign, steps, progression mode, repeatability, completion limit, and reward—can be revised until the first member starts it. Pause and save a published quest before making one of those structural changes; this closes the activity route before the definition is replaced. After participation exists, those structural fields keep their original meaning and the service rejects structural changes; presentation, display order, and operational status can still receive new versions. Create a new quest when an already-used journey needs different progression or reward semantics.

Pro campaigns provide optional UTC-normalized availability windows. Quests may be standalone or campaign-bound, sequential or parallel, one-time or repeatable. Each step uses a canonical event, member resolver, exact target, and exact increment.

Completion can award points, grant an achievement, assign a rank, or provide no extra reward. Per-member locks and cycle-specific idempotency keys make concurrent delivery and retries safe.