src/components/ui/skeleton.tsx-5-9 (1)

5-9: ⚠️ Potential issue | 🟡 Minor

Hide decorative skeletons from screen readers by default.

Line 5 renders a visual-only placeholder; add aria-hidden="true" so it isn’t announced by assistive tech.

Proposed fix

 function Skeleton({ className, ...props }: React.ComponentProps<"div">) {
   return (
     <div
       data-slot="skeleton"
       className={cn("animate-pulse rounded-md bg-muted", className)}
       {...props}
+      aria-hidden="true"
     />
   )
 }

As per coding guidelines, `src/components/**` and `**/*.tsx` must be reviewed for accessibility (ARIA labels/semantic accessibility checks).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/skeleton.tsx` around lines 5 - 9, Add aria-hidden="true" to
the visual-only placeholder div (the element with data-slot="skeleton" and
className={cn("animate-pulse rounded-md bg-muted", className)}) so screen
readers ignore it; ensure this default is applied even when props are spread by
either placing the aria-hidden attribute after {...props} or merging props to
set aria-hidden to true when not explicitly provided.

src/components/ui/toggle-group.tsx-43-43 (1)

43-43: ⚠️ Potential issue | 🟡 Minor

Avoid inline style for spacing variable in component code.

style={{ "--gap": spacing }} violates the no-inline-style component rule.

Prefer variant/class-based spacing tokens (e.g., data-spacing + class variants) instead of runtime inline style.

As per coding guidelines, src/components/**: “Review for React best practices: proper prop typing, accessibility (aria labels, keyboard navigation), memoization where appropriate, and no inline styles.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/toggle-group.tsx` at line 43, The inline style using the
CSS variable (style={{ "--gap": spacing }}) in the ToggleGroup component should
be removed; instead, map the spacing prop to a data attribute (e.g.,
data-spacing={spacing}) on the root element of the ToggleGroup and create
corresponding CSS/class variants that set --gap for each allowed spacing token.
Update the ToggleGroup component (toggle-group.tsx) to stop using inline style,
add/emit a typed spacing prop if not present, and add CSS rules or className
variants (e.g., [data-spacing="sm"], [data-spacing="md"], [data-spacing="lg"])
that assign --gap values so layout uses the CSS variable without runtime inline
styles.

src/components/stats/stat-card.tsx-62-70 (1)

62-70: ⚠️ Potential issue | 🟡 Minor

Replace inline color styles with class/token-based styling.

Inline style is used for icon and value color; this breaks the component styling rule.

A practical fix is to pass a semantic color class (e.g., text-category-wildfires) instead of raw hex and apply it via className.

As per coding guidelines, src/components/**: “Review for React best practices: proper prop typing, accessibility (aria labels, keyboard navigation), memoization where appropriate, and no inline styles.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/stats/stat-card.tsx` around lines 62 - 70, The component is
using inline style for color on the icon span and the value span; remove those
inline style usages and switch to class/token-based styling by accepting and
applying a semantic color class (e.g., colorClass or textColorClass) instead of
raw hex in the StatCard/StatCardProps (or the component that renders the icon
and value); update references to the prop in the icon span and the value span to
add the className (e.g., `${colorClass} shrink-0` and `${colorClass} text-sm
font-bold ...`) and ensure the prop is typed in StatCardProps and documented so
callers pass a semantic token like "text-category-wildfires" rather than inline
styles.

src/components/map/map-container.tsx-57-62 (1)

57-62: ⚠️ Potential issue | 🟡 Minor

Clear map context during cleanup to avoid stale map references.

Unmount cleanup resets isLoaded but leaves the provider’s map value untouched. Consumers can still hold/use a removed instance.

Suggested fix

     return () => {
       resizeObserver.disconnect();
       setIsLoaded(false);
+      setMap(null);
       map.remove();
       mapRef.current = null;
     };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/map/map-container.tsx` around lines 57 - 62, Cleanup currently
disconnects the ResizeObserver and removes the Leaflet map but leaves the
provider’s `map` value pointing at the removed instance; update the unmount
cleanup in map-container (where `resizeObserver`, `setIsLoaded`, `map.remove()`,
and `mapRef.current` are handled) to also clear the provider map reference by
calling the context updater (e.g. `setMap(null)` or the provider's equivalent)
so consumers cannot access a stale/removed map instance.

src/components/filters/category-filter.tsx-22-24 (1)

22-24: ⚠️ Potential issue | 🟡 Minor

Set type="button" on filter buttons.

Without an explicit type, these controls can submit surrounding forms unexpectedly.

💡 Proposed fix

           <button
             key={id}
+            type="button"
             onClick={() => onToggle(id)}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/filters/category-filter.tsx` around lines 22 - 24, The filter
buttons in the CategoryFilter component are missing an explicit type which can
cause them to submit surrounding forms; update the JSX for the button rendered
with key={id} and onClick={() => onToggle(id)} to include type="button" so it
won't act as a submit control, keeping the existing onToggle handler and id
usage unchanged.

src/components/filters/date-range-filter.tsx-33-37 (1)

33-37: ⚠️ Potential issue | 🟡 Minor

Fix the “All” option ARIA label wording.

For the All option, the current label resolves to “Show events from last All”, which is not screen-reader friendly.

💡 Proposed fix

-          aria-label={`Show events from last ${option.label}`}
+          aria-label={
+            option.value === 0
+              ? "Show events from all time"
+              : `Show events from last ${option.label}`
+          }

As per coding guidelines, **/*.tsx: "Review for accessibility (alt text, semantic HTML, ARIA labels), proper TypeScript typing, and no use of any type."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/filters/date-range-filter.tsx` around lines 33 - 37, The ARIA
label on ToggleGroupItem currently produces "Show events from last All" for the
All option; update the aria-label logic in the rendering of ToggleGroupItem (the
component using option.value and option.label) to conditionally use a different
string when option.value or option.label indicates the all option (e.g., if
option.value === 'all' or option.label.toLowerCase() === 'all' then set
aria-label to "Show all events" or "Show events from all time"), otherwise keep
the existing "Show events from last {option.label}" wording so screen readers
get an appropriate label.

src/lib/utils/format.ts-35-41 (1)

35-41: ⚠️ Potential issue | 🟡 Minor

Guard formatCoordinates against non-finite values.

NaN/Infinity currently pass through and can produce malformed output like NaN°N.

💡 Proposed fix

 export function formatCoordinates(coords: number[]): string {
   if (!coords || coords.length < 2) return "N/A";

   const [lng, lat] = coords;
+  if (!Number.isFinite(lng) || !Number.isFinite(lat)) return "N/A";
   const latDir = lat >= 0 ? "N" : "S";
   const lngDir = lng >= 0 ? "E" : "W";

As per coding guidelines, src/lib/**: "Review for proper TypeScript typing, error handling, and separation of concerns. API clients should handle errors gracefully."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/utils/format.ts` around lines 35 - 41, The formatCoordinates function
currently formats coords without validating numeric finiteness; update the guard
in formatCoordinates to also check that coords[0] and coords[1] are finite
numbers (e.g., use Number.isFinite on lng and lat) and return "N/A" if either is
not finite, then proceed to compute lat, lng, latDir, lngDir and the formatted
string only when both values are finite; reference the coords array and the
lat/lng variables in your fix.

src/components/ui/dialog.tsx-111-115 (1)

111-115: ⚠️ Potential issue | 🟡 Minor

Missing accessible label on DialogFooter close button.

The close button in DialogContent (lines 73-75) correctly includes <span className="sr-only">Close</span> for screen reader users, but the close button in DialogFooter lacks this accessible label. This inconsistency means the footer close button won't have an accessible name.

♿ Proposed fix to add accessible label

       {showCloseButton && (
-        <DialogPrimitive.Close render={<Button variant="outline" />}>
-          Close
-        </DialogPrimitive.Close>
+        <DialogPrimitive.Close render={<Button variant="outline" />} aria-label="Close">
+          Close
+        </DialogPrimitive.Close>
       )}

Alternatively, since the text "Close" is visible, it may already serve as the accessible name. However, adding aria-label ensures consistency with the icon-only close button behavior.

As per coding guidelines: src/components/**: "Review for React best practices: proper prop typing, accessibility (aria labels, keyboard navigation)".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/dialog.tsx` around lines 111 - 115, The DialogFooter close
button (DialogPrimitive.Close used with <Button variant="outline" />) is missing
an accessible label; update the DialogFooter close button to provide an
accessible name—either add a visually-hidden span (e.g., <span
className="sr-only">Close</span>) inside the Close button or add an explicit
aria-label="Close" on the DialogPrimitive.Close/Button so it matches the
DialogContent close button's accessibility; ensure you modify the DialogFooter
block that renders DialogPrimitive.Close and Button to include the chosen
accessible label.

CLAUDE.md-28-29 (1)

28-29: ⚠️ Potential issue | 🟡 Minor

Update action naming in structure docs to match the repo.

Line 28 says update-pre-commit, but the action in this PR is update-pre-commit-composite. Please align naming to keep the structure section accurate.

Suggested doc fix

-  actions/              # Composite actions (security-scan, update-pre-commit)
+  actions/              # Composite actions (security-scan, update-pre-commit-composite)

As per coding guidelines, CLAUDE.md: Verify that the documented structure, hooks, and CI/CD sections match the actual repository state.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@CLAUDE.md` around lines 28 - 29, Update the actions listing in CLAUDE.md so
the action name matches the repository: replace the documented
"update-pre-commit" entry under the actions/ section with
"update-pre-commit-composite" (i.e., ensure the actions/ comment line and any
other mentions of update-pre-commit are renamed to update-pre-commit-composite
to reflect the actual composite action introduced in this PR).

docs/adr/001-nextjs-over-spa.md-14-14 (1)

14-14: ⚠️ Potential issue | 🟡 Minor

Update ADR to reflect Next.js 16 instead of Next.js 15.

Line 14 documents "Next.js 15 with App Router" but the actual implementation uses Next.js 16.2.2 (per package.json). Update the ADR to match the current version.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/adr/001-nextjs-over-spa.md` at line 14, The ADR text currently states
"Next.js 15 with App Router" but the project uses Next.js 16.2.2; update the ADR
by replacing the phrase "Next.js 15 with App Router" with "Next.js 16 (16.2.2)
with App Router" (or similar wording reflecting v16), and scan the document for
any other occurrences of "Next.js 15" to make them consistent with the
package.json "next": "16.2.2" entry.

src/components/stats/stats-bar.tsx-36-42 (1)

36-42: ⚠️ Potential issue | 🟡 Minor

Make the total label follow the selected status.

This count is events.length, but the dashboard supports open | closed | all. When the user switches away from open, the card still says "Active Events" even though the dataset can be closed or mixed. A neutral "Events" label or a status prop would keep the copy accurate.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/stats/stats-bar.tsx` around lines 36 - 42, The "Active Events"
label is static but should reflect the current selected status (open | closed |
all); update the code that renders the StatCard (component: StatCard, props:
label, value currently set from events.length) to derive both the count and the
label from the selected status (e.g., selectedStatus or filterStatus): compute
value as the filtered count when status !== 'all' and set label to "Active
Events" for 'open', "Closed Events" for 'closed', and a neutral "Events" for
'all' (or alternatively pass the status into StatCard via a new status prop and
let StatCard pick the label). Ensure you reference the existing events array and
the selected status variable when computing the display count and label.

src/lib/hooks/use-events.ts-13-18 (1)

13-18: ⚠️ Potential issue | 🟡 Minor

Preserve the API route's error payload.

Every failure is flattened to the status code, so callers lose the proxy's actual message and upstream reason. Read the response body before throwing and fall back to the status only if parsing fails.

🛠️ Suggested change

 async function fetcher(url: string): Promise<EONETEventsResponse> {
   const response = await fetch(url);
   if (!response.ok) {
-    throw new Error(`Events fetch failed: ${response.status}`);
+    const errorBody = (await response.json().catch(() => null)) as
+      | { error?: string; message?: string }
+      | null;
+    throw new Error(
+      errorBody?.error ??
+        errorBody?.message ??
+        `Events fetch failed: ${response.status}`,
+    );
   }
   return response.json() as Promise<EONETEventsResponse>;
 }

As per coding guidelines, `src/lib/**`: "Review for proper TypeScript typing, error handling, and separation of concerns. API clients should handle errors gracefully."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/hooks/use-events.ts` around lines 13 - 18, The fetcher function
currently throws only the HTTP status, losing upstream error details; modify
fetcher to read the response body when !response.ok, attempt to parse JSON (or
fallback to text) to extract the API's error payload, and include that payload
(or the parsed message) in the thrown Error (fall back to `response.status` if
parsing yields nothing); keep the return type for successful responses as
Promise<EONETEventsResponse> and ensure the thrown Error message includes both
the status and the preserved payload for debugging.

src/lib/hooks/use-geojson.ts-13-18 (1)

13-18: ⚠️ Potential issue | 🟡 Minor

Preserve the API route's error payload.

Every failure is flattened to the status code, so callers lose the proxy's actual message and upstream reason. Read the response body before throwing and fall back to the status only if parsing fails.

🛠️ Suggested change

 async function fetcher(url: string): Promise<EONETGeoJSONResponse> {
   const response = await fetch(url);
   if (!response.ok) {
-    throw new Error(`GeoJSON fetch failed: ${response.status}`);
+    const errorBody = (await response.json().catch(() => null)) as
+      | { error?: string; message?: string }
+      | null;
+    throw new Error(
+      errorBody?.error ??
+        errorBody?.message ??
+        `GeoJSON fetch failed: ${response.status}`,
+    );
   }
   return response.json() as Promise<EONETGeoJSONResponse>;
 }

As per coding guidelines, `src/lib/**`: "Review for proper TypeScript typing, error handling, and separation of concerns. API clients should handle errors gracefully."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/hooks/use-geojson.ts` around lines 13 - 18, The fetcher function
flattens errors to just the status code, losing the proxy/API error payload;
update fetcher(url: string): Promise<EONETGeoJSONResponse> to read the response
body when !response.ok (attempt to parse JSON then text), extract an informative
message (e.g., body.message or raw text), and throw a new Error that includes
the upstream payload plus the status as a fallback if parsing fails so callers
of fetcher can see the proxy's actual error details.

.claude/hooks/post-edit.sh-21-23 (1)

21-23: ⚠️ Potential issue | 🟡 Minor

Use npx --no-install prettier to respect repo dependency scope.

The repo has .prettierrc but prettier is not in package.json dependencies. Running plain npx prettier can resolve to a globally installed version or trigger installation outside the repo's pinned setup. Use npx --no-install prettier to ensure the formatter only runs if explicitly available in the project, failing gracefully otherwise.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/hooks/post-edit.sh around lines 21 - 23, Update the post-edit Git
hook's npx invocation so it won't pull or use a global/preinstalled prettier; in
the case branch that currently calls npx prettier within
.claude/hooks/post-edit.sh (the block guarded by "if command -v npx > /dev/null
2>&1; then" and the pattern matching "*.ts | *.tsx | *.js | *.jsx | *.css)"),
replace the plain "npx prettier" call with "npx --no-install prettier" so the
hook only runs the repo-local/preinstalled prettier and otherwise fails
gracefully; preserve the existing redirection and "|| true" behavior so the hook
remains tolerant of missing formatter.

src/components/filters/source-filter.tsx-54-66 (1)

54-66: ⚠️ Potential issue | 🟡 Minor

Active-source badges lack keyboard accessibility.

The Badge elements are interactive (clickable to remove sources) but may not be keyboard-navigable. Screen reader and keyboard-only users cannot tab to these badges or activate them with Enter/Space.

Consider using a <button> element instead, or add role="button", tabIndex={0}, and onKeyDown handlers.

♿ Proposed fix to improve keyboard accessibility

-            <Badge
-              key={source}
-              variant="secondary"
-              className="cursor-pointer text-xs"
-              onClick={() => handleToggle(source)}
-            >
-              {source}
-              <span className="ml-1" aria-hidden="true">
-                &times;
-              </span>
-            </Badge>
+            <button
+              key={source}
+              type="button"
+              onClick={() => handleToggle(source)}
+              className="inline-flex items-center rounded-md bg-secondary px-2 py-0.5 text-xs text-secondary-foreground hover:bg-secondary/80 cursor-pointer"
+              aria-label={`Remove source filter: ${source}`}
+            >
+              {source}
+              <span className="ml-1" aria-hidden="true">
+                &times;
+              </span>
+            </button>

As per coding guidelines: src/components/**: Review for accessibility (aria labels, keyboard navigation).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/filters/source-filter.tsx` around lines 54 - 66, The active
source badges rendered in the activeSources.map are interactive but not
keyboard-accessible; update the Badge usage (or replace it with a semantic
<button>) so each item that calls handleToggle(source) is focusable and
activatable via keyboard: either render a button element styled like the Badge
or add role="button", tabIndex={0}, aria-label (e.g., `Remove ${source}`) and an
onKeyDown handler that calls handleToggle(source) on Enter/Space; ensure the key
prop, variant, className and displayed text remain the same and that
handleToggle is used for both click and keyboard activation.

src/components/layout/sidebar.tsx-12-37 (1)

12-37: ⚠️ Potential issue | 🟡 Minor

Remove unused categories prop from interface and component.

The categories prop is declared in SidebarProps (line 14) but is never destructured or used anywhere in the component. The parent component still passes it, so removing it requires updating both the interface definition and the call sites in dashboard-shell.tsx.

Changes needed

1. In src/components/layout/sidebar.tsx: Remove categories: string[] from the SidebarProps interface
2. In src/components/layout/dashboard-shell.tsx: Remove categories={filters.categories} from both the <Sidebar> component (line 114) and <MobileDrawer> component (line 144)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/layout/sidebar.tsx` around lines 12 - 37, Remove the unused
categories prop: delete "categories: string[]" from the SidebarProps interface
and remove it from the Sidebar component props if present; then update call
sites by removing categories={filters.categories} passed into <Sidebar> and
<MobileDrawer> in the dashboard-shell (remove those prop occurrences so the
component invocation matches the new SidebarProps). Ensure you only remove the
prop declaration and prop usage — do not alter other prop names or handler
signatures like onCategoryToggle, onEventSelect, or isLoading.

src/components/layout/header.tsx-63-80 (1)

63-80: ⚠️ Potential issue | 🟡 Minor

Expose the auto-refresh state with aria-pressed.

This control behaves like a toggle, but assistive tech currently only gets a changing label. Add aria-pressed={isAutoRefresh} so the current on/off state is announced.

As per coding guidelines, **/*.tsx: Review for accessibility (alt text, semantic HTML, ARIA labels), proper TypeScript typing, and no use of any type.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/layout/header.tsx` around lines 63 - 80, The toggle button for
auto-refresh (Button wrapping RefreshCw) currently only updates aria-label;
update the Button element to include aria-pressed={isAutoRefresh} so screen
readers receive the boolean pressed state, keeping the existing aria-label and
onClick handler (onRefreshToggle) intact; ensure the prop uses the same
isAutoRefresh boolean and that TypeScript types accept the boolean ARIA prop on
the Button component.

src/__tests__/lib/format.test.ts-20-31 (1)

20-31: ⚠️ Potential issue | 🟡 Minor

The cases named here aren't actually exercised.

Line 21 still passes a full timestamp, so the “date without time component” path is untested, and Lines 28-30 never assert the time portion of formatDateTime. A formatter that drops time entirely would still pass this suite.

As per coding guidelines, **/*.test.ts: Review for test quality: meaningful assertions, edge cases covered, no flaky patterns, proper mocking.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/__tests__/lib/format.test.ts` around lines 20 - 31, Update the tests so
they actually exercise the intended branches: for the formatDate test (function
name formatDate) pass a date-only string (e.g., "2025-12-25") instead of a full
timestamp so the no-time component path is exercised and still assert the
expected "Dec 25, 2025" pattern; for the formatDateTime test (function name
formatDateTime) assert the time portion as well (e.g., check for "14:30", "2:30
PM", or the specific time format your formatter returns) in addition to the
existing year and month checks so any implementation that drops or mangles the
time will fail.

src/app/globals.css-149-157 (1)

149-157: ⚠️ Potential issue | 🟡 Minor

Stylelint will fail on currentColor keyword casing.

Lines 149, 153, and 157 use currentColor; your configured rule expects lowercase currentcolor.

💡 Suggested fix

   0% {
-    box-shadow: 0 0 0 0 currentColor;
+    box-shadow: 0 0 0 0 currentcolor;
     opacity: 1;
   }
   70% {
-    box-shadow: 0 0 0 10px currentColor;
+    box-shadow: 0 0 0 10px currentcolor;
     opacity: 0;
   }
   100% {
-    box-shadow: 0 0 0 0 currentColor;
+    box-shadow: 0 0 0 0 currentcolor;
     opacity: 0;
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/globals.css` around lines 149 - 157, The CSS uses the `currentColor`
keyword with uppercase C which violates stylelint's casing rule; update the
color keyword instances used in the `box-shadow` declarations (the three
occurrences shown in the keyframe steps 0%, 70%, 100%) to the lowercase form
`currentcolor` so they match the configured lint rule.

src/components/ui/command.tsx-165-165 (1)

165-165: ⚠️ Potential issue | 🟡 Minor

Use data-selected instead of data-checked for item selection state.

The check icon visibility is bound to group-data-[checked=true], but cmdk uses data-selected to indicate selection (focus) state on Command.Item. Change to group-data-[selected=true] so the icon displays when items are selected.

Reference: https://dip-cmdk.mintlify.app/components/item

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/command.tsx` at line 165, The CheckIcon's visibility class
is using group-data-[checked=true] but cmdk marks selected/focused Command.Item
via data-selected; update the className on the CheckIcon (the JSX inside
Command.Item) to use group-data-[selected=true] instead of
group-data-[checked=true] so the icon becomes visible when an item is selected.

src/components/ui/input-group.tsx-57-63 (1)

57-63: ⚠️ Potential issue | 🟡 Minor

Click-to-focus logic misses textarea controls and is easy to override accidentally.

Line 61 only targets input, so addons in textarea groups won’t focus the control. Also, because ...props is spread after onClick, caller-provided onClick replaces this behavior entirely.

💡 Suggested fix

 function InputGroupAddon({
   className,
   align = "inline-start",
-  ...props
+  onClick,
+  ...props
 }: React.ComponentProps<"div"> & VariantProps<typeof inputGroupAddonVariants>) {
   return (
     <div
@@
-      onClick={(e) => {
-        if ((e.target as HTMLElement).closest("button")) {
+      onClick={(e) => {
+        onClick?.(e)
+        if (e.defaultPrevented) return
+        if (
+          e.target instanceof Element &&
+          e.target.closest("button, [role='button'], a, input, textarea, select")
+        ) {
           return
         }
-        e.currentTarget.parentElement?.querySelector("input")?.focus()
+        e.currentTarget.parentElement
+          ?.querySelector<HTMLElement>("input, textarea")
+          ?.focus()
       }}
       {...props}
     />
   )
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/input-group.tsx` around lines 57 - 63, The click-to-focus
handler in src/components/ui/input-group.tsx currently only queries "input" and
is placed before the spread {...props} so callers can accidentally override it;
update the onClick on the wrapper used in the InputGroup component to (1) search
for broader focusable controls (e.g., querySelector with "input, textarea,
[contenteditable=true]" or a small helper that finds the first focusable form
control) instead of only "input" and (2) compose with any incoming onClick prop
rather than being replaced — either move {...props} before your onClick or call
props.onClick(e) inside the handler so caller clicks are preserved; reference
the existing onClick block and the spread of {...props} in the component when
making the change.

src/components/ui/card.tsx (1)

36-47: Consider allowing semantic heading element for CardTitle.

CardTitle renders as a <div>, which lacks semantic meaning for assistive technologies. Screen reader users rely on heading elements for navigation. Consider accepting an as prop to allow consumers to specify the appropriate heading level.

♻️ Optional: Add polymorphic `as` prop for semantic flexibility

-function CardTitle({ className, ...props }: React.ComponentProps<"div">) {
+function CardTitle<T extends React.ElementType = "div">({
+  className,
+  as,
+  ...props
+}: { as?: T } & React.ComponentPropsWithoutRef<T>) {
+  const Component = as || "div"
   return (
-    <div
+    <Component
       data-slot="card-title"
       className={cn(
         "font-heading text-base leading-snug font-medium group-data-[size=sm]/card:text-sm",
         className
       )}
       {...props}
     />
   )
 }

Usage:

<CardTitle as="h2">Event Details</CardTitle>

Alternatively, the current pattern (delegating semantic responsibility to consumers via composition) is also valid for shadcn/ui-style libraries. As per coding guidelines, **/*.tsx files should be reviewed for semantic HTML.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/card.tsx` around lines 36 - 47, CardTitle currently always
renders a <div>, which is not semantic; update the CardTitle component to accept
an optional polymorphic as prop (e.g., as?: keyof JSX.IntrinsicElements |
React.ElementType) defaulting to "div", type props generically so props are
ComponentPropsWithRef<typeof As> and preserve className and {...props}, and
render the chosen element (const As = as ?? "div") while keeping
data-slot="card-title" and using cn for classes; ensure the component accepts
ref if applicable and export the updated signature so callers can use <CardTitle
as="h2">.

SECURITY.md (1)

11-16: Consider adding response time expectations and data handling policies.

The documented security practices are solid. For enhanced clarity and completeness, consider adding:

• Expected response time for vulnerability reports
• Data handling policy (particularly for NASA EONET API data)
• HTTPS/TLS requirements for API communications
• Security update policy (e.g., critical patches within 48h)

📋 Example enhancement

 ## Security Practices
 
 - No secrets or credentials are committed to this repository
 - Dependencies are scanned weekly via Dependabot and Trivy
 - Static analysis runs on every PR via Semgrep
 - Environment variables are used for all sensitive configuration
+- All external API communications use HTTPS/TLS
+- We aim to respond to vulnerability reports within 48 hours
+- Critical security patches are released within 7 days of disclosure

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@SECURITY.md` around lines 11 - 16, Update the "Security Practices" section in
SECURITY.md to add explicit operational requirements: add a bullet specifying
expected response times for vulnerability reports (e.g., acknowledgement within
24h and remediation/triage SLA), a short data handling policy for NASA EONET API
data (storage, retention, access controls, and anonymization rules), a
requirement that all API communications use HTTPS/TLS, and a security update
policy stating timelines for critical/important patches (e.g., critical within
48h). Modify the existing "Security Practices" bullets under the "Security
Practices" heading to include these new points so reviewers can find them
alongside the current items about secrets, dependency scanning, and static
analysis.

.github/actions/security-scan/action.yml (1)

27-31: Consider guarding SARIF upload against missing file.

The upload step runs with if: always(), but if the Trivy step fails or is cancelled before writing the output file, the upload will error because trivy-results.sarif won't exist. You may want to add a file existence check or use if: always() && hashFiles('trivy-results.sarif') != ''.

♻️ Proposed fix

     - name: Upload Trivy results to GitHub Security
       uses: github/codeql-action/upload-sarif@0d579ffd059c29b07949a3cce3983f0780820c98 # v4.32.6
-      if: always()
+      if: always() && hashFiles('trivy-results.sarif') != ''
       with:
         sarif_file: trivy-results.sarif

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/actions/security-scan/action.yml around lines 27 - 31, The SARIF
upload step ("Upload Trivy results to GitHub Security") currently runs
unconditionally (if: always()) and will fail when trivy-results.sarif is
missing; change the step's condition to run only when the SARIF file exists (for
example replace or augment the if with a check like
hashFiles('trivy-results.sarif') != '' or a file-existence check) so the upload
action (uses: github/codeql-action/upload-sarif@...) is skipped when the Trivy
output was not produced.

src/components/map/map-provider.tsx (1)

33-39: Consider memoizing the context value to prevent unnecessary re-renders.

The context value object is recreated on every render of MapProvider, which can cause all consumers of useMap() to re-render even when none of the values have changed.

♻️ Proposed fix using useMemo

 import {
   createContext,
   useCallback,
   useContext,
+  useMemo,
   useState,
   type ReactNode,
 } from "react";

 // ... existing code ...

+  const value = useMemo(
+    () => ({ map, setMap, isLoaded, setIsLoaded: setIsLoadedCb }),
+    [map, setMap, isLoaded, setIsLoadedCb]
+  );
+
   return (
-    <MapContext.Provider
-      value={{ map, setMap, isLoaded, setIsLoaded: setIsLoadedCb }}
-    >
+    <MapContext.Provider value={value}>
       {children}
     </MapContext.Provider>
   );

As per coding guidelines, src/components/**: Review for memoization where appropriate.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/map/map-provider.tsx` around lines 33 - 39, The context value
object passed into MapContext.Provider is recreated each render (value={{ map,
setMap, isLoaded, setIsLoaded: setIsLoadedCb }}), causing unnecessary consumer
re-renders; wrap the value in useMemo inside the MapProvider (memoize an object
containing map, setMap, isLoaded, setIsLoaded: setIsLoadedCb) with a dependency
array [map, setMap, isLoaded, setIsLoadedCb] and pass that memoized value to
MapContext.Provider so consumers only update when one of those actual values
changes.

src/lib/constants/categories.ts (1)

40-40: Strengthen CATEGORY_IDS typing to preserve category key safety.

Object.keys widens to string[]; narrowing to known keys improves downstream type checks.

Suggested typing refinement

-export const CATEGORY_IDS = Object.keys(CATEGORIES);
+export const CATEGORY_IDS = Object.keys(
+  CATEGORIES
+) as Array<keyof typeof CATEGORIES>;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/constants/categories.ts` at line 40, CATEGORY_IDS is currently typed
as string[] because Object.keys widens to string[]; narrow it to the actual keys
of CATEGORIES by casting or using a typed helper so downstream code gets correct
keyof typing. Update the export of CATEGORY_IDS to use a type assertion like "as
Array<keyof typeof CATEGORIES>" (or use a generic keys<T>(obj: T) helper that
returns Array<keyof T>) so CATEGORY_IDS and references to CATEGORIES preserve
the specific category key types.

src/components/ui/dialog.tsx (1)

73-74: Consider adding aria-hidden to decorative icon.

The XIcon is decorative since the adjacent sr-only span provides the accessible name. Adding aria-hidden="true" ensures screen readers skip the icon entirely.

♿ Optional improvement

         <XIcon
+          aria-hidden="true"
         />

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/ui/dialog.tsx` around lines 73 - 74, The XIcon is decorative
and should be ignored by assistive tech; update the XIcon element in the dialog
component to include aria-hidden="true" (e.g., <XIcon aria-hidden="true" ... />)
so screen readers will skip it, leaving the adjacent sr-only span as the
accessible name.

.markdown-link-check.json (1)

10-14: Consider adding 172.16.0.0/12 private range to ignore patterns.

The configuration ignores 10.x and 192.168.x private networks but omits the 172.16.0.0/12 range (172.16.x.x through 172.31.x.x), which is also commonly used in internal/Docker networks.

Proposed addition

     {
       "pattern": "^https?://192\\.168\\."
+    },
+    {
+      "pattern": "^https?://172\\.(1[6-9]|2[0-9]|3[0-1])\\."
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.markdown-link-check.json around lines 10 - 14, Add a new ignore pattern to
.markdown-link-check.json to cover the 172.16.0.0/12 private range: introduce a
"pattern" entry that matches URLs starting with http(s)://172.16.x.x through
172.31.x.x (for example using the regex
"^https?://172\\.(1[6-9]|2[0-9]|3[0-1])\\."). Place this new pattern alongside
the existing "pattern" entries for 10.x and 192.168.x so the link checker also
skips the entire 172.16.0.0/12 range.

.github/copilot-instructions.md (1)

16-16: Clarify the src/-only rule to avoid blocking valid repo changes.

Line 16 is too absolute; this repository intentionally includes CI/docs/security/config code outside src/. Consider scoping this to application code only.

Proposed wording

-- All code in `src/` directory
+- Application/runtime code should live in `src/`; repository config/docs/workflow files may live outside `src/` as needed

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/copilot-instructions.md at line 16, The rule "All code in `src/`
directory" is too broad; update the wording to scope it to application source
code only (e.g., change the phrase "All code in `src/` directory" to
"Application source code should reside in the `src/` directory; CI, docs,
security, and config files may live outside `src/`") so the guideline permits
valid repo files outside src while still enforcing where application code
belongs.

src/app/page.tsx (1)

1-23: Consider adding metadata export for SEO.

This page is missing a metadata export, which is a Next.js App Router best practice for SEO and social sharing. The dashboard would benefit from proper page title and description.

📝 Suggested metadata export

 import { Suspense } from "react";
 import { DashboardShell } from "@/components/layout/dashboard-shell";
+import type { Metadata } from "next";
+
+export const metadata: Metadata = {
+  title: "Earth Events Dashboard",
+  description: "Real-time visualization of natural events from NASA EONET API",
+};

 function DashboardLoading() {

As per coding guidelines, src/app/**: "Review for Next.js App Router best practices: proper use of Server vs Client Components, metadata exports, loading/error boundaries, and data fetching patterns."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/page.tsx` around lines 1 - 23, Add a Next.js App Router metadata
export to this page by declaring and exporting a top-level metadata object
(e.g., export const metadata) that includes at minimum title and description for
the dashboard and optionally openGraph/social fields; place it alongside the
existing DashboardLoading and Home exports so the page uses the provided
title/description for SEO and social sharing. Ensure the metadata keys are plain
strings (title, description) and can include openGraph.title,
openGraph.description, and twitter.card if desired, without changing the
DashboardLoading component or the default Home export.

src/components/layout/mobile-drawer.tsx (2)

41-45: Consider controlling the active snap point.

activeSnapPoint={undefined} makes the drawer fully uncontrolled. If you need to programmatically control the drawer state (e.g., close it when an event is selected), you may want to lift this to controlled state.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/layout/mobile-drawer.tsx` around lines 41 - 45, The
Drawer.Root is currently uncontrolled because activeSnapPoint={undefined}; make
the drawer controlled by adding component state (e.g., useState for
activeSnapPoint) and pass that state into Drawer.Root's activeSnapPoint prop,
update it via the drawer's change callback (e.g., onActiveSnapPointChange or
similar event) and set the state to the desired snap (e.g., 0 to close) when
events occur (like an item selection) so you can programmatically open/close the
drawer.

---

13-38: Same unused categories prop as in Sidebar.

The categories: string[] prop (line 15) is declared in MobileDrawerProps but not destructured or used. Consider removing it for consistency with the fix in sidebar.tsx.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/layout/mobile-drawer.tsx` around lines 13 - 38, The
MobileDrawerProps interface declares a categories: string[] prop that is never
used in the MobileDrawer component; remove the unused categories property from
MobileDrawerProps and from any places that pass it (or if callers rely on it,
instead add categories to the MobileDrawer parameter destructure and use it
consistently). Update the MobileDrawerProps interface and the MobileDrawer
function signature to match (remove categories from the type and from component
props) and adjust any callers that pass categories so types remain consistent.

src/components/events/event-timeline.tsx (1)

21-28: Consider a more stable key than array index.

Using index as the React key (line 28) can cause issues if the list changes. While the sorted array is derived and non-interactive, a composite key would be more robust.

♻️ Suggested stable key

-          <div key={index} className="relative">
+          <div key={`${geo.date}-${index}`} className="relative">

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/events/event-timeline.tsx` around lines 21 - 28, Using the
array index as the React key in the sorted.map callback is unstable; change the
key on the returned <div> to a stable, unique identifier derived from the geo
item (for example use a composite like `${geo.type}-${geo.id ||
geo.properties?.id || geo.properties?.name}` or another unique field) inside the
sorted.map so that the mapping in the component (sorted.map, geo,
formatCoordinates) uses a deterministic key instead of index; ensure any
fallback uniqueness is consistent across renders.

src/app/layout.tsx (1)

39-41: overflow-hidden on body may affect accessibility in edge cases.

While intentional for a full-screen dashboard layout, overflow-hidden on <body> could prevent scrolling if content overflows unexpectedly (e.g., high zoom levels or dynamic content). Ensure internal scroll containers (like ScrollArea) handle all overflow scenarios.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/layout.tsx` around lines 39 - 41, The body has overflow-hidden which
can block scrolling in edge cases; remove or conditionalize the
"overflow-hidden" from the <body> class in layout.tsx and instead ensure an
internal scrollable container (e.g., wrap children in a dedicated ScrollArea or
a div with overflow-auto) inside NuqsAdapter or the main layout component so all
overflow is handled there; update NuqsAdapter or the immediate container around
{children} to provide proper focusable/keyboard accessible scroll behavior and
test zoom/dynamic-content scenarios to confirm scrolling still works.

src/components/layout/dashboard-shell.tsx (2)

63-70: Unchecked type assertion on URL-sourced status value.

The status as "open" | "closed" | "all" assertion assumes the value from URL parameters is always valid. Malformed or tampered URLs could pass invalid values.

Consider validating before casting, or handle this validation in useFilters.

🛡️ Defensive validation

  const handleStatusChange = useCallback(
    (status: string) => {
+     const validStatuses = ["open", "closed", "all"] as const;
+     if (!validStatuses.includes(status as typeof validStatuses[number])) {
+       return;
+     }
      void setFilters({
        status: status as "open" | "closed" | "all",
      });
    },
    [setFilters],
  );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/layout/dashboard-shell.tsx` around lines 63 - 70, The handler
handleStatusChange currently force-casts the URL-derived status with `status as
"open" | "closed" | "all"`, which is unsafe; update handleStatusChange (or add a
small validator used by useFilters) to check the incoming status string against
the allowed set ["open","closed","all"] and only call setFilters with a
validated value (or a safe fallback like "all") — e.g., perform a runtime
check/guard inside handleStatusChange and avoid the unchecked type assertion so
malformed/tampered URL values are rejected or normalized before calling
setFilters.

---

49-50: Unsafe type cast bypasses TypeScript checks.

The as unknown as GeoJSON.FeatureCollection double-cast completely bypasses type safety. If geojsonData has an unexpected structure, runtime errors could occur.

Consider defining a proper return type for useGeoJSON or adding runtime validation.

♻️ Suggested approach

Either update useGeoJSON to return a properly typed response, or add a type guard:

function isFeatureCollection(data: unknown): data is GeoJSON.FeatureCollection {
  return (
    data !== null &&
    typeof data === "object" &&
    "type" in data &&
    (data as { type: unknown }).type === "FeatureCollection"
  );
}

const geojsonFeatureCollection = isFeatureCollection(geojsonData) ? geojsonData : null;

As per coding guidelines: **/*.tsx: no use of any type (the double-cast effectively achieves the same unsafe behavior).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/layout/dashboard-shell.tsx` around lines 49 - 50, The
double-cast to GeoJSON.FeatureCollection is unsafe; replace it by either
updating useGeoJSON to return a properly typed GeoJSON.FeatureCollection (or
union) or add a runtime type guard (e.g., isFeatureCollection) and use that to
set geojsonFeatureCollection instead of the as unknown as cast; locate the
assignment to geojsonFeatureCollection and the useGeoJSON hook to implement one
of these fixes and ensure no use of any/unsafe casts remain.

.pre-commit-config.yaml (1)

27-61: Local hooks require pre-installed system tools.

The local hooks for gitleaks, shellcheck, shellharden, prettier, eslint, and zizmor use language: system, requiring these tools to be installed on each contributor's machine. Consider documenting these requirements in a CONTRIBUTING.md or the README to help new contributors set up their environment.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.pre-commit-config.yaml around lines 27 - 61, Add documentation listing the
system tools required by the local pre-commit hooks (gitleaks, shellcheck,
shellharden, prettier, eslint, and zizmor) and how to install or configure them;
update CONTRIBUTING.md or README with a new "Development setup" or "Pre-commit
hooks" section that enumerates each tool, required versions (if any),
installation commands for major platforms, and how to verify the tool is
available so contributors understand why the hooks use language: system and how
to satisfy those dependencies.

src/lib/api/eonet-client.ts (1)

8-8: Don't make the reusable client bypass your own proxy layer.

Every function targets NASA directly, so importing this module from UI code would skip the /api/eonet/* caching/rate-limit protection described in the PR and could end up shipping direct upstream requests to the browser. Either point this helper at the internal API routes or mark the module server-only to prevent accidental client-side use.

As per coding guidelines, src/lib/**: Review for proper TypeScript typing, error handling, and separation of concerns. API clients should handle errors gracefully.

Also applies to: 33-63

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/api/eonet-client.ts` at line 8, The module currently sets BASE_URL to
the public NASA endpoint which lets callers (including client-side code) bypass
your internal /api/eonet/* proxy; change BASE_URL to the internal route (e.g.,
"/api/eonet") or mark the module server-only (add the appropriate server-only
directive) so it cannot be imported from the browser, and while here improve
error handling and typings in the exported functions (e.g., the fetch wrappers
and any functions that reference BASE_URL) so they return typed results or
throw/catch errors consistently rather than allowing unhandled fetch failures.

src/components/events/event-detail-panel.tsx (1)

75-83: Replace inline category styling with classes or tokens.

The badge and dot both rely on style={...}, which breaks the repo rule for component styling and makes them harder to theme consistently. Push the color token/class into getCategoryConfig() and render classes here instead.

As per coding guidelines, src/components/**: Review for React best practices: proper prop typing, accessibility (aria labels, keyboard navigation), memoization where appropriate, and no inline styles.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/events/event-detail-panel.tsx` around lines 75 - 83, The Badge
and the inner dot in event-detail-panel.tsx currently use inline style props;
update getCategoryConfig() to return a color token or CSS class name (e.g.,
badgeClass and dotClass or colorToken) instead of raw color values, then remove
style={...} from the Badge and span and apply those returned classes via
className (or data- attributes if using CSS variables) so theming follows repo
rules; also ensure getCategoryConfig() typing is updated to include the new
fields and preserve accessibility by keeping existing text content/ARIA on the
Badge.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes