Question change — design, reporting and QA handoff
Scope: fictional online single-choice time preference poll for existing members. One completion per member. No response editing or offline collection. No real study was conducted.
Problem: split Weekday into daytime/evening without changing the meaning of earlier answers.
Fixture: earlier twenty=weekday8/weekend10/not sure2; new twenty=daytime4/evening6/weekend8/not sure2. Different members and periods. Exclude drafts and failed submissions.
Releases: preserve questions, choices and translations in immutable releases. Even a typo creates a new release. Retain identity only for verified-equivalent items; new meaning requires new question/choice items. Never overwrite historical wording with current labels.
Reporting: release-specific detail is default. New daytime4/20=20%, evening6/20=30%. Earlier weekday8 has uncollected detail, not zero or an inferred split. Common weekday18/40=45% requires equivalent meanings and an approved map. Weekend18 plus not sure4 reconciles40. Show periods, releases, denominator and mapping revision. No causal-impact claim.
Submission: look up identical prior operations first. For new requests, atomically check current release, option membership, required values, current access and previous completion with storage. Commit the response and retry record together, then send the receipt; delivery failure does not undo storage. Enforce one completion per member across tabs and new request keys.
Stale page: save nothing. Ask members to review changed questions and select again. Preserve only other answers with unchanged meaning and item identity. Typo-only changes still require a notice and resubmission. Failed new-form loading preserves old input and never announces receipt. Revised payload uses a new request key.
Retries: identical request/payload returns the original receipt within current access, with no added count. A changed payload with the same key is a conflict. A later release never migrates a completed response.
Race: an earlier write that commits first stays in its release once. Publication that commits first rejects an old first submission. Order publication and storage at one boundary.
Export: retain response-time release, question, choice and wording. Add the common category separately. Option removal and translation edits must not erase historical values. Mapping changes create a new reporting definition; keep the earlier definition reproducible.
Owners: planning=meaning/scope/alternatives; design=change and uncollected-detail notices; engineering=atomic storage/deduplication; QA=sequence and interface/record/report comparison; operations=publication and mapping reasons.
QA: execute the fourteen starting states and sequences in the article, recording screens, receipts, aggregates and exports. The flow and fixed scenarios are proposed design behavior, not completed backend integration tests.
Before reuse: settle actual meanings, multiple selection, response editing/deletion, offline collection, retention and access. Fill in accountable owners, applied releases and actual test results.