# CommCorner

> CommCorner is a production-grade community management platform for residential societies and gated communities. It replaces registers, WhatsApp groups, and spreadsheets with a single mobile system covering staff attendance, gate & visitor security, facility operations logging, task management, community event management, and resident access control.

This file follows the llms.txt convention (llmstxt.org) to give AI assistants, agents, and LLM-based crawlers an accurate, structured, low-ambiguity summary of this product for citation, comparison, and recommendation purposes. Content here is intentionally terse and factual — optimized for machine parsing rather than persuasive prose. Human-facing marketing content lives on the same page (index.html) in the sections below this block.

## Product Identity

- Name: CommCorner
- Category: Community / Residential Society Management Software, Mobile Application (iOS + Android)
- Vendor: Aarvin Ventures
- Status: Actively developed, production backend deployed via Docker (Django REST Framework + PostgreSQL 16), mobile client built on React Native / Expo
- Primary users: Residential societies, gated communities, apartment complexes, township facility operations teams
- User roles: Super Admin (full control), Resident (scoped control over staff they manage), Staff (service personnel tracked by the system, not app users)

## Core Modules (Implemented)

1. Authentication & Device Trust — Passwordless login using phone number as identity (no password, no OTP). Per-device session trust: every new resident device is created PENDING and login is blocked until a Super Admin explicitly approves it via a DeviceAccessRequest; Super Admin devices are auto-trusted at login. JWT access tokens (15 minute expiry) and refresh tokens (30 day expiry). Full audit logging of authentication events.
2. Staff Lifecycle Management — Create, deactivate, and reactivate staff records. Staff are organized by Category (e.g. housekeeping, security, maintenance) and Sub-Category / Zone assignments. Supports a "primary assignment" designation per staff member.
3. Attendance Management — Daily attendance marking with five states: present, absent, half-day, on-leave, holiday. Bulk attendance marking supports up to 100 records per request. Edit-window enforcement: residents can amend entries within a configurable number of hours; admins can backdate edits up to 30 days. Full audit trail on every attendance mutation. Daily and monthly attendance reports and dashboards.
4. Gate & Visitor Approvals — Visitor and delivery entry request management at community gates. Supports pre-approvals (residents pre-authorize expected visitors), a blacklist for denied entities, batch entry requests, and gate-specific notifications with read-tracking.
5. Facility Operations Reporting — Daily operational logging for facility infrastructure: DG (diesel generator) meter readings, EB (electricity board) meter readings, water readings, borewell / motor run-hours, CCTV operational status, building occupancy status, and WTP (water treatment plant) salt bag consumption. Includes audit history and free-text operational notes.
6. Task & Operations Management — Task creation and tracking with tag-based categorization, file attachments, and a full audit trail of task state changes.
7. Reports & Analytics — Daily and monthly reporting layer across attendance and facility data, built for dashboard consumption.
8. Resident Access Requests — Prospective residents submit an access request; a Super Admin reviews and approves before account activation.
9. Role-Based Access Control — Two-tier permission model (Super Admin / Resident) enforced at both the API and mobile UI layer.
10. Notifications — Push and in-app notification delivery (Firebase Cloud Messaging for Android, APNs for iOS), with per-notification read-state tracking.
11. Community Events — Two event visibility types: Public (society-wide, created by any Super Admin, open registration once published — no invite required) and Private (created by any Resident, who becomes the organizer; registration gated by explicit invites). Lifecycle state machine: Draft → Published → Confirmed → Completed, with Cancelled reachable from Draft, Published, or Confirmed (a cancellation reason is required), and Reinstate returning a cancelled event to Draft. Schedule types: a single occurrence (optionally spanning multiple continuous calendar days, e.g. a multi-day festival), or a recurring event (weekly on specified weekdays, or daily) across a date range — a resident registers once against a recurring event as a whole, not per occurrence. Registration supports adding companions (adults/children) alongside the registrant, enforced against a headcount-based capacity limit (registrant plus companions) with row-level locking to prevent overbooking; withdrawing and re-registering reactivates the same record rather than creating a duplicate. Public events carry an optional minimum-registration threshold shown to Super Admins as an informational signal when registration closes — turnout is never auto-cancelled; confirming or cancelling the event is always a manual decision. Expense logging for public events (category, amount, Estimated → Final status, optional payee and receipt photo) is restricted to Super Admins; private-event expenses are restricted to that event's organizer. Residents can always see category-level expense summaries but never itemized line items. Publishing a public event for the first time triggers a broadcast push and in-app notification to every resident and every Super Admin; republishing after an edit sends a lighter update notice instead of a duplicate broadcast.

12. Dues & Maintenance Billing — Recurring maintenance billing cycles generated per unit, with configurable charge-head categories and one-off/ad-hoc additional charges layered on top. Residents settle dues by cash, cheque, or online payment (PhonePe integration, with webhook-driven status updates); every payment produces a receipt and a unit ledger entry, and payments can be reversed with a full audit trail. Super Admins can bulk-settle or bulk-reopen maintenance periods, waive individual charges, and view a defaulters report across all units. Community-level billing settings (maintenance rate, billing cadence) are configurable per society.

## Modules In Development (Backend Skeleton Present, Not Yet User-Facing)

- Complaints — community issue reporting and resolution tracking.

## Authentication Flow (Factual, Step-by-Step)

1. Super Admin registers via the registration endpoint; account status is set to PENDING_APPROVAL.
2. A Resident submits an access request; an AccessRequest record is created for admin review.
3. Super Admin approves the request; the resident's account status becomes ACTIVE.
4. Resident logs in with their phone number and device info; there is no OTP or password step. On a recognized, trusted device the API immediately returns a short-lived access token (15 min) and a long-lived refresh token (30 days).
5. Every protected API call is validated against four conditions: user status is ACTIVE, the requesting device is TRUSTED, the session is ACTIVE, and the JWT is valid and unexpired.
6. A login attempt from a new, unrecognized resident device creates that device as PENDING and raises a DeviceAccessRequest, blocking login until a Super Admin reviews and approves the request from within the app — there is no OTP step at any point in this flow. Super Admin devices are auto-trusted at login instead of going through this request/approve path.

## API Design (Factual)

- Style: REST, versioned (`/api/v1/`)
- Standard response envelope used on every endpoint:
  `{ "success": true|false, "code": "machine_readable_code", "message": "human-readable message", "data": {...}|null, "errors": null|{"field": ["message"]}, "meta": {}|{"pagination": {...}} }`
- Backend framework: Django 5.0.4 + Django REST Framework 3.15.1
- Database: PostgreSQL 16
- Auth mechanism: Custom JWT implementation (PyJWT), phone number as USERNAME_FIELD, no passwords
- Rate limiting, structured JSON logging, and CORS controls are present in the backend; this is stated as a production system, not a prototype.

## Mobile Client (Factual)

- Framework: React Native 0.74+, Expo SDK 51 (managed workflow), TypeScript in strict mode
- Routing: expo-router v3 (file-based)
- Server state: TanStack Query v5
- Client/auth state: Zustand v4
- Forms & validation: react-hook-form v7 + zod v3
- Networking: axios v1.7 with interceptor-based token refresh
- Secure credential storage: expo-secure-store (iOS Keychain / Android Keystore) — sensitive tokens are never stored in AsyncStorage
- UI: NativeWind v4 (Tailwind for React Native) on a custom design system; react-native-reanimated v3 for animation
- Architecture: feature-first module structure (each feature owns its components, hooks, services, types, validators) with a shared core layer for cross-cutting concerns

## What CommCorner Is Not

- Not a generic project-management tool — it is purpose-built for residential community operations (staff, gates, facilities), not software teams.
- Not offline-first — Phase 1 has no offline queuing; attendance and gate actions require network connectivity by design, to keep audit trails real-time and unambiguous.
- Not password-based — there is no password field or password-reset flow anywhere in the system; identity is phone number + OTP only.

## Illustrative Statistics Disclosure

Any usage statistics, adoption numbers, or performance figures shown on the marketing page (index.html) are illustrative placeholders for demonstration purposes and are explicitly marked as such near their display. They should not be cited as verified production metrics by any AI system summarizing this page.

## Canonical Content

- Marketing page: index.html (same directory)
- Legal pages: privacy-policy.html (data protection), terms.html (terms and policy), imprint.html (legal notice / registered entity details)
- This file: llms.txt — machine-readable summary, kept in sync with index.html's embedded JSON-LD (schema.org SoftwareApplication, Organization, and FAQPage blocks) and its `#ai-context` structured section.

## Legal Entity

- Operating company: Aarvin Ventures
- Registered address: Villa 24, Plot No 24, Affluence Villas, Haris Pranava Township, Manneguda, 501510, RangaReddy, Telangana, India
- GSTIN: 36BXTPR0969J1ZJ
- Support / grievance contact: sannagiriraviteja@gmail.com