ghassan/laravel-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add prompt.md

Browse Source
This commit is contained in:
Ghassan Yusuf 2025-12-19 22:26:37 +03:00
parent 9d9d896357
commit d2f07f6e81
1 changed files with 83 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
prompt.md Normal file
View File

@ -0,0 +1,83 @@
Project Implementation Prompt for AI Agent
Project Title: Torox Club Management System
1. Core Objective
You are tasked with building a complete web application and a corresponding JSON API for a sports club named "Torox". The primary goal is to create a system for the club owner to sell and manage various subscription packages to their customers. The API must be robust enough to support a future mobile application.
2. Technology Stack
Backend: Laravel (PHP)
Database: MySQL / MariaDB
Frontend: The frontend should be built as a Single Page Application (SPA), preferably using Vue.js or React. All frontend interactions must communicate with the backend via the JSON API.
3. Database Schema
First, implement the complete database schema using Laravel migrations. The schema should consist of the following tables with their specified columns and relationships.
users: Stores all user types (admins, customers, trainers).
id, name, email (unique, nullable), mobile_phone (unique, nullable), password (nullable), picture_path (nullable), role (enum: 'admin', 'customer', 'trainer'), date_of_birth (nullable), gender (enum: 'male', 'female', 'other', nullable), blood_type (enum: 'A+', 'A-', 'B+', 'B-', 'AB+', 'AB-', 'O+', 'O-', nullable), parent_user_id (foreign key to users.id, nullable), timestamps.
Logic: A user must register with either an email or a mobile phone. password and parent_user_id are key to the family features.
packages: Defines the products for sale.
id, name, description, price (decimal), duration_days (integer), type (enum: 'fixed', 'flexible'), total_sessions (nullable integer for flexible packages), min_age (nullable), max_age (nullable), gender_restriction (enum: 'male_only', 'female_only', nullable), is_active (boolean), timestamps.
activities: The classes/sessions offered (e.g., "Yoga", "Spin").
id, name, description, default_trainer_id (foreign key to trainers.id, nullable), capacity (integer), timestamps.
schedules: Specific time slots for activities.
id, activity_id (FK), trainer_id (FK, nullable), start_time (datetime), end_time (datetime), day_of_week (enum, nullable), timestamps.
subscriptions: A user's purchased package instance.
id, user_id (FK to the member), package_id (FK), start_date, end_date, sessions_remaining (nullable), status (enum: 'active', 'expired', 'cancelled', 'pending_verification'), payment_status (enum: 'paid', 'unpaid', 'verifying', 'refunded'), timestamps.
payments: Tracks all payment attempts.
id, subscription_id (FK), payer_user_id (FK to who paid), amount (decimal), status (enum: 'pending_payment', 'pending_verification', 'verified', 'rejected'), proof_image_path (nullable string), admin_notes (nullable text), verified_by_user_id (FK to admin, nullable), processed_at (nullable timestamp), timestamps.
bookings: A member's reservation for a specific class schedule.
id, subscription_id (FK), schedule_id (FK), status (enum: 'booked', 'attended', 'cancelled', 'no_show'), timestamps.
Other Tables:
trainers: id, user_id (FK), bio, photo_path.
package_activity (pivot): package_id, activity_id.
settings: key (primary, string), value (string).
user_action_logs: id, user_id (FK), action (string), details (JSON), created_at.
family_relation_history: id, child_user_id (FK), parent_user_id (FK), action (enum: 'added', 'removed'), actor_user_id (FK), created_at.
4. Core Feature Implementation (API-first)
Please implement the following features, ensuring every action is available via a well-defined API endpoint.
User Authentication & Management:
Register new users. A user can register with either an email or a mobile phone.
Login using either email or mobile phone.
API authentication using Laravel Sanctum.
Users can upload/update their profile picture (picture_path).
Family Account Management:
A logged-in customer can create "family member" sub-accounts. These users are created without credentials (email, password are null) and have their parent_user_id set to the primary customer's ID.
A primary customer can "adopt" an existing independent user into their family, which sets the parent_user_id on the child's account. This should trigger a confirmation from the child user. The child retains their login credentials.
A family member can be "promoted" to an independent user. This involves adding credentials and setting their parent_user_id to null.
Log all changes to family structures in the family_relation_history table.
Package Enrollment & Payment Workflow:
"Pay Later" Setting: Create an admin setting to globally enable/disable a "Pay Later" option.
Enrollment: When a customer (for themselves or a family member) enrolls in a package:
If "Pay Later" is chosen: Create the subscription with status: 'active' and payment_status: 'unpaid'. Create a payment record with status: 'pending_payment'. The member can use the services immediately.
If "Pay Now" is chosen: The user must upload a payment proof image. Create the subscription with status: 'pending_verification' and payment_status: 'verifying'. Create a payment record with status: 'pending_verification' and store the proof_image_path.
Payment Verification (Admin Task):
The admin dashboard must show a list of payments with status pending_verification.
The admin can view the payment details and the uploaded proof image.
The admin can Approve (updates payment.status to 'verified', subscription.status to 'active', subscription.payment_status to 'paid') or Reject (updates payment.status to 'rejected', adds notes to admin_notes).
Notifications:
Send email/API notifications for successful payments, rejections, and reminders.
Create a scheduled task (Laravel Command) to run daily and send reminders for all subscriptions with a payment_status of unpaid.
Class Booking (for 'flexible' packages):
A member with a flexible package can view available schedules for the activities included in their package.
Booking a class should check for sessions_remaining > 0 on their subscription and available capacity on the activity.
A successful booking creates a bookings record and decrements sessions_remaining.
Logging:
Implement a system (e.g., a Trait or Middleware) to automatically log key user actions (logins, purchases, profile updates, etc.) into the user_action_logs table.
Please begin by setting up the project, creating the migrations and models, and then proceed to build the API endpoints for these features.