Ten duplicate rows caught before publication

A generated open-source parts database provided a real test of the free Action: inspect the output, report exact duplicates, and block publication without guessing which records to rewrite.

What was checked

The public CDFER/jlcpcb-parts-database project generates a CSV and publishes it through GitHub Pages. Running the released CSV Preflight implementation against the live snapshot found 10 data rows that were byte-for-byte equivalent after CSV parsing. The report identified their row numbers; it did not delete or merge them.

The narrow proposed fix

Public pull request #11 adds a full-row drop_duplicates() call after the generator merges its data, then runs the Action before the Pages artifact is uploaded. On the reproduced snapshot, this reduced 1,583 rows to 1,573 and the validator reported no remaining structural issue.

Why exact duplicates are the safe first boundary

Rows that merely share a part number or description may still represent distinct records. Automatically merging near-duplicates would introduce a business rule that a structural validator cannot justify. This check reports exact repeated rows; the owning project decides whether and where deduplication belongs.

Reusable workflow pattern

1. Generate or update the CSV.
2. Run the Action using an immutable commit SHA.
3. Keep the issue report as an artifact even when validation fails.
4. Upload or publish data only after the check passes.

The complete copy-ready workflow is in the GitHub Actions guide. It validates one generic UTF-8 CSV up to 10 MiB on the runner, requires no API key, and does not upload the input. Passing checks CSV structure only; it does not guarantee an importer accepts the file.