From 0f9d12c3cf74b7fc0b6c4b8522564ee9d81ee183 Mon Sep 17 00:00:00 2001 From: Naser Mansour Date: Sun, 27 Sep 2026 22:02:23 +0300 Subject: [PATCH] Prepare project for pipeline takeover: task tracker, UX doc, CLAUDE.md pointers Adds docs/tasks/ (16 epics + 102 stories converted to task/subtask files with statuses.md as the new status source of truth) and docs/ux-design.md (retrospective design-system reference), and points CLAUDE.md at them. docs/prd.md and docs/architecture.md are kept as BMAD wrote them; the legacy docs/stories/, docs/epics/, docs/qa/gates/ and .bmad-core/ stay in place as historical/traceability records, superseded but not deleted. Co-Authored-By: Claude Sonnet 5 --- CLAUDE.md | 12 +++- docs/tasks/1-1.md | 24 ++++++++ docs/tasks/1-2.md | 35 +++++++++++ docs/tasks/1-3.md | 39 ++++++++++++ docs/tasks/1-4.md | 50 +++++++++++++++ docs/tasks/1.md | 21 +++++++ docs/tasks/10-1.md | 22 +++++++ docs/tasks/10-2.md | 27 +++++++++ docs/tasks/10-3.md | 22 +++++++ docs/tasks/10-4.md | 22 +++++++ docs/tasks/10-5.md | 22 +++++++ docs/tasks/10-6.md | 21 +++++++ docs/tasks/10.md | 28 +++++++++ docs/tasks/11-1.md | 30 +++++++++ docs/tasks/11-2.md | 45 ++++++++++++++ docs/tasks/11-3.md | 33 ++++++++++ docs/tasks/11-4.md | 28 +++++++++ docs/tasks/11.md | 23 +++++++ docs/tasks/12-1.md | 24 ++++++++ docs/tasks/12-2.md | 23 +++++++ docs/tasks/12-3.md | 28 +++++++++ docs/tasks/12-4.md | 22 +++++++ docs/tasks/12-5.md | 21 +++++++ docs/tasks/12-6.md | 21 +++++++ docs/tasks/12.md | 19 ++++++ docs/tasks/13-1.md | 20 ++++++ docs/tasks/13-2.md | 21 +++++++ docs/tasks/13-3.md | 20 ++++++ docs/tasks/13-4.md | 24 ++++++++ docs/tasks/13-5.md | 26 ++++++++ docs/tasks/13.md | 22 +++++++ docs/tasks/14-1.md | 21 +++++++ docs/tasks/14-2.md | 21 +++++++ docs/tasks/14-3.md | 21 +++++++ docs/tasks/14-4.md | 21 +++++++ docs/tasks/14-5.md | 23 +++++++ docs/tasks/14-6.md | 20 ++++++ docs/tasks/14.md | 26 ++++++++ docs/tasks/15-1.md | 19 ++++++ docs/tasks/15-2.md | 24 ++++++++ docs/tasks/15-3.md | 26 ++++++++ docs/tasks/15.md | 19 ++++++ docs/tasks/16-1.md | 22 +++++++ docs/tasks/16-2.md | 23 +++++++ docs/tasks/16-3.md | 21 +++++++ docs/tasks/16-4.md | 21 +++++++ docs/tasks/16-5.md | 22 +++++++ docs/tasks/16-6.md | 22 +++++++ docs/tasks/16.md | 28 +++++++++ docs/tasks/2-1.md | 39 ++++++++++++ docs/tasks/2-2.md | 36 +++++++++++ docs/tasks/2-3.md | 33 ++++++++++ docs/tasks/2-4.md | 38 ++++++++++++ docs/tasks/2-5.md | 46 ++++++++++++++ docs/tasks/2.md | 22 +++++++ docs/tasks/3-1.md | 33 ++++++++++ docs/tasks/3-2.md | 38 ++++++++++++ docs/tasks/3-3.md | 34 +++++++++++ docs/tasks/3-4.md | 19 ++++++ docs/tasks/3-5.md | 38 ++++++++++++ docs/tasks/3-6.md | 35 +++++++++++ docs/tasks/3-7.md | 39 ++++++++++++ docs/tasks/3-8.md | 30 +++++++++ docs/tasks/3-9.md | 40 ++++++++++++ docs/tasks/3.md | 24 ++++++++ docs/tasks/4-1.md | 30 +++++++++ docs/tasks/4-2.md | 40 ++++++++++++ docs/tasks/4-3.md | 29 +++++++++ docs/tasks/4-4.md | 34 +++++++++++ docs/tasks/4-5.md | 29 +++++++++ docs/tasks/4-6.md | 30 +++++++++ docs/tasks/4.md | 21 +++++++ docs/tasks/5-1.md | 33 ++++++++++ docs/tasks/5-2.md | 30 +++++++++ docs/tasks/5-3.md | 26 ++++++++ docs/tasks/5-4.md | 32 ++++++++++ docs/tasks/5-5.md | 27 +++++++++ docs/tasks/5.md | 21 +++++++ docs/tasks/6-1.md | 33 ++++++++++ docs/tasks/6-10.md | 34 +++++++++++ docs/tasks/6-2.md | 39 ++++++++++++ docs/tasks/6-3.md | 37 +++++++++++ docs/tasks/6-4.md | 42 +++++++++++++ docs/tasks/6-5.md | 30 +++++++++ docs/tasks/6-6.md | 33 ++++++++++ docs/tasks/6-7.md | 52 ++++++++++++++++ docs/tasks/6-8.md | 26 ++++++++ docs/tasks/6-9.md | 30 +++++++++ docs/tasks/6.md | 21 +++++++ docs/tasks/7-1.md | 44 ++++++++++++++ docs/tasks/7-2.md | 33 ++++++++++ docs/tasks/7-3.md | 25 ++++++++ docs/tasks/7-4.md | 32 ++++++++++ docs/tasks/7-5.md | 27 +++++++++ docs/tasks/7-6.md | 27 +++++++++ docs/tasks/7.md | 21 +++++++ docs/tasks/8-1.md | 27 +++++++++ docs/tasks/8-10.md | 27 +++++++++ docs/tasks/8-2.md | 29 +++++++++ docs/tasks/8-3.md | 32 ++++++++++ docs/tasks/8-4.md | 25 ++++++++ docs/tasks/8-5.md | 23 +++++++ docs/tasks/8-6.md | 27 +++++++++ docs/tasks/8-7.md | 25 ++++++++ docs/tasks/8-8.md | 29 +++++++++ docs/tasks/8-9.md | 30 +++++++++ docs/tasks/8.md | 20 ++++++ docs/tasks/9-1.md | 27 +++++++++ docs/tasks/9-10.md | 30 +++++++++ docs/tasks/9-11.md | 30 +++++++++ docs/tasks/9-2.md | 26 ++++++++ docs/tasks/9-3.md | 27 +++++++++ docs/tasks/9-4.md | 38 ++++++++++++ docs/tasks/9-5.md | 33 ++++++++++ docs/tasks/9-6.md | 28 +++++++++ docs/tasks/9-7.md | 36 +++++++++++ docs/tasks/9-8.md | 31 ++++++++++ docs/tasks/9-9.md | 43 +++++++++++++ docs/tasks/9.md | 21 +++++++ docs/tasks/statuses.md | 123 +++++++++++++++++++++++++++++++++++++ docs/ux-design.md | 135 +++++++++++++++++++++++++++++++++++++++++ 121 files changed, 3628 insertions(+), 1 deletion(-) create mode 100644 docs/tasks/1-1.md create mode 100644 docs/tasks/1-2.md create mode 100644 docs/tasks/1-3.md create mode 100644 docs/tasks/1-4.md create mode 100644 docs/tasks/1.md create mode 100644 docs/tasks/10-1.md create mode 100644 docs/tasks/10-2.md create mode 100644 docs/tasks/10-3.md create mode 100644 docs/tasks/10-4.md create mode 100644 docs/tasks/10-5.md create mode 100644 docs/tasks/10-6.md create mode 100644 docs/tasks/10.md create mode 100644 docs/tasks/11-1.md create mode 100644 docs/tasks/11-2.md create mode 100644 docs/tasks/11-3.md create mode 100644 docs/tasks/11-4.md create mode 100644 docs/tasks/11.md create mode 100644 docs/tasks/12-1.md create mode 100644 docs/tasks/12-2.md create mode 100644 docs/tasks/12-3.md create mode 100644 docs/tasks/12-4.md create mode 100644 docs/tasks/12-5.md create mode 100644 docs/tasks/12-6.md create mode 100644 docs/tasks/12.md create mode 100644 docs/tasks/13-1.md create mode 100644 docs/tasks/13-2.md create mode 100644 docs/tasks/13-3.md create mode 100644 docs/tasks/13-4.md create mode 100644 docs/tasks/13-5.md create mode 100644 docs/tasks/13.md create mode 100644 docs/tasks/14-1.md create mode 100644 docs/tasks/14-2.md create mode 100644 docs/tasks/14-3.md create mode 100644 docs/tasks/14-4.md create mode 100644 docs/tasks/14-5.md create mode 100644 docs/tasks/14-6.md create mode 100644 docs/tasks/14.md create mode 100644 docs/tasks/15-1.md create mode 100644 docs/tasks/15-2.md create mode 100644 docs/tasks/15-3.md create mode 100644 docs/tasks/15.md create mode 100644 docs/tasks/16-1.md create mode 100644 docs/tasks/16-2.md create mode 100644 docs/tasks/16-3.md create mode 100644 docs/tasks/16-4.md create mode 100644 docs/tasks/16-5.md create mode 100644 docs/tasks/16-6.md create mode 100644 docs/tasks/16.md create mode 100644 docs/tasks/2-1.md create mode 100644 docs/tasks/2-2.md create mode 100644 docs/tasks/2-3.md create mode 100644 docs/tasks/2-4.md create mode 100644 docs/tasks/2-5.md create mode 100644 docs/tasks/2.md create mode 100644 docs/tasks/3-1.md create mode 100644 docs/tasks/3-2.md create mode 100644 docs/tasks/3-3.md create mode 100644 docs/tasks/3-4.md create mode 100644 docs/tasks/3-5.md create mode 100644 docs/tasks/3-6.md create mode 100644 docs/tasks/3-7.md create mode 100644 docs/tasks/3-8.md create mode 100644 docs/tasks/3-9.md create mode 100644 docs/tasks/3.md create mode 100644 docs/tasks/4-1.md create mode 100644 docs/tasks/4-2.md create mode 100644 docs/tasks/4-3.md create mode 100644 docs/tasks/4-4.md create mode 100644 docs/tasks/4-5.md create mode 100644 docs/tasks/4-6.md create mode 100644 docs/tasks/4.md create mode 100644 docs/tasks/5-1.md create mode 100644 docs/tasks/5-2.md create mode 100644 docs/tasks/5-3.md create mode 100644 docs/tasks/5-4.md create mode 100644 docs/tasks/5-5.md create mode 100644 docs/tasks/5.md create mode 100644 docs/tasks/6-1.md create mode 100644 docs/tasks/6-10.md create mode 100644 docs/tasks/6-2.md create mode 100644 docs/tasks/6-3.md create mode 100644 docs/tasks/6-4.md create mode 100644 docs/tasks/6-5.md create mode 100644 docs/tasks/6-6.md create mode 100644 docs/tasks/6-7.md create mode 100644 docs/tasks/6-8.md create mode 100644 docs/tasks/6-9.md create mode 100644 docs/tasks/6.md create mode 100644 docs/tasks/7-1.md create mode 100644 docs/tasks/7-2.md create mode 100644 docs/tasks/7-3.md create mode 100644 docs/tasks/7-4.md create mode 100644 docs/tasks/7-5.md create mode 100644 docs/tasks/7-6.md create mode 100644 docs/tasks/7.md create mode 100644 docs/tasks/8-1.md create mode 100644 docs/tasks/8-10.md create mode 100644 docs/tasks/8-2.md create mode 100644 docs/tasks/8-3.md create mode 100644 docs/tasks/8-4.md create mode 100644 docs/tasks/8-5.md create mode 100644 docs/tasks/8-6.md create mode 100644 docs/tasks/8-7.md create mode 100644 docs/tasks/8-8.md create mode 100644 docs/tasks/8-9.md create mode 100644 docs/tasks/8.md create mode 100644 docs/tasks/9-1.md create mode 100644 docs/tasks/9-10.md create mode 100644 docs/tasks/9-11.md create mode 100644 docs/tasks/9-2.md create mode 100644 docs/tasks/9-3.md create mode 100644 docs/tasks/9-4.md create mode 100644 docs/tasks/9-5.md create mode 100644 docs/tasks/9-6.md create mode 100644 docs/tasks/9-7.md create mode 100644 docs/tasks/9-8.md create mode 100644 docs/tasks/9-9.md create mode 100644 docs/tasks/9.md create mode 100644 docs/tasks/statuses.md create mode 100644 docs/ux-design.md diff --git a/CLAUDE.md b/CLAUDE.md index dc7dcb7..3650593 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -85,7 +85,17 @@ php artisan make:model ModelName -mf - `app/Enums/` - UserType, UserStatus, ConsultationType, ConsultationStatus, PaymentStatus, TimelineStatus, PostStatus - `docs/prd.md` - Full product requirements document - `docs/architecture.md` - Complete architecture document -- `docs/stories/` - User story specifications +- `docs/ux-design.md` - Design system reference (colors, typography, layout, components — retrospective, written 2026-09-27) +- `docs/tasks/` - **Current task/status tracker** (`statuses.md` is the status source of truth). One row per epic (parent) and per story (subtask), e.g. `3.md` / `3-4.md`. +- `docs/stories/`, `docs/epics/`, `docs/qa/gates/` - **Legacy.** Original BMAD-agent build records (98→102 stories across 16 epics). Kept for implementation history and traceability, no longer the status source — `docs/tasks/statuses.md` superseded them 2026-09-27. `.bmad-core/` and `.claude/commands/BMad/` are the retired BMAD toolchain, also kept but unused. + +## Pipeline takeover (2026-09-27) + +This project was built by BMAD agents and has been handed to a different pipeline (Jarvis/ElenosLabs +tooling) for any further work. `docs/tasks/statuses.md` is now authoritative for what's open — most +subtasks are `QA Review` (BMAD's "Ready for Review" with no final close-out), a couple are `Draft` +(never started: `3-9` guest booking request, `13-5` auth-page visual QA). Cross-check a task's own +`docs/stories/story--*.md` file for full history/QA notes before starting new work on it. ### Services - `app/Services/AvailabilityService.php` - Calculates available time slots for bookings diff --git a/docs/tasks/1-1.md b/docs/tasks/1-1.md new file mode 100644 index 0000000..c381e8b --- /dev/null +++ b/docs/tasks/1-1.md @@ -0,0 +1,24 @@ +--- +id: 1-1 +title: 1-1 Project Setup & Database Schema +status: Done +date: 2026-09-27 +parent: 1 +--- + +## Description + +As a developer, I want the Laravel 12 project configured with all required packages and complete database schema, So that the foundation is established for all subsequent feature development. Full implementation history: docs/stories/story-1.1-project-setup-database-schema.md + +## Acceptance Criteria + +- [ ] Laravel 12 project created with Livewire 3, Volt, Flux UI +- [ ] Tailwind CSS 4 configured with `@theme` directive +- [ ] Database migrations for all core tables: +- [ ] Model factories created for testing +- [ ] Development environment working (`composer run dev`) +- [ ] SQLite configured for development database +- [ ] All migrations run without errors +- [ ] Factories generate valid test data +- [ ] All database tables have proper indexes +- [ ] Foreign key constraints properly defined diff --git a/docs/tasks/1-2.md b/docs/tasks/1-2.md new file mode 100644 index 0000000..5519605 --- /dev/null +++ b/docs/tasks/1-2.md @@ -0,0 +1,35 @@ +--- +id: 1-2 +title: 1-2 Authentication & Role System +status: Done +date: 2026-09-27 +parent: 1 +--- + +## Description + +As an admin, I want a secure authentication system with Admin/Client roles, So that only authorized users can access the platform with appropriate permissions. Full implementation history: docs/stories/story-1.2-authentication-role-system.md + +## Acceptance Criteria + +- [ ] Fortify configured with custom Volt views +- [ ] Login page with bilingual support (Arabic/English) +- [ ] Session timeout after 2 hours of inactivity +- [ ] Rate limiting on login attempts (5 attempts per minute) +- [ ] Admin role with full access to all features +- [ ] Client role with restricted access (own data only) +- [ ] Registration feature DISABLED (admin creates all accounts) +- [ ] CSRF protection enabled on all forms +- [ ] Password hashing using bcrypt +- [ ] Custom middleware for admin authorization +- [ ] Secure session configuration +- [ ] Remember me functionality (optional) +- [ ] Login redirects to appropriate dashboard: +- [ ] Logout clears session properly and redirects to login page +- [ ] Admin middleware protects admin-only routes (return 403 for unauthorized) +- [ ] Failed login attempts logged to `admin_logs` table +- [ ] Deactivated users cannot log in +- [ ] Login form validates inputs properly +- [ ] Error messages are clear and bilingual +- [ ] All test scenarios in "Testing" section pass +- [ ] No security vulnerabilities diff --git a/docs/tasks/1-3.md b/docs/tasks/1-3.md new file mode 100644 index 0000000..7b47480 --- /dev/null +++ b/docs/tasks/1-3.md @@ -0,0 +1,39 @@ +--- +id: 1-3 +title: 1-3 Bilingual Infrastructure (Arabic/English) +status: QA Review +date: 2026-09-27 +parent: 1 +--- + +## Description + +As a user (admin or client), I want full bilingual support with Arabic as primary and English as secondary language, So that I can use the platform in my preferred language with proper RTL/LTR layout. Context: Integrates with: Laravel localization, Tailwind CSS, user preferences; Technology: Laravel lang files, Tailwind RTL, Google Fonts; Follows pattern: Laravel localization best practices. Full implementation history: docs/stories/story-1.3-bilingual-infrastructure.md + +## Acceptance Criteria + +- [ ] Language files for Arabic (ar) and English (en) +- [ ] Language toggle in navigation (visible on all pages) +- [ ] User language preference stored in `users.preferred_language` +- [ ] Guest language stored in session (persists across page loads) +- [ ] RTL layout for Arabic, LTR for English +- [ ] All UI elements translatable via `__()` helper +- [ ] Language switch preserves current page (redirect back to same URL) +- [ ] Form validation messages display in current locale +- [ ] Missing translations fall back to key name (not break page) +- [ ] Arabic: DD/MM/YYYY format +- [ ] English: MM/DD/YYYY format +- [ ] Both: 12-hour time format (AM/PM) +- [ ] Both: Western numerals (123) - no Arabic numerals +- [ ] Arabic fonts: Cairo or Tajawal (Google Fonts) +- [ ] English fonts: Montserrat or Lato (Google Fonts) +- [ ] Font weights: 300, 400, 600, 700 +- [ ] font-display: swap for performance +- [ ] Language middleware sets locale from user preference or session +- [ ] Direction attribute (`dir="rtl"` or `dir="ltr"`) on HTML element +- [ ] Tailwind RTL utilities working +- [ ] Forms align correctly in both directions +- [ ] No hardcoded strings in views +- [ ] All translation keys organized by feature +- [ ] Tests verify language switching +- [ ] No layout breaks when switching languages diff --git a/docs/tasks/1-4.md b/docs/tasks/1-4.md new file mode 100644 index 0000000..594d0d4 --- /dev/null +++ b/docs/tasks/1-4.md @@ -0,0 +1,50 @@ +--- +id: 1-4 +title: 1-4 Base UI & Navigation +status: Done +date: 2026-09-27 +parent: 1 +--- + +## Description + +As a website visitor or logged-in user, I want a professional, responsive navigation system with brand colors, So that I can easily navigate the platform on any device. Context: Integrates with: Flux UI Free, Tailwind CSS 4, bilingual system; Technology: Livewire Volt, Flux UI components, Alpine.js; Follows pattern: Flux UI navbar patterns, mobile-first design. - **Logo SVG:** Required at public/images/logo.svg - **Fallback:** Text "Libra" in gold displayed if logo asset not available - **Logo Specs:** SVG format preferred, min 120px width desktop, 80px mobile - **Note:** Logo asset to be provided by client; use text fallback during development. Full implementation history: docs/stories/story-1.4-base-ui-navigation.md + +## Acceptance Criteria + +- [ ] Primary: Dark Navy Blue (#0A1F44) - backgrounds, headers +- [ ] Accent: Gold (#D4AF37) - buttons, links, accents +- [ ] Light Gold: #F4E4B8 - hover states +- [ ] Off-White/Cream: #F9F7F4 - cards, content areas +- [ ] Charcoal Gray: #2C3E50 - secondary text +- [ ] Custom Tailwind colors configured via @theme +- [ ] Fixed top position +- [ ] Navy blue background +- [ ] Logo placement: left on desktop, centered on mobile +- [ ] Main menu items: Home, Booking, Posts, Login/Dashboard +- [ ] Language toggle (Arabic/English) visible +- [ ] Responsive mobile hamburger menu +- [ ] Gold text for links, hover effects +- [ ] Full-width dropdown or slide-in +- [ ] Navy background with gold text +- [ ] Touch-friendly targets (44px+ height) +- [ ] Smooth open/close animation +- [ ] Close on outside click or navigation +- [ ] Navy blue background +- [ ] Libra logo (smaller version) +- [ ] Firm contact information +- [ ] Links: Terms of Service, Privacy Policy +- [ ] Copyright notice with current year +- [ ] Sticky footer (always at bottom of viewport) +- [ ] Card-based layouts with proper shadows and border-radius +- [ ] Consistent spacing using Tailwind utilities +- [ ] Container max-width: 1200px, centered +- [ ] WCAG AA contrast compliance verified +- [ ] Flux UI components used where available +- [ ] Works with RTL and LTR layouts +- [ ] Navigation state reflects current page +- [ ] Login/logout state reflected in menu +- [ ] Responsive on all breakpoints (mobile, tablet, desktop) +- [ ] No horizontal scroll on any viewport +- [ ] Fast loading (minimal CSS/JS) +- [ ] Tests verify navigation rendering diff --git a/docs/tasks/1.md b/docs/tasks/1.md new file mode 100644 index 0000000..45cc829 --- /dev/null +++ b/docs/tasks/1.md @@ -0,0 +1,21 @@ +--- +id: 1 +title: 1 Core Foundation & Infrastructure +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Establishes the foundational Laravel 12 application: authentication with Admin/Client roles via Fortify, full bilingual (Arabic/English) infrastructure with RTL/LTR layout switching, and the base UI/navigation shell that every later epic builds on. + +## Acceptance Criteria + +- [ ] Laravel 12 project configured and running +- [ ] Database schema designed and migrations created +- [ ] Fortify authentication working (login only, no self-registration) +- [ ] Admin and Client roles implemented with proper authorization +- [ ] Bilingual infrastructure (Arabic primary, English secondary) +- [ ] RTL/LTR layout switching functional +- [ ] Base UI framework with brand colors (Navy #0A1F44, Gold #D4AF37) +- [ ] Navigation system with language toggle diff --git a/docs/tasks/10-1.md b/docs/tasks/10-1.md new file mode 100644 index 0000000..f856a8c --- /dev/null +++ b/docs/tasks/10-1.md @@ -0,0 +1,22 @@ +--- +id: 10-1 +title: 10-1 Core CSS Theme Update +status: QA Review +date: 2026-09-27 +parent: 10 +--- + +## Description + +As a developer I want to update the Tailwind CSS theme color variables So that the application uses the new LIBRA for Rights brand palette. - resources/css/app.css - Main theme file. Full implementation history: docs/stories/story-10.1-core-css-theme-update.md + +## Acceptance Criteria + +- [ ] AC1: Update Color Variables in `resources/css/app.css`: Given the current theme uses Navy Blue + Gold palette; When I update the `@theme` block; Then the following color mappings are applied: +- [ ] AC2: Maintain Backward Compatibility Aliases: Given existing components use `navy`, `gold`, `cream` class names; When the theme is updated; Then aliases are created so existing classes continue to work: +- [ ] AC3: Update Semantic Aliases: Given semantic aliases exist for components; When theme is updated; Then these mappings are correct: +- [ ] AC4: Update Button Styles: Given button classes use gold/navy colors; When theme is updated; Then `.btn-primary` and `.btn-secondary` use new palette: +- [ ] AC5: Update Form Focus States: Given form inputs have gold focus rings; When theme is updated; Then focus states use Warm Gray: +- [ ] AC6: Update Prose Class: Given `.prose-navy` class exists for blog content; When theme is updated; Then rename to `.prose-brand` or update colors: +- [ ] AC7: Status Colors Unchanged: Given status colors serve functional purposes; When theme is updated; Then these remain unchanged: +- [ ] AC8: WCAG AA Contrast Compliance: Given accessibility requirements; When new colors are applied; Then all text/background combinations meet WCAG AA: diff --git a/docs/tasks/10-2.md b/docs/tasks/10-2.md new file mode 100644 index 0000000..1067539 --- /dev/null +++ b/docs/tasks/10-2.md @@ -0,0 +1,27 @@ +--- +id: 10-2 +title: 10-2 Blade Component Color Migration +status: QA Review +date: 2026-09-27 +parent: 10 +--- + +## Description + +As a developer I want to update all Blade components and pages to use the new color palette So that the entire application has consistent branding. Full implementation history: docs/stories/story-10.2-blade-component-color-migration.md + +## Acceptance Criteria + +- [ ] AC1: Navigation Component Updated: Given `resources/views/components/navigation.blade.php` uses old colors; When I update the component; Then the following changes are applied: +- [ ] AC2: Footer Component Updated: Given `resources/views/components/footer.blade.php` uses old colors; When I update the component; Then the following changes are applied: +- [ ] AC3: Logo Component Updated: Given `resources/views/components/logo.blade.php` references logo files; When I update the component; Then it references the correct logo variant for the background +- [ ] AC4: Language Toggle Updated: Given `resources/views/components/language-toggle.blade.php` uses old colors; When I update the component; Then colors match new palette +- [ ] AC5: Card Components Updated: Given card components use old colors; When I update `resources/views/components/ui/card.blade.php`; Then the following changes are applied: +- [ ] AC6: Stat Card Component Updated: Given `resources/views/components/ui/stat-card.blade.php` uses old colors; When I update the component; Then colors match new palette +- [ ] AC7: Spinner Component Updated: Given `resources/views/components/spinner.blade.php` uses old colors; When I update the component; Then spinner uses Charcoal or Warm Gray +- [ ] AC8: Toast Component Updated: Given `resources/views/components/toast.blade.php` uses old colors; When I update the component; Then colors match new palette (status colors remain unchanged) +- [ ] AC9: Public Pages Updated: Given public pages use old colors; When I update the following pages; Then they use the new palette: +- [ ] AC10: Post Pages Updated: Given post display pages use old colors; When I update the following pages; Then they use the new palette: +- [ ] AC11: Public Layout Updated: Given `resources/views/components/layouts/public.blade.php` uses old colors; When I update the layout; Then it uses the new palette +- [ ] AC12: RTL Layout Integrity: Given the application supports RTL (Arabic); When colors are updated; Then RTL layout displays correctly with new colors +- [ ] AC13: Responsive Appearance: Given the application is responsive; When colors are updated; Then all breakpoints display correctly (mobile, tablet, desktop) diff --git a/docs/tasks/10-3.md b/docs/tasks/10-3.md new file mode 100644 index 0000000..3447a87 --- /dev/null +++ b/docs/tasks/10-3.md @@ -0,0 +1,22 @@ +--- +id: 10-3 +title: 10-3 Email Template Color Update +status: QA Review +date: 2026-09-27 +parent: 10 +--- + +## Description + +As a developer I want to update email templates to use the new brand colors So that all email communications reflect the new LIBRA for Rights branding. **Theme CSS:** - resources/views/vendor/mail/html/themes/default.css. Full implementation history: docs/stories/story-10.3-email-template-color-update.md + +## Acceptance Criteria + +- [ ] AC1: Email Theme CSS Updated: Given `resources/views/vendor/mail/html/themes/default.css` uses old colors; When I update the stylesheet; Then the following changes are applied: +- [ ] AC2: Email Header Component Updated: Given `resources/views/vendor/mail/html/header.blade.php` may have inline styles; When I update the component; Then any inline color references use new palette +- [ ] AC3: Email Footer Component Updated: Given `resources/views/vendor/mail/html/footer.blade.php` may have inline styles; When I update the component; Then any inline color references use new palette +- [ ] AC4: Button Component Updated: Given `resources/views/vendor/mail/html/button.blade.php` may have inline styles; When I update the component; Then primary buttons use: +- [ ] AC5: Panel Component Updated: Given `resources/views/vendor/mail/html/panel.blade.php` may have inline styles; When I update the component; Then panel border uses Warm Gray (`#C9C4BA`) +- [ ] AC6: Email Logo Updated: Given email header displays the logo; When emails are sent; Then the logo matches the new brand identity +- [ ] AC7: All Email Templates Tested: Given the application sends various email types; When I test each email template; Then colors display correctly: +- [ ] AC8: Plain Text Fallback Unaffected: Given plain text email templates exist; When colors are updated; Then plain text templates continue to work (no color changes needed) diff --git a/docs/tasks/10-4.md b/docs/tasks/10-4.md new file mode 100644 index 0000000..9d76053 --- /dev/null +++ b/docs/tasks/10-4.md @@ -0,0 +1,22 @@ +--- +id: 10-4 +title: 10-4 PDF Template Color Update +status: QA Review +date: 2026-09-27 +parent: 10 +--- + +## Description + +As a developer I want to update PDF export templates to use the new brand colors So that all exported documents reflect the new LIBRA for Rights branding. **PDF Templates:** - resources/views/pdf/users-export.blade.php - resources/views/pdf/consultations-export.blade.php - resources/views/pdf/timelines-export.blade.php - resources/views/pdf/monthly-report.blade.php. Full implementation history: docs/stories/story-10.4-pdf-template-color-update.md + +## Acceptance Criteria + +- [ ] AC1: Users Export PDF Updated: Given `resources/views/pdf/users-export.blade.php` uses old colors; When I update the template; Then the following changes are applied: +- [ ] AC2: Consultations Export PDF Updated: Given `resources/views/pdf/consultations-export.blade.php` uses old colors; When I update the template; Then colors match the new brand palette +- [ ] AC3: Timelines Export PDF Updated: Given `resources/views/pdf/timelines-export.blade.php` uses old colors; When I update the template; Then colors match the new brand palette +- [ ] AC4: Monthly Report PDF Updated: Given `resources/views/pdf/monthly-report.blade.php` uses old colors; When I update the template; Then the following changes are applied: +- [ ] AC5: Monthly Report Service Updated: Given `app/Services/MonthlyReportService.php` may contain color references; When I review the service; Then any hardcoded colors are updated to new palette +- [ ] AC6: PDF Logo Updated: Given PDF templates include the logo; When PDFs are generated; Then the logo matches the new brand identity +- [ ] AC7: Print-Friendly Colors: Given PDFs are often printed; When colors are updated; Then they remain legible when printed in grayscale +- [ ] AC8: All PDF Exports Tested: Given the admin can export various data types; When I test each PDF export; Then colors display correctly and documents are professional diff --git a/docs/tasks/10-5.md b/docs/tasks/10-5.md new file mode 100644 index 0000000..f4948d8 --- /dev/null +++ b/docs/tasks/10-5.md @@ -0,0 +1,22 @@ +--- +id: 10-5 +title: 10-5 Logo and SVG Assets Update +status: QA Review +date: 2026-09-27 +parent: 10 +--- + +## Description + +As a developer I want to update all logo files and SVG assets to match the new brand So that the application displays the correct LIBRA for Rights logo everywhere. **Logo Files:** - public/images/logo.svg - Primary full-color logo - public/images/logo-reversed.svg - For dark backgrounds - public/images/logo-mono.svg - Single-color version - public/images/logo.png - PNG fallback. Full implementation history: docs/stories/story-10.5-logo-assets-update.md + +## Acceptance Criteria + +- [ ] AC1: Primary Logo Updated: Given `public/images/logo.svg` contains the old Scales of Justice logo with gold colors; When I update or replace the logo; Then the new botanical/wheat logo is displayed with correct colors: +- [ ] AC2: Reversed Logo Updated: Given `public/images/logo-reversed.svg` is for dark backgrounds; When I update or replace the logo; Then the logo displays correctly on Charcoal backgrounds: +- [ ] AC3: Monochrome Logo Updated: Given `public/images/logo-mono.svg` exists for single-color applications; When I update or replace the logo; Then the logo uses appropriate single color from new palette +- [ ] AC4: PNG Logo Updated: Given `public/images/logo.png` is used in some contexts; When I update or replace the logo; Then the PNG matches the new SVG logo +- [ ] AC5: Favicon Updated: Given the application has a favicon; When I review favicon files; Then they are updated to match new brand (if applicable) +- [ ] AC6: Logo Component References Correct Files: Given `resources/views/components/logo.blade.php` references logo files; When I review the component; Then it uses the correct logo variant based on context (light/dark background) +- [ ] AC7: Logo Displays Correctly Throughout App: Given the logo appears in multiple locations; When logos are updated; Then they display correctly in: +- [ ] AC8: Logo Clear Space Maintained: Given brand guidelines specify clear space around logo; When logo is displayed; Then minimum padding/margin is maintained as per `docs/brand.md` diff --git a/docs/tasks/10-6.md b/docs/tasks/10-6.md new file mode 100644 index 0000000..fa2972d --- /dev/null +++ b/docs/tasks/10-6.md @@ -0,0 +1,21 @@ +--- +id: 10-6 +title: 10-6 Documentation Update +status: QA Review +date: 2026-09-27 +parent: 10 +--- + +## Description + +As a developer I want to update all documentation to reflect the new brand colors So that future development references accurate color information. **Core Documentation:** - CLAUDE.md - docs/prd.md - docs/architecture.md - docs/brand.md (verify accuracy). Full implementation history: docs/stories/story-10.6-documentation-update.md + +## Acceptance Criteria + +- [ ] AC1: CLAUDE.md Updated: Given `CLAUDE.md` contains color guidance; When I update the file; Then the following sections are updated: +- [ ] AC2: PRD Updated: Given `docs/prd.md` contains detailed color specifications; When I update the document; Then the following sections are updated: +- [ ] AC3: Architecture Document Updated: Given `docs/architecture.md` may contain color references; When I review and update the document; Then any color references are updated to new palette +- [ ] AC4: Epic 9 Stories Referenced as Superseded: Given Epic 9 stories implemented the original Navy+Gold palette; When I review Epic 9 story files; Then a note is added indicating colors were updated in Epic 10: +- [ ] AC5: Epic 10 Document Updated: Given `docs/epics/epic-10-brand-color-refresh.md` exists; When all stories are complete; Then the epic document is updated with completion status +- [ ] AC6: brand.md Verified Accurate: Given `docs/brand.md` defines the new brand; When I review the document; Then it accurately describes: +- [ ] AC7: No Stale Color References: Given documentation should be accurate; When I search all markdown files for old hex values; Then no references to old colors remain: diff --git a/docs/tasks/10.md b/docs/tasks/10.md new file mode 100644 index 0000000..80959d7 --- /dev/null +++ b/docs/tasks/10.md @@ -0,0 +1,28 @@ +--- +id: 10 +title: 10 Brand Color Refresh +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +A brownfield color migration replacing the original Navy+Gold palette with a Charcoal + Warm Gray earth-tone palette across the whole application: core CSS theme, all Blade components, email templates, PDF templates, logo/SVG assets, and documentation. Superseded again by Epic 12. + +## Acceptance Criteria + +- [ ] Story 10.1: Core CSS theme updated with new colors +- [ ] Story 10.2: All Blade components using new palette +- [ ] Story 10.3: Email templates updated +- [ ] Story 10.4: PDF templates updated +- [ ] Story 10.5: Logo files updated/replaced +- [ ] Story 10.6: All documentation updated +- [ ] All pages render correctly with new colors +- [ ] WCAG AA contrast compliance verified +- [ ] RTL layout displays correctly +- [ ] Responsive design intact across breakpoints +- [ ] PDF exports display new branding +- [ ] Email templates display new branding +- [ ] Code formatted with Pint +- [ ] All existing tests passing +- [ ] Visual QA completed on all major pages diff --git a/docs/tasks/11-1.md b/docs/tasks/11-1.md new file mode 100644 index 0000000..03cf8d6 --- /dev/null +++ b/docs/tasks/11-1.md @@ -0,0 +1,30 @@ +--- +id: 11-1 +title: 11-1 Database Schema & Model Updates +status: QA Review +date: 2026-09-27 +parent: 11 +--- + +## Description + +As a developer, I want to extend the consultation system to support guest bookings, So that consultations can be created for both registered clients and anonymous guests. The existing foreign key consultations_user_id_foreign cascades on delete. With nullable user_id: - Guest consultations won't be affected by user deletions (they have no user) - Client consultations still cascade delete when user is deleted. Full implementation history: docs/stories/story-11.1-database-schema-model-updates.md + +## Acceptance Criteria + +- [ ] `user_id` column changed to nullable on `consultations` table +- [ ] `guest_name` column added (varchar 255, nullable) +- [ ] `guest_email` column added (varchar 255, nullable) +- [ ] `guest_phone` column added (varchar 50, nullable) +- [ ] Index added on `guest_email` for 1-per-day lookup performance +- [ ] Migration is reversible without data loss +- [ ] Existing consultations with `user_id` unaffected +- [ ] `Consultation` model updated with new fillable fields +- [ ] `isGuest()` helper method returns true when `user_id` is null +- [ ] `getClientName()` helper returns guest_name or user->full_name +- [ ] `getClientEmail()` helper returns guest_email or user->email +- [ ] `getClientPhone()` helper returns guest_phone or user->phone +- [ ] Model validation ensures either user_id OR guest fields are present +- [ ] `ConsultationFactory` updated with `guest()` state +- [ ] Guest state generates fake guest_name, guest_email, guest_phone +- [ ] Guest state sets user_id to null diff --git a/docs/tasks/11-2.md b/docs/tasks/11-2.md new file mode 100644 index 0000000..723309b --- /dev/null +++ b/docs/tasks/11-2.md @@ -0,0 +1,45 @@ +--- +id: 11-2 +title: 11-2 Public Booking Form with Custom Captcha +status: QA Review +date: 2026-09-27 +parent: 11 +--- + +## Description + +As a website visitor, I want to request a consultation without creating an account, So that I can easily reach out to the lawyer for legal assistance. Full implementation history: docs/stories/story-11.2-public-booking-form.md + +## Acceptance Criteria + +- [ ] `/booking` route displays guest booking form for unauthenticated visitors +- [ ] Logged-in users redirected to `/client/consultations/book` +- [ ] Page uses public layout (`x-layouts.public`) +- [ ] Bilingual support (Arabic/English) +- [ ] Mobile responsive design +- [ ] Reuses existing `availability-calendar` Livewire component +- [ ] Shows available time slots (same as client view) +- [ ] Blocked/booked times not selectable +- [ ] Full name field (required, min 3 chars, max 255) +- [ ] Email field (required, valid email format) +- [ ] Phone field (required, valid format) +- [ ] Problem summary field (required, min 20 chars, max 2000) +- [ ] All fields have clear labels and validation messages +- [ ] Form follows Flux UI patterns +- [ ] Math-based captcha (e.g., "What is 7 + 3?") +- [ ] Question generated server-side, answer stored in session +- [ ] User must enter correct answer to submit +- [ ] Refresh button to get new captcha question +- [ ] Captcha validates before form submission +- [ ] Bilingual captcha labels +- [ ] Check if email has pending/approved booking for selected date +- [ ] If limit reached, show error message and prevent submission +- [ ] Clear error message explaining the limit +- [ ] Limit applies per email address per calendar day +- [ ] Maximum 5 booking attempts per IP per 24 hours +- [ ] Rate limit error shown if exceeded +- [ ] Step 1: Select date/time from calendar +- [ ] Step 2: Fill contact info + problem summary + captcha +- [ ] Step 3: Confirmation screen showing all details +- [ ] Step 4: Submit creates guest consultation (status: pending) +- [ ] Success message with instructions to check email diff --git a/docs/tasks/11-3.md b/docs/tasks/11-3.md new file mode 100644 index 0000000..7eedb79 --- /dev/null +++ b/docs/tasks/11-3.md @@ -0,0 +1,33 @@ +--- +id: 11-3 +title: 11-3 Guest Email Notifications & Admin Integration +status: QA Review +date: 2026-09-27 +parent: 11 +--- + +## Description + +As a guest who submitted a booking, I want to receive email confirmations about my booking status, So that I know my request was received and can track its progress. As an admin, I want to see guest contact information when reviewing bookings, So that I can contact them and manage their appointments. Full implementation history: docs/stories/story-11.3-guest-notifications-admin.md + +## Acceptance Criteria + +- [ ] Guest receives confirmation email when booking submitted +- [ ] Guest receives approval email when booking approved (with date/time details) +- [ ] Guest receives rejection email when booking rejected +- [ ] All emails use existing email template/branding +- [ ] Emails sent to guest_email address +- [ ] Bilingual support based on site locale at submission time +- [ ] Guest bookings appear in pending list alongside client bookings +- [ ] Guest bookings show "Guest" badge/indicator +- [ ] Guest name, email, phone displayed in list +- [ ] Click through to booking review shows full guest details +- [ ] Guest contact info displayed prominently +- [ ] Guest name shown instead of user name +- [ ] Guest email shown with mailto link +- [ ] Guest phone shown with tel link +- [ ] Approve/reject workflow works for guest bookings +- [ ] Email notifications sent to guest on status change +- [ ] `NewBookingAdminEmail` updated to handle guest bookings +- [ ] Admin email shows guest contact info for guest bookings +- [ ] Admin email shows client info for client bookings diff --git a/docs/tasks/11-4.md b/docs/tasks/11-4.md new file mode 100644 index 0000000..6b62b49 --- /dev/null +++ b/docs/tasks/11-4.md @@ -0,0 +1,28 @@ +--- +id: 11-4 +title: 11-4 Documentation Updates +status: QA Review +date: 2026-09-27 +parent: 11 +--- + +## Description + +As a developer or stakeholder, I want documentation to accurately reflect guest booking functionality, So that future development and maintenance has accurate reference material. Full implementation history: docs/stories/story-11.4-documentation-updates.md + +## Acceptance Criteria + +- [ ] Section 5.4 (Booking & Consultation System) updated with guest booking flow +- [ ] Guest vs client booking distinction documented +- [ ] 1-per-day limit for guests documented +- [ ] Custom captcha requirement documented +- [ ] Rate limiting rules documented +- [ ] Guest data handling documented +- [ ] Database schema section updated with guest fields +- [ ] Change log entry added +- [ ] CaptchaService documented in Services section +- [ ] Guest booking flow documented +- [ ] Database schema changes noted +- [ ] Any new patterns or services mentioned if needed +- [ ] Epic 11 marked as complete +- [ ] All story checkboxes marked done diff --git a/docs/tasks/11.md b/docs/tasks/11.md new file mode 100644 index 0000000..f729b4a --- /dev/null +++ b/docs/tasks/11.md @@ -0,0 +1,23 @@ +--- +id: 11 +title: 11 Guest Booking +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Extends the booking system to unauthenticated visitors: a public `/booking` form with custom (non-third-party) captcha and a 1-per-day-by-email limit, guest-specific email notifications, and admin visibility/handling of guest requests inside the existing booking review workflow, via new database schema/model support for nullable `user_id`. + +## Acceptance Criteria + +- [ ] All stories completed with acceptance criteria met +- [ ] Existing client booking tests still pass +- [ ] New tests cover guest booking scenarios +- [ ] Admin can manage guest bookings through existing interface +- [ ] Guest receives appropriate email notifications +- [ ] Custom captcha working correctly +- [ ] 1-per-day limit enforced +- [ ] No regression in existing features +- [ ] Bilingual support (Arabic/English) for guest form and emails +- [ ] PRD and documentation updated diff --git a/docs/tasks/12-1.md b/docs/tasks/12-1.md new file mode 100644 index 0000000..fcb369a --- /dev/null +++ b/docs/tasks/12-1.md @@ -0,0 +1,24 @@ +--- +id: 12-1 +title: 12-1 Logo Asset Deployment and CSS Layout Updates +status: QA Review +date: 2026-09-27 +parent: 12 +--- + +## Description + +As a developer I want to deploy the new square logo with Palestinian tatreez patterns and update CSS layouts So that the application displays the new brand identity correctly throughout the website. **Components:** - resources/views/components/navigation.blade.php - resources/views/components/footer.blade.php - resources/views/components/logo.blade.php - resources/views/components/app-logo.blade.php - resources/views/components/app-logo-icon.blade.php. Full implementation history: docs/stories/story-12.1-logo-asset-deployment.md + +## Acceptance Criteria + +- [ ] AC1: Logo Files Deployed to Public Directory: Given logo files have been generated in the `logo/` folder; When I deploy them to the public directory; Then the following files are placed correctly: +- [ ] AC2: Navigation Component Updated for Square Logo: Given the navigation uses a horizontal logo layout; When I update `resources/views/components/navigation.blade.php`; Then the following changes are applied: +- [ ] AC3: Footer Component Updated for Square Logo: Given the footer uses the logo; When I update `resources/views/components/footer.blade.php`; Then the following changes are applied: +- [ ] AC4: Logo Blade Component Updated: Given `resources/views/components/logo.blade.php` references logo files; When I update the component; Then it: +- [ ] AC5: Auth Pages Logo Updated: Given auth pages (login, password reset, etc.) display the logo; When I update auth page layouts; Then the square logo displays correctly: +- [ ] AC6: Favicon Displays in Browser Tab: Given the new favicon files are deployed; When I view the application in a browser; Then the botanical design icon appears in: +- [ ] AC7: Mobile App Icons Updated: Given mobile manifest files reference app icons; When I update `public/manifest.json` (if exists) or meta tags; Then mobile icons reference the new files: +- [ ] AC8: Logo Displays Correctly on All Breakpoints: Given the application is responsive; When I test the logo on different screen sizes; Then it displays correctly: +- [ ] AC9: RTL Layout Support: Given the application supports RTL (Arabic); When viewing in Arabic mode; Then the logo displays correctly without mirroring +- [ ] AC10: Old Logo Files Removed: Given old SVG logo files exist; When deployment is complete; Then the following old files are removed or archived: diff --git a/docs/tasks/12-2.md b/docs/tasks/12-2.md new file mode 100644 index 0000000..921ac97 --- /dev/null +++ b/docs/tasks/12-2.md @@ -0,0 +1,23 @@ +--- +id: 12-2 +title: 12-2 Core CSS Theme Update - Dark Charcoal & Warm Gold Palette +status: QA Review +date: 2026-09-27 +parent: 12 +--- + +## Description + +As a developer I want to update the Tailwind CSS theme to use the new dark charcoal and warm gold color palette So that the application reflects the refined LIBRA for Rights brand colors. - resources/css/app.css - Main theme file. Full implementation history: docs/stories/story-12.2-core-css-theme-update.md + +## Acceptance Criteria + +- [ ] AC1: Update Color Variables in `resources/css/app.css`: Given the current theme uses Olive Green palette; When I update the `@theme` block; Then the following color mappings are applied: +- [ ] AC2: Add Color Variants for UI States: Given the new palette needs hover and active states; When I update the theme; Then these additional variants are defined: +- [ ] AC3: Update Button Styles: Given button classes use the primary/accent colors; When theme is updated; Then `.btn-primary` and `.btn-secondary` use new palette: +- [ ] AC4: Update Form Focus States: Given form inputs have focus rings; When theme is updated; Then focus states use Warm Gold: +- [ ] AC5: Update Link Colors: Given links use accent colors; When theme is updated; Then link colors use warm gold: +- [ ] AC6: Status Colors Unchanged: Given status colors serve functional purposes; When theme is updated; Then these remain unchanged: +- [ ] AC7: WCAG AA Contrast Compliance: Given accessibility requirements; When new colors are applied; Then all text/background combinations meet WCAG AA: +- [ ] AC8: Update Prose Class: Given `.prose-brand` class exists for blog content; When theme is updated; Then prose colors use new palette: +- [ ] AC9: Build Succeeds: Given CSS changes are made; When I run `npm run build`; Then the build completes successfully without errors diff --git a/docs/tasks/12-3.md b/docs/tasks/12-3.md new file mode 100644 index 0000000..65cd96a --- /dev/null +++ b/docs/tasks/12-3.md @@ -0,0 +1,28 @@ +--- +id: 12-3 +title: 12-3 Blade Component Color Migration - Dark Charcoal & Warm Gold +status: QA Review +date: 2026-09-27 +parent: 12 +--- + +## Description + +As a developer I want to update all Blade components and pages to use the new dark charcoal and warm gold palette So that the entire application has consistent branding. Full implementation history: docs/stories/story-12.3-blade-component-color-migration.md + +## Acceptance Criteria + +- [ ] AC1: Navigation Component Updated: Given `resources/views/components/navigation.blade.php` uses current colors; When I update the component; Then the following changes are applied: +- [ ] AC2: Footer Component Updated: Given `resources/views/components/footer.blade.php` uses current colors; When I update the component; Then the following changes are applied: +- [ ] AC3: Card Components Updated: Given card components use accent colors; When I update `resources/views/components/ui/card.blade.php`; Then the following changes are applied: +- [ ] AC4: Stat Card Component Updated: Given `resources/views/components/ui/stat-card.blade.php` uses colors; When I update the component; Then accent colors use new palette: +- [ ] AC5: Spinner Component Updated: Given `resources/views/components/spinner.blade.php` uses colors; When I update the component; Then spinner uses Warm Gold (`#A68966`) +- [ ] AC6: Toast Component Updated: Given `resources/views/components/toast.blade.php` uses colors; When I update the component; Then default/info toast uses Warm Gold (status colors remain unchanged) +- [ ] AC7: Language Toggle Updated: Given `resources/views/components/language-toggle.blade.php` uses colors; When I update the component; Then : +- [ ] AC8: Public Pages Updated: Given public pages use accent colors; When I update the following pages; Then they use the new palette: +- [ ] AC9: Post Pages Updated: Given post display pages use colors; When I update the following pages; Then they use the new palette: +- [ ] AC10: Admin Dashboard Components Updated: Given admin dashboard uses accent colors; When I update admin components; Then they use new palette: +- [ ] AC11: Client Dashboard Components Updated: Given client dashboard uses accent colors; When I update client components; Then they use new palette consistently +- [ ] AC12: Public Layout Updated: Given `resources/views/components/layouts/public.blade.php` uses colors; When I update the layout; Then it uses the new palette: +- [ ] AC13: RTL Layout Integrity: Given the application supports RTL (Arabic); When colors are updated; Then RTL layout displays correctly with new colors +- [ ] AC14: Responsive Appearance: Given the application is responsive; When colors are updated; Then all breakpoints display correctly (mobile, tablet, desktop) diff --git a/docs/tasks/12-4.md b/docs/tasks/12-4.md new file mode 100644 index 0000000..f36ef5b --- /dev/null +++ b/docs/tasks/12-4.md @@ -0,0 +1,22 @@ +--- +id: 12-4 +title: 12-4 Email Template Color Update - Dark Charcoal & Warm Gold +status: QA Review +date: 2026-09-27 +parent: 12 +--- + +## Description + +As a developer I want to update email templates to use the new dark charcoal and warm gold colors So that all email communications reflect the refined LIBRA for Rights branding. **Theme CSS:** - resources/views/vendor/mail/html/themes/default.css. Full implementation history: docs/stories/story-12.4-email-template-color-update.md + +## Acceptance Criteria + +- [ ] AC1: Email Theme CSS Updated: Given `resources/views/vendor/mail/html/themes/default.css` uses current colors; When I update the stylesheet; Then the following changes are applied: +- [ ] AC2: Email Header Component Updated: Given `resources/views/vendor/mail/html/header.blade.php` has inline styles; When I update the component; Then : +- [ ] AC3: Email Footer Component Updated: Given `resources/views/vendor/mail/html/footer.blade.php` has inline styles; When I update the component; Then any inline color references use new palette: +- [ ] AC4: Button Component Updated: Given `resources/views/vendor/mail/html/button.blade.php` may have inline styles; When I update the component; Then primary buttons use: +- [ ] AC5: Panel Component Updated: Given `resources/views/vendor/mail/html/panel.blade.php` may have inline styles; When I update the component; Then panel border uses Gold Light (`#C4A882`) +- [ ] AC6: All Email Templates Tested: Given the application sends various email types; When I test each email template; Then colors display correctly: +- [ ] AC7: Plain Text Fallback Unaffected: Given plain text email templates exist; When colors are updated; Then plain text templates continue to work (no color changes needed) +- [ ] AC8: Email Client Compatibility: Given emails are viewed in various clients; When I test the templates; Then they render correctly in: diff --git a/docs/tasks/12-5.md b/docs/tasks/12-5.md new file mode 100644 index 0000000..02d706c --- /dev/null +++ b/docs/tasks/12-5.md @@ -0,0 +1,21 @@ +--- +id: 12-5 +title: 12-5 PDF Template Color Update - Dark Charcoal & Warm Gold +status: QA Review +date: 2026-09-27 +parent: 12 +--- + +## Description + +As a developer I want to update PDF export templates to use the new dark charcoal and warm gold colors So that all exported documents reflect the refined LIBRA for Rights branding. **PDF Templates:** - resources/views/pdf/users-export.blade.php - resources/views/pdf/consultations-export.blade.php - resources/views/pdf/timelines-export.blade.php - resources/views/pdf/monthly-report.blade.php. Full implementation history: docs/stories/story-12.5-pdf-template-color-update.md + +## Acceptance Criteria + +- [ ] AC1: Users Export PDF Updated: Given `resources/views/pdf/users-export.blade.php` uses current colors; When I update the template; Then the following changes are applied: +- [ ] AC2: Consultations Export PDF Updated: Given `resources/views/pdf/consultations-export.blade.php` uses current colors; When I update the template; Then colors match the new palette: +- [ ] AC3: Timelines Export PDF Updated: Given `resources/views/pdf/timelines-export.blade.php` uses current colors; When I update the template; Then colors match the new palette: +- [ ] AC4: Monthly Report PDF Updated: Given `resources/views/pdf/monthly-report.blade.php` uses current colors; When I update the template; Then the following changes are applied: +- [ ] AC5: Monthly Report Service Updated: Given `app/Services/MonthlyReportService.php` contains color references for charts; When I update the service; Then chart colors use new palette: +- [ ] AC6: Print-Friendly Colors: Given PDFs are often printed; When colors are updated; Then they remain legible when printed: +- [ ] AC7: All PDF Exports Tested: Given the admin can export various data types; When I test each PDF export; Then colors display correctly and documents are professional: diff --git a/docs/tasks/12-6.md b/docs/tasks/12-6.md new file mode 100644 index 0000000..c436aa6 --- /dev/null +++ b/docs/tasks/12-6.md @@ -0,0 +1,21 @@ +--- +id: 12-6 +title: 12-6 Brand Documentation Update - Dark Charcoal & Warm Gold +status: QA Review +date: 2026-09-27 +parent: 12 +--- + +## Description + +As a developer I want to update all brand documentation to reflect the new dark charcoal and warm gold color palette So that documentation accurately represents the current brand identity. **Documentation:** - docs/brand.md - Primary brand documentation - CLAUDE.md - Project instructions - docs/architecture.md - Architecture documentation - docs/prd.md - Product requirements. Full implementation history: docs/stories/story-12.6-documentation-update.md + +## Acceptance Criteria + +- [ ] AC1: Update `docs/brand.md`: Given the brand documentation references old colors; When I update the file; Then the following sections are updated: +- [ ] AC2: Update `CLAUDE.md`: Given CLAUDE.md contains design requirements with old colors; When I update the file; Then the Design Requirements section reflects new palette: +- [ ] AC3: Update `docs/architecture.md` (if applicable): Given architecture docs may reference brand colors; When I review the file; Then any color references are updated to new palette +- [ ] AC4: Update `docs/prd.md` (if applicable): Given PRD may reference brand colors; When I review the file; Then any color references are updated to new palette +- [ ] AC5: Update Test Color Assertions: Given tests may assert specific color values; When I review test files; Then color assertions are updated: +- [ ] AC6: Review and Update Code Comments: Given code comments may reference old color names; When I review key files; Then comments are updated: +- [ ] AC7: Update Logo Generation Instructions (if exists): Given `docs/logo-generation-instructions.md` may exist; When I review the file; Then any color references match new palette diff --git a/docs/tasks/12.md b/docs/tasks/12.md new file mode 100644 index 0000000..c562e0f --- /dev/null +++ b/docs/tasks/12.md @@ -0,0 +1,19 @@ +--- +id: 12 +title: 12 Branding Refresh (Logo + Color Scheme) +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Rolls out the new square LIBRA logo with Palestinian tatreez patterns and a Dark Forest Green + Warm Gold color scheme: logo asset deployment, core CSS theme update, Blade component and email/PDF template color migration, and brand documentation updates. This is the palette that `docs/brand.md` documents as current. + +## Acceptance Criteria + +- [ ] All stories completed with acceptance criteria met +- [ ] New logo displays correctly across all pages and devices +- [ ] Color scheme is consistent throughout the application +- [ ] Brand documentation is updated +- [ ] No regression in existing features +- [ ] Visual QA completed on major pages diff --git a/docs/tasks/13-1.md b/docs/tasks/13-1.md new file mode 100644 index 0000000..121cc01 --- /dev/null +++ b/docs/tasks/13-1.md @@ -0,0 +1,20 @@ +--- +id: 13-1 +title: 13-1 Language Toggle Visibility Enhancement +status: QA Review +date: 2026-09-27 +parent: 13 +--- + +## Description + +As a user on authentication pages I want to clearly see and interact with the language toggle So that I can easily switch between Arabic and English. - resources/views/components/language-toggle.blade.php. Full implementation history: docs/stories/story-13.1-language-toggle-visibility.md + +## Acceptance Criteria + +- [ ] AC1: Update Light Variant Text Color: Given the language toggle has a `light` variant for light backgrounds; When viewed on auth pages (white/cream background); Then the inactive language uses `text-primary` (Dark Forest Green #2D3624) instead of `text-body/70` +- [ ] AC2: Update Light Variant Hover State: Given the user hovers over an inactive language option; When the variant is `light`; Then the hover state uses: +- [ ] AC3: Update Light Variant Separator Color: Given the separator `|` between languages; When the variant is `light`; Then it uses `text-primary/50` instead of `text-body/30` for better visibility +- [ ] AC4: Dark Variant Unchanged: Given the language toggle has a `dark` variant for dark backgrounds (navigation bar); When viewed on the public navigation; Then the existing styling remains unchanged: +- [ ] AC5: Active State Unchanged: Given the currently active language; When displayed in either variant; Then it maintains the existing active styling: +- [ ] AC6: Contrast Compliance: Given accessibility requirements; When the light variant is used on Warm Cream background (#F4F1EA); Then the text contrast meets WCAG AA: diff --git a/docs/tasks/13-2.md b/docs/tasks/13-2.md new file mode 100644 index 0000000..f026e81 --- /dev/null +++ b/docs/tasks/13-2.md @@ -0,0 +1,21 @@ +--- +id: 13-2 +title: 13-2 Auth Layout Split Design Update +status: QA Review +date: 2026-09-27 +parent: 13 +--- + +## Description + +As a visitor to the authentication pages I want to see a visually appealing split-screen layout with the LIBRA branding So that the login experience feels professional and aligned with the brand identity. - resources/views/components/layouts/auth/split.blade.php. Full implementation history: docs/stories/story-13.2-auth-split-layout.md + +## Acceptance Criteria + +- [ ] AC1: Left Panel - Brand Side (Desktop): Given the split layout is viewed on desktop (lg+ breakpoint); When the page loads; Then the left panel displays: +- [ ] AC2: Right Panel - Form Side (Desktop): Given the split layout is viewed on desktop; When the page loads; Then the right panel displays: +- [ ] AC3: Mobile Layout: Given the split layout is viewed on mobile (below lg breakpoint); When the page loads; Then : +- [ ] AC4: RTL (Arabic) Support: Given the user's locale is Arabic; When the split layout renders; Then : +- [ ] AC5: Language Toggle Positioning: Given the language toggle component; When displayed on the split layout; Then : +- [ ] AC6: Remove Inspiring Quotes: Given the existing split layout has inspiring quotes; When the layout is updated; Then the quotes section is removed for a cleaner, branded appearance +- [ ] AC7: Responsive Breakpoints: Given various screen sizes; When the layout responds; Then : diff --git a/docs/tasks/13-3.md b/docs/tasks/13-3.md new file mode 100644 index 0000000..b73af68 --- /dev/null +++ b/docs/tasks/13-3.md @@ -0,0 +1,20 @@ +--- +id: 13-3 +title: 13-3 Subtle Background Pattern Implementation +status: QA Review +date: 2026-09-27 +parent: 13 +--- + +## Description + +As a visitor to the authentication pages I want to see a subtle, elegant background pattern on the form side So that the page feels polished and professionally designed. **Option A: Geometric (Recommended)** - Simple diagonal lines or dots - Clean, modern aesthetic - Easier to create and maintain. Full implementation history: docs/stories/story-13.3-background-pattern.md + +## Acceptance Criteria + +- [ ] AC1: Create SVG Pattern Asset: Given the need for a subtle background pattern; When the pattern is created; Then : +- [ ] AC2: Pattern Placement: Given the SVG pattern is created; When applied to the auth layout; Then : +- [ ] AC3: Pattern Opacity: Given readability requirements; When the pattern is displayed; Then : +- [ ] AC4: CSS Implementation: Given the pattern asset; When integrated into CSS; Then : +- [ ] AC5: Performance Consideration: Given page load performance; When the pattern loads; Then : +- [ ] AC6: Mobile Compatibility: Given mobile viewport; When pattern is displayed; Then : diff --git a/docs/tasks/13-4.md b/docs/tasks/13-4.md new file mode 100644 index 0000000..bcbc3de --- /dev/null +++ b/docs/tasks/13-4.md @@ -0,0 +1,24 @@ +--- +id: 13-4 +title: 13-4 Auth Pages Migration to Split Layout +status: QA Review +date: 2026-09-27 +parent: 13 +--- + +## Description + +As a user accessing any authentication page I want to see the consistent, branded split layout So that all auth pages provide a cohesive, professional experience. Full implementation history: docs/stories/story-13.4-auth-pages-migration.md + +## Acceptance Criteria + +- [ ] AC1: Login Page Migration: Given the login page at `/login`; When the page loads; Then : +- [ ] AC2: Forgot Password Page Migration: Given the forgot password page at `/forgot-password`; When the page loads; Then : +- [ ] AC3: Reset Password Page Migration: Given the reset password page at `/reset-password/{token}`; When the page loads; Then : +- [ ] AC4: Two-Factor Challenge Page Migration: Given the 2FA challenge page at `/two-factor-challenge`; When the page loads; Then : +- [ ] AC5: Confirm Password Page Migration: Given the confirm password page at `/confirm-password`; When the page loads; Then : +- [ ] AC6: Email Verification Page Migration: Given the email verification page at `/email/verify`; When the page loads; Then : +- [ ] AC7: Update Default Auth Layout: Given the auth layout wrapper (`x-layouts.auth`); When called by auth pages; Then : +- [ ] AC8: RTL Support Verified: Given Arabic language selected; When any auth page loads; Then : +- [ ] AC9: Mobile Responsiveness Verified: Given mobile viewport (below lg breakpoint); When any auth page loads; Then : +- [ ] AC10: Accessibility Maintained: Given accessibility requirements; When auth pages render; Then : diff --git a/docs/tasks/13-5.md b/docs/tasks/13-5.md new file mode 100644 index 0000000..c9cb30d --- /dev/null +++ b/docs/tasks/13-5.md @@ -0,0 +1,26 @@ +--- +id: 13-5 +title: 13-5 Visual QA and Refinement +status: Draft +date: 2026-09-27 +parent: 13 +--- + +## Description + +As a product owner I want to ensure all auth pages look polished and consistent So that users have a professional, trustworthy experience. Full implementation history: docs/stories/story-13.5-visual-qa.md + +## Acceptance Criteria + +- [ ] AC1: Cross-Browser Testing: Given the updated auth pages; When tested in major browsers; Then all pages render correctly in: +- [ ] AC2: Desktop Viewport Testing: Given desktop viewports; When auth pages are viewed; Then the split layout displays correctly at: +- [ ] AC3: Mobile Viewport Testing: Given mobile viewports; When auth pages are viewed; Then the mobile layout displays correctly at: +- [ ] AC4: RTL Visual Verification: Given Arabic language selected; When all auth pages are viewed; Then : +- [ ] AC5: Logo Visibility Verification: Given the LIBRA logo on the brand panel; When viewed on desktop; Then : +- [ ] AC6: Language Toggle Visibility Verification: Given the language toggle on auth pages; When viewed; Then : +- [ ] AC7: Pattern Subtlety Verification: Given the background pattern; When viewed across all pages; Then : +- [ ] AC8: Form Element Alignment: Given form elements on auth pages; When viewed; Then : +- [ ] AC9: Color Consistency: Given the brand color palette; When auth pages are viewed; Then : +- [ ] AC10: Animation/Transition Polish: Given interactive elements; When interacted with; Then : +- [ ] AC11: Print Stylesheet (Optional): Given a user prints an auth page; When the page is printed; Then : +- [ ] AC12: Fix Any Visual Issues: Given issues discovered during QA; When fixes are needed; Then : diff --git a/docs/tasks/13.md b/docs/tasks/13.md new file mode 100644 index 0000000..263d79c --- /dev/null +++ b/docs/tasks/13.md @@ -0,0 +1,22 @@ +--- +id: 13 +title: 13 Authentication Pages Design Enhancement +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Redesigns the auth pages (login, forgot/reset password, etc.) from plain layouts into a branded split-screen experience — dark panel with the LIBRA logo on one side, a warm-cream form panel with a subtle background pattern on the other — plus a language-toggle visibility fix, migration of all auth pages to the new layout, and a final cross-browser/viewport visual QA pass. + +## Acceptance Criteria + +- [ ] All stories completed with acceptance criteria met +- [ ] Language toggle visible and accessible on auth pages +- [ ] Split layout displays correctly on desktop and tablet +- [ ] Mobile layout is functional and attractive +- [ ] RTL (Arabic) layout mirrors correctly +- [ ] Pattern is subtle and professional +- [ ] No regression in auth functionality +- [ ] Visual QA completed on major browsers (Chrome, Firefox, Safari) +- [ ] Accessibility audit passed (contrast ratios, focus states) diff --git a/docs/tasks/14-1.md b/docs/tasks/14-1.md new file mode 100644 index 0000000..1099317 --- /dev/null +++ b/docs/tasks/14-1.md @@ -0,0 +1,21 @@ +--- +id: 14-1 +title: 14-1 Hero Section Implementation +status: QA Review +date: 2026-09-27 +parent: 14 +--- + +## Description + +As a website visitor I want to see an impactful hero section when I land on the home page So that I immediately understand what Libra offers and how to take action. - resources/views/pages/home.blade.php - Main implementation - lang/en/home.php - English translations - lang/ar/home.php - Arabic translations. Full implementation history: docs/stories/story-14.1-hero-section.md + +## Acceptance Criteria + +- [ ] AC1: Hero Section Container: Given a visitor lands on the home page; When the page loads; Then a full-width hero section is displayed with: +- [ ] AC2: Tagline Display: Given the hero section; When viewed in English; Then display: "Committed to Justice – Grounded in Dignity – Driven to Advocate" +- [ ] AC3: Introductory Text: Given the hero section below the tagline; When displayed; Then show a brief 1-2 sentence introduction: +- [ ] AC4: Primary CTA Button: Given the hero section; When displayed below the intro text; Then show a primary CTA button: +- [ ] AC5: Secondary CTA Button (Optional): Given the hero section; When displayed next to primary CTA; Then show a secondary CTA button: +- [ ] AC6: Responsive Layout: Given different screen sizes; When viewing the hero section: +- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the hero section; Then all text and elements align right-to-left correctly diff --git a/docs/tasks/14-2.md b/docs/tasks/14-2.md new file mode 100644 index 0000000..4991ff9 --- /dev/null +++ b/docs/tasks/14-2.md @@ -0,0 +1,21 @@ +--- +id: 14-2 +title: 14-2 About Section with Lawyer Profile +status: QA Review +date: 2026-09-27 +parent: 14 +--- + +## Description + +As a website visitor I want to see information about the lawyer behind Libra So that I can trust the firm and understand who will be handling my case. - resources/views/pages/home.blade.php - Add about section - lang/en/home.php - Add translations - lang/ar/home.php - Add translations - public/images/huda-armouche.jpg - Lawyer photo (to be added). Full implementation history: docs/stories/story-14.2-about-section.md + +## Acceptance Criteria + +- [ ] AC1: Section Container: Given a visitor scrolls past the hero section; When viewing the about section; Then display a section with: +- [ ] AC2: Section Heading: Given the about section; When displayed; Then show a section heading: +- [ ] AC3: Lawyer Photo: Given the about section; When displayed; Then show Huda Armouche's professional photo: +- [ ] AC4: Lawyer Name and Title: Given the about section; When displayed; Then show: +- [ ] AC5: Bio Text: Given the about section; When displayed; Then show a professional bio: +- [ ] AC6: Layout Structure: Given different screen sizes; When viewing the about section: +- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the about section; Then layout mirrors appropriately (photo on right in RTL if it was on left in LTR) diff --git a/docs/tasks/14-3.md b/docs/tasks/14-3.md new file mode 100644 index 0000000..fcc89ee --- /dev/null +++ b/docs/tasks/14-3.md @@ -0,0 +1,21 @@ +--- +id: 14-3 +title: 14-3 Services Section +status: QA Review +date: 2026-09-27 +parent: 14 +--- + +## Description + +As a website visitor I want to see what legal services Libra offers So that I can determine if they can help with my legal needs. - resources/views/pages/home.blade.php - Add services section - lang/en/home.php - Add translations - lang/ar/home.php - Add translations. Full implementation history: docs/stories/story-14.3-services-section.md + +## Acceptance Criteria + +- [ ] AC1: Section Container: Given a visitor scrolls to the services section; When viewing the section; Then display with: +- [ ] AC2: Section Heading: Given the services section; When displayed; Then show a section heading: +- [ ] AC3: Four Service Cards: Given the services section; When displayed; Then show 4 service cards: +- [ ] AC4: Service Card Design: Given each service card; When displayed; Then include: +- [ ] AC5: Service Descriptions: Given each service card; When displayed; Then show appropriate descriptions: +- [ ] AC6: Grid Layout: Given different screen sizes; When viewing the services section: +- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the services section; Then cards maintain proper alignment and text direction diff --git a/docs/tasks/14-4.md b/docs/tasks/14-4.md new file mode 100644 index 0000000..dbf2d3a --- /dev/null +++ b/docs/tasks/14-4.md @@ -0,0 +1,21 @@ +--- +id: 14-4 +title: 14-4 Values Section +status: QA Review +date: 2026-09-27 +parent: 14 +--- + +## Description + +As a website visitor I want to understand Libra's core values So that I can assess if their principles align with my expectations. - resources/views/pages/home.blade.php - Add values section - lang/en/home.php - Add translations - lang/ar/home.php - Add translations. Full implementation history: docs/stories/story-14.4-values-section.md + +## Acceptance Criteria + +- [ ] AC1: Section Container: Given a visitor scrolls to the values section; When viewing the section; Then display with: +- [ ] AC2: Section Heading: Given the values section; When displayed; Then show a section heading: +- [ ] AC3: Six Value Items: Given the values section; When displayed; Then show 6 values: +- [ ] AC4: Value Item Design: Given each value item; When displayed; Then include: +- [ ] AC5: Grid Layout: Given different screen sizes; When viewing the values section: +- [ ] AC6: Visual Style Options: Given the values display; When implemented; Then choose one of these styles: +- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the values section; Then items maintain proper alignment and text direction diff --git a/docs/tasks/14-5.md b/docs/tasks/14-5.md new file mode 100644 index 0000000..efcb6ff --- /dev/null +++ b/docs/tasks/14-5.md @@ -0,0 +1,23 @@ +--- +id: 14-5 +title: 14-5 Latest Posts Section +status: QA Review +date: 2026-09-27 +parent: 14 +--- + +## Description + +As a website visitor I want to see recent legal articles and updates on the home page So that I can access valuable legal content and see that the firm is active. - resources/views/pages/home.blade.php - Add posts section with data query - lang/en/home.php - Add translations - lang/ar/home.php - Add translations. Full implementation history: docs/stories/story-14.5-latest-posts-section.md + +## Acceptance Criteria + +- [ ] AC1: Section Container: Given a visitor scrolls to the latest posts section; When viewing the section; Then display with: +- [ ] AC2: Section Heading: Given the latest posts section; When displayed; Then show a section heading: +- [ ] AC3: Display 3 Latest Posts: Given the posts section; When posts exist in the database; Then display the 3 most recent published posts showing: +- [ ] AC4: Post Card Design: Given each post card; When displayed; Then include: +- [ ] AC5: Empty State: Given the posts section; When no published posts exist; Then either: +- [ ] AC6: View All Link: Given the posts section; When posts are displayed; Then show a "View All Articles" / "عرض جميع المقالات" link: +- [ ] AC7: Grid Layout: Given different screen sizes; When viewing the posts section: +- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the posts section; Then cards and text align right-to-left correctly +- [ ] AC9: Dynamic Data: Given the posts section; When rendered; Then query posts from database: diff --git a/docs/tasks/14-6.md b/docs/tasks/14-6.md new file mode 100644 index 0000000..1878597 --- /dev/null +++ b/docs/tasks/14-6.md @@ -0,0 +1,20 @@ +--- +id: 14-6 +title: 14-6 Footer Contact Information Update +status: QA Review +date: 2026-09-27 +parent: 14 +--- + +## Description + +As a website visitor I want to see accurate contact information in the footer So that I can reach out to Libra through the correct phone number and address. - resources/views/components/layouts/public.blade.php - Main footer location - OR resources/views/components/footer.blade.php - If footer is a separate component. Full implementation history: docs/stories/story-14.6-footer-update.md + +## Acceptance Criteria + +- [ ] AC1: Update Phone Number: Given the website footer; When displayed; Then show the phone number: `+970599353502` +- [ ] AC2: Update Address: Given the website footer; When displayed; Then show the address: +- [ ] AC3: Phone Display Format: Given the phone number in footer; When displayed; Then format as: +- [ ] AC4: Contact Section Layout: Given the footer contact area; When displayed; Then include: +- [ ] AC5: RTL Support: Given Arabic language is selected; When viewing the footer; Then address displays in Arabic and layout adjusts for RTL +- [ ] AC6: Consistency Check: Given the footer update; When completed; Then ensure footer displays correctly on: diff --git a/docs/tasks/14.md b/docs/tasks/14.md new file mode 100644 index 0000000..3b42256 --- /dev/null +++ b/docs/tasks/14.md @@ -0,0 +1,26 @@ +--- +id: 14 +title: 14 Home Page Redesign +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Transforms the minimal home page into a full landing page: hero section, an about section featuring lawyer Huda Armouche, a services section, a values section, a latest-posts section pulling live data, and an updated footer with current contact information. + +## Acceptance Criteria + +- [ ] All 6 stories completed with acceptance criteria met +- [ ] Hero section displays tagline and CTAs correctly +- [ ] About section shows lawyer photo and bio +- [ ] Services section displays 4 generalized services +- [ ] Values section displays 6 values with icons +- [ ] Latest posts section pulls real data from database +- [ ] Footer shows updated phone and address +- [ ] Responsive design works on mobile, tablet, desktop +- [ ] RTL (Arabic) layout displays correctly +- [ ] LTR (English) layout displays correctly +- [ ] All text in translation files (ar/en) +- [ ] Visual consistency with brand guidelines +- [ ] Accessibility standards maintained diff --git a/docs/tasks/15-1.md b/docs/tasks/15-1.md new file mode 100644 index 0000000..1a19050 --- /dev/null +++ b/docs/tasks/15-1.md @@ -0,0 +1,19 @@ +--- +id: 15-1 +title: 15-1 Database Schema & Model Setup +status: QA Review +date: 2026-09-27 +parent: 15 +--- + +## Description + +As an admin I want to have a database structure for potential clients So that I can store and manage prospective client information. Full implementation history: docs/stories/story-15.1-database-model.md + +## Acceptance Criteria + +- [ ] AC1: Database Migration: Given the system needs to store potential clients; When the migration runs; Then a `potential_clients` table is created with: +- [ ] AC2: PotentialClientType Enum: Given potential clients have different types; When the enum is created; Then `App\Enums\PotentialClientType` contains: +- [ ] AC3: PotentialClient Model: Given the migration exists; When the model is created; Then `App\Models\PotentialClient` includes: +- [ ] AC4: Model Factory: Given tests need potential client data; When the factory is created; Then `Database\Factories\PotentialClientFactory` generates: +- [ ] AC5: Translation Keys: Given the system is bilingual; When translations are added; Then create keys in `lang/en/potential-clients.php` and `lang/ar/potential-clients.php`: diff --git a/docs/tasks/15-2.md b/docs/tasks/15-2.md new file mode 100644 index 0000000..ce786bf --- /dev/null +++ b/docs/tasks/15-2.md @@ -0,0 +1,24 @@ +--- +id: 15-2 +title: 15-2 Potential Clients List with Type Filter +status: QA Review +date: 2026-09-27 +parent: 15 +--- + +## Description + +As an admin I want to view a list of potential clients with filtering capabilities So that I can easily browse and find specific prospective clients. | File | Purpose | |------|---------| | resources/views/livewire/admin/potential-clients/index.blade.php | List Volt component | | routes/web.php | Add route for potential clients |. Full implementation history: docs/stories/story-15.2-list-filter.md + +## Acceptance Criteria + +- [ ] AC1: Admin Navigation: Given the admin is logged in; When viewing the admin sidebar; Then a "Potential Clients" menu item is visible with an appropriate icon +- [ ] AC2: List Page Header: Given the admin navigates to `/admin/potential-clients`; When the page loads; Then display: +- [ ] AC3: Type Filter: Given the potential clients list; When the filter is displayed; Then a type dropdown includes: +- [ ] AC4: Search Functionality: Given the potential clients list; When the admin types in the search box; Then filter potential clients by name, email, or phone +- [ ] AC5: List Table Display: Given potential clients exist; When viewing the list; Then display a table with columns: +- [ ] AC6: Type Badges: Given potential clients in the list; When displaying the type; Then show colored badges: +- [ ] AC7: Empty State: Given no potential clients exist; When viewing the list; Then display an empty state with: +- [ ] AC8: Pagination: Given more than 10 potential clients exist; When viewing the list; Then display pagination controls +- [ ] AC9: Clear Filters: Given search or type filter is active; When admin clicks "Clear filters"; Then reset all filters to defaults +- [ ] AC10: RTL Support: Given Arabic language is selected; When viewing the potential clients list; Then all text and layout align correctly right-to-left diff --git a/docs/tasks/15-3.md b/docs/tasks/15-3.md new file mode 100644 index 0000000..79b3700 --- /dev/null +++ b/docs/tasks/15-3.md @@ -0,0 +1,26 @@ +--- +id: 15-3 +title: 15-3 CRUD Operations for Potential Clients +status: QA Review +date: 2026-09-27 +parent: 15 +--- + +## Description + +As an admin I want to create, view, edit, and delete potential clients So that I can fully manage my prospective client records. | File | Purpose | |------|---------| | resources/views/livewire/admin/potential-clients/create.blade.php | Create form component | | resources/views/livewire/admin/potential-clients/show.blade.php | View page component | | resources/views/livewire/admin/potential-clients/edit.blade.php | Edit form component |. Full implementation history: docs/stories/story-15.3-crud-operations.md + +## Acceptance Criteria + +- [ ] AC1: Create Form Access: Given the admin is on the potential clients list; When clicking "Add Potential Client"; Then navigate to `/admin/potential-clients/create` +- [ ] AC2: Create Form Fields: Given the admin is on the create form; When the form is displayed; Then show the following fields: +- [ ] AC3: Create Submission: Given the admin fills the create form; When submitting with valid data; Then create a new potential client record +- [ ] AC4: Create Validation: Given the admin submits the create form; When type is not selected; Then show validation error: "Please select a type" / "يرجى اختيار النوع" +- [ ] AC5: View Page: Given a potential client exists; When the admin clicks the view icon from the list; Then navigate to `/admin/potential-clients/{id}` +- [ ] AC6: View Page Display: Given the admin is viewing a potential client; When the page loads; Then display: +- [ ] AC7: Edit Form Access: Given the admin is viewing a potential client; When clicking "Edit"; Then navigate to `/admin/potential-clients/{id}/edit` +- [ ] AC8: Edit Form Submission: Given the admin modifies the edit form; When submitting with valid data; Then update the potential client record +- [ ] AC9: Delete Confirmation: Given the admin is viewing a potential client; When clicking "Delete"; Then show a confirmation modal with: +- [ ] AC10: Delete Execution: Given the delete confirmation modal is shown; When the admin confirms deletion; Then delete the potential client record +- [ ] AC11: RTL Support: Given Arabic language is selected; When viewing create/edit/view pages; Then all forms and layouts align correctly right-to-left +- [ ] AC12: Cancel Actions: Given the admin is on create or edit form; When clicking "Cancel"; Then navigate back to the previous page (list or view) diff --git a/docs/tasks/15.md b/docs/tasks/15.md new file mode 100644 index 0000000..7821a5a --- /dev/null +++ b/docs/tasks/15.md @@ -0,0 +1,19 @@ +--- +id: 15 +title: 15 Potential Clients Management +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Adds an admin-only lead-tracking system for prospects (individual/company/agency) who don't yet have accounts: a new standalone `PotentialClient` model/table, a filterable list view by client type, and full CRUD, following existing admin interface patterns. + +## Acceptance Criteria + +- [ ] All stories completed with acceptance criteria met +- [ ] Tests cover CRUD operations and filtering +- [ ] Admin can manage potential clients through new interface +- [ ] No regression in existing features +- [ ] Bilingual support (Arabic/English) for all UI elements +- [ ] Admin navigation updated with new menu item diff --git a/docs/tasks/16-1.md b/docs/tasks/16-1.md new file mode 100644 index 0000000..4281ff9 --- /dev/null +++ b/docs/tasks/16-1.md @@ -0,0 +1,22 @@ +--- +id: 16-1 +title: 16-1 About Page Layout & Hero Section +status: QA Review +date: 2026-09-27 +parent: 16 +--- + +## Description + +As a website visitor I want to access a dedicated About Us page So that I can learn about Libra for Rights' identity and purpose. - resources/views/pages/about.blade.php - Main page - lang/en/about.php - English translations - lang/ar/about.php - Arabic translations. Full implementation history: docs/stories/story-16.1-about-page-layout-hero.md + +## Acceptance Criteria + +- [ ] AC1: Route & Navigation: Given a visitor on any page; When they look at the main navigation; Then an "About Us" / "من نحن" link is visible +- [ ] AC2: Page Structure: Given a visitor accesses `/about`; When the page loads; Then the page uses the public layout with: +- [ ] AC3: Hero Section Container: Given the About Us page loads; When displayed; Then show a hero section with: +- [ ] AC4: Page Title: Given the hero section; When viewed in English; Then display title: "About Us" +- [ ] AC5: Tagline Display: Given the hero section below the title; When displayed; Then show the tagline: +- [ ] AC6: Identity Statement: Given the hero section below the tagline; When displayed; Then show the identity statement: +- [ ] AC7: Responsive Layout: Given different screen sizes; When viewing the hero section: +- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the page; Then all text and elements align right-to-left correctly diff --git a/docs/tasks/16-2.md b/docs/tasks/16-2.md new file mode 100644 index 0000000..2e33709 --- /dev/null +++ b/docs/tasks/16-2.md @@ -0,0 +1,23 @@ +--- +id: 16-2 +title: 16-2 Vision & Mission Section +status: QA Review +date: 2026-09-27 +parent: 16 +--- + +## Description + +As a website visitor I want to read Libra's vision and mission statements So that I understand the organization's purpose and who they serve. Full implementation history: docs/stories/story-16.2-vision-mission-section.md + +## Acceptance Criteria + +- [ ] AC1: Vision Section Container: Given the About Us page below the hero; When displayed; Then show a vision section with: +- [ ] AC2: Vision Section Header: Given the vision section; When displayed; Then show section header: +- [ ] AC3: Vision Statement: Given the vision section; When displayed; Then show the full vision statement: +- [ ] AC4: Mission Section Container: Given the About Us page below the vision; When displayed; Then show a mission section with: +- [ ] AC5: Mission Section Header: Given the mission section; When displayed; Then show section header: +- [ ] AC6: Mission Cards - Three Categories: Given the mission section; When displayed; Then show 3 mission cards in a responsive grid: +- [ ] AC7: Mission Card Styling: Given each mission card; When displayed; Then style with: +- [ ] AC8: Responsive Grid: Given different screen sizes; When viewing mission cards: +- [ ] AC9: RTL Support: Given Arabic language is selected; When viewing both sections; Then all text and cards align right-to-left correctly diff --git a/docs/tasks/16-3.md b/docs/tasks/16-3.md new file mode 100644 index 0000000..6de2374 --- /dev/null +++ b/docs/tasks/16-3.md @@ -0,0 +1,21 @@ +--- +id: 16-3 +title: 16-3 Values Section +status: QA Review +date: 2026-09-27 +parent: 16 +--- + +## Description + +As a website visitor I want to see Libra's core values So that I understand the principles that guide their work. Full implementation history: docs/stories/story-16.3-values-section.md + +## Acceptance Criteria + +- [ ] AC1: Values Section Container: Given the About Us page below the mission section; When displayed; Then show a values section with: +- [ ] AC2: Values Section Header: Given the values section; When displayed; Then show section header: +- [ ] AC3: Values Introduction: Given the values section below the header; When displayed; Then show introductory text: +- [ ] AC4: Six Value Cards: Given the values section; When displayed; Then show 6 value cards: +- [ ] AC5: Value Card Styling: Given each value card; When displayed; Then style with: +- [ ] AC6: Responsive Grid: Given different screen sizes; When viewing value cards: +- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the values section; Then all cards and text align correctly for RTL diff --git a/docs/tasks/16-4.md b/docs/tasks/16-4.md new file mode 100644 index 0000000..16dcfdf --- /dev/null +++ b/docs/tasks/16-4.md @@ -0,0 +1,21 @@ +--- +id: 16-4 +title: 16-4 Goals Section +status: QA Review +date: 2026-09-27 +parent: 16 +--- + +## Description + +As a website visitor I want to see Libra's organizational goals So that I understand what they are working to achieve. Full implementation history: docs/stories/story-16.4-goals-section.md + +## Acceptance Criteria + +- [ ] AC1: Goals Section Container: Given the About Us page below the values section; When displayed; Then show a goals section with: +- [ ] AC2: Goals Section Header: Given the goals section; When displayed; Then show section header: +- [ ] AC3: Seven Goals Display: Given the goals section; When displayed; Then show all 7 goals: +- [ ] AC4: Goals List Styling: Given the goals list; When displayed; Then style as: +- [ ] AC5: Numbered Circle Style: Given each goal number; When displayed; Then style the number with: +- [ ] AC6: Responsive Layout: Given different screen sizes; When viewing goals: +- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the goals section; Then numbers align on the right, text flows RTL diff --git a/docs/tasks/16-5.md b/docs/tasks/16-5.md new file mode 100644 index 0000000..3665c06 --- /dev/null +++ b/docs/tasks/16-5.md @@ -0,0 +1,22 @@ +--- +id: 16-5 +title: 16-5 Legal Services Section +status: QA Review +date: 2026-09-27 +parent: 16 +--- + +## Description + +As a website visitor I want to see Libra's comprehensive legal services So that I know what services they offer and if they can help with my legal needs. Full implementation history: docs/stories/story-16.5-legal-services-section.md + +## Acceptance Criteria + +- [ ] AC1: Services Section Container: Given the About Us page below the goals section; When displayed; Then show a services section with: +- [ ] AC2: Services Section Header: Given the services section; When displayed; Then show section header: +- [ ] AC3: Services Introduction: Given the services section below the header; When displayed; Then show introductory text: +- [ ] AC4: Four Service Categories: Given the services section; When displayed; Then show 4 service category cards: +- [ ] AC5: Service Card Styling: Given each service card; When displayed; Then style with: +- [ ] AC6: Responsive Grid: Given different screen sizes; When viewing service cards: +- [ ] AC7: CTA Button: Given the services section; When displayed below the cards; Then show a CTA button: +- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the services section; Then all cards, lists, and text align correctly for RTL diff --git a/docs/tasks/16-6.md b/docs/tasks/16-6.md new file mode 100644 index 0000000..e87c49f --- /dev/null +++ b/docs/tasks/16-6.md @@ -0,0 +1,22 @@ +--- +id: 16-6 +title: 16-6 Scholarship Aspiration Section +status: QA Review +date: 2026-09-27 +parent: 16 +--- + +## Description + +As a website visitor I want to learn about Libra's scholarship aspiration So that I understand their vision for supporting Palestinian arts and law students. Full implementation history: docs/stories/story-16.6-scholarship-section.md + +## Acceptance Criteria + +- [ ] AC1: Scholarship Section Container: Given the About Us page below the services section; When displayed; Then show a scholarship section with: +- [ ] AC2: Scholarship Section Header: Given the scholarship section; When displayed; Then show section header: +- [ ] AC3: Scholarship Description: Given the scholarship section; When displayed; Then show the scholarship description with two paragraphs: +- [ ] AC4: Key Aspirations List: Given the scholarship section below the description; When displayed; Then show 4 key aspirations as highlight items: +- [ ] AC5: Aspiration Item Styling: Given each aspiration item; When displayed; Then style with: +- [ ] AC6: Visual Accent: Given the scholarship section; When displayed; Then include: +- [ ] AC7: Responsive Layout: Given different screen sizes; When viewing the scholarship section: +- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the scholarship section; Then all text and items align correctly for RTL diff --git a/docs/tasks/16.md b/docs/tasks/16.md new file mode 100644 index 0000000..b193403 --- /dev/null +++ b/docs/tasks/16.md @@ -0,0 +1,28 @@ +--- +id: 16 +title: 16 About Us Page +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Builds a new public `/about` page presenting LIBRA for Rights' identity, vision, mission, values, goals, legal services, and scholarship aspiration, sourced from the organization's vision/mission/values document, across hero, vision/mission, values, goals, legal-services, and scholarship sections. + +## Acceptance Criteria + +- [ ] All 6 stories completed with acceptance criteria met +- [ ] About Us page accessible at `/about` +- [ ] Navigation updated with About Us link +- [ ] Hero section displays title and identity statement +- [ ] Vision section displays full vision statement +- [ ] Mission section displays all three mission categories +- [ ] Values section displays 6 values with icons +- [ ] Goals section displays 7 goals +- [ ] Legal services section displays all service categories +- [ ] Scholarship section displays aspiration content +- [ ] Responsive design works on mobile, tablet, desktop +- [ ] RTL (Arabic) layout displays correctly +- [ ] LTR (English) layout displays correctly +- [ ] All text in translation files (ar/en) +- [ ] Visual consistency with brand guidelines diff --git a/docs/tasks/2-1.md b/docs/tasks/2-1.md new file mode 100644 index 0000000..b24f7d3 --- /dev/null +++ b/docs/tasks/2-1.md @@ -0,0 +1,39 @@ +--- +id: 2-1 +title: 2-1 Individual Client Account Management +status: Done +date: 2026-09-27 +parent: 2 +--- + +## Description + +As an admin, I want to create, view, edit, and search individual client accounts, So that I can manage client information and provide them platform access. Context: Integrates with: Users table, Fortify authentication; Technology: Livewire Volt, Flux UI forms; Follows pattern: Admin CRUD patterns, class-based Volt components. - **Validation failure:** Display inline field errors using Flux UI error states - **Duplicate email:** Show "Email already exists" error on email field - **Duplicate National ID:** Show "National ID already registered" error - **Empty search results:** Display "No clients found" message with clear filters option. Full implementation history: docs/stories/story-2.1-individual-client-account-management.md + +## Acceptance Criteria + +- [ ] Form with required fields: +- [ ] Validation for all required fields +- [ ] Duplicate email/National ID prevention with clear error message +- [ ] Password strength indicator (optional) +- [ ] Success message on creation +- [ ] Display all individual clients (user_type = 'individual') +- [ ] Columns: Name, Email, National ID, Phone, Status, Created Date +- [ ] Pagination (10/25/50 per page) +- [ ] Default sort by created date (newest first) +- [ ] Search by name, email, or National ID +- [ ] Filter by status (active/deactivated/all) +- [ ] Real-time search with debounce (300ms) +- [ ] Clear filters button +- [ ] Edit all client information +- [ ] Cannot change user_type from this form +- [ ] Validation same as create +- [ ] Success message on update +- [ ] Display all client information +- [ ] Show consultation history summary +- [ ] Show timeline history summary +- [ ] Quick links to related records +- [ ] Bilingual form labels and messages +- [ ] Proper form validation with error display +- [ ] Audit log entries for all operations +- [ ] Tests for CRUD operations diff --git a/docs/tasks/2-2.md b/docs/tasks/2-2.md new file mode 100644 index 0000000..ae64e2f --- /dev/null +++ b/docs/tasks/2-2.md @@ -0,0 +1,36 @@ +--- +id: 2-2 +title: 2-2 Company/Corporate Client Account Management +status: QA Review +date: 2026-09-27 +parent: 2 +--- + +## Description + +As an admin, I want to create, view, edit, and manage company/corporate client accounts, So that I can serve corporate clients with their unique data requirements. Context: Integrates with: `users` table (company-specific fields), `admin_logs` table; Technology: Livewire Volt (class-based), Flux UI forms, Pest tests; Follows pattern: Same CRUD pattern as Story 2.1 Individual Clients. > **Note:** This migration is NOT part of this story. It is preserved here for future reference if multiple contact persons feature is prioritized. Full implementation history: docs/stories/story-2.2-company-client-account-management.md + +## Acceptance Criteria + +- [ ] Form with required fields: +- [ ] Validation for all required fields +- [ ] Duplicate email/registration number prevention +- [ ] Success message on creation +- [ ] Display all company clients (user_type = 'company') +- [ ] Columns: Company Name, Contact Person, Email, Reg #, Status, Created Date +- [ ] Pagination (10/25/50 per page) +- [ ] Default sort by created date +- [ ] Search by company name, email, or registration number +- [ ] Filter by status (active/deactivated/all) +- [ ] Real-time search with debounce +- [ ] Edit all company information +- [ ] Update contact person details +- [ ] Validation same as create +- [ ] Success message on update +- [ ] Display all company information (including contact person details) +- [ ] Show consultation history summary +- [ ] Show timeline history summary +- [ ] Bilingual form labels and messages +- [ ] Proper form validation +- [ ] Audit log entries for all operations +- [ ] Tests for CRUD operations diff --git a/docs/tasks/2-3.md b/docs/tasks/2-3.md new file mode 100644 index 0000000..af1440a --- /dev/null +++ b/docs/tasks/2-3.md @@ -0,0 +1,33 @@ +--- +id: 2-3 +title: 2-3 Account Type Conversion +status: QA Review +date: 2026-09-27 +parent: 2 +--- + +## Description + +As an admin, I want to convert individual accounts to company accounts and vice versa, So that I can accommodate clients whose business structure changes. Context: Integrates with: Users table, consultations, timelines; Technology: Livewire Volt (class-based), Flux UI modals, Pest tests; Follows pattern: Admin action pattern with confirmation modal (same as Story 2.1/2.2 CRUD pattern). Full implementation history: docs/stories/story-2.3-account-type-conversion.md + +## Acceptance Criteria + +- [ ] "Convert to Company" action available on individual profiles +- [ ] Modal/form prompts for additional company fields: +- [ ] Preserve existing data (email, phone, password) +- [ ] Preserve all consultation history +- [ ] Preserve all timeline history +- [ ] Confirmation dialog before conversion +- [ ] Success message after conversion +- [ ] "Convert to Individual" action available on company profiles +- [ ] Modal/form prompts for individual-specific fields: +- [ ] Handle company-specific data: +- [ ] Preserve all consultation history +- [ ] Preserve all timeline history +- [ ] Confirmation dialog before conversion +- [ ] Audit log entry capturing: +- [ ] Email notification to user about account type change +- [ ] Bilingual confirmation dialogs +- [ ] Bilingual email notification +- [ ] All data preserved (verify in tests) +- [ ] No broken relationships after conversion diff --git a/docs/tasks/2-4.md b/docs/tasks/2-4.md new file mode 100644 index 0000000..73d430f --- /dev/null +++ b/docs/tasks/2-4.md @@ -0,0 +1,38 @@ +--- +id: 2-4 +title: 2-4 Account Lifecycle Management +status: QA Review +date: 2026-09-27 +parent: 2 +--- + +## Description + +As an admin, I want to deactivate, reactivate, and permanently delete client accounts, So that I can manage the full lifecycle of client relationships. Context: Integrates with: Users table, consultations, timelines, notifications, sessions; Technology: Livewire Volt (class-based), Flux UI modals, Pest tests; Follows pattern: Same admin action patterns as Story 2.1/2.2, soft deactivation via status field, hard deletion with cascade. Full implementation history: docs/stories/story-2.4-account-lifecycle-management.md + +## Acceptance Criteria + +- [ ] "Deactivate" button on user profile and list +- [ ] Confirmation dialog explaining consequences +- [ ] Effects of deactivation: +- [ ] Visual indicator in user list (grayed out, badge) +- [ ] Audit log entry created +- [ ] "Reactivate" button on deactivated profiles +- [ ] Confirmation dialog +- [ ] Effects of reactivation: +- [ ] Email notification sent to user +- [ ] Audit log entry created +- [ ] "Delete" button (with danger styling) +- [ ] Confirmation dialog with strong warning: +- [ ] Effects of deletion: +- [ ] Audit log entry preserved (for audit trail) +- [ ] No email sent (user no longer exists) +- [ ] "Reset Password" action on user profile +- [ ] Options: +- [ ] Email new credentials to client +- [ ] Force password change on next login (optional) - Not implemented per simplified approach +- [ ] Audit log entry created +- [ ] All actions logged in admin_logs table +- [ ] Bilingual confirmation messages +- [ ] Clear visual states for account status +- [ ] Tests for all lifecycle operations diff --git a/docs/tasks/2-5.md b/docs/tasks/2-5.md new file mode 100644 index 0000000..2e3bf79 --- /dev/null +++ b/docs/tasks/2-5.md @@ -0,0 +1,46 @@ +--- +id: 2-5 +title: 2-5 Account Creation Email Notification +status: QA Review +date: 2026-09-27 +parent: 2 +--- + +## Description + +As an admin, I want welcome emails sent automatically when I create client accounts, So that clients receive their login credentials and know how to access the platform. Context: Integrates with: User creation flow, Laravel Mail; Technology: Laravel Mailable, queued jobs; Follows pattern: Laravel notification/mailable patterns. Full implementation history: docs/stories/story-2.5-account-creation-email-notification.md + +## Acceptance Criteria + +- [ ] Email sent automatically on account creation +- [ ] Works for both individual and company accounts +- [ ] Queued for performance (async sending) +- [ ] No email sent for admin accounts +- [ ] Personalized greeting: +- [ ] Message: "Your account has been created" +- [ ] Login credentials: +- [ ] Login URL (clickable button/link) +- [ ] Brief platform introduction +- [ ] Contact information for questions +- [ ] Professional template with Libra branding +- [ ] Colors: Navy blue (#0A1F44) and Gold (#D4AF37) +- [ ] Libra logo in header +- [ ] Footer with firm information +- [ ] Mobile-responsive layout +- [ ] From: no-reply@libra.ps +- [ ] From Name: Libra Law Firm / مكتب ليبرا للمحاماة +- [ ] Reply-To: (firm contact email) +- [ ] Email in user's preferred_language +- [ ] Arabic email for Arabic preference +- [ ] English email for English preference +- [ ] All text translated +- [ ] Plain text version generated +- [ ] All essential information included +- [ ] Readable without HTML +- [ ] Email passes spam filters +- [ ] Links work correctly +- [ ] Password visible but not overly prominent +- [ ] Tests verify email sending +- [ ] Email queued with retry on failure (Laravel default: 3 attempts) +- [ ] Failed emails logged to `failed_jobs` table +- [ ] User creation succeeds even if email fails (non-blocking) diff --git a/docs/tasks/2.md b/docs/tasks/2.md new file mode 100644 index 0000000..9f182fd --- /dev/null +++ b/docs/tasks/2.md @@ -0,0 +1,22 @@ +--- +id: 2 +title: 2 User Management System +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Gives the admin full lifecycle control over client accounts: creating individual and company/corporate accounts, converting between types, deactivating or permanently deleting accounts, resetting passwords, and sending welcome-email notifications. All operations are audit-logged. + +## Acceptance Criteria + +- [ ] Admin can create individual client accounts +- [ ] Admin can create company/corporate client accounts +- [ ] Admin can convert between account types +- [ ] Admin can deactivate accounts (data retained) +- [ ] Admin can permanently delete accounts +- [ ] Admin can reset client passwords +- [ ] Welcome email sent with login credentials +- [ ] User search and filtering functional +- [ ] All operations logged for audit diff --git a/docs/tasks/3-1.md b/docs/tasks/3-1.md new file mode 100644 index 0000000..aa514ce --- /dev/null +++ b/docs/tasks/3-1.md @@ -0,0 +1,33 @@ +--- +id: 3-1 +title: 3-1 Working Hours Configuration +status: Done +date: 2026-09-27 +parent: 3 +--- + +## Description + +As an admin, I want to configure available working hours for each day of the week, So that clients can only book consultations during my available times. Context: Integrates with: working_hours table, availability calendar; Technology: Livewire Volt, Flux UI forms; Follows pattern: Admin settings pattern. The AdminLog model is used for audit logging (defined in Epic 1). Schema:. Full implementation history: docs/stories/story-3.1-working-hours-configuration.md + +## Acceptance Criteria + +- [ ] Set available days (enable/disable each day of week) +- [ ] Set start time for each enabled day +- [ ] Set end time for each enabled day +- [ ] Support different hours for different days +- [ ] 15-minute buffer automatically applied between appointments +- [ ] 12-hour time format display (AM/PM) +- [ ] Visual weekly schedule view +- [ ] Toggle for each day (Sunday-Saturday) +- [ ] Time pickers for start/end times +- [ ] Preview of available slots per day +- [ ] Save button with confirmation +- [ ] Changes take effect immediately for new bookings +- [ ] Existing approved bookings NOT affected by changes +- [ ] Warning if changing hours that have pending bookings +- [ ] Validation: end time must be after start time +- [ ] Bilingual labels and messages +- [ ] Default working hours on initial setup +- [ ] Audit log entry on changes +- [ ] Tests for configuration logic diff --git a/docs/tasks/3-2.md b/docs/tasks/3-2.md new file mode 100644 index 0000000..5199572 --- /dev/null +++ b/docs/tasks/3-2.md @@ -0,0 +1,38 @@ +--- +id: 3-2 +title: 3-2 Time Slot Blocking +status: QA Review +date: 2026-09-27 +parent: 3 +--- + +## Description + +As an admin, I want to block specific dates or time ranges for personal events or holidays, So that clients cannot book during my unavailable times. Context: Integrates with: blocked_times table, availability calendar; Technology: Livewire Volt, Flux UI; Follows pattern: CRUD pattern with calendar integration. Full implementation history: docs/stories/story-3.2-time-slot-blocking.md + +## Acceptance Criteria + +- [ ] Block entire days (all-day events) +- [ ] Block specific time ranges within a day +- [ ] Add reason/note for blocked time +- [ ] View list of all blocked times (upcoming and past) +- [ ] Edit blocked times +- [ ] Delete blocked times +- [ ] Select date (date picker) +- [ ] Choose: All day OR specific time range +- [ ] If time range: start time and end time +- [ ] Optional reason/note field +- [ ] Confirmation on save +- [ ] Blocked times show as unavailable in calendar (Story 3.3 dependency) +- [ ] Visual distinction from "already booked" slots (Story 3.3 dependency) +- [ ] Future blocked times don't affect existing approved bookings +- [ ] Warning if blocking time with pending bookings +- [ ] Show all blocked times +- [ ] Sort by date (upcoming first) +- [ ] Filter: past/upcoming/all +- [ ] Quick actions: edit, delete +- [ ] Show reason if provided +- [ ] Bilingual support +- [ ] Audit log for create/edit/delete +- [ ] Validation: end time after start time +- [ ] Tests for blocking logic diff --git a/docs/tasks/3-3.md b/docs/tasks/3-3.md new file mode 100644 index 0000000..17eb649 --- /dev/null +++ b/docs/tasks/3-3.md @@ -0,0 +1,34 @@ +--- +id: 3-3 +title: 3-3 Availability Calendar Display +status: QA Review +date: 2026-09-27 +parent: 3 +--- + +## Description + +As a client, I want to see a calendar with available time slots, So that I can choose a convenient time for my consultation. Context: Integrates with: working_hours, blocked_times, consultations tables; Technology: Livewire Volt, JavaScript calendar library; Follows pattern: Real-time availability checking. Full implementation history: docs/stories/story-3.3-availability-calendar-display.md + +## Acceptance Criteria + +- [ ] Monthly calendar view showing available dates +- [ ] Visual distinction for date states: +- [ ] Navigate between months +- [ ] Current month shown by default +- [ ] Clicking a date shows available time slots +- [ ] 1-hour slots (45min consultation + 15min buffer) +- [ ] Clear indication of slot availability +- [ ] Unavailable reasons (optional): +- [ ] Availability checked on date selection +- [ ] Prevent double-booking (race condition handling) +- [ ] Refresh availability when navigating months +- [ ] Prevent navigating to months before current month (all dates would be "past") +- [ ] Optionally limit future navigation (e.g., max 3 months ahead) - configurable (deferred to future story) +- [ ] Mobile-friendly calendar +- [ ] Touch-friendly slot selection +- [ ] Proper RTL support for Arabic +- [ ] Fast loading (eager load data) +- [ ] Language-appropriate date formatting +- [ ] Accessible (keyboard navigation) +- [ ] Tests for availability logic diff --git a/docs/tasks/3-4.md b/docs/tasks/3-4.md new file mode 100644 index 0000000..2332ce9 --- /dev/null +++ b/docs/tasks/3-4.md @@ -0,0 +1,19 @@ +--- +id: 3-4 +title: 3-4 Booking Request Submission +status: QA Review +date: 2026-09-27 +parent: 3 +--- + +## Description + +As a client, I want to submit a consultation booking request, so that I can schedule a meeting with the lawyer. Full implementation history: docs/stories/story-3.4-booking-request-submission.md + +## Acceptance Criteria + +- [ ] Booking Form (AC1-5) +- [ ] Validation & Constraints (AC6-9) +- [ ] Submission Flow (AC10-14) +- [ ] UI/UX (AC15-18) +- [ ] Quality Requirements (AC19-22) diff --git a/docs/tasks/3-5.md b/docs/tasks/3-5.md new file mode 100644 index 0000000..f6e8d10 --- /dev/null +++ b/docs/tasks/3-5.md @@ -0,0 +1,38 @@ +--- +id: 3-5 +title: 3-5 Admin Booking Review & Approval +status: QA Review +date: 2026-09-27 +parent: 3 +--- + +## Description + +As an admin, I want to review, categorize, and approve or reject booking requests, So that I can manage my consultation schedule and set appropriate consultation types. Context: Integrates with: consultations table, notifications, .ics generation; Technology: Livewire Volt, Flux UI; Follows pattern: Admin action workflow. Create these notification classes in app/Notifications/:. Full implementation history: docs/stories/story-3.5-admin-booking-review-approval.md + +## Acceptance Criteria + +- [ ] View all pending booking requests +- [ ] Display: client name, requested date/time, submission date +- [ ] Show problem summary preview +- [ ] Click to view full details +- [ ] Sort by date (oldest first default) +- [ ] Filter by date range +- [ ] Full client information +- [ ] Complete problem summary +- [ ] Client consultation history +- [ ] Requested date and time +- [ ] Set consultation type: +- [ ] If paid: set payment amount +- [ ] If paid: add payment instructions (optional) +- [ ] Approve button with confirmation +- [ ] On approval: +- [ ] Optional rejection reason field +- [ ] Reject button with confirmation +- [ ] On rejection: +- [ ] Quick approve (free) button on list +- [ ] Quick reject button on list +- [ ] Bulk actions (optional) +- [ ] Audit log for all decisions +- [ ] Bilingual notifications +- [ ] Tests for approval/rejection flow diff --git a/docs/tasks/3-6.md b/docs/tasks/3-6.md new file mode 100644 index 0000000..b147ed3 --- /dev/null +++ b/docs/tasks/3-6.md @@ -0,0 +1,35 @@ +--- +id: 3-6 +title: 3-6 Calendar File Generation (.ics) +status: QA Review +date: 2026-09-27 +parent: 3 +--- + +## Description + +As a client, I want to receive a calendar file when my booking is approved, So that I can easily add the consultation to my calendar app. Context: Integrates with: Consultation model, email attachments; Technology: iCalendar format (RFC 5545); Follows pattern: Service class for generation. Full implementation history: docs/stories/story-3.6-calendar-file-generation.md + +## Acceptance Criteria + +- [ ] Generate valid .ics file on booking approval +- [ ] File follows iCalendar specification (RFC 5545) +- [ ] Compatible with major calendar apps: +- [ ] Event title: "Consultation with Libra Law Firm" (bilingual) +- [ ] Date and time (correct timezone) +- [ ] Duration: 45 minutes +- [ ] Location (office address or "Phone consultation") +- [ ] Description with: +- [ ] Reminder: 1 hour before +- [ ] Attach to approval email +- [ ] Available for download from client dashboard +- [ ] Proper MIME type (text/calendar) +- [ ] Correct filename (consultation-{date}.ics) +- [ ] Event title in client's preferred language +- [ ] Description in client's preferred language +- [ ] Valid iCalendar format (passes validators) +- [ ] Tests for file generation +- [ ] Tests for calendar app compatibility +- [ ] Tests for bilingual content (Arabic/English) +- [ ] Tests for download route authorization +- [ ] Tests for email attachment diff --git a/docs/tasks/3-7.md b/docs/tasks/3-7.md new file mode 100644 index 0000000..8950202 --- /dev/null +++ b/docs/tasks/3-7.md @@ -0,0 +1,39 @@ +--- +id: 3-7 +title: 3-7 Consultation Management +status: QA Review +date: 2026-09-27 +parent: 3 +--- + +## Description + +As an admin, I want to manage consultations throughout their lifecycle, So that I can track completed sessions, handle no-shows, and maintain accurate records. Context: Integrates with: consultations table, notifications; Technology: Livewire Volt, Flux UI; Follows pattern: Admin management dashboard. Handle these scenarios with appropriate validation and error handling:. Full implementation history: docs/stories/story-3.7-consultation-management.md + +## Acceptance Criteria + +- [ ] View all consultations with filters: +- [ ] Sort by date, status, client name +- [ ] Pagination (15/25/50 per page) +- [ ] Quick status indicators +- [ ] Mark consultation as completed +- [ ] Mark consultation as no-show +- [ ] Cancel booking on behalf of client +- [ ] Status change confirmation +- [ ] Reschedule appointment to new date/time +- [ ] Validate new slot availability +- [ ] Send notification to client +- [ ] Generate new .ics file +- [ ] Mark payment as received (for paid consultations) +- [ ] Payment date recorded +- [ ] Payment status visible in list +- [ ] Add internal admin notes +- [ ] Notes not visible to client +- [ ] View notes in consultation detail +- [ ] Edit/delete notes +- [ ] View all consultations for a specific client +- [ ] Linked from user profile +- [ ] Summary statistics per client +- [ ] Audit log for all status changes +- [ ] Bilingual labels +- [ ] Tests for status transitions diff --git a/docs/tasks/3-8.md b/docs/tasks/3-8.md new file mode 100644 index 0000000..6f87064 --- /dev/null +++ b/docs/tasks/3-8.md @@ -0,0 +1,30 @@ +--- +id: 3-8 +title: 3-8 Consultation Reminders +status: QA Review +date: 2026-09-27 +parent: 3 +--- + +## Description + +As a client, I want to receive reminder emails before my consultation, So that I don't forget my appointment and can prepare accordingly. Context: Integrates with: consultations table, Laravel scheduler, email notifications; Technology: Laravel Queue, Scheduler, Mailable; Follows pattern: Scheduled job pattern. Full implementation history: docs/stories/story-3.8-consultation-reminders.md + +## Acceptance Criteria + +- [ ] Sent 24 hours before consultation +- [ ] Includes: +- [ ] Sent 2 hours before consultation +- [ ] Includes: +- [ ] Only for approved consultations +- [ ] Skip cancelled consultations +- [ ] Skip no-show consultations +- [ ] Don't send duplicate reminders +- [ ] Handle timezone correctly +- [ ] Email in client's preferred language +- [ ] Arabic template for Arabic preference +- [ ] English template for English preference +- [ ] Scheduled jobs run reliably +- [ ] Retry on failure +- [ ] Logging for debugging +- [ ] Tests for reminder logic diff --git a/docs/tasks/3-9.md b/docs/tasks/3-9.md new file mode 100644 index 0000000..77ff0c1 --- /dev/null +++ b/docs/tasks/3-9.md @@ -0,0 +1,40 @@ +--- +id: 3-9 +title: 3-9 Guest Booking Request +status: Draft +date: 2026-09-27 +parent: 3 +--- + +## Description + +As a guest visitor, I want to submit a consultation booking request with my contact details, So that I can request legal services without needing an account first. Context: Integrates with: Availability calendar (Story 3.3), Admin booking review (Story 3.5), User creation (Epic 2); Technology: Livewire Volt, Flux UI, existing availability calendar component; Follows pattern: Client booking submission (Story 3.4), Admin approval workflow (Story 3.5). Extend the existing admin.bookings.pending component to include guest booking requests:. Full implementation history: docs/stories/story-3.9-guest-booking-request.md + +## Acceptance Criteria + +- [ ] **AC1:** Public `/booking` page accessible without login +- [ ] **AC2:** Display availability calendar (reuse existing component) +- [ ] **AC3:** Guest can select date and available time slot +- [ ] **AC4:** Account type toggle: Individual / Company +- [ ] **AC5:** Form fields for Individual: +- [ ] **AC6:** Additional fields for Company: +- [ ] **AC7:** Problem summary field (required, textarea, min 20 characters, max 2000) +- [ ] **AC8:** Confirmation step before submission showing all entered data +- [ ] **AC9:** Duplicate check: If email OR national_id exists in users table, show "Account already exists. Please login to book." with login link +- [ ] **AC10:** 1-per-day limit by email: Check guest_booking_requests table for same email on same booking_date +- [ ] **AC11:** Validate selected slot is still available +- [ ] **AC12:** Clear error messages for all validation failures (bilingual) +- [ ] **AC13:** On submit, create record in `guest_booking_requests` table with status 'pending' +- [ ] **AC14:** Guest sees success page: "Request received. We will contact you soon." +- [ ] **AC15:** Admin receives email notification about new guest booking request +- [ ] **AC16:** Guest receives submission confirmation email +- [ ] **AC17:** Guest booking requests appear in admin pending bookings queue with "Guest" badge +- [ ] **AC18:** Admin can view full guest details and problem summary +- [ ] **AC19:** Admin action: **Approve + Create Account** +- [ ] **AC20:** Admin action: **Reject** +- [ ] **AC21:** Admin action: **Create Account Only** +- [ ] **AC22:** All admin actions logged in audit trail +- [ ] **AC23:** Bilingual support (Arabic/English) for all UI and emails +- [ ] **AC24:** Mobile-responsive design +- [ ] **AC25:** Race condition prevention for slot availability +- [ ] **AC26:** Comprehensive test coverage diff --git a/docs/tasks/3.md b/docs/tasks/3.md new file mode 100644 index 0000000..ff34846 --- /dev/null +++ b/docs/tasks/3.md @@ -0,0 +1,24 @@ +--- +id: 3 +title: 3 Booking & Consultation System +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Implements the full consultation booking workflow: admin-configured working hours and blocked time, a live availability calendar, client and guest booking submission, admin approval/rejection with free/paid assignment, consultation management, .ics calendar-file generation, and 24h/2h reminders. + +## Acceptance Criteria + +- [ ] Calendar displays available time slots +- [ ] Clients can submit booking requests +- [ ] 1 consultation per day per client enforced +- [ ] Admin can approve/reject bookings +- [ ] Admin assigns free/paid status +- [ ] Email notifications at each stage +- [ ] Consultation reminders (24hr, 2hr) +- [ ] Calendar file (.ics) generation +- [ ] Admin can mark as completed/no-show/cancelled +- [ ] Guests can submit booking requests from public page +- [ ] Admin can approve guest requests and create accounts diff --git a/docs/tasks/4-1.md b/docs/tasks/4-1.md new file mode 100644 index 0000000..38507a9 --- /dev/null +++ b/docs/tasks/4-1.md @@ -0,0 +1,30 @@ +--- +id: 4-1 +title: 4-1 Timeline Creation +status: QA Review +date: 2026-09-27 +parent: 4 +--- + +## Description + +As an admin, I want to create case timelines for clients, So that I can track and communicate progress on their legal matters. Context: Integrates with: timelines table, timeline_updates table, users table, admin_logs table; Technology: Livewire Volt, Flux UI; Follows pattern: Admin CRUD pattern (see existing admin components). Full implementation history: docs/stories/story-4.1-timeline-creation.md + +## Acceptance Criteria + +- [ ] Select client (search by name/email) - only users with user_type 'individual' or 'company' +- [ ] Case name/title (required) +- [ ] Case reference number (optional, unique if provided) +- [ ] Initial notes (optional) +- [ ] Timeline assigned to selected client +- [ ] Creation date automatically recorded +- [ ] Status defaults to 'active' +- [ ] Can create multiple timelines per client +- [ ] Confirmation message on successful creation +- [ ] Timeline immediately visible to client +- [ ] Case name required +- [ ] Case reference unique if provided +- [ ] Client must exist +- [ ] Audit log entry created via AdminLog model +- [ ] Bilingual labels and messages +- [ ] Tests for creation flow diff --git a/docs/tasks/4-2.md b/docs/tasks/4-2.md new file mode 100644 index 0000000..9b5a1cb --- /dev/null +++ b/docs/tasks/4-2.md @@ -0,0 +1,40 @@ +--- +id: 4-2 +title: 4-2 Timeline Updates Management +status: QA Review +date: 2026-09-27 +parent: 4 +--- + +## Description + +As an admin, I want to add and edit updates within a timeline, So that I can keep clients informed about their case progress. Context: Integrates with: timeline_updates table, timelines table; Technology: Livewire Volt, rich text editor (Trix recommended); Follows pattern: Nested CRUD pattern. Full implementation history: docs/stories/story-4.2-timeline-updates-management.md + +## Acceptance Criteria + +- [ ] Add new update to timeline +- [ ] Update text content (required) +- [ ] Rich text formatting supported: +- [ ] Timestamp automatically recorded +- [ ] Admin name automatically recorded +- [ ] Client notified via email on new update +- [ ] Edit existing update text +- [ ] Edit history preserved (updated_at changes) +- [ ] Cannot change timestamp or admin +- [ ] Updates displayed in chronological order +- [ ] Each update shows: +- [ ] Visual timeline representation +- [ ] HTML sanitization using `mews/purifier` package +- [ ] Audit log for add/edit operations via AdminLog +- [ ] Feature tests for all operations +- [ ] Can add update with valid text (min 10 chars) +- [ ] Cannot add update with empty text - validation error +- [ ] Cannot add update with text < 10 chars - validation error +- [ ] HTML is sanitized (script tags, XSS vectors removed) +- [ ] Client receives notification email on new update +- [ ] Audit log created when update is added +- [ ] Audit log created when update is edited (includes old/new values) +- [ ] Updates display in chronological order (oldest first) +- [ ] Admin name and timestamp automatically recorded +- [ ] Edit preserves original created_at, updates updated_at +- [ ] Cannot change timestamp or admin on edit diff --git a/docs/tasks/4-3.md b/docs/tasks/4-3.md new file mode 100644 index 0000000..cb62190 --- /dev/null +++ b/docs/tasks/4-3.md @@ -0,0 +1,29 @@ +--- +id: 4-3 +title: 4-3 Timeline Archiving +status: QA Review +date: 2026-09-27 +parent: 4 +--- + +## Description + +As an admin, I want to archive completed cases and unarchive if needed, So that I can organize active and completed case timelines. Context: Integrates with: timelines table (status field from Story 4.1); Technology: Livewire Volt; Follows pattern: Soft state change pattern. Add these methods to app/Models/Timeline.php:. Full implementation history: docs/stories/story-4.3-timeline-archiving.md + +## Acceptance Criteria + +- [ ] Archive button on timeline detail view (admin only) +- [ ] Confirmation modal before archiving ("Are you sure?") +- [ ] Status changes to 'archived' +- [ ] Timeline remains visible to client (read-only as always) +- [ ] No further updates can be added (show disabled state with tooltip) +- [ ] Visual indicator shows archived status (badge + muted styling) +- [ ] Unarchive button on archived timelines +- [ ] Status returns to 'active' +- [ ] Updates can be added again +- [ ] Archiving already-archived timeline: No-op, no error shown +- [ ] Unarchiving already-active timeline: No-op, no error shown +- [ ] Adding update to archived timeline: Prevented with error message +- [ ] Audit log for status changes (action: 'archive' or 'unarchive') - uses AdminLog `action` field +- [ ] Bilingual labels (AR/EN for buttons, messages) +- [ ] Feature tests covering all scenarios below diff --git a/docs/tasks/4-4.md b/docs/tasks/4-4.md new file mode 100644 index 0000000..3dbfbe5 --- /dev/null +++ b/docs/tasks/4-4.md @@ -0,0 +1,34 @@ +--- +id: 4-4 +title: 4-4 Admin Timeline Dashboard +status: QA Review +date: 2026-09-27 +parent: 4 +--- + +## Description + +As an admin, I want a central view to manage all timelines across all clients, So that I can efficiently track and update case progress. Context: Integrates with: timelines table, users table; Technology: Livewire Volt with pagination; Follows pattern: Admin list/dashboard pattern. resources/views/livewire/admin/timelines/index.blade.php. Full implementation history: docs/stories/story-4.4-admin-timeline-dashboard.md + +## Acceptance Criteria + +- [ ] Display all timelines with: +- [ ] Pagination (15/25/50 per page) +- [ ] Empty state message when no timelines exist +- [ ] Filter by client (search/select) +- [ ] Filter by status (active/archived/all) +- [ ] Filter by date range (created/updated) +- [ ] Search by case name or reference +- [ ] Clear filters option +- [ ] Show "No results" message when filters return empty +- [ ] Sort by client name +- [ ] Sort by case name +- [ ] Sort by last updated +- [ ] Sort by created date +- [ ] Visual indicator for current sort column/direction +- [ ] View timeline details +- [ ] Add update (inline or link) +- [ ] Archive/unarchive toggle with confirmation +- [ ] Fast loading with eager loading +- [ ] Bilingual support +- [ ] Tests for filtering/sorting diff --git a/docs/tasks/4-5.md b/docs/tasks/4-5.md new file mode 100644 index 0000000..4ae730e --- /dev/null +++ b/docs/tasks/4-5.md @@ -0,0 +1,29 @@ +--- +id: 4-5 +title: 4-5 Client Timeline View +status: QA Review +date: 2026-09-27 +parent: 4 +--- + +## Description + +As a client, I want to view my case timelines and updates, So that I can track the progress of my legal matters. Context: Integrates with: timelines, timeline_updates tables; Technology: Livewire Volt (read-only); Follows pattern: Client dashboard pattern. Full implementation history: docs/stories/story-4.5-client-timeline-view.md + +## Acceptance Criteria + +- [ ] Display all client's timelines +- [ ] Active timelines prominently displayed +- [ ] Archived timelines clearly separated +- [ ] Visual distinction (color/icon) for status +- [ ] Show for each: +- [ ] Case name and reference +- [ ] Status indicator +- [ ] All updates in chronological order +- [ ] Each update shows: +- [ ] Read-only (no edit/comment) +- [ ] No ability to archive/delete +- [ ] Only see own timelines (403 for unauthorized access) +- [ ] Recent updates indicator (new since last view, optional) +- [ ] Responsive design for mobile +- [ ] Bilingual labels and dates diff --git a/docs/tasks/4-6.md b/docs/tasks/4-6.md new file mode 100644 index 0000000..2b9912a --- /dev/null +++ b/docs/tasks/4-6.md @@ -0,0 +1,30 @@ +--- +id: 4-6 +title: 4-6 Timeline Update Notifications +status: QA Review +date: 2026-09-27 +parent: 4 +--- + +## Description + +As a client, I want to receive email notifications when my timeline is updated, So that I stay informed about my case progress without checking the portal. Context: Integrates with: timeline_updates creation, email system; Technology: Laravel Notifications, queued emails; Follows pattern: Event-driven notification pattern. Full implementation history: docs/stories/story-4.6-timeline-update-notifications.md + +## Acceptance Criteria + +- [ ] Email sent when new update added to timeline +- [ ] Triggered automatically on TimelineUpdate creation +- [ ] Queued for performance +- [ ] Case name and reference +- [ ] Update summary or full text +- [ ] Date of update +- [ ] Link to view timeline +- [ ] Libra branding +- [ ] Email in client's preferred language +- [ ] Arabic template +- [ ] English template +- [ ] No email for archived timeline reactivation +- [ ] No email if client deactivated +- [ ] Professional email template +- [ ] Tests for notification sending +- [ ] Error handling for failed sends diff --git a/docs/tasks/4.md b/docs/tasks/4.md new file mode 100644 index 0000000..ea17266 --- /dev/null +++ b/docs/tasks/4.md @@ -0,0 +1,21 @@ +--- +id: 4 +title: 4 Case Timeline System +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Lets the admin create and maintain one-way, text-only case timelines per client (multiple timelines per client, active/archived states), with clients able to view (read-only) their timelines and receive email notifications on updates. + +## Acceptance Criteria + +- [ ] Admin can create unlimited timelines per client +- [ ] Admin can add text updates to timelines +- [ ] Admin can edit existing updates +- [ ] Admin can archive/unarchive timelines +- [ ] Clients can view their timelines (read-only) +- [ ] Clients notified via email on updates +- [ ] Update history with timestamps preserved +- [ ] Clear visual distinction between active/archived diff --git a/docs/tasks/5-1.md b/docs/tasks/5-1.md new file mode 100644 index 0000000..775f46e --- /dev/null +++ b/docs/tasks/5-1.md @@ -0,0 +1,33 @@ +--- +id: 5-1 +title: 5-1 Post Creation & Editing +status: QA Review +date: 2026-09-27 +parent: 5 +--- + +## Description + +As an admin, I want to create and edit blog posts with rich text formatting, So that I can publish professional legal content for website visitors. Context: Integrates with: posts table; Technology: Livewire Volt, TinyMCE or similar rich text editor; Follows pattern: Admin CRUD pattern. Use the mews/purifier package for HTML sanitization via the clean() helper:. Full implementation history: docs/stories/story-5.1-post-creation-editing.md + +## Acceptance Criteria + +- [ ] Title (required, bilingual: Arabic and English) +- [ ] Body content (required, bilingual) +- [ ] Status (draft/published) +- [ ] Bold, italic, underline +- [ ] Headings (H2, H3) +- [ ] Bullet and numbered lists +- [ ] Links +- [ ] Blockquotes +- [ ] Save as draft functionality +- [ ] Preview post before publishing +- [ ] Edit published posts +- [ ] Auto-save draft periodically (every 60 seconds) +- [ ] Immediate publishing (no scheduling) +- [ ] created_at recorded on creation +- [ ] updated_at updated on edit +- [ ] HTML sanitization for XSS prevention +- [ ] Bilingual form labels +- [ ] Audit log for create/edit +- [ ] Tests for CRUD operations diff --git a/docs/tasks/5-2.md b/docs/tasks/5-2.md new file mode 100644 index 0000000..6d7f598 --- /dev/null +++ b/docs/tasks/5-2.md @@ -0,0 +1,30 @@ +--- +id: 5-2 +title: 5-2 Post Management Dashboard +status: QA Review +date: 2026-09-27 +parent: 5 +--- + +## Description + +As an admin, I want a dashboard to manage all blog posts, So that I can organize, publish, and maintain content efficiently. Context: Integrates with: posts table, admin_logs table; Technology: Livewire Volt with pagination; Follows pattern: Admin list pattern (see similar components in `resources/views/livewire/admin/`). Create Volt component at: resources/views/livewire/admin/posts/index.blade.php. Full implementation history: docs/stories/story-5.2-post-management-dashboard.md + +## Acceptance Criteria + +- [ ] Display all posts with: +- [ ] Pagination (10/25/50 per page) +- [ ] Filter by status (draft/published/all) +- [ ] Search by title or body content +- [ ] Sort by date (newest/oldest) +- [ ] Edit post +- [ ] Delete (with confirmation) +- [ ] Publish/unpublish toggle +- [ ] Bulk delete option (optional) - **OUT OF SCOPE** +- [ ] Bilingual labels +- [ ] Audit log for delete and status change actions +- [ ] Authorization check (admin only) on all actions +- [ ] Tests for list operations +- [ ] Handle post not found gracefully (race condition on delete) +- [ ] Per-page selector visible in UI (10/25/50 options) +- [ ] Bulk delete is **out of scope** for this story (marked optional) diff --git a/docs/tasks/5-3.md b/docs/tasks/5-3.md new file mode 100644 index 0000000..3a46164 --- /dev/null +++ b/docs/tasks/5-3.md @@ -0,0 +1,26 @@ +--- +id: 5-3 +title: 5-3 Post Deletion +status: QA Review +date: 2026-09-27 +parent: 5 +--- + +## Description + +As an admin, I want to permanently delete posts, So that I can remove outdated or incorrect content from the website. Context: Integrates with: posts table; Technology: Livewire Volt; Follows pattern: Permanent delete pattern. Add delete button to the post edit form (from Story 5.1) when editing an existing post:. Full implementation history: docs/stories/story-5.3-post-deletion.md + +## Acceptance Criteria + +- [ ] Delete button on post list (primary location) +- [ ] Delete button on post edit page (secondary location) +- [ ] Confirmation modal dialog before deletion +- [ ] Permanent deletion (no soft delete per PRD) +- [ ] Success message after deletion +- [ ] Redirect to post list after deletion from edit page +- [ ] Admin-only access (middleware protection) +- [ ] Audit log entry preserved +- [ ] Old values stored in log +- [ ] Clear warning in confirmation +- [ ] Bilingual messages +- [ ] Tests for deletion diff --git a/docs/tasks/5-4.md b/docs/tasks/5-4.md new file mode 100644 index 0000000..7ed2f82 --- /dev/null +++ b/docs/tasks/5-4.md @@ -0,0 +1,32 @@ +--- +id: 5-4 +title: 5-4 Public Posts Display +status: QA Review +date: 2026-09-27 +parent: 5 +--- + +## Description + +As a website visitor, I want to view published blog posts, So that I can read legal updates and articles from the firm. Context: Integrates with: posts table (published only); Technology: Livewire Volt (public routes); Follows pattern: Public content display. Full implementation history: docs/stories/story-5.4-public-posts-display.md + +## Acceptance Criteria + +- [ ] Public access (no login required) +- [ ] Display in reverse chronological order +- [ ] Each post card shows: +- [ ] Pagination for many posts +- [ ] Full post content displayed +- [ ] Clean, readable typography +- [ ] Publication date shown +- [ ] Back to posts list link +- [ ] Content displayed based on current site language +- [ ] Title and body in selected language +- [ ] Date formatting per locale +- [ ] Responsive design (mobile-friendly) +- [ ] Professional typography +- [ ] Consistent with brand colors +- [ ] Only published posts visible +- [ ] Fast loading +- [ ] SEO-friendly URLs (optional per PRD) +- [ ] Tests for display logic diff --git a/docs/tasks/5-5.md b/docs/tasks/5-5.md new file mode 100644 index 0000000..22cd3b4 --- /dev/null +++ b/docs/tasks/5-5.md @@ -0,0 +1,27 @@ +--- +id: 5-5 +title: 5-5 Post Search +status: QA Review +date: 2026-09-27 +parent: 5 +--- + +## Description + +As a website visitor, I want to search through blog posts, So that I can find relevant legal articles and information. Context: Integrates with: posts table, public posts listing; Technology: Livewire Volt with real-time search; Follows pattern: Search component pattern. Full implementation history: docs/stories/story-5.5-post-search.md + +## Acceptance Criteria + +- [ ] Search input on posts listing page +- [ ] Search by title (both languages) +- [ ] Search by body content (both languages) +- [ ] Real-time search results (debounced) +- [ ] "No results found" message when empty +- [ ] Clear search button +- [ ] Search works in both Arabic and English +- [ ] Only searches published posts +- [ ] Search highlights in results +- [ ] Search suggestions +- [ ] Debounce to reduce server load (300ms) +- [ ] Case-insensitive search +- [ ] Tests for search functionality diff --git a/docs/tasks/5.md b/docs/tasks/5.md new file mode 100644 index 0000000..1916597 --- /dev/null +++ b/docs/tasks/5.md @@ -0,0 +1,21 @@ +--- +id: 5 +title: 5 Posts/Blog System +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +An admin-only publishing system for legal articles/news: rich-text creation and editing, draft saving, deletion, public bilingual display in reverse-chronological order, and simple title/body search — all without login or comments. + +## Acceptance Criteria + +- [ ] Admin can create, edit, delete posts +- [ ] Rich text editor for formatting +- [ ] Draft saving capability +- [ ] Posts publicly visible +- [ ] Search functionality +- [ ] Reverse chronological display +- [ ] Bilingual content support +- [ ] Responsive design diff --git a/docs/tasks/6-1.md b/docs/tasks/6-1.md new file mode 100644 index 0000000..51f4b1c --- /dev/null +++ b/docs/tasks/6-1.md @@ -0,0 +1,33 @@ +--- +id: 6-1 +title: 6-1 Dashboard Overview & Statistics +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to see real-time metrics and key statistics at a glance, So that I can understand the current state of my practice. Full implementation history: docs/stories/story-6.1-dashboard-overview-statistics.md + +## Acceptance Criteria + +- [ ] Total active clients (individual + company with status = active) +- [ ] Individual vs company breakdown (count each type) +- [ ] Deactivated clients count +- [ ] New clients this month (created_at in current month) +- [ ] Pending requests count (highlighted with warning color) +- [ ] Today's consultations (scheduled for today, approved status) +- [ ] This week's consultations +- [ ] This month's consultations +- [ ] Free vs paid breakdown (consultation_type field) +- [ ] No-show rate percentage (no-show / total completed * 100) +- [ ] Active case timelines (status = active) +- [ ] Archived timelines (status = archived) +- [ ] Updates added this week (timeline_updates created in last 7 days) +- [ ] Total published posts (status = published) +- [ ] Posts published this month +- [ ] Clean card-based layout using Flux UI components +- [ ] Color-coded status indicators (gold for highlights, success green, warning colors) +- [ ] Responsive grid (2 columns on tablet, 1 on mobile, 4 on desktop) +- [ ] Navy blue and gold color scheme per PRD Section 7.1 diff --git a/docs/tasks/6-10.md b/docs/tasks/6-10.md new file mode 100644 index 0000000..edce6e0 --- /dev/null +++ b/docs/tasks/6-10.md @@ -0,0 +1,34 @@ +--- +id: 6-10 +title: 6-10 Audit Log Viewer +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to view admin action history, So that I can maintain accountability and track changes. - resources/views/livewire/admin/audit-logs.blade.php - Main Volt component - app/Models/AdminLog.php - Eloquent model (if not already created in Story 1.1) - routes/web.php - Add admin route (or admin routes file) - lang/ar/audit.php - Arabic translations - lang/en/audit.php - English translations. Full implementation history: docs/stories/story-6.10-audit-log-viewer.md + +## Acceptance Criteria + +- [ ] Paginated table of audit log entries (25 per page) +- [ ] Each row displays: +- [ ] Filter by action type (dropdown with available actions) +- [ ] Filter by target type (dropdown with available targets) +- [ ] Filter by date range (date pickers for from/to) +- [ ] Filters apply without page reload (Livewire) +- [ ] Reset filters button +- [ ] Search by target ID (exact match) +- [ ] Search updates results in real-time with debounce +- [ ] Modal displays full log entry details +- [ ] Shows old values in readable format (JSON pretty-printed) +- [ ] Shows new values in readable format +- [ ] Highlights differences between old/new for updates +- [ ] Bilingual labels +- [ ] Export current filtered results to CSV +- [ ] CSV includes all displayed columns +- [ ] CSV filename includes export date +- [ ] Bilingual column headers based on admin's language preference +- [ ] Friendly message when no logs exist +- [ ] Friendly message when filters return no results diff --git a/docs/tasks/6-2.md b/docs/tasks/6-2.md new file mode 100644 index 0000000..04ce352 --- /dev/null +++ b/docs/tasks/6-2.md @@ -0,0 +1,39 @@ +--- +id: 6-2 +title: 6-2 Analytics Charts +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want visual charts showing trends and historical data, So that I can identify patterns in client acquisition and consultation outcomes to make informed business decisions. Full implementation history: docs/stories/story-6.2-analytics-charts.md + +## Acceptance Criteria + +- [ ] Display new clients per month (from `users.created_at`) +- [ ] Display consultations per month (from `consultations.scheduled_date`) +- [ ] Two data series on same chart with legend +- [ ] X-axis: Month labels (e.g., "Jan 2025", "Feb 2025") +- [ ] Y-axis: Count values with appropriate scale +- [ ] Show free vs paid consultation ratio +- [ ] Display percentage labels on segments +- [ ] Legend showing "Free" and "Paid" with counts +- [ ] Monthly no-show percentage trend +- [ ] X-axis: Month labels +- [ ] Y-axis: Percentage (0-100%) +- [ ] Visual threshold line at concerning rate (e.g., 20%) +- [ ] Preset options: Last 6 months, Last 12 months +- [ ] Custom date range picker (start/end month) +- [ ] Charts update when range changes +- [ ] Default selection: Last 6 months +- [ ] Tooltips showing exact values on hover +- [ ] Responsive sizing (charts resize with viewport) +- [ ] Bilingual labels (Arabic/English based on locale) +- [ ] Loading state while fetching data +- [ ] Empty state when no data available +- [ ] Charts section below statistics cards from Story 6.1 +- [ ] Card-based layout for each chart +- [ ] Navy blue and gold color scheme per PRD Section 7.1 +- [ ] Responsive grid (1 column mobile, 2 columns tablet+) diff --git a/docs/tasks/6-3.md b/docs/tasks/6-3.md new file mode 100644 index 0000000..61f64d8 --- /dev/null +++ b/docs/tasks/6-3.md @@ -0,0 +1,37 @@ +--- +id: 6-3 +title: 6-3 Quick Actions Panel +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want quick access to pending items and common tasks, So that I can efficiently manage my daily workflow without navigating away from the dashboard. Full implementation history: docs/stories/story-6.3-quick-actions-panel.md + +## Acceptance Criteria + +- [ ] Display count badge showing number of pending consultation requests +- [ ] Urgent indicator (red/warning styling) when pending count > 0 +- [ ] Mini list showing up to 5 most recent pending bookings with: +- [ ] "View All" link navigating to booking management page (`admin.bookings.pending`) +- [ ] Empty state message when no pending bookings +- [ ] List of today's approved consultations ordered by time +- [ ] Each item displays: +- [ ] Quick status buttons for each consultation: +- [ ] Empty state message when no consultations scheduled today +- [ ] Display last 5 timeline updates across all clients +- [ ] Each item shows: +- [ ] Click navigates to the specific timeline (`admin.timelines.show`) +- [ ] Empty state message when no recent updates +- [ ] **Create Client** button - navigates to `admin.clients.individual.create` +- [ ] **Create Post** button - navigates to `admin.posts.create` +- [ ] **Block Time Slot** button - opens modal to block availability +- [ ] Bell icon in admin header/navbar +- [ ] Badge showing total pending items count (pending bookings) +- [ ] Badge hidden when count is 0 +- [ ] Click navigates to pending bookings +- [ ] Widgets auto-refresh via Livewire polling every 30 seconds +- [ ] No full page reload required +- [ ] Visual indication during refresh (subtle loading state) - Using default Livewire behavior diff --git a/docs/tasks/6-4.md b/docs/tasks/6-4.md new file mode 100644 index 0000000..09a51f0 --- /dev/null +++ b/docs/tasks/6-4.md @@ -0,0 +1,42 @@ +--- +id: 6-4 +title: 6-4 Data Export - User Lists +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to export user data in CSV and PDF formats, So that I can generate reports and maintain offline records. Full implementation history: docs/stories/story-6.4-data-export-user-lists.md + +## Acceptance Criteria + +- [ ] Export all users (both individual and company clients) +- [ ] Export individual clients only (`user_type = 'individual'`) +- [ ] Export company clients only (`user_type = 'company'`) +- [ ] Date range filter on `created_at` field (start date, end date) +- [ ] Status filter: active, deactivated, or all +- [ ] Filters combine with export type (e.g., "active individual clients created in 2024") +- [ ] Name (`name` for individual, `company_name` for company) +- [ ] Email (`email`) +- [ ] Phone (`phone`) +- [ ] User type (`user_type`: individual/company) +- [ ] National ID / Company registration (`national_id` for individual, `company_cert_number` for company) +- [ ] Status (`status`: active/deactivated) +- [ ] Created date (`created_at` formatted per locale) +- [ ] UTF-8 BOM for proper Arabic character display in Excel +- [ ] Same data fields as CSV in tabular format +- [ ] Libra branding header (logo, firm name) +- [ ] Generation timestamp in footer +- [ ] Page numbers if multiple pages +- [ ] Professional formatting with brand colors (Navy #0A1F44, Gold #D4AF37) +- [ ] Column headers based on admin's `preferred_language` setting +- [ ] Date formatting per locale (DD/MM/YYYY for Arabic, MM/DD/YYYY for English) +- [ ] PDF title and footer text bilingual +- [ ] Export section accessible from Admin User Management page +- [ ] Filter form with: user type dropdown, status dropdown, date range picker +- [ ] "Export CSV" and "Export PDF" buttons +- [ ] Loading indicator during export generation +- [ ] Success toast on download start +- [ ] Error toast if export fails diff --git a/docs/tasks/6-5.md b/docs/tasks/6-5.md new file mode 100644 index 0000000..b54b961 --- /dev/null +++ b/docs/tasks/6-5.md @@ -0,0 +1,30 @@ +--- +id: 6-5 +title: 6-5 Data Export - Consultation Records +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to export consultation/booking data in CSV and PDF formats, So that I can generate reports for accounting, analyze consultation patterns, and maintain offline records of client interactions. Follow the export pattern established in Story 6.4. Reuse any base export functionality created there. Full implementation history: docs/stories/story-6.5-data-export-consultation-records.md + +## Acceptance Criteria + +- [ ] Export all consultations +- [ ] Export filtered subset based on criteria below +- [ ] Date range (booking_date between start/end) +- [ ] Consultation type (free/paid) +- [ ] Status (pending/approved/completed/no-show/cancelled/rejected) +- [ ] Payment status (pending/received/na) +- [ ] Client name (from user relationship) +- [ ] Date and time (booking_date, booking_time) +- [ ] Consultation type (free/paid) +- [ ] Status +- [ ] Payment status +- [ ] Problem summary (truncated in PDF if > 500 chars) +- [ ] CSV format with streaming download +- [ ] PDF format with professional layout and Libra branding +- [ ] Column headers based on admin's preferred language +- [ ] Use translation keys from `lang/{locale}/export.php` diff --git a/docs/tasks/6-6.md b/docs/tasks/6-6.md new file mode 100644 index 0000000..e59642a --- /dev/null +++ b/docs/tasks/6-6.md @@ -0,0 +1,33 @@ +--- +id: 6-6 +title: 6-6 Data Export - Timeline Reports +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to export timeline and case data, So that I can maintain records and generate case reports. Context: Follows pattern: Story 6.4 (User Lists Export) and Story 6.5 (Consultation Export) - same UI layout, filter approach, and export mechanisms; Integrates with: Timeline model, TimelineUpdate model, User model; Technology: Livewire Volt, Flux UI, league/csv, barryvdh/laravel-dompdf. Full implementation history: docs/stories/story-6.6-data-export-timeline-reports.md + +## Acceptance Criteria + +- [ ] Export all timelines (across all clients) +- [ ] Export timelines for specific client (client selector/search) +- [ ] Status filter (active/archived/all) +- [ ] Date range filter (created_at) +- [ ] Client filter (search by name/email) +- [ ] Case name and reference +- [ ] Client name +- [ ] Status +- [ ] Created date +- [ ] Number of updates +- [ ] Last update date +- [ ] CSV format with bilingual headers +- [ ] PDF format with Libra branding +- [ ] Include update content toggle (full content vs summary only) +- [ ] When enabled, PDF includes all update entries per timeline +- [ ] Filter controls match Story 6.4/6.5 layout +- [ ] Export buttons clearly visible +- [ ] Loading state during export generation +- [ ] Success/error feedback messages diff --git a/docs/tasks/6-7.md b/docs/tasks/6-7.md new file mode 100644 index 0000000..ed55c3c --- /dev/null +++ b/docs/tasks/6-7.md @@ -0,0 +1,52 @@ +--- +id: 6-7 +title: 6-7 Monthly Statistics Report +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to generate comprehensive monthly PDF reports from the admin dashboard, So that I can archive business performance records, share summaries with stakeholders, and track month-over-month trends. Full implementation history: docs/stories/story-6.7-monthly-statistics-report.md + +## Acceptance Criteria + +- [ ] "Generate Monthly Report" button in admin dashboard (below metrics cards or in a Reports section) +- [ ] Month/year selector dropdown (default: previous month) +- [ ] Selectable range: last 12 months only (no future months) +- [ ] Libra logo and branding +- [ ] Report title: "Monthly Statistics Report" +- [ ] Period: Month and Year (e.g., "December 2025") +- [ ] Generated date and time +- [ ] List of sections with page numbers +- [ ] Non-clickable (simple text list for print compatibility) +- [ ] Key highlights (2-3 bullet points) +- [ ] Month-over-month comparison if prior month data exists +- [ ] New clients registered this month +- [ ] Total active clients (end of month) +- [ ] Individual vs company breakdown +- [ ] Client growth trend (compared to previous month) +- [ ] Total consultations this month +- [ ] Approved/Completed/Cancelled/No-show breakdown +- [ ] Free vs paid ratio +- [ ] No-show rate percentage +- [ ] Pie chart: Consultation types (rendered as image) +- [ ] Active timelines (end of month) +- [ ] New timelines created this month +- [ ] Timeline updates added this month +- [ ] Archived timelines this month +- [ ] Posts published this month +- [ ] Total published posts (cumulative) +- [ ] Line chart showing monthly consultations trend (last 6 months ending with selected month) +- [ ] Rendered as base64 PNG image +- [ ] Professional A4 portrait layout +- [ ] Libra branding: Navy Blue (#0A1F44) headers, Gold (#D4AF37) accents +- [ ] Consistent typography and spacing +- [ ] Print-friendly (no dark backgrounds, adequate margins) +- [ ] Bilingual: Arabic or English based on admin's `preferred_language` setting +- [ ] Loading indicator with "Generating report..." message during PDF creation +- [ ] Disable generate button while processing +- [ ] Auto-download PDF on completion +- [ ] Success toast notification after download starts +- [ ] Error handling with user-friendly message if generation fails diff --git a/docs/tasks/6-8.md b/docs/tasks/6-8.md new file mode 100644 index 0000000..e8b4201 --- /dev/null +++ b/docs/tasks/6-8.md @@ -0,0 +1,26 @@ +--- +id: 6-8 +title: 6-8 System Settings +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to configure system-wide settings, So that I can customize the platform to my needs. Add preferred_language column to users table:. Full implementation history: docs/stories/story-6.8-system-settings.md + +## Acceptance Criteria + +- [ ] Admin name +- [ ] Email +- [ ] Password change +- [ ] Preferred language +- [ ] Display current sender email from `config('mail.from.address')` +- [ ] Display current sender name from `config('mail.from.name')` +- [ ] "Send Test Email" button that sends a test email to admin's email address +- [ ] Success/error feedback after test email attempt +- [ ] Settings saved and applied immediately +- [ ] Validation for all inputs +- [ ] Flash messages for success/error states +- [ ] Password fields cleared after successful update diff --git a/docs/tasks/6-9.md b/docs/tasks/6-9.md new file mode 100644 index 0000000..7f40656 --- /dev/null +++ b/docs/tasks/6-9.md @@ -0,0 +1,30 @@ +--- +id: 6-9 +title: 6-9 Legal Pages Editor +status: QA Review +date: 2026-09-27 +parent: 6 +--- + +## Description + +As an admin, I want to edit Terms of Service and Privacy Policy pages, So that I can maintain legal compliance and update policies. This project uses **class-based Volt components** for interactivity. Follow existing patterns in resources/views/livewire/. Full implementation history: docs/stories/story-6.9-legal-pages-editor.md + +## Acceptance Criteria + +- [ ] Terms of Service (`/page/terms`) +- [ ] Privacy Policy (`/page/privacy`) +- [ ] Rich text editor using Quill.js (lightweight, RTL-friendly) +- [ ] Bilingual content with Arabic/English tabs in editor UI +- [ ] Save and publish button updates database immediately +- [ ] Preview opens modal showing rendered content in selected language +- [ ] HTML content sanitized before save (prevent XSS) +- [ ] Accessible under Admin Dashboard > Settings section +- [ ] Sidebar item: "Legal Pages" or integrate into Settings page +- [ ] List view showing both pages with "Edit" action +- [ ] Edit page shows language tabs (Arabic | English) above editor +- [ ] Pages accessible from footer links (no auth required) +- [ ] Route: `/page/{slug}` where slug is `terms` or `privacy` +- [ ] Content displayed in user's current language preference +- [ ] Last updated timestamp displayed at bottom of page +- [ ] Professional layout consistent with site design (navy/gold) diff --git a/docs/tasks/6.md b/docs/tasks/6.md new file mode 100644 index 0000000..b951204 --- /dev/null +++ b/docs/tasks/6.md @@ -0,0 +1,21 @@ +--- +id: 6 +title: 6 Admin Dashboard +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +A centralized control panel for the admin: overview statistics, Chart.js analytics, a quick-actions panel, CSV/PDF data exports (users, consultations, timelines, monthly stats), system settings, a legal-pages (Terms/Privacy) editor, and an audit-log viewer. + +## Acceptance Criteria + +- [ ] Overview dashboard with key metrics +- [ ] Charts for trends and analytics +- [ ] Quick access to pending actions +- [ ] Data export (CSV, PDF) +- [ ] System settings management +- [ ] Legal pages editor (Terms, Privacy) +- [ ] Audit log visibility +- [ ] Responsive design for tablet use diff --git a/docs/tasks/7-1.md b/docs/tasks/7-1.md new file mode 100644 index 0000000..2c6c270 --- /dev/null +++ b/docs/tasks/7-1.md @@ -0,0 +1,44 @@ +--- +id: 7-1 +title: 7-1 Client Dashboard Overview +status: QA Review +date: 2026-09-27 +parent: 7 +--- + +## Description + +As a client, I want a dashboard showing my key information at a glance, So that I can quickly see upcoming consultations and case updates. Full implementation history: docs/stories/story-7.1-client-dashboard-overview.md + +## Acceptance Criteria + +- [ ] Display "Welcome, {client name}" greeting +- [ ] Use localized greeting based on user's preferred language +- [ ] Show current date in user's locale format +- [ ] Display next approved consultation (or "No upcoming consultations" if none) +- [ ] Show consultation date/time formatted per locale (AR: DD/MM/YYYY, EN: MM/DD/YYYY) +- [ ] Show time in 12-hour format (AM/PM) +- [ ] Display type badge: "Free" (green) or "Paid" (gold) +- [ ] Display status badge with appropriate color +- [ ] "View Details" link to consultation details (Story 7.2) +- [ ] Display count of active timelines +- [ ] Show preview of most recent update (truncated to ~100 chars) +- [ ] "View All Cases" link to timelines list (Story 7.3) +- [ ] Empty state: "No active cases" with muted styling +- [ ] Display last 3 timeline updates across all user's cases +- [ ] Each update shows: case name, update date, preview text +- [ ] "View Timeline" link for each update +- [ ] Empty state: "No recent updates" +- [ ] Display count of pending booking requests +- [ ] Show booking limit indicator: +- [ ] "Book Consultation" button linking to booking page (Story 7.5) +- [ ] Disable button if daily limit reached +- [ ] Card-based layout using Flux UI components +- [ ] Color scheme: Navy (#0A1F44) background sections, Gold (#D4AF37) accents +- [ ] Mobile-first responsive (stack cards vertically on mobile) +- [ ] All text content bilingual (Arabic RTL / English LTR) +- [ ] Use consistent spacing: `gap-6` between cards, `p-6` card padding +- [ ] No consultations: Show empty state with "Book your first consultation" CTA +- [ ] No timelines: Show empty state "No cases assigned yet" +- [ ] No updates: Show empty state "No recent updates" +- [ ] Loading state: Show skeleton loaders while data fetches diff --git a/docs/tasks/7-2.md b/docs/tasks/7-2.md new file mode 100644 index 0000000..4e59412 --- /dev/null +++ b/docs/tasks/7-2.md @@ -0,0 +1,33 @@ +--- +id: 7-2 +title: 7-2 My Consultations View +status: QA Review +date: 2026-09-27 +parent: 7 +--- + +## Description + +As a client, I want to view all my consultations, So that I can track upcoming appointments and review past sessions. - resources/views/livewire/client/consultations.blade.php - Main Volt component - routes/web.php - Add route within client middleware group. Full implementation history: docs/stories/story-7.2-my-consultations-view.md + +## Acceptance Criteria + +- [ ] Date and time (formatted per locale) +- [ ] Consultation type (free/paid) +- [ ] Status (approved/pending) +- [ ] Payment status (for paid consultations) +- [ ] Download .ics calendar file button +- [ ] Submitted bookings awaiting approval +- [ ] Submission date +- [ ] Problem summary preview (truncated) +- [ ] Status: "Pending Review" +- [ ] Historical consultations +- [ ] Status (completed/cancelled/no-show) +- [ ] Date and type +- [ ] Visual status indicators (badges with colors) +- [ ] Sort by date (default: newest first for past) +- [ ] Pagination if many consultations (10 per page) +- [ ] No edit/cancel capabilities (read-only) +- [ ] "No upcoming consultations" message with link to book +- [ ] "No pending requests" message +- [ ] "No past consultations" message diff --git a/docs/tasks/7-3.md b/docs/tasks/7-3.md new file mode 100644 index 0000000..dff01d8 --- /dev/null +++ b/docs/tasks/7-3.md @@ -0,0 +1,25 @@ +--- +id: 7-3 +title: 7-3 My Cases/Timelines View (Dashboard Integration) +status: QA Review +date: 2026-09-27 +parent: 7 +--- + +## Description + +As a client, I want to access my case timelines from the dashboard navigation, So that I can easily track the progress of my legal matters from one central location. Context: Story 4.5: Client Timeline View - MUST be complete (provides all timeline components); Story 7.1: Client Dashboard Overview - MUST be complete (provides dashboard layout and navigation). Full implementation history: docs/stories/story-7.3-my-cases-timelines-view.md + +## Acceptance Criteria + +- [ ] "My Cases" navigation item added to client dashboard sidebar/nav +- [ ] Navigation links to `route('client.timelines.index')` +- [ ] Active state shown when on timeline routes +- [ ] Icon: folder or briefcase icon for cases +- [ ] "My Cases" widget card displays: +- [ ] Widget shows empty state if no cases exist +- [ ] Timeline pages use client dashboard layout (consistent header/nav) +- [ ] Breadcrumbs: Dashboard > My Cases (on index) - *Not implemented: would require modifying Story 4.5 components* +- [ ] Breadcrumbs: Dashboard > My Cases > [Case Name] (on show) - *Not implemented: would require modifying Story 4.5 components* +- [ ] Navigation label translated (AR/EN) +- [ ] Widget content translated (AR/EN) diff --git a/docs/tasks/7-4.md b/docs/tasks/7-4.md new file mode 100644 index 0000000..f85027b --- /dev/null +++ b/docs/tasks/7-4.md @@ -0,0 +1,32 @@ +--- +id: 7-4 +title: 7-4 My Profile View +status: QA Review +date: 2026-09-27 +parent: 7 +--- + +## Description + +As a client, I want to view my profile information, So that I can verify my account details are correct. Full implementation history: docs/stories/story-7.4-my-profile-view.md + +## Acceptance Criteria + +- [ ] Full name displayed +- [ ] National ID displayed +- [ ] Email address displayed +- [ ] Phone number displayed +- [ ] Preferred language displayed +- [ ] Account created date displayed +- [ ] Company name displayed +- [ ] Company certificate/registration number displayed +- [ ] Contact person name displayed +- [ ] Contact person ID displayed +- [ ] Email address displayed +- [ ] Phone number displayed +- [ ] Preferred language displayed +- [ ] Account created date displayed +- [ ] Account type indicator (Individual/Company badge) +- [ ] No edit capabilities (read-only view) +- [ ] Message: "Contact admin to update your information" +- [ ] Logout button with confirmation redirect diff --git a/docs/tasks/7-5.md b/docs/tasks/7-5.md new file mode 100644 index 0000000..d706a8b --- /dev/null +++ b/docs/tasks/7-5.md @@ -0,0 +1,27 @@ +--- +id: 7-5 +title: 7-5 New Booking Interface +status: QA Review +date: 2026-09-27 +parent: 7 +--- + +## Description + +As a client, I want to submit new consultation booking requests, So that I can schedule meetings with the lawyer. Reuse availability calendar from Story 3.3 and booking submission from Story 3.4. Full implementation history: docs/stories/story-7.5-new-booking-interface.md + +## Acceptance Criteria + +- [ ] Quick access from dashboard +- [ ] Book Now button in navigation +- [ ] Calendar showing available dates +- [ ] Available time slots for selected date +- [ ] Selected date/time (display) +- [ ] Problem summary (required, textarea) +- [ ] Submit button +- [ ] Enforce 1 booking per day limit +- [ ] Show warning if already booked that day +- [ ] Prevent booking on unavailable slots +- [ ] Confirmation before submission +- [ ] Success message with "Pending Review" status +- [ ] Redirect to consultations list diff --git a/docs/tasks/7-6.md b/docs/tasks/7-6.md new file mode 100644 index 0000000..25fc9cb --- /dev/null +++ b/docs/tasks/7-6.md @@ -0,0 +1,27 @@ +--- +id: 7-6 +title: 7-6 Booking Limit Indicator +status: QA Review +date: 2026-09-27 +parent: 7 +--- + +## Description + +As a client, I want to see my booking status and limits clearly, So that I understand when I can book consultations. - resources/views/livewire/client/booking-status.blade.php - Reusable status component. Full implementation history: docs/stories/story-7.6-booking-limit-indicator.md + +## Acceptance Criteria + +- [ ] Dashboard widget showing booking status +- [ ] Booking page status banner +- [ ] "You can book a consultation today" (when no booking exists for today) +- [ ] "You already have a booking for today" (when pending/approved booking exists for today) +- [ ] "You have a pending request for [date]" (shows first pending request date) +- [ ] Pass `bookedDates` array to availability calendar component +- [ ] Calendar marks user's booked dates as unavailable (distinct styling) +- [ ] Visual indicator differentiates "user already booked" from "no slots available" +- [ ] Clear messaging about 1-per-day limit +- [ ] Bilingual messages (Arabic/English) +- [ ] Handle multiple pending requests (show count or list) +- [ ] Handle cancelled bookings (should not block new booking) +- [ ] Loading state while fetching booking status diff --git a/docs/tasks/7.md b/docs/tasks/7.md new file mode 100644 index 0000000..dffc53f --- /dev/null +++ b/docs/tasks/7.md @@ -0,0 +1,21 @@ +--- +id: 7 +title: 7 Client Dashboard +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +The authenticated client portal: an overview dashboard, views of upcoming/past consultations and case timelines (read-mostly), profile viewing, a new-booking interface, and a booking-limit (1/day) indicator — all mobile-responsive. + +## Acceptance Criteria + +- [ ] Client overview dashboard +- [ ] View upcoming and past consultations +- [ ] Download calendar files +- [ ] View case timelines (read-only) +- [ ] View profile information +- [ ] Submit new booking requests +- [ ] Booking limit enforcement (1 per day) +- [ ] Responsive mobile design diff --git a/docs/tasks/8-1.md b/docs/tasks/8-1.md new file mode 100644 index 0000000..f299e67 --- /dev/null +++ b/docs/tasks/8-1.md @@ -0,0 +1,27 @@ +--- +id: 8-1 +title: 8-1 Email Infrastructure Setup +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a developer, I want to configure email sending infrastructure and base templates, So that all emails have consistent branding and reliable delivery. Full implementation history: docs/stories/story-8.1-email-infrastructure-setup.md + +## Acceptance Criteria + +- [ ] MAIL_MAILER configured via .env +- [ ] MAIL_HOST, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD +- [ ] MAIL_ENCRYPTION (TLS) +- [ ] MAIL_FROM_ADDRESS: no-reply@libra.ps +- [ ] MAIL_FROM_NAME: Libra Law Firm / مكتب ليبرا للمحاماة +- [ ] Libra logo in header +- [ ] Navy blue (#0A1F44) and gold (#D4AF37) colors +- [ ] Professional typography +- [ ] Footer with firm contact info +- [ ] Mobile-responsive layout +- [ ] Plain text fallback generation (auto-generated from HTML) +- [ ] Queue configuration for async sending (database driver) +- [ ] Email logging for debugging (log channel) diff --git a/docs/tasks/8-10.md b/docs/tasks/8-10.md new file mode 100644 index 0000000..9280fd8 --- /dev/null +++ b/docs/tasks/8-10.md @@ -0,0 +1,27 @@ +--- +id: 8-10 +title: 8-10 Admin Notification - System Events +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As an admin, I want to be notified of critical system events, So that I can address issues promptly. - app/Notifications/SystemErrorNotification.php - app/Notifications/QueueFailureNotification.php - app/Contracts/ShouldNotifyAdmin.php (marker interface) - app/Services/AdminNotificationService.php (rate limiting logic). Full implementation history: docs/stories/story-8.10-admin-notification-system-events.md + +## Acceptance Criteria + +- [ ] Email delivery failures (SMTP errors, bounces) +- [ ] Scheduled job failures (Laravel scheduler) +- [ ] Queue job failures +- [ ] Critical application errors (database, payment, etc.) +- [ ] Event type and description +- [ ] Timestamp (formatted per locale) +- [ ] Relevant details (error message, stack trace summary, job name) +- [ ] Recommended action (if applicable) +- [ ] Environment indicator (production/staging) +- [ ] Sent immediately using sync mail driver (not queued) +- [ ] Clear subject line indicating urgency with event type +- [ ] Rate limited: max 1 notification per error type per 15 minutes +- [ ] Uses base email template from Story 8.1 diff --git a/docs/tasks/8-2.md b/docs/tasks/8-2.md new file mode 100644 index 0000000..a271328 --- /dev/null +++ b/docs/tasks/8-2.md @@ -0,0 +1,29 @@ +--- +id: 8-2 +title: 8-2 Welcome Email (Account Created) +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a new client, I want to receive a welcome email with my login credentials, So that I can access the platform. - Base email template with Libra branding (navy #0A1F44, gold #D4AF37) - Queue configuration for async email delivery - SMTP configuration via .env. Full implementation history: docs/stories/story-8.2-welcome-email.md + +## Acceptance Criteria + +- [ ] Sent automatically on user creation by admin +- [ ] Queued for performance (implements `ShouldQueue`) +- [ ] Triggered via admin creation action (recommended approach per Technical Notes) +- [ ] Personalized greeting (name/company) +- [ ] "Your account has been created" message +- [ ] Login credentials (email, password) +- [ ] Login URL link with button +- [ ] Brief platform introduction +- [ ] Contact info for questions +- [ ] Email in user's `preferred_language` field +- [ ] Default to Arabic ('ar') if `preferred_language` is null +- [ ] Arabic template +- [ ] English template +- [ ] Professional branding (inherits from base template in Story 8.1) +- [ ] Call-to-action button: "Login Now" / "تسجيل الدخول" diff --git a/docs/tasks/8-3.md b/docs/tasks/8-3.md new file mode 100644 index 0000000..0c8d811 --- /dev/null +++ b/docs/tasks/8-3.md @@ -0,0 +1,32 @@ +--- +id: 8-3 +title: 8-3 Booking Submitted Confirmation +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a client, I want to receive confirmation when I submit a booking request, So that I know my request was received and what to expect next. Send the email after successful consultation creation. Typical location:. Full implementation history: docs/stories/story-8.3-booking-submitted-confirmation.md + +## Acceptance Criteria + +- [ ] Sent immediately after successful consultation creation +- [ ] Consultation status: pending +- [ ] Email queued for async delivery +- [ ] Subject line: "Your consultation request has been submitted" / "تم استلام طلب الاستشارة" +- [ ] Personalized greeting with client name +- [ ] "Your consultation request has been submitted" message +- [ ] Requested date and time (formatted per user's language preference) +- [ ] Problem summary preview (first 200 characters, with "..." if truncated) +- [ ] "Pending Review" status note with visual indicator +- [ ] Expected response timeframe: "We will review your request and respond within 1-2 business days" +- [ ] Contact information for questions +- [ ] Email sent in client's `preferred_language` (default: 'ar') +- [ ] Arabic template for Arabic users +- [ ] English template for English users +- [ ] Uses base email template from Story 8.1 +- [ ] No action required message (informational only) +- [ ] Professional template with Libra branding +- [ ] Gold call-to-action style for "View My Bookings" link (optional) diff --git a/docs/tasks/8-4.md b/docs/tasks/8-4.md new file mode 100644 index 0000000..0c16d4d --- /dev/null +++ b/docs/tasks/8-4.md @@ -0,0 +1,25 @@ +--- +id: 8-4 +title: 8-4 Booking Approved Email +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a client, I want to receive notification when my booking is approved, So that I can confirm the appointment and add it to my calendar. Full implementation history: docs/stories/story-8.4-booking-approved-email.md + +## Acceptance Criteria + +- [ ] Sent on booking approval by admin +- [ ] "Your consultation has been approved" +- [ ] Confirmed date and time +- [ ] Duration (45 minutes) +- [ ] Consultation type (free/paid) +- [ ] If paid: amount and payment instructions +- [ ] .ics calendar file attached +- [ ] "Add to Calendar" button +- [ ] Location/contact information +- [ ] Email in client's preferred language +- [ ] Valid .ics calendar file diff --git a/docs/tasks/8-5.md b/docs/tasks/8-5.md new file mode 100644 index 0000000..f69a2a4 --- /dev/null +++ b/docs/tasks/8-5.md @@ -0,0 +1,23 @@ +--- +id: 8-5 +title: 8-5 Booking Rejected Email +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a client, I want to be notified when my booking is rejected, So that I can understand why and request a new consultation if needed. Full implementation history: docs/stories/story-8.5-booking-rejected-email.md + +## Acceptance Criteria + +- [ ] Sent when consultation status changes to `'rejected'` +- [ ] "Your consultation request could not be approved" +- [ ] Original requested date and time +- [ ] Rejection reason (conditionally shown if provided by admin) +- [ ] Invitation to request new consultation +- [ ] Contact info for questions +- [ ] Empathetic, professional +- [ ] Email in client's preferred language (Arabic or English) +- [ ] Default to Arabic if no preference set diff --git a/docs/tasks/8-6.md b/docs/tasks/8-6.md new file mode 100644 index 0000000..4a35811 --- /dev/null +++ b/docs/tasks/8-6.md @@ -0,0 +1,27 @@ +--- +id: 8-6 +title: 8-6 Consultation Reminder (24 Hours) +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a client, I want to receive a reminder 24 hours before my consultation, So that I don't forget my appointment. Add tracking column to prevent duplicate reminders:. Full implementation history: docs/stories/story-8.6-consultation-reminder-24h.md + +## Acceptance Criteria + +- [ ] Scheduled artisan command runs hourly +- [ ] Find consultations approximately 24 hours away (within 30-minute window) +- [ ] Only for approved consultations (`status = 'approved'`) +- [ ] Skip cancelled/no-show/completed consultations +- [ ] Track sent reminders to prevent duplicates +- [ ] Subject: "Reminder: Your consultation is tomorrow" / "تذكير: استشارتك غدًا" +- [ ] Consultation date and time (formatted per locale) +- [ ] Consultation type (free/paid) +- [ ] Payment reminder: Show if `consultation_type = 'paid'` AND `payment_status != 'received'` +- [ ] Calendar file download link (using route to CalendarService) +- [ ] Office contact information for questions +- [ ] Email rendered in client's `preferred_language` (ar/en) +- [ ] Date/time formatted according to locale diff --git a/docs/tasks/8-7.md b/docs/tasks/8-7.md new file mode 100644 index 0000000..1a93e57 --- /dev/null +++ b/docs/tasks/8-7.md @@ -0,0 +1,25 @@ +--- +id: 8-7 +title: 8-7 Consultation Reminder (2 Hours) +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a client, I want to receive a reminder 2 hours before my consultation, So that I'm prepared and ready for my appointment with final details and contact information. **Arabic Template:** resources/views/emails/reminders/consultation-2h/ar.blade.php **English Template:** resources/views/emails/reminders/consultation-2h/en.blade.php. Full implementation history: docs/stories/story-8.7-consultation-reminder-2h.md + +## Acceptance Criteria + +- [ ] Scheduled artisan command runs every 15 minutes +- [ ] Find consultations approximately 2 hours away (within 7-minute window) +- [ ] Only for approved consultations (`status = 'approved'`) +- [ ] Skip cancelled/no-show/completed consultations +- [ ] Track sent reminders to prevent duplicates via `reminder_2h_sent_at` +- [ ] Subject: "Your consultation is in 2 hours" / "استشارتك بعد ساعتين" +- [ ] Consultation date and time (formatted per locale) +- [ ] Final payment reminder: Show if `consultation_type = 'paid'` AND `payment_status != 'received'` +- [ ] Office contact information for last-minute issues/questions +- [ ] Email rendered in client's `preferred_language` (ar/en) +- [ ] Date/time formatted according to locale diff --git a/docs/tasks/8-8.md b/docs/tasks/8-8.md new file mode 100644 index 0000000..d822302 --- /dev/null +++ b/docs/tasks/8-8.md @@ -0,0 +1,29 @@ +--- +id: 8-8 +title: 8-8 Timeline Update Notification +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As a client, I want to be notified via email when my case timeline is updated, So that I stay informed about my case progress without having to repeatedly check the portal. Full implementation history: docs/stories/story-8.8-timeline-update-notification.md + +## Acceptance Criteria + +- [ ] Email sent automatically when `TimelineUpdate` is created +- [ ] Uses model observer pattern for clean separation +- [ ] Email queued for performance (not sent synchronously) +- [ ] Only triggered for active timelines (not archived) +- [ ] Subject: "Update on your case: [Case Name]" / "تحديث على قضيتك: [اسم القضية]" +- [ ] Case reference number (if exists) +- [ ] Full update content text +- [ ] Date of update (formatted for locale) +- [ ] "View Timeline" button linking to client dashboard timeline view +- [ ] Email template selected based on client's `preferred_language` +- [ ] Default to Arabic ('ar') if no preference set +- [ ] Date formatting appropriate for locale +- [ ] Uses base email template from Story 8.1 (Libra branding) +- [ ] Professional, informative tone +- [ ] Clear visual hierarchy: case name → update content → action button diff --git a/docs/tasks/8-9.md b/docs/tasks/8-9.md new file mode 100644 index 0000000..ef0ef6c --- /dev/null +++ b/docs/tasks/8-9.md @@ -0,0 +1,30 @@ +--- +id: 8-9 +title: 8-9 Admin Notification - New Booking +status: QA Review +date: 2026-09-27 +parent: 8 +--- + +## Description + +As an admin, I want to be notified when a client submits a booking request, So that I can review and respond promptly. Using Mailable pattern to align with sibling stories (8.2-8.8):. Full implementation history: docs/stories/story-8.9-admin-notification-new-booking.md + +## Acceptance Criteria + +- [ ] Sent immediately after successful consultation creation (same trigger as Story 8.3) +- [ ] Consultation status: pending +- [ ] Email queued for async delivery +- [ ] First user with `user_type = 'admin'` in the database +- [ ] If no admin exists, log error but don't fail the booking process +- [ ] Subject line: "[Action Required] New Consultation Request" / "[إجراء مطلوب] طلب استشارة جديد" +- [ ] "New Consultation Request" heading +- [ ] Client name: +- [ ] Requested date and time (formatted per admin's language preference) +- [ ] Problem summary (full text, no truncation) +- [ ] Client contact information: +- [ ] "Review Request" button linking to consultation detail in admin dashboard +- [ ] "[Action Required]" prefix in subject line (English) +- [ ] "[إجراء مطلوب]" prefix in subject line (Arabic) +- [ ] Email sent in admin's `preferred_language` +- [ ] Default to 'en' (English) if admin has no preference set (admin-facing communications default to English) diff --git a/docs/tasks/8.md b/docs/tasks/8.md new file mode 100644 index 0000000..4b08832 --- /dev/null +++ b/docs/tasks/8.md @@ -0,0 +1,20 @@ +--- +id: 8 +title: 8 Email Notification System +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Professional, bilingual, queued email notifications covering every platform event: welcome/account emails, booking submitted/approved/rejected, 24h and 2h consultation reminders, timeline update notifications, and admin alerts for new bookings and system events, sent from no-reply@libra.ps. + +## Acceptance Criteria + +- [ ] Professional email templates with branding +- [ ] Bilingual emails (based on recipient preference) +- [ ] All 9+ notification types implemented +- [ ] Calendar file attachments +- [ ] Queued delivery for performance +- [ ] Plain text fallback +- [ ] Consistent branding across all emails diff --git a/docs/tasks/9-1.md b/docs/tasks/9-1.md new file mode 100644 index 0000000..ec930bf --- /dev/null +++ b/docs/tasks/9-1.md @@ -0,0 +1,27 @@ +--- +id: 9-1 +title: 9-1 Color System Implementation +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a developer, I want to implement the complete color palette as Tailwind CSS theme, So that brand colors are consistently applied throughout the application. The file resources/css/app.css already exists with: - Tailwind and Flux CSS imports (PRESERVE these) - Zinc color palette (can be REMOVED - not used in brand) - Accent color variables using neutral-800 (REPLACE with brand colors) - Flux field/label/control selectors (PRESERVE these). Full implementation history: docs/stories/story-9.1-color-system-implementation.md + +## Acceptance Criteria + +- [ ] Dark Navy Blue: #0A1F44 (backgrounds, headers) +- [ ] Gold/Brass: #D4AF37 (accents, buttons, links) +- [ ] Light Gold: #F4E4B8 (hover states) +- [ ] Off-White/Cream: #F9F7F4 (text, cards) +- [ ] Charcoal Gray: #2C3E50 (secondary text) +- [ ] Success Green: #27AE60 (approved status) +- [ ] Warning Red: #E74C3C (rejected, errors) +- [ ] Pending Yellow: #F39C12 (pending status) +- [ ] Custom Tailwind colors configured via @theme +- [ ] Color variables for easy maintenance +- [ ] Semantic color aliases (primary, accent, etc.) +- [ ] Dark mode is **deferred** to a future story +- [ ] Document that dark mode will require additional color mappings later diff --git a/docs/tasks/9-10.md b/docs/tasks/9-10.md new file mode 100644 index 0000000..2213d58 --- /dev/null +++ b/docs/tasks/9-10.md @@ -0,0 +1,30 @@ +--- +id: 9-10 +title: 9-10 Accessibility Compliance +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user with disabilities, I want the platform to be accessible, So that I can use it regardless of my abilities. Full implementation history: docs/stories/story-9.10-accessibility-compliance.md + +## Acceptance Criteria + +- [ ] Body text: 4.5:1 minimum contrast ratio +- [ ] Large text (18px+ bold or 24px+ regular): 3:1 minimum +- [ ] UI elements (buttons, form borders, icons): 3:1 minimum +- [ ] Verify gold (#D4AF37) on navy (#0A1F44) meets requirements +- [ ] Verify text colors on cream (#F9F7F4) backgrounds +- [ ] Visible focus outline (gold) +- [ ] Not just color change +- [ ] All interactive elements reachable +- [ ] Logical tab order +- [ ] Skip to main content link +- [ ] Proper heading hierarchy (h1 > h2 > h3) +- [ ] Alt text for images +- [ ] ARIA labels where needed +- [ ] Form labels associated +- [ ] Respect prefers-reduced-motion +- [ ] No auto-playing animations diff --git a/docs/tasks/9-11.md b/docs/tasks/9-11.md new file mode 100644 index 0000000..45fece3 --- /dev/null +++ b/docs/tasks/9-11.md @@ -0,0 +1,30 @@ +--- +id: 9-11 +title: 9-11 Animations & Micro-interactions +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want subtle, professional animations, So that the interface feels polished and responsive. Full implementation history: docs/stories/story-9.11-animations-micro-interactions.md + +## Acceptance Criteria + +- [ ] Button hover: 150ms ease +- [ ] Card hover: 200ms ease +- [ ] Modal open/close: 200ms +- [ ] Page transitions (optional) +- [ ] Skeleton loaders for content +- [ ] Spinner for actions +- [ ] Progress indicators +- [ ] Success checkmark +- [ ] Error shake +- [ ] Toast slide-in +- [ ] Links: Color transition +- [ ] Cards: Lift effect +- [ ] Buttons: Background transition +- [ ] All animations subtle, professional +- [ ] Under 300ms duration +- [ ] Respect prefers-reduced-motion diff --git a/docs/tasks/9-2.md b/docs/tasks/9-2.md new file mode 100644 index 0000000..d49f349 --- /dev/null +++ b/docs/tasks/9-2.md @@ -0,0 +1,26 @@ +--- +id: 9-2 +title: 9-2 Typography System +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want professional, readable typography, So that the platform feels polished and content is easy to read. **Target File:** resources/css/app.css. Full implementation history: docs/stories/story-9.2-typography-system.md + +## Acceptance Criteria + +- [ ] Primary: Cairo or Tajawal (Google Fonts) +- [ ] Weights: Light (300), Regular (400), SemiBold (600), Bold (700) +- [ ] Primary: Montserrat or Lato +- [ ] Weights: Light (300), Regular (400), SemiBold (600), Bold (700) +- [ ] H1: Bold, 2.5rem (40px) +- [ ] H2: SemiBold, 2rem (32px) +- [ ] H3: SemiBold, 1.5rem (24px) +- [ ] Body: Regular, 1rem (16px) +- [ ] Small: Regular, 0.875rem (14px) +- [ ] Line height: 1.6 body, 1.3 headings +- [ ] font-display: swap +- [ ] Preload critical fonts diff --git a/docs/tasks/9-3.md b/docs/tasks/9-3.md new file mode 100644 index 0000000..441cf0f --- /dev/null +++ b/docs/tasks/9-3.md @@ -0,0 +1,27 @@ +--- +id: 9-3 +title: 9-3 Logo Integration +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a visitor, I want to see the Libra scales logo prominently displayed, So that I recognize the firm's branding. An app-logo.blade.php component already exists at resources/views/components/app-logo.blade.php. This story will **replace** it with a more robust implementation supporting variants and sizes. Full implementation history: docs/stories/story-9.3-logo-integration.md + +## Acceptance Criteria + +- [ ] Navigation: Top left (desktop), centered (mobile) +- [ ] Footer: Smaller version (integrated when footer created in Story 9.7) +- [ ] Email templates: Header (integrated when email templates created in Epic 8) +- [ ] PDF exports: Header (integrated when PDF exports created) +- [ ] Minimum size: 120px width (desktop), 80px width (mobile) +- [ ] Clear space: 20px padding minimum around logo +- [ ] SVG primary (scalable, preferred) +- [ ] PNG fallback (for email clients that don't support SVG) +- [ ] **Full color:** Gold (#D4AF37) logo on Navy (#0A1F44) background +- [ ] **Reversed:** Navy (#0A1F44) logo on light/cream (#F9F7F4) background +- [ ] **Monochrome:** Single-color gold (#D4AF37) version +- [ ] Responsive sizing based on viewport +- [ ] Accessible alt text: "Libra Law Firm" (translatable) diff --git a/docs/tasks/9-4.md b/docs/tasks/9-4.md new file mode 100644 index 0000000..37d2fa0 --- /dev/null +++ b/docs/tasks/9-4.md @@ -0,0 +1,38 @@ +--- +id: 9-4 +title: 9-4 Component Styling - Buttons +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want consistent, professional button styling, So that interactive elements are clear and visually appealing. Flux UI buttons accept a variant prop. We extend Flux by: 1. Using Flux's component as-is for structure 2. Applying brand colors via the variant prop or custom CSS classes 3. NOT creating wrapper components unless absolutely necessary. Full implementation history: docs/stories/story-9.4-component-styling-buttons.md + +## Acceptance Criteria + +- [ ] Background: Gold (`bg-gold` / #D4AF37) +- [ ] Text: Dark Navy Blue (`text-navy`) +- [ ] Hover: Light Gold (`hover:bg-gold-light` / #F4E4B8) +- [ ] Border-radius: 6px (`rounded-md`) +- [ ] Padding: 12px 24px (`px-6 py-3`) +- [ ] Background: Transparent +- [ ] Border: 2px solid Gold (`border-2 border-gold`) +- [ ] Text: Gold (`text-gold`) +- [ ] Hover: Gold background, Navy text (`hover:bg-gold hover:text-navy`) +- [ ] Background: #CCCCCC +- [ ] Text: #666666 +- [ ] No hover effect +- [ ] Cursor: not-allowed +- [ ] Background: #E74C3C (`bg-danger`) +- [ ] Text: White +- [ ] Hover: Slightly darker (`hover:bg-danger/90`) +- [ ] Small: `px-4 py-2 text-sm` (for compact UI areas) +- [ ] Default: `px-6 py-3 text-base` (standard usage) +- [ ] Large: `px-8 py-4 text-lg` (hero CTAs) +- [ ] Loading states with Flux spinner component +- [ ] Focus states: Gold outline ring for accessibility (`focus:ring-2 focus:ring-gold focus:ring-offset-2`) +- [ ] Icon support: Buttons with leading/trailing icons +- [ ] Full-width variant for mobile forms +- [ ] Button groups with proper border-radius handling diff --git a/docs/tasks/9-5.md b/docs/tasks/9-5.md new file mode 100644 index 0000000..2ded99c --- /dev/null +++ b/docs/tasks/9-5.md @@ -0,0 +1,33 @@ +--- +id: 9-5 +title: 9-5 Component Styling - Forms +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want consistent, accessible form styling, So that data entry is intuitive and error states are clear. Full implementation history: docs/stories/story-9.5-component-styling-forms.md + +## Acceptance Criteria + +- [ ] Border: Charcoal Gray (`border-charcoal/30`) +- [ ] Focus: Gold border with subtle ring (`focus:border-gold focus:ring-gold/20`) +- [ ] Border-radius: 6px (`rounded-md`) +- [ ] Padding: 12px 16px (`px-4 py-3`) +- [ ] Same styling as inputs +- [ ] Minimum height: 120px (`min-h-[120px]`) +- [ ] Custom styled using Flux UI (not native browser) +- [ ] Consistent border/focus styling with inputs +- [ ] Custom styled with gold accent when checked +- [ ] Clear visual distinction between checked/unchecked states +- [ ] SemiBold weight (`font-semibold`) +- [ ] Required indicator (*) in danger color +- [ ] Red border (`border-danger`) +- [ ] Error message displayed below field +- [ ] Error ring on focus (`focus:ring-danger/20`) +- [ ] Labels align to the right in RTL mode +- [ ] Input text direction follows locale +- [ ] Error messages align correctly +- [ ] Padding swaps appropriately (use `ps-4 pe-4` instead of `px-4` if needed) diff --git a/docs/tasks/9-6.md b/docs/tasks/9-6.md new file mode 100644 index 0000000..c4e8d4d --- /dev/null +++ b/docs/tasks/9-6.md @@ -0,0 +1,28 @@ +--- +id: 9-6 +title: 9-6 Component Styling - Cards & Containers +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want consistent card and container styling, So that content is well-organized and visually appealing. | Class | Color | Hex | |-------|-------|-----| | bg-cream | Off-white/Cream | #F9F7F4 | | text-gold / border-gold | Gold | #D4AF37 | | bg-gold/10 | Gold at 10% opacity | - | | text-navy | Dark Navy Blue | #0A1F44 | | text-charcoal | Charcoal Gray | #2C3E50 | | text-success | Success Green | #27AE60 | | text-danger | Warning Red | #E74C3C |. Full implementation history: docs/stories/story-9.6-component-styling-cards-containers.md + +## Acceptance Criteria + +- [ ] Background: Off-white/cream +- [ ] Box-shadow: 0 2px 8px rgba(0,0,0,0.1) +- [ ] Border-radius: 8px +- [ ] Padding: 24px +- [ ] Optional gold top/left border +- [ ] For featured/important cards +- [ ] Subtle lift effect +- [ ] Shadow increase +- [ ] Icon with gold accent +- [ ] Large number display +- [ ] Trend indicator +- [ ] Consistent item spacing +- [ ] Clear click targets +- [ ] Max-width: 1200px, centered diff --git a/docs/tasks/9-7.md b/docs/tasks/9-7.md new file mode 100644 index 0000000..c5b0daf --- /dev/null +++ b/docs/tasks/9-7.md @@ -0,0 +1,36 @@ +--- +id: 9-7 +title: 9-7 Navigation & Footer Styling +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want professional navigation and footer styling, So that I can easily navigate the site and find information. Full implementation history: docs/stories/story-9.7-navigation-footer-styling.md + +## Acceptance Criteria + +- [ ] Fixed top position with `z-50` +- [ ] Navy blue background (`bg-navy`) +- [ ] Logo left (desktop), centered (mobile) +- [ ] Gold text for links (`text-gold`) +- [ ] Active link indicator (gold underline or background) +- [ ] Language toggle styled consistently +- [ ] Responsive mobile menu +- [ ] Full-width dropdown/slide from left +- [ ] Navy background (`bg-navy`) +- [ ] Clear touch targets (44px+ minimum) +- [ ] Smooth animation (200-300ms) +- [ ] Close button visible +- [ ] Navy blue background (`bg-navy`) +- [ ] Logo and firm info (using ``) +- [ ] Contact details section +- [ ] Links to Terms/Privacy pages +- [ ] Copyright notice with dynamic year +- [ ] Sticky footer (always at bottom even on short pages) +- [ ] Guest navigation: Show Home, Posts, Contact, Login/Register +- [ ] Authenticated navigation: Show Home, Dashboard, Posts, user menu +- [ ] RTL layout: Logo moves to right, menu items reverse order +- [ ] Empty page content: Footer stays at viewport bottom diff --git a/docs/tasks/9-8.md b/docs/tasks/9-8.md new file mode 100644 index 0000000..dc943e5 --- /dev/null +++ b/docs/tasks/9-8.md @@ -0,0 +1,31 @@ +--- +id: 9-8 +title: 9-8 RTL/LTR Layout Perfection +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want perfect RTL layout for Arabic and LTR for English, So that the content is natural to read in my language. Full implementation history: docs/stories/story-9.8-rtl-ltr-layout-perfection.md + +## Acceptance Criteria + +- [ ] `dir="rtl"` dynamically set on `` when locale is `ar` +- [ ] Text aligns right naturally +- [ ] Navigation mirrors (sidebar on right for RTL) +- [ ] Form labels on right side of inputs +- [ ] Icons/arrows flip appropriately (chevrons, arrows) +- [ ] Margins/paddings swap using logical properties +- [ ] `dir="ltr"` set on `` when locale is `en` +- [ ] Standard left-to-right layout +- [ ] Proper text alignment +- [ ] Seamless language toggle without page reload issues +- [ ] No layout breaks on switch +- [ ] No flash of wrong direction on page load +- [ ] Calendar component RTL support (date picker) +- [ ] Tables RTL support (horizontal scroll direction) +- [ ] Dropdowns open in correct direction +- [ ] Modals position correctly +- [ ] All Flux UI components tested in both modes diff --git a/docs/tasks/9-9.md b/docs/tasks/9-9.md new file mode 100644 index 0000000..944c20f --- /dev/null +++ b/docs/tasks/9-9.md @@ -0,0 +1,43 @@ +--- +id: 9-9 +title: 9-9 Responsive Design Implementation +status: QA Review +date: 2026-09-27 +parent: 9 +--- + +## Description + +As a user, I want the platform to work perfectly on all device sizes, So that I can use it on my phone, tablet, or desktop. - **Tailwind CSS 4:** Using CSS-first configuration with @theme directive - **Flux UI Free:** Leverage built-in responsive behavior for available components - **Alpine.js:** For mobile menu toggles and collapsible sections (included with Livewire). Full implementation history: docs/stories/story-9.9-responsive-design-implementation.md + +## Acceptance Criteria + +- [ ] Mobile: < 576px (single column, stacked layouts) +- [ ] Tablet: 576px - 991px (two columns where appropriate) +- [ ] Desktop: 992px - 1199px (full layouts with sidebars) +- [ ] Large Desktop: >= 1200px (max-width container: 1200px) +- [ ] Touch-friendly targets minimum 44px height/width for all interactive elements +- [ ] Font sizes remain readable (minimum 16px for body text to prevent iOS zoom) +- [ ] Single column layouts for all content sections +- [ ] Collapsible/accordion sections for long content +- [ ] Navigation collapses to hamburger menu +- [ ] Forms stack labels above inputs +- [ ] Cards display full-width +- [ ] Two-column grid layouts where appropriate (dashboard stats, post listings) +- [ ] Sidebar collapsible via toggle (not permanently visible) +- [ ] Tables may show reduced columns or scroll horizontally +- [ ] Calendar shows week view or scrollable month +- [ ] Full layouts with persistent sidebars +- [ ] Multi-column grids (3-4 columns for dashboard stats) +- [ ] Tables show all columns +- [ ] Calendar shows full month view +- [ ] Max container width: 1200px centered +- [ ] **Forms:** All forms (booking, login, user management) fully usable on mobile with proper input sizing +- [ ] **Calendar:** Booking calendar functional on mobile (touch-friendly date selection, scrollable) +- [ ] **Tables:** All data tables have horizontal scroll wrapper, pinned first column if needed +- [ ] **No horizontal scroll:** Page-level horizontal scroll must never occur on any viewport +- [ ] **Modals:** Modal dialogs responsive (full-screen on mobile, centered on desktop) +- [ ] **Charts:** Dashboard charts resize appropriately or stack on mobile +- [ ] All responsive layouts tested in both LTR (English) and RTL (Arabic) +- [ ] Sidebar collapses from correct side (start-0 not left-0) +- [ ] Horizontal scroll direction correct for RTL diff --git a/docs/tasks/9.md b/docs/tasks/9.md new file mode 100644 index 0000000..2fc0959 --- /dev/null +++ b/docs/tasks/9.md @@ -0,0 +1,21 @@ +--- +id: 9 +title: 9 Design & Branding Implementation +status: Ready for Dev +date: 2026-09-27 +--- + +## Description + +Implements the full visual design system in its original (Navy+Gold, later superseded) form: color system, typography, logo integration, component styling for buttons/forms/cards/navigation, RTL/LTR layout correctness, responsive design, WCAG AA accessibility, and animations/micro-interactions. + +## Acceptance Criteria + +- [ ] Brand colors consistently applied +- [ ] Logo properly integrated throughout +- [ ] Typography hierarchy implemented +- [ ] RTL/LTR layouts perfect +- [ ] Responsive on all breakpoints +- [ ] WCAG AA contrast compliance +- [ ] Professional, polished finish +- [ ] Smooth animations and transitions diff --git a/docs/tasks/statuses.md b/docs/tasks/statuses.md new file mode 100644 index 0000000..ef5190a --- /dev/null +++ b/docs/tasks/statuses.md @@ -0,0 +1,123 @@ +# Task Statuses: Libra +**Last synced:** 2026-09-27 + +| ID | Title | Status | +|----|-------|--------| +| 1 | 1 Core Foundation & Infrastructure | Ready for Dev | +| 1-1 | 1-1 Project Setup & Database Schema | Done | +| 1-2 | 1-2 Authentication & Role System | Done | +| 1-3 | 1-3 Bilingual Infrastructure (Arabic/English) | QA Review | +| 1-4 | 1-4 Base UI & Navigation | Done | +| 2 | 2 User Management System | Ready for Dev | +| 2-1 | 2-1 Individual Client Account Management | Done | +| 2-2 | 2-2 Company/Corporate Client Account Management | QA Review | +| 2-3 | 2-3 Account Type Conversion | QA Review | +| 2-4 | 2-4 Account Lifecycle Management | QA Review | +| 2-5 | 2-5 Account Creation Email Notification | QA Review | +| 3 | 3 Booking & Consultation System | Ready for Dev | +| 3-1 | 3-1 Working Hours Configuration | Done | +| 3-2 | 3-2 Time Slot Blocking | QA Review | +| 3-3 | 3-3 Availability Calendar Display | QA Review | +| 3-4 | 3-4 Booking Request Submission | QA Review | +| 3-5 | 3-5 Admin Booking Review & Approval | QA Review | +| 3-6 | 3-6 Calendar File Generation (.ics) | QA Review | +| 3-7 | 3-7 Consultation Management | QA Review | +| 3-8 | 3-8 Consultation Reminders | QA Review | +| 3-9 | 3-9 Guest Booking Request | Draft | +| 4 | 4 Case Timeline System | Ready for Dev | +| 4-1 | 4-1 Timeline Creation | QA Review | +| 4-2 | 4-2 Timeline Updates Management | QA Review | +| 4-3 | 4-3 Timeline Archiving | QA Review | +| 4-4 | 4-4 Admin Timeline Dashboard | QA Review | +| 4-5 | 4-5 Client Timeline View | QA Review | +| 4-6 | 4-6 Timeline Update Notifications | QA Review | +| 5 | 5 Posts/Blog System | Ready for Dev | +| 5-1 | 5-1 Post Creation & Editing | QA Review | +| 5-2 | 5-2 Post Management Dashboard | QA Review | +| 5-3 | 5-3 Post Deletion | QA Review | +| 5-4 | 5-4 Public Posts Display | QA Review | +| 5-5 | 5-5 Post Search | QA Review | +| 6 | 6 Admin Dashboard | Ready for Dev | +| 6-1 | 6-1 Dashboard Overview & Statistics | QA Review | +| 6-2 | 6-2 Analytics Charts | QA Review | +| 6-3 | 6-3 Quick Actions Panel | QA Review | +| 6-4 | 6-4 Data Export - User Lists | QA Review | +| 6-5 | 6-5 Data Export - Consultation Records | QA Review | +| 6-6 | 6-6 Data Export - Timeline Reports | QA Review | +| 6-7 | 6-7 Monthly Statistics Report | QA Review | +| 6-8 | 6-8 System Settings | QA Review | +| 6-9 | 6-9 Legal Pages Editor | QA Review | +| 6-10 | 6-10 Audit Log Viewer | QA Review | +| 7 | 7 Client Dashboard | Ready for Dev | +| 7-1 | 7-1 Client Dashboard Overview | QA Review | +| 7-2 | 7-2 My Consultations View | QA Review | +| 7-3 | 7-3 My Cases/Timelines View (Dashboard Integration) | QA Review | +| 7-4 | 7-4 My Profile View | QA Review | +| 7-5 | 7-5 New Booking Interface | QA Review | +| 7-6 | 7-6 Booking Limit Indicator | QA Review | +| 8 | 8 Email Notification System | Ready for Dev | +| 8-1 | 8-1 Email Infrastructure Setup | QA Review | +| 8-2 | 8-2 Welcome Email (Account Created) | QA Review | +| 8-3 | 8-3 Booking Submitted Confirmation | QA Review | +| 8-4 | 8-4 Booking Approved Email | QA Review | +| 8-5 | 8-5 Booking Rejected Email | QA Review | +| 8-6 | 8-6 Consultation Reminder (24 Hours) | QA Review | +| 8-7 | 8-7 Consultation Reminder (2 Hours) | QA Review | +| 8-8 | 8-8 Timeline Update Notification | QA Review | +| 8-9 | 8-9 Admin Notification - New Booking | QA Review | +| 8-10 | 8-10 Admin Notification - System Events | QA Review | +| 9 | 9 Design & Branding Implementation | Ready for Dev | +| 9-1 | 9-1 Color System Implementation | QA Review | +| 9-2 | 9-2 Typography System | QA Review | +| 9-3 | 9-3 Logo Integration | QA Review | +| 9-4 | 9-4 Component Styling - Buttons | QA Review | +| 9-5 | 9-5 Component Styling - Forms | QA Review | +| 9-6 | 9-6 Component Styling - Cards & Containers | QA Review | +| 9-7 | 9-7 Navigation & Footer Styling | QA Review | +| 9-8 | 9-8 RTL/LTR Layout Perfection | QA Review | +| 9-9 | 9-9 Responsive Design Implementation | QA Review | +| 9-10 | 9-10 Accessibility Compliance | QA Review | +| 9-11 | 9-11 Animations & Micro-interactions | QA Review | +| 10 | 10 Brand Color Refresh | Ready for Dev | +| 10-1 | 10-1 Core CSS Theme Update | QA Review | +| 10-2 | 10-2 Blade Component Color Migration | QA Review | +| 10-3 | 10-3 Email Template Color Update | QA Review | +| 10-4 | 10-4 PDF Template Color Update | QA Review | +| 10-5 | 10-5 Logo and SVG Assets Update | QA Review | +| 10-6 | 10-6 Documentation Update | QA Review | +| 11 | 11 Guest Booking | Ready for Dev | +| 11-1 | 11-1 Database Schema & Model Updates | QA Review | +| 11-2 | 11-2 Public Booking Form with Custom Captcha | QA Review | +| 11-3 | 11-3 Guest Email Notifications & Admin Integration | QA Review | +| 11-4 | 11-4 Documentation Updates | QA Review | +| 12 | 12 Branding Refresh (Logo + Color Scheme) | Ready for Dev | +| 12-1 | 12-1 Logo Asset Deployment and CSS Layout Updates | QA Review | +| 12-2 | 12-2 Core CSS Theme Update - Dark Charcoal & Warm Gold Palette | QA Review | +| 12-3 | 12-3 Blade Component Color Migration - Dark Charcoal & Warm Gold | QA Review | +| 12-4 | 12-4 Email Template Color Update - Dark Charcoal & Warm Gold | QA Review | +| 12-5 | 12-5 PDF Template Color Update - Dark Charcoal & Warm Gold | QA Review | +| 12-6 | 12-6 Brand Documentation Update - Dark Charcoal & Warm Gold | QA Review | +| 13 | 13 Authentication Pages Design Enhancement | Ready for Dev | +| 13-1 | 13-1 Language Toggle Visibility Enhancement | QA Review | +| 13-2 | 13-2 Auth Layout Split Design Update | QA Review | +| 13-3 | 13-3 Subtle Background Pattern Implementation | QA Review | +| 13-4 | 13-4 Auth Pages Migration to Split Layout | QA Review | +| 13-5 | 13-5 Visual QA and Refinement | Draft | +| 14 | 14 Home Page Redesign | Ready for Dev | +| 14-1 | 14-1 Hero Section Implementation | QA Review | +| 14-2 | 14-2 About Section with Lawyer Profile | QA Review | +| 14-3 | 14-3 Services Section | QA Review | +| 14-4 | 14-4 Values Section | QA Review | +| 14-5 | 14-5 Latest Posts Section | QA Review | +| 14-6 | 14-6 Footer Contact Information Update | QA Review | +| 15 | 15 Potential Clients Management | Ready for Dev | +| 15-1 | 15-1 Database Schema & Model Setup | QA Review | +| 15-2 | 15-2 Potential Clients List with Type Filter | QA Review | +| 15-3 | 15-3 CRUD Operations for Potential Clients | QA Review | +| 16 | 16 About Us Page | Ready for Dev | +| 16-1 | 16-1 About Page Layout & Hero Section | QA Review | +| 16-2 | 16-2 Vision & Mission Section | QA Review | +| 16-3 | 16-3 Values Section | QA Review | +| 16-4 | 16-4 Goals Section | QA Review | +| 16-5 | 16-5 Legal Services Section | QA Review | +| 16-6 | 16-6 Scholarship Aspiration Section | QA Review | diff --git a/docs/ux-design.md b/docs/ux-design.md new file mode 100644 index 0000000..7b53eba --- /dev/null +++ b/docs/ux-design.md @@ -0,0 +1,135 @@ +# UX / Design Reference — Libra Law Firm + +Retrospective documentation of the design system as it is currently **built and live**. This +is not a proposal — it describes what shipped, so a dev/QA agent picking up a new task can match +existing patterns rather than invent new ones. Synthesized from `docs/brand.md`, epics 9/10/12/13/14/16, +and the root `CLAUDE.md`. + +## Brand colors (current — source of truth: `docs/brand.md`) + +The palette has changed twice since the original PRD. **Use the values below**, from `docs/brand.md`, +for any new work — they are the most recent and match what Epic 12 shipped. + +| Token | Hex | Usage | +|---|---|---| +| Primary — Dark Forest Green | `#2D3624` | Header/footer backgrounds | +| CTA — Warm Gold | `#A68966` | Buttons, links, accents | +| Background — Warm Cream | `#F4F1EA` | Main page background | +| Text — Forest Green | `#2D322A` | Headings, body text | +| Card — Pure White | `#FFFFFF` | Card backgrounds | +| Active — Olive Green | `#4A5D23` | Active states, language toggle | +| Primary Light | `#3D4634` | Primary hover state | +| CTA Hover | `#8A7555` | Button hover state | +| CTA Light | `#C4A882` | Light accents | +| Active Hover | `#5A7030` | Active-state hover | +| Deep Black | `#1A1A1A` | Logo artwork, headline emphasis | + +**History (do not use these for new work, they are superseded):** +- Epic 1 / PRD / Epic 9 originally specified **Navy Blue `#0A1F44` + Gold `#D4AF37`**. +- Epic 10 ("Brand Color Refresh") replaced that with **Charcoal `#4A4A42` + Warm Gray `#C9C4BA`**. +- Epic 12 ("Branding Refresh") replaced *that* with the **Dark Forest Green + Warm Gold** palette + above, which is what `docs/brand.md` documents and what is currently live. Epic 9's own stories + (button/form/card specs) still reference the original Navy+Gold hex values — treat those as + structural/pattern guidance only (border-radius, padding, states) and substitute the current + hex values from the table above. + +## Typography + +- **Arabic:** Cairo or Tajawal (Google Fonts), weights Light 300 / Regular 400 / SemiBold 600 / Bold 700. +- **English:** Montserrat or Lato, same weight set. +- `docs/brand.md` additionally suggests a serif (Playfair Display / Libre Baskerville) for the + organization name/headline treatment and an italic serif for taglines, with a sans body + (Source Sans Pro / Open Sans / Inter) — this is brand-identity guidance; the app itself + implements the Cairo/Tajawal + Montserrat/Lato pairing from Epic 9.2. +- **Hierarchy:** H1 Bold 2.5rem/40px · H2 SemiBold 2rem/32px · H3 SemiBold 1.5rem/24px · + Body Regular 1rem/16px · Small Regular 0.875rem/14px. +- Line height: 1.6 body, 1.3 headings. +- `font-display: swap`, critical fonts preloaded, loaded via Google Fonts + Tailwind `font-family` + config with `@font-face` fallbacks. + +## Layout system + +- Container max-width: **1200px**. +- Card padding: 24px; card border-radius: 8px; card shadow `0 2px 8px rgba(0,0,0,0.1)`, with a + subtle lift + shadow increase on hover. +- Button padding 12px 24px, border-radius 6px; input/textarea padding 12px 16px, border-radius 6px, + textarea min-height 120px. +- **Breakpoints:** Mobile `<576px` · Tablet `576–991px` · Desktop `992–1199px` · Large Desktop `>=1200px`. + Mobile-first: single-column + collapsible sections on mobile, two-column/collapsible sidebar on + tablet, full multi-column grid + sidebars on desktop. Touch targets >= 44px. Tables scroll + horizontally on small screens; calendar and forms must remain usable on mobile. +- Transitions are short and subtle: button hover 150ms ease, card hover 200ms ease, modal + open/close 200ms, all under 300ms — and must respect `prefers-reduced-motion` (no auto-playing + animations). + +## Component patterns (Epic 9 stories 9.4–9.7) + +- **Buttons:** primary = CTA-gold background / dark text, hover to CTA-hover; secondary = + transparent with gold border + gold text, hover fills gold with dark text; disabled = flat gray + background/text, no hover, `cursor: not-allowed`; danger = solid red (`#E74C3C`) with white text. + Loading state shows a spinner; all buttons have a visible focus state. Built by extending Flux UI's + button component with Tailwind component classes. +- **Forms:** inputs/textareas/selects share consistent border + radius, gold border on focus; + selects and checkboxes/radios are custom-styled (not native) with gold accents on + checked/selected state; labels are SemiBold with a `*` required indicator; errors show a red + border plus a message rendered directly below the field. Built on Flux UI form components with + explicit RTL alignment handling. +- **Cards/containers:** off-white/cream background, optional gold top/left accent border for + featured or important cards; dashboard stat cards add a gold-accented icon, a large number, and + a trend indicator; list cards use consistent item spacing and clear click targets. Implemented as + a reusable Blade card component with variant props. +- **Navigation/footer:** fixed-top nav, brand-primary background, logo left on desktop / centered + on mobile, gold link text with an active-link indicator, styled language toggle, and a full-width + slide/dropdown mobile menu (Alpine.js) with 44px+ touch targets. Footer shares the brand-primary + background and carries logo + firm info, contact details, Terms/Privacy links, and copyright; it + stays pinned to the bottom of short pages (sticky footer). + +## Bilingual / RTL–LTR rules + +- Arabic is primary and renders RTL; English is secondary, LTR. `dir="rtl"` is set on `` for + Arabic; layout uses Tailwind's RTL support and logical properties (`start`/`end` rather than + `left`/`right`) so components flip automatically rather than needing per-direction overrides. +- In RTL: text aligns right, navigation mirrors (logo moves to the right), form labels sit on the + right, directional icons/arrows flip, and margins/paddings swap sides. +- Switching language must not break layout — calendars and tables must render correctly in both + directions, and every component is expected to be tested in both. +- All user-facing strings live in language files (`ar`/`en`); there is no hardcoded UI copy. + +## Key page layouts + +- **Home** (Epic 14): Navigation → Hero (tagline + intro + CTA buttons, Warm Cream background) → + About (Huda Armouche's photo + bio) → Services (4 cards: Consultations, Representation, + Litigation, Contracts) → Values (6 icon cards) → Latest Posts (3 most recent published posts, + pulled live via `Post::where('status','published')->latest()->take(3)->get()`, with a "View All" + link) → Footer (phone + address + links). Sections alternate between Warm Cream and White + backgrounds; CTAs use Warm Gold. +- **About Us** (Epic 16, new page at `/about`): Navigation → Hero (title + identity statement) → + Vision & Mission (three-fold: For Itself / For Society / For Diaspora, card layout) → Values + (6 core values: Integrity, Justice, Knowledge, Women's Empowerment, Professionalism, Social + Innovation) → Goals (7 goals, numbered/scannable) → Legal Services (grouped by category: + consultations, litigation, family law, business services) → Scholarship Aspiration section + (Libra Scholarship for Law and Palestinian Arts) → Footer. +- **Auth pages** (Epic 13 — login, forgot/reset password, 2FA challenge, confirm-password, email + verify): split-screen layout. Left panel: Dark Forest Green (`#2D3624`) background with the + LIBRA logo centered. Right panel: Warm Cream background with a subtle SVG botanical/geometric + background pattern (low-opacity brand colors) behind the form. On mobile, only the form side + shows, with the logo displayed above it. The language toggle's `light` variant was darkened + (`text-primary` instead of `text-body/70`) specifically for visibility on this light panel, + without changing its appearance on the dark public-nav background. +- **Dashboards** (Epics 6 admin / 7 client): standard authenticated-app shell — nav/sidebar + + content area using the same card, button, and table components as the rest of the app. Admin + dashboard emphasizes stat cards, Chart.js analytics, and data tables with export actions; client + dashboard is read-mostly (consultations, timelines, profile) with a single primary action + (submit new booking) and a booking-limit indicator. + +## Accessibility (WCAG AA — Epic 9.10) + +- Color contrast: body text >= 4.5:1, large text (18px+ bold or 24px+ regular) >= 3:1, UI elements + (buttons, borders, icons) >= 3:1. The gold-on-dark-forest-green and text-on-cream combinations + must be verified against these ratios whenever a color changes. +- Focus indicators must be visible (a gold outline), never conveyed by color change alone. +- Full keyboard navigation: every interactive element reachable, logical tab order, a skip-to-main-content + link. +- Screen readers: correct heading hierarchy (h1 > h2 > h3), alt text on all images, ARIA labels + where needed, form labels programmatically associated with their fields. +- Motion: respect `prefers-reduced-motion`; no auto-playing animations.