System Requirements Document for messenger-point-chet

1. Introduction

POINT CHET is a premium messenger application inspired by modern chat apps such as WhatsApp, but with a fully ORIGINAL design, logo, colour system, and visual identity. It is built mobile-first and responsive across Android, iPhone, tablet, and desktop, with a modern, elegant, smooth, fast, and professional interface.

The product intent is a daily-driver messenger that feels like a real, complete application: users sign in with a phone number and a 6-digit PIN, chat privately and in groups with rich message types, share status/stories, manage contacts, groups, and communities, place simulated voice and video calls, receive notifications, search globally, and configure the app through a complete settings surface. The prototype persists its data in localStorage and ships with dummy data so the app immediately looks alive.

The audience is Indonesian and global mobile-first users (default country code +62) who expect a WhatsApp-class daily driver but want an original, elevated identity — calm, machined, and premium rather than loud or playful.

2. System Overview

POINT CHET is delivered as a mobile-first, responsive frontend prototype. All primary buttons have real interaction in the prototype. Data for accounts, sessions, chats, messages, contacts, groups, status, settings, and notifications is stored in localStorage, seeded with dummy data. Calls are a frontend UI simulation and are never claimed to be real-time. The visual identity is original: no WhatsApp logo, asset, green palette, doodle wallpaper, or naming convention is copied. Icons come from the open-source Lucide Icons library.

The active human actors are the accepted persona catalog: Pengguna Messenger (End User), Pembuat & Pengelola Grup/Komunitas, Pengguna Status/Story, Pengguna Panggilan, and Pengguna Pengaturan & Privasi. The application owns identity: users self-register with a phone number and profile, returning users verify with phone number + 6-digit PIN, forgotten PIN is handled through Account Recovery, and the session persists. Group and community administrative actions require the verified user to hold the applicable admin or management role.

2a. Product Interpretation and Delivery Boundary

POINT CHET is a first-party application with application-owned identity. Anonymous visitors first meet the product on the Landing surface, which explains POINT CHET and its purpose before account access. From there, new users self-register on Sign Up (phone number, PIN, PIN confirmation, name, username, profile photo, bio), returning users verify on Login (phone number + 6-digit PIN, country code default +62, show/hide PIN), and users who forgot their PIN recover access through Account Recovery. Once identity is established, the session persists across visits and the user reaches the Dashboard hub and the main navigation: CHAT | STATUS | KOMUNITAS | PANGGILAN | PROFIL.

Current delivery covers the full messenger surface described in this document: chats (private and group) with rich message types and message actions, voice messages, status/stories with 24-hour expiry and privacy control, profile and contacts, groups and communities, simulated call UI with call history, a notification center, global search, and complete settings including dark mode applied across the whole application.

Boundaries: calls are a frontend UI simulation only and must not be presented as real-time calling. The prototype persists to localStorage; a real backend implementation must not store PINs as plain text, and protected durable records require backend execution in a production implementation. No adjacent account-management capabilities beyond registration, login, PIN recovery, session persistence, and logout are in scope.

2b. Source Content Inventory

Not applicable — no reference directive declares content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: anonymous entry explaining POINT CHET, its target users, and what the messenger does; original POINT CHET logo mark and wordmark; tagline "MESSENGER · PRIVATE BY DESIGN".
• Primary actions: proceed to Login; proceed to Sign Up.
• Supporting actions: none beyond entry navigation.
• Domain entities: product identity, brand mark.
• Component responsibilities: hero composition (graphite field, wordmark, hairline rule, surface panel), primary CTA, secondary CTA.
• States: loading (skeleton), default, error/recovery (if entry navigation fails, retry).

Login

• Information/state: phone number field with country-code prefix chip (default +62), 6-digit PIN entry, show/hide PIN toggle, persisted-session awareness.
• Primary actions: verify with phone number + PIN; navigate to Sign Up; navigate to Account Recovery.
• Supporting actions: toggle PIN visibility; change country code.
• Domain entities: account, session, PIN credential.
• Component responsibilities: phone input, country-code chip, six PIN cells, show/hide control, primary CTA, links to Sign Up and Account Recovery.
• States: loading (skeleton), empty, success (session established → Dashboard), error (invalid phone/PIN with recovery path), recovery (redirect to Account Recovery).

Sign Up

• Information/state: phone number, PIN, PIN confirmation, name, username, profile photo, bio.
• Primary actions: create account; return to Login.
• Supporting actions: upload/choose profile photo; toggle PIN visibility.
• Domain entities: account, profile, credential.
• Component responsibilities: registration form, photo picker, validation messaging, primary CTA.
• States: loading, empty, success (account created → Dashboard), error (validation failure, e.g. PIN mismatch, with inline recovery).

Dashboard

• Information/state: post-login hub summarizing and routing to main navigation (CHAT | STATUS | KOMUNITAS | PANGGILAN | PROFIL); header with logo POINT CHET, search, camera, new chat, menu, profile photo, unread badge.
• Primary actions: enter CHAT, STATUS, KOMUNITAS, PANGGILAN, PROFIL; open Search; open camera; start new chat; open menu; open profile.
• Supporting actions: view unread badge; open Notifications.
• Domain entities: session, unread counts, navigation state.
• Component responsibilities: header, navigation (desktop sidebar + main area; mobile bottom navigation), unread badge, profile avatar.
• States: loading (skeleton), empty, success, error/recovery.

CHAT

• Information/state: list of private and group conversations with preview, timestamp, unread badge, pin/mute/archive state.
• Primary actions: open a conversation; start a new chat; search chats.
• Supporting actions: pin, mute, archive, delete chat; open chat context menu.
• Domain entities: chat, message preview, participant, unread count.
• Component responsibilities: ChatList, Avatar, context menu, header controls.
• States: loading (skeleton), empty (no chats), success, error/recovery.

Conversation

• Information/state: message thread with modern chat bubbles, timestamp, and message status (sent/delivered/read); typing indicator; online/last seen; reply/edit/delete/copy/pin/star/reaction/mention state; media attachments.
• Primary actions: send text, emoji, sticker/GIF, photo, video, file/document, audio, location, contact, voice message; reply, forward, edit, delete, copy, pin, star/favorite, react, mention.
• Supporting actions: search messages; open message context menu; open media viewer; open audio player.
• Domain entities: message, attachment, reaction, mention, read receipt.
• Component responsibilities: ChatBubble, MessageInput, MediaViewer, AudioPlayer, context menu, typing indicator, status ticks.
• States: loading (skeleton), empty, success, error/recovery (failed send with retry).

Voice Message

• Information/state: recording capsule with live waveform, timer, and breathing record dot; playback state with progress and speed.
• Primary actions: hold to record; pause/resume; cancel; send; play; change playback speed.
• Supporting actions: scrub progress.
• Domain entities: voice message, waveform, duration.
• Component responsibilities: recording capsule, waveform renderer, timer, AudioPlayer with speed chip.
• States: loading, empty, recording, paused, success (sent), error/recovery (cancel or failed send).

Message Search

• Information/state: searchable message results within a conversation.
• Primary actions: search messages; jump to a result.
• Supporting actions: clear query.
• Domain entities: message, query.
• Component responsibilities: search field, result list, highlight.
• States: loading, empty, success, error/recovery.

STATUS

• Information/state: list of statuses/stories (text, photo, video), own status, add-status entry, 24-hour expiry awareness.
• Primary actions: add status; open a status in the viewer.
• Supporting actions: open Status Privacy.
• Domain entities: status, media, expiry, audience.
• Component responsibilities: StoryItem, add-status control, privacy entry.
• States: loading (skeleton), empty, success, error/recovery.

Status Viewer

• Information/state: fullscreen story viewer with progress bar, next/previous navigation, reply/reaction/like controls, viewer list.
• Primary actions: advance/return between statuses; reply; react; like; view viewer list.
• Supporting actions: close viewer.
• Domain entities: status, viewer, reaction, reply.
• Component responsibilities: fullscreen viewer, progress bar, navigation controls, reaction bar, viewer list sheet.
• States: loading, empty, success, error/recovery (expired or unavailable status).

Status Privacy

• Information/state: audience selection — all contacts, specific contacts, or choose people.
• Primary actions: select audience; save privacy setting.
• Supporting actions: search/select contacts.
• Domain entities: audience rule, contact.
• Component responsibilities: audience selector, contact picker, save control.
• States: loading, empty, success, error/recovery.

KOMUNITAS

• Information/state: communities with name, photo, description; group list; announcement; members; admin; community settings entry.
• Primary actions: create community; open a community; manage groups; manage members/admin; edit announcement; open community settings.
• Supporting actions: add/remove groups; open New Community.
• Domain entities: community, group, member, admin, announcement.
• Component responsibilities: community list, GroupCard, settings entry.
• States: loading (skeleton), empty, success, error/recovery.

New Group

• Information/state: group name, photo, description; member selection.
• Primary actions: create group; add members.
• Supporting actions: choose group photo.
• Domain entities: group, member.
• Component responsibilities: group form, member picker, primary CTA.
• States: loading, empty, success (group created), error/recovery.

Group Members

• Information/state: member list, admin status, pending approvals, invite link, QR invite, member permissions.
• Primary actions: add/remove members; approve new members; generate invite link; show QR invite; set member permissions.
• Supporting actions: search members.
• Domain entities: member, admin, invite, permission, approval request.
• Component responsibilities: member list, approval queue, invite controls, permission toggles.
• States: loading, empty, success, error/recovery.

Group Settings

• Information/state: group info (name, photo, description), admin list, pin/mute state, leave/delete options.
• Primary actions: edit group info; add/remove admin; pin/mute group; leave group; delete group.
• Supporting actions: open Group Members.
• Domain entities: group, admin, settings.
• Component responsibilities: settings rows, admin management, destructive-action confirmation.
• States: loading, empty, success, error/recovery.

Group Chat

• Information/state: group message thread with mentions, sender identity, and message status.
• Primary actions: send messages and media; mention members; reply/react/pin/star.
• Supporting actions: open group info; search messages.
• Domain entities: group message, mention, member.
• Component responsibilities: ChatBubble, MessageInput with mention picker, member list.
• States: loading, empty, success, error/recovery.

New Community

• Information/state: community name, photo, description.
• Primary actions: create community.
• Supporting actions: choose community photo.
• Domain entities: community.
• Component responsibilities: community form, primary CTA.
• States: loading, empty, success, error/recovery.

Community Settings

• Information/state: community groups, announcement, members, admin, community settings.
• Primary actions: add/remove groups; edit announcement; manage members/admin; edit community settings.
• Supporting actions: open group management.
• Domain entities: community, group, announcement, member, admin.
• Component responsibilities: settings rows, group management, announcement editor.
• States: loading, empty, success, error/recovery.

PANGGILAN

• Information/state: call entry surface for voice and video calls; call history and missed calls.
• Primary actions: start voice call; start video call; open call history.
• Supporting actions: open Call Screen.
• Domain entities: call record, contact.
• Component responsibilities: call list, Call History entry, call initiation controls.
• States: loading, empty, success, error/recovery.

Call Screen

• Information/state: simulated incoming/outgoing voice and video call UI with call controls.
• Primary actions: mute; toggle speaker; camera on/off; switch camera; minimize; end call.
• Supporting actions: accept/decline incoming call.
• Domain entities: call session (simulated), participant.
• Component responsibilities: call controls, video preview placeholder, minimize state.
• States: loading, incoming, outgoing, active, minimized, ended, error/recovery. Calls are a frontend simulation and are never claimed to be real-time.

Call History

• Information/state: list of past calls including missed calls.
• Primary actions: review call history; redial.
• Supporting actions: open contact from a call entry.
• Domain entities: call record, missed call.
• Component responsibilities: history list, missed-call indicator.
• States: loading, empty, success, error/recovery.

PROFIL

• Information/state: profile photo, name, username, phone number, bio, online status.
• Primary actions: edit profile; change photo; edit name/username/bio; show QR profile; share profile; open media, links & documents; block/report.
• Supporting actions: open Profile Editor; open Contacts.
• Domain entities: profile, QR, media, block/report state.
• Component responsibilities: ProfileCard, QR card, media list, block/report controls.
• States: loading, empty, success, error/recovery.

Profile Editor

• Information/state: editable name, username, bio, profile photo.
• Primary actions: save profile changes; change photo; show QR profile; share profile.
• Supporting actions: cancel edits.
• Domain entities: profile, QR.
• Component responsibilities: edit form, photo picker, QR/share controls.
• States: loading, empty, success, error/recovery.

Contact Profile

• Information/state: contact photo, name, username, phone number, bio, online status; media, links & documents; block/report.
• Primary actions: start chat; voice call; video call; block; report.
• Supporting actions: open media/links/documents.
• Domain entities: contact, media, block/report.
• Component responsibilities: ProfileCard, action bar, media list.
• States: loading, empty, success, error/recovery.

Contacts

• Information/state: contact list with online status; search.
• Primary actions: search contacts; add contact; invite friend; open profile; start chat; voice call; video call.
• Supporting actions: filter online contacts.
• Domain entities: contact, online status.
• Component responsibilities: contact list, search field, add/invite controls.
• States: loading (skeleton), empty, success, error/recovery.

Notifications

• Information/state: notification center with new messages, mentions, reactions, status, group, calls, system; unread badge; toast notifications.
• Primary actions: open a notification; clear/read notifications.
• Supporting actions: open notification settings.
• Domain entities: notification, badge count.
• Component responsibilities: Notification component, badge, Toast.
• States: loading, empty, success, error/recovery.

Search

• Information/state: global search across users, usernames, chats, messages, groups, communities, and media; filters All / People / Chats / Groups / Messages / Media.
• Primary actions: enter query; apply filter; open a result.
• Supporting actions: clear query.
• Domain entities: user, chat, message, group, community, media.
• Component responsibilities: search field, filter chips, result list.
• States: loading, empty, success, error/recovery.

Account

• Information/state: account settings — edit profile, phone number, username, PIN.
• Primary actions: edit profile; change phone number; change username; change PIN.
• Supporting actions: logout.
• Domain entities: account, credential, session.
• Component responsibilities: settings rows, edit forms, confirmation dialogs.
• States: loading, empty, success, error/recovery.

Privacy

• Information/state: last seen, online status, profile photo, bio, status, read receipts, blocked users.
• Primary actions: set visibility for each privacy item; manage blocked users.
• Supporting actions: unblock a user.
• Domain entities: privacy setting, blocked user.
• Component responsibilities: privacy rows, visibility selectors, blocked-user list.
• States: loading, empty, success, error/recovery.

Appearance

• Information/state: theme (light, dark, system) and accent color.
• Primary actions: select theme; select accent color.
• Supporting actions: preview theme.
• Domain entities: appearance setting.
• Component responsibilities: theme selector, accent picker.
• States: loading, empty, success, error/recovery.

Storage

• Information/state: storage usage; media; documents; cache.
• Primary actions: view storage usage; view media; view documents; clear cache.
• Supporting actions: open media/document items.
• Domain entities: storage usage, media, document, cache.
• Component responsibilities: usage summary, media/document lists, clear-cache control.
• States: loading, empty, success, error/recovery.

Security

• Information/state: app lock UI, PIN, 2FA UI, active sessions.
• Primary actions: configure app lock; set/change PIN; configure 2FA; review active sessions.
• Supporting actions: end an active session.
• Domain entities: security setting, PIN, 2FA, session.
• Component responsibilities: security rows, PIN form, 2FA setup UI, session list.
• States: loading, empty, success, error/recovery.

About

• Information/state: version, terms, privacy, help.
• Primary actions: view version; open terms; open privacy; open help.
• Supporting actions: none beyond navigation.
• Domain entities: version, legal content, help content.
• Component responsibilities: info rows, content links.
• States: loading, empty, success, error/recovery.

Account Recovery

• Information/state: recovery flow for a forgotten PIN.
• Primary actions: initiate recovery; verify identity; set a new PIN.
• Supporting actions: return to Login.
• Domain entities: account, credential, recovery request.
• Component responsibilities: recovery form, verification step, new-PIN entry.
• States: loading, empty, success (access restored → Login/Dashboard), error/recovery.

3. Functional Requirements

FR-01 — Original premium messenger identity explicit As a Pengguna Messenger (End User), I should use a premium messenger named POINT CHET with an original design, logo, colour, and visual identity inspired by modern chat apps but never copying WhatsApp assets, so that the product feels distinct and trustworthy.

• Trigger/input: opening the application.
• Observable result: POINT CHET logo, palette, and identity are visible throughout; no WhatsApp logo, asset, green palette, doodle wallpaper, or naming convention appears.
• Access state: anonymous on Landing; authenticated after login.
• Failure/recovery: if assets fail to load, the interface degrades to text and Lucide icons without breaking layout.
• Continuation: user proceeds to Login or Sign Up.

FR-02 — Mobile-first responsive layout explicit As a Pengguna Messenger (End User), I should use POINT CHET on Android, iPhone, tablet, and desktop with a modern, elegant, smooth, fast, professional UI, so that the experience fits my device.

• Trigger/input: opening the app at any viewport.
• Observable result: mobile shows bottom navigation, fullscreen chat, and touch-friendly buttons; desktop shows sidebar, chat panel, and profile/info panel.
• Access state: any.
• Failure/recovery: layout reflows without clipping readable text or controls.
• Continuation: user navigates normally.

FR-03 — Login with phone number and 6-digit PIN explicit As a Pengguna Messenger (End User), I should log in with my phone number and a 6-digit PIN, with country code defaulting to +62 and a show/hide PIN option, so that I can access my account securely.

• Trigger/input: entering phone number and 6-digit PIN on Login.
• Observable result: session is established and the user reaches the Dashboard.
• Access state: anonymous entry on Login.
• Failure/recovery: invalid credentials show an error with retry; forgotten PIN routes to Account Recovery.
• Continuation: user enters the main navigation.

FR-04 — Register a new account explicit As a Pengguna Messenger (End User), I should register a new account with phone number, PIN, PIN confirmation, name, username, profile photo, and bio, so that I can start using POINT CHET.

• Trigger/input: completing the Sign Up form.
• Observable result: account is created and the user reaches the Dashboard.
• Access state: anonymous entry on Sign Up.
• Failure/recovery: validation errors (e.g. PIN mismatch) show inline with correction.
• Continuation: user enters the main navigation.

FR-05 — Forgot PIN recovery explicit As a Pengguna Messenger (End User), I should recover access when I forget my PIN, so that I am not locked out.

• Trigger/input: choosing "forgot PIN" from Login.
• Observable result: Account Recovery restores access and the user can log in again.
• Access state: anonymous entry on Account Recovery.
• Failure/recovery: failed verification keeps the user in recovery with retry.
• Continuation: user returns to Login or Dashboard.

FR-06 — Persisted session and logout explicit As a Pengguna Messenger (End User), I should have my session persist and be able to log out, so that I stay signed in between visits and can end my session deliberately.

• Trigger/input: reopening the app; choosing logout.
• Observable result: session persists across visits; logout clears the session and returns to Login.
• Access state: authenticated for persistence; anonymous after logout.
• Failure/recovery: corrupted session data falls back to Login.
• Continuation: user resumes or re-authenticates.

FR-07 — Prototype persistence and PIN safety explicit As a Pengguna Messenger (End User), I should have prototype data stored in localStorage while a real backend never stores PINs as plain text, so that the prototype works offline and real deployments stay safe.

• Trigger/input: any data mutation in the prototype.
• Observable result: accounts, session, chats, messages, contacts, groups, status, settings, and notifications persist in localStorage; PIN handling in a real backend is not plain text.
• Access state: any.
• Failure/recovery: storage errors surface a toast and keep in-memory state.
• Continuation: user continues working.

FR-08 — Main navigation explicit As a Pengguna Messenger (End User), I should navigate CHAT | STATUS | KOMUNITAS | PANGGILAN | PROFIL, so that I can reach every core area.

• Trigger/input: selecting a navigation item.
• Observable result: the selected destination opens.
• Access state: authenticated.
• Failure/recovery: unavailable destination shows an error state with retry.
• Continuation: user continues in the destination.

FR-09 — Header controls explicit As a Pengguna Messenger (End User), I should see a header with logo POINT CHET, search, camera, new chat, menu, profile photo, and unread badge, so that key actions are always reachable.

• Trigger/input: viewing the header.
• Observable result: each control is present and interactive; unread badge reflects unread counts.
• Access state: authenticated.
• Failure/recovery: badge hides at zero; failed actions show a toast.
• Continuation: user opens the chosen control.

FR-10 — Desktop sidebar and mobile bottom navigation explicit As a Pengguna Messenger (End User), I should get a sidebar plus main area on desktop and bottom navigation on mobile, so that navigation matches my device.

• Trigger/input: viewport change.
• Observable result: layout switches between sidebar and bottom navigation.
• Access state: authenticated.
• Failure/recovery: layout reflows without losing state.
• Continuation: user continues navigating.

FR-11 — Send rich message types explicit As a Pengguna Messenger (End User), I should send text, emoji, sticker/GIF UI, photo, video, file/document, audio, location, contact, and voice message in private and group chats, so that I can communicate in any form.

• Trigger/input: composing and sending from MessageInput.
• Observable result: the message appears in the thread with the correct type.
• Access state: authenticated.
• Failure/recovery: failed send shows retry.
• Continuation: conversation continues.

FR-12 — Message actions explicit As a Pengguna Messenger (End User), I should reply, forward, edit, delete, copy, pin, star/favorite, react with emoji, mention, and search messages, so that I can manage conversations precisely.

• Trigger/input: opening the message context menu or search.
• Observable result: the action applies and is reflected in the thread.
• Access state: authenticated.
• Failure/recovery: unsupported action shows a toast; failed action can be retried.
• Continuation: user continues the conversation.

FR-13 — Conversation presence and status explicit As a Pengguna Messenger (End User), I should see typing indicator, online/last seen, sent/delivered/read status, unread badge, and pin/mute/archive/delete chat, so that I know the state of every conversation.

• Trigger/input: viewing the chat list or thread.
• Observable result: indicators and statuses update accordingly.
• Access state: authenticated.
• Failure/recovery: stale presence falls back to last known value.
• Continuation: user continues.

FR-14 — Modern chat bubble explicit As a Pengguna Messenger (End User), I should see modern chat bubbles with timestamp and message status, so that each message reads clearly.

• Trigger/input: rendering a message.
• Observable result: bubble shows content, timestamp, and status.
• Access state: authenticated.
• Failure/recovery: missing timestamp/status renders a placeholder without breaking layout.
• Continuation: user reads and replies.

FR-15 — Voice message recording and playback explicit As a Pengguna Messenger (End User), I should hold to record, see a timer and waveform, pause/resume, cancel, send, and play back with progress and playback speed, so that voice messages are fully usable.

• Trigger/input: holding the record control; playing an audio message.
• Observable result: recording capsule shows waveform and timer; sent message becomes an AudioPlayer with progress and speed control.
• Access state: authenticated.
• Failure/recovery: cancel discards the recording; failed send offers retry.
• Continuation: conversation continues.

FR-16 — Status/story creation and viewing explicit As a Pengguna Status/Story, I should add text, photo, and video statuses and view them in a fullscreen story viewer with progress bar, next/previous, reply, reaction, like, and viewer list, so that I can share and consume stories.

• Trigger/input: adding a status; opening a status.
• Observable result: status appears in STATUS and opens fullscreen with the listed controls.
• Access state: authenticated.
• Failure/recovery: unavailable/expired status shows an error state and returns to STATUS.
• Continuation: user moves to the next status or exits.

FR-17 — Status 24-hour expiry explicit As a Pengguna Status/Story, I should have statuses expire automatically after 24 hours, so that shared content stays current.

• Trigger/input: passage of 24 hours since posting.
• Observable result: expired status no longer appears in STATUS or the viewer.
• Access state: authenticated.
• Failure/recovery: expired status opened from a stale link shows an expiry message.
• Continuation: user returns to STATUS.

FR-18 — Status privacy explicit As a Pengguna Status/Story, I should set status privacy to all contacts, specific contacts, or chosen people, so that only the intended audience sees my status.

• Trigger/input: selecting an audience in Status Privacy.
• Observable result: the audience rule is saved and applied to new statuses.
• Access state: authenticated.
• Failure/recovery: failed save keeps the previous rule and shows a toast.
• Continuation: user posts or views statuses.

FR-19 — Profile display explicit As a Pengguna Messenger (End User), I should see profile photo, name, username, phone number, bio, and online status, so that identity is clear.

• Trigger/input: opening PROFIL or a contact profile.
• Observable result: all listed fields render.
• Access state: authenticated.
• Failure/recovery: missing fields show placeholders.
• Continuation: user acts on the profile.

FR-20 — Profile features explicit As a Pengguna Messenger (End User), I should edit profile, change photo, edit name/username/bio, show QR profile, share profile, view media/links & documents, and block/report, so that I control my identity and safety.

• Trigger/input: choosing a profile action.
• Observable result: the change or view is applied.
• Access state: authenticated.
• Failure/recovery: failed save keeps prior values with a toast.
• Continuation: user continues in PROFIL.

FR-21 — Contacts explicit As a Pengguna Messenger (End User), I should see a contact list with search, add contact, invite friend, online contacts, open profile, start chat, voice call, and video call, so that I can reach people quickly.

• Trigger/input: opening Contacts and choosing an action.
• Observable result: the chosen action executes (chat opens, call screen opens, profile opens).
• Access state: authenticated.
• Failure/recovery: empty results show an empty state; failed action shows a toast.
• Continuation: user continues from the opened surface.

FR-22 — Group creation and management explicit As a Pembuat & Pengelola Grup/Komunitas, I should create a group with name, photo, and description; add/remove members; manage admin; add/remove admin; edit group info; create group invite link; show QR invite; mention members; pin/mute group; set member permissions; approve new members; and leave/delete the group, so that groups stay well managed.

• Trigger/input: group creation and group management actions.
• Observable result: group state reflects the change; members and admins are correct.
• Access state: authenticated; administrative actions require the applicable admin/management role.
• Failure/recovery: unauthorized attempts are blocked with an explanatory message; failed actions can be retried.
• Continuation: user continues managing or chatting.

FR-23 — Community creation and management explicit As a Pembuat & Pengelola Grup/Komunitas, I should create a community with name, photo, and description; manage its group list; announcement; members; admin; add/remove groups; and community settings, so that communities stay organized.

• Trigger/input: community creation and management actions.
• Observable result: community state reflects the change.
• Access state: authenticated; administrative actions require the applicable admin/management role.
• Failure/recovery: unauthorized attempts are blocked; failed actions can be retried.
• Continuation: user continues managing the community.

FR-24 — Simulated call UI explicit As a Pengguna Panggilan, I should use voice call and video call UI with incoming/outgoing call, call history, missed call, mute, speaker, camera on/off, switch camera, minimize, and end call, so that the call experience is complete in the prototype.

• Trigger/input: starting or receiving a call; using call controls.
• Observable result: the Call Screen reflects each control state; call history records the call.
• Access state: authenticated.
• Failure/recovery: the UI is a frontend simulation and never claims real-time calling; ending or failing returns to PANGGILAN.
• Continuation: user reviews Call History or starts another call.

FR-25 — Notification center explicit As a Pengguna Messenger (End User), I should receive a notification center covering new messages, mentions, reactions, status, group, calls, and system, with unread badge and toast notifications, so that I never miss activity.

• Trigger/input: incoming activity.
• Observable result: notification appears in the center, badge updates, and a toast shows.
• Access state: authenticated.
• Failure/recovery: failed delivery retries and keeps the badge accurate.
• Continuation: user opens the related item.

FR-26 — Global search explicit As a Pengguna Messenger (End User), I should search users, usernames, chats, messages, groups, communities, and media with filters All / People / Chats / Groups / Messages / Media, so that I can find anything.

• Trigger/input: entering a query and selecting a filter.
• Observable result: matching results render under the selected filter.
• Access state: authenticated.
• Failure/recovery: no results show an empty state; failed query shows retry.
• Continuation: user opens a result.

FR-27 — Complete settings explicit As a Pengguna Pengaturan & Privasi, I should configure Account (edit profile, number, username, PIN), Privacy (last seen, online status, profile photo, bio, status, read receipts, blocked users), Chat (wallpaper, theme, font size, enter to send, auto download media), Notifications (message, group, call, sound, vibration), Appearance (light, dark, system, accent color), Storage (storage usage, media, documents, clear cache), Security (app lock UI, PIN, 2FA UI, active sessions), and About (version, terms, privacy, help), so that the app behaves how I want.

• Trigger/input: changing a setting.
• Observable result: the setting is saved and applied across the application.
• Access state: authenticated.
• Failure/recovery: failed save keeps the previous value with a toast.
• Continuation: user continues configuring or returns to the app.

FR-28 — Premium UI system explicit As a Pengguna Messenger (End User), I should experience modern typography, rounded corners, soft shadow, restrained glass effect, elegant gradient, smooth animation, micro interaction, skeleton loading, modal, bottom sheet, dropdown, toast, and context menu, without a crowded design, so that the app feels premium.

• Trigger/input: interacting with any surface.
• Observable result: the listed UI patterns appear where appropriate and the layout stays uncluttered.
• Access state: any.
• Failure/recovery: reduced-motion preference removes non-essential animation.
• Continuation: user continues.

FR-29 — Dark mode across the application explicit As a Pengguna Pengaturan & Privasi, I should have dark mode applied to background, card, chat bubble, text, input, icon, modal, and navigation, so that the whole app is consistently dark.

• Trigger/input: selecting dark mode (or system dark).
• Observable result: every listed surface switches to dark tokens.
• Access state: authenticated.
• Failure/recovery: unsupported preference falls back to system.
• Continuation: user continues using the app.

FR-30 — Prototype dummy data explicit As a Pengguna Messenger (End User), I should see dummy data so the app immediately looks alive, so that the prototype demonstrates real usage.

• Trigger/input: first launch with empty storage.
• Observable result: accounts, chats, messages, contacts, groups, status, settings, and notifications are seeded.
• Access state: any.
• Failure/recovery: seeding failure leaves the app usable with empty states.
• Continuation: user explores the app.

FR-31 — Reusable components explicit As a Pengguna Messenger (End User), I should see consistent Avatar, ChatList, ChatBubble, MessageInput, StoryItem, ProfileCard, GroupCard, Modal, BottomSheet, Toast, AudioPlayer, MediaViewer, and Notification components, so that the interface is coherent.

• Trigger/input: rendering any surface that uses these components.
• Observable result: components render consistently across pages.
• Access state: any.
• Failure/recovery: component failure degrades gracefully without breaking the page.
• Continuation: user continues.

FR-32 — Code structure explicit As a Pengguna Messenger (End User), I should have the prototype delivered as index.html, css/style.css, js/app.js, js/auth.js, js/chat.js, js/status.js, js/profile.js, js/groups.js, js/calls.js, js/settings.js — or, if the platform supports only one file, a single HTML with internal CSS and JavaScript — so that the codebase is organized.

• Trigger/input: inspecting the delivered files.
• Observable result: the specified structure exists or the single-file fallback is used.
• Access state: not applicable.
• Failure/recovery: single-file fallback preserves all behavior.
• Continuation: development continues.

FR-33 — Real interaction on primary buttons explicit As a Pengguna Messenger (End User), I should have every primary button perform a real interaction in the prototype, so that the app feels functional.

• Trigger/input: pressing a primary button.
• Observable result: the button performs its action or shows a meaningful state change.
• Access state: any.
• Failure/recovery: failed action shows a toast with retry.
• Continuation: user continues.

FR-34 — Lucide Icons explicit As a Pengguna Messenger (End User), I should see open-source Lucide Icons used for application icons, so that iconography is consistent and licensed.

• Trigger/input: rendering icons.
• Observable result: Lucide icons appear at consistent stroke and size.
• Access state: any.
• Failure/recovery: missing icon falls back to a text label.
• Continuation: user continues.

FR-35 — Final product feel explicit As a Pengguna Messenger (End User), I should experience POINT CHET as a real messenger with premium, original, responsive, smooth, and complete UI, so that the prototype is convincing.

• Trigger/input: using the app end to end.
• Observable result: the app behaves and looks like a complete messenger.
• Access state: any.
• Failure/recovery: any broken surface shows a recovery state rather than a dead end.
• Continuation: user keeps using the app.

FR-36 — Self-service registration establishes identity required_inference As a Pengguna Messenger (End User), I should establish my phone-number identity and profile through self-service registration before protected work, so that my account exists.

• Trigger/input: completing Sign Up.
• Observable result: identity and profile are created and bound to the session.
• Access state: anonymous entry on Sign Up.
• Failure/recovery: incomplete form blocks creation with inline errors.
• Continuation: user reaches the Dashboard.

FR-37 — Returning verification and session continuity required_inference As a Pengguna Messenger (End User), I should verify with phone number and 6-digit PIN and have my session persist, so that I can resume without re-entering credentials each time.

• Trigger/input: reopening the app with a stored session.
• Observable result: the user lands authenticated in the app.
• Access state: anonymous entry on Login when no session exists.
• Failure/recovery: invalid or expired session returns to Login.
• Continuation: user resumes work.

FR-38 — Account Recovery restores protected access required_inference As a Pengguna Messenger (End User), I should use Account Recovery before protected access is restored when I forget my PIN, so that recovery is deliberate and safe.

• Trigger/input: initiating recovery from Login.
• Observable result: access is restored only after recovery completes.
• Access state: anonymous entry on Account Recovery.
• Failure/recovery: failed verification keeps protected state unavailable.
• Continuation: user logs in with the new PIN.

FR-39 — Role-gated group and community administration required_inference As a Pembuat & Pengelola Grup/Komunitas, I should hold the applicable admin or management role for administrative actions, so that group and community control stays correct.

• Trigger/input: attempting an administrative action.
• Observable result: the action is allowed only for the applicable role.
• Access state: authenticated with the applicable role.
• Failure/recovery: unauthorized attempts are blocked with an explanatory message.
• Continuation: user continues with permitted actions.

FR-40 — Call simulation boundary required_inference As a Pengguna Panggilan, I should use the call UI as a frontend simulation that never claims real-time calling, so that expectations match the prototype.

• Trigger/input: starting or receiving a call.
• Observable result: the UI presents the call flow without real-time claims.
• Access state: authenticated.
• Failure/recovery: ending or failing returns to PANGGILAN.
• Continuation: user reviews Call History.

FR-41 — Automatic status expiry required_inference As a Pengguna Status/Story, I should have status records expire automatically after 24 hours, so that shared content does not persist indefinitely.

• Trigger/input: 24 hours elapsed since posting.
• Observable result: the status is removed from active status lists.
• Access state: authenticated.
• Failure/recovery: expired status shows an expiry message if opened.
• Continuation: user returns to STATUS.

FR-42 — Appearance preferences applied application-wide required_inference As a Pengguna Pengaturan & Privasi, I should have dark-mode and appearance preferences applied across the application, so that my choice is consistent everywhere.

• Trigger/input: changing theme or accent color.
• Observable result: all surfaces update immediately.
• Access state: authenticated.
• Failure/recovery: unsupported value falls back to system.
• Continuation: user continues.

FR-43 — Backend execution for protected durable records required_inference As a Pengguna Messenger (End User), I should have protected durable records executed by a backend in a production implementation, so that data integrity and credential safety hold outside the prototype.

• Trigger/input: production deployment.
• Observable result: protected records are persisted server-side; PINs are never stored as plain text.
• Access state: authenticated.
• Failure/recovery: backend failure surfaces an error with retry.
• Continuation: user continues when the backend recovers.

4. User Personas

Pengguna Messenger (End User)

• Product context: the primary daily user of POINT CHET, signing in with a phone number and 6-digit PIN (country code default +62) and living in the CHAT surface.
• Primary goal: communicate smoothly with private and group contacts, with clear message status and no missed activity.
• Distinct accepted responsibilities: sending text, emoji, sticker/GIF, photo, video, file/document, audio, location, contact, and voice messages; applying reply, forward, edit, delete, copy, pin, star/favorite, reaction, and mention; searching messages; relying on typing indicator, online/last seen, sent/delivered/read, and unread badge; pinning, muting, archiving, and deleting chats; managing contacts (list, search, add, invite, online, open profile, start chat, voice call, video call); using global search with All / People / Chats / Groups / Messages / Media filters; and receiving notifications.
• Relevant inputs or decisions: choosing a conversation, choosing a message type, choosing a message action, choosing a search filter, deciding whether to open a notification.
• Interactions with other accepted participants: chats with contacts and group members; receives status updates from Pengguna Status/Story; places calls with Pengguna Panggilan; relies on settings chosen by Pengguna Pengaturan & Privasi.
• Observable success: conversations are stored, statuses are accurate, and the user can resume any thread with correct unread and read state.

Pembuat & Pengelola Grup/Komunitas

• Product context: a user who takes responsibility for group and community structure inside POINT CHET.
• Primary goal: keep groups and communities tidy with correct members, admins, and access rights.
• Distinct accepted responsibilities: creating groups with name, photo, and description; adding/removing members; appointing and removing admins; editing group info; generating group invite links and QR invites; mentioning members; pinning/muting groups; setting member permissions; approving new members; leaving or deleting groups; creating communities with name, photo, and description; managing community group lists, announcements, members, admins, adding/removing groups, and community settings.
• Relevant inputs or decisions: who joins, who becomes admin, what permissions members hold, whether a pending member is approved, whether to leave or delete.
• Interactions with other accepted participants: manages Pengguna Messenger (End User) members; coordinates with other admins; communicates inside Group Chat.
• Observable success: groups and communities reflect the intended membership and permissions, and administrative actions are restricted to the applicable role.

Pengguna Status/Story

• Product context: a user who shares ephemeral status content and consumes others' statuses.
• Primary goal: share statuses that reach exactly the intended audience and expire on time.
• Distinct accepted responsibilities: adding text, photo, and video statuses; watching in a fullscreen viewer with progress bar and next/previous; replying, reacting, and liking; viewing the viewer list; relying on automatic 24-hour expiry; and setting privacy to all contacts, specific contacts, or chosen people.
• Relevant inputs or decisions: what to post, which audience rule to apply, whether to reply/react/like.
• Interactions with other accepted participants: shares with Pengguna Messenger (End User) contacts; audience rules interact with Privacy settings owned by Pengguna Pengaturan & Privasi.
• Observable success: statuses appear to the correct audience, interactions are recorded, and expired statuses disappear.

Pengguna Panggilan

• Product context: a user who uses the voice and video call surfaces.
• Primary goal: run a complete call flow and review call history, understanding that the prototype simulates the call.
• Distinct accepted responsibilities: starting voice and video calls; handling incoming and outgoing calls; reviewing call history and missed calls; using mute, speaker, camera on/off, switch camera, minimize, and end call.
• Relevant inputs or decisions: whom to call, voice or video, which controls to toggle, when to end.
• Interactions with other accepted participants: calls contacts and group members; call records feed the notification center for Pengguna Messenger (End User).
• Observable success: the call flow runs end to end in the UI and the call is recorded in Call History, without any real-time claim.

Pengguna Pengaturan & Privasi

• Product context: a user who tunes the application to their preferences and controls visibility.
• Primary goal: have preferences saved and applied consistently across the whole app, including dark mode.
• Distinct accepted responsibilities: Account (edit profile, number, username, PIN); Privacy (last seen, online status, profile photo, bio, status, read receipts, blocked users); Chat (wallpaper, theme, font size, enter to send, auto download media); Notifications (message, group, call, sound, vibration); Appearance (light, dark, system, accent color); Storage (storage usage, media, documents, clear cache); Security (app lock UI, PIN, 2FA UI, active sessions); About (version, terms, privacy, help).
• Relevant inputs or decisions: which visibility rules to apply, which theme and accent to use, whether to clear cache, whether to end an active session.
• Interactions with other accepted participants: privacy choices affect what Pengguna Messenger (End User) contacts see; notification choices affect how activity reaches the user.
• Observable success: every preference persists and visibly changes the application, including dark mode across background, card, chat bubble, text, input, icon, modal, and navigation.

5. Core User Flows

Flow 1 — First-time visitor learns about POINT CHET and registers (Pengguna Messenger (End User))

1. The visitor opens POINT CHET and lands on Landing, which presents the original POINT CHET logo mark and wordmark, the tagline "MESSENGER · PRIVATE BY DESIGN", and a short explanation of the messenger and its audience.
2. The visitor chooses to create an account and is taken to Sign Up.
3. On Sign Up, the visitor enters phone number (country code default +62), PIN, PIN confirmation, name, username, profile photo, and bio.
4. The visitor submits. If validation fails (for example PIN and confirmation differ), inline errors appear and the visitor corrects the fields.
5. On success, the account is created, the session is established, and the visitor arrives at Dashboard.
6. From Dashboard, the user enters the main navigation CHAT | STATUS | KOMUNITAS | PANGGILAN | PROFIL and begins using the app.

Flow 2 — Returning user logs in and resumes (Pengguna Messenger (End User))

1. The user opens POINT CHET. If a persisted session exists, the user lands authenticated in the app; otherwise the user reaches Login.
2. On Login, the user enters the phone number with the country-code prefix (default +62) and the 6-digit PIN, optionally toggling show/hide PIN.
3. The user submits. On success, the session is established and the user reaches Dashboard.
4. If the credentials are invalid, an error appears and the user retries.
5. If the user has forgotten the PIN, the user proceeds to Account Recovery (Flow 3).
6. From Dashboard, the user resumes conversations, statuses, calls, and settings.

Flow 3 — Forgotten PIN recovery (Pengguna Messenger (End User))

1. From Login, the user chooses "forgot PIN" and is taken to Account Recovery.
2. On Account Recovery, the user initiates recovery and completes the verification step.
3. If verification fails, protected access remains unavailable and the user retries.
4. On success, the user sets a new PIN and access is restored.
5. The user returns to Login and signs in with the new PIN, reaching Dashboard.

Flow 4 — Private conversation with rich messages (Pengguna Messenger (End User))

1. The user opens CHAT from the navigation. The chat list shows private and group conversations with preview, timestamp, unread badge, and pin/mute/archive state.
2. The user opens a conversation, arriving at Conversation. The thread shows modern chat bubbles with timestamp and sent/delivered/read status, plus typing indicator and online/last seen.
3. The user composes a message in MessageInput and sends text, emoji, sticker/GIF, photo, video, file/document, audio, location, or contact.
4. The recipient's side shows the message; the sender sees sent → delivered → read status update, and the unread badge clears for the recipient.
5. The user applies a message action: reply, forward, edit, delete, copy, pin, star/favorite, reaction emoji, or mention. The thread reflects the change.
6. The user searches messages via Message Search and jumps to a result.
7. If a send fails, the message shows a retry affordance and the user retries.
8. The user continues the conversation or returns to CHAT to pin, mute, archive, or delete a chat.

Flow 5 — Voice message (Pengguna Messenger (End User))

1. Inside Conversation, the user holds the record control, which opens the Voice Message recording capsule with a live waveform, a tabular timer, and a breathing record dot.
2. The user pauses and resumes as needed; the timer and waveform reflect the state.
3. The user either cancels — the capsule slides away and the recording is discarded — or sends.
4. On send, the recording becomes an AudioPlayer capsule in the thread with progress and a playback speed control.
5. The recipient plays it, scrubs progress, and changes playback speed.
6. If sending fails, the user retries from the thread.

Flow 6 — Sharing and consuming status (Pengguna Status/Story)

1. The user opens STATUS and sees existing statuses plus an add-status entry.
2. The user adds a text, photo, or video status.
3. Before or after posting, the user opens Status Privacy and selects the audience: all contacts, specific contacts, or chosen people. The rule is saved and applied.
4. The user opens a status, which launches the fullscreen Status Viewer with a progress bar and next/previous navigation.
5. The viewer replies, reacts, or likes; the author can open the viewer list to see who viewed.
6. After 24 hours the status expires automatically and no longer appears in STATUS or the viewer; opening an expired status shows an expiry message and returns to STATUS.

Flow 7 — Contacts and starting communication (Pengguna Messenger (End User))

1. The user opens Contacts and sees the contact list with online status.
2. The user searches, adds a contact, or invites a friend.
3. The user opens a contact's Contact Profile, which shows photo, name, username, phone number, bio, and online status, plus media, links & documents and block/report.
4. From the profile the user starts a chat (→ Conversation), starts a voice call, or starts a video call (→ Call Screen).
5. If the user blocks or reports, the state is saved and reflected in the contact and in Privacy's blocked users.
6. The user continues from the opened surface.

Flow 8 — Creating and managing a group (Pembuat & Pengelola Grup/Komunitas)

1. The user opens KOMUNITAS and chooses to create a group, arriving at New Group.
2. The user enters the group name, photo, and description, and selects members.
3. The group is created and the user lands in Group Chat, where members can be mentioned and messages sent.
4. The user opens Group Members to add or remove members, approve pending members, generate a group invite link, show a QR invite, and set member permissions.
5. The user opens Group Settings to edit group info, add or remove admins, pin or mute the group, and leave or delete the group.
6. Administrative actions are permitted only when the user holds the applicable admin/management role; otherwise the action is blocked with an explanatory message.
7. The user continues managing or returns to Group Chat.

Flow 9 — Creating and managing a community (Pembuat & Pengelola Grup/Komunitas)

1. The user opens KOMUNITAS and chooses to create a community, arriving at New Community.
2. The user enters the community name, photo, and description and creates it.
3. The user opens Community Settings to manage the group list (add/remove groups), edit the announcement, manage members and admins, and adjust community settings.
4. Administrative actions require the applicable admin/management role; unauthorized attempts are blocked with an explanatory message.
5. The user returns to KOMUNITAS to continue.

Flow 10 — Simulated voice or video call (Pengguna Panggilan)

1. The user opens PANGGILAN and chooses voice call or video call, or starts a call from Contacts or Contact Profile.
2. The Call Screen opens showing the simulated incoming or outgoing call UI.
3. During the call the user toggles mute, speaker, camera on/off, and switch camera, and can minimize the call.
4. The user ends the call. The UI never claims the call is real-time; it is a frontend simulation.
5. The call is recorded and appears in Call History, including missed calls.
6. The user reviews Call History and can redial.

Flow 11 — Notifications and global search (Pengguna Messenger (End User))

1. Activity arrives (new message, mention, reaction, status, group, call, or system). The notification center in Notifications records it, the unread badge updates, and a toast appears.
2. The user opens Notifications and opens a notification, which routes to the related surface.
3. Separately, the user opens Search and enters a query.
4. The user applies a filter: All / People / Chats / Groups / Messages / Media.
5. Results render under the selected filter; the user opens a result and continues there.
6. If no results match, an empty state appears and the user adjusts the query.

Flow 12 — Configuring the application (Pengguna Pengaturan & Privasi)

1. The user opens settings and enters Account to edit profile, change the phone number, change the username, or change the PIN.
2. The user opens Privacy to set last seen, online status, profile photo, bio, status, read receipts, and blocked users.
3. The user opens Appearance and selects light, dark, or system, plus an accent color. Dark mode is applied across background, card, chat bubble, text, input, icon, modal, and navigation.
4. The user opens Storage to review storage usage, media, and documents, and to clear cache.
5. The user opens Security to configure app lock UI, PIN, 2FA UI, and active sessions, and can end an active session.
6. The user opens About to view version, terms, privacy, and help.
7. Every change is saved and applied across the application; failed saves keep the previous value and show a toast.
8. The user logs out from Account, which clears the session and returns to Login.

6. Visuals Colors and Theme

The creative direction is authoritative: Quiet precision after Jony Ive — a messenger machined from graphite and one ember accent. The muse is Jony Ive; the headline is "Graphite and one ember." POINT CHET is a high-frequency personal utility, so the interface is the product: restraint, material honesty, generous negative space, one perfectly lit subject, hairline dividers, and continuous-curve radii. This differentiates hard from WhatsApp's green-on-white and from the forbidden generic indigo/blue-on-white SaaS template.

Colour tokens — Dark mode (primary)

• --bg: #0E1012 (app canvas)
• --surface: #17191C (cards, sheets, sidebar, incoming bubbles)
• --surface-elevated: #1F2226 (modals, bottom sheets, dropdowns)
• --hairline: rgba(255,255,255,0.08)
• --text: #F2F3F5
• --text-muted: #8A9099
• --text-tertiary: #5F656D
• --primary: #E8E9EB (aluminium — high-contrast UI chrome, send glyph, active tab, light-mode ink; never a saturated brand colour)
• --accent: #FF5A2B (ember — rationed to under 5% of pixels: own outgoing bubble, unread badge, record dot, call end, active toggle, focus ring, one CTA per screen)
• --shadow-sheet: 0 8px 24px rgba(0,0,0,0.45) (sheets and modals only)

Colour tokens — Light mode (sibling)

• --bg: #F7F7F8
• --surface: #FFFFFF
• --hairline: rgba(0,0,0,0.07)
• --text: #14161A
• Same ember accent #FF5A2B; same aluminium primary role.

No blue, indigo, or violet primary/accent anywhere. No gradients except one very low-contrast graphite sheen on the hero device frame.

Typography

• Headings: Inter Tight, Light-to-regular weights (300/400) at large sizes with tight tracking (−0.02em to −0.04em), sentence case for screen titles; uppercase 11px micro-labels with +0.14em tracking for section headers and metadata (ONLINE, PINNED, TODAY).
• Body: Inter Tight.
• Scale: 1.25 modular on a 4/8pt rhythm — 12 / 13 / 15 / 17 / 20 / 24 / 32 / 44 / 64. Body 15px (chat message), 13px metadata, 12px micro-label.
• Display: hero wordmark clamp(44px, 9vw, 96px) light weight; auth screen title clamp(28px, 5vw, 40px); screen titles 20–24px; section headers 11px uppercase tracked.
• Numerals tabular for timers, unread counts, and call durations. Never bold-display; hierarchy comes from size and space, not weight.

Shape language

• Continuous-curve radii (squircle feel): message bubbles 18px with one 6px corner on the tail side; cards and sheets 20px; buttons and inputs 14px; avatars full circle; tab bar 24px top corners.
• Hairline 1px borders in rgba(255,255,255,0.08) instead of shadows wherever possible; where depth is needed, one soft shadow 0 8px 24px rgba(0,0,0,0.45) on sheets and modals only.
• No blobs, no stickers, no chunky outlines. Iconography is Lucide at 1.5px stroke, 20/24px, optically aligned to the 4pt grid.

Spacing rhythm

• 8pt vertical rhythm; mobile single column with a 16px gutter. Chat list rows 72px tall with a 52px avatar, name 15px, preview 13px muted, timestamp right-aligned 12px. Message thread is a single 720px max-width column.

Imagery style

• The interface is the imagery: no stock photography, no illustration, no 3D blobs. Visual subjects are limited to (a) the original POINT CHET logo mark — a geometric glyph built from a circle and a squared-off tail, drawn as a 1.5px hairline outline in aluminium with the ember accent on one segment, never a copy of any existing messenger mark; (b) user avatars as circular crops with a monogram fallback in Inter Tight on a graphite disc; (c) macro material detail used exactly twice — the auth screen's hairline "machined edge" rule and the profile QR card's brushed-graphite panel. Media attachments render as 8px-radius thumbnails with a hairline border and a 12px muted filename/type label; nothing is decorated.

7. Signature Design Concept

The public entry is the Landing / auth composition, and it is a portrait composition, not a centred SaaS hero.

• Top 55% of the viewport is a single graphite field (#0E1012) with a very subtle vertical sheen, carrying the POINT CHET wordmark set in Inter Tight Light at clamp(44px, 9vw, 96px), left-aligned on the 16px gutter so it spans nearly the full width at 375px and stops around 60% at 1280px.
• Beneath the wordmark, one 11px uppercase ember-tracked line: "MESSENGER · PRIVATE BY DESIGN".
• The original logo mark sits above the wordmark at 48px as a hairline-outlined circle-and-tail glyph with one ember segment.
• Below the wordmark, a single hairline rule spans gutter-to-gutter.
• Bottom 45% is a surface #17191C panel with 24px top corners containing the phone field (country code +62 as a bordered 14px-radius prefix chip), the 6-digit PIN as six 44px squircle cells, and one full-width ember CTA.
• Nothing is centred in a card; the composition is a stacked column of a dark field and a light-edged panel, and it could not be mistaken for a generic SaaS hero.

The signature moves carry through the product: the 6-digit PIN entered into six 44px squircle cells with a hairline border that fills with a single ember dot per digit, and a show/hide eye that toggles to a masked state where each filled cell shows a 6px aluminium disc instead of a numeral; own-message bubbles as the only large ember surface (#FF5A2B fill, #0E1012 text) against graphite incoming bubbles with a hairline; desktop navigation as a 320px hairline-ruled sidebar with a 1.5px Lucide icon rail, uppercase 11px tracked section labels (CHATS / STATUS / COMMUNITIES / CALLS), and selection shown by a 2px ember bar on the left edge of the active row rather than a filled pill; and voice-message recording as a full-width hairline-bordered capsule replacing the input row, with a live 60-bar waveform drawn as 1.5px aluminium strokes, a tabular timer, and a single ember dot breathing at 1.4s.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the POINT CHET wordmark and logo mark on the graphite field, with the surface panel beneath it.
• Input → transformation → outcome thesis: on first paint, the graphite field settles and the wordmark resolves from a 12px downward offset with a soft opacity ramp; the hairline rule draws gutter-to-gutter; the surface panel rises 24px into place. The outcome is a composed, machined first frame with the phone field, six PIN cells, and the single ember CTA ready for input. No accepted behaviour is added — only the accepted entry composition is revealed.
• Motion vocabulary: slow, physical easing cubic-bezier(0.22, 1, 0.36, 1) at 320–420ms for panel and sheet transitions; 120–180ms for hover, press, and state changes. Press scales a bubble to 0.985; the unread badge counts up once; the typing indicator is three 1.5px dots on a 1.2s loop; the record button breathes at 1.4s. No bounce, no particles, no gradient drift, no cursor-following effects.
• Composed first frame: graphite field top 55%, left-aligned wordmark, ember-tracked tagline, hairline rule, surface panel bottom 45% with phone field, six squircle PIN cells, and one ember CTA.
• Reduced-motion state: prefers-reduced-motion removes the reveal cascade and the typing dots become a static "typing…" label; the first frame renders fully composed with no motion.

Reveal-on-scroll is limited to one subject: on first paint the chat list staggers in as a single 40ms-per-row cascade, then nothing animates again. Decorative animation is limited to one cascade on first paint, one typing loop, and one breathing record dot.

9. Non-Functional Requirements

• NFR-01 — Originality explicit: design, logo, colour, and visual identity must be original; no WhatsApp logo, asset, green palette, doodle wallpaper, or naming convention may be copied. Rationale: explicit hard constraint.
• NFR-02 — Prototype persistence and credential safety explicit: the prototype uses localStorage for accounts, session, chats, messages, contacts, groups, status, settings, and notifications; a real backend must never store PINs as plain text. Rationale: explicit hard constraint.
• NFR-03 — Call honesty explicit: if only frontend, the call UI is a simulation and must not claim real-time calling. Rationale: explicit hard constraint.
• NFR-04 — Visual restraint explicit: the design must not be too crowded; no more than one ember CTA visible at a time and no screen with more than two competing filled surfaces. Rationale: explicit hard constraint plus creative direction.
• NFR-05 — Icon library explicit: use the open-source Lucide Icons library at 1.5px stroke, 20/24px, aligned to the 4pt grid. Rationale: explicit hard constraint.
• NFR-06 — Single-file fallback explicit: if the platform supports only one file, combine everything into one HTML with internal CSS and JavaScript. Rationale: explicit hard constraint.
• NFR-07 — Status expiry explicit: statuses expire automatically after 24 hours. Rationale: explicit hard constraint.
• NFR-08 — Dark mode coverage explicit: dark mode must apply to background, card, chat bubble, text, input, icon, modal, and navigation. Rationale: explicit hard constraint.
• NFR-09 — Responsiveness explicit: mobile-first across Android, iPhone, tablet, and desktop; mobile uses bottom navigation, fullscreen chat, and touch-friendly buttons; desktop uses sidebar, chat panel, and profile/info panel. Rationale: explicit requirement.
• NFR-10 — Performance feel explicit: the UI must feel smooth and fast; the restrained motion ceiling and layered_2d depth ceiling keep chat performant on mid-range Android. Rationale: explicit requirement plus creative direction.
• NFR-11 — Readable text and controls explicit: 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(...)) to fit, and no other element covers any part of them. Rationale: explicit direction constraint.
• NFR-12 — Backend execution for protected durable records required_inference: protected durable records require backend execution in a production implementation. Rationale: indispensable for credential safety and data integrity outside the prototype.
• NFR-13 — Accessibility of motion required_inference: prefers-reduced-motion removes the first-paint cascade and replaces the typing dots with a static "typing…" label. Rationale: indispensable for users who cannot tolerate motion.

10. Tech Stack

• Frontend: HTML, CSS, and JavaScript prototype delivered as index.html, css/style.css, js/app.js, js/auth.js, js/chat.js, js/status.js, js/profile.js, js/groups.js, js/calls.js, js/settings.js; if the platform supports only one file, a single HTML with internal CSS and JavaScript. explicit
• Icons: Lucide Icons (open-source). explicit
• Prototype storage: localStorage for accounts, session, chats, messages, contacts, groups, status, settings, and notifications, seeded with dummy data. explicit
• Production backend required_inference: a backend for protected durable records, with PINs never stored as plain text. Python/FastAPI with appropriate storage is the default choice for this service; Docker/docker-compose for local packaging, and Kubernetes only if deployment requires it.
• Typography: Inter Tight (headings and body). explicit via creative direction.

11. Assumptions and Constraints

• A-01 explicit: The prototype is frontend-only unless a backend is added; calls are simulated UI and never claimed real-time.
• A-02 explicit: Prototype data lives in localStorage; a real backend must not store PINs as plain text.
• A-03 explicit: Default country code is +62; PIN is exactly 6 digits.
• A-04 explicit: Statuses expire automatically after 24 hours.
• A-05 explicit: Dark mode applies across background, card, chat bubble, text, input, icon, modal, and navigation.
• A-06 explicit: Design, logo, colour, and identity are original; no WhatsApp asset, logo, green palette, doodle wallpaper, or naming convention is used.
• A-07 explicit: All primary buttons have real interaction in the prototype.
• A-08 explicit: Dummy data is seeded so the app immediately looks alive.
• A-09 required_inference: Group and community administrative actions require the verified user to hold the applicable admin or management role.
• A-10 required_inference: Protected durable records require backend execution in a production implementation.
• A-11 required_inference: Application-owned identity is established through self-service registration, verified through phone number + 6-digit PIN, and recovered through Account Recovery; the session persists until logout.
• A-12 required_inference: The visual system is graphite neutrals plus one ember accent #FF5A2B; no blue, indigo, or violet primary/accent is used, and the generic indigo/blue-on-white SaaS template is forbidden.
• A-13 [Default — not specified by user]: Python/FastAPI with appropriate storage is the assumed production backend; Docker/docker-compose for packaging, Kubernetes only if deployment requires it.

12. Glossary

• POINT CHET: The premium messenger product specified in this document, with original design, logo, colour, and visual identity.
• PIN: The 6-digit credential used with a phone number to log in; never stored as plain text in a real backend.
• Session: The persisted authenticated state that keeps the user signed in until logout.
• Account Recovery: The flow that restores access when a user forgets their PIN.
• Chat: A private or group conversation containing messages.
• Conversation: The message thread workspace for a chat.
• Voice Message: A recorded audio message with waveform, timer, pause/resume, cancel, send, playback progress, and playback speed.
• Status/Story: Ephemeral text, photo, or video content that expires automatically after 24 hours.
• Status Privacy: The audience rule for a status — all contacts, specific contacts, or chosen people.
• Group: A named conversation with photo, description, members, admins, invite link, QR invite, permissions, and approval of new members.
• Community: A container of groups with name, photo, description, announcement, members, admins, and settings.
• Call Screen: The simulated voice/video call UI with mute, speaker, camera on/off, switch camera, minimize, and end call.
• Call History: The record of past calls, including missed calls.
• Notification Center: The surface listing new messages, mentions, reactions, status, group, calls, and system notifications, with unread badge and toasts.
• Global Search: Search across users, usernames, chats, messages, groups, communities, and media, with filters All / People / Chats / Groups / Messages / Media.
• Ember accent: The single accent colour #FF5A2B, rationed to under 5% of pixels.
• Graphite field: The dark canvas #0E1012 used as the app background and the auth hero field.
• Hairline: A 1px border in rgba(255,255,255,0.08) (dark) or rgba(0,0,0,0.07) (light) used instead of shadows.
• Squircle: A continuous-curve radius shape used for bubbles, cards, sheets, buttons, inputs, and PIN cells.