System Requirements Document for mygate-com

1. Introduction

mygate-com is a working community-management web application for gated residential societies, modelled on the MyGate-style product category: residents pre-approve and track visitors at the gate, security guards verify visitors and keep the gate log, residents raise complaints that community admins review and resolve, admins publish notices that residents read, and residents view their dues while admins track dues collection across the community. The product serves three human roles — Resident, Security Guard, and Community Admin / Management Committee — each with a role-appropriate account and a role-scoped working area.

The requester asked for a directly working build rather than a planning artefact; this document records the requirements that build must satisfy. The audience is neighbours, gate staff, and committee volunteers in Indian residential communities, not enterprise IT teams, and the product's tone and interface reflect that.

2. System Overview

mygate-com is delivered as a first-party web application with application-owned identity. Three runnable services make up the current system:

• frontend — the React application UI that renders the Landing, Login, Sign Up, Gate Requests, Gate Log, Complaints, Complaint Management, Notices, Notice Management, Dues, and Dues Collection pages.
• backend — a shared FastAPI process that exposes the application APIs and domain modules for identity, gate requests and gate log, complaints, notices, and dues.
• database — MariaDB holding application-owned persistent data: accounts and roles, gate requests and gate-log entries, complaints and their status history, notices, and dues records.

The frontend calls the backend over HTTP; the backend reads and writes MariaDB. No other services are required for the current scope.

Actors. The active human personas are Resident, Security Guard, and Community Admin / Management Committee. All three are first-party application users with self-service accounts. There are no system, provider, or external actors in the current scope.

Accepted behavior. Self-service sign-up with role selection, returning login, and role-appropriate scoping; resident visitor gate requests with status tracking; guard lookup of gate requests and recording of entry and exit in the gate log; resident complaint submission and status tracking; admin complaint review and resolution; admin notice publishing and resident notice reading; resident dues viewing and admin dues-collection tracking.

Exclusions. The current scope is limited to the eleven pages and the workflows above. It does not include amenity or clubhouse booking, accounting/ERP functions, polls and discussions, classifieds, AI-assisted policy answers, e-Intercom calling, payment gateway integration, or automated escalation matrices.

Removed from scope

• Amenities / Clubhouse Booking (also: Clubhouse, slot-based booking, blackout blocking)
• Accounting & Financial Management (also: ERP, GST control, trial balance, journal vouchers, TDS/GST reports, Tally exports)
• Polls & Discussions (also: classifieds, AGM invites, resident forums)
• Ask Society (MIRA) (also: AI-assisted policy answers)
• e-Intercom (also: fallback calling)
• Payment gateway settlement (also: UPI, PayU, RazorPay, net banking, e-wallets, foreign cards)
• Automated escalation matrix (also: Helpdesk Manager → Facility Manager → Admin escalation)
• Dues Lock on visitor access (also: outstanding-dues visitor blocking)

2a. Product Interpretation and Delivery Boundary

mygate-com is a first-party application: the community app itself owns the accounts, the gate workflow, the complaint workflow, the notice board, and the dues records. Nothing in the current scope is delegated to a provider surface or an external destination, and nothing is delivered headlessly.

Access is split into two boundaries. The Landing page is anonymously reachable and explains the product to visitors who have not signed in. Login and Sign Up are also anonymously reachable, because a protected destination cannot own the interaction that establishes access to itself. Every other page — Gate Requests, Gate Log, Complaints, Complaint Management, Notices, Notice Management, Dues, and Dues Collection — requires sign-in and the appropriate role, and is scoped so each role sees only its own areas.

Identity is application-owned and established self-service: a person chooses Resident, Security Guard, or Community Admin / Management Committee at sign-up, and returning users verify at Login. Identity provides role-appropriate scoping of the working areas; it does not introduce any finer-grained permission model beyond the three roles.

The current delivery horizon covers the eleven pages and the workflows described in this document. Amenity booking, accounting/ERP, community discussion features, AI-assisted policy answers, e-Intercom fallback calling, payment-gateway settlement, automated escalation, and dues-based visitor blocking are outside the current horizon and are not part of any current page.

2c. Page Content and Component Coverage

Landing

• Information/state: Public entry surface for anonymous visitors. Presents the product's purpose — a community app for residents, guards, and committee admins — and the three role families with a one-line job each: Resident ("Approve visitors from the sofa"), Guard ("Log every entry at the gate"), Admin ("Close complaints and collect dues").
• Primary actions: "Get started" (terracotta pill) leading to Sign Up; "I already have an account" text link leading to Login.
• Supporting actions: None beyond navigation into the two identity surfaces.
• Domain entities: None persisted; role descriptions only.
• Component responsibilities: Asymmetric hero (oversized headline left, rotated stack of three illustrated role cards right, joined by a dotted path); colour-blocked feature bands introducing Visitor Management (terracotta), Helpdesk (teal), and Dues (butter); shared footer.
• States: Static content; no loading, empty, or error states. Success is a visitor choosing Get started or Login.

Login

• Information/state: Returning verification for all three roles. Anonymous access.
• Primary actions: Submit credentials to sign in.
• Supporting actions: Navigate to Sign Up if the person has no account.
• Domain entities: Account (email/identifier, password, role).
• Component responsibilities: Credential form, submit control, inline validation, link to Sign Up.
• States: Loading during verification; error on invalid credentials with a recovery path back to the form; success routes the person to their role-appropriate area.

Sign Up

• Information/state: Self-service enrollment. Anonymous access.
• Primary actions: Choose role (Resident, Security Guard, or Community Admin / Management Committee), provide account details, and create the account.
• Supporting actions: Navigate to Login if an account already exists.
• Domain entities: Account with selected role.
• Component responsibilities: Role selector, account-detail fields, submit control, inline validation, link to Login.
• States: Loading during creation; error on invalid or duplicate account details with a recovery path; success establishes the session and routes to the role-appropriate area.

Gate Requests

• Information/state: Resident-owned, role-restricted. Lists the resident's visitor gate requests with their current status (e.g. pending, approved, denied, entered, exited) and any passcode issued for an approved visitor.
• Primary actions: Create a new visitor gate request (visitor name and visit details) and track its status.
• Supporting actions: Review the status of existing requests; view the passcode for an approved request.
• Domain entities: Gate request (resident, visitor details, status, passcode, timestamps).
• Component responsibilities: Request-creation form, request list with sticker-style status chips, passcode display.
• States: Loading while requests are fetched; empty state when the resident has no requests; success confirmation on creation; error on submission failure with retry; status updates reflected as the guard acts.

Gate Log

• Information/state: Guard-owned, role-restricted. Shows visitor gate requests the guard can look up, and the gate log of recorded entries and exits.
• Primary actions: Look up a visitor's gate request and record entry or exit.
• Supporting actions: Review the gate log of recorded movements.
• Domain entities: Gate request, gate-log entry (visitor, resident, direction, timestamp).
• Component responsibilities: Lookup control, request detail with record-entry/record-exit controls, gate-log list.
• States: Loading during lookup; empty state when no matching request exists; success confirmation on recording; error on recording failure with retry.

Complaints

• Information/state: Resident-owned, role-restricted. Lists the resident's complaints with status (e.g. new, in progress, resolved) and details.
• Primary actions: Submit a complaint with a description.
• Supporting actions: Follow the status of existing complaints.
• Domain entities: Complaint (resident, description, status, timestamps).
• Component responsibilities: Complaint-submission form, complaint list with status chips.
• States: Loading while complaints are fetched; empty state when none exist; success confirmation on submission; error on submission failure with retry; status changes reflected after admin action.

Complaint Management

• Information/state: Admin-owned, role-restricted. Lists complaints raised by residents with their current status and details.
• Primary actions: Review a complaint and update its status to resolved.
• Supporting actions: Filter or scan the complaint list by status.
• Domain entities: Complaint, status history.
• Component responsibilities: Complaint list, complaint detail, status-update control.
• States: Loading while complaints are fetched; empty state when none are open; success confirmation on status update; error on update failure with retry.

Notices

• Information/state: Resident-facing, role-restricted. Lists notices published by the community admin, newest first, with title, body, and publish date.
• Primary actions: Read a notice.
• Supporting actions: Browse the notice list.
• Domain entities: Notice (title, body, author, publish date).
• Component responsibilities: Notice list, notice detail.
• States: Loading while notices are fetched; empty state when none are published; error on fetch failure with retry.

Notice Management

• Information/state: Admin-owned, role-restricted. Lists published notices and provides the publishing form.
• Primary actions: Publish a notice with a title and body.
• Supporting actions: Review previously published notices.
• Domain entities: Notice.
• Component responsibilities: Notice-composition form, publish control, published-notice list.
• States: Loading while notices are fetched; empty state when none are published; success confirmation on publish; error on publish failure with retry.

Dues

• Information/state: Resident-owned, role-restricted. Shows the resident's dues with amount and payment status.
• Primary actions: View dues and their payment status.
• Supporting actions: Review the dues record.
• Domain entities: Dues record (resident, amount, status).
• Component responsibilities: Dues summary with status chips, dues detail.
• States: Loading while dues are fetched; empty state when no dues are recorded; error on fetch failure with retry.

Dues Collection

• Information/state: Admin-owned, role-restricted. Shows dues collection status across residents.
• Primary actions: View dues status across residents.
• Supporting actions: Scan the collection list.
• Domain entities: Dues record, resident.
• Component responsibilities: Collection list with per-resident status chips.
• States: Loading while records are fetched; empty state when no dues are recorded; error on fetch failure with retry.

3. Functional Requirements

FR-1 — Working community app. As a user of mygate-com I should have a working community-management application covering the gate, complaint, notice, and dues workflows so that the community's day-to-day operations run in one place. (explicit)

• Lifecycle: the application is reachable at the Landing page; each role signs in and reaches its role-scoped area; each workflow produces an observable state change persisted in the database.
• Acceptance: all eleven pages render and every workflow below completes end to end.

FR-2 — Self-service sign-up with role selection. As an anonymous visitor I should be able to create an account by choosing Resident, Security Guard, or Community Admin / Management Committee and providing my account details, so that I can enter the area appropriate to my role. (required_inference)

• Trigger/input: submission of the Sign Up form with a selected role and valid account details.
• Observable result: an account is created with the chosen role, a session is established, and I am routed to my role-appropriate area.
• Failure/recovery: invalid or duplicate details show an inline error and keep the form available for correction.
• Continuation: I can proceed directly into my role's area.

FR-3 — Returning login verification. As a returning user I should sign in with my credentials before accessing any protected area, so that my role-scoped work is protected. (required_inference)

• Trigger/input: submission of the Login form.
• Observable result: a session is established and I am routed to my role-appropriate area.
• Failure/recovery: invalid credentials show an error and keep the form available; I can navigate to Sign Up if I have no account.
• Access: Login is anonymously reachable; every protected page redirects an unauthenticated visitor to Login.

FR-4 — Role-appropriate scoping. As a signed-in user I should see only the areas appropriate to my role, so that each role's work is separated. (required_inference)

• Observable result: a Resident reaches Gate Requests, Complaints, Notices, and Dues; a Security Guard reaches Gate Log; a Community Admin / Management Committee reaches Complaint Management, Notice Management, and Dues Collection.
• Access: each protected page requires sign-in and the appropriate role.

FR-5 — Resident creates a visitor gate request. As a Resident I should create a gate request for a visitor so that the guard can verify the visit at the gate. (explicit)

• Trigger/input: visitor name and visit details submitted from Gate Requests.
• Observable result: the request is stored with a pending status and appears in my request list.
• Failure/recovery: a failed submission shows an error and keeps my input available for retry.
• Continuation: I can track the request's status as the guard acts on it.

FR-6 — Resident views gate activity. As a Resident I should view the status of my gate requests, including any passcode issued for an approved visitor, so that I know whether my visitor may enter. (explicit)

• Observable result: my request list shows each request's current status and, where issued, its passcode.
• Empty state: a clear message when I have no requests.

FR-7 — Guard verifies visitors at the gate. As a Security Guard I should look up a visitor's gate request so that I can verify the visit before allowing entry. (explicit)

• Trigger/input: a lookup from Gate Log.
• Observable result: the matching request's details are shown for verification.
• Failure/recovery: no match shows an empty result and lets me retry the lookup.

FR-8 — Guard maintains the gate log. As a Security Guard I should record a visitor's entry and exit so that the gate log reflects every movement. (explicit)

• Trigger/input: record-entry or record-exit on a verified request.
• Observable result: a gate-log entry is stored with direction and timestamp, and the request's status reflects the movement.
• Failure/recovery: a failed recording shows an error and lets me retry.
• Continuation: the gate log lists the recorded movements.

FR-9 — Resident raises a complaint. As a Resident I should submit a complaint with a description so that the community admin can address the issue. (explicit)

• Trigger/input: a complaint description submitted from Complaints.
• Observable result: the complaint is stored with a new status and appears in my complaint list.
• Failure/recovery: a failed submission shows an error and keeps my input available for retry.

FR-10 — Resident follows complaint status. As a Resident I should follow the status of my complaints so that I know whether the issue is being handled or resolved. (explicit)

• Observable result: my complaint list shows each complaint's current status, updated after admin action.
• Empty state: a clear message when I have no complaints.

FR-11 — Admin manages and resolves complaints. As a Community Admin / Management Committee member I should review resident complaints and update their status to resolved so that issues are closed out. (explicit)

• Trigger/input: selecting a complaint in Complaint Management and updating its status.
• Observable result: the complaint's status changes and the resident sees the updated status.
• Failure/recovery: a failed update shows an error and lets me retry.
• Empty state: a clear message when no complaints are open.

FR-12 — Admin publishes notices. As a Community Admin / Management Committee member I should publish a notice with a title and body so that residents receive community information. (explicit)

• Trigger/input: a notice title and body submitted from Notice Management.
• Observable result: the notice is stored and appears in the published-notice list and on the residents' Notices page.
• Failure/recovery: a failed publish shows an error and keeps my draft available for retry.

FR-13 — Resident reads notices. As a Resident I should read notices published by the community admin so that I stay informed. (explicit)

• Observable result: the Notices page lists published notices newest first with title, body, and publish date.
• Empty state: a clear message when no notices are published.

FR-14 — Resident views dues. As a Resident I should view my dues and their payment status so that I know what I owe. (explicit)

• Observable result: the Dues page shows my dues with amount and status.
• Empty state: a clear message when no dues are recorded.

FR-15 — Admin tracks dues collection. As a Community Admin / Management Committee member I should view dues collection status across residents so that I can see what has been collected and what remains. (explicit)

• Observable result: the Dues Collection page lists residents' dues with per-resident status.
• Empty state: a clear message when no dues are recorded.

4. User Personas

Resident

Product context. A Resident lives in the gated community and uses mygate-com from a phone or laptop to handle the parts of community life that touch them personally: getting visitors through the gate, reporting problems, reading what the committee has announced, and knowing what they owe.

Primary goal. Get visitors through the gate without friction, get complaints tracked to resolution, and stay informed about notices and dues.

Distinct responsibilities. The Resident is the only role that creates visitor gate requests and the only role that submits complaints. The Resident is the originator of the gate request that the guard later verifies, and the originator of the complaint that the admin later resolves. The Resident also reads notices and views dues — both are read-only for this role.

Inputs and decisions. Visitor name and visit details when creating a gate request; a complaint description when raising an issue; the decision to check a request's status or passcode before a visitor arrives.

Interactions with other participants. The Resident's gate request is the object the Security Guard looks up and acts on at the gate; the Resident sees the resulting status. The Resident's complaint is the object the Community Admin reviews and resolves; the Resident sees the resolved status. The Resident reads notices the admin publishes and views dues the admin tracks.

Observable success. Gate requests show a clear status and passcode; complaints move from new to resolved; notices are readable; dues and their status are visible.

Security Guard

Product context. A Security Guard staffs the gate of the community and uses mygate-com at the gate to check incoming visitors against resident approvals and to record every movement.

Primary goal. Verify every visitor against a resident's gate request and capture every entry and exit in the gate log.

Distinct responsibilities. The Security Guard is the only role that looks up gate requests for verification and the only role that records entry and exit. The guard is the indispensable participant on the other side of the Resident's gate request: the request is not usable until the guard verifies it and records the movement.

Inputs and decisions. The visitor's identifying details for lookup; the decision to record entry or exit once the request is verified.

Interactions with other participants. The guard acts on gate requests the Resident created and produces the gate-log entries and status changes the Resident sees.

Observable success. Every lookup resolves to a request or a clear empty result; every movement is recorded in the gate log with direction and timestamp.

Community Admin / Management Committee

Product context. A Community Admin / Management Committee member volunteers to run the community's shared operations and uses mygate-com to close out resident complaints, publish notices, and see the state of dues collection.

Primary goal. Close complaints out, get notices to residents, and keep dues status visible.

Distinct responsibilities. The Community Admin is the only role that updates complaint status to resolved, the only role that publishes notices, and the only role that views dues collection across residents. The admin is the indispensable participant on the other side of the Resident's complaint and the source of the notices the Resident reads.

Inputs and decisions. The decision to resolve a complaint; the notice title and body to publish; the review of dues status across residents.

Interactions with other participants. The admin acts on complaints the Resident raised and produces the resolved status the Resident sees; the admin publishes notices the Resident reads; the admin views dues the Resident also views from their own side.

Observable success. Complaints reach resolved; notices appear on the residents' Notices page; dues collection status is visible across residents.

5. Core User Flows

Flow 1 — A new person creates an account and enters their role's area

1. The person opens the Landing page and reads the three role cards.
2. The person selects "Get started" and arrives at Sign Up.
3. The person chooses Resident, Security Guard, or Community Admin / Management Committee and provides their account details.
4. The person submits. On success, an account is created with the chosen role and a session is established; the person is routed to their role-appropriate area (Resident → Gate Requests; Security Guard → Gate Log; Community Admin → Complaint Management).
5. On failure (invalid or duplicate details), an inline error appears and the form remains available for correction.
6. Continuation: the person can begin their role's work immediately.

Flow 2 — A returning user signs in

1. The person opens Login, either directly or by following "I already have an account" from Landing, or by being redirected from a protected page.
2. The person submits their credentials.
3. On success, a session is established and the person is routed to their role-appropriate area.
4. On failure, an error appears and the form remains available; the person may navigate to Sign Up if they have no account.

Flow 3 — A Resident creates a gate request and tracks it

1. The signed-in Resident opens Gate Requests.
2. The Resident enters the visitor's name and visit details and submits.
3. On success, the request is stored with a pending status and appears in the Resident's request list.
4. On failure, an error appears and the Resident's input remains available for retry.
5. The Resident later returns to Gate Requests and sees the request's current status and, where issued, its passcode.
6. If the Resident has no requests, the page shows a clear empty message.

Flow 4 — A Security Guard verifies a visitor and records the movement

1. The signed-in Security Guard opens Gate Log.
2. The Guard looks up the visitor's gate request.
3. If a match is found, the request's details are shown for verification. If no match is found, an empty result is shown and the Guard can retry the lookup.
4. The Guard records entry on the verified request. A gate-log entry is stored with direction and timestamp, and the request's status reflects the movement; the Resident sees the updated status on Gate Requests.
5. When the visitor leaves, the Guard records exit, producing a further gate-log entry and status change.
6. On a failed recording, an error appears and the Guard can retry.
7. Continuation: the gate log lists the recorded movements.

Flow 5 — A Resident raises a complaint and follows it to resolution

1. The signed-in Resident opens Complaints and submits a complaint description.
2. On success, the complaint is stored with a new status and appears in the Resident's complaint list. On failure, an error appears and the input remains available for retry.
3. The Resident later returns to Complaints and sees the complaint's current status.
4. The Community Admin reviews the complaint in Complaint Management and updates its status to resolved (Flow 6).
5. The Resident sees the resolved status on Complaints.

Flow 6 — A Community Admin resolves a complaint

1. The signed-in Community Admin opens Complaint Management and sees the list of resident complaints with their statuses.
2. The Admin selects a complaint and reviews its details.
3. The Admin updates its status to resolved.
4. On success, the complaint's status changes and the Resident sees the updated status on Complaints. On failure, an error appears and the Admin can retry.
5. If no complaints are open, the page shows a clear empty message.

Flow 7 — A Community Admin publishes a notice and a Resident reads it

1. The signed-in Community Admin opens Notice Management and enters a notice title and body.
2. The Admin publishes. On success, the notice is stored and appears in the published-notice list and on the residents' Notices page. On failure, an error appears and the draft remains available for retry.
3. The signed-in Resident opens Notices and sees the published notices newest first with title, body, and publish date.
4. The Resident reads a notice.
5. If no notices are published, the Resident sees a clear empty message.

Flow 8 — A Resident views dues and a Community Admin tracks collection

1. The signed-in Resident opens Dues and sees their dues with amount and payment status; if none are recorded, a clear empty message is shown.
2. The signed-in Community Admin opens Dues Collection and sees dues status across residents; if none are recorded, a clear empty message is shown.

6. Visuals Colors and Theme

The muse is Pablo Stanley, and the headline is "Your society, running smoothly" — warm, human community software with modular illustration, big radii, and sunny primaries on cream.

Colour tokens (light mode).

Terracotta is the single hot action colour — gate approvals, pay dues, primary buttons — used on roughly 10% of surface. Teal is the secondary signal for resolved/inside/approved states and guard-side UI. Status chips use the pastel supports with ink text for contrast. No blue or indigo primary buttons anywhere.

Typography. Headings: Bricolage Grotesque at 700–800, tight tracking (-0.02em), sentence case. Body and UI: DM Sans at 400/500, 16–18px reading size, 1.55 line-height. Scale is 1.333 modular: 64/48/36/27/20/18/16/14. Hero display clamp(40px, 9vw, 96px); section headings clamp(28px, 4vw, 44px); card titles 20px; body 16px; labels 14px. Inter, Roboto, and system-ui are not used for headings or body.

Shape language. Big continuous radii — 24px cards, 999px pills for buttons and chips; sticker-like circular badges; soft offset shadows 0 6px 0 rgba(31,42,68,0.08) instead of blur glows; hand-drawn underline squiggles beneath key words; modular character illustrations built from simple geometric primitives. No sharp corners, no glassmorphism, no hairline-only borders.

Spacing rhythm. 12-column grid with 24px gutters on the cream canvas; white rounded cards float on the ground with the offset shadow.

Imagery. Pablo Stanley-style modular vector people: a resident with a phone, a guard with a clipboard, an admin with a megaphone, drawn in flat shapes with terracotta, teal, butter, and blush fills on cream. Hand-drawn accents — squiggle underlines, small stars, dotted paths connecting the three role cards. Status badges as stickers. No stock photography in the hero; small real photos only inside complaint attachments.

Section colour-blocking. Terracotta band for Visitor Management, teal band for Helpdesk, butter band for Dues — each with its own illustrated section opener.

7. Signature Design Concept

The public entry is an asymmetric cream first screen. The left seven columns carry the oversized Bricolage Grotesque headline "Your society, running smoothly" at clamp(40px, 9vw, 96px) with a hand-drawn terracotta squiggle under "smoothly", and beneath it a single terracotta pill CTA "Get started" plus a text link "I already have an account". The right five columns hold a stacked, slightly rotated trio of white role cards — Resident, Guard, Admin — each with a modular character illustration, a bold card title, and one line of plain copy ("Approve visitors from the sofa", "Log every entry at the gate", "Close complaints and collect dues"), connected by a dotted hand-drawn path. There is no gradient blob, no centred stack, and no blue button anywhere.

Below the hero, scrolling the Landing page feels like walking through rooms: colour-blocked bands — terracotta for Visitor Management, teal for Helpdesk, butter for Dues — each with its own illustrated section opener. Sticker-style status chips (mint "Approved", butter "Pending", blush "Overdue") with 999px radii and a 2px ink outline are used identically across gate requests, complaints, and dues so state is learnable once and reused everywhere. The app interior uses a role-aware shell: a persistent left rail on desktop that swaps its items by role with a small character illustration at the top, collapsing to a bottom tab bar on mobile — the navigation itself tells you who you are. The Resident's Gate Requests page carries a "live gate" widget: a stack of the three most recent visitor requests with big terracotta Approve / outline Deny pills and a 6-digit passcode shown as a monospace chip, animated in with a springy stagger.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief. The focal subject is the rotated stack of three illustrated role cards — Resident, Guard, Admin — joined by a dotted hand-drawn path, set against the oversized headline. The thesis: as the page settles, the three role cards spring into their stacked positions in sequence and the dotted path draws between them, so the visitor reads the three roles as one connected community; the terracotta squiggle under "smoothly" draws itself last. The motion vocabulary is springy but purposeful — 180–280ms with a soft overshoot cubic-bezier(0.34, 1.56, 0.64, 1) on chips, status changes, and card entrances; character illustrations do a small nod or wave on first view of a section; hover lifts a card by 3px and shifts its offset shadow; gate-approval buttons give a satisfying press. The composed first frame shows the headline, CTA, and the three role cards already in place with the dotted path faintly visible, so nothing is missing before motion begins. The reduced-motion state shows the same composed arrangement with instant state changes and no transforms.

9. Non-Functional Requirements

• Access control. Gate Requests, Gate Log, Complaints, Complaint Management, Notices, Notice Management, Dues, and Dues Collection require sign-in and the appropriate user role; unauthenticated visitors are redirected to Login. (explicit)
• Role scoping. Each signed-in user sees only their role's areas: Resident → Gate Requests, Complaints, Notices, Dues; Security Guard → Gate Log; Community Admin / Management Committee → Complaint Management, Notice Management, Dues Collection. (required_inference)
• Durable state. Accounts, gate requests, gate-log entries, complaints and their statuses, notices, and dues records persist in MariaDB across sessions. (required_inference)
• Responsive readability. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit; no other element covers any part of them. Imagery and decoration may be cropped, bled, rotated, or overlapped as the direction asks, as long as they cover no readable text or control.
• Reduced motion. With prefers-reduced-motion, all motion falls back to instant state changes with no transforms, and any moving or scrollable content provides a usable static arrangement in which each item can be brought fully into view.
• Mobile-friendly UI. The app shell collapses to a bottom tab bar on mobile and the pages remain usable at phone widths. (explicit, from the Society Dashboard mobile-friendly reference)
• Tone. Copy talks like a person and stays warm without undermining guard or dues workflows. (from creative direction)

10. Tech Stack

• Frontend: React application UI (the frontend service).
• Backend: Python / FastAPI shared process exposing the application APIs and domain modules (the backend service).
• Database: MariaDB for application-owned persistent data (the database service).
• Orchestration: docker-compose with the three services above; no Kubernetes is required for the current scope.

11. Assumptions and Constraints

• Assumption: The three roles are the complete active-human set; no additional roles or finer-grained permissions exist in the current scope.
• Assumption: Identity is application-owned and self-service; there is no invitation, provisioning, or deployment bootstrap flow.
• Assumption: Dues records are viewed only; no payment-gateway settlement, receipt generation, advance/overdue logic, or "I have paid" flow is in the current scope.
• Assumption: Complaints carry a description and a status; photo/document attachments, comments, reopening, filtering by location, and the escalation matrix are not in the current scope.
• Assumption: Gate requests carry visitor name, visit details, status, and a passcode where issued; e-Intercom fallback, 60-day history limits, and dues-based visitor blocking are not in the current scope.
• Assumption: Notices carry a title, body, author, and publish date; targeted-house delivery, polls, discussions, classifieds, and AGM invites are not in the current scope.
• Constraint: The generic indigo/blue-on-white SaaS template is forbidden; the palette, fonts, surfaces, tone, and layout in Sections 6–8 are binding.
• Constraint: Amenity booking, accounting/ERP, community discussion features, AI-assisted policy answers, e-Intercom, payment-gateway settlement, automated escalation, and dues-based visitor blocking are outside the current horizon and must not appear in current pages.

12. Glossary

• RWA — Resident Welfare Association; the community's governing body, represented in this product by the Community Admin / Management Committee role.
• Gate request — A Resident's pre-authorization record for a visitor, carrying visitor details, status, and a passcode where issued.
• Gate log — The Security Guard's record of visitor entries and exits, each with direction and timestamp.
• Passcode — The 6-digit code issued for an approved gate request, shown to the Resident and checked at the gate.
• Complaint — A Resident's reported issue, tracked through statuses from new to resolved.
• Notice — A community announcement published by the Community Admin and read by Residents.
• Dues — Maintenance or society charges owed by a Resident, shown with amount and payment status.
• Sticker chip — The 999px-radius, 2px-ink-outlined status badge (mint Approved, butter Pending, blush Overdue) used identically across gate requests, complaints, and dues.