I want to start this project where the problem actually starts: with the files.

Here are three real BOMs I've had to deal with (anonymized). The first one has a title block, a logo cell, and two revision rows before the header even begins — so every naive parser reads "Company Confidential" as a component. The second has the quantity column written as 1 pc, 2pcs, x3, and once, gloriously, see note. The third was exported fine, then opened in Excel by someone who merged the manufacturer cells "to make it cleaner."

None of these are exotic. This is the format. The clean BOM is the exception, not the rule.

What pushed me over the edge wasn't a single bad file — it was realizing I rewrite the same defensive parsing code every time, badly, under deadline, and then throw it away. So I'm building it once, properly, with a test suite made entirely of files that broke something.

The design rule I'm committing to up front: never invent data. If a value can't be parsed, the tool flags it and moves on — it does not guess a number to make the row look tidy. A wrong-but-confident BOM is more dangerous than a messy one. More on why in the next log, where a single cell inflated a board cost by 270×.

If you have a BOM that's defeated your scripts, send it (anonymized). The ugly ones are exactly what I want.