if you've ever sent out a number that was wrong because of a query that looked fine, i'd like to hear what the query was. collecting these to turn into puzzles.

im wokring TsundereSQL, a visual novel where the answers are real SQL, graded on the sample data plus a few hidden sets using duckdb.

here's the one in the demo right now. page 2 of a december BTC trade list, ranked by price * quantity (quote currencies are mixed, which a real desk would yell about):

SELECT trade_id,
  CASE WHEN side = 'buy' THEN 'BUY FLOW' ELSE 'SELL FLOW' END AS flow,
  ROUND(price * quantity, 2) AS notional_value,
  STRFTIME(executed_at, '%Y-%m-%d') AS executed_on
FROM trades
WHERE base_asset = 'BTC'
  AND executed_at BETWEEN '2025-12-01' AND '2025-12-31'
  AND price * quantity > 50000
ORDER BY notional_value DESC, trade_id
LIMIT 10 OFFSET 10

passes the sample and two of the hidden sets. the third has a trade at dec 31 17:36. executed_at is a timestamp, so DuckDB casts '2025-12-31' to 2025-12-31 00:00:00 and that trade falls outside the range. it was the 4th biggest of the month. everything below it moves up one and page 2 comes back with 2 rows instead of 3, and the missing row is a dec 11 trade that got pushed onto page 1, so the two rows you do get look fine.

fix is a half-open range: executed_at >= '2025-12-01' AND executed_at < '2026-01-01'.

anything that can be checked by comparing result sets has a shot at becoming a level.

https://store.steampowered.com/app/5213730/