System Requirements Document for patrickmusic

1. Introduction

patrickmusic is an Android application for listening to music — specifically, a curated catalogue of songs uploaded by a single administrator. The product intent is a private, hand-picked listening room rather than an open music platform: the catalogue is scarce because exactly one account may add to it, and that scarcity is the point.

The audience is a small circle of listeners who consume the admin-curated catalogue, plus the one administrator who curates it. Listeners browse and play the uploaded songs. The administrator — the account signed in with Google as kensquad123ryan@gmail.com — is the only account granted the ability to upload songs. Every other account is listen-only and is never given upload access.

The product is delivered as an Android mobile application, with Google sign-in as the identity mechanism, and the uploaded songs persisted as application data so they remain available to be listened to after upload.

2. System Overview

patrickmusic is a mobile Android application with a first-party custom interface. It has four surfaces: an anonymous Landing page that explains the app, a Login page that performs Google sign-in and establishes which account is signed in, a Songs page where authenticated listeners browse and play the admin-uploaded catalogue, and an Upload page where the single authorized admin account adds songs to that catalogue.

Two human actors use the product. The Listener signs in with Google, browses the catalogue, and plays songs; the Listener never receives upload access. The Admin (kensquad123ryan@gmail.com) signs in with the same Google mechanism, and because the signed-in account matches the designated admin address, the Admin additionally receives the Upload surface and can add songs that then become available to listeners. The distinction between the two actors is not a general role system — it is a single, explicit account gate: upload access is granted only when the Google login is kensquad123ryan@gmail.com, and no other account is given upload access.

Songs uploaded by the Admin are stored as application data and become part of the catalogue that authenticated listeners can browse and play. Playback happens inside the app on the Songs surface, with a persistent now-playing strip.

Narrow exclusions. This document does not add social features, sharing, playlists, recommendations, algorithmic discovery, payments, or any account-management capability beyond Google sign-in and the single admin upload gate. Upload access is restricted to the one designated admin account; no other account receives it.

2a. Product Interpretation and Delivery Boundary

patrickmusic is delivered as a first-party Android application with its own custom interface. Identity is application-owned in the sense that the app must know which Google account is signed in, because that fact alone decides whether the Upload surface is available: the app verifies the signed-in Google account against kensquad123ryan@gmail.com before granting upload access. Google provides the sign-in itself; the app owns the verification and the resulting access decision.

Access is layered. Landing and Login are reachable without being signed in — a visitor can read what the app is and begin Google sign-in. Songs and Upload are protected: they require an authenticated session, and Upload additionally requires that the authenticated account is the designated admin address. A protected surface never owns the interaction that establishes access to itself; the anonymous Landing and Login surfaces carry that entry.

Everything described in this document is current. No future-horizon features are claimed.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous entry surface. States the product's purpose — an Android app for listening to songs that have been uploaded by the admin — and makes clear that the catalogue is curated by one administrator rather than generated. Presents the editorial hero: an oversized headline reading MUSIK YANG DIPILIH, BUKAN DI-ALGORITMA with the word DIPILIH in hot red, set flush left over a full-bleed black field, with a single hard-cropped monochrome photograph bleeding off the right edge behind the headline's last line. No signed-in state is required to view it.
• Primary action: A single red-underlined text link, "Masuk dengan Google", which begins the Google sign-in journey. No button chrome.
• Supporting actions: None beyond the sign-in entry; the page is a statement of what the app is.
• Domain entities: None persisted; the page reads only static product copy.
• Component responsibilities: Hero headline block (Playfair Display, stacked three lines, tight leading, DIPILIH in #FF3B2F); hard-cropped monochrome hero image bled off the right edge and layered behind the type; red-underlined sign-in text link; bottom navigation bar on mobile (Songs / Upload if admin / Profile) that becomes a left-edge vertical rail on tablet and desktop.
• States: Loading — not applicable beyond first paint; the hero headline reveals line-by-line with a 60ms stagger on first paint. Empty — not applicable. Success — the visitor reads the product statement and can proceed to sign in. Error — not applicable to static content. Recovery — with prefers-reduced-motion, the hero renders in its final state with no stagger.

Login

• Information / state: Anonymous identity-access surface. Explains that signing in with Google is required to enter the app, and that the account used determines whether upload access is granted. Shows the signed-in account's Google address once sign-in completes, so the user can see which account is active.
• Primary action: Sign in with Google — starts the Google account chooser and returns the chosen account to the app.
• Supporting actions: Retry sign-in after a failure or cancellation; sign out of the current Google account to sign in with a different one.
• Domain entities: The authenticated session and the signed-in Google account address; the verification result comparing that address against kensquad123ryan@gmail.com.
• Component responsibilities: Google sign-in control; account-address display; verification result handling that routes the authenticated user onward and determines whether the Upload surface is exposed; error and cancellation messaging.
• States: Loading — sign-in in progress, with the sign-in control held in a pending state. Empty — no account signed in yet; the page shows only the sign-in entry. Success — Google returns an account; the app records the session, verifies the address, and continues to Songs (and exposes Upload when the address is the admin address). Error — Google sign-in fails, is cancelled, or returns no account; the page states the failure and offers retry. Recovery — the user retries sign-in, or signs out and chooses a different Google account; no protected content is shown until a session exists.

Songs

• Information / state: Protected listening surface for authenticated users. Presents the catalogue of songs uploaded by the admin as a single-column ruled tracklist — rank number, title, artist, duration — with hairline #2A2A2A rules between rows, monospace-aligned rank numbers in #7A756E, and Playfair Display titles. The currently playing row is marked by a 2px #FF3B2F left rule spanning the full row height. A 72px flat #1A1A1A now-playing strip sits at the bottom with a 48px artwork thumbnail, an Archivo title, and a single circular 64px red play/pause disc pinned to the right.
• Primary action: Play a song from the tracklist; pause and resume from the now-playing disc.
• Supporting actions: Browse and scroll the tracklist; long-press (mobile) or hover (desktop) a row to swap its artwork to a monochrome duotone version and reveal the artist name in Playfair italic.
• Domain entities: Song (title, artist, duration, artwork or duotone placeholder, rank position, upload date); playback state (current song, playing/paused); the authenticated listener session.
• Component responsibilities: Tracklist index with rank numbers and hairline rules; active-row red rule; now-playing strip with thumbnail, title, and circular play/pause disc; artwork rendering with monochrome duotone placeholder (track initial in Playfair at 200px, #2A2A2A on #0E0E0E) when no artwork exists; empty-catalogue messaging.
• States: Loading — the catalogue is being fetched; the tracklist area shows a loading state. Empty — no songs have been uploaded yet; the page states that the catalogue is empty and that songs appear once the admin uploads them. Success — the tracklist renders and a selected song plays, with the now-playing strip sliding up once (280ms ease-out) and staying put. Error — the catalogue fails to load, or a selected song fails to play; the page states the failure and offers retry. Recovery — retry loading the catalogue or retry playback; the previously selected row and playback position are preserved where possible.

Upload

• Information / state: Protected admin-only surface, reachable only when the signed-in Google account is kensquad123ryan@gmail.com. Announced by a 1px red top border across the entire viewport and a micro-label "ADMIN · kensquad123ryan@gmail.com" in 11px uppercase Archivo with 0.18em tracking — the account is named on screen, not hidden behind a generic badge. Presents a full-bleed drop zone occupying the top 60vh with the file picker as a single red-underlined text action, and lists the songs already uploaded.
• Primary action: Select an audio file and upload it so it becomes available in the catalogue.
• Supporting actions: Review the list of already-uploaded songs; retry a failed upload.
• Domain entities: Song being uploaded (audio file, title, artist, artwork if provided); the uploaded-song record persisted as application data; the verified admin account identity.
• Component responsibilities: Full-bleed drop zone; red-underlined file-picker text action; upload progress and result reporting; uploaded-song list; admin identity banner (red top border plus micro-label); access-denied handling for any non-admin account that reaches this surface.
• States: Loading — an upload is in progress, with progress reported. Empty — no songs uploaded yet; the drop zone is the only content. Success — the song is stored as application data and appears in the uploaded-song list and in the Songs catalogue for listeners. Error — the file is rejected, the upload fails, or the signed-in account is not the admin address; the page states the reason and offers retry, and a non-admin account is denied access to the surface. Recovery — retry the upload with the same or a different file; re-verify the signed-in account before any further upload attempt.

3. Functional Requirements

FR-1 — Listen to songs in the Android app (explicit) As a Listener, I should listen to songs inside the patrickmusic Android app, so that I can enjoy the curated catalogue on my Android device.

• Trigger / input: The Listener opens the app and selects a song.
• Observable result: The selected song plays inside the app, with the now-playing strip showing its artwork thumbnail and title and the circular red play/pause disc controlling playback.
• Access state: Requires an authenticated session; the Songs surface is protected.
• Failure / recovery: If playback fails, the app states the failure and offers retry; the selected row remains marked.
• Continuation: The Listener can pause, resume, or select another song from the tracklist.

FR-2 — Only admin-uploaded songs are available to listen to (explicit) As a Listener, I should only be able to listen to songs that were uploaded by the admin, so that the catalogue stays the admin's curated selection.

• Trigger / input: The Listener opens the Songs surface.
• Observable result: The tracklist contains exactly the songs the admin has uploaded and stored as application data; no other source contributes songs.
• Access state: Requires an authenticated session.
• Failure / recovery: If the catalogue fails to load, the app states the failure and offers retry.
• Continuation: The Listener browses the tracklist and plays any listed song.

FR-3 — Admin is the Google account kensquad123ryan@gmail.com (explicit) As the Admin (kensquad123ryan@gmail.com), I should be recognized as the admin only when I sign in with Google using kensquad123ryan@gmail.com, so that admin identity is bound to that exact account.

• Trigger / input: A user completes Google sign-in.
• Observable result: The app compares the signed-in Google account address against kensquad123ryan@gmail.com and records the result; the Upload surface is exposed only when the addresses match.
• Access state: The comparison happens after authentication and governs access to the Upload surface.
• Failure / recovery: If the address does not match, the account is treated as a non-admin listener and no upload access is granted.
• Continuation: A matching account proceeds to upload; a non-matching account continues to the Songs catalogue.

FR-4 — Only the admin account may upload songs (explicit) As the Admin (kensquad123ryan@gmail.com), I should be the only account able to upload songs, so that the catalogue remains under my sole curation.

• Trigger / input: The Admin selects an audio file on the Upload surface and confirms the upload.
• Observable result: The song is stored as application data and appears in the uploaded-song list and in the Songs catalogue.
• Access state: The Upload surface is available only when the signed-in Google account is kensquad123ryan@gmail.com.
• Failure / recovery: If the upload fails, the app states the reason and offers retry.
• Continuation: The Admin can upload further songs or review the uploaded-song list.

FR-5 — No upload access for any other account (explicit) As a Listener, I should never be given access to upload songs, so that only the designated admin can add to the catalogue.

• Trigger / input: Any signed-in account other than kensquad123ryan@gmail.com uses the app.
• Observable result: The Upload surface is not available to that account, and any attempt to reach it is denied with a clear statement that upload access is restricted to the admin account.
• Access state: Applies to every account whose Google address is not kensquad123ryan@gmail.com.
• Failure / recovery: The denied account is returned to the Songs catalogue and can continue listening.
• Continuation: The Listener continues browsing and playing songs.

FR-6 — Sign in with Google before accessing app features (required_inference) As a Listener, I should sign in with Google before accessing the app's features, so that the app knows which account is using it.

• Trigger / input: An unauthenticated visitor selects "Masuk dengan Google" on the Landing page or the sign-in control on the Login page.
• Observable result: Google returns an account, the app records the authenticated session, and the user is taken to the Songs catalogue.
• Access state: Landing and Login are reachable anonymously; Songs and Upload require the resulting session.
• Failure / recovery: If sign-in fails or is cancelled, the Login page states the failure and offers retry; no protected content is shown.
• Continuation: After a successful sign-in the user proceeds to Songs, and the Upload surface is exposed only if the account is the admin address.

FR-7 — Verify the signed-in Google account before granting upload access (required_inference) As the Admin (kensquad123ryan@gmail.com), I should have my signed-in Google account verified against kensquad123ryan@gmail.com before upload access is granted, so that upload access cannot be obtained by any other account.

• Trigger / input: A signed-in user reaches the point where upload access would be granted.
• Observable result: The app compares the signed-in Google address against kensquad123ryan@gmail.com; on a match the Upload surface is exposed and announced with the admin identity banner, and on a mismatch access is denied.
• Access state: Runs after authentication and before any upload interaction.
• Failure / recovery: A mismatch denies access and returns the user to Songs; a verification failure states the problem and allows retry.
• Continuation: A verified admin proceeds to upload; a non-admin continues listening.

FR-8 — Listeners must be authenticated before browsing and playing (required_inference) As a Listener, I should be authenticated before I can browse and play songs, so that the catalogue is available only to signed-in users.

• Trigger / input: An unauthenticated visitor attempts to reach the Songs catalogue.
• Observable result: The visitor is directed to sign in with Google; the catalogue is shown only once a session exists.
• Access state: Songs is protected; Landing and Login remain anonymously reachable.
• Failure / recovery: If sign-in fails or is cancelled, the visitor remains on the Login page with a stated failure and a retry option.
• Continuation: After signing in, the Listener reaches the Songs catalogue and can play songs.

FR-9 — Uploaded songs persist as application data (required_inference) As the Admin (kensquad123ryan@gmail.com), I should have each uploaded song stored as application data, so that it remains available to be listened to after upload.

• Trigger / input: The Admin completes an upload on the Upload surface.
• Observable result: The song is persisted with its title, artist, duration, and artwork (or duotone placeholder), and appears in the uploaded-song list and in the Songs catalogue.
• Access state: Writing requires the verified admin session; reading the catalogue requires an authenticated session.
• Failure / recovery: If persistence fails, the app states the failure and offers retry; the song is not presented as available.
• Continuation: The persisted song is immediately available to listeners on the Songs surface.

4. User Personas

Listener

The Listener is a general user of the patrickmusic Android app whose goal is to hear the music the admin has chosen. Their context is a curated, deliberately small catalogue: they cannot add to it, and they know the selection is someone else's editorial decision. Their primary goal is to browse the tracklist and play songs.

Their distinct accepted responsibilities are browsing the catalogue and playing songs. They sign in with Google — the same mechanism the admin uses — but the account they use is not kensquad123ryan@gmail.com, so the app never exposes the Upload surface to them. Their relevant inputs are their Google account choice and their selection of a track; their relevant decision is which song to play next. They interact with the Admin only indirectly: the songs they see and hear are the ones the Admin uploaded, and the catalogue's contents are entirely the Admin's doing. Their observable success is that a selected song plays, the now-playing strip shows its artwork and title, and the currently playing row is marked with the red left rule.

What makes the Listener's work different from the Admin's is that it is purely consumptive and gated: the Listener's entire lifecycle is sign in, browse, play, and continue — with upload access structurally unavailable rather than merely hidden.

Admin (kensquad123ryan@gmail.com)

The Admin is the single account authorized to curate the catalogue, identified by the Google login kensquad123ryan@gmail.com. Their context is ownership: the catalogue exists because they upload to it, and its scarcity is a direct consequence of their exclusive access. Their primary goal is to add songs so that listeners can hear them.

Their distinct accepted responsibilities are signing in with Google, uploading songs so they become available to listeners, and reviewing the songs already uploaded. Their relevant inputs are the audio files they choose and the song details that accompany them; their relevant decision is what enters the catalogue. They interact with Listeners by supplying the entire catalogue those Listeners consume — every song a Listener can play arrived through the Admin's upload. Their observable success is that an uploaded song is stored as application data and then appears in the Songs catalogue, where listeners can play it.

What makes the Admin's work different from the Listener's is that it is productive and gated by identity rather than by interface: the Upload surface is exposed only after the app verifies that the signed-in Google account is kensquad123ryan@gmail.com, and the surface announces that account on screen with a red top border and the micro-label "ADMIN · kensquad123ryan@gmail.com".

5. Core User Flows

Flow A — Listener signs in and plays a song

1. Starting context: The Listener has installed patrickmusic on an Android device and has not signed in. They open the app and land on the anonymous Landing page, which states that this is an app for listening to songs uploaded by the admin, under the headline MUSIK YANG DIPILIH, BUKAN DI-ALGORITMA.
2. The Listener taps the red-underlined text link "Masuk dengan Google" and arrives at the Login page.
3. On Login, the Listener taps Sign in with Google and chooses their Google account in the Google account chooser. (Owner: Google sign-in, initiated from the Login page.)
4. Observable result: Google returns the chosen account; the app records the authenticated session and shows the signed-in account address on the Login page. The app compares the address against kensquad123ryan@gmail.com; it does not match, so the account is a Listener and no upload access is granted.
5. The Listener is taken to the Songs page, which renders the catalogue as a single-column ruled tracklist — rank number, title, artist, duration — with hairline rules between rows.
6. The Listener selects a song. Observable result: the now-playing strip slides up once (280ms ease-out) and stays put, showing a 48px artwork thumbnail and the Archivo title, with the circular 64px red play/pause disc pinned to the right; the playing row is marked by a 2px #FF3B2F left rule spanning the full row height.
7. Continuation: The Listener pauses or resumes with the red disc, or selects another song. The Listener may long-press a row to swap its artwork to a monochrome duotone version and reveal the artist name in Playfair italic.
8. Material failure / recovery: If the catalogue fails to load, the Songs page states the failure and offers retry. If a selected song fails to play, the app states the failure and offers retry while keeping the row marked. If sign-in fails or is cancelled at step 3, the Login page states the failure and offers retry, and no protected content is shown.

Flow B — Listener is denied upload access

1. Starting context: The Listener is signed in with a Google account that is not kensquad123ryan@gmail.com and is on the Songs page.
2. The Listener looks for a way to add music. Observable result: the Upload surface is not available to this account — the bottom navigation (or left-edge rail on larger screens) shows Songs and Profile but no Upload entry.
3. If the Listener attempts to reach the Upload surface directly, the app denies access and states that upload access is restricted to the admin account.
4. Continuation: The Listener is returned to the Songs catalogue and continues browsing and playing songs. No upload capability is granted at any point in this flow.

Flow C — Admin signs in and uploads a song

1. Starting context: The Admin opens patrickmusic on an Android device and is not signed in. They arrive at the anonymous Landing page.
2. The Admin taps "Masuk dengan Google", reaches the Login page, and taps Sign in with Google.
3. In the Google account chooser, the Admin selects the account kensquad123ryan@gmail.com. (Owner: Google sign-in, initiated from the Login page.)
4. Observable result: Google returns the account; the app records the session and compares the address against kensquad123ryan@gmail.com. The addresses match, so the app verifies the Admin and exposes the Upload surface.
5. The Admin opens Upload. Observable result: the surface is announced by a 1px red top border across the entire viewport and the micro-label "ADMIN · kensquad123ryan@gmail.com" in 11px uppercase Archivo with 0.18em tracking. The full-bleed drop zone occupies the top 60vh, with the file picker as a single red-underlined text action.
6. The Admin selects an audio file and confirms the upload. Observable result: upload progress is reported, and on completion the song is stored as application data with its title, artist, duration, and artwork (or a duotone placeholder) and appears in the uploaded-song list.
7. Continuation: The Admin can upload further songs or review the uploaded-song list.
8. Material failure / recovery: If the file is rejected or the upload fails, the Upload page states the reason and offers retry; the song is not presented as available. If the signed-in account is not the admin address, access to the surface is denied and the user is returned to Songs.

Flow D — Admin's uploaded song reaches a Listener

1. Starting context: The Admin has completed an upload in Flow C, and the song is stored as application data.
2. A Listener who is signed in opens the Songs page. Observable result: the newly uploaded song appears in the tracklist with its rank number, title, artist, and duration, and the catalogue reflects the Admin's curation.
3. The Listener selects the song. Observable result: the song plays, the now-playing strip shows its artwork thumbnail and title, and the row is marked with the 2px red left rule.
4. Continuation: The Listener continues through the catalogue. Material failure / recovery: if the catalogue fails to refresh or the song fails to play, the app states the failure and offers retry.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. Muse: Tobias van Schneider. Headline direction: Editorial swagger for a curated music room — oversized type, black ground, one hot red. The register is a limited pressing, a listening room, a zine — not a Spotify clone. The admin gate makes the catalogue scarce and therefore precious, and the design must carry that weight.

Color tokens (dark mode):

Typography:

• Headings: Playfair Display at 700–900 weight, tight leading (0.95), tight tracking (-0.02em), sentence case for editorial warmth, with occasional italic for the artist name. Headlines are the primary image of the page and are allowed to be larger than the artwork.
• Body: Archivo at 400/500, generous line-height (1.55), never larger than 17px so the display type keeps its dominance.
• Scale: 1.333 modular scale — display 56px mobile / 128px desktop (clamp), h1 40/72, h2 28/40, h3 20/24, body 16/17, caption 13/12, micro-label 11 uppercase with 0.18em tracking.

Shape language: Sharp corners everywhere — 0px radius on cards, artwork frames, buttons, and the now-playing bar. The only rounded element in the entire app is the circular play button (a 64px disc), which reads as a physical transport control against the otherwise rectangular, editorial layout. Hairline 1px rules in #2A2A2A divide rows and sections; no shadows, no elevation, no glass.

Layout: Asymmetric editorial grid — a 12-column base where content is deliberately offset. The featured track's artwork sits in columns 1–7 and its oversized title spills into columns 5–12, allowed to overlap the artwork's right edge. The Songs list is a single-column ruled index (rank number, title, artist, duration) like a tracklist on a record sleeve, not a card grid. The Upload page is a full-bleed drop zone occupying the top 60vh with the file picker as a single red-underlined text action. Navigation is a bottom bar on mobile (Songs / Upload if admin / Profile) that becomes a left-edge vertical rail on tablet and desktop, with the active item marked by a 2px red vertical rule rather than a pill.

Imagery: Album artwork is the only photography, treated as full-bleed editorial images with generous black margins around them — never inside a card with a border. Where no artwork exists, a monochrome duotone placeholder (the track's initial set in Playfair at 200px, in #2A2A2A on #0E0E0E) stands in. No stock people, no gradients, no blobs, no device mockups. The landing hero uses one large monochrome image (a hand on a turntable, a speaker cone, a cassette — anything tactile and cropped hard) bled off the right edge.

Avoid: Any blue or indigo accent; rounded cards, soft shadows, hover-lift grids, or any card treatment for the tracklist; gradient blobs, glassmorphism, or translucent panels; Inter, Roboto, Poppins, or any neutral geometric sans as the display face; album artwork inside a bordered card with a caption below it; a centred hero with headline + subtext + button stacked in the middle; waveform visualisers, equaliser bars, or any animated audio-reactive decoration; stock photography of people, headphones, or concert crowds. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Readable text and controls stay whole at every viewport: headlines, wordmarks, labels, numbers, 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 and decoration may be cropped, bled off an edge, or overlapped exactly as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The public entry is a full-bleed black field that reads as a record sleeve rather than a landing page. On the left, an oversized Playfair Display headline — "MUSIK YANG DIPILIH, BUKAN DI-ALGORITMA" — is set at 56px on mobile and 128px on desktop, stacked in three lines, flush left, with tight leading, and the word "DIPILIH" in #FF3B2F. To the right, a single monochrome photograph is cropped hard against the right viewport edge and bleeds off-screen, sitting behind the headline's last line so the type crosses over the image — type on top, image behind, the image covering no readable text. Beneath the headline sits a single red-underlined text link, "Masuk dengan Google", with no button chrome.

The composition is asymmetric and dominated by the type. It could not be mistaken for a centred SaaS hero, and it carries the product's actual argument: this catalogue was chosen by a person, not generated. The only chromatic event on the page is the red of DIPILIH and the underline of the sign-in link — under 5% of the screen, which is exactly the point.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The oversized Playfair Display headline MUSIK YANG DIPILIH, BUKAN DI-ALGORITMA, with DIPILIH in #FF3B2F, layered over a single hard-cropped monochrome photograph that bleeds off the right viewport edge.
• Input → transformation → outcome thesis: On first paint, the headline reveals line-by-line with a 60ms stagger, so the visitor's eye is walked down the three lines in reading order; the monochrome image is already in place behind the last line. The outcome is a composed first frame in which the type is the primary image and the sign-in link is the single available action — no motion is required to understand or use the page.
• Motion vocabulary: Slow crossfades (400–600ms) between routes; line-by-line headline reveal with 60ms stagger on first paint; artwork scales from 0.98 to 1 on scroll-in; no bounce, no spring, no hover-lift on cards — hover swaps artwork to a monochrome version instead; the now-playing bar slides up once (280ms ease-out) when a track starts and stays put; section transitions are full-width black wipes (a #0E0E0E panel slides across in 400ms) rather than fades, so navigation feels like turning a page in a zine.
• Composed first frame: Black field, three stacked lines of Playfair Display flush left with DIPILIH in red, the monochrome photograph cropped hard at the right edge behind the final line, and the red-underlined "Masuk dengan Google" link beneath — everything in its final position.
• Reduced-motion state: With prefers-reduced-motion, everything renders in its final state: no stagger, no crossfade, no wipe, no scroll-in scale. The hero is fully legible and the sign-in link is fully usable with no motion at all.

9. Non-Functional Requirements

NFR-1 — Android platform (explicit) The application is delivered as an Android mobile application. Rationale: the user explicitly requested an Android app, and the planning scope records the Android platform as an explicit hard constraint.

NFR-2 — Google sign-in as the identity mechanism (explicit) Authentication is performed through Google sign-in. Rationale: the user's requirement is conditioned on "google login admin kensquad123ryan@gmail.com", which makes Google the identity provider for the app.

NFR-3 — Upload authorization is bound to a single account address (explicit) Upload access is granted only when the signed-in Google account is kensquad123ryan@gmail.com; every other account is denied upload access. Rationale: this is the explicit hard constraint in the authoritative user evidence and the central product rule.

NFR-4 — Uploaded songs persist as application data (required_inference) Songs uploaded by the admin are stored as application data so they remain available to be listened to after upload. Rationale: without persistence, an accepted outcome — listeners hearing admin-uploaded songs — could not be delivered.

NFR-5 — Readable text and controls remain whole at every viewport (explicit, from creative direction) Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering them. Rationale: stated as a hard readability rule in the creative direction.

NFR-6 — Reduced-motion support (explicit, from creative direction) The interface respects prefers-reduced-motion by rendering everything in its final state, with a usable static arrangement. Rationale: stated in the creative direction's motion and readability rules.

NFR-7 — No blue or indigo accent (explicit, from creative direction) The palette contains exactly one chromatic colour, #FF3B2F; blue and indigo accents are excluded, and the generic indigo/blue-on-white SaaS template is forbidden. Rationale: stated as an explicit exclusion in the creative direction.

10. Tech Stack

• Client: Android mobile application with a first-party custom interface. (explicit — the user requested an Android app; the planning scope records custom UI as the delivery shape.)
• Identity: Google sign-in, used to authenticate users and to determine whether the signed-in account is kensquad123ryan@gmail.com. (explicit)
• Backend integration: Required to support authentication, song storage, and catalogue retrieval. (required_inference — the planning scope records requires_backend_integration: true, and the accepted journeys require songs to be stored and served.)
• Storage: Application data storage for uploaded songs and their metadata (title, artist, duration, artwork), so the catalogue persists and remains available to listeners. (required_inference)

11. Assumptions and Constraints

Constraints

• C-1 (explicit): Upload access is granted only when the Google login is kensquad123ryan@gmail.com; no other account is given upload access.
• C-2 (explicit): The application is an Android mobile application.
• C-3 (explicit, from creative direction): The palette is dark mode with background #0E0E0E, surface #1A1A1A, text #F5F1EA, primary and accent #FF3B2F, muted #7A756E, and hairline rules #2A2A2A. Red is used at under 5% of the screen at any time.
• C-4 (explicit, from creative direction): Headings use Playfair Display at 700–900 weight; body copy uses Archivo at 400/500 and never exceeds 17px.
• C-5 (explicit, from creative direction): Corners are sharp (0px radius) everywhere except the single circular 64px play button; there are no shadows, no elevation, and no glass.
• C-6 (explicit, from creative direction): No blue or indigo accent, no rounded cards, no gradient blobs, no glassmorphism, no waveform or equaliser decoration, and no stock photography of people, headphones, or concert crowds.

Assumptions

• A-1 (required_inference): The app must know which Google account is signed in, because that single fact decides whether the Upload surface is available. Identity is therefore application-owned for the purpose of this access decision; Google provides the sign-in itself.
• A-2 (required_inference): Landing and Login are reachable without being signed in, because a protected surface cannot own the interaction that establishes access to itself. Songs and Upload are protected.
• A-3 (required_inference): Songs uploaded by the admin are stored as application data and served to authenticated listeners; this is the minimum mechanic needed for the accepted outcome that listeners hear admin-uploaded songs.
• A-4 (required_inference): The distinction between the Admin and the Listener is a single explicit account gate on kensquad123ryan@gmail.com, not a general role or permission system. No differentiated permissions beyond this gate are assumed.
• A-5 (required_inference): The Upload surface is exposed only after the signed-in account is verified against kensquad123ryan@gmail.com, and it announces that account on screen rather than hiding it behind a generic badge.

12. Glossary

• patrickmusic — The Android application described by this document, for listening to songs uploaded by the admin.
• Admin — The single account authorized to upload songs, identified by the Google login kensquad123ryan@gmail.com.
• Listener — A general user of the app who signs in with Google, browses the catalogue, and plays songs, and who is never granted upload access.
• Catalogue — The set of songs uploaded by the Admin and available to authenticated listeners on the Songs surface.
• Upload surface — The admin-only page where the Admin selects an audio file and adds it to the catalogue.
• Tracklist — The single-column ruled index on the Songs page showing rank number, title, artist, and duration, with hairline rules between rows.
• Now-playing strip — The 72px flat #1A1A1A bar at the bottom of the Songs page containing a 48px artwork thumbnail, an Archivo title, and the circular 64px red play/pause disc.
• Duotone placeholder — The monochrome stand-in used when a track has no artwork: the track's initial set in Playfair at 200px, in #2A2A2A on #0E0E0E.
• Admin identity banner — The 1px red top border across the viewport plus the micro-label "ADMIN · kensquad123ryan@gmail.com" in 11px uppercase Archivo with 0.18em tracking that announces the Upload surface.