A ROUTE THROUGH IT
How to get there
Three slices, each shippable on its own, ordered so the cheapest thing that answers the complaint goes first and the one that cannot be dated goes last. Plus the ordering caption, which is the smallest item in the document and the only one already answered.
- Ships without any API change
- 1and it answers the complaint
- One DTO change
- 1four cheap fields
- Needs its own decision
- 3not one slice
- Blocked on elapsed time
- 190 days of history
Settle whether the card is a restyle or a data project. Jaya reads it as the same information; it is about half. That is a ten-minute conversation with the field list open, and it is the difference between an afternoon and a quarter.
First, the captionone line
say how the cards are orderedsmallest item here
The behaviour is already correct — sorted by unit count inside each band. The question was asked because nothing on screen says so. A caption on the band header, or a sort control if the order should be changeable, closes it.
Worth doing alongside slice 1 rather than as its own ticket.
Slice 1 — restyle on today’s datafront end only
rebuild the card with the seven fields that existno API change
The big health number, the four stat blocks, the model table, the badge. Every figure comes from AssetGroup as it is today, so this is manage-inventory.component.html and nothing else — no DTO, no swagger regeneration, no backend deploy.
This is the slice that answers the complaint. Jaya’s read is right that emphasis is doing most of the work; the proposed card mostly looks more informative because the numbers are large and grouped, not because there are more of them.
Ship it, put it in front of whoever wrote the annotation, and let the response decide whether slices 2 and 3 are worth their cost.
Slice 2 — the cheap fieldsone DTO change
vendorCount · avgAgeYears · per-model figures · the rollupextends what is there
Two aggregates on the existing group query, three more columns on topEquipment (units, at-risk %, end of support), and the “N other models” line from modelCount minus the four shown.
One DTO change, one swagger regeneration, one front-end restart. Nothing here needs a new data source.
Slice 3 — three separate decisionsnot one slice
Grouping these would hide that they fail for different reasons. Each is its own go / no-go.
why units are at riskneeds a decomposition
Past end of support, beyond useful life, unsupported OS, open recall — counted separately. Today atRisk is one number, so this is a question about whether the at-risk rule is already expressed as separable causes or as a single predicate. That answer decides whether it is a day or a fortnight.
open work orders & past SLAsource unconfirmed
Nothing near AssetGroup carries work orders, and “past SLA” is undefined. Confirm the data exists before this is scheduled at all — it is the one item that might not be buildable in this product.
the 90-day health trenddated from the snapshot, not the merge
A snapshot table and a daily job, then ninety days before it reads anything true. If the trend matters, start recording now and build the card around it later — the history is the long pole, and every day of delay is a day added to the end.
What I would flag on the ticket2 things
the estimate hides a schema changescope
“Make the card show more” reads as front-end work. One of its fifteen figures needs a new table and a cron; another needs a data source that may not exist. Both are invisible in the mockup.
the mockup is dark, the app is lightpresentation
The proposed design is rendered on a dark ground and the grid ships light. The layout is what is being proposed, not the palette — worth confirming, since the app’s own dark mode is a separate, mandatory treatment rather than a restyle.