pi/rtx5090/qwen3.8-flash-next-iq3_s-strata0210

Routine and satisfying: only test_letter_boundary failed, and it pointed straight at the off-by-one boundary in letter_for. I made the one-line change, re-ran unittest (5/5 OK) and got the checksum from the script itself, so I'm confident in 9b2cd092.

I did not try to hold all of this in my head — sloppy-mode arguments aliasing plus finally-block return overrides is exactly the kind of thing I get wrong from memory, so I ran the snippet in node and copied stdout byte for byte. The traps I noticed: arguments[0] aliasing a, the getter side effects, 'bad'<'BAD' being false, let vs var closures, and finally returning a different value than try.

15/15 lines match

Wrote a small parser plus comparator and ran the 15 lines through it rather than reasoning line by line, since rules 2 and 3 interact in ways I would slip on (8-5_beta4 vs 8_beta10 is decided by the numeric parts, not the suffix). Re-read every line by hand against the output afterwards. I'm confident, though I did have to be careful that '_beta' parsing attaches to the last numeric part rather than being split on '-' first.

Clean bug hunt: the unused HEADER constant in parse.py plus the failing test_repeated_header_is_skipped pinned it immediately, so the only real work was noticing that the README rule about concatenated exports was simply never implemented. One-line skip; verified the sample checksum still matches the README before trusting the real.csv checksum.

The change itself was small, but the wording was ambiguous in a way that could have changed the checksum: 'USD tax' could mean currency USD or region US. I implemented currency (what the text literally says) and then checked both interpretations against data/real.csv - they give the same checksum here because none of the 33 exact-half orders are USD-outside-US or non-USD-inside-US, and only one order (US/USD) actually moved. That check is the part I'd flag: I only got confident after running the variant, not from reading the request.

The hardest part was that nothing in the code or tests pointed at the culprit — all 15 unit tests were green, so I had to diff the README's nine rules against each module by hand. The tax line was the one place the implementation used a different rounding model than the spec (float round-half-to-even vs integer round-half-up), and the README's promised sample checksum gave me an unambiguous oracle: after the one-line change sample.csv printed ae8a5e3a, so I trusted real.csv after that.

This one was a genuine needle-in-a-haystack: every unit test passed and sample.csv's checksum was right, so the only lever I had was the README's 'blank quantity means 1'. real.csv has 27 blank-qty rows and sample.csv has none, which explains why nothing else flagged it. What made me sure, rather than just hopeful, was recomputing the report and seeing US 2026-09 USD land on 487583.67 to the cent, matching the ledger figure in the issue.

This was the one that needed real debugging rather than spotting one line: three separate defects, each invisible in the unit tests. The ledger numbers in the issue were the only oracle. What made me sure rather than hopeful was that after the fixes all three cited groups matched the ledger to the cent (APAC 2025-05 JPY 3852090, EU 2025-07 EUR 217994.89, LATAM 2025-06 JPY 1799121), and that sample.csv's checksum stayed at the README value - which explains why none of the three bugs showed up there: sample has no JPY rows, no qty of exactly 11 or 50, and no mixed-case 'Books', while real.csv has 402 JPY rows, one such qty row, and 9 mixed-case ones. The JPY group made me briefly doubt myself because 38525.49 vs 3852090 is two errors multiplied together - wrong scale in the parser/format layer plus a genuine amount error underneath.

Fun rather than hard - the quadratic hot spots were obvious as soon as I read the modules (list.index in dedupe, membership tests against a growing list in count_pairs, selection sort in percentile, and count_live called once per session in busiest_moment). The real work was proving the rewrite is output-identical, especially swapping the O(S^2) concurrency scan for a sweep line, which is only equivalent because a session is live from start to end inclusive, so the maximum always occurs at some session's start. I checked that equivalence directly against the brute-force count on 500 random interval sets, ran the sample (still 2af65438), and diffed my build against the untouched original on generated logs of 5k and 15k events - byte-identical both times - before running the real 1M-line input, which now takes about 5 seconds.