How many risks to show can seem like a dashboard-design choice. Reading the manufacturing prototype’s historical correction record alongside its current query showed that the first decision is which complete population gets evaluated.
A correct function cannot inspect missing rows
The historical correction record describes limiting by due date before risk sorting. A correct risk function cannot evaluate rows already excluded. I treat that record as the earlier question, not a claim that the same bug remains today, and do not reuse historical test totals as this task’s evidence.
The current service aggregates performance by work order, evaluates and sorts the full target set, then paginates. Reading both states is necessary for an accurate production account. No actual work order or deadline is published; the story explains the sequence that preserves the result’s meaning.
Separate total counts from visible rows
The synthetic dashboard counts risk across supplied rows, sorts by risk then identifier, and applies the display limit afterward. Population, risk count, rows and has-more are distinct results. Two visible entries do not mean only two risks exist.
Risk is caller-declared here; the original deadline forecast is not reproduced. The source sorts risk, due date and identifier, while the independent example uses risk and string identifier. The shared contract isolates population-before-limit rather than claiming identical implementations.
Place the counterexample outside the early rows
Only the last three of one thousand synthetic rows are marked risky. With a display limit of two, the global count stays three and both shown rows are risky. Early truncation would miss that condition. Tests also confirm input order is preserved rather than changed in place.
Duplicate identifiers and non-boolean risk declarations fail. There is no default that treats missing risk as normal. The thousand-row example is a test scale, not a production performance guarantee or an actual factory’s inventory.
Connect a short list to complete exploration
A short representative view helps quick inspection, but it should not strand the remaining entries. The current source provides pagination after full evaluation. This small module only returns has-more, without a next-page server or filter state; an existing snapshot-query contract can support that separate integration.
Counts, conditions and pages also need one coherent observation basis. Old global counts beside a newer list could disagree. Verifying one memory result cannot establish a real snapshot-query workflow, so that responsibility remains explicit.
Separate calculation and query evidence
The original risk vectors and database audit belong to historical evidence. This task ran twenty-five new module tests covering population, quantities, calendar days and keypad state. Source and extraction passed, and actual inline handlers were tested with DOM stubs. No prototype server or operational database ran.
Reaching the final page still needs checks in the actual interface and data scale. Browser rendering and factory usability were not established here. The evidence is narrower: the independent functions honor their declared ordering and state contracts.
Change the question behind the representative view
Before strengthening a risk color, ask whether any risks were excluded. Separating query population from display scope helps a representative distinguish the whole situation from the portion currently visible. Brevity and complete access should be designed together.
The decision extends beyond manufacturing. Receivables, approvals and shortage lists also need an explicit selection population. Keeping snapshot consistency and population ordering as distinct responsibilities makes the question reusable in another website’s administration screen.