In the previous step, I made duplicate detection profile-specific.

[Previous article: profile-specific duplicate rules]

https://dev.to/fastapier/i-added-profile-specific-duplicate-rules-to-my-csv-intake-console-4-4pno

That improved the intake logic.

But there was still a practical problem:

an operator could be given the right result, and still not trust the screen.

So this update was about the operator view.

I cleaned up the parts of the console that matter when someone is trying to understand a staged import quickly:

headline run counts

row-by-row decisions

remediation context for blocked rows

run history with downloadable remediation packs

The goal here was not to make the UI “prettier.”

It was to make the intake state readable.

A staged run should immediately answer questions like:

How many rows are actually ready?

Which row is blocked?

Why was it blocked?

Can I export the blocked set and retry safely later?

Can I trace what happened across runs?

That is where intake systems usually…