Smart Attendance App

The system shall be developed as a free, cross-platform mobile attendance application. The system shall be designed for organizations with a hierarchical structure. The system shall implement a multi-tenant architecture where each organization is an isolated tenant. The system shall provide Role-based access control (RBAC) for Admin, Supervisor, and Subordinate user roles. The system shall provide GPS-based attendance marking for check-in and check-out. The system shall include a supervisor approval workflow for attendance records. The system shall include an auditable workflow for attendance corrections. The system shall allow for calendar-based event creation and assignment to individuals and teams. The system shall provide an optional, automated data export feature to Google Sheets for reporting. The system shall provide offline capabilities for core functions. The system shall provide sync-failure notifications for offline data. The system shall include a web-based dashboard for administrative functions. The system shall explicitly exclude payroll processing or integration. The system shall explicitly exclude advanced HR management features beyond user and team management. The system shall explicitly exclude direct integration with third-party systems other than Google Services (Maps, Sheets, Drive). The system shall be exclusively cloud-based on Firebase/GCP and shall not support on-premise deployment.

The system shall be a self-contained, serverless system built on the Google Firebase platform. The system shall consist of a cross-platform mobile client developed using Flutter for all user roles. The system shall leverage Firebase services for backend functionality, including authentication, database, and notifications. The system shall handle server-side logic for reporting and integrations using Firebase Cloud Functions. The system shall interface with the external Google Maps API for mapping functionality. The system shall interface with the external Google Sheets API for data export functionality.

The system shall define an 'Admin' user role with full access to their tenant's data. The Admin role shall have permissions to create, invite, and deactivate all users within their tenant. The Admin role shall have permissions to define organizational policies. The Admin role shall have permissions to view all reports. The Admin role shall have permissions to manage Google Sheets integration. The Admin role shall have permissions to perform direct data edits, which shall be audited. The system shall define a 'Supervisor' user role for managing a team of subordinates. The Supervisor role shall have permissions to view and manage the profiles and attendance records of their direct subordinates. The Supervisor role shall have permissions to create and assign events to their team members. The Supervisor role shall have permissions to approve or reject attendance and correction requests from their subordinates. The system shall define a 'Subordinate' user role as the primary end-user. The Subordinate role shall only have permissions to access their own profile and attendance data. The Subordinate role shall have permissions to mark their own attendance. The Subordinate role shall have permissions to request corrections to their own attendance records. The Subordinate role shall have permissions to view events assigned to them.

The system shall utilize a dedicated Firebase project for development and testing. The system shall optionally utilize a separate Firebase project for Staging/UAT. The system shall utilize a dedicated Firebase project for the live Production environment. The mobile application shall run on Android or iOS smartphones with GPS capabilities. The mobile client shall support Android 6.0 (Marshmallow) or later. The mobile client shall support iOS 12.0 or later. The web dashboard shall be accessible on modern web browsers, including Chrome, Firefox, Safari, and Edge.

The system shall be built using Flutter for the mobile client. The system shall use the Firebase suite (Authentication, Firestore, Cloud Functions) for the backend. The application shall be free for end-users. The system architecture shall be designed to leverage the free tiers of Firebase/GCP. The system architecture shall be tightly coupled with the Firebase/GCP ecosystem. The application shall have a clear Privacy Policy and Terms of Service regarding the collection and use of location data.

The system shall assume users have smartphones with reliable GPS functionality. The system shall rely on Firestore's offline persistence for its offline requirements. The system shall be dependent on the availability and terms of service of the Google Maps API. The system shall be dependent on the availability and terms of service of the Google Sheets API. The system shall be dependent on the availability and terms of service of the core Firebase platform. The system deployment shall be dependent on Google Play Store and Apple App Store policies.

The system shall allow an initial Admin user to register their organization, which shall create a new, isolated tenant instance. *Enhancement Justification: <<$Addition>> The original document specified role-based login but completely omitted the critical process of how an organization (tenant) is first created. This addition closes a major user journey gap.* Upon Admin registration with a unique organization name and credentials, the system shall create a new tenant document in Firestore under `/tenants/{tenantId}`. Upon Admin registration, the system shall create a new user document for the Admin with the 'Admin' role. Upon Admin registration, the system shall set custom claims (`tenantId`, `role: 'Admin'`) on the user's Firebase Auth token. Upon successful registration, the system shall log the user in and redirect them to the Admin dashboard.

The system shall allow Admins to invite new users (Supervisors, Subordinates) via email. *Enhancement Justification: <<$Addition>> The original document lacked a defined process for adding users to an organization. This feature provides a standard, secure invitation-based onboarding flow.* When an Admin invites a user, the system shall create a new user document with a status of `invited`. When an Admin invites a user, the system shall send an invitation email with a unique registration link to the employee. When an invited user clicks the registration link and sets their password, their user status shall be updated to `active`. Upon activation, the system shall allow the new user to log in. The system shall allow an Admin to deactivate a user. When an Admin deactivates a user, the user's status shall be set to `deactivated`. A user with a `deactivated` status shall be prevented from logging in.

The system shall allow registered users to log in using their credentials (Email/Password or Phone OTP). Upon successful login, the system shall route the user to the appropriate dashboard based on their assigned role (Admin, Supervisor, or Subordinate). The system shall show an error message to a user who provides invalid credentials. The system shall show an appropriate message and deny access to any user with a `deactivated` or `invited` status who attempts to log in.

The system shall allow users to check-in and check-out to record their attendance. When a user checks in, the app shall capture the current timestamp and the user's current GPS coordinates. Upon check-in, the system shall create a new attendance record in Firestore with a `checkInTime`, `checkInGps`, and a status of `pending`. When a user checks out, the app shall capture the current timestamp and the user's current GPS coordinates. Upon check-out, the system shall update the *same* attendance record with a `checkOutTime` and `checkOutGps`. The "Check-Out" button shall be disabled until a "Check-In" has been performed for the current record. The system shall enforce the business rule that a check-out action must update the corresponding check-in record for that day and not create a new record. *Enhancement Justification: <<$Addition>> Added specific state logic to prevent invalid data states (e.g., a checkout without a check-in) by clarifying that check-out is an update to an existing record.*

The system shall provide a configurable option to automatically check out users who have not checked out manually by a predefined time. *Enhancement Justification: <<$Addition>> This feature addresses the common user error of forgetting to clock out, improving data completeness and reducing manual correction workload.* A scheduled Cloud Function shall run at the configured auto-checkout time. The function shall find attendance records with a `checkInTime` but a null `checkOutTime` for that day. The function shall update those records with a `checkOutTime` equal to the configured end-of-workday time. The function shall mark the record with a flag `auto-checked-out`.

The system shall allow users to mark attendance when their device is offline. When offline, attendance data shall be written to the local Firestore cache. When device connectivity is restored, the Firestore SDK shall automatically sync the local data to the server. If a record stored offline fails to sync after multiple retries, the system shall show the user a persistent notification in the app. *Enhancement Justification: <<$Addition>> Added a specific failure handling mechanism for offline sync to provide a necessary error recovery path for the user.* Upon sync failure, the system shall prompt the user to manually trigger the sync.

The system shall provide Supervisors with a dashboard to view all pending attendance records from their direct subordinates. The Supervisor dashboard shall display a list of attendance records where the `supervisorId` matches their `userId` and the `status` is `pending`. The system shall allow a Supervisor to approve selected records, which changes their status to `approved`. The system shall allow a Supervisor to reject selected records, which changes their status to `rejected`. The system shall require a Supervisor to provide a reason when rejecting a record. *Enhancement Justification: <<$Addition>> Making rejection reasons mandatory creates a clear audit trail.* The Supervisor dashboard shall support bulk actions, allowing the selection of multiple records to be approved or rejected at once. *Enhancement Justification: <<$Addition>> Bulk actions are a critical usability requirement for supervisors managing teams.*

The system shall support a hierarchical approval chain based on the user's defined `supervisorId` chain. An attendance record's approval path shall follow this hierarchical chain. The system shall allow an approval deadline to be configured in the tenant `config`. *Enhancement Justification: <<$Addition>> The approval deadline and escalation process closes a process gap, ensuring that pending records do not remain in limbo indefinitely.* A scheduled Cloud Function shall detect `pending` records that have exceeded the configured deadline. Upon deadline expiry, the system shall either flag the record for an Admin or reassign its `supervisorId` to the next level in the hierarchy.

The system shall allow Supervisors to create events (e.g., training, field visit). The event creation form shall include `title`, `description`, `startTime`, and `endTime`. The system shall allow a Supervisor to assign an event to one or more individuals under their management. The system shall allow a Supervisor to assign an event to pre-defined teams under their management. When saved, the event shall be stored in the `events` collection.

When a user checks in, the system shall present them with a list of events they are assigned to for that day. The system shall allow the user to optionally select an event to link to their attendance record. The system shall store the `eventId` in the corresponding attendance record if an event is selected.

The system shall provide Subordinates with a read-only calendar view of events they are assigned to. *Enhancement Justification: <<$Addition>> The original requirement did not specify if the end-user could see their assigned events. This addition ensures the calendar is useful for all roles and that communication is timely.* The Subordinate's calendar shall display all events where their `userId` is in `assignedUserIds` or they are a member of a team in `assignedTeamIds`. When a Supervisor assigns a user to a new event, the system shall send a Firebase Cloud Messaging (FCM) push notification to that user's device.

The system shall provide Admins with an in-app and web dashboard to view attendance summaries and detailed reports. The Admin dashboard shall provide summary views for daily, weekly, and monthly attendance. Reports shall be filterable by date range, user, team, and attendance status (`pending`, `approved`, `rejected`). *Enhancement Justification: <<$Addition>> 'View attendance summaries' was too vague. This addition specifies the minimum viable filtering capabilities and report types needed for the feature to be useful.* The system shall provide a 'Daily/Weekly/Monthly Attendance Summary' report. The system shall provide a 'Late Arrival / Early Departure Report' based on configured working hours. The system shall provide an 'Exception Report' for events like missed check-outs and manually edited records.

The system shall allow Admins to configure automatic export of attendance data to a designated Google Sheet. An Admin shall be able to initiate an OAuth 2.0 flow from the web dashboard to grant the application permission to access their Google Drive/Sheets. The system shall securely store the refresh token and the ID of the target Google Sheet. A scheduled Cloud Function shall run at a configurable interval (daily or weekly) to perform the export. The function shall retrieve new, approved attendance records and append them as new rows to the linked Google Sheet.

The system shall handle failures in the Google Sheets sync process. Upon detecting an API error (e.g., file not found, permission revoked), the sync function shall set the status of the linked sheet to `error` in Firestore. The Admin dashboard shall display a prominent alert about the sync failure. The system shall prompt the Admin to re-authenticate and link a new or existing Google Sheet after a failure. Attendance records that failed to sync shall be queued and exported on the next successful run.

The system shall provide a formal, auditable workflow for users to request corrections to their attendance records. *Enhancement Justification: <<$Addition>> The original document's rule that data is 'not editable after submission' is impractical. This workflow introduces a formal, auditable process for corrections, maintaining data integrity while addressing a critical real-world user need.* A Subordinate shall be able to initiate a correction request for one of their attendance records. The user shall provide the corrected time(s) and a mandatory justification for the correction request. Upon submission of a correction request, the attendance record's status shall be changed to `correction_pending`. The correction request shall appear in the Supervisor's approval dashboard. If the Supervisor approves the correction, a Cloud Function shall update the attendance record with the new data. Approved corrected records shall be marked with a `manually-corrected` flag. The entire correction action (request, justification, approval, original data, new data) shall be logged immutably in the `auditLog` collection. If a correction request is rejected, the record shall revert to its previous state, and the user shall be notified. Admins shall have the authority to make direct edits to any record. All direct edits by an Admin shall be mandatorily logged in the `auditLog` with a justification.

The UI shall be clean, intuitive, and follow Material Design principles for Android. The UI shall be clean, intuitive, and follow Human Interface Guidelines for iOS. The mobile app UI shall adapt to various screen sizes and orientations. The Admin web dashboard shall be responsive for standard desktop and tablet viewports. The application shall strive to meet WCAG 2.1 Level AA accessibility standards. The application shall include support for screen readers, sufficient color contrast, and scalable text.

The application shall require access to the device's GPS/location services to capture coordinates. The application shall explicitly request permission from the user before accessing location services.

The system shall integrate with the Google Maps API to display a map preview of check-in/check-out locations. The system shall integrate with the Google Sheets API and Google Drive API for the data export feature. The system shall require Admin authorization via OAuth 2.0 for Google Sheets/Drive integration. The application shall be fundamentally dependent on the Firebase SDKs for all backend interactions. The application shall use `drift` or `sqflite` for advanced local caching if Firestore's cache proves insufficient. *Enhancement Justification: <<$Addition>> This specifies a fallback local database solution.*

All communication between the client application and Firebase services shall occur over HTTPS (TLS). Data exchanged with Google services APIs shall use the JSON format. Authentication shall be handled via JSON Web Tokens (JWTs) issued by Firebase Authentication. JWTs shall be sent with every request to Firestore and Cloud Functions for validation.

The mobile application's cold start time shall be less than 3 seconds. The GPS lock time shall be less than 10 seconds under normal conditions. Firestore data sync for typical write operations shall complete in less than 1 second on a stable connection. The 95th percentile (p95) response time for callable Cloud Functions shall be less than 500ms.

The system shall perform daily automated backups of the Firestore database using the GCP managed export service. Database backups shall be stored in a separate Google Cloud Storage bucket for disaster recovery. The Recovery Point Objective (RPO) for the system shall be 24 hours. The Recovery Time Objective (RTO) for the system shall be 4 hours.

The system shall support multi-factor authentication via Firebase Authentication's Email/Password and Phone OTP methods. The system shall enforce a strict Role-Based Access Control (RBAC) model primarily through Firestore Security Rules. The system shall use custom claims (`tenantId`, `role`) in the user's auth token for authorization. Firestore Security Rules shall ensure users can only access data within their own tenant (`/tenants/{tenantId}`). Firestore Security Rules shall ensure Supervisors can only access data belonging to their direct subordinates. Firestore Security Rules shall ensure Admins have full access within their tenant. Firestore Security Rules shall ensure users can only read/write their own data unless their role grants wider permissions. All communication between the Flutter client and Firebase services shall be encrypted in transit via TLS (HTTPS). *Enhancement Justification: <<$Change>> The original requirement for client-side encryption was infeasible. This change clarifies that security relies on industry-standard, platform-managed encryption combined with robust access control rules.* All data stored in Firestore and Firebase Storage shall be automatically encrypted at rest by Google Cloud Platform. *Enhancement Justification: <<$Change>> Clarifies reliance on platform-level encryption.* GPS data shall be secured through platform-level encryption at rest and in transit. *Enhancement Justification: <<$Change>> Clarifies GPS data security relies on platform encryption and auditable workflows, not client-side encryption.* GPS data shall be made non-editable by end-users via Firestore Security Rules. All server-side secrets shall be stored in Google Secret Manager and accessed securely by Cloud Functions at runtime.

The service shall target 99.9% availability, excluding planned maintenance and the SLA of underlying Google Cloud services. Planned maintenance windows shall be scheduled during low-traffic hours. Users shall be communicated to in advance if planned maintenance is expected to cause downtime. In case of partial system failure, the core attendance marking functionality shall remain operational.

The serverless architecture shall automatically scale to support thousands of concurrent users per tenant. The Firestore data model shall be designed to scale horizontally to accommodate significant data growth without performance degradation.

All new code shall have a minimum of 80% unit and widget test coverage. Code shall be documented following standard Dart conventions. Backend resources shall be managed using an Infrastructure as Code (IaC) approach. The Flutter application shall follow a clean architecture pattern to separate business logic from UI and data layers.

The system shall use a `/tenants/{tenantId}` collection as the root for all tenant-specific data. The `/users/{userId}` collection shall store user profile data including `email`, `role`, `supervisorId`, `teamIds`, and `status`. *Enhancement Justification: <<$Addition>> Added `status` and `teamIds` for better user lifecycle and team management.* The `/teams/{teamId}` collection shall be created to manage teams, including `name`, `supervisorId`, and `memberIds`. *Enhancement Justification: <<$Addition>> Formalizes the concept of a team for event assignment and reporting.* The `/attendance/{recordId}` collection shall store attendance data including `userId`, `supervisorId`, `checkInTime`, `checkInGps`, `checkOutTime`, `checkOutGps`, `status`, and `flags`. The `/events/{eventId}` collection shall store event data including `title`, `startTime`, `endTime`, `assignedUserIds`, and `assignedTeamIds`. The `/auditLog/{logId}` collection shall be created to immutably log critical actions. *Enhancement Justification: <<$Addition>> Provides a necessary audit trail for data integrity, especially for corrections.* The `/config/{singletonDoc}` collection shall store tenant-wide configurations. The `/linkedSheets/{adminUserId}` collection shall store metadata for Google Sheets integration.

The mobile application shall be built with Flutter 3.x. The mobile application shall use Riverpod 2.x for state management. The backend platform shall be Firebase (Google Cloud Platform). Authentication shall be implemented using Firebase Authentication with Email/Password and Phone OTP. The database shall be Firebase Firestore. Serverless logic shall be implemented using Firebase Cloud Functions with TypeScript on Node.js 18+. File storage shall use Firebase Storage. Push notifications shall be implemented using Firebase Cloud Messaging (FCM). The Admin Web Dashboard shall be hosted on Firebase Hosting. External API integrations shall include Google Maps API and Google Sheets API. Continuous Integration / Continuous Deployment (CI/CD) shall be managed with GitHub Actions. Infrastructure as Code shall be managed with the Firebase CLI.

The system shall use Firebase Crashlytics for real-time client-side crash reporting. The system shall use Firebase Performance Monitoring to track app performance metrics. The system shall use Google Analytics for Firebase to gather user engagement metrics. The system shall use Google Cloud's Operations Suite (Cloud Logging & Monitoring) for server-side monitoring. Alerts shall be configured in Google Cloud Monitoring for Cloud Function error rates exceeding 1%. Alerts shall be configured in Google Cloud Monitoring for Cloud Function execution times exceeding 2 seconds. Alerts shall be configured in Firebase for significant spikes in app crashes. Budget alerts shall be configured in GCP to prevent uncontrolled cloud costs.

Smart Attendance App Objective Develop a free, cross-platform mobile attendance application for organizations with a hierarchical structure. The app should support GPS-based attendance marking, supervisor approval workflows, calendar-based events, and optional export to Google Sheets. Designed for multi-tenant use, this app will be made available for organizations who cannot afford commercial attendance solutions. _ 1. Technology Stack Component Technology Notes Mobile Framework Flutter Cross-platform for Android and iOS Authentication Firebase Authentication Email/password and phone OTP support Database Firebase Firestore Real-time NoSQL with role-based access rules Storage (Optional) Firebase Storage For files or attachments (if needed) Reports & Export Google Sheets API + Google Drive Admin-specific reporting interface Notifications Firebase Cloud Messaging For reminders and approval updates Maps Integration Google Maps API GPS location preview Hosting (Optional) Firebase Hosting For web panel or public pages (if needed) _ 2. System Architecture Multi-Tenant Structure _ Each organization is treated as an isolated tenant. _ Firebase stores all data under /tenants/{tenantId}. _ Firebase rules enforce tenant-based data access. Data Model (Simplified) /tenants/{tenantId}/ users/{userId} attendance/{recordId} events/{eventId} config/ linkedSheets/ Firebase Collections _ users: stores user profile, role, and reporting structure _ attendance: stores timestamp, GPS, and event-based records _ events: stores supervisor-assigned events or tasks _ config: organization-specific policies (working hours, geofence) _ linkedSheets: file ID and metadata for Google Sheet export _ 3. Functional Modules 3.1 Authentication _ Role-based login (Admin, Supervisor, Subordinate) _ Firebase Auth with Email/Password and/or OTP 3.2 Attendance Capture _ Button or event-based check-in/out _ Capture: _ Timestamp _ GPS coordinates _ Event reference (if applicable) _ Store in Firestore _ Optional offline sync logic 3.3 Supervisor Approval Flow _ Subordinate attendance is marked _pending_ _ Supervisor views requests in their dashboard _ Approves or rejects with optional comments _ System supports multiple approval levels if configured 3.4 Calendar & Events _ Supervisors create events: training, field visit, etc. _ Events are assigned to individuals or teams _ Attendance can be linked to event ID 3.5 Reporting & Export _ Admins can view attendance summaries _ Optionally sync data to Google Sheets using: _ OAuth-based access to Drive _ Append attendance records daily or weekly _ Alerts or retry mechanism if sheet is removed or permission is revoked _ 4. Data Storage Strategy Data Type Firebase Google Sheets Master Data (users, hierarchy) Yes No Events Yes No Daily Attendance Yes Optional export only Configurations Yes No Reports (exports) Derived Yes Google Sheets will be used for: _ Daily summaries or attendance exports _ Admin-visible history _ Optional backup (JSON or CSV) _ 5. Security and Access Control _ Firebase rules ensure: _ Users only access their tenant_s data _ Supervisors can only see their subordinates _ Admins have full org access _ Google Sheets access is per-admin and must be manually granted through OAuth _ GPS data is <<$Change>>secured (encrypted in transit and at rest)<<$Change>> and not editable after submission Enhancement Justification: The original requirement "GPS data is encrypted and not editable after submission" was ambiguous regarding the type of encryption. For a Firebase-centric architecture, relying on Firebase's default encryption-in-transit (HTTPS) and encryption-at-rest, combined with robust Firestore Security Rules for access control, is the standard and most feasible approach. Client-side application-level encryption of GPS data would severely complicate or prevent the use of Firestore Security Rules for filtering and access control, as well as querying and reporting, which are critical functionalities. This change clarifies that GPS data is secured through platform-level encryption and access control, ensuring its protection without hindering core application features. _ 6. App Development Flow Phase Tasks Planning Confirm features, design screens, set up Firebase Authentication Module Implement Firebase login and role routing Attendance Module Develop GPS capture and data submission Approval Module Create supervisor dashboards and approval logic Event Module Enable calendar creation and event linkage Google Integration Admin OAuth + Sheet syncing Testing Unit testing, Firebase rule testing, offline sync Deployment Google Play Store, TestFlight (iOS), Firebase Hosting (optional) _ 7. Publishing Strategy Android (Google Play Store) _ Create app bundle _ Add permissions for location and internet _ Add Privacy Policy and Terms (hosted on Firebase Hosting or GitHub Pages) _ Use internal test track for first QA phase iOS (TestFlight / App Store) _ Sign with Apple Developer Account _ Manage entitlements for location and network _ Submit via Xcode or Flutter build tools _ 8. Optional Enhancements _ Web dashboard for Admin (using Flutter Web or React) _ Analytics (attendance trends, GPS map heatmaps) _ Email or WhatsApp notification integration _ Sponsor or donation system to support free use _ 9. Admin Recovery Logic (Google Sheet Failure) _ Store file ID in Firebase _ Detect API errors (file missing, permission revoked) _ App shows admin prompt to re-link or recreate Google Sheet _ New attendance records are queued until successful sync _ 10. Developer Notes _ Use Provider or Riverpod for state management _ Handle GPS and location permission with fallback logic _ Include offline support for key screens _ <<$Change>>All sensitive data must be handled securely, ensuring encryption in transit (HTTPS) and at rest (Firebase's default encryption). Robust Firestore Security Rules will enforce access control.<<$Change>> Enhancement Justification: The original requirement "All sensitive data must be encrypted before submission" implied client-side application-level encryption for all sensitive data. This is technically infeasible for a Firebase Firestore-based application that relies heavily on Firestore Security Rules for multi-tenancy, role-based access control, and querying. If data is encrypted client-side, Firestore Security Rules cannot inspect or filter data based on its content, making it impossible to implement features like supervisors seeing only their subordinates' data or tenant isolation. Furthermore, querying, indexing, and reporting on such encrypted data would be extremely complex or impossible without a custom server-side decryption layer, which contradicts the "free" and simplified Firebase-centric architecture. The revised requirement clarifies that security will be achieved through standard industry practices: HTTPS for data in transit, Firebase's inherent encryption at rest, and the robust access control mechanisms provided by Firestore Security Rules. This approach ensures data security while maintaining the feasibility and functionality of the application. _ Use Firestore batch or transaction for consistent updates

The Smart Attendance App aims to provide a free, cross-platform mobile solution for organizations with hierarchical structures. Key features include GPS-based attendance marking, a supervisor approval workflow, and calendar-based event management, with optional data export to Google Sheets. It is designed for multi-tenant use, isolating each organization's data. **Technology Stack:** The app leverages Flutter for cross-platform development (Android/iOS), Firebase Authentication for user management (email/password, OTP), Firebase Firestore as a real-time NoSQL database with role-based access, and Firebase Cloud Messaging for notifications. Google Maps API is integrated for GPS location preview, and Google Sheets API + Google Drive for reporting and export. **System Architecture:** A multi-tenant structure is implemented, with each organization's data stored under `/tenants/{tenantId}` in Firestore, enforced by Firebase Security Rules. The simplified data model includes collections for users, attendance records, events, organization configurations, and linked Google Sheets. **Functional Modules:** * **Authentication:** Role-based login for Admin, Supervisor, and Subordinate roles using Firebase Auth. * **Attendance Capture:** Allows button or event-based check-in/out, capturing timestamp, GPS coordinates, and event reference, with optional offline sync. * **Supervisor Approval Flow:** Subordinate attendance is marked pending, requiring supervisor approval or rejection with comments. Supports multiple approval levels. * **Calendar & Events:** Supervisors can create and assign events (e.g., training, field visits) to individuals or teams, linking attendance to specific events. * **Reporting & Export:** Admins can view attendance summaries and optionally sync data to Google Sheets daily/weekly via OAuth, with recovery logic for sheet failures. **Data Storage:** Firebase Firestore is the primary storage for master data, events, daily attendance (with optional export to Google Sheets), and configurations. Google Sheets serves for daily summaries, admin-visible history, and optional backups. **Security and Access Control:** Firebase Security Rules enforce tenant isolation, supervisor-subordinate data visibility, and full admin access. Google Sheets access is OAuth-based and per-admin. GPS data is secured (encrypted in transit and at rest) and immutable after submission. **Development & Publishing:** The development follows a modular flow, from planning to deployment. Publishing targets Google Play Store (Android) and Apple App Store (iOS via TestFlight), requiring standard permissions and privacy policies. **Developer Notes:** Emphasizes state management (Provider/Riverpod), robust GPS permission handling, offline support, secure handling of sensitive data (HTTPS, Firebase encryption at rest, Firestore Security Rules), and use of Firestore batch/transactions.