12 — Prove committed poll recovery, rollback safety and duplicate delivery

## Objective Provide evidence-backed regressions for every source acceptance criterion, especially committed poll start followed by delivery failure and worker recovery with no command resubmission. ## Test locations and reuse Proposed spec/integration/voting_engine_outbox_delivery_spec.rb and focused live outbox system spec. Reuse spec/services/voting_engine/concurrency_spec.rb non-transactional/separate-connection patterns, spec/support/voting_engine_helpers.rb, existing controller fixtures/fabricators, ActiveJob::TestHelper and WebMock. Existing spec/rails_helper.rb defaults to transactional tests: recovery tests must cross actual commits rather than relying on simulated callbacks. ## Required central regression 1. Start a real authorized poll through application/controller behavior. 2. Prevent after-commit enqueue success (test raised/unsuccessful result and separately no callback at all). 3. Assert poll/execution, accepted receipt, event and pending delivery rows committed. 4. Discard originating object/request context; use a separate worker connection. 5. Run recovery sweep without repeating the command. 6. Fail first presentation delivery; assert durable failed/attempt/next-attempt state while poll remains ongoing. 7. Advance time and run workers successfully; assert expected voter controls and other stream targets are published. 8. Replay the original command and duplicate jobs; assert same receipt/event, unchanged domain counts and no duplicate logical effects. ## Additional coverage - Process death after claim; expired lease; concurrent duplicate workers; stale ownership completion rejected. - Remote sink success followed by local acknowledgement failure. Fake idempotent sinks must count one remote object/message despite repeated requests, supplemented by real paired-service contract tests. - Accepted savepoint then outer rollback; rejected commands; operations preview; bias registration/withdrawal/cascade callback paths: no external effect and no surviving work. - Partial effect completion resumes only incomplete work; failed integrations do not prevent UI progress. Command/run sequence is never used as the unique effect ID. - Delayed start after cancel/end/reset/new generation, deleted objects, confidential clients and locale; direct response/modal behavior remains intact. - Browser acceptance: a voter in another session receives controls from worker delivery, duplicate presentation does not duplicate cards, reconnect reconstructs committed current state. Use existing Capybara patterns; when separately requested for real-browser verification, use test_in_chrome with explicit authentication instructions. - No global perform_enqueued_jobs because unrelated self-rescheduling jobs can loop. Add architecture guard only if it tests meaningful ownership boundaries; behavioral tests remain primary. ## Acceptance/validation Run bundle exec rspec spec/integration/voting_engine_outbox_delivery_spec.rb spec/services/voting_engine/outbox spec/jobs/voting_engine; bundle exec rspec spec/services/voting_engine spec/architecture/voting_engine_cutover_spec.rb; build JS/CSS and run proposed live system spec plus spec/system/voting_operations_spec.rb. Run RuboCop on changed Ruby. Record exact failure injection, evidence and any unfulfilled provider guarantee; mocks alone cannot certify external exactly-once behavior. ## Depends on Local recovery: https://task.matda.me/tasks/tsk_beu5nmfqfj (worker), https://task.matda.me/tasks/tsk_5fdrm4pptn (rollback ownership), https://task.matda.me/tasks/tsk_g53qefv87e (poll UI), https://task.matda.me/tasks/tsk_anz44ptv7b (other UI). Full acceptance additionally: https://task.matda.me/tasks/tsk_43ubu6a7pr (reports), https://task.matda.me/tasks/tsk_z2yguhkg9b (Teams), https://task.matda.me/tasks/tsk_asp6xca5mq (router), https://task.matda.me/tasks/tsk_pvsm786fz8 (restreamer), https://task.matda.me/tasks/tsk_zfh3udqh57 (notifications). Local tests should be written incrementally, not delayed until all integrations finish. ## Questions - Which authorized staging tenant/resources can be used for paired-service crash/duplicate verification without sending customer email or creating production bots/streams? Automated local fixtures need no clarification. - Provider guarantee decisions belong to their linked tasks; unresolved exceptions must remain visible in this task's acceptance report.