added the dark mode

[muditagrawal2007]

---

Summary by cubic

Adds a system-aware dark mode with a global ThemeProvider and a header toggle. Updates styles across the app using Tailwind’s class-based dark mode for a consistent UI in low light.

• New Features

  • ThemeContext with system preference detection and localStorage persistence; auto-toggles html.dark.
  • Header DarkModeToggle (Sun/Moon) with keyboard and screen reader support.
  • Tailwind dark mode enabled (darkMode: 'class'); base styles in index.css and variables in App.css.
  • Key components and views updated with dark: classes (e.g., ChatWidget, StatusTracker, ReportForm, VerifyView).
  • Comprehensive docs added (implementation, testing, user guide, deployment). No backend changes. Minor package-lock patch only.

• Migration

  • Wrap App in ThemeProvider (main.jsx).
  • For new UI, use Tailwind dark: utilities; use useTheme() if you need theme state.
  • No breaking changes; no new dependencies.

^{Written for commit fd976a0. Summary will update on new commits.}

Summary by CodeRabbit

• New Features

  • Dark mode toggle in the app header with keyboard & ARIA accessibility
  • Theme preference persists across sessions and syncs across tabs
  • Respects and listens to system theme preference with smooth transitions
  • App-wide dark styling applied across UI components and views

• Documentation

  • Comprehensive user, implementation, testing, verification, and deployment guides added

[netlify]

👷 Deploy request for fixmybharat pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	fd976a0

[github-actions]

🙏 Thank you for your contribution, @muditagrawal2007!

PR Details:

• Title: added the dark mode
• Number: added the dark mode #366

Quality Checklist:
Please ensure your PR meets the following criteria:

• Code follows the project's style guidelines
• Self-review of code completed
• Code is commented where necessary
• Documentation updated (if applicable)
• No new warnings generated
• Tests added/updated (if applicable)
• All tests passing locally
• No breaking changes to existing functionality

Review Process:

1. Automated checks will run on your code
2. A maintainer will review your changes
3. Address any requested changes promptly
4. Once approved, your PR will be merged! 🎉

Note: The maintainers will monitor code quality and ensure the overall project flow isn't broken.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a production-ready dark mode: a ThemeContext with persistence and system-preference detection, a DarkModeToggle component, app integration (ThemeProvider, Tailwind class strategy), widespread dark: styling across frontend components, and an extensive documentation and testing package.

Changes

Cohort / File(s)	Summary
Core Dark Mode Implementation frontend/src/contexts/ThemeContext.jsx, frontend/src/components/DarkModeToggle.jsx	New ThemeProvider/ThemeContext with useTheme hook, system preference listening, localStorage key theme-preference, DOM html.dark toggling; new accessible DarkModeToggle component (default export).
App Integration & Configuration frontend/src/main.jsx, frontend/src/App.jsx, frontend/src/index.css, frontend/src/App.css, frontend/tailwind.config.js	Wrap App with ThemeProvider; add global CSS variables and dark-mode base/component styles; enable darkMode: 'class' and add dark color tokens in Tailwind.
View & Component Styling Updates frontend/src/components/..., frontend/src/views/... (multiple files)	Applied Tailwind dark: variants across many components/views (ChatWidget, StatusTracker, ActionView, GrievanceView, Home, LeaderboardView, MaharashtraRepView, MapView, NotFound, ReportForm, StatsView, VerifyView) — presentation-only changes, no control-flow alterations.
Documentation Package DARK_MODE_README.md, DARK_MODE_IMPLEMENTATION.md, DARK_MODE_USER_GUIDE.md, DARK_MODE_TESTING.md, DARK_MODE_QUICK_REFERENCE.md, DARK_MODE_SUMMARY.md, DARK_MODE_VERIFICATION.md, DARK_MODE_INDEX.md, DARK_MODE_DEPLOYMENT_GUIDE.md, DARK_MODE_PR_DESCRIPTION.md, DARK_MODE_COMPLETE.md, START_HERE_DARK_MODE.md, IMPLEMENTATION_COMPLETE.md	Extensive docs: implementation, guides, testing, deployment, verification, quick reference, and PR description — large documentation bundle accompanying code changes.

Sequence Diagram(s)

sequenceDiagram
    actor User
    participant Toggle as DarkModeToggle
    participant Context as ThemeContext
    participant Storage as localStorage
    participant DOM as HTML Document
    participant Tailwind as CSS Engine

    User->>Toggle: Click toggle
    Toggle->>Context: toggleTheme()
    Context->>Context: update isDark state
    Context->>DOM: add/remove 'dark' class on html
    Context->>Storage: set 'theme-preference'
    DOM->>Tailwind: activate dark: styles
    Tailwind->>User: render themed UI

    rect rgba(100, 200, 150, 0.5)
    Note over Context,Storage: On App load
    Context->>Storage: read 'theme-preference'
    alt preference exists
        Context->>Context: apply saved theme
    else no preference
        Context->>DOM: query prefers-color-scheme
        Context->>Context: apply system preference
    end
    Context->>DOM: apply theme class
    DOM->>Tailwind: apply matching styles
    Tailwind->>User: render themed UI
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Suggested labels

ECWoC26, ECWoC26-L3

Poem

🐰 In moonlit CSS I hop and play,
I toggle themes and hide the day,
Context hums, localStorage keeps tight,
Tailwind paints shadows soft at night,
A happy rabbit hops — dark mode’s delight!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'added the dark mode' is vague and generic, using non-specific language that doesn't clearly convey the scope or specifics of the changeset beyond mentioning 'dark mode.'	Consider using a more descriptive title that specifies key aspects, such as 'Implement system-aware dark mode with ThemeContext and localStorage persistence' or 'Add dark mode support with theme toggle and system preference detection.'

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

👋 Hello @muditagrawal2007! Thank you for your first Pull Request to VishwaGuru! 🎉

We appreciate your contribution to this open source platform empowering India's youth to engage with democracy.

What happens next?

• A maintainer will review your PR soon
• Please ensure all tests pass and the code follows our style guidelines
• Be ready to address any feedback or requested changes

Before your PR is merged:

• Ensure your code follows the project's coding standards
• All tests should pass
• Update documentation if needed
• Make sure your commits are clear and descriptive

Resources:

• Architecture Guide
• Deployment Guide
• Code of Conduct

Thank you for contributing! 🚀

[cubic-dev-ai]

6 issues found across 33 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="frontend/src/components/DarkModeToggle.jsx">

<violation number="1" location="frontend/src/components/DarkModeToggle.jsx:14">
P2: Set an explicit button type to avoid unintended form submissions when this component is used inside a form.</violation>
</file>

<file name="IMPLEMENTATION_COMPLETE.md">

<violation number="1" location="IMPLEMENTATION_COMPLETE.md:39">
P3: Documentation count is inconsistent (11 vs 12). Update the heading to match the listed items and stats.</violation>
</file>

<file name="START_HERE_DARK_MODE.md">

<violation number="1" location="START_HERE_DARK_MODE.md:50">
P3: The document self-references `DARK_MODE_COMPLETE.md`, but the file being added is `START_HERE_DARK_MODE.md`. This makes the documentation index inaccurate and will send readers to a non-existent file. Update the reference to the actual filename (or rename the file).</violation>
</file>

<file name="frontend/src/contexts/ThemeContext.jsx">

<violation number="1" location="frontend/src/contexts/ThemeContext.jsx:37">
P1: Bug: System preference change listener is effectively dead code. The second `useEffect` always saves to `localStorage` after mount (even when the theme was auto-detected, not user-chosen), so the `!localStorage.getItem('theme-preference')` guard in the media query handler is always `false`. OS-level dark/light mode changes will never propagate to the app.

Fix: only persist to `localStorage` on explicit user toggle, not on every `isDark` change. Move the `localStorage.setItem` call into `toggleTheme` instead.</violation>
</file>

<file name="DARK_MODE_DEPLOYMENT_GUIDE.md">

<violation number="1" location="DARK_MODE_DEPLOYMENT_GUIDE.md:65">
P3: The documentation file count is inconsistent with the list (9 entries listed but labeled as 8). This makes the deployment guide inaccurate and harder to trust; update the counts to match the actual list.</violation>
</file>

<file name="frontend/src/App.jsx">

<violation number="1" location="frontend/src/App.jsx:279">
P2: Inconsistent dark mode: the "Contact Us" link is missing `dark:hover:text-blue-400` that was added to the sibling "Privacy Policy" and "Terms of Service" links.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P1: Bug: System preference change listener is effectively dead code. The second useEffect always saves to localStorage after mount (even when the theme was auto-detected, not user-chosen), so the !localStorage.getItem('theme-preference') guard in the media query handler is always false. OS-level dark/light mode changes will never propagate to the app.

Fix: only persist to localStorage on explicit user toggle, not on every isDark change. Move the localStorage.setItem call into toggleTheme instead.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At frontend/src/contexts/ThemeContext.jsx, line 37:

<comment>Bug: System preference change listener is effectively dead code. The second `useEffect` always saves to `localStorage` after mount (even when the theme was auto-detected, not user-chosen), so the `!localStorage.getItem('theme-preference')` guard in the media query handler is always `false`. OS-level dark/light mode changes will never propagate to the app.

Fix: only persist to `localStorage` on explicit user toggle, not on every `isDark` change. Move the `localStorage.setItem` call into `toggleTheme` instead.</comment>

<file context>
@@ -0,0 +1,82 @@
+    if (!mounted) return;
+
+    // Update localStorage
+    localStorage.setItem('theme-preference', isDark ? 'dark' : 'light');
+
+    // Update DOM class
</file context>

[cubic-dev-ai]

P2: Set an explicit button type to avoid unintended form submissions when this component is used inside a form.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At frontend/src/components/DarkModeToggle.jsx, line 14:

<comment>Set an explicit button type to avoid unintended form submissions when this component is used inside a form.</comment>

<file context>
@@ -0,0 +1,55 @@
+  const { isDark, toggleTheme } = useTheme();
+
+  return (
+    <button
+      onClick={toggleTheme}
+      className={`
</file context>

[cubic-dev-ai]

P3: Documentation count is inconsistent (11 vs 12). Update the heading to match the listed items and stats.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At IMPLEMENTATION_COMPLETE.md, line 39:

<comment>Documentation count is inconsistent (11 vs 12). Update the heading to match the listed items and stats.</comment>

<file context>
@@ -0,0 +1,428 @@
+
+---
+
+## 📚 Documentation Package (11 Files)
+
+### Comprehensive Guides Created
</file context>

[cubic-dev-ai]

P3: The document self-references DARK_MODE_COMPLETE.md, but the file being added is START_HERE_DARK_MODE.md. This makes the documentation index inaccurate and will send readers to a non-existent file. Update the reference to the actual filename (or rename the file).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At START_HERE_DARK_MODE.md, line 50:

<comment>The document self-references `DARK_MODE_COMPLETE.md`, but the file being added is `START_HERE_DARK_MODE.md`. This makes the documentation index inaccurate and will send readers to a non-existent file. Update the reference to the actual filename (or rename the file).</comment>

<file context>
@@ -0,0 +1,473 @@
+8. `DARK_MODE_INDEX.md` - Documentation index
+9. `DARK_MODE_DEPLOYMENT_GUIDE.md` - Deployment guide
+10. `DARK_MODE_PR_DESCRIPTION.md` - PR template
+11. `DARK_MODE_COMPLETE.md` - Delivery summary
+
+---
</file context>

[cubic-dev-ai]

P3: The documentation file count is inconsistent with the list (9 entries listed but labeled as 8). This makes the deployment guide inaccurate and harder to trust; update the counts to match the actual list.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At DARK_MODE_DEPLOYMENT_GUIDE.md, line 65:

<comment>The documentation file count is inconsistent with the list (9 entries listed but labeled as 8). This makes the deployment guide inaccurate and harder to trust; update the counts to match the actual list.</comment>

<file context>
@@ -0,0 +1,463 @@
+frontend/tailwind.config.js              +2 lines
+```
+
+### Documentation Files (8)
+```
+DARK_MODE_README.md                  Central hub
</file context>

[coderabbitai]

Actionable comments posted: 18

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (6)

frontend/src/views/ActionView.jsx (1)

7-10: ⚠️ Potential issue | 🔴 Critical

Pre-existing: Early return before useEffect violates the Rules of Hooks.

Line 8 returns early when actionPlan is falsy, causing the useEffect on Line 10 to be skipped on some renders. React requires hooks to be called unconditionally and in the same order every render. If actionPlan transitions from truthy to null, React will throw a "Rendered fewer hooks than expected" error.

Not introduced by this PR, but worth fixing while you're editing this file.

Proposed fix

Move the early return below the useEffect:

 const ActionView = ({ actionPlan, setActionPlan, setView }) => {
-  if (!actionPlan) return null;
-
   useEffect(() => {
     let interval;
-    if (actionPlan.status === 'generating' && actionPlan.id) {
+    if (actionPlan?.status === 'generating' && actionPlan?.id) {
       interval = setInterval(async () => {
         ...
       }, 2000);
     }
     return () => clearInterval(interval);
   }, [actionPlan, setActionPlan]);

+  if (!actionPlan) return null;
+
   if (actionPlan.status === 'generating') {

frontend/src/App.jsx (5)

131-144: ⚠️ Potential issue | 🟠 Major

SuccessAlert is missing dark mode styling, unlike ErrorAlert.

ErrorAlert (Lines 77-128) was updated with dark: variants, but SuccessAlert still uses hardcoded light-mode classes (bg-green-50, text-green-400, text-green-700). This will render poorly on a dark background.

Proposed fix

 const SuccessAlert = ({ message }) => (
-  <div className="bg-green-50 border-l-4 border-green-500 p-4 rounded-lg my-4 animate-fadeIn">
+  <div className="bg-green-50 dark:bg-green-900/20 border-l-4 border-green-500 dark:border-green-700/50 p-4 rounded-lg my-4 animate-fadeIn">
     <div className="flex items-center">
       <div className="flex-shrink-0">
-        <svg className="h-5 w-5 text-green-400" fill="currentColor" viewBox="0 0 20 20">
+        <svg className="h-5 w-5 text-green-400 dark:text-green-500" fill="currentColor" viewBox="0 0 20 20">

-        <p className="text-sm font-medium text-green-700">{message}</p>
+        <p className="text-sm font-medium text-green-700 dark:text-green-300">{message}</p>

---

147-174: ⚠️ Potential issue | 🟠 Major

NavigationBreadcrumb is missing dark mode styling.

Hardcoded light-mode colors (text-gray-500, text-gray-400, text-blue-600) will have poor contrast on the dark background. This component appears on every non-home page.

Proposed fix

-          <a href="/" className="text-gray-500 hover:text-blue-600 transition-colors duration-200">
+          <a href="/" className="text-gray-500 dark:text-gray-400 hover:text-blue-600 dark:hover:text-blue-400 transition-colors duration-200">
             Home
           </a>

-            <svg className="h-4 w-4 text-gray-400 mx-1" fill="currentColor" viewBox="0 0 20 20">
+            <svg className="h-4 w-4 text-gray-400 dark:text-gray-500 mx-1" fill="currentColor" viewBox="0 0 20 20">

-            <span className={`capitalize ${index === paths.length - 1 ? 'text-blue-600 font-medium' : 'text-gray-500'}`}>
+            <span className={`capitalize ${index === paths.length - 1 ? 'text-blue-600 dark:text-blue-400 font-medium' : 'text-gray-500 dark:text-gray-400'}`}>

---

177-209: ⚠️ Potential issue | 🟠 Major

DetectorWrapper only partially styled for dark mode.

Line 204 has dark variants, but the border (Line 183: border-gray-100), back button text (Line 186: text-gray-600), and "Back to Home" label (Line 196) are missing dark mode classes.

Proposed fix

-      <div className="flex items-center justify-between mb-6 pb-4 border-b border-gray-100">
+      <div className="flex items-center justify-between mb-6 pb-4 border-b border-gray-100 dark:border-gray-700">
         <button
           onClick={onBack}
-          className="group flex items-center gap-2 text-gray-600 hover:text-blue-600 transition-all duration-300 hover:-translate-x-1"
+          className="group flex items-center gap-2 text-gray-600 dark:text-gray-400 hover:text-blue-600 dark:hover:text-blue-400 transition-all duration-300 hover:-translate-x-1"
         >

---

647-777: ⚠️ Potential issue | 🟠 Major

GlobalStyles component is defined after export default App and never rendered.

This component is dead code — it's not imported or used anywhere. The animations it defines (e.g., animate-fadeIn, animate-gradient) appear to work only because they're duplicated in CSS files. Remove it or integrate it into the component tree.

---

51-57: ⚠️ Potential issue | 🟡 Minor

border-3 and border-6 are not standard Tailwind CSS utility classes and are not defined as custom utilities.

Tailwind provides border, border-2, border-4, and border-8. These non-standard classes at lines 54 and 56 will be silently ignored by Tailwind and have no visual effect.

Proposed fix

     md: "h-10 w-10 border-3",
+    md: "h-10 w-10 border-2",
     lg: "h-16 w-16 border-4",
-    xl: "h-24 w-24 border-6"
+    xl: "h-24 w-24 border-8"

🤖 Fix all issues with AI agents

In `@DARK_MODE_PR_DESCRIPTION.md`:
- Line 24: The fenced code blocks in DARK_MODE_PR_DESCRIPTION.md are missing
language specifiers (three occurrences of ```), causing MD040; update each
triple-backtick fence to include a language identifier (for example change ```
to ```text) for the blocks around the examples so static analysis passes; search
for the bare ``` fences in the file and replace them with labeled fences (e.g.,
```text) to fix the MD040 warnings.
- Around line 1-230: Remove the committed PR description file
DARK_MODE_PR_DESCRIPTION.md from the changeset and place its contents into the
GitHub PR body instead; specifically delete the file from the branch (or revert
the addition) so it is not merged into the repo, update the PR description with
the copied content, and ensure no other commits re-add
DARK_MODE_PR_DESCRIPTION.md before merging.

In `@DARK_MODE_QUICK_REFERENCE.md`:
- Around line 1-344: The docs are overly duplicated across many markdowns (e.g.,
DARK_MODE_QUICK_REFERENCE.md plus DARK_MODE_README.md, DARK_MODE_USER_GUIDE.md,
DARK_MODE_INDEX.md, DARK_MODE_IMPLEMENTATION.md, DARK_MODE_TESTING.md,
DARK_MODE_VERIFICATION.md, DARK_MODE_SUMMARY.md, DARK_MODE_PR_DESCRIPTION.md,
DARK_MODE_DEPLOYMENT_GUIDE.md); consolidate them into a single canonical
DARK_MODE.md that includes sections for architecture, usage patterns, color
palette, testing tips and deployment checklist, then delete the redundant files
and update any references/links (README or PR description) to point to
DARK_MODE.md; keep the PR description short and reference the consolidated doc
and ensure any unique content from the removed files (e.g., specific testing
steps or deployment checklist) is merged into appropriate sections in
DARK_MODE.md.

In `@DARK_MODE_README.md`:
- Around line 248-255: Replace the unverified "WCAG AA Compliant" claim: either
run a contrast checker for the palette and add documented contrast ratios (e.g.,
measure "#D1D5DB" on "#2D2D2D" and all primary/secondary text vs backgrounds
showing they meet 4.5:1 or 3:1 where applicable) and list the results, or soften
the wording to "designed with accessibility in mind" and remove the absolute
compliance statement; update the Accessibility section text (the "WCAG AA
Compliant" heading and bullet) accordingly so it references the measured ratios
or the softer language.
- Line 83: The README self-reference is wrong: locate the line containing the
literal text "README.md ← This file" and replace "README.md" with
"DARK_MODE_README.md" so the pointer matches the actual filename; ensure any
similar occurrences in the file (e.g., the same annotated tree line) are updated
to "DARK_MODE_README.md ← This file".

In `@DARK_MODE_TESTING.md`:
- Around line 229-273: The test stubs under the "ThemeContext" describe block
and the "Dark Mode Integration" describe block are empty and should either be
implemented or the entire "Automated Testing (For Developers)" section removed;
to fix, implement real unit tests for ThemeContext (replace comments in tests
named 'should initialize with localStorage preference', 'should initialize with
system preference', 'should toggle theme correctly', 'should persist theme to
localStorage', 'should respond to system theme changes') using your test runner
and assertions to verify initial state, toggleTheme behavior, localStorage
updates, and media-query listener response, and implement integration tests in
the 'Dark Mode Integration' suite ('should apply dark class to html element',
'should update all component styles', 'should persist across route changes') to
assert DOM class application, CSS changes, and SPA persistence, or remove the
entire section to avoid implying nonexistent coverage.

In `@DARK_MODE_USER_GUIDE.md`:
- Around line 24-26: Documentation claims theme syncs across tabs in real-time
but ThemeContext doesn't handle the storage event; either update ThemeContext to
listen for window "storage" events (in the ThemeContext useEffect, add
window.addEventListener('storage', handler) that reads the theme from
localStorage and calls your theme setter—e.g., setTheme—then cleanup the
listener) so other tabs update immediately, or change the doc line to "persists
across page reloads and new tabs" to accurately reflect current behavior.
- Around line 65-67: The documentation import path for ThemeContext is
misleading: update the example import of useTheme from 'useTheme' and
'ThemeContext' to show a relative path that reflects the common component
location (e.g., from inside src/components), changing the import string
'./contexts/ThemeContext' to the correct relative path (such as
'../contexts/ThemeContext') so components under src/components can resolve
useTheme from ThemeContext; ensure the example references the same symbol names
(useTheme and ThemeContext) so readers can follow the example without path
errors.

In `@DARK_MODE_VERIFICATION.md`:
- Around line 1-364: DARK_MODE_VERIFICATION.md contains a fully self-checked,
author-marked readiness checklist (e.g., entries like "Changes merged to main",
"Build successful", "Feature accessible to users") that falsely implies CI/peer
verification; remove or replace this file with a non-authoritative artifact:
either delete DARK_MODE_VERIFICATION.md or convert it into a checklist template
that clearly marks items as "To be verified by CI/Reviewer" and add placeholders
for CI build status, reviewer initials, and timestamp so only automated CI
badges or reviewer signatures can mark deployment steps (update the header and
entries referencing "Changes merged to main"/"Build successful"/"Feature
accessible to users" to require external verification).

In `@frontend/src/App.css`:
- Around line 39-42: Add dark-mode overrides for the globally-styled components
that remain hardcoded to light colors: update the stylesheet to provide
html.dark rules for .card (override background var(--glass-bg) to a
dark-friendly value or use a dark CSS variable), input, textarea, select
(override their background rgba(255,255,255,0.9) to a dark input background and
adjust color/border), .gradient-border (replace white with a dark-appropriate
color or gradient), and ::-webkit-scrollbar-track (set a darker track color
under html.dark); if instead these elements are styled via Tailwind in JSX, add
a concise comment near the top explaining that dark styles are applied in
components so future maintainers don’t add redundant html.dark overrides.

In `@frontend/src/App.jsx`:
- Around line 277-281: The "Contact Us" footer anchor is missing the dark mode
hover class; update the JSX anchor for the "Contact Us" link (the <a> element
whose className currently includes "hover:text-blue-600 transition-colors
duration-200") to also include "dark:hover:text-blue-400" so all three footer
links use the same hover classes ("hover:text-blue-600 dark:hover:text-blue-400
transition-colors duration-200").
- Around line 225-243: The DarkModeToggle is absolutely positioned and removed
from the flex flow, causing overlap on small screens; move the DarkModeToggle
out of the absolutely positioned wrapper and make it a normal flex child inside
the container with class "flex items-center justify-between" (the same parent
that contains the centered title block), remove the "absolute right-4 md:right-8
top-1/2 transform -translate-y-1/2" wrapper around DarkModeToggle, and instead
position it with flex utility classes (e.g., place it as the right-side flex
item using ml-auto or appropriate order and responsive visibility classes) so it
participates in the layout and doesn’t overlap the h1 on narrow viewports.

In `@frontend/src/contexts/ThemeContext.jsx`:
- Around line 16-30: The code reads and writes localStorage unguarded (in the
useEffect that sets theme, and in the other places calling
localStorage.getItem/setItem), which can throw in restricted environments;
create small safe helpers (e.g., getStoredTheme and setStoredTheme) that wrap
localStorage.getItem and localStorage.setItem in try/catch and return null or
silently fail on error, then replace direct localStorage calls in the useEffect
and wherever theme persistence is handled (references: the useEffect that calls
setIsDark, any code that calls localStorage.getItem('theme-preference') and
localStorage.setItem('theme-preference')) to use these helpers so the app
degrades gracefully when storage is unavailable.
- Around line 33-45: Introduce a "userHasPreference" (or similar) state to
distinguish explicit user toggles from system-derived initial value, update the
toggle handler that sets isDark to also set userHasPreference=true, change the
useEffect that currently writes localStorage (watching isDark and mounted) to
only persist when userHasPreference is true, and modify the system preference
listener's handleChange to update isDark only when userHasPreference is false
(and keep the initial read of localStorage to set userHasPreference if a saved
preference exists); reference the existing symbols isDark, mounted,
localStorage.getItem('theme-preference'), handleChange, and the two useEffect
hooks to locate and apply these changes.

In `@frontend/src/views/MapView.jsx`:
- Line 9: The current header uses key.replace('_', ' ') which only replaces the
first underscore; update the transformation in MapView.jsx where the header is
rendered (the expression using key.replace) to replace all underscores (e.g.,
use key.replaceAll('_', ' ') or key.replace(/_/g, ' ')) so keys like
"central_government_authority" become "central government authority".

In `@frontend/tailwind.config.js`:
- Around line 10-15: Remove the unused custom dark theme tokens from the
Tailwind colors config: delete the 'dark-bg', 'dark-card', and 'dark-border'
entries from the colors object so only the standard Tailwind gray palette
remains; ensure no references to 'dark-bg', 'dark-card', or 'dark-border' exist
elsewhere (search the repo) and remove or replace any usages with the
corresponding standard Tailwind gray classes.

In `@IMPLEMENTATION_COMPLETE.md`:
- Around line 1-428: Consolidate the dozen root-level markdowns into a single
docs/dark-mode.md (or at most 2–3 files) and move all dark-mode documentation
into the docs/ directory, removing the extra files from the repository root;
update IMPLEMENTATION_COMPLETE.md to reflect the new paths and correct the
"START_HERE_DARK_MODE.md" reference. In code, fix the incorrect claims by
updating ThemeContext.jsx: ensure ThemeProvider initializes theme from a
synchronous check to avoid initial flash (e.g., derive initial isDark from
window.matchMedia where available) and wrap all localStorage reads/writes used
by useTheme()/ThemeProvider in try/catch to safely handle disabled storage and
log/fallback appropriately. Finally, update IMPLEMENTATION_COMPLETE.md content
to remove mismatched assertions (no initial page flash, localStorage handling)
so documentation matches actual behavior.

In `@START_HERE_DARK_MODE.md`:
- Around line 1-473: The repo has 11 duplicated dark-mode docs; consolidate them
into a single canonical document (DARK_MODE.md) or at most two
(DARK_MODE_IMPLEMENTATION.md for devs + DARK_MODE_USER.md for users). Merge
unique content from START_HERE_DARK_MODE.md, DARK_MODE_README.md,
DARK_MODE_IMPLEMENTATION.md, DARK_MODE_USER_GUIDE.md, DARK_MODE_TESTING.md,
DARK_MODE_QUICK_REFERENCE.md, DARK_MODE_SUMMARY.md, DARK_MODE_VERIFICATION.md,
DARK_MODE_INDEX.md, DARK_MODE_DEPLOYMENT_GUIDE.md and
DARK_MODE_PR_DESCRIPTION.md into the chosen file(s), remove duplicated sections
(color palettes, file lists, checklists, compatibility tables), keep one
authoritative testing checklist and one deployment checklist, and delete the
now-redundant markdown files; update any references in README or PR templates to
point to the new DARK_MODE.md (or the two new docs) so ThemeContext.jsx,
DarkModeToggle.jsx and main.jsx integration guidance remains present.

🧹 Nitpick comments (9)

frontend/src/views/ActionView.jsx (1)

75-75: Redundant dark:text-white — text-white already applies in all modes.

text-white is not theme-aware, so dark:text-white is a no-op here.

-            <span className="bg-black dark:bg-gray-900 text-white dark:text-white px-2 py-1 rounded text-sm mr-2">X.com</span>
+            <span className="bg-black dark:bg-gray-900 text-white px-2 py-1 rounded text-sm mr-2">X.com</span>

frontend/src/views/LeaderboardView.jsx (1)

25-30: Minor: getRankIcon rank text missing dark mode variant.

The fallback rank text on line 29 uses text-gray-500 without a dark variant. While gray-500 is borderline readable on dark backgrounds, adding dark:text-gray-400 would be consistent with the rest of the file.

Proposed fix

-    return <span className="font-bold text-gray-500 w-6 text-center">{rank}</span>;
+    return <span className="font-bold text-gray-500 dark:text-gray-400 w-6 text-center">{rank}</span>;

frontend/src/views/GrievanceView.jsx (1)

267-268: Modal backdrop: verify bg-opacity override behavior with Tailwind's class dark mode strategy.

Line 267 combines bg-gray-600 dark:bg-gray-950 bg-opacity-50 dark:bg-opacity-75. With Tailwind's class dark mode strategy, the dark:bg-opacity-75 should correctly override bg-opacity-50 when the dark class is present on an ancestor. However, if you're using Tailwind v3.x with JIT, consider using the slash opacity syntax (e.g., bg-gray-600/50 dark:bg-gray-950/75) for clearer intent and to avoid potential specificity edge cases.

Proposed simplification

-          <div className="fixed inset-0 bg-gray-600 dark:bg-gray-950 bg-opacity-50 dark:bg-opacity-75 overflow-y-auto h-full w-full z-50">
+          <div className="fixed inset-0 bg-gray-600/50 dark:bg-gray-950/75 overflow-y-auto h-full w-full z-50">

frontend/src/views/ReportForm.jsx (1)

400-413: Consider extracting repeated color pattern strings to reduce duplication.

Across this file (and the other view files), the pattern bg-{color}-50 dark:bg-{color}-900/20 border-{color}-200 dark:border-{color}-700/50 text-{color}-800 dark:text-{color}-300 is repeated many times for different severity/status levels (lines 455-457, 581-584, 617-621, etc.). This makes maintenance harder — a single design token change requires updating dozens of lines.

Consider extracting these into a utility function or a shared style map, e.g.:

const colorVariant = (color) =>
  `bg-${color}-50 dark:bg-${color}-900/20 border-${color}-200 dark:border-${color}-700/50 text-${color}-800 dark:text-${color}-300`;

Note: If using Tailwind's JIT/purge, dynamically constructed class names won't be detected. You'd need to safelist them or use a complete class map instead. A map-based approach (mapping level → full class string) is safer.

frontend/src/views/Home.jsx (1)

161-166: dark:text-current neutralizes category-specific icon colors in dark mode.

On Line 163, dark:text-current will override the per-category item.color (e.g., text-red-600) in dark mode since the dark: variant has higher specificity. The resolved currentColor will inherit from the nearest ancestor's text color, making all icons the same color and losing their distinctive per-category tinting.

If this is intentional (uniform muted icons in dark mode), consider using an explicit class like dark:text-gray-300 for clarity. If category colors should be preserved, remove dark:text-current and instead map each item.color to a dark-friendly equivalent (e.g., text-red-600 dark:text-red-400).

frontend/src/contexts/ThemeContext.jsx (1)

12-13: Initial isDark = false causes a brief light-mode flash for dark-preferring users.

The provider renders {children} immediately (Line 68) with isDark = false before the mount effect reads the actual preference. Users who prefer dark mode will see a flash of the light theme on every page load.

A common mitigation: either render null/a loading state until mounted is true, or initialize isDark synchronously from localStorage via a lazy initializer in useState.

Lazy initializer approach (no extra render, no flash)

-  const [isDark, setIsDark] = useState(false);
-  const [mounted, setMounted] = useState(false);
+  const [isDark, setIsDark] = useState(() => {
+    try {
+      const saved = localStorage.getItem('theme-preference');
+      if (saved) return saved === 'dark';
+      return window.matchMedia('(prefers-color-scheme: dark)').matches;
+    } catch {
+      return false;
+    }
+  });
+  const [mounted, setMounted] = useState(false);

Then the mount effect only needs to call setMounted(true) and apply the DOM class.

Also applies to: 66-69

frontend/src/App.css (1)

11-17: Dark-mode CSS variables defined but never consumed.

--dark-glass-bg, --dark-glass-border, --dark-shadow-soft, --dark-shadow-medium, and --dark-shadow-intense are declared here but no html.dark selector or var(...) reference uses them. Either wire them up or remove the dead declarations.

frontend/src/index.css (1)

7-19: CSS custom properties are defined but never consumed.

The variables --bg-light, --bg-dark, --text-light, --text-dark, --border-light, --border-dark (and their secondary variants) are declared in lines 7-19 but never referenced via var(...) anywhere in the codebase. The actual dark-mode styles hardcode the same hex values instead—lines 22-26 use Tailwind utilities like bg-white, bg-[#1a1a1a], and text-gray-100 rather than consuming these variables.

Either remove these unused properties or refactor to consume them for a single source of truth on color tokens.

Option A: Use the variables

  html {
-   `@apply` bg-white text-gray-900 transition-colors duration-300;
+   background-color: var(--bg-light);
+   color: var(--text-light);
+   transition: color 0.3s, background-color 0.3s;
  }

  html.dark {
-   `@apply` bg-[`#1a1a1a`] text-gray-100;
+   background-color: var(--bg-dark);
+   color: var(--text-dark);
  }

Option B: Remove unused variables

 `@layer` base {
-  :root {
-    --bg-light: `#ffffff`;
-    --bg-light-secondary: `#f9fafb`;
-    --text-light: `#1f2937`;
-    --text-light-secondary: `#6b7280`;
-    --border-light: `#e5e7eb`;
-    
-    --bg-dark: `#1a1a1a`;
-    --bg-dark-secondary: `#2d2d2d`;
-    --text-dark: `#f3f4f6`;
-    --text-dark-secondary: `#d1d5db`;
-    --border-dark: `#404040`;
-  }
-
   html {

frontend/src/views/MaharashtraRepView.jsx (1)

103-103: Conflicting display classes: block and flex on the same element.

Line 103 applies both block and flex — flex will win but block is dead code and confusing. While this may be pre-existing, it should be cleaned up since this line was touched.

Proposed fix

-                  className="block w-full text-center bg-black dark:bg-gray-900 text-white py-2 rounded hover:bg-gray-800 dark:hover:bg-gray-800 transition flex items-center justify-center gap-2"
+                  className="flex w-full bg-black dark:bg-gray-900 text-white py-2 rounded hover:bg-gray-800 dark:hover:bg-gray-800 transition items-center justify-center gap-2"

[coderabbitai]

⚠️ Potential issue | 🟠 Major

This file should be the PR description, not a committed file.

DARK_MODE_PR_DESCRIPTION.md duplicates what should live in the GitHub PR body. Committing PR descriptions as repository files adds permanent clutter and goes stale immediately after merge. Remove this file from the PR and paste the relevant content into the PR description on GitHub instead.

🧰 Tools

🪛 LanguageTool

[grammar] ~46-~46: Ensure spelling is correct
Context: ...ht corner) - Smooth visual transitions (300ms CSS transitions) - Immediate visual fee...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🪛 markdownlint-cli2 (0.20.0)

[warning] 24-24: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

[warning] 34-34: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

[warning] 78-78: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

[warning] 138-138: Tables should be surrounded by blank lines

(MD058, blanks-around-tables)

🤖 Prompt for AI Agents

In `@DARK_MODE_PR_DESCRIPTION.md` around lines 1 - 230, Remove the committed PR
description file DARK_MODE_PR_DESCRIPTION.md from the changeset and place its
contents into the GitHub PR body instead; specifically delete the file from the
branch (or revert the addition) so it is not merged into the repo, update the PR
description with the copied content, and ensure no other commits re-add
DARK_MODE_PR_DESCRIPTION.md before merging.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Fenced code blocks missing language specifiers.

Static analysis flags MD040 on Lines 24, 34, and 78. Add a language identifier (e.g., ```text) to these fenced code blocks.

Also applies to: 34-34, 78-78

🧰 Tools

🪛 markdownlint-cli2 (0.20.0)

[warning] 24-24: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents

In `@DARK_MODE_PR_DESCRIPTION.md` at line 24, The fenced code blocks in
DARK_MODE_PR_DESCRIPTION.md are missing language specifiers (three occurrences
of ```), causing MD040; update each triple-backtick fence to include a language
identifier (for example change ``` to ```text) for the blocks around the
examples so static analysis passes; search for the bare ``` fences in the file
and replace them with labeled fences (e.g., ```text) to fix the MD040 warnings.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Excessive documentation for a small feature.

This is one of 7+ markdown files being added for a ~200-line dark mode feature (2 new component files, 5 modified files). The content across DARK_MODE_README.md, DARK_MODE_USER_GUIDE.md, DARK_MODE_QUICK_REFERENCE.md, DARK_MODE_INDEX.md, DARK_MODE_IMPLEMENTATION.md, DARK_MODE_TESTING.md, DARK_MODE_VERIFICATION.md, DARK_MODE_SUMMARY.md, DARK_MODE_PR_DESCRIPTION.md, and DARK_MODE_DEPLOYMENT_GUIDE.md is heavily duplicated — the same color palettes, file structures, feature lists, and code patterns are repeated in nearly every file.

Consider consolidating into a single DARK_MODE.md that covers architecture, usage patterns, color reference, and testing tips. This reduces maintenance burden and avoids stale/inconsistent documentation as the feature evolves.

🧰 Tools

🪛 markdownlint-cli2 (0.20.0)

[warning] 6-6: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

[warning] 18-18: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

[warning] 241-241: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents

In `@DARK_MODE_QUICK_REFERENCE.md` around lines 1 - 344, The docs are overly
duplicated across many markdowns (e.g., DARK_MODE_QUICK_REFERENCE.md plus
DARK_MODE_README.md, DARK_MODE_USER_GUIDE.md, DARK_MODE_INDEX.md,
DARK_MODE_IMPLEMENTATION.md, DARK_MODE_TESTING.md, DARK_MODE_VERIFICATION.md,
DARK_MODE_SUMMARY.md, DARK_MODE_PR_DESCRIPTION.md,
DARK_MODE_DEPLOYMENT_GUIDE.md); consolidate them into a single canonical
DARK_MODE.md that includes sections for architecture, usage patterns, color
palette, testing tips and deployment checklist, then delete the redundant files
and update any references/links (README or PR description) to point to
DARK_MODE.md; keep the PR description short and reference the consolidated doc
and ensure any unique content from the removed files (e.g., specific testing
steps or deployment checklist) is merged into appropriate sections in
DARK_MODE.md.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Incorrect self-reference.

Line 83 says README.md ← This file, but the actual filename is DARK_MODE_README.md.

-└── README.md                          ← This file
+└── DARK_MODE_README.md                ← This file

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	└── README.md ← This file
	└── DARK_MODE_README.md ← This file

🤖 Prompt for AI Agents

In `@DARK_MODE_README.md` at line 83, The README self-reference is wrong: locate
the line containing the literal text "README.md ← This file" and replace
"README.md" with "DARK_MODE_README.md" so the pointer matches the actual
filename; ensure any similar occurrences in the file (e.g., the same annotated
tree line) are updated to "DARK_MODE_README.md ← This file".

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Unverified WCAG AA compliance claim.

Stating "WCAG AA Compliant" without measured contrast ratios is risky. For example, the dark mode secondary text #D1D5DB on background #2D2D2D should be verified to meet the 4.5:1 minimum contrast ratio. Either run the palette through a contrast checker and document results, or soften the language to "designed with accessibility in mind."

🤖 Prompt for AI Agents

In `@DARK_MODE_README.md` around lines 248 - 255, Replace the unverified "WCAG AA
Compliant" claim: either run a contrast checker for the palette and add
documented contrast ratios (e.g., measure "#D1D5DB" on "#2D2D2D" and all
primary/secondary text vs backgrounds showing they meet 4.5:1 or 3:1 where
applicable) and list the results, or soften the wording to "designed with
accessibility in mind" and remove the absolute compliance statement; update the
Accessibility section text (the "WCAG AA Compliant" heading and bullet)
accordingly so it references the measured ratios or the softer language.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

System preference listener is effectively dead after first mount.

The second useEffect (Line 33–45) writes to localStorage on every isDark/mounted change — including right after the initial mount when no user preference existed. This means localStorage.getItem('theme-preference') on Line 53 will always return a value after the first render, so the handleChange callback in the third useEffect will never apply system preference updates.

To fix this, distinguish between "user explicitly toggled" vs "system-derived initial value." One approach: only persist to localStorage when the user explicitly toggles, not on initial mount.

Proposed fix

Track whether the user has explicitly chosen a theme:

 export const ThemeProvider = ({ children }) => {
   const [isDark, setIsDark] = useState(false);
   const [mounted, setMounted] = useState(false);
+  const [userExplicitlyChose, setUserExplicitlyChose] = useState(false);

   useEffect(() => {
     const savedTheme = localStorage.getItem('theme-preference');
     if (savedTheme) {
       setIsDark(savedTheme === 'dark');
+      setUserExplicitlyChose(true);
     } else {
       const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
       setIsDark(prefersDark);
     }
     setMounted(true);
   }, []);

   useEffect(() => {
     if (!mounted) return;
-    localStorage.setItem('theme-preference', isDark ? 'dark' : 'light');
+    if (userExplicitlyChose) {
+      localStorage.setItem('theme-preference', isDark ? 'dark' : 'light');
+    }
     if (isDark) {
       document.documentElement.classList.add('dark');
     } else {
       document.documentElement.classList.remove('dark');
     }
   }, [isDark, mounted]);

   // ... system preference listener stays the same ...

   const toggleTheme = () => {
+    setUserExplicitlyChose(true);
     setIsDark(prev => !prev);
   };

Also applies to: 48-60

🤖 Prompt for AI Agents

In `@frontend/src/contexts/ThemeContext.jsx` around lines 33 - 45, Introduce a
"userHasPreference" (or similar) state to distinguish explicit user toggles from
system-derived initial value, update the toggle handler that sets isDark to also
set userHasPreference=true, change the useEffect that currently writes
localStorage (watching isDark and mounted) to only persist when
userHasPreference is true, and modify the system preference listener's
handleChange to update isDark only when userHasPreference is false (and keep the
initial read of localStorage to set userHasPreference if a saved preference
exists); reference the existing symbols isDark, mounted,
localStorage.getItem('theme-preference'), handleChange, and the two useEffect
hooks to locate and apply these changes.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

replace('_', ' ') only replaces the first underscore.

If any key contains multiple underscores (e.g. central_government_authority), only the first one is replaced. Use replaceAll or a regex with the global flag.

Proposed fix

-          <h3 className="font-bold text-lg capitalize mb-2 text-gray-900 dark:text-white">{key.replace('_', ' ')}</h3>
+          <h3 className="font-bold text-lg capitalize mb-2 text-gray-900 dark:text-white">{key.replaceAll('_', ' ')}</h3>

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	<h3 className="font-bold text-lg capitalize mb-2 text-gray-900 dark:text-white">{key.replace('_', ' ')}</h3>
	<h3 className="font-bold text-lg capitalize mb-2 text-gray-900 dark:text-white">{key.replaceAll('_', ' ')}</h3>

🤖 Prompt for AI Agents

In `@frontend/src/views/MapView.jsx` at line 9, The current header uses
key.replace('_', ' ') which only replaces the first underscore; update the
transformation in MapView.jsx where the header is rendered (the expression using
key.replace) to replace all underscores (e.g., use key.replaceAll('_', ' ') or
key.replace(/_/g, ' ')) so keys like "central_government_authority" become
"central government authority".

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for usage of the custom dark-* color tokens across the frontend source
echo "=== Searching for dark-bg usage ==="
rg -n 'dark-bg' -g '*.jsx' -g '*.tsx' -g '*.js' -g '*.ts' -g '*.css' -g '*.html'

echo "=== Searching for dark-card usage ==="
rg -n 'dark-card' -g '*.jsx' -g '*.tsx' -g '*.js' -g '*.ts' -g '*.css' -g '*.html'

echo "=== Searching for dark-border usage ==="
rg -n 'dark-border' -g '*.jsx' -g '*.tsx' -g '*.js' -g '*.ts' -g '*.css' -g '*.html'

Repository: RohanExploit/VishwaGuru

Length of output: 369

---

Remove the unused custom dark color tokens from Tailwind config.

The custom tokens dark-bg, dark-card, and dark-border are defined but never used anywhere in the codebase. Components consistently use standard Tailwind gray palette classes instead. Remove these tokens to avoid misleading developers.

🤖 Prompt for AI Agents

In `@frontend/tailwind.config.js` around lines 10 - 15, Remove the unused custom
dark theme tokens from the Tailwind colors config: delete the 'dark-bg',
'dark-card', and 'dark-border' entries from the colors object so only the
standard Tailwind gray palette remains; ensure no references to 'dark-bg',
'dark-card', or 'dark-border' exist elsewhere (search the repo) and remove or
replace any usages with the corresponding standard Tailwind gray classes.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Excessive documentation overhead — 12+ markdown files at project root for a 2-file feature.

This PR adds ~237 lines of code but introduces 12+ documentation files in the repository root. This creates significant clutter and maintenance burden disproportionate to the feature scope. Consider:

1. Consolidate into a single docs/dark-mode.md (or at most 2–3 files) and remove the rest.
2. Move documentation out of the project root into a docs/ directory.

Additionally, several claims in this document don't match the implementation:

• Line 121: "No initial page flash" — the ThemeProvider initializes isDark = false and reads the actual preference asynchronously, so a flash will occur for dark-preferring users.
• Line 122: "Handles localStorage being disabled" — localStorage calls are not wrapped in try/catch.
• Line 396: "START_HERE_DARK_MODE.md (this file)" — this file is IMPLEMENTATION_COMPLETE.md, not START_HERE_DARK_MODE.md.

🤖 Prompt for AI Agents

In `@IMPLEMENTATION_COMPLETE.md` around lines 1 - 428, Consolidate the dozen
root-level markdowns into a single docs/dark-mode.md (or at most 2–3 files) and
move all dark-mode documentation into the docs/ directory, removing the extra
files from the repository root; update IMPLEMENTATION_COMPLETE.md to reflect the
new paths and correct the "START_HERE_DARK_MODE.md" reference. In code, fix the
incorrect claims by updating ThemeContext.jsx: ensure ThemeProvider initializes
theme from a synchronous check to avoid initial flash (e.g., derive initial
isDark from window.matchMedia where available) and wrap all localStorage
reads/writes used by useTheme()/ThemeProvider in try/catch to safely handle
disabled storage and log/fallback appropriately. Finally, update
IMPLEMENTATION_COMPLETE.md content to remove mismatched assertions (no initial
page flash, localStorage handling) so documentation matches actual behavior.

[coderabbitai]

Actionable comments posted: 6

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (4)

frontend/src/views/ReportForm.jsx (2)

449-460: ⚠️ Potential issue | 🔴 Critical

Stray "Language" label and missing dark mode on the email field.

Line 450 introduces a "Language" label (with dark classes) that sits right before the "Email (Optional)" label on Line 451. This appears to be an accidental duplication — the actual language selector already has its own label at Line 463.

Additionally, the email input block (Lines 451–459) is entirely missing dark mode classes — the label, input, and helper text all use hardcoded light-mode styles while every other form field in this component has been updated.

🐛 Proposed fix

          <div>
-            <label className="block text-sm font-medium text-gray-700 dark:text-gray-300">Language</label>
-            <label className="block text-sm font-medium text-gray-700">Email (Optional)</label>
+            <label className="block text-sm font-medium text-gray-700 dark:text-gray-300">Email (Optional)</label>
             <input
               type="email"
-              className="mt-1 block w-full rounded-md border-gray-300 shadow-sm p-2 border"
+              className="mt-1 block w-full rounded-md border-gray-300 dark:border-gray-600 shadow-sm p-2 border bg-white dark:bg-gray-700 text-gray-900 dark:text-white"
               placeholder="Enter your email to track your reports"
               value={formData.email}
               onChange={(e) => setFormData({...formData, email: e.target.value})}
             />
-            <p className="text-xs text-gray-500 mt-1">We'll use this to group your reports under "My Reports".</p>
+            <p className="text-xs text-gray-500 dark:text-gray-400 mt-1">We'll use this to group your reports under "My Reports".</p>
           </div>

---

690-731: ⚠️ Potential issue | 🟠 Major

Nearby issues modal is entirely missing dark mode styling.

The modal overlay, container, header, list items, badges, and action button all use hardcoded light-mode classes (bg-white, text-gray-800, bg-gray-50, etc.) with no dark: variants. This will render as a bright white panel in dark mode.

frontend/src/views/Home.jsx (2)

13-90: ⚠️ Potential issue | 🔴 Critical

CameraCheckModal is defined twice — the file will not compile.

The component body appears twice: Lines 13–50 (with dark mode classes) and Lines 51–90 (without). The first definition at Line 50 is missing its closing </div> and }; before the second definition starts at Line 51, producing invalid JSX.

This pattern repeats throughout the entire file — dark-mode versions of sections are interleaved with the original versions (privacy badge at Lines 157–171, categorized features at Lines 206–230 vs 449–473, additional tools at Lines 232–239 vs 476–498, recent activity at Lines 412–566 vs 502–560). The static analyzer confirms parse errors at Lines 234–237 and 542–544 due to unclosed JSX tags.

This file is broken and will not build. It appears the dark-mode changes were pasted alongside the originals rather than replacing them. The entire file needs to be reconciled so each component/section exists exactly once with the dark mode classes applied.

---

595-607: ⚠️ Potential issue | 🔴 Critical

motion is not imported — motion.button will throw a ReferenceError.

Line 5 imports AnimatePresence from framer-motion but motion is not included, yet motion.button is used at Line 595.

🐛 Proposed fix

-import { AnimatePresence } from 'framer-motion';
+import { AnimatePresence, motion } from 'framer-motion';

🤖 Fix all issues with AI agents

In `@frontend/src/App.jsx`:
- Around line 203-239: The local AppHeader component defined in this file
shadows the imported AppHeader (imported on Line 7) causing the import to be
dead code; fix by either removing the local definition and using the imported
AppHeader component (ensure the imported AppHeader includes DarkModeToggle usage
and the same props/markup), or rename the local component (e.g., LocalAppHeader)
and update any references to it so it no longer collides with the imported
symbol; make sure to also remove the unused import if you keep the local version
to satisfy static analysis.
- Around line 522-529: Several JSX elements opened around the glass-morphism
section (the outer container div with class "max-w-7xl...", the <main> element,
the relative wrapper div, and the glass card div) are not closed after the
</Suspense> block; close them in the correct nested order and re-insert the
<AppFooter /> and the remaining outer layout closers so the structure matches:
close the glass card div, then the relative wrapper div, then </main>, then the
max-w-7xl container div, then render <AppFooter />, and finally close the outer
layout divs that wrap the whole app (the relative z-10 and the min-h-screen
containers) to restore valid JSX around the Suspense component.
- Around line 380-389: FloatingButtonsManager is redeclared locally which
shadows the import and declares an unused state showActions; either remove the
local component or remove the import at the top. To fix: if you want to use the
external component (FloatingButtonsManager import), delete the local function
declaration that defines FloatingButtonsManager (lines containing the function
that uses setView, showActions, EnhancedChatWidget, FloatingActions); otherwise
remove the import for FloatingButtonsManager and within the local definition
delete the unused useState call for showActions (and its setter) so only used
props (setView) remain. Ensure only one definition of FloatingButtonsManager
exists and that showActions is not declared if it is not read.
- Around line 50-62: Remove the orphaned LoadingSpinner fragment (the
variantClasses object, the JSX return block, and the stray closing brace) that
sits outside any function/component; specifically delete the code that defines
variantClasses and the return JSX using sizeClasses, variantClasses, className,
size and variant so the module no longer contains unparsable top-level component
code and relies on the existing import LoadingSpinner from
'./components/LoadingSpinner'.
- Around line 122-135: SuccessAlert currently only uses light-mode Tailwind
classes (e.g., bg-green-50, border-green-500, text-green-700, text-green-400) so
it looks wrong in dark mode; update the SuccessAlert component to include
matching dark: variants for the outer container, border, icon color and text
(for example add dark:bg-*, dark:border-*, dark:text-* and dark: classes
alongside the existing bg-green-50, border-green-500, text-green-700,
text-green-400) so styling mirrors ErrorAlert’s dark-mode usage; modify the
outer div, the border class on that div, the svg class (text-green-400) and the
message p (text-green-700) in the SuccessAlert component to include appropriate
dark: classes.
- Around line 138-165: NavigationBreadcrumb uses a plain <a href="/"> which
causes full page reloads; replace it with React Router's Link (import Link from
'react-router-dom') and use <Link to="/"> in the NavigationBreadcrumb component
to enable client-side navigation, and fix the label transformation which
currently uses path.replace('-', ' ') (only replaces first hyphen) by using
path.replaceAll('-', ' ') or path.replace(/-/g, ' ') so multi-hyphen segments
(e.g., smart-scan or grievance-analysis) render correctly.

🧹 Nitpick comments (2)

frontend/src/views/GrievanceView.jsx (1)

267-268: Modal backdrop mixes bg-opacity with dark:bg-opacity — consider using slash syntax.

bg-gray-600 bg-opacity-50 dark:bg-gray-950 dark:bg-opacity-75 can behave unexpectedly because bg-opacity and the background color are separate utilities. In Tailwind 3.x, the slash-alpha syntax is more reliable and readable:

♻️ Suggested simplification

-<div className="fixed inset-0 bg-gray-600 dark:bg-gray-950 bg-opacity-50 dark:bg-opacity-75 overflow-y-auto h-full w-full z-50">
+<div className="fixed inset-0 bg-gray-600/50 dark:bg-gray-950/75 overflow-y-auto h-full w-full z-50">

frontend/src/App.jsx (1)

168-170: Same single-hyphen replace issue in DetectorWrapper, and the component appears unused.

Line 170 has the same replace('-', ' ') bug. More importantly, DetectorWrapper doesn't appear to be referenced anywhere in the routes below — all detector routes either inline their back buttons or pass onBack as a prop. If it's unused, consider removing it.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Orphaned code outside any function — the app will fail to parse.

Lines 50–62 contain the tail end of what appears to be a LoadingSpinner component (variant classes, a return statement, and a closing }), but the function declaration is missing. This is a syntax error that will prevent the entire module from loading.

Given that LoadingSpinner is already imported on Line 9 (import LoadingSpinner from './components/LoadingSpinner'), this orphaned fragment should be removed entirely.

Proposed fix — remove the orphaned code

-  const variantClasses = {
-    primary: "border-blue-200 border-t-blue-600",
-    secondary: "border-orange-200 border-t-orange-500",
-    light: "border-gray-200 border-t-gray-600"
-  };
-
-  return (
-    <div className={`flex justify-center items-center ${className}`}>
-      <div className={`animate-spin rounded-full ${sizeClasses[size]} ${variantClasses[variant]}`}></div>
-      <span className="sr-only">Loading...</span>
-    </div>
-  );
-};

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const variantClasses = {
	primary: "border-blue-200 border-t-blue-600",
	secondary: "border-orange-200 border-t-orange-500",
	light: "border-gray-200 border-t-gray-600"
	};
	return (
	<div className={`flex justify-center items-center ${className}`}>
	<div className={`animate-spin rounded-full ${sizeClasses[size]} ${variantClasses[variant]}`}></div>
	<span className="sr-only">Loading...</span>
	</div>
	);
	};

🧰 Tools

🪛 Biome (2.3.13)

[error] 56-61: Illegal return statement outside of a function

(parse)

---

[error] 61-62: Expected a statement but instead found '}'.

Expected a statement here.

(parse)

🤖 Prompt for AI Agents

In `@frontend/src/App.jsx` around lines 50 - 62, Remove the orphaned
LoadingSpinner fragment (the variantClasses object, the JSX return block, and
the stray closing brace) that sits outside any function/component; specifically
delete the code that defines variantClasses and the return JSX using
sizeClasses, variantClasses, className, size and variant so the module no longer
contains unparsable top-level component code and relies on the existing import
LoadingSpinner from './components/LoadingSpinner'.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

SuccessAlert is missing dark mode styles, unlike ErrorAlert.

ErrorAlert uses dark: variants throughout (background, border, text), but SuccessAlert hardcodes light-only classes (bg-green-50, text-green-700, text-green-400). It will look out of place in dark mode.

Proposed fix

-const SuccessAlert = ({ message }) => (
-  <div className="bg-green-50 border-l-4 border-green-500 p-4 rounded-lg my-4 animate-fadeIn">
+const SuccessAlert = ({ message }) => (
+  <div className="bg-green-50 dark:bg-green-900/20 border-l-4 border-green-500 dark:border-green-700/50 p-4 rounded-lg my-4 animate-fadeIn">
     <div className="flex items-center">
       <div className="flex-shrink-0">
-        <svg className="h-5 w-5 text-green-400" fill="currentColor" viewBox="0 0 20 20">
+        <svg className="h-5 w-5 text-green-400 dark:text-green-500" fill="currentColor" viewBox="0 0 20 20">
           ...
         </svg>
       </div>
       <div className="ml-3">
-        <p className="text-sm font-medium text-green-700">{message}</p>
+        <p className="text-sm font-medium text-green-700 dark:text-green-300">{message}</p>
       </div>
     </div>
   </div>
 );

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const SuccessAlert = ({ message }) => (
	<div className="bg-green-50 border-l-4 border-green-500 p-4 rounded-lg my-4 animate-fadeIn">
	<div className="flex items-center">
	<div className="flex-shrink-0">
	<svg className="h-5 w-5 text-green-400" fill="currentColor" viewBox="0 0 20 20">
	<path fillRule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zm3.707-9.293a1 1 0 00-1.414-1.414L9 10.586 7.707 9.293a1 1 0 00-1.414 1.414l2 2a1 1 0 001.414 0l4-4z" clipRule="evenodd" />
	</svg>
	</div>
	<div className="ml-3">
	<p className="text-sm font-medium text-green-700">{message}</p>
	</div>
	</div>
	</div>
	);
	const SuccessAlert = ({ message }) => (
	<div className="bg-green-50 dark:bg-green-900/20 border-l-4 border-green-500 dark:border-green-700/50 p-4 rounded-lg my-4 animate-fadeIn">
	<div className="flex items-center">
	<div className="flex-shrink-0">
	<svg className="h-5 w-5 text-green-400 dark:text-green-500" fill="currentColor" viewBox="0 0 20 20">
	<path fillRule="evenodd" d="M10 18a8 8 0 100-16 8 8 0 000 16zm3.707-9.293a1 1 0 00-1.414-1.414L9 10.586 7.707 9.293a1 1 0 00-1.414 1.414l2 2a1 1 0 001.414 0l4-4z" clipRule="evenodd" />
	</svg>
	</div>
	<div className="ml-3">
	<p className="text-sm font-medium text-green-700 dark:text-green-300">{message}</p>
	</div>
	</div>
	</div>
	);

🤖 Prompt for AI Agents

In `@frontend/src/App.jsx` around lines 122 - 135, SuccessAlert currently only
uses light-mode Tailwind classes (e.g., bg-green-50, border-green-500,
text-green-700, text-green-400) so it looks wrong in dark mode; update the
SuccessAlert component to include matching dark: variants for the outer
container, border, icon color and text (for example add dark:bg-*,
dark:border-*, dark:text-* and dark: classes alongside the existing bg-green-50,
border-green-500, text-green-700, text-green-400) so styling mirrors
ErrorAlert’s dark-mode usage; modify the outer div, the border class on that
div, the svg class (text-green-400) and the message p (text-green-700) in the
SuccessAlert component to include appropriate dark: classes.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Breadcrumb uses <a href> instead of React Router's <Link> — causes full page reloads in this SPA.

Line 148 uses a plain <a href="/"> for the "Home" link. In a React Router app, this triggers a full page reload instead of client-side navigation. Use <Link to="/"> from react-router-dom.

Also, path.replace('-', ' ') on Line 158 only replaces the first hyphen. For paths like grievance-analysis this is fine, but multi-hyphen paths (e.g., smart-scan) would only replace the first occurrence. Use replaceAll or a regex.

Proposed fix

+import { Link } from 'react-router-dom';
 // ...
-          <a href="/" className="text-gray-500 hover:text-blue-600 transition-colors duration-200">
+          <Link to="/" className="text-gray-500 hover:text-blue-600 transition-colors duration-200">
             Home
-          </a>
+          </Link>

-            <span className={`capitalize ${index === paths.length - 1 ? 'text-blue-600 font-medium' : 'text-gray-500'}`}>
-              {path.replace('-', ' ')}
+            <span className={`capitalize ${index === paths.length - 1 ? 'text-blue-600 font-medium' : 'text-gray-500'}`}>
+              {path.replaceAll('-', ' ')}

🤖 Prompt for AI Agents

In `@frontend/src/App.jsx` around lines 138 - 165, NavigationBreadcrumb uses a
plain <a href="/"> which causes full page reloads; replace it with React
Router's Link (import Link from 'react-router-dom') and use <Link to="/"> in the
NavigationBreadcrumb component to enable client-side navigation, and fix the
label transformation which currently uses path.replace('-', ' ') (only replaces
first hyphen) by using path.replaceAll('-', ' ') or path.replace(/-/g, ' ') so
multi-hyphen segments (e.g., smart-scan or grievance-analysis) render correctly.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

AppHeader is redeclared — shadows the import on Line 7.

Line 7 imports AppHeader from './components/AppHeader', but Lines 203–239 define a new local AppHeader component that shadows it. The local definition is what actually gets used. This means the imported module is dead code, and the intent is ambiguous.

Either remove the import on Line 7 and keep the local definition, or remove the local definition and use the imported component. Keeping both is confusing and flagged by static analysis.

🧰 Tools

🪛 Biome (2.3.13)

[error] 203-203: Shouldn't redeclare 'AppHeader'. Consider to delete it or rename it.

'AppHeader' is defined here:

(lint/suspicious/noRedeclare)

🤖 Prompt for AI Agents

In `@frontend/src/App.jsx` around lines 203 - 239, The local AppHeader component
defined in this file shadows the imported AppHeader (imported on Line 7) causing
the import to be dead code; fix by either removing the local definition and
using the imported AppHeader component (ensure the imported AppHeader includes
DarkModeToggle usage and the same props/markup), or rename the local component
(e.g., LocalAppHeader) and update any references to it so it no longer collides
with the imported symbol; make sure to also remove the unused import if you keep
the local version to satisfy static analysis.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

FloatingButtonsManager is redeclared — shadows the import on Line 8.

Same issue as AppHeader: Line 8 imports FloatingButtonsManager from './components/FloatingButtonsManager', but Lines 380–389 redefine it locally. Additionally, showActions (Line 381) is declared but never read.

Remove either the import or the local definition to resolve the shadowing, and drop the unused showActions state.

If keeping the local definition, remove the import and unused state

-import FloatingButtonsManager from './components/FloatingButtonsManager';

 const FloatingButtonsManager = ({ setView }) => {
-  const [showActions, setShowActions] = useState(false);
-  
   return (
     <>
       <EnhancedChatWidget />

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const FloatingButtonsManager = ({ setView }) => {
	const [showActions, setShowActions] = useState(false);
	return (
	<>
	<EnhancedChatWidget />
	<FloatingActions setView={setView} />
	</>
	);
	};
	const FloatingButtonsManager = ({ setView }) => {
	return (
	<>
	<EnhancedChatWidget />
	<FloatingActions setView={setView} />
	</>
	);
	};

🧰 Tools

🪛 Biome (2.3.13)

[error] 380-380: Shouldn't redeclare 'FloatingButtonsManager'. Consider to delete it or rename it.

'FloatingButtonsManager' is defined here:

(lint/suspicious/noRedeclare)

🤖 Prompt for AI Agents

In `@frontend/src/App.jsx` around lines 380 - 389, FloatingButtonsManager is
redeclared locally which shadows the import and declares an unused state
showActions; either remove the local component or remove the import at the top.
To fix: if you want to use the external component (FloatingButtonsManager
import), delete the local function declaration that defines
FloatingButtonsManager (lines containing the function that uses setView,
showActions, EnhancedChatWidget, FloatingActions); otherwise remove the import
for FloatingButtonsManager and within the local definition delete the unused
useState call for showActions (and its setter) so only used props (setView)
remain. Ensure only one definition of FloatingButtonsManager exists and that
showActions is not declared if it is not read.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Unclosed JSX tags — the glass-morphism wrapper divs are never closed.

Lines 522–529 introduce several new wrapping elements (<div> for max-w-7xl, <main>, <div> for relative container, <div> for the glass card), but after </Suspense> at Line 682, there are only two </div> closings (Lines 684–685) before the function return ends. This leaves multiple tags unclosed — </main>, and at least two more </div> are missing, along with the <AppFooter /> component and the closing of the outer layout <div>.

This will produce a JSX parse error once the other parse error (Lines 50–62) is fixed. Please ensure every opened tag is properly closed. The expected closing structure after </Suspense> should be roughly:

              </div> {/* glass card */}
            </div> {/* relative */}
          </main>
        </div> {/* max-w-7xl */}
        <AppFooter />
      </div> {/* relative z-10 */}
    </div> {/* min-h-screen */}

Also applies to: 684-686

🤖 Prompt for AI Agents

In `@frontend/src/App.jsx` around lines 522 - 529, Several JSX elements opened
around the glass-morphism section (the outer container div with class
"max-w-7xl...", the <main> element, the relative wrapper div, and the glass card
div) are not closed after the </Suspense> block; close them in the correct
nested order and re-insert the <AppFooter /> and the remaining outer layout
closers so the structure matches: close the glass card div, then the relative
wrapper div, then </main>, then the max-w-7xl container div, then render
<AppFooter />, and finally close the outer layout divs that wrap the whole app
(the relative z-10 and the min-h-screen containers) to restore valid JSX around
the Suspense component.