System Requirements Document for mahkotasosmed-layanan-suntik

1. Introduction

MAHKOTASOSMED is an Indonesian social-media "suntik" (injection) service application. It lets people buy social-media engagement — followers, likes, views — for TikTok, Instagram, Facebook, and other platforms, ordered through an admin. The product intent is transactional but aspirational: a user registers with Google, passes a captcha gate, signs in, chooses a suntik service from the admin-provided catalogue, places an order, tracks its status, and talks to the admin directly through a live chat. On the other side, an admin account exists specifically to manage every feature: the suntik service catalogue, incoming user orders, and the live chat conversation with users.

The audience is young Indonesian creators, small online sellers, and hustle-culture users who live inside TikTok, Instagram, and Facebook and who read labels, hype, and drop-culture signalling fluently. The interface is deliberately not a corporate SaaS dashboard and not a wellness brand: it is a slightly underground, streetwear-flavoured utility where the label is the product.

2. System Overview

MAHKOTASOSMED is delivered as a custom first-party web application with application-owned identity. The current delivery covers:

• An anonymous Landing surface that explains MAHKOTASOSMED, the suntik services, the supported platforms, and the purpose of the application.
• daftar gogel — account registration using Google, followed by Verifikasi capcha — captcha verification at registration.
• Masuk — sign-in with captcha verification, used by both the user and the admin.
• LAYANAN SUNTIK DARI ADMIN — the signed-in user's place to browse and order suntik services for TikTok, Instagram, Facebook, and other platforms.
• Pesanan — the signed-in user's place to review the status and progress of stored suntik orders.
• LIVE CHAT ADMIN — the persistent communication space between the user and the admin.
• Kelola Layanan — the admin's place to manage the entire suntik service catalogue by platform and service type.
• Kelola Pesanan — the admin's place to review and manage user suntik orders.

Two accepted human personas act in the system: Pengguna (User) and Admin. The admin account is created and provisioned specifically to manage all features — this is an explicit hard constraint, not a general permission model.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. MAHKOTASOSMED is a first-party custom web application. All eight destinations above are application-owned custom pages. Identity is application-owned: a user establishes a durable account through Google registration, and that account is what binds their orders and their live-chat conversation to them. The admin account is provisioned specifically for the purpose of managing all features.

Access ownership. The Landing surface is anonymously reachable — it is the first impression and requires no identity. Registration (daftar gogel) and its captcha gate (Verifikasi capcha) are anonymous entry boundaries: a person who has no account yet must be able to reach them. Masuk is likewise anonymously reachable, because it is the interaction that establishes access to everything protected. The protected destinations — LAYANAN SUNTIK DARI ADMIN, Pesanan, LIVE CHAT ADMIN, Kelola Layanan, and Kelola Pesanan — require an established identity. Kelola Layanan and Kelola Pesanan are restricted to the admin account; the user-facing protected destinations are restricted to signed-in users.

Current vs. future boundary. Everything described in this document is current. No future-horizon requirements were accepted in the authoritative thread; nothing in this document is deferred.

Narrow exclusions. This document does not add adjacent capabilities that the source did not accept: no payment gateway or checkout flow, no wallet or balance system, no referral or affiliate programme, no analytics or reporting module, no notification centre, no multi-admin role hierarchy, no password-based credential flow (registration is via Google), and no account-management surface beyond what registration, captcha verification, and sign-in require.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous first impression. Explains what MAHKOTASOSMED is, that suntik services are provided by an admin, which platforms are supported (TikTok, Instagram, Facebook, and others), and what the application is for. No identity required; no user-specific state.
• Primary actions: Go to Masuk (sign in). Go to daftar gogel (register with Google).
• Supporting actions: Read the platform manifest; read the service explanation; follow the platform marquee.
• Domain entities: Platform (TikTok, Instagram, Facebook, X, YouTube, Telegram, and others), Suntik service category (followers, likes, views).
• Component responsibilities:
  • Hazard-stripe marquee band across the very top carrying platform names (TIKTOK · INSTAGRAM · FACEBOOK · X · YOUTUBE · TELEGRAM); loops continuously on desktop, wraps into a static two-row list under prefers-reduced-motion.
  • Oversized stacked wordmark "MAHKOTASOSMED" in Archivo Black, all-caps, three lines, bleeding off the left viewport edge.
  • Bone-coloured label plate reading "LAYANAN SUNTIK DARI ADMIN" in 14px uppercase with 0.14em tracking.
  • Vertical platform manifest: each platform name in quotation marks on its own graphite plate with a 2px bone border.
  • Primary CTA "MASUK" as an orange rectangular plate with a 2px acid-yellow offset shadow, pinned beneath the wordmark.
  • Optional cropped, high-contrast macro of a phone screen showing a follower count, near-black with an orange duotone, bled off the right edge so it never covers readable text.
• States:
  • Loading: static content; no data fetch required for the anonymous surface.
  • Empty: not applicable — the surface always carries the wordmark, label plate, platform manifest, and CTA.
  • Success: the visitor reads the explanation and proceeds to Masuk or daftar gogel.
  • Error: if the platform manifest cannot be rendered, the marquee and manifest fall back to the static two-row list so every platform name remains fully readable.
  • Recovery: the visitor can always reach Masuk and daftar gogel from the pinned CTA and the registration link.

daftar gogel

• Information / state: Anonymous registration entry. States that registration is performed with a Google account. No identity established yet.
• Primary actions: Continue with Google to create the MAHKOTASOSMED account.
• Supporting actions: Navigate to Masuk if the person already has an account.
• Domain entities: Google account identity, MAHKOTASOSMED account.
• Component responsibilities:
  • Google sign-up control as a rectangular plate button with a 2px acid-yellow offset shadow.
  • Quoted-label heading, e.g. "DAFTAR" / "GOOGLE", in Archivo Black.
  • Link to Masuk.
• States:
  • Loading: the Google sign-up control shows a pending state while the Google flow is in progress.
  • Empty: not applicable — the surface always presents the Google sign-up control.
  • Success: the Google account is accepted and the person proceeds to Verifikasi capcha.
  • Error: if the Google flow is cancelled or fails, the surface returns to its initial state with a readable message and the Google sign-up control remains available.
  • Recovery: the person can retry the Google sign-up, or switch to Masuk if they already have an account.

Verifikasi capcha

• Information / state: Anonymous captcha gate. Presented as part of registration, after the Google account has been accepted. No identity is established until the captcha is passed.
• Primary actions: Complete the captcha challenge and submit it for verification.
• Supporting actions: Request a new challenge if the current one is unreadable or expired.
• Domain entities: Captcha challenge, captcha verification result.
• Component responsibilities:
  • Captcha challenge widget.
  • Submit control as a rectangular plate button with a 2px acid-yellow offset shadow.
  • Refresh control for a new challenge.
  • Quoted-label heading, e.g. "VERIFIKASI" / "CAPCHA".
• States:
  • Loading: the challenge is being fetched or the answer is being verified.
  • Empty: not applicable — a challenge is always presented.
  • Success: the captcha is verified and registration completes; the person proceeds to Masuk.
  • Error: an incorrect or expired captcha shows a readable failure message and a fresh challenge is offered.
  • Recovery: the person can request a new challenge and retry without losing the accepted Google account step.

Masuk

• Information / state: Anonymous sign-in entry, used by both Pengguna (User) and Admin. States that sign-in is followed by captcha verification.
• Primary actions: Sign in with the Google account; complete the captcha verification.
• Supporting actions: Navigate to daftar gogel if the person has no account yet.
• Domain entities: Google account identity, MAHKOTASOSMED account, captcha challenge, captcha verification result, account role (user or admin).
• Component responsibilities:
  • Google sign-in control as a rectangular plate button with a 2px acid-yellow offset shadow.
  • Captcha challenge widget and submit control, presented as part of the sign-in interaction.
  • Refresh control for a new captcha challenge.
  • Link to daftar gogel.
  • Quoted-label heading, e.g. "MASUK".
• States:
  • Loading: the Google sign-in flow or the captcha verification is in progress.
  • Empty: not applicable — the sign-in control and captcha are always presented.
  • Success: the captcha is verified and the signed-in person is routed to their destinations — a user to LAYANAN SUNTIK DARI ADMIN, Pesanan, and LIVE CHAT ADMIN; the admin to Kelola Layanan, Kelola Pesanan, and LIVE CHAT ADMIN.
  • Error: an incorrect or expired captcha, or a cancelled or failed Google sign-in, shows a readable failure message and keeps the sign-in control available.
  • Recovery: the person can request a new captcha challenge and retry sign-in; a person without an account is directed to daftar gogel.

LAYANAN SUNTIK DARI ADMIN

• Information / state: Signed-in user surface. Presents the suntik services provided by the admin, organised by platform (TikTok, Instagram, Facebook, and others) and by service type (followers, likes, views). Shows each service's price and the quantity the user selects.
• Primary actions: Select a platform and service; enter the target and quantity; place the order.
• Supporting actions: Read service details and prices; move to Pesanan to review placed orders; open LIVE CHAT ADMIN.
• Domain entities: Platform, Suntik service (name, platform, service type, price), Order (target, quantity, status), User account.
• Component responsibilities:
  • Labelled service grid laid out as platform → service → price → quantity, not a wall of identical tiles.
  • Each service card carries a visible corner tag in the top-left with the platform name in quotation marks; the tag flips from graphite to safety orange on hover with a 2px nudge.
  • Each service card may carry one small abstract "injection" mark — a 3px vertical bar with a droplet — drawn as a simple SVG.
  • Order form controls for target and quantity, with tabular numerals.
  • Order submission control as a rectangular plate button with a 2px acid-yellow offset shadow.
  • Hazard-stripe section opener band with a small uppercase label.
• States:
  • Loading: the service catalogue is being fetched; service plates show a pending state.
  • Empty: when the admin has not published any service, the surface shows a readable empty state explaining that no suntik services are available yet, with a link to LIVE CHAT ADMIN.
  • Success: the order is placed and the user is shown the new order and can continue to Pesanan.
  • Error: an invalid target or quantity, or a failed order submission, shows a readable failure message and preserves the user's selections for retry.
  • Recovery: the user can correct the input and resubmit, or open LIVE CHAT ADMIN to ask the admin.

Pesanan

• Information / state: Signed-in user surface. Lists the user's stored suntik orders with their status and progress. Order quantities and numbers are rendered in Archivo Black at 1.5× body size so quantities read as labels.
• Primary actions: Review an order's status and progress; open LIVE CHAT ADMIN about a specific order.
• Supporting actions: Return to LAYANAN SUNTIK DARI ADMIN to place another order.
• Domain entities: Order (platform, service, target, quantity, status, timestamps), User account.
• Component responsibilities:
  • Order table with tabular numerals as the visual texture; admin table cells at 14px tabular.
  • Rectangular status chips with a punched-hole detail; "SELESAI" chips use the acid-yellow accent.
  • Order-status chips change with a 1-frame colour swap, no easing theatrics.
  • Hazard-stripe section opener band with a small uppercase label.
• States:
  • Loading: the order list is being fetched; order rows show a pending state.
  • Empty: when the user has placed no orders, the surface shows a readable empty state with a link to LAYANAN SUNTIK DARI ADMIN.
  • Success: the user sees each order's current status and progress.
  • Error: if the order list cannot be loaded, a readable failure message is shown with a retry control.
  • Recovery: the user can retry loading, or open LIVE CHAT ADMIN to ask the admin about an order.

LIVE CHAT ADMIN

• Information / state: Signed-in surface shared by Pengguna (User) and Admin. A persistent conversation between the user and the admin. On desktop it is a fixed right-hand drawer; on mobile it is a full-screen sheet. The header is a hazard-stripe band with an acid-yellow pulse dot next to the words "LIVE CHAT ADMIN".
• Primary actions: Send a message; read the admin's replies.
• Supporting actions: Open the drawer or sheet; close it; scroll back through the conversation.
• Domain entities: Conversation, Message (sender, body, timestamp), User account, Admin account.
• Component responsibilities:
  • Hazard-stripe header band with an acid-yellow pulse dot and the label "LIVE CHAT ADMIN".
  • Message list with sender attribution and timestamps in muted grey.
  • Message composer as a rectangular plate with a 2px bone border and a send control as a rectangular plate button with a 2px acid-yellow offset shadow.
  • Drawer slides in from the right with a 200ms cubic-bezier(0.2, 0, 0, 1).
• States:
  • Loading: the conversation history is being fetched; the message list shows a pending state.
  • Empty: when no messages exist yet, the surface shows a readable empty state inviting the user to write to the admin.
  • Success: the sent message appears in the conversation and the admin's reply appears when it arrives.
  • Error: if a message fails to send, a readable failure message is shown and the message text is preserved for retry.
  • Recovery: the user can resend the preserved message, or reload the conversation.

Kelola Layanan

• Information / state: Admin-only surface. Shows the entire suntik service catalogue organised by platform (TikTok, Instagram, Facebook, and others) and by service type (followers, likes, views), with each service's price. Uses a persistent left rail (240px desktop, collapsing to a top tab strip below 768px) with the same label-tag treatment.
• Primary actions: Create a suntik service; edit an existing service's platform, service type, and price; remove a service.
• Supporting actions: Filter the catalogue by platform or service type; move to Kelola Pesanan; open LIVE CHAT ADMIN.
• Domain entities: Platform, Suntik service (name, platform, service type, price, availability), Admin account.
• Component responsibilities:
  • Persistent left rail with label-tag treatment; top tab strip below 768px.
  • Service table with tabular numerals; admin table cells at 14px tabular.
  • Create and edit controls as rectangular plate buttons with a 2px acid-yellow offset shadow.
  • Rectangular status chips with a punched-hole detail.
  • Hazard-stripe section opener band with a small uppercase label.
• States:
  • Loading: the catalogue is being fetched; service rows show a pending state.
  • Empty: when no services exist, the surface shows a readable empty state with a create control.
  • Success: the created or edited service appears in the catalogue and becomes available on LAYANAN SUNTIK DARI ADMIN.
  • Error: an invalid or incomplete service definition, or a failed save, shows a readable failure message and preserves the admin's input.
  • Recovery: the admin can correct the input and resave, or discard the change.

Kelola Pesanan

• Information / state: Admin-only surface. Shows the suntik orders placed by users, with each order's platform, service, target, quantity, status, and timestamps. Uses the same persistent left rail (240px desktop, top tab strip below 768px) with label-tag treatment.
• Primary actions: Review an order; update an order's status as it progresses.
• Supporting actions: Filter orders by status or platform; move to Kelola Layanan; open LIVE CHAT ADMIN.
• Domain entities: Order (platform, service, target, quantity, status, timestamps), User account, Admin account.
• Component responsibilities:
  • Persistent left rail with label-tag treatment; top tab strip below 768px.
  • Order table with tabular numerals; admin table cells at 14px tabular.
  • Rectangular status chips with a punched-hole detail; "SELESAI" chips use the acid-yellow accent.
  • Status update control as a rectangular plate button with a 2px acid-yellow offset shadow.
  • Hazard-stripe section opener band with a small uppercase label.
• States:
  • Loading: the order list is being fetched; order rows show a pending state.
  • Empty: when no user orders exist, the surface shows a readable empty state.
  • Success: the updated status is stored and becomes visible to the user on Pesanan.
  • Error: if a status update fails, a readable failure message is shown and the previous status is retained.
  • Recovery: the admin can retry the status update, or open LIVE CHAT ADMIN to contact the user.

3. Functional Requirements

FR-1 — Application identity and naming (explicit) As a visitor, I should encounter the application under the name MAHKOTASOSMED, so that I know which service I am using.

• Actor: Visitor / Pengguna (User) / Admin.
• Trigger: Any page of the application is opened.
• Observable result: The name MAHKOTASOSMED is presented as the product identity.
• Access state: Anonymous.
• Failure/recovery: Not applicable — static identity.
• Continuation: The visitor proceeds to Masuk or daftar gogel.

FR-2 — Google registration (explicit) As a person without an account, I should register using my Google account on daftar gogel, so that I can create a MAHKOTASOSMED account without inventing new credentials.

• Actor: Pengguna (User).
• Trigger: The person opens daftar gogel and chooses to continue with Google.
• Observable result: The Google account is accepted and the person is carried into Verifikasi capcha.
• Access state: Anonymous.
• Failure/recovery: If the Google flow is cancelled or fails, the surface returns to its initial state with a readable message and the Google sign-up control remains available.
• Continuation: The person completes Verifikasi capcha, then signs in on Masuk.

FR-3 — Captcha verification at registration (explicit) As a person registering, I should pass captcha verification on Verifikasi capcha, so that registration is confirmed as human.

• Actor: Pengguna (User).
• Trigger: The Google account step on daftar gogel has been accepted.
• Observable result: The captcha is verified and registration completes.
• Access state: Anonymous.
• Failure/recovery: An incorrect or expired captcha shows a readable failure message and a fresh challenge is offered; the accepted Google account step is not lost.
• Continuation: The person proceeds to Masuk.

FR-4 — Sign-in with captcha verification (explicit) As a registered person, I should sign in on Masuk and pass captcha verification, so that I can reach my protected destinations.

• Actor: Pengguna (User) and Admin.
• Trigger: The person opens Masuk and signs in with their Google account.
• Observable result: The captcha is verified and the person is routed to their destinations — a user to LAYANAN SUNTIK DARI ADMIN, Pesanan, and LIVE CHAT ADMIN; the admin to Kelola Layanan, Kelola Pesanan, and LIVE CHAT ADMIN.
• Access state: Anonymous entry; establishes the signed-in session.
• Failure/recovery: An incorrect or expired captcha, or a cancelled or failed Google sign-in, shows a readable failure message and keeps the sign-in control available; a new challenge can be requested.
• Continuation: The signed-in person proceeds to their destinations.

FR-5 — Admin-provided suntik service catalogue (explicit) As a signed-in user, I should see the suntik services provided by the admin on LAYANAN SUNTIK DARI ADMIN, covering TikTok, Instagram, Facebook, and other platforms, so that I can choose what to order.

• Actor: Pengguna (User).
• Trigger: The signed-in user opens LAYANAN SUNTIK DARI ADMIN.
• Observable result: The catalogue of admin-provided suntik services is presented, organised by platform and service type, with prices.
• Access state: Signed-in user.
• Failure/recovery: If the catalogue cannot be loaded, a readable failure message is shown with a retry control.
• Continuation: The user selects a service and proceeds to order it.

FR-6 — Placing a suntik order (explicit) As a signed-in user, I should select a suntik service and place an order with a target and quantity, so that the admin can process engagement for my social-media account.

• Actor: Pengguna (User).
• Trigger: The user selects a service on LAYANAN SUNTIK DARI ADMIN and submits the order form.
• Observable result: The order is stored and the user is shown the new order.
• Access state: Signed-in user.
• Failure/recovery: An invalid target or quantity, or a failed submission, shows a readable failure message and preserves the user's selections for retry.
• Continuation: The user reviews the order on Pesanan, and the admin sees it on Kelola Pesanan.

FR-7 — Order status and progress review (required_inference) As a signed-in user, I should review the status and progress of my stored suntik orders on Pesanan, so that I know where each order stands.

• Actor: Pengguna (User).
• Trigger: The signed-in user opens Pesanan.
• Observable result: The user's orders are listed with their current status and progress.
• Access state: Signed-in user.
• Failure/recovery: If the order list cannot be loaded, a readable failure message is shown with a retry control.
• Continuation: The user places another order on LAYANAN SUNTIK DARI ADMIN, or opens LIVE CHAT ADMIN about an order.

FR-8 — Live chat with the admin (explicit) As a signed-in user, I should send messages to the admin and read the admin's replies on LIVE CHAT ADMIN, so that I can communicate directly about services and orders.

• Actor: Pengguna (User) and Admin.
• Trigger: The signed-in user or the admin opens LIVE CHAT ADMIN and sends a message.
• Observable result: The message appears in the conversation and the other participant's reply appears when it arrives.
• Access state: Signed-in user or admin.
• Failure/recovery: If a message fails to send, a readable failure message is shown and the message text is preserved for retry.
• Continuation: The conversation continues; the user can return to LAYANAN SUNTIK DARI ADMIN or Pesanan.

FR-9 — Admin account provisioned to manage all features (explicit) As an admin, I should hold an account created specifically to manage all features, so that I can operate the service side of MAHKOTASOSMED.

• Actor: Admin.
• Trigger: The admin account is provisioned and the admin signs in on Masuk.
• Observable result: The admin reaches Kelola Layanan, Kelola Pesanan, and LIVE CHAT ADMIN.
• Access state: Admin-restricted.
• Failure/recovery: If the admin's sign-in or captcha verification fails, the standard Masuk failure and recovery path applies.
• Continuation: The admin manages services, orders, and live chat.

FR-10 — Managing the suntik service catalogue (required_inference) As an admin, I should create, edit, and remove suntik services by platform and service type on Kelola Layanan, so that the catalogue users order from stays correct.

• Actor: Admin.
• Trigger: The admin opens Kelola Layanan and creates, edits, or removes a service.
• Observable result: The catalogue changes and the change becomes available on LAYANAN SUNTIK DARI ADMIN.
• Access state: Admin-restricted.
• Failure/recovery: An invalid or incomplete service definition, or a failed save, shows a readable failure message and preserves the admin's input.
• Continuation: The admin returns to the catalogue list, or moves to Kelola Pesanan.

FR-11 — Managing user orders (required_inference) As an admin, I should review user suntik orders and update their status as they progress on Kelola Pesanan, so that users see accurate order progress.

• Actor: Admin.
• Trigger: The admin opens Kelola Pesanan and updates an order's status.
• Observable result: The updated status is stored and becomes visible to the user on Pesanan.
• Access state: Admin-restricted.
• Failure/recovery: If a status update fails, a readable failure message is shown and the previous status is retained.
• Continuation: The admin continues through the order list, or opens LIVE CHAT ADMIN to contact the user.

FR-12 — Protected destinations require a signed-in identity (required_inference) As the application, I should require a signed-in identity before LAYANAN SUNTIK DARI ADMIN, Pesanan, and LIVE CHAT ADMIN are usable, so that orders and conversations stay bound to the correct user.

• Actor: Pengguna (User).
• Trigger: An anonymous visitor attempts to reach a protected destination.
• Observable result: The visitor is directed to Masuk; protected state remains unavailable until identity is established.
• Access state: Anonymous → signed-in.
• Failure/recovery: If sign-in or captcha verification fails, the standard Masuk failure and recovery path applies.
• Continuation: After sign-in, the user reaches the intended destination.

FR-13 — Admin destinations require admin access (required_inference) As the application, I should restrict Kelola Layanan and Kelola Pesanan to the admin account, so that only the admin manages services and orders.

• Actor: Admin.
• Trigger: A signed-in person attempts to reach an admin destination.
• Observable result: The admin reaches the destination; a non-admin signed-in user does not.
• Access state: Admin-restricted.
• Failure/recovery: A non-admin signed-in user is returned to their own destinations with a readable message.
• Continuation: The admin proceeds with service or order management.

4. User Personas

Pengguna (User)

Product context. The user is a young Indonesian creator, small online seller, or hustle-culture participant who lives inside TikTok, Instagram, and Facebook. They want more followers, likes, and views on their own social-media accounts, and they are comfortable with the vocabulary of buying visibility. They arrive at MAHKOTASOSMED without an account and expect a fast, low-friction way in.

Primary goal. To order a suntik service for their social-media account and see it processed.

Distinct accepted responsibilities.

• Registering a MAHKOTASOSMED account using their Google account on daftar gogel.
• Passing captcha verification on Verifikasi capcha to complete registration.
• Signing in on Masuk and passing captcha verification again.
• Browsing the admin-provided suntik catalogue on LAYANAN SUNTIK DARI ADMIN across TikTok, Instagram, Facebook, and other platforms.
• Selecting a service and placing an order with a target and quantity.
• Reviewing the status and progress of their stored orders on Pesanan.
• Sending messages to the admin and reading replies on LIVE CHAT ADMIN.

Relevant inputs or decisions. Which platform and which service type (followers, likes, views) to buy; the target account or post; the quantity; whether to ask the admin a question before or after ordering.

Interactions with other accepted participants. The user's orders are received and progressed by the Admin on Kelola Pesanan, and the user's questions are answered by the Admin on LIVE CHAT ADMIN. The user never manages the catalogue; the catalogue is provided by the admin.

Observable success. The user's suntik order is placed, appears on Pesanan with a progressing status, and reaches completion; questions asked in LIVE CHAT ADMIN receive an admin reply.

Source-backed constraints. The user must register with Google and pass captcha verification at registration and at sign-in. The user must be signed in before ordering or using live chat.

Admin

Product context. The admin is the operator of MAHKOTASOSMED. The admin account is created and provisioned specifically to manage all features — this is an explicit requirement, not a general permission model. The admin is the party who actually provides the suntik services and who answers users directly.

Primary goal. To keep the suntik service catalogue and the incoming user orders running, and to answer users through live chat.

Distinct accepted responsibilities.

• Signing in on Masuk with admin access, including captcha verification.
• Managing the entire suntik service catalogue on Kelola Layanan, organised by platform (TikTok, Instagram, Facebook, and others) and by service type.
• Reviewing user suntik orders and updating their status as they progress on Kelola Pesanan.
• Serving users through LIVE CHAT ADMIN, reading their messages and replying.

Relevant inputs or decisions. Which platforms and service types to offer and at what price; which orders to progress and to what status; how to answer a user's question.

Interactions with other accepted participants. The admin receives orders placed by Pengguna (User) on LAYANAN SUNTIK DARI ADMIN, progresses them so the user sees the change on Pesanan, and converses with the user on LIVE CHAT ADMIN.

Observable success. The catalogue on LAYANAN SUNTIK DARI ADMIN reflects what the admin published on Kelola Layanan; user orders move through statuses on Kelola Pesanan and are visible to the user on Pesanan; user messages on LIVE CHAT ADMIN are answered.

Source-backed constraints. The admin account exists specifically to manage all features. Admin destinations are restricted to the admin account.

5. Core User Flows

Flow A — Pengguna (User): register with Google and pass the captcha gate

1. The person, with no MAHKOTASOSMED account, opens the anonymous Landing surface and reads what MAHKOTASOSMED is, that suntik services are provided by an admin, and which platforms are supported.
2. The person chooses the registration path and arrives at daftar gogel.
3. On daftar gogel, the person chooses to continue with Google and completes the Google account step.
4. The person is carried to Verifikasi capcha and completes the captcha challenge.
5. Observable result: the captcha is verified and the MAHKOTASOSMED account is created.
6. Failure/recovery: if the Google step is cancelled or fails, daftar gogel returns to its initial state with a readable message and the Google control remains available. If the captcha is incorrect or expired, Verifikasi capcha shows a readable failure message and offers a fresh challenge without losing the accepted Google step.
7. Continuation: the person proceeds to Masuk.

Flow B — Pengguna (User): sign in and reach the suntik catalogue

1. The registered person opens Masuk.
2. The person signs in with their Google account and completes the captcha verification presented as part of sign-in.
3. Observable result: the captcha is verified and the person is signed in and routed to LAYANAN SUNTIK DARI ADMIN.
4. Failure/recovery: an incorrect or expired captcha, or a cancelled or failed Google sign-in, shows a readable failure message; the person requests a new challenge and retries.
5. Continuation: the person browses the suntik catalogue.

Flow C — Pengguna (User): order a suntik service

1. The signed-in user is on LAYANAN SUNTIK DARI ADMIN and sees the admin-provided services organised by platform (TikTok, Instagram, Facebook, and others) and by service type (followers, likes, views), each with its price.
2. The user selects a platform and a service; the service card's corner tag flips from graphite to safety orange with a 2px nudge.
3. The user enters the target and the quantity.
4. The user submits the order.
5. Observable result: the order is stored and the user is shown the new order.
6. Failure/recovery: an invalid target or quantity, or a failed submission, shows a readable failure message and preserves the user's selections so they can correct and resubmit.
7. Continuation: the user moves to Pesanan to review the order, or opens LIVE CHAT ADMIN to ask the admin about it.

Flow D — Pengguna (User): review order status and progress

1. The signed-in user opens Pesanan.
2. The user sees their stored suntik orders listed with platform, service, target, quantity, status, and timestamps; quantities render as labels in Archivo Black at 1.5× body size.
3. Observable result: the user sees each order's current status and progress, with status chips changing by a 1-frame colour swap.
4. Failure/recovery: if the order list cannot be loaded, a readable failure message is shown with a retry control.
5. Continuation: the user returns to LAYANAN SUNTIK DARI ADMIN to place another order, or opens LIVE CHAT ADMIN about an order.

Flow E — Pengguna (User): talk to the admin in live chat

1. The signed-in user opens LIVE CHAT ADMIN — a fixed right-hand drawer on desktop, a full-screen sheet on mobile, topped by a hazard-stripe header with an acid-yellow pulse dot.
2. The user writes a message in the composer and sends it.
3. Observable result: the message appears in the conversation; the admin's reply appears when it arrives.
4. Failure/recovery: if the message fails to send, a readable failure message is shown and the message text is preserved for retry.
5. Continuation: the conversation continues; the user can return to LAYANAN SUNTIK DARI ADMIN or Pesanan.

Flow F — Admin: sign in with admin access

1. The admin opens Masuk.
2. The admin signs in with the provisioned admin account and completes the captcha verification presented as part of sign-in.
3. Observable result: the admin is signed in and routed to Kelola Layanan, Kelola Pesanan, and LIVE CHAT ADMIN.
4. Failure/recovery: an incorrect or expired captcha, or a cancelled or failed sign-in, shows a readable failure message; the admin requests a new challenge and retries.
5. Continuation: the admin manages services, orders, or live chat.

Flow G — Admin: manage the suntik service catalogue

1. The signed-in admin opens Kelola Layanan from the persistent left rail (240px desktop, top tab strip below 768px).
2. The admin creates a new suntik service, or edits an existing one, specifying its platform (TikTok, Instagram, Facebook, or another) and its service type, and its price.
3. The admin saves the change.
4. Observable result: the catalogue is updated and the change becomes available to users on LAYANAN SUNTIK DARI ADMIN.
5. Failure/recovery: an invalid or incomplete service definition, or a failed save, shows a readable failure message and preserves the admin's input so it can be corrected and resaved.
6. Continuation: the admin returns to the catalogue list, or moves to Kelola Pesanan.

Flow H — Admin: manage user orders

1. The signed-in admin opens Kelola Pesanan from the persistent left rail.
2. The admin reviews the suntik orders placed by users, seeing each order's platform, service, target, quantity, status, and timestamps.
3. The admin updates an order's status as it progresses.
4. Observable result: the updated status is stored and becomes visible to the user on Pesanan.
5. Failure/recovery: if a status update fails, a readable failure message is shown and the previous status is retained so the admin can retry.
6. Continuation: the admin continues through the order list, or opens LIVE CHAT ADMIN to contact the user.

Flow I — Admin: answer a user in live chat

1. The signed-in admin opens LIVE CHAT ADMIN.
2. The admin reads the user's messages in the conversation.
3. The admin writes a reply in the composer and sends it.
4. Observable result: the reply appears in the conversation and the user sees it on their side of LIVE CHAT ADMIN.
5. Failure/recovery: if the reply fails to send, a readable failure message is shown and the reply text is preserved for retry.
6. Continuation: the admin returns to Kelola Layanan or Kelola Pesanan.

6. Visuals Colors and Theme

Muse and headline. Virgil Abloh — remixed familiarity for a social-media growth service: industrial labels, quotation marks, and a safety-orange ground. The label is the product.

Mode. Dark mode only.

Colour tokens by role.

Proportion. ~70% near-black ground, ~20% graphite surface, ~7% safety orange, ~3% acid yellow. Orange and yellow never sit on each other as text-on-fill; they are always paired against the dark ground for contrast.

Typography.

• Headings: Archivo Black, all-caps, tight tracking -0.02em, set at very large scale with deliberate stacking. Headlines are short labelled phrases in quotation marks, e.g. "FOLLOWERS" / "SUNTIK" / "LIVE CHAT". Weight is uniformly heavy; hierarchy comes from size and from the quotation marks, not from weight variation.
• Body: Space Grotesk.
• Scale: 1.333 modular, 1.25× for admin tables.
• Display (hero wordmark): clamp(48px, 9vw, 128px) mobile→desktop.
• H1: clamp(32px, 5vw, 72px). H2: clamp(24px, 3vw, 40px). H3/label: 14px uppercase, letter-spacing: 0.14em. Body: 16px / 1.5. Small/meta: 13px. Admin table cells: 14px tabular.
• Numbers in order tables use Archivo Black at 1.5× body size so quantities read as labels, not values.
• All headings wrap fully inside their container at 375px — no clipped wordmarks.

Shape language. Hard-edged rectangles with 0–4px radii only. Elements read as physical labels, tags, and industrial plates: chunky 2px borders in bone or orange, rectangular status chips with a punched-hole detail, and hazard-stripe bands (repeating linear-gradient at 45°, orange and near-black, 12px pitch) used as section dividers and as the top edge of the live-chat panel. Buttons are rectangular plates with a 2px offset shadow in acid yellow — not a soft blur — so they feel like a printed sticker lifted off the surface. No pills, no blobs, no soft shadows.

Layout. Asymmetric industrial grid: 12 columns at 1280px, 6 at 768px, 4 at 375px, with the hero deliberately breaking it — the wordmark bleeds off the left edge and the platform list runs as a vertical stack in a narrow right-hand column. Section openers are full-width hazard-stripe bands with a small uppercase label sitting on the stripe. Service cards are laid out as a labelled grid (platform → service → price → quantity) rather than a wall of identical tiles; each card carries a visible tag in the top-left corner with the platform name in quotation marks. The admin panel uses a persistent left rail (240px desktop, collapsing to a top tab strip below 768px) with the same label-tag treatment. Live chat is a fixed right-hand drawer on desktop and a full-screen sheet on mobile. Every readable label, price, and control stays fully inside its column at all three breakpoints.

Imagery. No stock photography of people. Visual interest comes from typographic labels, hazard-stripe bands, punched-hole tag details, and small high-contrast platform glyphs rendered as flat single-colour silhouettes in bone or orange. Each service card may carry one small abstract "injection" mark — a 3px vertical bar with a droplet — drawn as a simple SVG. Order tables use tabular numerals as the visual texture. Where a hero image is needed, use a cropped, high-contrast macro of a phone screen showing a follower count, treated in near-black with an orange duotone, bled off the right edge so it never covers readable text.

Avoid. No blue or indigo primary anywhere — no #2563EB, #3B82F6, #4F46E5, #6366F1, #7C3AED or neighbours. No white or near-white page ground. No Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body. No gradient-blob heroes, no glassmorphic frosted panels, no soft blurred shadows. No grid of identical hover-lift cards with uniform rounded corners. No stock photography of people, no smiling handshake imagery, no illustrated mascots. No rounded pill buttons, no 16px+ radii, no capsule shapes. No decorative motion beyond the single marquee and 120–200ms state changes; no particles, no parallax, no scroll-scrubbed camera moves.

7. Signature Design Concept

"MAHKOTASOSMED" as a shipping manifest of purchased attention.

The public entry is a full-bleed near-black (#111112) field, not a centred SaaS stack. A hazard-stripe marquee band runs edge-to-edge across the very top, carrying platform names — TIKTOK · INSTAGRAM · FACEBOOK · X · YOUTUBE · TELEGRAM — looping continuously on desktop and wrapping into a static two-row list under prefers-reduced-motion so every platform name is fully readable.

Below the band, on the left, MAHKOTASOSMED is set in Archivo Black at clamp(48px, 9vw, 128px), all-caps, stacked on three lines, and deliberately bleeds off the left viewport edge so the final "D" is cropped by the frame — the gesture is carried by the wordmark's own bleed, while every readable letter stays whole and inside the viewport at 375px, 768px, and 1280px. Directly beneath the wordmark, a bone-coloured label plate reads "LAYANAN SUNTIK DARI ADMIN" in 14px uppercase with 0.14em tracking.

To the right, a vertical stack of platform names — TIKTOK, INSTAGRAM, FACEBOOK, X, YOUTUBE, TELEGRAM — each in quotation marks, each on its own graphite plate with a 2px bone border, running top to bottom like a shipping manifest. The primary CTA "MASUK" sits as an orange rectangular plate with a 2px acid-yellow offset shadow, pinned beneath the wordmark, not centred. No gradient blob, no centred headline-plus-subtext, no blue button. On mobile the platform stack collapses beneath the wordmark and the marquee stays at the top; the wordmark scales down but never clips a readable letter.

The concept recomposes only accepted content, states, and controls: the product name, the admin-provided suntik service framing, the supported platforms, and the sign-in and registration entry points.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief.

• Focal subject: the oversized stacked MAHKOTASOSMED wordmark in Archivo Black, bleeding off the left viewport edge, with the vertical platform manifest running down the right-hand column.
• Input → transformation → outcome thesis: the hazard-stripe marquee band at the top carries platform names continuously across the frame; the visitor's attention moves from the moving band down to the static wordmark and label plate, and then to the pinned "MASUK" plate — the outcome is that the visitor understands this is an admin-provided suntik service for TikTok, Instagram, Facebook, and others, and proceeds to Masuk or daftar gogel.
• Motion vocabulary: snappy and mechanical — 120–180ms ease-out on all state changes; hover on a service card flips its corner tag from graphite to safety orange and shifts the card 2px (a tag flip, not a lift); the live-chat panel slides in from the right with a 200ms cubic-bezier(0.2, 0, 0, 1); order-status chips change with a 1-frame colour swap, no easing theatrics. No parallax, no particle fields, no gradient drift.
• Composed first frame: the hazard-stripe marquee band across the very top; the three-line wordmark bleeding off the left edge; the bone label plate reading "LAYANAN SUNTIK DARI ADMIN"; the vertical platform manifest on graphite plates with 2px bone borders on the right; the orange "MASUK" plate with its 2px acid-yellow offset shadow pinned beneath the wordmark.
• Reduced-motion state: the marquee stops and wraps into a static two-row list so every platform name is fully readable; all state changes remain instantaneous colour swaps with no easing.

9. Non-Functional Requirements

NFR-1 — Readable text and controls stay whole at every viewport (explicit — creative direction) Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving and scrollable content (the marquee) may cross the viewport edge by design and is judged by whether every item becomes fully readable as it passes. Under prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto).

• Rationale: the direction's bleed and marquee gestures must never cost legibility.

NFR-2 — Captcha verification is enforced at registration and at sign-in (explicit) Captcha verification is a required gate on Verifikasi capcha during registration and on Masuk during sign-in. Registration and sign-in do not complete without a verified captcha.

• Rationale: the source explicitly requires captcha verification at both points.

NFR-3 — Identity continuity binds orders and conversations to the correct participant (required_inference) A user's orders and live-chat conversation remain bound to that user's account across sessions; the admin's management actions remain bound to the admin account.

• Rationale: without this, an order or a conversation could be attributed to the wrong participant, breaking the accepted outcomes.

NFR-4 — Admin-only restriction on management destinations (explicit) Kelola Layanan and Kelola Pesanan are reachable only by the admin account. The admin account is created specifically to manage all features.

• Rationale: explicit hard constraint in the authoritative source.

NFR-5 — Motion restraint (explicit — creative direction) All state changes use 120–180ms ease-out. The only continuous motion is the single hazard-stripe marquee on the landing hero. No particles, no parallax, no scroll-scrubbed camera moves, no gradient drift.

• Rationale: the direction specifies a restrained tempo with one marquee.

NFR-6 — Dark-mode-only industrial palette (explicit — creative direction) The application renders on the #111112 ground with #1C1C1E surfaces; no white or near-white page ground and no blue or indigo primary is used anywhere.

• Rationale: the direction forbids the generic indigo/blue-on-white SaaS template.

NFR-7 — Responsive breakpoint behaviour (explicit — creative direction) The layout uses 12 columns at 1280px, 6 at 768px, and 4 at 375px. The admin left rail is 240px on desktop and collapses to a top tab strip below 768px. Live chat is a fixed right-hand drawer on desktop and a full-screen sheet on mobile.

• Rationale: the direction specifies these breakpoints and collapses.

10. Tech Stack

• Frontend: React (custom first-party web application, custom_ui: true).
• Backend: Python / FastAPI, required for backend integration (requires_backend_integration: true) — serving the suntik service catalogue, orders, order status, and the live-chat conversation.
• Storage: a persistent datastore for accounts, suntik services, orders, order status history, and chat messages, so that orders and conversations survive across sessions.
• Identity: Google sign-up and sign-in, with captcha verification at registration and at sign-in, and an admin account provisioned specifically to manage all features.
• Containerization: Docker / docker-compose for local and deployment packaging.
• Orchestration: Kubernetes is not required by any accepted requirement and is therefore not included.

11. Assumptions and Constraints

Assumptions.

• [Assumption] Registration is performed exclusively with a Google account; no password-based credential flow is introduced, because the source specifies "daftar gogel".
• [Assumption] The admin account is provisioned by the operator rather than self-registered, because the source asks for an admin account to be created specifically to manage all features.
• [Assumption] "Layanan suntik" covers social-media engagement services such as followers, likes, and views, ordered by a user and processed by the admin.
• [Assumption] The platform list on the landing marquee (TIKTOK · INSTAGRAM · FACEBOOK · X · YOUTUBE · TELEGRAM) is the direction's presentation of the source's "TIKTOK IG FB DAN LAINNYA"; the catalogue itself is defined by the admin on Kelola Layanan.

Constraints.

• The application is named MAHKOTASOSMED.
• Registration uses Google, with captcha verification.
• Sign-in uses captcha verification.
• Suntik services are provided by the admin, covering TikTok, Instagram, Facebook, and other platforms.
• Live chat with the admin is available to signed-in users.
• An admin account is created specifically to manage all features.
• Users must be signed in before ordering or using live chat.
• Admin destinations are restricted to the admin account.
• The palette, typography, shape language, layout, motion, and imagery follow the creative direction exactly; the generic indigo/blue-on-white SaaS template is forbidden.

Explicit exclusions (current scope).

• No payment gateway, checkout, or wallet/balance system.
• No referral or affiliate programme.
• No analytics or reporting module.
• No notification centre.
• No multi-admin role hierarchy or differentiated permission tiers beyond the admin/user distinction.
• No password-based credential flow.
• No account-management surface beyond registration, captcha verification, and sign-in.

12. Glossary

• MAHKOTASOSMED — the application; an Indonesian social-media "suntik" service where users buy engagement for their social-media accounts through an admin.
• Suntik — Indonesian for "injection"; in this product, a purchased social-media engagement service such as followers, likes, or views.
• Layanan suntik — a suntik service offered in the admin-managed catalogue, defined by platform, service type, and price.
• Platform — a social-media network the suntik service applies to: TikTok, Instagram, Facebook, and others.
• Service type — the kind of engagement a suntik service delivers, such as followers, likes, or views.
• Pesanan (Order) — a user's stored request for a suntik service, carrying platform, service, target, quantity, status, and timestamps.
• Target — the social-media account or post an order's engagement is directed at.
• Pengguna (User) — the accepted persona who registers with Google, signs in, orders suntik services, tracks orders, and chats with the admin.
• Admin — the accepted persona holding the account created specifically to manage all features: the suntik catalogue, user orders, and live chat.
• daftar gogel — the registration surface where a person creates a MAHKOTASOSMED account using their Google account.
• Verifikasi capcha — the captcha verification surface that gates registration.
• Masuk — the sign-in surface, with captcha verification, used by both the user and the admin.
• LAYANAN SUNTIK DARI ADMIN — the signed-in user's surface for browsing and ordering admin-provided suntik services.
• Pesanan — the signed-in user's surface for reviewing the status and progress of stored suntik orders.
• LIVE CHAT ADMIN — the persistent conversation surface between the user and the admin.
• Kelola Layanan — the admin-only surface for managing the suntik service catalogue by platform and service type.
• Kelola Pesanan — the admin-only surface for reviewing and managing user suntik orders.
• Captcha — the human-verification challenge required at registration and at sign-in.
• Hazard-stripe band — the repeating 45° orange-and-near-black stripe motif used as section dividers and as the top edge of the live-chat panel.
• Quoted-label motif — the direction's convention of writing every service, platform, and status inside quotation marks on a graphite plate with a 2px bone border.