[Feature] Define Poll lifecycle transition and decision-reset semantics #2

New Issue

zemion · 2026-07-20T17:31:29+02:00

zemion commented

2026-07-20 17:31:29 +02:00

Problem

Poll documents reopening as an owned behavior, but the generic transition services do not define a state matrix or consistently maintain lifecycle metadata. Today a decided Poll can be opened or closed again while retaining decided_at and decided_option_id, and repeated transitions rewrite timestamps. Scheduling now protects its stricter domain workflow, but reusable Poll semantics need an explicit policy.

Decisions needed

Which transitions are valid among draft, open, closed, decided, and archived?
Does reopening preserve prior responses, close history, and the previous decision, or clear/supersede them?
May a decided Poll be re-decided directly, and if so what audit history must be retained?
Are repeated exact transitions idempotent no-ops or new auditable actions?
Is archive terminal, and is closing a draft valid?

Acceptance criteria after the policy is chosen

Encode one transition matrix in the Poll service and document it.
Clear, preserve, or supersede closed_at, decided_at, and decided_option_id consistently.
Make exact retries deterministic and prevent accidental timestamp rewrites.
Add service/API tests for every allowed and rejected transition.
Expose action availability/reasons to Poll consumers so UIs do not duplicate the matrix.

Context

Discovered while hardening govoplan-scheduling#4; Scheduling-specific transitions are already guarded independently and should not be loosened by this ticket.

## Problem Poll documents reopening as an owned behavior, but the generic transition services do not define a state matrix or consistently maintain lifecycle metadata. Today a decided Poll can be opened or closed again while retaining `decided_at` and `decided_option_id`, and repeated transitions rewrite timestamps. Scheduling now protects its stricter domain workflow, but reusable Poll semantics need an explicit policy. ## Decisions needed - Which transitions are valid among `draft`, `open`, `closed`, `decided`, and `archived`? - Does reopening preserve prior responses, close history, and the previous decision, or clear/supersede them? - May a decided Poll be re-decided directly, and if so what audit history must be retained? - Are repeated exact transitions idempotent no-ops or new auditable actions? - Is archive terminal, and is closing a draft valid? ## Acceptance criteria after the policy is chosen - Encode one transition matrix in the Poll service and document it. - Clear, preserve, or supersede `closed_at`, `decided_at`, and `decided_option_id` consistently. - Make exact retries deterministic and prevent accidental timestamp rewrites. - Add service/API tests for every allowed and rejected transition. - Expose action availability/reasons to Poll consumers so UIs do not duplicate the matrix. ## Context Discovered while hardening `govoplan-scheduling#4`; Scheduling-specific transitions are already guarded independently and should not be loosened by this ticket.

zemion commented

2026-07-22 03:26:20 +02:00

Codex State: done

Summary

Implemented the approved lifecycle transition matrix, reopening/history preservation, auditable direct re-decision, archive/unarchive, and idempotency-key semantics on remote main.

Verification

Lifecycle and transition tests pass as part of the Poll suite.

Next / Blocked

None; later transition-engine generalization belongs to configurable workflow work.

## Codex State: done ### Summary - Implemented the approved lifecycle transition matrix, reopening/history preservation, auditable direct re-decision, archive/unarchive, and idempotency-key semantics on remote main. ### Verification - `Lifecycle and transition tests pass as part of the Poll suite.` ### Next / Blocked - None; later transition-engine generalization belongs to configurable workflow work.

zemion closed this issue

2026-07-22 03:26:20 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-poll#2