election_title: "BV2105 — Favorite ice cream (Bloc STAR, 2 seats): a partial ballot mis-filed as an abstention"

scenario_description: |-
  The LH reference for BetterVoting test BV2105 (election r4dqvd, "Favorite ice
  cream (Bloc STAR) - without end date"). Bloc STAR, 3 flavors, 2 seats, 4 ballots.
  Live results: https://bettervoting.com/r4dqvd/results
  Frozen raw export: bv2105_r4dqvd_ice_cream_bloc_bv_export.json.

  The four ballots:

    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 (both engines): Chocolate, Strawberry. Chocolate takes seat 1; seat 2
  is a Vanilla/Strawberry runoff TIE (1-1) broken by score — Strawberry 9 >
  Vanilla 8 — so BetterVoting's tieBreakType "score" and LH agree exactly.

  THE REGRESSION (counting, not tabulation). BetterVoting's summaryData reports
  nTallyVotes = 2 and nAbstentions = 2, i.e. it counts only the two FULL ballots
  and files BOTH the blank ballot AND the partial "1,-,-" ballot as abstentions.
  The LH engine counts 4 ballots with just 1 abstention (only the fully-blank
  row); the "1,-,-" ballot is a cast vote — LH's Score Distribution shows Vanilla
  with a real "1" and a total of 8. You can see BV dropped it: its per-candidate
  "score" is the average over 2 ballots (Vanilla (5+2)/2 = 3, not (5+2+1)/3), so
  the partial ballot never entered the tally.

  Same winners here (the dropped ballot only helped Vanilla, the seat-2 loser), so
  this is a REPORTING/counting regression rather than a wrong result — but a
  discarded cast ballot can flip closer elections. It is the opposite-direction
  sibling of BV15 / bettervoting#740: #740 DROPS abstentions from the displayed
  turnout; BV2105 mis-classifies a real partial ballot AS an abstention.

  CITATION CORRECTION (2026-08-04). This file used to credit the miscount to
  bettervoting#1056 and call it fixed. Both were 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. The two share only the BV2105 test-document name. The counting
  defect described above is a separate bug, filed 2026-08-04 as bettervoting#1478.

  The behavior is unchanged a year on. The re-check ran on 2026-08-04: the same
  four ballots, cast fresh through the live API so today's tabulator counts them,
  come back nTallyVotes 2 / nAbstentions 2 — identical to the numbers frozen
  here. That re-run is its own case, BV2105-r2 (election w3vvff,
  bv2105r2_w3vvff_ice_cream_recheck.yaml), which also explains why re-fetching
  THIS election could not have answered the question: r4dqvd is closed, so its
  stored ElectionResult may just be the 2025 tally.

  Likely root: bettervoting#884's rule that an all-equal ballot is an abstention.
  A ballot bearing ONE mark is trivially all-equal, so it falls through the same
  test — which would make this intended behavior rather than a coding slip. The
  counter-argument is that a voter who scores Vanilla 1 and leaves the rest blank
  HAS expressed a preference, because BV's own tally treats those blanks as 0.

  This file is therefore the 2025 BASELINE, and this LH reference pins the
  correct count (4 ballots, 1 abstention, 3 tallied, Vanilla total 8).

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

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

expected_winners:
  - Chocolate
  - Strawberry

# file: bv2105_r4dqvd_ice_cream_bloc.yaml