WorkForce is an AI-powered local service-provider marketplace designed to connect customers who need repair or maintenance services with nearby workers who have the relevant skills. For example, if a customer’s ceiling fan stops working, the customer can submit the problem through WorkForce, receive AI-assisted diagnostic information, find suitable workers, choose a worker, and proceed with an assignment. The platform also includes administrator verification, complaint management, account banning, and an OTP-based assignment workflow to improve trust and accountability.

1. Customer registration and login
   A customer first creates an account or logs in through the WorkForce frontend. Firebase Authentication handles user authentication, while the backend verifies the authenticated identity and the user’s role before allowing protected operations. After logging in, the customer accesses the Customer Dashboard, where they can submit a new service request, review available workers, track existing requests, and view the status of assignments. Customers should only be able to access their own private requests and relevant assignment information.
2. Worker registration and profile creation
   A person who wants to provide services registers as a worker and creates a professional profile. The profile can contain their name, contact details, locality, skills, experience, service categories, and other supported information. During onboarding, the worker submits the required identity-verification document, such as an Aadhaar image if that collection method has been implemented and appropriately secured. The worker’s profile and verification status are stored in the backend, while sensitive identity documents must be kept in private storage with restricted access. After registration, the worker can access the Worker Dashboard, but registration alone does not make the worker eligible to accept assignments.
3. Administrator verification of workers
   The administrator is responsible for reviewing worker profiles before those workers become eligible for assignments. A worker awaiting approval should appear in the administrator’s pending-verification queue. The administrator reviews the available profile details, skills, locality, and securely accessible verification document, then approves the worker, rejects the application, or requests resubmission. The backend records the decision and updates the canonical verification status. Only when the worker has an approved status should the backend permit the worker to accept eligible assignments. This is the process that should resolve the earlier error: “This worker has not yet completed administrator verification.” The error will disappear only when the administrator approval action updates the same verification field that the assignment or OTP endpoint checks.
4. Customer submits a service request
   When a customer experiences a problem, they open the service-request form and enter details such as the problem title, service category, description, locality, city, state, urgency, and optional preferred schedule. For example, the customer might report that a ceiling fan hums when switched on but its blades do not rotate. The customer may also upload a photograph of the problem if image upload is enabled. The frontend validates the input and sends it to the backend. The backend validates the data again and stores the request in Firestore with its initial status. Optional values, such as a preferred time that the customer has left blank, must be omitted or handled safely rather than saved as JavaScript undefined, which caused the earlier Firestore error.
5. AI-based problem analysis using Gemma
   After the request is created, WorkForce can send the problem description and, when supported, the uploaded image to the configured Gemma model through the backend. The AI analyzes the information and may suggest possible causes, the skills required to investigate the issue, the severity of the problem, and safe preliminary checks. For instance, a fan that hums without rotating might need inspection of its capacitor, motor, or mechanical components. This is an initial assessment, not a confirmed diagnosis. The AI should communicate uncertainty and recommend a qualified professional when appropriate, particularly for electrical, gas, or structural hazards. The Google AI API key remains on the backend and must never be exposed in the frontend.
   If AI analysis fails because of an invalid API key, unsupported model, network error, or other upstream problem, the already-created service request should remain saved. The interface should explain that the diagnostic could not be completed and allow the customer to retry without creating duplicate requests. AI analysis is an assisting feature; it must not determine administrator privileges, verify workers, authorize payments, or generate trusted assignment OTPs.
6. Worker matching and expression of interest
   Once a request is available, the system identifies workers who may be suitable for it. Matching can use the worker’s approved verification status, skills, service categories, locality, availability, and other supported criteria. The matching system should use actual worker profiles rather than fictional workers or AI-generated identities. Suitable workers can see eligible requests and express their interest in completing them. Expressing interest does not automatically assign the work; it indicates that the worker is willing to undertake the job. The backend should prevent banned, unverified, or otherwise ineligible workers from accepting work even if they attempt to bypass the frontend.
7. Customer reviews and selects a worker
   The customer can review the workers who have expressed interest and choose a suitable candidate. The information displayed should be based on real profile data, such as skills, experience, locality, verification status, and any legitimate pricing information available in the system. Once the customer selects a worker, the backend checks that the request is still available, the worker is approved and active, and the selection satisfies the assignment rules. If the worker is not verified, the platform should explain that administrator approval is still required. If the worker is banned or otherwise ineligible, the assignment must be blocked by the backend rather than merely disabled in the user interface.
8. Assignment and OTP generation
   After the customer selects an eligible worker, WorkForce initiates the assignment process. The backend generates an assignment OTP using a secure, server-side mechanism and associates it with the correct request and assignment. The OTP acts as a verification step in the workflow; it should not be generated or validated solely by frontend code. The system must check the assignment status and the eligibility of both parties before allowing the process to continue. The OTP must be protected against unauthorized access, brute-force attempts, and reuse, and it should expire according to the application’s configured rules. The exact moment at which the OTP is displayed or entered should follow the existing assignment design, but the customer and worker must not be able to manipulate the OTP or assignment status by directly editing frontend data.
9. Service progress and completion
   After the assignment is confirmed through the intended OTP flow, the customer and worker can follow the service request’s lifecycle. Depending on the states implemented in WorkForce, these may include submitted, awaiting worker selection, assigned, in progress, completed, or cancelled. The backend must validate each state transition so that a user cannot mark a job completed or assigned without meeting the required conditions. The customer should be able to see relevant progress updates, while the worker should see the work assigned to them. When the service is completed, the platform can record completion and collect feedback, provided those features are implemented and connected to the backend.
10. Cost estimation
    WorkForce can provide an approximate service-cost estimate based on the type of problem, its category, the expected skills, and the application’s configured sample rate cards. The estimate should be treated as guidance rather than a guaranteed final price because the actual repair cost may depend on inspection, parts, labour, and the worker’s legitimate rates. The backend should validate and calculate trusted cost values rather than blindly accepting numbers generated by Gemma or supplied by the browser. If the AI classification or rate-card data is missing, the application should handle the absence gracefully instead of writing undefined into Firestore or displaying a fabricated estimate.
11. Complaint submission by customers and workers
    Both customers and workers should be able to submit complaints when they encounter a problem with another participant. A complaint may concern misconduct, poor service, false information, inappropriate behaviour, or an assignment dispute. The complaint should identify the authenticated complainant, the reported account, the relevant service request or assignment when applicable, a category, a description, and optional supporting evidence. The backend should derive the complainant’s identity from the authenticated session instead of trusting a user ID supplied by the browser. Complaints and their evidence must be private, with access restricted to the parties and administrators who are authorized to see them. Users should not be able to read unrelated complaints or private administrator notes.
12. Administrator complaint review
    The administrator dashboard should provide separate complaint sections for reports against workers and reports against customers. Each entry should show the relevant account, complaint details, associated request, evidence available to the administrator, submission date, and review status. The administrator can investigate the complaint, move it into review, resolve it, or dismiss it with a recorded reason. Previous complaints can help the administrator understand repeated issues, provided the data is relevant and access is authorized. Every important decision should be recorded in an audit log with the administrator’s identity, timestamp, action, target account, and reason. This makes the complaint process more transparent and allows decisions to be reviewed later.
13. Banning and unbanning customers or workers
    If the administrator determines that an account violates WorkForce rules, they should be able to ban it from the account-management section. The administrator should provide a reason and confirm the action before the backend changes the account’s status. A banned worker must not accept new requests or receive new assignments, and a banned customer must not create new requests or proceed with new assignments. Unbanning should be an administrator-only action that restores the account’s eligible status without automatically approving a worker whose verification is still pending or rejected. The backend must enforce these restrictions across all relevant APIs, not just hide buttons in the dashboard. Existing assignments involving a banned account also need a defined policy so that work is not silently abandoned or left in an unsafe state.
14. Administrator login and security
    The administrator uses a protected admin login page, for example http://localhost:5173/admin during local development. The first administrator must be provisioned through a secure setup procedure that assigns the ADMIN role to a real authenticated account. The administrator then signs in with that account and is authorized to access the Admin Dashboard. Using an email address and a shared password alone must not allow an arbitrary person to become an administrator. Your requested initial password, #passAdmin321, should only be configured through a secure initial setup, and the administrator should be required to change it appropriately. Only an authenticated, authorized administrator should be permitted to change the administrator password. Customer and worker registration must never grant the administrator role, and backend APIs must verify administrator privileges before allowing verification decisions, bans, unbans, or other privileged actions.
15. Overall system architecture
    WorkForce uses a frontend for customer, worker, and administrator interfaces; a backend for business logic and authorization; Firebase Authentication for identity; Firestore for structured application records; private storage for identity documents and complaint evidence; and the configured Gemma integration for AI-assisted diagnostics. The frontend sends requests to the backend, the backend validates authentication and input, and trusted changes are saved to the appropriate data store. The AI service supplies diagnostic suggestions, while the backend remains responsible for security-sensitive decisions such as account roles, worker approval, assignment eligibility, OTP generation, and account bans. Automated tests and production builds help verify code correctness, but end-to-end testing is still required to prove that the real frontend, backend, Firebase, document storage, and Gemma service work together.