election_title: "BV2105-r2 — Favorite ice cream (Bloc STAR, 2 seats): the partial ballot, re-counted a year later"

scenario_description: |-
  The LH reference for BetterVoting test BV2105-r2 (election w3vvff), a deliberate
  RE-RUN of BV2105 (r4dqvd) on exactly the same four ballots — cast again so they
  are counted by today's tabulator rather than by the one that ran in 2025.
  Live results: https://bettervoting.com/w3vvff/results
  Frozen raw export: bv2105r2_w3vvff_ice_cream_recheck_bv_export.json.

  The four ballots — one of each KIND of ballot:

    Vanilla,Chocolate,Strawberry
    5,5,5     an all-5s ballot (loves everything)
    -,-,-     fully blank — a TRUE abstention
    1,-,-     Vanilla=1, the rest blank — a REAL (partial) vote
    2,5,4     a full ballot

  Winners: Chocolate, Strawberry — unchanged, and never in question. Chocolate
  takes seat 1; seat 2 is a Vanilla/Strawberry runoff tie broken by score,
  Strawberry 9 > Vanilla 8.

  WHY THIS ELECTION EXISTS. BV2105 reported nTallyVotes = 2 and nAbstentions = 2:
  it filed the partial "1,-,-" ballot as an abstention alongside the genuinely
  blank one.

  CITATION CORRECTION (2026-08-04). The library used to attribute that miscount
  to bettervoting#1056. Wrong: #1056 is a DIFFERENT defect on the same demo
  election — a 401 blocking JSON/CSV download and Race Details, introduced by the
  Editable Ballots work (#979) and correctly closed via #1058. They share only
  the BV2105 test-document name. The counting defect is a separate bug, filed
  2026-08-04 as bettervoting#1478.

  THE RESULT: THE MISCOUNT STILL REPRODUCES. Ballots cast through the live API on
  2026-08-04 come back nTallyVotes 2 / nAbstentions 2 — identical counts to the
  2025 run, with Vanilla's score again averaged over 2 ballots instead of 3.
  This file is the pinned correct count.

  IS IT A BUG OR THE POLICY? Stated fairly: bettervoting#884 made an ALL-EQUAL
  ballot an abstention, and a ballot bearing a SINGLE mark is trivially all-equal,
  so this may be that policy working as written. The counter-argument is that BV's
  own tally treats a blank as 0 — so "Vanilla 1, blank, blank" is really
  "Vanilla 1, Chocolate 0, Strawberry 0", which is NOT all-equal and strictly
  prefers Vanilla. Scope: partial ballots whose non-blank marks are all equal.
  Partial ballots with two or more distinct marks count correctly.

  WHY A NEW ELECTION WAS NEEDED (rather than re-fetching r4dqvd). Re-fetching the
  2025 election also returns 2/2, but r4dqvd is `closed` and its stored
  ElectionResult may simply be the tally computed back in 2025 — a re-fetch cannot
  tell "the bug is live" from "we are reading an old result." Only ballots cast
  through today's tabulator can, which is what w3vvff is.

  WHY NO OTHER CASE IN THE LIBRARY ANSWERS IT. The discriminating shape is a
  ballot whose non-blank marks are ALL EQUAL — here a single "1" — because that
  is what bettervoting#884's all-equal rule treats as an abstention. The only
  other 2026-minted export carrying a partial ballot is BV215 (26khr3), whose
  partial is "Ada 5, Bruno 1, blank": two DISTINCT marks, so it is counted either
  way and settles nothing.

  LH counts it correctly: 4 ballots, 1 abstention (only the fully-blank row),
  Vanilla total 8 (5 + 1 + 2). The dropped ballot only helped Vanilla, the seat-2
  loser, so the winners survive — this is a REPORTING/counting defect, not a wrong
  result. But a discarded cast ballot can flip a closer election.

# BetterVoting registry (machine-readable; the tabulation engine ignores these).
bv_test_id: BV2105-r2
bv_election_id: w3vvff
bv_results_url: https://bettervoting.com/w3vvff/results

num_winners: 2
voting_method: Bloc STAR
ballots: |-
  Vanilla,Chocolate,Strawberry
  5,5,5
  -,-,-
  1,-,-
  2,5,4

expected_winners:
  - Chocolate
  - Strawberry

# file: bv2105r2_w3vvff_ice_cream_recheck.yaml