System Requirements Document for mint-stone

1. Introduction

mint-stone is an Arabic-first Android application, delivered as an APK, that searches a bundled mock (fake) Facebook-account database by name, phone number, or account ID, and returns the matching account together with its phone number, its Facebook profile link, and the rest of its available account data. The database is explicitly dummy/test data — not real Facebook data — and is delivered inside the same folder as the application, saved beside it.

The product intent is a fast, legible, investigative lookup tool for a single operator: enter a query, pick the search mode, and read a dossier-like result card. The interface must be modern and carry a distinct industrial-ledger visual identity (see Sections 6–8), never a generic consumer social app and never a neutral admin panel.

The audience is the operator who runs the lookup (the searcher) and the owner who assembles and keeps the deliverable folder with the dummy database beside the app.

2. System Overview

mint-stone is a single-operator Android utility with a modern UI. Its current delivery consists of:

• An Android APK built from a React application UI, packaged for Android.
• A shared FastAPI backend process that serves the application APIs and domain modules (search over the mock account dataset).
• A MariaDB database used for application-owned persistent data.
• A bundled mock database file (data.json) shipped in the same delivery folder as the APK, beside it, and loaded so that search works before any query is run.

Actors

• الباحث عن حسابات فيسبوك — the human who searches by name, phone number, or ID and reads the result dossier.
• مالك التطبيق / مشغّل البيانات الوهمية — the human who creates/keeps the app folder with the dummy database beside it and confirms the app is ready to use.
• The backend and database are non-persona system actors that execute lookups and hold application-owned state.

Accepted behavior in brief: the Landing surface explains that the app searches mock Facebook accounts by name, phone, or ID and routes to search; the البحث surface takes the query text and the chosen search mode; the نتيجة البحث surface shows the matched account (name, phone, profile link, ID, and remaining available fields) or a clear no-match state.

Narrow exclusions: no real Facebook data, no live Facebook integration, no Facebook branding or official colours, and the dummy database is never presented as a downloadable or linked document.

Removed from scope

• Real Facebook account data (also: live Facebook lookup, real phone numbers, real profile links)
• Facebook branding, logos, and official Facebook colours
• Downloadable or linked dummy-database document

2a. Product Interpretation and Delivery Boundary

mint-stone is delivered as a self-contained Android APK plus its companion mock database file in one folder. The owner places the APK and data.json side by side; the app reads the bundled mock dataset so that search is executable immediately, without any external service or real Facebook access.

All three surfaces — Landing, البحث, and نتيجة البحث — are publicly reachable with no access requirement; there is no sign-in, account creation, or permission model in the current product. The backend and MariaDB support the lookup and hold application-owned state, but they are not destinations the operator visits.

Everything described in this document is current. No future-horizon capabilities are accepted; the mock-data constraint and the APK-plus-folder delivery constraint are binding for the whole current scope.

2c. Page Content and Component Coverage

Landing

• Information/state: product identity "mint-stone"; a quoted Arabic display statement explaining that the app searches Facebook accounts by name, phone number, or ID within a mock/test database; a persistent fake-data notice (hazard-tape ticker at the top); a footer folder chip labelled mint-stone / data.json indicating the dummy database sits beside the app.
• Primary action: rectangular orange CTA «ابحث الآن» with an acid-yellow 2px offset shadow, positioned bottom-right of the type block, routing to البحث.
• Supporting actions: none beyond entry to search.
• Domain entities: none persisted here; presents the mock-dataset concept and the delivery-folder concept.
• Component responsibilities: hero type block (flush-right Arabic display line over a 3-line hazard-tape band); tilted specimen dossier card (rotated −3°, cropped by the viewport edge while all its text stays visible) showing quoted labels 'ID', 'PHONE', 'PROFILE'; fake-data ticker; folder chip.
• States: loading — not applicable (static entry); empty — not applicable; success — hero and CTA render fully at 375/768/1280px; error — not applicable; recovery — if the bundled dataset is unavailable, the fake-data notice area surfaces a plain message that the mock database beside the app could not be read, and the CTA remains available to retry entry.

البحث

• Information/state: the current search mode (name / phone / ID) and the query text; a hint of the expected input shape for the active mode.
• Primary action: submit the search against the mock database.
• Supporting actions: switch search mode among the three file tabs (name / phone / ID); clear or edit the query.
• Domain entities: search query (mode + text); mock account records.
• Component responsibilities: three vertical file tabs on the left rail at 768px+ (stacked/horizontal at 375px), active tab marked by a 4px orange left rule and pulled 8px out of the column; query input with zero radius and 2px #2E2E31 border; fixed bottom search bar at 375px; submit control.
• States: loading — a snappy in-progress indication while the lookup runs; empty — no query entered yet, submit disabled or prompting for input; success — navigates to نتيجة البحث with the matched account; error — empty/blank query is rejected with an inline message; recovery — the query text is preserved so the operator can correct it and resubmit.

نتيجة البحث

• Information/state: the matched account rendered as a ruled dossier panel — striped square avatar with initials, quoted name, and aligned label/value rows for 'ID', 'PHONE', 'LINK' (Facebook profile link) plus the remaining available account fields; a rotated orange 'MATCH' stamp; a no-match state when nothing matches.
• Primary action: open the account's Facebook profile link (external destination).
• Supporting actions: return to البحث to run another query; re-run with a different mode.
• Domain entities: matched mock account (name, ID, phone, profile link, other available fields).
• Component responsibilities: dossier card with exposed 1px grid lines; tabular Archivo numerals for ID and phone at display size; quoted 11px tracked labels above each value; hazard-stripe wipe across the dossier header on arrival; no-match panel.
• States: loading — dossier skeleton while the result resolves; empty — no-match panel stating clearly that no account matched the query, with a return-to-search action; success — full dossier with all readable text and the profile link control fully inside the viewport; error — lookup failure shows a plain retry message and preserves the query; recovery — retry or return to البحث.

3. Functional Requirements

FR-1 — Android APK with a modern UI (explicit) As الباحث عن حسابات فيسبوك, I should receive and run mint-stone as an Android APK with a modern interface, so that I can use the lookup tool on an Android device.

• Trigger/input: installing and launching the APK.
• Observable result: the app opens on Landing with the industrial-ledger UI rendered.
• Access: none. Failure/recovery: if the app cannot read its bundled dataset, a plain message is shown and the app remains usable to retry. Continuation: proceed to search.

FR-2 — Search by name, phone number, or ID (explicit) As الباحث عن حسابات فيسبوك, I should search Facebook accounts by name, by phone number, or by ID, so that I can find the account from whichever identifier I hold.

• Trigger/input: query text plus a selected search mode (name / phone / ID) on البحث.
• Observable result: the lookup runs against the mock database and the matching account is presented on نتيجة البحث.
• Access: none. Failure/recovery: a blank query is rejected inline and the text is preserved; a lookup error shows a retry message. Continuation: adjust mode or query and search again.

FR-3 — Result shows account, phone, profile link, and all available data (explicit) As الباحث عن حسابات فيسبوك, I should see the matched account with its phone number, its Facebook profile link, and everything else available about it, so that I have the complete record in one place.

• Trigger/input: a successful lookup.
• Observable result: a dossier panel with the account name, 'ID', 'PHONE', 'LINK', and the remaining available fields, each under a quoted label.
• Access: none. Failure/recovery: if a field is absent in the mock record, its row shows an explicit "غير متوفر" value rather than a blank. Continuation: open the profile link or run another search.

FR-4 — Clear no-match state (required_inference) As الباحث عن حسابات فيسبوك, I should see a clear message when no account matches, so that I know the mock database holds no such record.

• Trigger/input: a lookup that returns zero matches.
• Observable result: a no-match panel on نتيجة البحث with a return-to-search action. Access: none. Continuation: return to البحث with the previous query preserved.

FR-5 — Open the Facebook profile link (explicit, external destination) As الباحث عن حسابات فيسبوك, I should open the account's Facebook profile link from the result, so that I can reach the profile URL shown in the record.

• Trigger/input: activating the 'LINK' value/control on the dossier.
• Observable result: the link is handed to the device's browser/external handler. Access: none. Failure/recovery: if no handler is available, the full URL remains selectable and readable on the card. Continuation: return to the dossier.

FR-6 — Mock database only (explicit constraint) As مالك التطبيق / مشغّل البيانات الوهمية, I should have the app operate exclusively on dummy/test data, so that no real Facebook data is implied or used.

• Observable result: every result is drawn from the bundled mock dataset, and the fake-data notice is persistently visible. Access: none.

FR-7 — App and dummy database delivered in one folder, side by side (explicit) As مالك التطبيق / مشغّل البيانات الوهمية, I should receive the APK and the dummy database saved together in one folder, so that the deliverable is self-contained.

• Observable result: the delivery folder contains the APK and data.json beside it, represented in-app by the footer folder chip mint-stone / data.json (never a clickable document link). Access: none.

FR-8 — Search executable before any query (required_inference) As الباحث عن حسابات فيسبوك, I should be able to search immediately after launch because the bundled mock database is already loaded, so that the first lookup succeeds without setup.

• Observable result: the first submitted query returns a dossier or a no-match state. Failure/recovery: if the dataset cannot be read, a plain message names the missing companion file and search remains retryable.

4. User Personas

الباحث عن حسابات فيسبوك

• Product context: a single operator using an Android APK to look up accounts inside a bundled mock Facebook dataset.
• Primary goal: obtain a clear, complete result for a name, phone number, or ID.
• Distinct responsibilities: chooses the search mode among three file tabs, enters the query, reads the dossier, and decides whether to open the profile link or search again.
• Inputs/decisions: the identifier at hand (name vs. phone vs. ID) determines the mode; the dossier determines whether the record is the right one.
• Interactions: consumes results produced by the backend over the mock dataset; relies on the owner having delivered the folder with data.json beside the APK.
• Observable success: a dossier showing name, ID, phone, and profile link — or an unambiguous no-match message.

مالك التطبيق / مشغّل البيانات الوهمية

• Product context: the person who assembles and keeps the deliverable — the APK and the dummy database in one folder.
• Primary goal: a ready-to-use app whose mock database sits beside it and is loaded on launch.
• Distinct responsibilities: keeps the folder intact, ensures data.json accompanies the APK, and confirms the app is usable.
• Inputs/decisions: where the folder lives on the device/host and whether the companion file is present.
• Interactions: hands the ready folder to the searcher; the app's footer chip reflects the companion file.
• Observable success: launching the APK yields a working search against the mock data with the folder chip visible.

5. Core User Flows

Flow A — Owner prepares the deliverable folder

1. مالك التطبيق / مشغّل البيانات الوهمية creates a folder and places the mint-stone APK inside it.
2. The owner saves the dummy database data.json beside the APK in the same folder.
3. The owner launches the APK; Landing renders with the fake-data ticker and the footer chip mint-stone / data.json.
4. If the companion file is missing or unreadable, Landing shows a plain message naming it; the owner restores the file and relaunches.
5. Success: the app is ready and the folder is handed to the searcher.

Flow B — Search by name

1. الباحث عن حسابات فيسبوك opens the app on Landing and activates «ابحث الآن».
2. On البحث, the searcher selects the 'NAME' file tab (marked by the 4px orange rule).
3. The searcher types the name and submits.
4. نتيجة البحث stamps in the dossier with the matched account, its 'ID', 'PHONE', 'LINK', and remaining fields.
5. If nothing matches, the no-match panel appears; the searcher returns to البحث with the query preserved and adjusts it.

Flow C — Search by phone number

1. From البحث, the searcher selects the 'PHONE' tab.
2. The searcher enters the phone number and submits.
3. The dossier appears with the phone number set in large tabular numerals as the loudest element, alongside name, ID, and link.
4. Failure: a blank entry is rejected inline; the searcher corrects and resubmits.

Flow D — Search by ID

1. From البحث, the searcher selects the 'ID' tab.
2. The searcher enters the account ID and submits.
3. The dossier appears with the 'MATCH' stamp and the ID rendered in grouped tabular figures.
4. Continuation: the searcher opens the 'LINK' to reach the profile URL, or returns to البحث for another lookup.

Flow E — Open the profile link

1. On نتيجة البحث, the searcher activates the 'LINK' value.
2. The device's external handler opens the profile URL.
3. The searcher returns to the dossier, which remains intact, and may run another search.

6. Visuals Colors and Theme

Muse: Virgil Abloh — quoted labels, safety-tape accents, and an industrial search ledger.

Headline gesture: every field is a tagged, "quoted" datum; results read as a dossier card stamped with an ID; the search box behaves like a labelled specimen tray.

Colour tokens (dark mode)

• Background: #111112
• Surface: #1B1B1D
• Hairline rules: #2E2E31
• Text: #F2F0EA
• Primary (active tab, CTA, stamped ID): #FF4D00
• Accent (hazard stripes, fake-data status dot): #E8FF3A
• Muted (labels, metadata): #8C8C8C
• No blue anywhere. Orange-on-black and off-white-on-black both exceed 7:1.

Typography

• Headings: Archivo — Archivo Black / Archivo 800, uppercase for Latin micro-labels and numerals, 0.14em tracking; Arabic display in IBM Plex Sans Arabic 700, tight leading, flush-right.
• Body: IBM Plex Sans Arabic.
• Scale (1.5 modular): display 40px mobile / 96px desktop; H1 32/56; H2 24/32; body 16/17; label 11/12 uppercase tracked. Arabic line-height 1.55 body, 1.15 display.
• Latin labels always quoted: 'SEARCH', 'NAME', 'ID', 'PHONE', 'LINK', 'MATCH'.

Shape language: zero radius on cards and inputs; chunky 2px #2E2E31 borders; 45° hazard-tape stripes as section dividers; exposed 1px grid lines in the result dossier; a single 4px orange left rule marking the active search mode; buttons are rectangles with a 2px acid-yellow offset shadow.

Layout: mobile-first single column at 375px with a fixed bottom search bar; at 768px a two-column split with the three search-mode tabs stacked as file tabs on the left rail; at 1280px a 12-column grid with the dossier in columns 4–11 and the rail bleeding to the left edge. Every result is a ruled dossier panel: avatar square, quoted name, then aligned label/value rows separated by hairlines.

Imagery: no photography. Visual material is the interface itself — quoted labels, hazard stripes, exposed grid lines, monospaced-looking numerals, and one abstract specimen graphic: a square avatar placeholder of 45° orange/black stripes with the account's initials in off-white. The dummy database appears only as the footer folder chip mint-stone / data.json.

Readability rule: headlines, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (e.g. clamp(...)) to fit; decoration may crop or bleed, readable text and controls may not.

7. Signature Design Concept

The Landing is a full-bleed industrial black field (#111112) with a single oversized Arabic display line set flush-right — a quoted statement about searching mock Facebook accounts by name, phone, or ID — sitting directly on a 3-line hazard-tape band (#FF4D00 / #111112 at 45°) that runs edge to edge behind the last word. Below it, floating half-off the right edge, a tilted dossier card (rotated −3°) shows a specimen account with 'ID', 'PHONE', and 'PROFILE' quoted labels in orange; the card is cropped by the viewport edge on purpose while all its text stays inside the visible portion. A single rectangular orange CTA «ابحث الآن» with an acid-yellow offset shadow sits bottom-right of the type block, not centred. No gradient, no blob, no centred stack. The footer carries the mint-stone / data.json folder chip as a non-clickable label.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the flush-right Arabic display statement over the hazard-tape band, with the tilted specimen dossier card half-off the right edge.
• Input → transformation → outcome thesis: on load, the hazard-tape band wipes in behind the last word and the dossier card settles from a slight rotation offset into its −3° resting tilt; the CTA's acid-yellow offset shadow snaps into place. No accepted behavior is added — the CTA still routes to البحث.
• Motion vocabulary: frame-based and snappy — 120ms step transitions, a single hazard-stripe wipe, a 90ms scale from 0.96 for stamped elements; a slow marquee ticker of the fake-data notice at the top only.
• Composed first frame: black field, Arabic display line flush-right, tape band mid-wipe, dossier card entering from the right edge, CTA bottom-right.
• Reduced-motion state: all stamps become instant opacity swaps, the ticker becomes a static wrapped line, and the dossier card appears at its resting tilt without motion.

Result arrival on نتيجة البحث uses the same vocabulary: the dossier stamps in with a 90ms scale from 0.96 and a single hazard-stripe wipe across its header. Decorative motion never delays reading a result.

9. Non-Functional Requirements

• Mock data only (explicit): the app must operate exclusively on dummy/test data; no real Facebook data is fetched, stored, or implied.
• APK delivery (explicit): the deliverable must be an Android APK.
• Folder co-location (explicit): the APK and the dummy database must be saved together in one folder, side by side.
• Readability at every viewport (explicit design constraint): readable text and controls remain whole and uncovered at 375px, 768px, and 1280px.
• No Facebook branding (explicit design constraint): no real Facebook logos, branding, or official colours.
• No blue/indigo accent (explicit design constraint): orange and acid yellow only.
• Reduced motion (explicit design constraint): prefers-reduced-motion yields a usable static arrangement.
• Arabic-first RTL (required_inference): the interface is Arabic-first with right-to-left layout, with Latin micro-labels quoted and tracked.

10. Tech Stack

• Frontend: React application UI, packaged as an Android APK.
• Backend: shared FastAPI process serving the application APIs and domain modules (search over the mock dataset).
• Database: MariaDB for application-owned persistent data.
• Bundled mock database: data.json delivered in the same folder as the APK, beside it.
• Containerization: Docker / docker-compose for the backend and database services.

11. Assumptions and Constraints

• The mock database is a JSON file named data.json placed beside the APK; the footer chip reflects this name. (Assumption — narrow, consistent with the folder requirement.)
• The three search modes are mutually exclusive per query; one mode is active at a time. (Assumption.)
• The profile link is an external URL opened by the device's handler; the app does not embed a browser. (Assumption.)
• No authentication, accounts, or permissions exist in the current scope; all three surfaces are public. (From the page contract.)
• The app is single-operator; no multi-user or sharing features are in scope.

12. Glossary

• APK: the Android application package delivered to the operator.
• Mock database / البيانات الوهمية: the bundled dummy dataset (data.json) of fake Facebook accounts, not real data.
• Dossier: the ruled result card presenting a matched account's fields under quoted labels.
• Search mode: the selected identifier type — name, phone number, or ID.
• Folder chip: the non-clickable footer label mint-stone / data.json representing the companion database file.
• Hazard-tape band: the 45° repeating orange/black stripe used as divider and result wipe.