feat(cli): align severity badges in finding tables - #122
Open
mldangelo wants to merge 1 commit into
Open
Conversation
`severity.padEnd(8)` is a no-op for INFORMATIONAL, which is thirteen
characters, so informational findings pushed their title five columns to
the right of every other severity and broke the table:
HIGH Short severity row
INFORMATIONAL Long severity row
The badge width and the two indents that line up beneath it were three
independent literals (8, 14, 14), so they only agreed while every label
happened to fit in eight columns.
Derive all of them from the label set and abbreviate INFORMATIONAL to
INFO. Both values are unchanged at 8 and 14, so only the informational
label differs; spelling the word out instead would cost every finding
title five characters, which matters most at the 48-column minimum.
mldangelo
force-pushed
the
fix/severity-badge-alignment
branch
from
July 30, 2026 13:43
e493e05 to
dc31734
Compare
This was referenced Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
src/scan-history-renderer.tspads the severity badge withseverity.padEnd(8). That is a no-op forINFORMATIONAL, which is thirteen characters, so informational findings push their title five columns right of every other severity:INFORMATIONALis a normal value, not an edge case — it is the longest key inSEVERITY_COLORSand it appears inDISPLAY_SEVERITIESinsrc/cli.ts. Any scan that reports an informational finding renders a broken table inscans compareandscans show.The underlying problem is that the badge width and the two indents that must line up beneath it were three independent literals —
padEnd(8),wrap(title, 14, ...), and a hardcoded 14-space path indent — plus two more at +2/+4 for the nestedLINKED FINDINGSblock. They agreed only for as long as every label happened to fit in eight columns.What this changes
All five are now derived from one place:
Both values are unchanged: width 8, indent 14. So the only difference in rendered output is the label itself,
INFORMATIONAL→INFO. Adding a longer severity in future automatically widens the column and moves every dependent indent with it, rather than silently breaking alignment again.The one judgment call — please confirm
I chose to abbreviate rather than widen the column to 13. Widening is the alternative and it keeps the full word, but it costs every finding title five characters: at the 48-column minimum, titles drop from 32 usable characters to 27, and finding titles are routinely 40–60 characters, so they would wrap considerably more.
INFOis unambiguous and the badge is a compact status column, so the trade seemed clearly worth it — but it is a user-visible label change, so say the word and I will switch to widening instead.This affects only the TTY history view. SARIF/CSV/JSON exports go through a different path and are untouched.
Known remaining limitation: an unrecognized severity longer than eight characters still misaligns. I deliberately did not truncate arbitrary values, since mangling a future legitimate severity name seemed worse than misaligning an anomalous one. (A related ordering bug for unknown severities — they sorted above CRITICAL because
indexOfreturns-1— is fixed in the companion PR below.)Testing / QA instructions
Baseline before this branch: 470 pass / 6 skip / 0 fail. After: 472 pass / 6 skip / 0 fail (two added tests).
Confirm the new tests actually catch the bug
The two added tests must fail against
main's renderer. Verify by reverting only the source and keeping the tests:Note that plain
git stashdoes not work for this check — the tests live in the same file, so stashing removes them too and you get a misleading6 pass / 0 fail.New coverage —
severity badge columnstarts every finding title at the same column— renders all five severities and asserts every title begins at the same offset, acrosscolor: false/trueand widths 48/96/120. Also asserts the path line beneath each badge lines up with the title above it, which is the indent coupling.keeps the badge column as wide as its widest label— asserts the exact stringINFO Informational findingand thatINFORMATIONALno longer appears.Existing tests are unmodified
All six pre-existing tests in this file pass untouched. They assert relative ordering via
text.indexOf(...)rather than badge text, which is why the label change does not churn them. Their exact-text assertions on other rows are the guard that indent 14 really did stay 14.Manual check
Note for maintainers
This file is also touched by PR "fix: keep scan history rendering total over workbench payloads". Different regions (badge padding and indents here; field accessors there), but whichever lands second may need a trivial rebase.