## Recommended tasks for the next sprint


* In the mobile applications, since the structure is now finalized (at least for the existing features), we need to **strictly follow best practices while coding**:
  * Break down large widgets into **smaller, reusable widgets**
  * Add **doc comments** where necessary to improve readability and maintainability
  * **Remove overly complicated or unnecessary logic** introduced by AI and simplify where possible
* Improvement points
- apps/mobile/packages/features/client/client_coverage/lib/src/data/repositories_impl/coverage_repository_impl.dart
  - Fix the location field in CoverageShiftRole to use the correct fallback logic.
  - line 125 remove redundant location values.

- Update the dataconnect docs.
- Track `lat` and `lng` in the staff preferred work locations (for now we are only storing the name).
- Change the name of the dataconnect connector replacing the "ExampleConnecter" with "KrowConnecter" 

- `  final String status;` in `OrderItem` make it an enum.
-  /// Date of the shift (ISO format).
  final String date; make this in the DateTime format instead of string.

- in `view_orders_cubit.dart` combine the logic of `_calculateUpNextCount ` and `_calculateTodayCount` into a single function that calculates both counts together to avoid redundant filtering of orders.
- In places api call in the when the api's not working we need to show a proper error message instead of just an empty list.
- pending should come first in the view order list.





- track minimum shift hours in the staff profile and show a warning if they try to apply for shifts that are below their minimum hours.
  - this need to be added in the BE and also a FE validation (5 hrs).

- Cannot cancel before 24 hours of the shift start time. If do we should charge for 4 hours of work for each shifts.

- verify the order creation process in the client app.
  - Vendor don't need to verify the order, when the order is created it should be automatically published.
  - rethink the order status, we need to simplify it.

- Validation layer
  - Profile info
  - emergency contact
  - experiences
  - attires
    - there should be manual verification by the client even if the ai verification is passed.
    - to track false positives and false negatives.
  - certifications
    - there should be manual verification by the client even if the ai verification is passed.
    - to track false positives and false negatives.
  - documents
  - tax forms

- How do we handle the current bank account verifcaiton in the current legacy application.
- We need have a show a list of clothing items in the staff app -> shift page.
- Template models for the pdf reports in the client and web apps.
- remove `any` type and replace it with the correct types in the codebase.