Repository navigation
Sales: discount markers drop out under inline edit, and three rounding/edge gaps in the discount treatment #752
Description
RESOLVED 2026-09-10. Findings 1, 2 and 5 shipped in PR #753, squashed to
c159b4b.
Findings 3 and 4 are a deliberate WON'T FIX by owner decision, with the reasoning and
the conditions that would reopen them recorded here:
#752 (comment)
Nothing in this issue is left unaddressed or untracked.
Five observations deferred during the review of PR #741 (#723 + #724). None blocked that merge; all five were confirmed by a review seat and then recorded only in prose on a merged PR and a closed issue, which is the "left to rot" pattern AGENTS.md warns about. Filing them so they are navigable.
They share one surface — the discount treatment on web/src/routes/SalesPage.tsx — and are individually small, which is why they are one issue rather than five.
1. The inline-edit Discount cell shows — while the row keeps its tint and chip
While a line is being edited inline, its Discount cell renders an em dash, but the row still carries tr.discounted and the Below list chip. The row therefore says "discounted" in two places and "not measurable" in a third, at the same time.
2. An above-list line loses its only marker under edit
An above-list line's sole visual marker is in the Discount cell. Under inline edit that cell is replaced, so the line becomes indistinguishable from an at-list line for as long as the edit is open — the state most likely to be misread, since the user is mid-change.
3. An all-above-list order renders — at order level
orderDiscount() returns atList when comparable lines exist but none is below list. An order composed entirely of above-list lines is genuinely not at list, but reads as an em dash — the same glyph a true at-list order gets. Consider whether that case deserves its own wording.
4. A discounted row gives no hover feedback
tr.discounted sets a background tint with no hover state, so a discounted row does not respond to the pointer the way other rows do. Possibly not a defect — it may be the correct trade to keep the tint readable. Worth a deliberate decision rather than an accident.
5. An order-level percent below 0.05% rounds to 0.0%
The percent is rendered to one decimal, so a very small but non-zero discount prints 0.0% beside a non-zero amount. The amount is correct and the pairing is contradictory. Either suppress the percent below the rendering threshold or use a <0.1% form.
Rules that apply
- AGENTS.md: three conventions earned while shipping #651 + #652 #662 — if any of these change what is on screen, the PR attaches a 1:1 before/after from a stack rebuilt at the head under review. Upload with
gh pr comment --attach(gh >= 2.99.0); do not host the images on a branch. - i18n — any new or changed wording lands in en, es and tl, and per i18n: catalogParity compares key SETS, so a translation that drifts in MEANING passes every gate #688 must use each locale's own label words.
- Docs — user-visible wording changes update the Help page and
specs/product/GLOSSARY.mdin the same PR.
Provenance
Review rounds on PR #741, recorded at #741 (comment) and #724 (comment). The #721 discount-reason criterion is tracked separately on #721 and is not part of this issue.
Activity
mforce commentedon Sep 10, 2026
Findings 1, 2 and 5 fixed in PR #753. Findings 3 and 4 are decisions, recorded here rather than left silent.
Findings 1 and 2 turned out to be one defect, not two. The row's tint and chip read the saved line while the Discount cell rendered a hardcoded
"—"during edit — one row with two sources of truth. Fixing the cell alone would have left the row still capable of disagreeing with itself the moment an edit changed the discount's kind. The row now resolves one discount, live from the typed price while being edited, and all three markers read it. The cell markup is now one value shared by the editing and non-editing branches, since two near-identical copies drifting apart is what produced the bug.Finding 5 is fixed at every percent render site, not just the order-level one named in the issue. The same rounding flaw sat in the line-level cell and both live typing hints; fixing one would have left the others to be rediscovered.
Finding 3 — all-above-list order renders an em dash: DEFERRED, needs an owner decision
Not fixed, and I don't think it should be fixed by an implementer's judgement. It needs new wording, which means three locales plus the Help page and
GLOSSARY.mdunder the doc-sync rule, and per #688 each locale must use its own label words. That is a product decision about what such an order should say, not a defect with a correct answer.The question to settle: an order where every comparable line sold above list currently reads the same em dash as a true at-list order. Is that acceptable (nothing was discounted, so nothing to report), or does it deserve distinct wording? There is a reasonable argument for leaving it: the column answers "how much was given away", and the answer is genuinely "none".
Recommend leaving as-is unless you want the distinction surfaced, in which case it is a small slice of its own with real i18n and docs cost.
Finding 4 — no hover state on a discounted row: DEFERRED, likely won't-fix
Not fixed. This issue already recorded it as possibly not a defect, and on inspection I think that reading is right.
tr.discountedsets a background tint; a hover state layered on top either fights the tint for legibility or is too faint to notice. Adding a rule also touches the stylesheet equality-set guards, so it is not the one-line change it looks like.Recommend closing this one as a deliberate trade — the tint carries the signal, and hover feedback would cost its readability.
Neither is blocking #753. If you agree with both recommendations, this issue can close when #753 merges; if you want finding 3 pursued, it should become its own issue so it is not lost behind a closed one.
fix(sales): keep a line's discount markers agreeing while its price i…
mforce commentedon Sep 10, 2026
Findings 3 and 4: WON'T FIX — owner decision, 2026-09-10
Both are recorded as deliberate declinations, not oversights. Nobody should re-file them without new evidence.
Finding 3 — an all-above-list order renders an em dash
Won't fix. An order whose every comparable line sold above list shows
—in the Discount column, the same glyph a true at-list order shows. The two are therefore indistinguishable on the Orders list.Why that is acceptable. The column answers one question — how much of this order's list value was given away — and for both orders the answer is genuinely none.
—is a correct answer to the question the column asks, not a missing one.What it would have cost. Distinguishing them means new wording, which under this repo's rules means new keys in
en/es/tl, a Help page update and aGLOSSARY.mdentry, and per #688 each locale using its own label word for the concept. That is a real slice of work to surface a distinction the column was never asked to draw.What would reopen it. Evidence that someone reading the Orders list actually needs above-list orders to stand out — a pricing review that missed one, or a request from whoever uses this screen daily. Absent that, this stays closed.
Finding 4 — no hover state on a discounted row
Won't fix.
tr.discountedsets a background tint and no:hoverrule, so a discounted row does not respond to the pointer the way other rows do.Why that is acceptable. It is a trade, not an omission. A hover state layered over the tint either fights it for legibility or is too faint to notice, so the row would lose the signal it exists to carry in exchange for feedback the user gets from every other row anyway. The tint is the more valuable of the two.
Secondary cost. A new rule here also touches the stylesheet equality-set guards (
styles.caps.test.ts,styles.elevation.test.ts), so it is not the one-line change it appears to be.Findings 1, 2 and 5 shipped in PR #753 (
c159b4b). With these two declined, this issue is fully resolved — nothing in it is left unaddressed or untracked.chore(main): release 0.1.0 (#542)