Review DaisyUI replacement strategy documents

next steps

• Write a browser-based orphaned-class auditor (using Chrome MCP) to visually verify no regressions on key pages
• Iterate on any visual drift found by the auditor
• Remove the daisyui npm dependency and Tailwind plugin once the shim is confirmed visually
• Optionally consolidate individual component classes to Flux or Blade components over time

key decisions

• Use a shim approach (register palette in tailwind.config.js + component classes in app.css) rather than converting everything to Flux, because daisyUI v2 exposes its palette as Tailwind color names and its components as plain CSS classes, making a shim low-risk and reversible
• Use exact winter palette values from daisyUI source (hex for base colors, hsl for -content/-focus) to avoid visual drift
• Add `<alpha-value>` placeholder to all hsl() color definitions so Tailwind opacity modifiers work
• Keep the two original audit documents as history; replace the consolidated plan with the corrected version

open questions

• Will the shimmed classes produce identical visual output on every page, or are there subtle differences in spacing/color that only a browser render can catch?
• Are there any dynamically-generated daisyUI classes from the 9 PHP files that the static grep missed?
• Should the shim be committed as-is or should the daisyui npm dependency be removed first?

next steps

—

key decisions

• Stage only the four files (tailwind.config.js, app.css, plan.md, orphan-audit.js) and exclude pre-existing lock-file changes from the commit.
• Use a reusable browser-console auditor script to detect orphaned daisyUI classes at runtime.

open questions

—

next steps

—

key decisions

• Use the browser MCP to navigate to public routes and run the orphan auditor + screenshot for visual confirmation.
• Focus on /subreddits and /authors as representative public pages exercising buttons, badges, selects, inputs, and the hero base-200 tint.

open questions

—

next steps

—

key decisions

• Sweep admin pages (dashboard, app-settings, subreddits, patreon) with the orphan auditor and screenshots.
• Test the CSS-only dropdown by clicking it to confirm :focus-within behavior works.
• Test the collapse by clicking a title; empty data prevented expansion but the identical mechanism was proven by the dropdown.
• Inject a component swatch into the live page to visually confirm all variants (toggles, progress bars, buttons, badges, checkboxes) render correctly.

open questions

—

next steps

—

key decisions

• Temporarily restore the pre-shim state (git checkout HEAD~1 for the two files) to rebuild with daisyUI plugin on, then restore current state, to show the real CSS savings.
• Record both raw and gzipped sizes for compiled.css.

open questions

—

next steps

—

key decisions

• Remove daisyui from package.json dependencies, then npm install to prune it and its transitive deps (color, css-selector-tokenizer).
• Stage only package.json and package-lock.json, leaving the pre-existing yarn.lock drift unstaged.
• Verify final prod build matches the baseline (241.7 KiB) and daisyUI artifacts are absent.

open questions

—

next steps

—

key decisions

• Confirm no yarn references exist in deploy/CI/config scripts before removing.
• Use git rm to stage the deletion and commit separately.

open questions

—

next steps

• Mark Steps 1–2 as done in docs/daisyui-removal-plan.md (deferred from this segment).
• Proceed with Step 3 incremental consolidation: swap shim classes for Flux/Blade components bucket-by-bucket.

key decisions

• Perform a comprehensive sweep of all daisyUI v2 component classes against the compiled CSS to catch any missed orphans.
• Extract daisyUI's exact .table / .table-compact CSS rules from the temporarily restored package and reproduce them faithfully using the registered palette colors.
• Use @apply with the registered color tokens (base-100, base-200, base-300, base-content) instead of HSL variables.

open questions

—

next steps

—

key decisions

• Use browser CSS engine scan plus static grep across all views for authoritative completeness check.
• Filter daisyUI vocabulary first to avoid false positives from non-daisyUI classes.

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

—

key decisions

• Use native <details>/<summary> instead of daisyUI's fragile focus hack for better accessibility and robustness.
• Hide the disclosure triangle via list-none and [&::-webkit-details-marker]:hidden to preserve visual appearance.

open questions

—

next steps

—

key decisions

• Use Alpine x-data/@click/@click.away/x-show/x-transition pattern matching the existing <x-dropdown> component.
• Inline menu-item styles to avoid needing the .menu shim.

open questions

—

next steps

• Proceed with alert consolidation, form controls, badges, buttons, cards, and trivial singletons.

key decisions

• Full consolidation including buttons/cards, using existing components where possible (x-status-pill, x-callout, Jetstream buttons) and inline Tailwind where visual match requires it.

open questions

—

next steps

• Proceed with alert → x-callout conversion.
• Then form controls, buttons, cards, and remaining singletons.

key decisions

• Use x-status-pill for admin status labels (visual match).
• Use inline Tailwind for the public flair badge to preserve solid purple appearance (status-pill's light style wouldn't match).
• Add 'info' variant to x-callout to support alert-info mapping.

open questions

—

next steps

—

key decisions

• Complex alert with custom SVG icon and action button kept inline Tailwind rather than forcing into x-callout structure.

open questions

—

next steps

—

key decisions

• Kept btn/form/table classes as first-class project component CSS (not daisyUI residue) to avoid Jetstream <x-button> collision and verbose inline utilities.
• Complex-title card (Their Subreddits) kept inline Tailwind instead of x-info-card.

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

• Pinpoint the exact file rendering the User Flair card on /authors/{name}.
• Determine if accent='amber' is intentional or a leftover from previous styling.
• Check all info-card accent usages for consistency.

key decisions

—

open questions

• Why does the User Flair card have accent='amber' while other info-cards on the same page do not?
• Is this accent intentional or a styling artifact?

next steps

—

key decisions

• The amber accent on User Flair is intentional design, not a regression.
• The undefined accent="rose" in info-card needs fixing (add rose to the component or change the usage).

open questions

—

next steps

—

key decisions

• The verification pass caught stale pre-shim reasoning in some findings; corrected before synthesizing.
• Chip system fragmentation is the dominant theme (15+ inline implementations with drifting colors/padding).

open questions

—

next steps

—

key decisions

• Used a single <x-icon-check> component with overridable class for color/size, rather than separate components per color.
• Used a single <x-freshness-indicator> component with label/caption props, rather than duplicating the pulsing dot markup.
• Added rose, green, and red to info-card's accent match array to support existing usage and future needs.

open questions

—

next steps

• Re-enumerate remaining inline chip files with corrected grep patterns (the previous grep returned 0 results, likely due to scope or pattern issues).
• Migrate remaining inline chips in subreddits, posts, locations, and other public views to use <x-filter-chip> or <x-location-chip> as appropriate.
• Consider creating a status-badge component for Banned/Private/Quarantined pills if they appear in public views.

key decisions

• Used a single <x-filter-chip> component with variant prop rather than separate components per chip type, matching the design system's documented pattern.
• The filter-chip-rail's removable chips (with wire:click × buttons) were fixed inline rather than migrated to the component, because the remove-button structure is rail-specific.
• Chip colors follow §7 semantics: flair→amber, orientation→violet, location→teal, sort→rose, region→indigo.

open questions

• Why did the grep for remaining inline chip files return 0 results? Possible causes: files outside the scoped directories, pattern mismatch (e.g., bg-teal-100 text-teal-800 vs bg-teal-50 text-teal-700), or all chips already migrated.

next steps

—

key decisions

• Use workflow with migrate+verify phases for safety due to fatigue-error risk.

open questions

—

next steps

—

key decisions

• Left subreddit status badges, flair hero gradient, subreddit-public-breakdown winter tokens as deliberate decisions (low value or needs design call).

open questions

—

next steps

—

key decisions

• Status badges untouched; icon/count-bearing location chips left for later extension.

open questions

—

next steps

—

key decisions

• Compute title in @php to avoid Blade @if inside component attribute (caused ParseError).

open questions

—

next steps

• Begin admin-side UI review.

key decisions

—

open questions

• Subreddit status badges (Banned/Private/etc.) design decision still open.

next steps

—

key decisions

• Admin consolidation scope: Tier 1 + 2 now, handle Tier 3 opportunistically
• Canonical badge system: x-status-pill (keep chip partial only for domain state→color maps)
• Breadcrumb collapse is the highest-value mechanical win (~52 files)

open questions

—

next steps

• Commit Wave 1 changes
• Run view:cache compile gate
• Spot-check in Chrome
• Launch Wave 2: a11y div→button swaps, hand-rolled badges→x-status-pill, empty-state adoption, CSS bug fixes, Sentry nav removal

key decisions

• All 52 hand-rolled breadcrumb headers are breadcrumb-only (no search forms/actions) — transform is uniform
• Leave @section('title') untouched; only add :breadcrumbs prop to keep <title> byte-identical
• city/show.blade.php correctly skipped due to dynamic @if conditionals in breadcrumb
• Sentry nav removal and route navigability audit folded into subsequent waves

open questions

—

next steps

—

key decisions

• Used array_merge for conditional trails (state/index) to preserve dynamic behavior.
• Left city/show with its hand-rolled nav due to dynamic conditionals and query-string URL.

open questions

—

next steps

—

key decisions

• Removed from both menus for consistency; Sentry remains accessible via the admin dashboard.
• Admin, Usage, and Feature Access links preserved.

open questions

—

next steps

—

key decisions

• Used codebase-consistent variant mapping (Indexed→success, Ingested→info) rather than generic color rubric.
• Reverted string-hash flags from admin variant to info to match show page consistency.
• Kept pre-existing false-positive diagnostics (blade-in-attribute patterns) as known linter limitations.

open questions

—

next steps

• Migrate admin-media-operations nav to use the canonical media-tabs partial.
• Migrate scraper-v2 and sentry route-based tab bars to <x-admin-tabs>.
• Run compile gate and commit Wave 3.

key decisions

• Used blue accent for media tabs to match existing blue styling.
• Canonical media tab set includes all 6 tabs with optional badges (opsPending, deletePending).
• Component supports badge_variant for red count badges (e.g., pending delete counts).

open questions

—

next steps

—

key decisions

• Preserved explicit $active contract for Sentry child routes (e.g., issue-show keeps 'issues' tab active) rather than switching to route-based detection.
• Kept Sentry tabs indigo and scraper-v2 tabs indigo (their existing colors) — no accent unification across areas yet.

open questions

—

next steps

—

key decisions

• Kept texts tabs blue (their existing color) to avoid clashing with other blue accents on those pages.
• Used accent='blue' on the texts-tabs partial to match the original styling.

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

• Link admin.posts.updates from the admin post detail page
• Link admin.redditusers.recently-updated-posts from the redditusers index or retire the page
• Link admin.embedding-stream-monitor from the embeddings dashboard

key decisions

• The 4 .search routes are correctly not nav links — they are GET form-action endpoints.
• admin.media.networks is a Route::redirect alias, not a page — no link needed.
• The 6 buried section pages (cities, states, banned-emails, conductor, health, spam-reports) are reachable via hierarchical or contextual deep links — acceptable.

open questions

• Should admin.banned-emails.index and admin.conductor.index get dashboard quick-links for discoverability?