Generated Epics

This commit is contained in:
Naser Mansour 2025-12-20 20:37:45 +02:00
parent ff83974f4a
commit d889b24f12
10 changed files with 2405 additions and 0 deletions

View File

@ -0,0 +1,153 @@
# Epic 1: Core Foundation & Infrastructure
## Epic Goal
Establish the foundational Laravel application with authentication, bilingual support (Arabic/English), and RTL/LTR layout switching to enable all subsequent feature development.
## Epic Description
### Business Context
Libra Law Firm requires a professional bilingual web platform. This epic lays the groundwork by setting up the Laravel 12 application with proper authentication, role-based access (Admin/Client), and full Arabic/English language support with RTL layout.
### Technical Context
- **Framework:** Laravel 12 with PHP 8.4
- **Frontend:** Livewire 3, Volt, Flux UI Free, Tailwind CSS 4
- **Database:** SQLite (dev), MariaDB (production)
- **Auth:** Laravel Fortify
### Success 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
---
## Stories
### Story 1.1: Project Setup & Database Schema
**Description:** Initialize Laravel 12 project with all required packages and design the complete database schema.
**Acceptance Criteria:**
- [ ] Laravel 12 project created with Livewire 3, Volt, Flux UI
- [ ] Tailwind CSS 4 configured
- [ ] Database migrations for all core tables:
- users (with user_type, national_id, company fields)
- consultations
- timelines
- timeline_updates
- posts
- working_hours
- blocked_times
- notifications
- admin_logs
- [ ] Model factories created for testing
- [ ] Development environment working (`composer run dev`)
**Technical Notes:**
- Use SQLite for development
- Follow existing Volt class-based component pattern
- Reference PRD Section 16.1 for schema details
---
### Story 1.2: Authentication & Role System
**Description:** Implement Fortify authentication with Admin/Client roles. No self-registration - admin creates all accounts.
**Acceptance Criteria:**
- [ ] Fortify configured with custom Volt views
- [ ] Login page with bilingual support
- [ ] Session timeout after 2 hours inactivity
- [ ] Rate limiting on login attempts
- [ ] Admin role with full access
- [ ] Client role with restricted access
- [ ] Gates/Policies for authorization
- [ ] CSRF protection enabled
- [ ] Password hashing (bcrypt)
**Technical Notes:**
- Disable registration feature in Fortify config
- Reference existing `app/Actions/Fortify/` for patterns
- Use `FortifyServiceProvider` for custom views
---
### Story 1.3: Bilingual Infrastructure (Arabic/English)
**Description:** Implement full bilingual support with Arabic as primary language and RTL/LTR layout switching.
**Acceptance Criteria:**
- [ ] Language files for Arabic (ar) and English (en)
- [ ] Language toggle in navigation
- [ ] User language preference stored in database
- [ ] RTL layout for Arabic, LTR for English
- [ ] Date formats: DD/MM/YYYY (Arabic), MM/DD/YYYY (English)
- [ ] 12-hour time format (AM/PM) for both languages
- [ ] Western numerals (123) for both languages
- [ ] All UI elements translatable
- [ ] Arabic fonts (Cairo/Tajawal) configured
- [ ] English fonts (Montserrat/Lato) configured
**Technical Notes:**
- Use Laravel's localization features
- Store preference in users.preferred_language
- Configure Tailwind for RTL support
---
### Story 1.4: Base UI & Navigation
**Description:** Implement the base UI framework with brand colors and responsive navigation system.
**Acceptance Criteria:**
- [ ] Color scheme implemented:
- Primary: Dark Navy Blue (#0A1F44)
- Accent: Gold (#D4AF37)
- Supporting colors per PRD Section 7.1
- [ ] Fixed top navigation bar
- [ ] Language toggle (Arabic/English)
- [ ] Responsive mobile menu
- [ ] Main menu items: Home, Booking, Posts, Login
- [ ] Libra scales logo placement (left desktop, center mobile)
- [ ] Footer with firm information
- [ ] Card-based layouts with proper shadows/radius
- [ ] Flux UI components used where available
- [ ] WCAG AA contrast compliance
**Technical Notes:**
- Reference PRD Section 7 for all design specifications
- Use Flux UI Free components
- Ensure mobile-first responsive design
---
## Dependencies
- None (this is the foundation epic)
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| RTL implementation complexity | Medium | Use established RTL patterns, test early |
| Font loading performance | Low | Use font-display: swap, preload critical fonts |
| Fortify customization | Low | Reference existing Actions in codebase |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Tests passing for authentication and authorization
- [ ] Bilingual switching works seamlessly
- [ ] RTL/LTR layouts render correctly
- [ ] Navigation responsive on all breakpoints
- [ ] Code formatted with Pint
- [ ] No critical accessibility issues

View File

@ -0,0 +1,196 @@
# Epic 2: User Management System
## Epic Goal
Enable the admin to create, manage, and control all user accounts (individual and corporate clients) with full lifecycle management including activation, deactivation, and deletion.
## Epic Description
### Business Context
Libra Law Firm operates with admin-controlled user accounts. Clients cannot self-register - the lawyer creates all accounts manually. The system must support two client types: individual clients and company/corporate clients with different data requirements.
### Technical Context
- **User Types:** Individual, Company/Corporate
- **Account States:** Active, Deactivated, Deleted
- **Password Management:** Admin-only (no client reset)
- **Notifications:** Email on account creation with credentials
### Success 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
---
## Stories
### Story 2.1: Individual Client Account Management
**Description:** Implement CRUD operations for individual client accounts by admin.
**Acceptance Criteria:**
- [ ] Create individual client form with fields:
- Full Name (required)
- National ID Number (required, unique)
- Email Address (required, unique)
- Phone Number (required)
- Password (admin-set, required)
- Preferred Language (Arabic/English)
- [ ] List view of all individual clients
- [ ] Edit client information
- [ ] View client profile with consultation/timeline history
- [ ] Search by name, email, or National ID
- [ ] Filter by status (active/deactivated)
- [ ] Validation for all required fields
- [ ] Duplicate email/ID prevention
**Technical Notes:**
- Store user_type as 'individual' in users table
- Use Volt components for forms
- Implement proper form validation
---
### Story 2.2: Company/Corporate Client Account Management
**Description:** Implement CRUD operations for company client accounts with support for multiple contact persons.
**Acceptance Criteria:**
- [ ] Create company client form with fields:
- Company Name (required)
- Company Registration Number (required, unique)
- Contact Person Name (required)
- Contact Person ID (required)
- Email Address (required, unique)
- Phone Number (required)
- Password (admin-set, required)
- Preferred Language (Arabic/English)
- [ ] Support unlimited contact persons per company
- [ ] List view of all company clients
- [ ] Edit company and contact person information
- [ ] View company profile with consultation/timeline history
- [ ] Search by company name, email, or registration number
- [ ] Filter by status (active/deactivated)
**Technical Notes:**
- Store user_type as 'company' in users table
- Consider separate contact_persons table for multiple contacts
- Company fields nullable for individual accounts
---
### Story 2.3: Account Type Conversion
**Description:** Allow admin to convert individual accounts to company accounts and vice versa.
**Acceptance Criteria:**
- [ ] Convert individual to company account
- Prompt for additional company fields
- Preserve existing data (name, email, phone)
- Preserve consultation and timeline history
- [ ] Convert company to individual account
- Prompt for individual-specific fields
- Handle company-specific data appropriately
- Preserve consultation and timeline history
- [ ] Confirmation dialog before conversion
- [ ] Audit log entry for conversion
- [ ] Email notification to user about account type change
**Technical Notes:**
- Implement as dedicated admin action
- Ensure all relationships preserved during conversion
- Log old and new values in admin_logs
---
### Story 2.4: Account Lifecycle Management
**Description:** Implement account deactivation, reactivation, and permanent deletion with proper data handling.
**Acceptance Criteria:**
- [ ] **Deactivate Account:**
- User cannot login
- All data retained (consultations, timelines)
- Account marked as deactivated
- Can be reactivated by admin
- Visual indicator in user list
- [ ] **Reactivate Account:**
- Restore login ability
- All data intact
- Email notification to user
- [ ] **Delete Account:**
- Confirmation dialog with warning
- Permanently removes user
- Cascades to: consultations, timelines, notifications
- Cannot be recovered
- Audit log entry preserved
- [ ] Admin can reset client password
- Generate new password or set manually
- Email new credentials to client
- [ ] All actions logged in admin_logs table
**Technical Notes:**
- Use soft deletes for deactivation (status field)
- Hard delete for permanent deletion with cascade
- Password reset sends new credentials via email
---
### Story 2.5: Account Creation Email Notification
**Description:** Send welcome email with login credentials when admin creates a new account.
**Acceptance Criteria:**
- [ ] Welcome email sent automatically on account creation
- [ ] Email includes:
- Personalized greeting (name/company name)
- Login credentials (email, password)
- Login URL
- Brief platform introduction
- [ ] Email in user's preferred language
- [ ] Sender: no-reply@libra.ps
- [ ] Sender Name: Libra Law Firm / مكتب ليبرا للمحاماة
- [ ] Professional email template with brand colors
- [ ] Plain text fallback
**Technical Notes:**
- Use Laravel Mail with Mailable class
- Reference PRD Section 8 for email requirements
- Depends on Epic 8 for full email infrastructure
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Authentication system, database schema, bilingual support |
| Epic 8 | Email notification system (partial - welcome email) |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Data loss on deletion | High | Require confirmation, clear warning, audit log |
| Account type conversion data loss | Medium | Validate all data preserved before commit |
| Email delivery failures | Medium | Queue emails, implement retry logic |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Tests for all CRUD operations
- [ ] Tests for account lifecycle (deactivate/delete)
- [ ] Tests for account type conversion
- [ ] Bilingual support for all UI elements
- [ ] Audit logging verified
- [ ] Email notifications sending correctly
- [ ] Code formatted with Pint

View File

@ -0,0 +1,256 @@
# Epic 3: Booking & Consultation System
## Epic Goal
Implement a complete consultation booking system with calendar-based availability, admin approval workflow, consultation type assignment (free/paid), and automated reminders.
## Epic Description
### Business Context
Clients book consultations through a calendar interface. Each consultation is 45 minutes with a 15-minute buffer. The admin reviews requests, determines if free or paid, and approves/rejects. Clients are limited to 1 consultation per day. Payment is handled offline.
### Technical Context
- **Duration:** 45 minutes consultation + 15 minutes buffer = 1 hour slot
- **Limit:** Maximum 1 consultation per client per day
- **Types:** Free or Paid (determined by admin)
- **Payment:** Offline only (no gateway)
- **Calendar:** Real-time availability display
### Success 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
---
## Stories
### Story 3.1: Working Hours Configuration
**Description:** Allow admin to configure available working hours for each day of the week.
**Acceptance Criteria:**
- [ ] Set available days (enable/disable each day)
- [ ] Set start and end time for each day
- [ ] Support different hours for different days
- [ ] 15-minute buffer automatically applied between appointments
- [ ] Changes take effect immediately
- [ ] Existing approved bookings not affected by changes
- [ ] Visual preview of weekly schedule
- [ ] 12-hour time format (AM/PM)
**Technical Notes:**
- Store in working_hours table
- Fields: day_of_week, start_time, end_time, is_active
- Consider timezone handling
---
### Story 3.2: Time Slot Blocking
**Description:** Allow admin to block specific dates/times for personal events or holidays.
**Acceptance Criteria:**
- [ ] Block entire days
- [ ] Block specific time ranges within a day
- [ ] Add reason/note for blocked time
- [ ] View list of all blocked times
- [ ] Edit/delete blocked times
- [ ] Blocked times show as unavailable in calendar
- [ ] Prevent booking on blocked times
- [ ] Future blocked times don't affect existing bookings
**Technical Notes:**
- Store in blocked_times table
- Fields: block_date, start_time, end_time, reason
- Query both working_hours and blocked_times for availability
---
### Story 3.3: Availability Calendar Display
**Description:** Display real-time calendar with available time slots for booking.
**Acceptance Criteria:**
- [ ] Calendar view showing available dates
- [ ] Time slots based on working hours configuration
- [ ] Unavailable slots clearly indicated:
- Already booked (by other clients)
- Outside working hours
- Blocked by admin
- [ ] 1-hour slots (45min + 15min buffer)
- [ ] Visual distinction between available/unavailable
- [ ] Responsive design (mobile-friendly)
- [ ] Language-appropriate date formatting
- [ ] Prevent double-booking
**Technical Notes:**
- Consider FullCalendar.js or similar
- Real-time availability check on slot selection
- Account for 15-minute buffer between appointments
---
### Story 3.4: Booking Request Submission
**Description:** Allow logged-in clients to submit consultation booking requests.
**Acceptance Criteria:**
- [ ] Client must be logged in
- [ ] Select date from calendar
- [ ] Select available time slot
- [ ] Provide detailed problem summary (required, textarea)
- [ ] System validates: no more than 1 booking per day for this client
- [ ] Confirmation before submission
- [ ] Booking enters "pending" status
- [ ] Admin receives email notification
- [ ] Client sees "Pending Review" status
- [ ] Client receives submission confirmation email
**Technical Notes:**
- Store in consultations table
- Status: 'pending' initially
- Validate against existing bookings for same client/day
---
### Story 3.5: Admin Booking Review & Approval
**Description:** Admin workflow to review, categorize, and approve/reject booking requests.
**Acceptance Criteria:**
- [ ] View list of pending booking requests
- [ ] See client details and problem summary
- [ ] Determine consultation type:
- Free consultation
- Paid consultation (with amount)
- [ ] Set payment amount and instructions (if paid)
- [ ] Approve booking:
- Status changes to 'approved'
- Client notified via email
- Calendar file (.ics) attached
- Payment instructions included (if paid)
- [ ] Reject booking:
- Optional rejection reason
- Client notified via email
- [ ] Quick action buttons for approve/reject
- [ ] Filter by date range, client
**Technical Notes:**
- Update consultation status and type
- Trigger appropriate email notifications
- Generate .ics file on approval
---
### Story 3.6: Calendar File Generation (.ics)
**Description:** Generate downloadable calendar files for approved consultations.
**Acceptance Criteria:**
- [ ] Generate valid .ics file on booking approval
- [ ] Include:
- Event title: "Consultation with Libra Law Firm"
- Date and time
- Duration: 45 minutes
- Location (if applicable)
- Description with booking reference
- [ ] Attach to approval email
- [ ] Available for download from client dashboard
- [ ] Compatible with major calendar apps (Google, Apple, Outlook)
- [ ] Bilingual event details based on client preference
**Technical Notes:**
- Use maennchen/zipstream-php or spatie/icalendar-generator
- Follow iCalendar specification (RFC 5545)
---
### Story 3.7: Consultation Management
**Description:** Admin tools to manage consultations through their lifecycle.
**Acceptance Criteria:**
- [ ] View all consultations with filters:
- Status (pending/approved/completed/cancelled/no-show)
- Type (free/paid)
- Date range
- Payment status
- Client name
- [ ] Mark consultation as completed
- [ ] Mark consultation as no-show
- [ ] Cancel booking on behalf of client
- [ ] Reschedule appointment:
- Select new date/time
- Notify client via email
- [ ] Mark payment as received (for paid)
- [ ] Add admin notes (internal only)
- [ ] View consultation history per client
**Technical Notes:**
- Status enum: pending, approved, completed, cancelled, no_show
- Payment status: pending, received, not_applicable
- Admin notes stored separately from client-visible data
---
### Story 3.8: Consultation Reminders
**Description:** Automated reminder emails before scheduled consultations.
**Acceptance Criteria:**
- [ ] Send reminder 24 hours before consultation
- [ ] Send reminder 2 hours before consultation
- [ ] Reminder includes:
- Consultation date and time
- Type (free/paid)
- Payment reminder (if paid and not received)
- Any instructions
- [ ] Reminders in client's preferred language
- [ ] No reminder for cancelled consultations
- [ ] Scheduled job for sending reminders
**Technical Notes:**
- Use Laravel scheduler for reminder jobs
- Check consultation status before sending
- Depends on Epic 8 for email infrastructure
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Authentication, database schema, bilingual support |
| Epic 2 | User accounts must exist to book |
| Epic 8 | Email notifications (approval, reminders) |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Double-booking race condition | High | Database-level locking, unique constraints |
| Timezone confusion | Medium | Store UTC, display in local time |
| Reminder job failures | Medium | Queue monitoring, retry logic |
| Calendar file compatibility | Low | Test with major calendar apps |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Tests for booking flow end-to-end
- [ ] Tests for 1-per-day constraint
- [ ] Tests for availability calculation
- [ ] Calendar file validated with multiple apps
- [ ] Email notifications working
- [ ] Reminder jobs scheduled and tested
- [ ] Bilingual support verified
- [ ] Code formatted with Pint

View File

@ -0,0 +1,219 @@
# Epic 4: Case Timeline System
## Epic Goal
Implement a case tracking system where admin can create and update timelines for each client's legal matters, providing clients with read-only visibility into their case progress.
## Epic Description
### Business Context
Each client can have multiple legal cases/matters tracked through separate timelines. The admin adds text-based updates to keep clients informed of progress. This is strictly one-way communication - clients can view but cannot interact or respond.
### Technical Context
- **Timelines:** Multiple per client allowed
- **Updates:** Text-only (no document attachments)
- **Communication:** One-way (admin to client)
- **Status:** Active or Archived
- **Notifications:** Email on each update
### Success 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
---
## Stories
### Story 4.1: Timeline Creation
**Description:** Allow admin to create new case timelines for any client.
**Acceptance Criteria:**
- [ ] Create timeline form with:
- Select client (search by name/email)
- 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 on successful creation
- [ ] Timeline immediately visible to client
**Technical Notes:**
- Store in timelines table
- Fields: user_id, case_name, case_reference, status, created_at
- Validate case_reference uniqueness if provided
---
### Story 4.2: Timeline Updates Management
**Description:** Allow admin to add, edit, and manage updates within a timeline.
**Acceptance Criteria:**
- [ ] Add new update to timeline:
- Update text content (required, rich text supported)
- Timestamp automatically recorded
- Admin name automatically recorded
- [ ] Edit existing updates:
- Modify update text
- Edit history preserved (updated_at changes)
- [ ] Updates displayed in chronological order
- [ ] Each update shows:
- Date/timestamp
- Admin name
- Update content
- [ ] Visual timeline representation (optional enhancement)
- [ ] Client notified via email on new update
**Technical Notes:**
- Store in timeline_updates table
- Fields: timeline_id, admin_id, update_text, created_at, updated_at
- Track edit history via updated_at
---
### Story 4.3: Timeline Archiving
**Description:** Allow admin to archive completed cases and unarchive if needed.
**Acceptance Criteria:**
- [ ] Archive timeline:
- Status changes to 'archived'
- Timeline remains visible to client
- No further updates can be added (until unarchived)
- Visual indicator shows archived status
- [ ] Unarchive timeline:
- Status returns to 'active'
- Updates can be added again
- [ ] Filter timelines by status (active/archived)
- [ ] Bulk archive option for multiple timelines
- [ ] Archived timelines sorted separately in client view
**Technical Notes:**
- Use status field: 'active' or 'archived'
- Soft archive (no data deletion)
---
### Story 4.4: Admin Timeline Dashboard
**Description:** Central view for admin to manage all timelines across all clients.
**Acceptance Criteria:**
- [ ] List all timelines with:
- Case name
- Client name
- Status (active/archived)
- Last update date
- Update count
- [ ] Filter by:
- Client (search/select)
- Status (active/archived/all)
- Date range
- [ ] Sort by:
- Client name
- Case name
- Last updated
- Created date
- [ ] Quick actions:
- View timeline details
- Add update
- Archive/unarchive
- [ ] Search by case name or reference
- [ ] Pagination for large lists
**Technical Notes:**
- Use Livewire for real-time filtering
- Eager load relationships to prevent N+1
---
### Story 4.5: Client Timeline View
**Description:** Read-only timeline view for clients to track their case progress.
**Acceptance Criteria:**
- [ ] List all client's timelines:
- Active timelines prominently displayed
- Archived timelines clearly separated
- Visual distinction (color/icon) for status
- [ ] View individual timeline:
- Case name and reference
- Status indicator
- All updates in chronological order
- Each update with date and content
- [ ] No edit/comment capabilities
- [ ] No ability to archive/delete
- [ ] Responsive design for mobile viewing
- [ ] Recent updates indicator (new since last view)
- [ ] Bilingual labels and dates
**Technical Notes:**
- Filter by authenticated user's ID
- Track last_viewed timestamp per timeline (optional)
- Read-only Volt component
---
### Story 4.6: Timeline Update Notifications
**Description:** Email clients when admin adds updates to their timelines.
**Acceptance Criteria:**
- [ ] Email sent when new update added
- [ ] Email includes:
- Case name/reference
- Update summary or full text
- Link to view timeline
- Date of update
- [ ] Email in client's preferred language
- [ ] Sender: no-reply@libra.ps
- [ ] Professional template with branding
- [ ] No email for archived timeline reactivation
- [ ] Queue emails for performance
**Technical Notes:**
- Use Laravel notifications
- Trigger on timeline_updates creation
- Depends on Epic 8 for full email infrastructure
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Authentication, database schema |
| Epic 2 | User accounts (timelines assigned to users) |
| Epic 8 | Email notifications |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Large update content performance | Low | Paginate updates, lazy load |
| Email notification failures | Medium | Queue with retry, log failures |
| Accidental archive of active case | Low | Confirmation dialog, unarchive option |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Tests for timeline CRUD operations
- [ ] Tests for update management
- [ ] Tests for archive/unarchive
- [ ] Client view properly scoped to their timelines only
- [ ] Email notifications working
- [ ] Bilingual support verified
- [ ] Code formatted with Pint

View File

@ -0,0 +1,181 @@
# Epic 5: Posts/Blog System
## Epic Goal
Implement an admin-only content publishing system for legal updates, articles, and news that is publicly visible to all website visitors.
## Epic Description
### Business Context
The lawyer needs to publish professional legal content to establish expertise and keep visitors informed. Posts are created by admin only, displayed publicly without login requirement, and support bilingual content (Arabic/English).
### Technical Context
- **Publishing:** Admin-only creation
- **Visibility:** Public (no login required)
- **Content:** Text-only with rich text formatting
- **Interaction:** Read-only (no comments)
- **Search:** Simple title and body search
### Success 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
---
## Stories
### Story 5.1: Post Creation & Editing
**Description:** Allow admin to create and edit blog posts with rich text formatting.
**Acceptance Criteria:**
- [ ] Create post form with:
- Title (required, bilingual: Arabic and English)
- Body content (required, bilingual)
- Status (draft/published)
- [ ] Rich text editor for body:
- 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
- [ ] Immediate publishing (no scheduling)
- [ ] Timestamps: created_at, updated_at
**Technical Notes:**
- Use TinyMCE or similar rich text editor
- Store bilingual content (title_ar, title_en, body_ar, body_en)
- Or use JSON column for translations
---
### Story 5.2: Post Management Dashboard
**Description:** Admin interface to manage all posts.
**Acceptance Criteria:**
- [ ] List all posts with:
- Title (in current admin language)
- Status (draft/published)
- Created date
- Last updated date
- [ ] Filter by status (draft/published/all)
- [ ] Search by title or body content
- [ ] Sort by date (newest/oldest)
- [ ] Quick actions:
- Edit
- Delete (with confirmation)
- Publish/unpublish toggle
- [ ] Pagination for large post counts
- [ ] Bulk delete option
**Technical Notes:**
- Use Livewire for real-time filtering
- Soft delete consideration (or hard delete per PRD)
---
### Story 5.3: Post Deletion
**Description:** Allow admin to permanently delete posts.
**Acceptance Criteria:**
- [ ] Delete button on post list and edit page
- [ ] Confirmation dialog before deletion
- [ ] Permanent deletion (no soft delete)
- [ ] Success message after deletion
- [ ] Cannot delete while viewing post publicly
- [ ] Audit log entry for deletion
**Technical Notes:**
- Hard delete from posts table
- Log in admin_logs for audit
---
### Story 5.4: Public Posts Display
**Description:** Display published posts to all website visitors.
**Acceptance Criteria:**
- [ ] Posts listing page (public, no login required)
- [ ] Display in reverse chronological order
- [ ] Each post card shows:
- Title
- Publication date
- Excerpt (first ~150 characters)
- Read more link
- [ ] Individual post page with full content
- [ ] Clean, readable typography
- [ ] Responsive design (mobile-friendly)
- [ ] Language-appropriate content based on site language
- [ ] Back to posts list link
- [ ] Pagination for post list
**Technical Notes:**
- Display title/body based on current locale
- No authentication required
- SEO-friendly URLs (optional, per PRD no SEO for now)
---
### Story 5.5: Post Search
**Description:** Allow visitors to search through published posts.
**Acceptance Criteria:**
- [ ] Search input on posts listing page
- [ ] Search by:
- Title (both languages)
- Body content (both languages)
- [ ] Real-time search results (debounced)
- [ ] Search highlights in results (optional)
- [ ] "No results found" message
- [ ] Clear search button
- [ ] Search works in both Arabic and English
- [ ] Only searches published posts
**Technical Notes:**
- Use Livewire for real-time search
- LIKE query on title and body fields
- Consider full-text search for performance (future)
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Base UI, navigation, bilingual support |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Rich text editor XSS | High | Sanitize HTML, whitelist allowed tags |
| Large content performance | Low | Paginate, excerpt for listings |
| Draft loss on browser crash | Medium | Auto-save functionality |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Tests for post CRUD operations
- [ ] Tests for public display
- [ ] Tests for search functionality
- [ ] Rich text properly sanitized
- [ ] Bilingual content working
- [ ] Responsive design verified
- [ ] Code formatted with Pint

View File

@ -0,0 +1,340 @@
# Epic 6: Admin Dashboard
## Epic Goal
Create a comprehensive admin dashboard providing centralized control, statistics, analytics, data exports, and system configuration for the law firm's operations.
## Epic Description
### Business Context
The lawyer needs a central control panel to manage all aspects of the platform efficiently. This includes real-time metrics, quick actions, data visualization, export capabilities, and system settings.
### Technical Context
- **Charts:** Chart.js for visualizations
- **Exports:** CSV and PDF formats
- **Real-time:** Live metrics updates
- **PDF:** barryvdh/laravel-dompdf
- **CSV:** league/csv
### Success 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
---
## Stories
### Story 6.1: Dashboard Overview & Statistics
**Description:** Main dashboard page with real-time metrics and key performance indicators.
**Acceptance Criteria:**
- [ ] **User Metrics Card:**
- Total active clients
- Individual vs company breakdown
- Deactivated clients count
- New clients this month
- [ ] **Booking Metrics Card:**
- Pending requests count (highlighted)
- Today's consultations
- This week's consultations
- This month's consultations
- Total consultations (all time)
- Free vs paid breakdown
- No-show rate percentage
- [ ] **Timeline Metrics Card:**
- Active case timelines
- Archived timelines
- Updates added this week
- [ ] **Posts Metrics Card:**
- Total published posts
- Posts published this month
- [ ] Clean card-based layout
- [ ] Color-coded status indicators
- [ ] Quick stats at a glance
**Technical Notes:**
- Use Livewire for real-time updates
- Cache expensive queries with short TTL
- Responsive grid layout
---
### Story 6.2: Analytics Charts
**Description:** Visual charts showing trends and historical data.
**Acceptance Criteria:**
- [ ] **Monthly Trends Chart (Line):**
- New clients per month
- Consultations per month
- [ ] **Consultation Breakdown (Pie/Donut):**
- Free vs paid ratio
- [ ] **No-show Rate (Line):**
- Monthly no-show trend
- [ ] Date range selector:
- Last 6 months
- Last 12 months
- Custom range
- [ ] Chart tooltips with exact values
- [ ] Responsive charts (resize with viewport)
- [ ] Bilingual labels
**Technical Notes:**
- Use Chart.js
- Data aggregated server-side
- Lazy load chart data
---
### Story 6.3: Quick Actions Panel
**Description:** Quick access to pending items requiring admin attention.
**Acceptance Criteria:**
- [ ] **Pending Bookings:**
- Count badge with urgent indicator
- Link to booking management
- Mini list of recent pending
- [ ] **Today's Schedule:**
- List of today's consultations
- Time and client name
- Quick status update buttons
- [ ] **Recent Timeline Updates:**
- Last 5 updates made
- Quick link to timeline
- [ ] Notification bell with pending count
- [ ] One-click access to common tasks:
- Create user
- Create post
- Block time slot
**Technical Notes:**
- Dashboard widgets pattern
- Real-time updates via Livewire polling
---
### Story 6.4: Data Export - User Lists
**Description:** Export user data in CSV and PDF formats.
**Acceptance Criteria:**
- [ ] Export all users
- [ ] Export individual clients only
- [ ] Export company clients only
- [ ] **Filter options:**
- Date range (created)
- Status (active/deactivated)
- [ ] **CSV export includes:**
- Name, email, phone
- User type
- National ID / Company reg
- Status
- Created date
- [ ] **PDF export includes:**
- Same data with professional formatting
- Libra branding header
- Generation timestamp
- [ ] Download directly to device
- [ ] Bilingual column headers (based on admin language)
**Technical Notes:**
- Use league/csv for CSV
- Use barryvdh/laravel-dompdf for PDF
- Chunked processing for large datasets
---
### Story 6.5: Data Export - Consultation Records
**Description:** Export consultation/booking data.
**Acceptance Criteria:**
- [ ] Export all consultations
- [ ] **Filter options:**
- Date range
- Consultation type (free/paid)
- Status (approved/completed/no-show/cancelled)
- Payment status
- [ ] **Export includes:**
- Client name
- Date and time
- Consultation type
- Status
- Payment status
- Problem summary
- [ ] CSV and PDF formats
- [ ] Professional PDF layout with branding
**Technical Notes:**
- Similar pattern to user exports
- Handle large problem summaries in PDF
---
### Story 6.6: Data Export - Timeline Reports
**Description:** Export timeline and case data.
**Acceptance Criteria:**
- [ ] Export all timelines (across all clients)
- [ ] Export timelines for specific client
- [ ] **Filter options:**
- Status (active/archived)
- Date range
- [ ] **Export includes:**
- Case name and reference
- Client name
- Status
- Created date
- Number of updates
- Last update date
- [ ] CSV and PDF formats
**Technical Notes:**
- Option to include update content or summary only
---
### Story 6.7: Monthly Statistics Report
**Description:** Generate comprehensive monthly PDF report.
**Acceptance Criteria:**
- [ ] "Generate Monthly Report" button
- [ ] Select month/year
- [ ] **PDF report includes:**
- Overview of key metrics
- Charts (rendered as images)
- User statistics
- Consultation statistics
- Timeline statistics
- Post statistics
- [ ] Professional layout with branding
- [ ] Table of contents
- [ ] Printable format
- [ ] Bilingual based on admin preference
**Technical Notes:**
- Complex PDF generation
- Pre-render charts as base64 images
- Longer generation time (loading indicator)
---
### Story 6.8: System Settings
**Description:** Configure system-wide settings.
**Acceptance Criteria:**
- [ ] **Profile Settings:**
- Admin name
- Email
- Password change
- Preferred language
- [ ] **Email Settings:**
- View current sender email
- Test email functionality
- [ ] **Notification Preferences:**
- Toggle admin notifications
- Summary email frequency
- [ ] Settings saved and applied immediately
- [ ] Validation for all inputs
**Technical Notes:**
- Settings can be stored in config or database
- Some settings may require .env changes (display only)
---
### Story 6.9: Legal Pages Editor
**Description:** Admin-editable Terms of Service and Privacy Policy pages.
**Acceptance Criteria:**
- [ ] Edit Terms of Service:
- Rich text editor
- Bilingual content (Arabic/English)
- Save and publish
- [ ] Edit Privacy Policy:
- Rich text editor
- Bilingual content
- Save and publish
- [ ] Pages accessible from footer (public)
- [ ] Last updated timestamp displayed
- [ ] Preview before publishing
**Technical Notes:**
- Store in database (settings table or pages table)
- Public routes for viewing
- No versioning required (simple overwrite)
---
### Story 6.10: Audit Log Viewer
**Description:** View admin action history for accountability.
**Acceptance Criteria:**
- [ ] List admin actions from admin_logs table
- [ ] **Display:**
- Action type (create, update, delete)
- Target (user, consultation, timeline, etc.)
- Old and new values (for updates)
- Timestamp
- IP address
- [ ] Filter by:
- Action type
- Target type
- Date range
- [ ] Search by target name/ID
- [ ] Pagination
- [ ] Export audit log (CSV)
**Technical Notes:**
- admin_logs table from Epic 1
- Read-only view
- Consider retention policy (future)
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Base UI, authentication, database |
| Epic 2 | User data for metrics |
| Epic 3 | Booking data for metrics |
| Epic 4 | Timeline data for metrics |
| Epic 5 | Posts data for metrics |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Large export performance | Medium | Chunked processing, background jobs |
| PDF generation memory | Medium | Limit data per report, optimize |
| Real-time metric performance | Low | Cache with short TTL, efficient queries |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Metrics display accurately
- [ ] Charts render correctly
- [ ] Exports generate valid files
- [ ] PDF branding correct
- [ ] Settings save and apply
- [ ] Legal pages editable and public
- [ ] Audit log queryable
- [ ] Responsive on tablet
- [ ] Code formatted with Pint

View File

@ -0,0 +1,240 @@
# Epic 7: Client Dashboard
## Epic Goal
Create a client portal where logged-in clients can view their consultations, case timelines, profile information, and book new consultations.
## Epic Description
### Business Context
Clients need a simple, intuitive interface to access their information and services. They can view (but not modify) their profile, see upcoming and past consultations, track case progress through timelines, and request new consultations.
### Technical Context
- **Access:** Authenticated clients only
- **Capabilities:** Read-mostly (can only submit bookings)
- **Restrictions:** Cannot edit profile, cancel bookings, or comment
- **Design:** Mobile-friendly, professional
### Success 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
---
## Stories
### Story 7.1: Client Dashboard Overview
**Description:** Main dashboard page for clients showing key information at a glance.
**Acceptance Criteria:**
- [ ] Welcome message with client name
- [ ] **Upcoming Consultations Widget:**
- Next consultation date/time
- Type (free/paid)
- Status
- Quick link to details
- [ ] **Active Cases Widget:**
- Count of active timelines
- Latest update preview
- Link to full list
- [ ] **Recent Updates Widget:**
- Last 3 timeline updates (across all cases)
- Case name and date
- Link to full timeline
- [ ] **Booking Status Widget:**
- Pending booking requests
- Daily booking limit indicator
- Quick book button
- [ ] Clean, card-based layout
- [ ] Bilingual content
**Technical Notes:**
- Scoped to authenticated user's data only
- Use Livewire components for widgets
- Mobile-first responsive design
---
### Story 7.2: My Consultations View
**Description:** List of all client's consultations (upcoming and past).
**Acceptance Criteria:**
- [ ] **Upcoming Consultations Section:**
- Date and time
- Consultation type (free/paid)
- Status (approved/pending)
- Payment status (for paid)
- Download .ics calendar file button
- [ ] **Pending Requests Section:**
- Submitted bookings awaiting approval
- Submission date
- Problem summary preview
- Status: "Pending Review"
- [ ] **Past Consultations Section:**
- Historical consultations
- Status (completed/cancelled/no-show)
- Date and type
- [ ] Visual status indicators
- [ ] Sort by date (default: newest first for past)
- [ ] Pagination if many consultations
- [ ] No edit/cancel capabilities
**Technical Notes:**
- Filter by authenticated user
- Group by status categories
- Calendar download from Epic 3
---
### Story 7.3: My Cases/Timelines View
**Description:** List and detail view of client's case timelines.
**Acceptance Criteria:**
- [ ] **Active Cases Section:**
- List of active timelines
- Case name and reference
- Last update date
- Update count
- "View" button
- [ ] **Archived Cases Section:**
- Clearly separated from active
- Different visual styling (muted)
- Still accessible for viewing
- [ ] **Individual Timeline View:**
- Case name and reference
- Status badge (active/archived)
- All updates in chronological order
- Each update shows:
- Date and time
- Update content
- Read-only (no interactions)
- [ ] Back to cases list navigation
- [ ] Responsive layout
**Technical Notes:**
- Reuse components from Epic 4
- Read-only view only
- Proper date formatting per locale
---
### Story 7.4: My Profile View
**Description:** Display client's profile information (read-only).
**Acceptance Criteria:**
- [ ] **Individual Client Profile:**
- Full name
- National ID
- Email address
- Phone number
- Preferred language
- Account created date
- [ ] **Company Client Profile:**
- Company name
- Registration number
- Contact person name
- Contact person ID
- Email address
- Phone number
- Preferred language
- Account created date
- [ ] Account type indicator
- [ ] No edit capabilities
- [ ] Message: "Contact admin to update your information"
- [ ] Logout button
**Technical Notes:**
- Display based on user_type
- Mask sensitive data if needed (e.g., partial ID)
---
### Story 7.5: New Booking Interface
**Description:** Interface for clients to submit new consultation booking requests.
**Acceptance Criteria:**
- [ ] Quick access from dashboard
- [ ] Calendar view showing available dates
- [ ] Available time slots for selected date
- [ ] **Booking Form:**
- Selected date/time (display)
- Problem summary (required, textarea)
- Submit button
- [ ] **Validation:**
- 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
**Technical Notes:**
- Reuse availability calendar from Epic 3
- Client-side validation + server-side enforcement
- Check existing bookings for same day
---
### Story 7.6: Booking Limit Indicator
**Description:** Visual indicator of client's booking status and limits.
**Acceptance Criteria:**
- [ ] Show on dashboard and booking page
- [ ] Display current booking status:
- "You can book a consultation today"
- "You already have a booking for today"
- "You have a pending request for [date]"
- [ ] Calendar shows booked days as unavailable
- [ ] Clear messaging about 1-per-day limit
- [ ] Bilingual messages
**Technical Notes:**
- Query consultations for user
- Consider future bookings in calculation
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Authentication, base UI |
| Epic 2 | User accounts (client data) |
| Epic 3 | Consultation data, booking interface |
| Epic 4 | Timeline data |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Confusion over read-only restrictions | Medium | Clear messaging, contact admin prompts |
| Mobile usability issues | Medium | Thorough mobile testing |
| Booking limit bypass attempts | Low | Server-side validation always |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Dashboard displays accurate data
- [ ] Consultations list works correctly
- [ ] Timelines display read-only
- [ ] Profile shows correct information
- [ ] Booking limit enforced
- [ ] Calendar files downloadable
- [ ] Mobile responsive verified
- [ ] Bilingual support verified
- [ ] Code formatted with Pint

View File

@ -0,0 +1,302 @@
# Epic 8: Email Notification System
## Epic Goal
Implement a comprehensive email notification system with professional templates, bilingual support, and reliable delivery for all platform communications.
## Epic Description
### Business Context
Email is the primary communication channel. Clients receive mandatory notifications (no opt-out) for account creation, booking updates, reminders, and timeline updates. Admin receives notifications for new bookings and system events.
### Technical Context
- **Sender:** no-reply@libra.ps
- **Sender Name:** Libra Law Firm / مكتب ليبرا للمحاماة
- **SMTP:** Configured via .env
- **Delivery:** All mandatory (no opt-out for clients)
- **Templates:** Professional with branding
### Success 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
---
## Stories
### Story 8.1: Email Infrastructure Setup
**Description:** Configure email sending infrastructure and base template.
**Acceptance Criteria:**
- [ ] SMTP configuration via .env:
- MAIL_MAILER
- MAIL_HOST
- MAIL_PORT
- MAIL_USERNAME
- MAIL_PASSWORD
- MAIL_ENCRYPTION
- MAIL_FROM_ADDRESS (no-reply@libra.ps)
- MAIL_FROM_NAME
- [ ] Base email template with:
- Libra logo header
- Navy blue (#0A1F44) and gold (#D4AF37) colors
- Professional typography
- Footer with firm contact info
- Mobile-responsive layout
- [ ] Plain text fallback generation
- [ ] Queue configuration for async sending
- [ ] Email logging for debugging
**Technical Notes:**
- Use Laravel Mail with Mailable classes
- Create base Mailable with shared layout
- Configure queue connection
---
### Story 8.2: Welcome Email (Account Created)
**Description:** Email sent when admin creates a new client account.
**Acceptance Criteria:**
- [ ] Triggered on user creation
- [ ] **Content:**
- Personalized greeting (name/company)
- "Your account has been created"
- Login credentials (email, password)
- Login URL link
- Brief platform introduction
- Contact info for questions
- [ ] Language based on user's preferred_language
- [ ] Call-to-action button: "Login Now"
- [ ] Security note about changing password (N/A - admin only)
**Technical Notes:**
- Mailable: WelcomeEmail
- Trigger: User created event
- Queue for performance
---
### Story 8.3: Booking Submitted Confirmation
**Description:** Email to client confirming their booking request was submitted.
**Acceptance Criteria:**
- [ ] Triggered on booking submission
- [ ] **Content:**
- "Your consultation request has been submitted"
- Requested date and time
- Problem summary preview
- "Pending Review" status note
- Expected response timeframe (general)
- [ ] Language based on client preference
- [ ] No action required message
**Technical Notes:**
- Mailable: BookingSubmittedEmail
- Trigger: Consultation created with status 'pending'
---
### Story 8.4: Booking Approved Email
**Description:** Email to client when admin approves their booking.
**Acceptance Criteria:**
- [ ] Triggered on booking approval
- [ ] **Content:**
- "Your consultation has been approved"
- Confirmed date and time
- Duration (45 minutes)
- Consultation type (free/paid)
- If paid: amount and payment instructions
- Calendar file (.ics) attached
- "Add to Calendar" button/link
- Location/contact information
- [ ] Language based on client preference
- [ ] Professional confirmation tone
**Technical Notes:**
- Mailable: BookingApprovedEmail
- Attach .ics file from Epic 3
- Trigger: Consultation status changed to 'approved'
---
### Story 8.5: Booking Rejected Email
**Description:** Email to client when admin rejects their booking.
**Acceptance Criteria:**
- [ ] Triggered on booking rejection
- [ ] **Content:**
- "Your consultation request could not be approved"
- Original requested date and time
- Rejection reason (if provided by admin)
- Invitation to request new consultation
- Contact info for questions
- [ ] Empathetic, professional tone
- [ ] Language based on client preference
**Technical Notes:**
- Mailable: BookingRejectedEmail
- Optional reason field from admin
- Trigger: Consultation status changed to 'rejected'
---
### Story 8.6: Consultation Reminder (24 Hours)
**Description:** Reminder email sent 24 hours before scheduled consultation.
**Acceptance Criteria:**
- [ ] Scheduled job runs daily
- [ ] Find consultations 24 hours away
- [ ] **Content:**
- "Reminder: Your consultation is tomorrow"
- Date and time
- Consultation type
- Payment reminder (if paid and not received)
- Calendar file link
- Any preparation notes
- [ ] Skip cancelled/no-show consultations
- [ ] Language based on client preference
**Technical Notes:**
- Scheduled command: php artisan reminders:send-24h
- Run via Laravel scheduler
- Mailable: ConsultationReminder24Email
---
### Story 8.7: Consultation Reminder (2 Hours)
**Description:** Reminder email sent 2 hours before scheduled consultation.
**Acceptance Criteria:**
- [ ] Scheduled job runs hourly
- [ ] Find consultations 2 hours away
- [ ] **Content:**
- "Your consultation is in 2 hours"
- Date and time
- Final payment reminder (if applicable)
- Contact info for last-minute issues
- [ ] Skip cancelled/no-show consultations
- [ ] Language based on client preference
**Technical Notes:**
- Scheduled command: php artisan reminders:send-2h
- More frequent checks for accuracy
- Mailable: ConsultationReminder2hEmail
---
### Story 8.8: Timeline Update Notification
**Description:** Email to client when admin adds update to their timeline.
**Acceptance Criteria:**
- [ ] Triggered on timeline update creation
- [ ] **Content:**
- "Update on your case: [Case Name]"
- Case reference number
- Update content (full or summary)
- Date of update
- "View Timeline" button/link
- [ ] Language based on client preference
- [ ] Professional, informative tone
**Technical Notes:**
- Mailable: TimelineUpdateEmail
- Trigger: TimelineUpdate created event
- Link to client dashboard timeline view
---
### Story 8.9: Admin Notification - New Booking
**Description:** Email to admin when client submits new booking request.
**Acceptance Criteria:**
- [ ] Triggered on booking submission
- [ ] Sent to admin email
- [ ] **Content:**
- "New Consultation Request"
- Client name (individual or company)
- Requested date and time
- Problem summary (full)
- Client contact info
- "Review Request" button/link
- [ ] Admin language preference (or default)
- [ ] Priority indicator in subject line
**Technical Notes:**
- Mailable: NewBookingAdminEmail
- Send to configured admin email
- Include direct link to booking management
---
### Story 8.10: Admin Notification - System Events
**Description:** Critical system notifications to admin.
**Acceptance Criteria:**
- [ ] Email failures notification
- [ ] Scheduled job failures notification
- [ ] Critical errors summary
- [ ] **Content:**
- Event type and description
- Timestamp
- Relevant details
- Recommended action (if any)
- [ ] Sent immediately (not queued)
- [ ] Clear subject line indicating urgency
**Technical Notes:**
- Use Laravel exception handler
- Monitor queues and scheduler
- Consider separate notification channel
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Base application, user preferences |
| Epic 2 | User creation (welcome email) |
| Epic 3 | Booking events, calendar files |
| Epic 4 | Timeline updates |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Email delivery failures | High | Queue retry, logging, admin alerts |
| SMTP configuration issues | High | Test email feature, validation |
| Spam filtering | Medium | Proper SPF/DKIM, professional content |
| Timezone issues in reminders | Medium | Store and display in consistent timezone |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] All 9+ email types implemented
- [ ] Emails render correctly (HTML and plain text)
- [ ] Bilingual emails working
- [ ] Branding consistent across all emails
- [ ] Queue processing reliable
- [ ] Reminder jobs scheduled and tested
- [ ] Calendar attachments working
- [ ] Admin notifications delivered
- [ ] Code formatted with Pint

View File

@ -0,0 +1,405 @@
# Epic 9: Design & Branding Implementation
## Epic Goal
Implement the complete visual design system with professional branding, ensuring a polished, elegant, and accessible user experience across all pages and devices.
## Epic Description
### Business Context
Libra Law Firm requires a highly professional aesthetic that reflects legal excellence and attention to detail. The design must balance sophistication with usability, supporting bilingual (Arabic/English) audiences with proper RTL/LTR layouts.
### Technical Context
- **Colors:** Dark Navy Blue (#0A1F44) + Gold (#D4AF37)
- **Fonts:** Cairo/Tajawal (Arabic), Montserrat/Lato (English)
- **Framework:** Tailwind CSS 4, Flux UI Free
- **Accessibility:** WCAG AA compliance
- **Responsive:** Mobile-first design
### Success 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
---
## Stories
### Story 9.1: Color System Implementation
**Description:** Implement the complete color palette as Tailwind CSS theme.
**Acceptance Criteria:**
- [ ] **Primary Colors:**
- Dark Navy Blue: #0A1F44 (backgrounds, headers)
- Gold/Brass: #D4AF37 (accents, buttons, links)
- [ ] **Supporting Colors:**
- 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
- [ ] Dark mode consideration (optional)
- [ ] Color variables for easy maintenance
**Technical Notes:**
- Configure in Tailwind CSS 4 @theme directive
- Create semantic color aliases (primary, accent, etc.)
---
### Story 9.2: Typography System
**Description:** Implement typography with proper font loading and hierarchy.
**Acceptance Criteria:**
- [ ] **Arabic Fonts:**
- Primary: Cairo or Tajawal (Google Fonts)
- Weights: Light (300), Regular (400), SemiBold (600), Bold (700)
- [ ] **English Fonts:**
- Primary: Montserrat or Lato
- Weights: Light (300), Regular (400), SemiBold (600), Bold (700)
- [ ] **Font 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 for performance
- [ ] Preload critical fonts
- [ ] Consistent across all pages
**Technical Notes:**
- Import from Google Fonts
- Configure Tailwind font-family
- Use @font-face for fallbacks
---
### Story 9.3: Logo Integration
**Description:** Integrate Libra scales logo throughout the application.
**Acceptance Criteria:**
- [ ] **Logo Placement:**
- Navigation: Top left (desktop), centered (mobile)
- Footer: Smaller version
- Email templates: Header
- PDF exports: Header
- [ ] **Logo Specifications:**
- Minimum size: 120px (desktop), 80px (mobile)
- Clear space: 20px padding minimum
- [ ] **Format Support:**
- SVG primary (scalable)
- PNG fallback
- [ ] **Color Variations:**
- Full color (gold on navy)
- Reversed (navy on light)
- Monochrome gold
- [ ] Responsive sizing
- [ ] Accessible alt text
**Technical Notes:**
- Use SVG for scalability
- Blade component for reuse
- Dynamic color based on background
---
### Story 9.4: Component Styling - Buttons
**Description:** Style all button types per brand guidelines.
**Acceptance Criteria:**
- [ ] **Primary Button:**
- Background: Gold (#D4AF37)
- Text: Dark Navy Blue
- Hover: Light Gold (#F4E4B8)
- Border-radius: 6px
- Padding: 12px 24px
- [ ] **Secondary Button:**
- Background: Transparent
- Border: 2px solid Gold
- Text: Gold
- Hover: Gold background, Navy text
- [ ] **Disabled State:**
- Background: #CCCCCC
- Text: #666666
- No hover effect
- Cursor: not-allowed
- [ ] **Danger Button:**
- Background: #E74C3C
- Text: White
- [ ] Loading states with spinner
- [ ] Focus states for accessibility
- [ ] Flux UI button integration
**Technical Notes:**
- Extend Flux UI button component
- Create Tailwind component classes
- Ensure consistent sizing
---
### Story 9.5: Component Styling - Forms
**Description:** Style all form elements consistently.
**Acceptance Criteria:**
- [ ] **Input Fields:**
- Border: Charcoal Gray
- Focus: Gold border
- Border-radius: 6px
- Padding: 12px 16px
- [ ] **Textareas:**
- Same styling as inputs
- Minimum height: 120px
- [ ] **Select Dropdowns:**
- Custom styled (not native)
- Consistent with inputs
- [ ] **Checkboxes & Radios:**
- Custom styled with gold accent
- Clear checked state
- [ ] **Labels:**
- SemiBold weight
- Required indicator (*)
- [ ] **Error States:**
- Red border
- Error message below field
- [ ] RTL support for all fields
- [ ] Flux UI field integration
**Technical Notes:**
- Use Flux UI form components
- Ensure proper RTL alignment
- Validate error message positioning
---
### Story 9.6: Component Styling - Cards & Containers
**Description:** Style cards and container elements.
**Acceptance Criteria:**
- [ ] **Card Styling:**
- Background: Off-white/cream
- Box-shadow: 0 2px 8px rgba(0,0,0,0.1)
- Border-radius: 8px
- Padding: 24px
- [ ] **Gold Border Highlight:**
- Optional gold top/left border
- For featured/important cards
- [ ] **Hover States:**
- Subtle lift effect
- Shadow increase
- [ ] **Dashboard Stat Cards:**
- Icon with gold accent
- Large number display
- Trend indicator
- [ ] **List Cards:**
- Consistent item spacing
- Clear click targets
- [ ] Container max-width: 1200px
**Technical Notes:**
- Create Blade card component
- Variant props for different styles
---
### Story 9.7: Navigation & Footer Styling
**Description:** Style the navigation bar and footer.
**Acceptance Criteria:**
- [ ] **Navigation Bar:**
- Fixed top position
- Navy blue background
- Logo left (desktop), centered (mobile)
- Gold text for links
- Active link indicator
- Language toggle styled
- Responsive mobile menu
- [ ] **Mobile Menu:**
- Full-width dropdown/slide
- Navy background
- Clear touch targets (44px+)
- Smooth animation
- [ ] **Footer:**
- Navy blue background
- Logo and firm info
- Contact details
- Links to Terms/Privacy
- Social links (if any)
- Copyright notice
- [ ] Sticky footer (always at bottom)
**Technical Notes:**
- Use Flux navbar if available
- Alpine.js for mobile menu toggle
---
### Story 9.8: RTL/LTR Layout Perfection
**Description:** Ensure perfect RTL layout for Arabic and LTR for English.
**Acceptance Criteria:**
- [ ] **RTL (Arabic):**
- Text aligns right
- Navigation mirrors (logo right)
- Form labels on right
- Icons/arrows flip appropriately
- Margins/paddings swap
- [ ] **LTR (English):**
- Standard left-to-right layout
- Proper text alignment
- [ ] Seamless language toggle
- [ ] No layout breaks on switch
- [ ] Calendar RTL support
- [ ] Tables RTL support
- [ ] All components tested in both
**Technical Notes:**
- Use Tailwind RTL plugin
- dir="rtl" on html element
- Logical properties (start/end vs left/right)
---
### Story 9.9: Responsive Design Implementation
**Description:** Ensure all pages work perfectly on all device sizes.
**Acceptance Criteria:**
- [ ] **Breakpoints:**
- Mobile: < 576px
- Tablet: 576px - 991px
- Desktop: 992px - 1199px
- Large Desktop: >= 1200px
- [ ] **Mobile Optimizations:**
- Touch-friendly targets (44px+)
- Readable font sizes
- Single column layouts
- Collapsible sections
- [ ] **Tablet Optimizations:**
- Two-column where appropriate
- Sidebar collapsible
- [ ] **Desktop Optimizations:**
- Full layouts with sidebars
- Multi-column grids
- [ ] All forms usable on mobile
- [ ] Calendar usable on mobile
- [ ] Tables scroll horizontally
**Technical Notes:**
- Mobile-first approach
- Test on real devices
- Use responsive utilities
---
### Story 9.10: Accessibility Compliance
**Description:** Ensure WCAG AA accessibility compliance.
**Acceptance Criteria:**
- [ ] **Color Contrast:**
- Body text: 4.5:1 minimum
- Large text: 3:1 minimum
- UI elements: 3:1 minimum
- [ ] **Focus Indicators:**
- Visible focus outline (gold)
- Not just color change
- [ ] **Keyboard Navigation:**
- All interactive elements reachable
- Logical tab order
- Skip to main content link
- [ ] **Screen Readers:**
- Proper heading hierarchy
- Alt text for images
- ARIA labels where needed
- Form labels associated
- [ ] **Motion:**
- Respect prefers-reduced-motion
- No auto-playing animations
**Technical Notes:**
- Use accessibility testing tools
- Test with screen reader
- Document any exceptions
---
### Story 9.11: Animations & Micro-interactions
**Description:** Add subtle, professional animations and transitions.
**Acceptance Criteria:**
- [ ] **Transitions:**
- Button hover: 150ms ease
- Card hover: 200ms ease
- Modal open/close: 200ms
- Page transitions (optional)
- [ ] **Loading States:**
- Skeleton loaders for content
- Spinner for actions
- Progress indicators
- [ ] **Feedback Animations:**
- Success checkmark
- Error shake
- Toast slide-in
- [ ] **Hover Effects:**
- Links: Color transition
- Cards: Lift effect
- Buttons: Background transition
- [ ] All animations subtle, professional
- [ ] Respect reduced-motion preference
**Technical Notes:**
- Use Tailwind transition utilities
- Keep animations under 300ms
- Avoid distracting effects
---
## Dependencies
| Epic | Dependency |
|------|------------|
| Epic 1 | Base Tailwind/Flux setup |
| All Epics | This epic applies styling to all features |
## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Logo not provided in vector | Medium | Request SVG, create placeholder |
| RTL edge cases | Medium | Thorough testing, RTL checklist |
| Browser inconsistencies | Low | Cross-browser testing |
| Accessibility issues discovered late | Medium | Test early and often |
## Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Brand colors consistent throughout
- [ ] Typography proper and readable
- [ ] Logo integrated correctly
- [ ] All components styled
- [ ] RTL layout perfect
- [ ] Responsive on all breakpoints
- [ ] WCAG AA compliant
- [ ] Animations smooth and subtle
- [ ] Cross-browser tested
- [ ] Code formatted with Pint

113
docs/epics/index.md Normal file
View File

@ -0,0 +1,113 @@
# Libra Law Firm - Project Epics
**Project:** Libra Law Firm Website
**Domain:** libra.ps
**Generated:** December 20, 2025
**Source PRD:** [docs/prd.md](../prd.md)
---
## Overview
This document provides an index of all epics for the Libra Law Firm platform development. The project is a bilingual (Arabic/English) web platform for managing client consultations, appointments, and case tracking.
---
## Epic Summary
| # | Epic | Stories | Priority | Dependencies |
|---|------|---------|----------|--------------|
| 1 | [Core Foundation & Infrastructure](./epic-1-core-foundation.md) | 4 | Critical | None |
| 2 | [User Management System](./epic-2-user-management.md) | 5 | Critical | Epic 1 |
| 3 | [Booking & Consultation System](./epic-3-booking-consultation.md) | 8 | Critical | Epic 1, 2 |
| 4 | [Case Timeline System](./epic-4-case-timeline.md) | 6 | High | Epic 1, 2 |
| 5 | [Posts/Blog System](./epic-5-posts-blog.md) | 5 | Medium | Epic 1 |
| 6 | [Admin Dashboard](./epic-6-admin-dashboard.md) | 10 | High | Epic 1-5 |
| 7 | [Client Dashboard](./epic-7-client-dashboard.md) | 6 | High | Epic 1-4 |
| 8 | [Email Notification System](./epic-8-email-notifications.md) | 10 | High | Epic 1-4 |
| 9 | [Design & Branding Implementation](./epic-9-design-branding.md) | 11 | High | Epic 1 |
**Total Stories:** 65
---
## Recommended Implementation Order
### Phase 1: Foundation (Weeks 1-2)
1. **Epic 1: Core Foundation** - Laravel setup, auth, bilingual infrastructure
2. **Epic 9: Design & Branding** - Can run in parallel, styling applied throughout
### Phase 2: Core Features (Weeks 2-4)
3. **Epic 2: User Management** - Admin-managed accounts
4. **Epic 3: Booking System** - Calendar and consultation booking
5. **Epic 8: Email Notifications** - Supports Epic 2 and 3
### Phase 3: Extended Features (Weeks 4-5)
6. **Epic 4: Case Timeline** - Client case tracking
7. **Epic 5: Posts/Blog** - Public content publishing
### Phase 4: Dashboards & Polish (Weeks 5-6)
8. **Epic 6: Admin Dashboard** - Management interface
9. **Epic 7: Client Dashboard** - Client portal
---
## Dependency Graph
```
Epic 1 (Core Foundation)
├── Epic 2 (User Management)
│ └── Epic 3 (Booking)
│ └── Epic 4 (Timeline)
│ └── Epic 6 (Admin Dashboard)
│ └── Epic 7 (Client Dashboard)
│ └── Epic 8 (Email)
├── Epic 5 (Posts)
└── Epic 9 (Design)
```
---
## Technology Stack Reference
| Component | Technology | Version |
|-----------|------------|---------|
| Backend | Laravel | 12 |
| PHP | PHP | 8.4 |
| Frontend | Livewire + Volt | 3 / 1 |
| UI Components | Flux UI Free | 2 |
| CSS | Tailwind CSS | 4 |
| Database | SQLite (dev) / MariaDB (prod) | - |
| Auth | Laravel Fortify | 1 |
| Testing | Pest | 4 |
---
## Key Design Specifications
| Element | Specification |
|---------|---------------|
| Primary Color | Dark Navy Blue (#0A1F44) |
| Accent Color | Gold (#D4AF37) |
| Arabic Font | Cairo / Tajawal |
| English Font | Montserrat / Lato |
| Primary Language | Arabic (RTL) |
| Secondary Language | English (LTR) |
---
## Quick Links
- [PRD Document](../prd.md)
- [Architecture Documentation](../architecture/) *(if available)*
- [Stories Location](../stories/)
---
## Notes
- All epics follow the existing codebase patterns (Volt class-based components)
- Each epic includes stories with detailed acceptance criteria
- Testing is required for all features (Pest framework)
- Code must be formatted with Pint before completion
- Bilingual support (Arabic/English) required for all user-facing features