fix(output): compact mode truncates findings and fix groups without saying so
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 715
- Forks
- 145
- Avg merge
- 21h 39m
- Merged PRs (30d)
- 66
Description
Compact output truncates in two places and announces neither.
1. Finding blocks, capped at three
src/output/finding-display.ts:16-19:
const urgentLimit = options?.urgentLimit ?? 3;
const urgent = findings
.filter(finding => finding.severity === "critical" || finding.severity === "high")
.slice(0, urgentLimit);
On examples/juice-shop that prints 3 finding blocks out of 54. The selection is
also narrower than a plain "top 3": only critical and high are eligible, plus every
unknown-severity direct finding, so medium and low findings never appear as blocks at
all no matter how many there are.
The footer on that same run reports "34 urgent issues found", so the output states a
number and then shows three, with nothing connecting the two.
2. Fix-command groups, capped at three
src/output/printers.ts:918:
for (const section of plan.sections.slice(0, 3)) {
On examples/juice-shop the plan has six sections. Compact prints three and silently drops:
Medium severity parent updates within range
Low severity validated chain upgrades
Low severity parent upgrades
The only hint is the generic footer at src/output/printers.ts:1039, "Run with --verbose for fix plan, paths, and full table." That reads as an offer of more detail about what you have already seen, not as notice that three command groups were withheld. Nothing in the output distinguishes "this is the whole plan" from "this is the first half of the plan".
It is worse in combination with the summary line above it, which reports the full finding count. A reader sees the true total, sees two or three command groups, and has no reason to think the two do not correspond.
The truncation itself is right. Sections are ordered by severity, so what gets cut is always the least urgent, and compact output should stay compact. The problem is only that the cut is undisclosed.
Suggested fix
Both caps need a line saying what was withheld.
For findings, after the last block when more were suppressed:
Showing 3 of 54 findings. Run --verbose --all to see them all.
For command groups, after the last shown section when plan.sections.length > 3:
3 more command groups (medium, low). Run --verbose to see them.
Derive the counts and severities from what was actually hidden rather than hardcoding
them, so the message stays honest when the mix differs.
Worth deciding at the same time
Whether three is still the right cap. It predates several section kinds being added (validated-chain-upgrade, parent-update), so a plan that once produced three sections can now produce six for the same project. The cap has not moved with it.
Found while checking compact-mode behaviour ahead of the Open Source Friday demo on 2026-09-18. Not a regression from v1.35.0; the cap has been there for some time.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/output/finding-display.ts:16-19 and src/output/printers.ts:918, then run compact output against examples/juice-shop to reproduce both undisclosed caps. Add notices that report the hidden finding count and command-group count or severities, using the actual truncated data; verify the output distinguishes withheld content from the complete compact result.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100