What is wrong
components/post/SearchResults.tsx declares its own severity label map at the top of the file:
const SEVERITY_LABELS: Record<number, string> = {
1: "Minimal",
2: "Low",
3: "Moderate",
4: "Severe",
5: "Critical",
};
The canonical map already exists in lib/constants/severity.ts:
export const SEVERITY_LABELS: Record<1 | 2 | 3 | 4 | 5, string> = {
1: "Minor",
2: "Moderate",
3: "Significant",
4: "Severe",
5: "Catastrophic",
};
The two disagree on three of the five levels. So the search filter panel tells a user they are filtering for "Moderate to Critical", while the case page (app/(public)/case/[caseNumber]/page.tsx line ~84), the DamageLevel component, and the OG image route (app/api/og/[caseNumber]/route.tsx line ~71) call the same levels "Significant to Catastrophic". Every other consumer in the repo imports from lib/constants/severity.ts. SearchResults.tsx is the only file with a private copy.
Why it matters
Severity is the primary axis a reader filters and sorts this registry by. Two vocabularies for the same 1 to 5 scale makes the filter results look wrong even when they are correct, and the private copy will drift again the next time the labels are edited.
What to change
In components/post/SearchResults.tsx:
- Delete the local
SEVERITY_LABELS const (lines 14 to 20).
- Add
import { SEVERITY_LABELS } from "@/lib/constants/severity";.
- Fix the resulting types at the usage sites (lines ~198 and ~199).
minSeverity and maxSeverity are typed number, and the imported map is keyed by 1 | 2 | 3 | 4 | 5, so narrow them rather than reaching for any. Typing the two useState calls as SeverityLevel (also exported from lib/constants/severity.ts) is the cleanest route, and the button row already only ever produces values from [1, 2, 3, 4, 5].
Note that SEVERITY_STYLES in the same constants file carries a separate short vocabulary (MINIMAL, LOW, MODERATE, SEVERE, CRITICAL) used for dense listings. That one is deliberate. This issue is only about the long labels.
Verify
npx tsc --noEmit
npm run format
Then open /search, expand Filters, and confirm the severity caption now reads the same words as a case page.
Comment here to claim it and ask anything you are unsure about. You will usually get a reply within a day.
What is wrong
components/post/SearchResults.tsxdeclares its own severity label map at the top of the file:The canonical map already exists in
lib/constants/severity.ts:The two disagree on three of the five levels. So the search filter panel tells a user they are filtering for "Moderate to Critical", while the case page (
app/(public)/case/[caseNumber]/page.tsxline ~84), theDamageLevelcomponent, and the OG image route (app/api/og/[caseNumber]/route.tsxline ~71) call the same levels "Significant to Catastrophic". Every other consumer in the repo imports fromlib/constants/severity.ts.SearchResults.tsxis the only file with a private copy.Why it matters
Severity is the primary axis a reader filters and sorts this registry by. Two vocabularies for the same 1 to 5 scale makes the filter results look wrong even when they are correct, and the private copy will drift again the next time the labels are edited.
What to change
In
components/post/SearchResults.tsx:SEVERITY_LABELSconst (lines 14 to 20).import { SEVERITY_LABELS } from "@/lib/constants/severity";.minSeverityandmaxSeverityare typednumber, and the imported map is keyed by1 | 2 | 3 | 4 | 5, so narrow them rather than reaching forany. Typing the twouseStatecalls asSeverityLevel(also exported fromlib/constants/severity.ts) is the cleanest route, and the button row already only ever produces values from[1, 2, 3, 4, 5].Note that
SEVERITY_STYLESin the same constants file carries a separateshortvocabulary (MINIMAL, LOW, MODERATE, SEVERE, CRITICAL) used for dense listings. That one is deliberate. This issue is only about the long labels.Verify
Then open
/search, expand Filters, and confirm the severity caption now reads the same words as a case page.Comment here to claim it and ask anything you are unsure about. You will usually get a reply within a day.