the import a business can afford to run twice

Bringing a business's catalogue onto the platform in one upload is a different problem from editing it. The failure that actually hurts is not a wrong cell; it is a partly written catalogue somebody has to reconcile by hand, late, on the day the business opens.

The design chose whole-file refusal. A structural error in any row, or a violation of the stated product rules, means nothing is written at all, and the response carries every error found rather than the first. That second half is the difference between a file a person fixes in one pass and a file they fix one row per attempt until they stop.

Errors and warnings were separated deliberately: a warning is reported and the import proceeds, only an error stops it. So the answer to an upload is a report with four counts — created, updated, unchanged, problems — not a partial success nobody can describe afterwards.

What makes repetition safe is content comparison at the natural key inside the business: match on name, compare the row, update only what genuinely changed, leave the rest alone. Re-uploading an unchanged file is then a true no-op, confirmed by the platform's own change tracking declining to advance a version. That is what lets a business keep one file as its source of truth and re-send it after every edit.

Free column order and stable identifiers across imports are the small courtesies that make other tools' output work; an unsupported second file format is refused explicitly rather than silently accepted.

Cost: one bad row blocks a large, mostly correct upload.

What it proves: the team designed for the second import, not for the demonstration.