System Requirements Document for purple-pemutar

1. Introduction

purple-pemutar is a personal music player application. The user's request is direct and complete: build a music player modeled on a referenced image ("Poto ini"), and make sure every feature works properly. The referenced image was not attached to the request, so its visual and structural intent is carried by the project's authoritative creative direction — a glossy, curved, sensual-pop-minimalist purple player — rather than by literal pixel reproduction.

The product intent is therefore twofold and equally binding:

1. A working music player. A listener can see the available music, choose a track, start and pause playback, seek within the current track, and control playback volume — and every one of those controls responds correctly and predictably.
2. A player that looks and feels like the referenced object. Glossy candy surfaces, organic curves, a violet/magenta material palette, capsule controls with top-edge gloss, a chunky magenta playhead knob, and a shelf of unique two-tone album blobs — not a generic blue-on-white app shell.

Audience. The audience is anyone who wants playback to feel like a treat: tactile, colourful, low-friction. The single accepted active human role is the Music Listener — a person playing audio tracks and operating the player's controls. The emotional register is playful confidence and physical delight, not utility or productivity.

2. System Overview

purple-pemutar is a browser-delivered, single-user music player with four first-party surfaces:

Actors. One accepted active human persona: Music Listener. There are no other human roles, no administrators, no moderators, and no second participant whose state is changed by playback. Audio output is a device/system capability, not a persona.

Accepted behavior. Track selection from a library; play and pause of the current track; seeking to a position within the current track; volume adjustment; and continuous, readable feedback of what is playing and how far along it is. Every control must function correctly — this is an explicit hard constraint, not a quality aspiration.

Ownership. All four surfaces are application-owned custom pages. Playback itself is executed by the browser's audio capability under the application's control; the application owns the transport state, the current-track identity, the playback position, and the volume level.

Narrow exclusions. This document does not add accounts, sign-in, user profiles, social features, sharing, playlists, search, recommendations, uploads, purchases, lyrics, or any server-side music catalogue. None of these were requested, and the accepted page contract contains no surface for them.

2a. Product Interpretation and Delivery Boundary

Delivery. purple-pemutar is delivered as a first-party web application. The listener opens it in a browser and uses it immediately. There is no install step, no companion app, and no external service the listener must visit to play music.

Access ownership. All four accepted surfaces are reachable without establishing an identity. The listener's work — choosing a track, playing it, seeking, and setting volume — is a single continuous session of listening, not a durable relationship that must be bound to a returning person. No accepted journey requires the listener to be recognized on a later visit, to resume private state, or to receive a commitment, entitlement, or value transfer tied to their identity. Accordingly, no application-owned identity, sign-in, or account establishment is introduced, and no surface is protected. This is consistent with the accepted access contract for every page.

Current vs. future. Everything described in Sections 2c, 3, and 5 is current. Nothing in this document is deferred. The player must work correctly now, in the current delivery.

2b. Source Content Inventory

Not applicable. No reference directive declares content_source; the referenced image supplies visual inspiration and structure reference only, and was not attached. No factual entity, collection item, field, value, date, contact, link, or media reference is supplied by an authoritative content source, so no inventory is rendered and no dummy catalogue facts are invented here. The concrete track list is a runtime data concern of the Music Library (see Section 2c), not a source-supplied content set.

2c. Page Content and Component Coverage

Landing

• Information and state. The public entry surface. Presents the lowercase wordmark purple-pemutar in Comfortaa, a short statement of what the player is and who it is for, and a truthful summary of its working capabilities (play, pause, seek, volume). Shows a small "now playing" chip with a live progress ring reflecting the current track and position, or an idle state when nothing has been started.
• Primary action. A magenta play capsule pinned beneath the wordmark that immediately starts the first track and moves the listener into active playback.
• Supporting actions. A link into the Music Library to choose a different track; a link into the Player to view the active track; a link into Volume.
• Domain entities. Current track (title, blob identity), playback position, playback state (idle / playing / paused).
• Component responsibilities. Hero composition (oversized glossy violet blob bleeding off the right edge, lowercase stacked wordmark left, magenta play capsule beneath); animated magenta waveform along the bottom edge; now-playing chip with progress ring; navigation into the other three surfaces.
• States.
  • Loading: hero renders immediately; the now-playing chip shows a neutral placeholder until playback state is known.
  • Empty: no track has been started — the chip reads as idle and the play capsule is the clear next action.
  • Success: the play capsule starts the first track; the chip switches to the track title with a live progress ring; the listener is offered a route into the Player.
  • Error: if the first track cannot be started (no playable source, or the browser blocks audio), the capsule returns to its idle appearance and an inline message states plainly that playback could not start, with a retry action.
  • Recovery: retry re-attempts the same track; the listener can also go to the Music Library and choose another track.

Music Library

• Information and state. The available music list. Each track appears as a rounded row (or, at 1280px, a card in a two-column grid) carrying a unique two-tone gradient blob generated from the track title, the track title, and secondary metadata in muted lilac. The currently playing track is marked with the hot-magenta active marker.
• Primary action. Select a track to play it.
• Supporting actions. A play capsule on each row to start that track directly; a route into the Player for the active track; a route into Volume.
• Domain entities. Track (title, metadata, blob identity derived from title hash), current track, playback state.
• Component responsibilities. Track list/grid; per-track blob chip; per-track play capsule; active-track marker; empty-state panel.
• States.
  • Loading: rows render as rounded skeleton placeholders in the surface colour while the list resolves.
  • Empty: no tracks are available — a clear panel states that the library is empty and that there is nothing to play yet.
  • Success: the list renders; selecting or pressing a row's play capsule starts that track and marks the row active.
  • Error: if a selected track cannot be played, the row shows an inline failure note and the previously playing track's state is left intact rather than silently cleared.
  • Recovery: the listener selects another track; the failed row remains selectable for a retry.

Player

• Information and state. The active track's full presentation: a blob-shaped album-art frame at the top, the track title, the scrubber as a thick pill across the width, elapsed and total time, and the transport controls in a centred row of capsules. Reflects playing or paused state truthfully at all times.
• Primary action. Play / pause the current track.
• Supporting actions. Seek by dragging the chunky magenta playhead knob along the scrubber; seek by keyboard on the focused scrubber; skip to the previous or next track in the library; route into the Music Library; route into Volume.
• Domain entities. Current track, playback position, track duration, playback state, queue position within the library.
• Component responsibilities. Album blob frame; title and metadata block; pill scrubber with magenta playhead knob and violet→magenta gradient fill; elapsed/total time readout; transport capsule row; idle gloss sweep across the player slab.
• States.
  • Loading: the slab renders with the blob frame and a disabled transport row until the track's duration is known.
  • Empty: no track is loaded — the slab shows a neutral blob and a prompt to choose a track from the Music Library.
  • Success: the track plays; the scrubber fills with the shifting gradient; the playhead knob tracks position; pause freezes position and the knob stays where it was.
  • Error: if playback fails mid-track, the transport returns to a paused appearance, the position is retained, and an inline message states that playback stopped, with a retry action.
  • Recovery: retry resumes from the retained position; the listener may also seek to a different position or choose another track.

Volume

• Information and state. A focused surface with one oversized circular dial carrying a visible gloss arc, plus a numeric readout of the current level in Quicksand 700. Reflects the live volume level.
• Primary action. Set the playback volume by dragging the dial.
• Supporting actions. Adjust the level with arrow keys when the dial is focused; mute and unmute; return to the Player or the Music Library.
• Domain entities. Volume level (0–100), mute state.
• Component responsibilities. Oversized dial with gloss arc; numeric readout; mute toggle capsule; navigation back to Player and Library.
• States.
  • Loading: the dial renders at the last known level; the readout shows a neutral placeholder until the level is confirmed.
  • Empty: not applicable — volume always has a value; the dial renders at its current level.
  • Success: dragging or arrowing the dial changes the level immediately and audibly; the readout updates in step; the gloss arc follows the level.
  • Error: if the level cannot be applied, the dial snaps back to the last applied value and an inline message states that the volume change did not take effect.
  • Recovery: the listener retries the adjustment; the previously applied level remains in force throughout.

3. Functional Requirements

Each requirement below is a distinct story point. Provenance is marked explicit (stated by the user), basic_default (accepted default), or required_inference (indispensable mechanics for an accepted outcome).

FR-1 — See the available music. As a Music Listener, I should see the list of available tracks so that I can choose what to play.

• Provenance: required_inference (indispensable prerequisite for selecting a track).
• Trigger/input: opening the Music Library.
• Observable result: a list of tracks, each with a title, secondary metadata, and a unique two-tone gradient blob derived from the track title.
• Access state: reachable without establishing an identity.
• Failure/recovery: if the list cannot be resolved, an empty-state panel states that there is nothing to play; the listener can retry.
• Continuation: selecting a track moves the listener into playback.
• Owner: Music Library.

FR-2 — Select a track to play. As a Music Listener, I should select a track from the library so that it becomes the current track and begins playing.

• Provenance: explicit (the user asked for a working music player).
• Trigger/input: pressing a track row or its play capsule.
• Observable result: the selected track becomes the current track, playback begins, and the row is marked with the hot-magenta active marker.
• Access state: reachable without establishing an identity.
• Failure/recovery: if the track cannot be played, the row shows an inline failure note and the previously playing track's state is left intact; the listener can select another track or retry.
• Continuation: the listener is offered a route into the Player for the active track.
• Owner: Music Library.

FR-3 — Start playback from the entry surface. As a Music Listener, I should start the first track directly from the landing surface so that I can hear music without first browsing.

• Provenance: required_inference (the accepted hero direction pins a play capsule that immediately starts the first track).
• Trigger/input: pressing the magenta play capsule on Landing.
• Observable result: the first track begins playing; the now-playing chip switches to the track title with a live progress ring.
• Access state: reachable without establishing an identity.
• Failure/recovery: if playback cannot start, the capsule returns to its idle appearance and an inline message states that playback could not start, with a retry action.
• Continuation: the listener can move into the Player or the Music Library.
• Owner: Landing.

FR-4 — Play and pause the current track. As a Music Listener, I should play and pause the current track so that I control when audio is running.

• Provenance: explicit (the user asked for a working music player; the accepted Player page owns play and pause).
• Trigger/input: pressing the play/pause capsule on the Player.
• Observable result: audio starts or stops; the transport capsule reflects the true state; on pause the position is retained and the playhead knob stays where it was.
• Access state: reachable without establishing an identity.
• Failure/recovery: if playback fails mid-track, the transport returns to a paused appearance, the position is retained, and an inline message states that playback stopped, with a retry action.
• Continuation: retry resumes from the retained position; the listener may seek or choose another track.
• Owner: Player.

FR-5 — Seek within the current track. As a Music Listener, I should seek to a position within the current track so that I can move to the part I want to hear.

• Provenance: explicit (the accepted Player page owns seeking within the current track).
• Trigger/input: dragging the chunky magenta playhead knob along the pill scrubber, or using keyboard controls on the focused scrubber.
• Observable result: the playback position moves to the chosen point; the scrubber's violet→magenta gradient fill and the elapsed-time readout update in step; the knob scales to 1.15 while grabbed.
• Access state: reachable without establishing an identity.
• Failure/recovery: if the seek cannot be applied, the position returns to the last valid point and the readout stays truthful.
• Continuation: playback continues from the new position.
• Owner: Player.

FR-6 — Move between tracks. As a Music Listener, I should move to the previous or next track so that I can keep listening without returning to the library.

• Provenance: required_inference (indispensable continuation mechanics for a working player with a track list).
• Trigger/input: pressing the previous or next capsule on the Player.
• Observable result: the adjacent track in the library becomes current and plays; the blob frame, title, duration, and scrubber all update.
• Access state: reachable without establishing an identity.
• Failure/recovery: at the ends of the library the control is visibly unavailable rather than silently doing nothing; if the adjacent track cannot be played, the current track's state is left intact and an inline message states the failure.
• Continuation: the listener continues with the new current track.
• Owner: Player.

FR-7 — See what is playing and how far along it is. As a Music Listener, I should see the current track and its progress so that I always know the player's state.

• Provenance: explicit (the accepted surfaces carry a now-playing chip with a live progress ring and a scrubber with elapsed/total time).
• Trigger/input: any playback state change or position change.
• Observable result: the track title, blob identity, elapsed time, total time, and progress fill all reflect the true current state; the active track is marked in the library.
• Access state: reachable without establishing an identity.
• Failure/recovery: when no track is loaded, the surfaces show a truthful idle/empty state rather than a stale title.
• Continuation: the listener acts on the state they see.
• Owner: Player (primary), Landing and Music Library (reflecting the same state).

FR-8 — Adjust playback volume. As a Music Listener, I should set the playback volume so that the music is at a comfortable level.

• Provenance: explicit (the accepted Volume page provides the listener's playback-volume control).
• Trigger/input: dragging the oversized circular dial, or using arrow keys when the dial is focused.
• Observable result: the volume level changes immediately and audibly; the numeric readout in Quicksand 700 updates in step; the gloss arc follows the level.
• Access state: reachable without establishing an identity.
• Failure/recovery: if the level cannot be applied, the dial snaps back to the last applied value and an inline message states that the change did not take effect.
• Continuation: the listener continues listening at the applied level.
• Owner: Volume.

FR-9 — Mute and unmute. As a Music Listener, I should mute and unmute playback so that I can silence audio instantly without losing my level.

• Provenance: required_inference (indispensable companion mechanic to the accepted volume control).
• Trigger/input: pressing the mute toggle capsule on the Volume surface.
• Observable result: audio is silenced or restored; the dial and readout reflect the muted state; the previously set level is preserved and restored on unmute.
• Access state: reachable without establishing an identity.
• Failure/recovery: if mute cannot be applied, the control returns to its previous state and an inline message states the failure.
• Continuation: the listener unmutes and continues at the preserved level.
• Owner: Volume.

FR-10 — Every control responds correctly. As a Music Listener, I should find that every control does what it appears to do so that I can trust the player.

• Provenance: explicit (hard constraint: "pastikan semua berpungsi dengan baik" — all features must work properly).
• Trigger/input: any interaction with any control on any surface.
• Observable result: the control's visible state changes in step with the actual playback state; no control is decorative, inert, or misleading; no control reports a state the player is not in.
• Access state: applies on all four surfaces, all reachable without establishing an identity.
• Failure/recovery: any control that cannot complete its action reports the failure inline and leaves the player in a truthful, usable state.
• Continuation: the listener can always retry or take another action.
• Owner: Landing, Music Library, Player, Volume (all surfaces).

FR-11 — Reach every surface. As a Music Listener, I should move between the entry surface, the library, the player, and the volume control so that I can complete any listening task without getting stuck.

• Provenance: required_inference (indispensable navigation for the accepted four-surface contract).
• Trigger/input: navigation controls on each surface.
• Observable result: each of the four surfaces is reachable from the others; the listener always has a route back to the active track.
• Access state: all four surfaces reachable without establishing an identity.
• Failure/recovery: if a destination cannot be reached, the current surface remains usable and the failure is stated inline.
• Continuation: the listener continues from the destination.
• Owner: Landing, Music Library, Player, Volume.

4. User Personas

Music Listener

Product context. The Music Listener is the sole accepted active human role. They come to purple-pemutar to play audio tracks and operate the player's controls. They are not administering anything, not managing other people, and not maintaining a catalogue — they are listening. The product's whole surface area exists to serve this one continuous activity.

Primary goal. To hear the track they want, at the level they want, with every control responding exactly as it appears to.

Distinct accepted responsibilities.

• Browsing the available music and choosing a track (Music Library).
• Starting playback directly from the entry surface without browsing first (Landing).
• Playing and pausing the current track (Player).
• Seeking to a position within the current track (Player).
• Moving to the previous or next track (Player).
• Reading what is playing and how far along it is (Player, Landing, Music Library).
• Setting the playback volume (Volume).
• Muting and unmuting without losing the set level (Volume).
• Moving between the four surfaces to complete any of the above (all surfaces).

Relevant inputs and decisions. Which track to play; whether to start from the entry surface or browse the library first; when to pause; where in the track to seek; how loud to listen; whether to mute rather than lower the level. Each of these is a direct, immediate decision with an immediately observable result.

Interactions with other accepted participants. None. The Music Listener is the only accepted active human participant, and no other persona's state, commitment, or outcome is changed by playback. Audio output is a device capability the application drives, not a participant. There is no second human whose response must be shown, and this document does not invent one.

Observable success. Audio plays when the listener asks it to; it stops when they ask it to; the position moves where they put it; the volume follows the dial; the surfaces always show the true current track and progress; and no control ever appears to work while doing nothing.

What makes this role's work distinct. The listener's work is entirely sensory and immediate — every action has an audible and visible result within the same moment, and there is no deferred, shared, or approval-bound state anywhere in the product. That is why the player's feedback fidelity (FR-7, FR-10) is as binding as its playback capability: for this role, a control that lies is a broken control.

5. Core User Flows

Flow A — Start listening immediately from the entry surface

1. The Music Listener opens purple-pemutar and lands on Landing. The deep-aubergine field, the oversized glossy violet blob bleeding off the right edge, the lowercase purple-pemutar wordmark stacked left, and the magenta waveform along the bottom edge are all visible. The now-playing chip in the lower left reads as idle.
2. The listener presses the magenta play capsule pinned beneath the wordmark.
3. Observable result: the first track begins playing. The now-playing chip switches to the track title and its progress ring starts advancing. The waveform continues along the bottom edge.
4. Continuation: the listener follows the route into Player to see the full track presentation, or into Music Library to choose something else.
5. Failure/recovery: if the first track cannot be started — no playable source, or the browser blocks audio — the capsule returns to its idle appearance and an inline message states plainly that playback could not start, with a retry action. Retrying re-attempts the same track; the listener can also go to the Music Library and choose another.

Flow B — Choose a track from the library and play it

1. The Music Listener opens Music Library. The available tracks render as rounded rows, each with a unique two-tone gradient blob generated from its title, its title text, and secondary metadata in muted lilac. At 1280px the list becomes a two-column grid of track cards.
2. The listener reads the rows and decides which track to hear.
3. The listener presses that row or its play capsule.
4. Observable result: the chosen track becomes the current track and begins playing; the row is marked with the hot-magenta active marker; the previously active row's marker clears.
5. Continuation: the listener moves into Player for the full presentation, or stays in the library and selects another track.
6. Failure/recovery: if the track cannot be played, the row shows an inline failure note and the previously playing track's state is left intact — the player does not silently go quiet. The listener selects another track or retries the failed one.

Flow C — Play, pause, and seek within the current track

1. The Music Listener is on Player. The blob-shaped album-art frame sits at the top, the track title below it, the thick pill scrubber runs across the width with the chunky magenta playhead knob on it, elapsed and total time are shown, and the transport capsules sit centred below.
2. The listener presses the play/pause capsule to pause.
3. Observable result: audio stops. The transport capsule reflects the paused state. The position is retained and the playhead knob stays exactly where it was.
4. The listener grabs the magenta playhead knob and drags it along the scrubber to the point they want.
5. Observable result: the knob scales to 1.15 while grabbed. The scrubber's violet→magenta gradient fill and the elapsed-time readout update in step with the drag. On release, the position is set to the chosen point.
6. The listener presses play again.
7. Observable result: playback resumes from the chosen position. The gradient fill continues shifting hue as the track advances.
8. Continuation: the listener keeps listening, seeks again, or moves to another track.
9. Failure/recovery: if playback fails mid-track, the transport returns to a paused appearance, the position is retained, and an inline message states that playback stopped, with a retry action. Retry resumes from the retained position. If a seek cannot be applied, the position returns to the last valid point and the readout stays truthful.

Flow D — Move to the previous or next track

1. The Music Listener is on Player with a track playing.
2. The listener presses the next capsule.
3. Observable result: the adjacent track in the library becomes current and plays. The blob frame, title, duration, and scrubber all update to the new track.
4. Continuation: the listener keeps listening, or presses previous to go back.
5. Failure/recovery: at the ends of the library the control is visibly unavailable rather than silently doing nothing. If the adjacent track cannot be played, the current track's state is left intact and an inline message states the failure.

Flow E — Set the playback volume

1. The Music Listener opens Volume. One oversized circular dial fills the surface with a visible gloss arc, and the numeric readout in Quicksand 700 shows the current level.
2. The listener drags the dial, or focuses it and uses the arrow keys.
3. Observable result: the volume changes immediately and audibly. The numeric readout updates in step. The gloss arc follows the level.
4. Continuation: the listener returns to Player or Music Library and continues listening at the applied level.
5. Failure/recovery: if the level cannot be applied, the dial snaps back to the last applied value and an inline message states that the volume change did not take effect. The previously applied level remains in force throughout.

Flow F — Mute and unmute without losing the level

1. The Music Listener is on Volume with the level set where they want it.
2. The listener presses the mute toggle capsule.
3. Observable result: audio is silenced. The dial and readout reflect the muted state. The previously set level is preserved.
4. The listener presses the mute toggle again.
5. Observable result: audio is restored at exactly the preserved level.
6. Continuation: the listener continues listening.
7. Failure/recovery: if mute cannot be applied, the control returns to its previous state and an inline message states the failure.

Flow G — Confirm the player is telling the truth

1. At any point during any of the flows above, the Music Listener looks at the now-playing chip on Landing, the active marker in Music Library, or the scrubber and time readout on Player.
2. Observable result: all three reflect the same true current track and position. No surface shows a stale title, a frozen progress ring, or an active marker on a track that is not playing.
3. Continuation: the listener acts on what they see, confident that the control will do what it appears to do.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. It names Karim Rashid as the muse and the headline idea is sensual pop minimalism for a purple music player — glossy, curved, optimistic. The player must read as a designed object you want to touch: the playhead, the knob, and the buttons are physical things, not UI chrome.

Color tokens — dark mode

Colour is used generously as material. Panels are coloured, not white cards on white. The progress bar fills with a magenta-to-violet gradient that shifts hue as the track advances.

Typography

• Headings: Comfortaa, 700 weight, generous tracking, soft terminals. Set large and confident. The project wordmark is lowercase — purple-pemutar — to feel friendly and toy-like.
• Body: Quicksand.
• Scale: 1.333 modular — 56 / 42 / 32 / 24 / 18 / 16.
• Display sizes: clamp(40px, 8vw, 96px) for the hero wordmark; clamp(28px, 5vw, 48px) for section titles; 16px body; 13px micro-labels.
• Numeric readouts (volume level, elapsed/total time) use Quicksand 700.

Shape language

Organic curves everywhere. Capsule buttons, pill sliders, blob-shaped album-art frames, soft 24–40px radii, and a glossy highlight on the top edge of every control. No sharp corners. The player is a single curved slab with a thumb-sized playhead knob and a circular volume dial with a visible gloss arc.

Layout

• Landing: single-column, centred, generous vertical rhythm.
• Player: a full-viewport glossy slab — album blob at the top, the scrubber as a thick pill across the width, transport controls in a centred row of capsules.
• Library: a vertical stack of rounded track rows with a colour-chip on the left and a play capsule on the right.
• Volume: its own focused surface with one oversized dial.
• Breakpoints: at 375px everything stacks full-width with 16px gutters; at 768px the player slab is max 640px; at 1280px the library becomes a 2-column grid of track cards while the player remains a single centred slab.

Imagery

Glossy 3D blobs and rounded album-art chips rendered as CSS/SVG gradients — no photography. Each track gets a unique two-tone blob (violet + magenta + a rotating third hue) generated from its title hash, so the library feels like a shelf of candy objects rather than a list of files.

Readability rule

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

7. Signature Design Concept

The candy slab and the bleeding blob.

The public entry is a full-bleed deep-aubergine field (#1A0B2E). A single oversized glossy violet blob sits off-centre right and bleeds past the viewport edge — it is decoration, so it may be cropped exactly as the direction asks, and it never covers the wordmark or the play capsule. The wordmark purple-pemutar is set lowercase in Comfortaa at clamp(40px, 8vw, 96px), stacked in two lines on the left. A magenta play capsule (#FF6EC7) is pinned beneath it and immediately starts the first track. A thin animated waveform in #FF6EC7 runs along the bottom edge. A small "now playing" chip with a live progress ring sits in the lower left.

There is no centred headline, no gradient-blob-with-button composition, and no blue button. The composition is asymmetric, colour-led, and tactile.

The concept carries through the rest of the product as one material system: every control is a capsule with a top-edge gloss highlight — buttons, sliders, tabs, and the volume dial all share it. The playhead is a chunky magenta knob on a thick pill scrubber; grabbing it scales it to 1.15 and the filled portion shifts hue from violet to magenta as the track advances. The Library renders each track as a rounded row with a unique two-tone gradient blob generated from the track title, so no two rows look alike. The Volume surface is one oversized circular dial with a visible gloss arc, rotated by drag or arrow keys, with a numeric readout in Quicksand 700.

This concept only recomposes accepted content, states, and controls. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject. The oversized glossy violet blob bleeding off the right edge of the hero, with the lowercase purple-pemutar wordmark stacked left and the magenta play capsule pinned beneath it.
• Input → transformation → outcome thesis. The listener presses the magenta play capsule → the capsule compresses with a soft bounce and the now-playing chip's progress ring begins advancing while the bottom-edge waveform starts moving → the first track is audibly playing and the entry surface truthfully reports it. Only accepted behaviour is used: starting the first track and reporting the current track and position.
• Motion vocabulary. Liquid and glossy. 200–320ms ease-out on hover. Soft bounces on play/pause press. The playhead knob scales to 1.15 on grab. A slow glossy highlight drifts across the player slab on idle. The progress bar fills with a magenta-to-violet gradient that shifts hue as the track advances.
• Composed first frame. Deep-aubergine field; the glossy violet blob anchored off-centre right and bleeding past the edge; the two-line lowercase wordmark left; the magenta play capsule beneath it; the thin magenta waveform resting along the bottom edge; the now-playing chip idle in the lower left. Nothing overlaps the wordmark, the capsule, or the chip.
• Reduced-motion state. All bounces become instant state changes, the idle gloss stops, and the progress bar still fills. The waveform stops moving and shows as a static line. Every control remains clearly readable and every state change remains visible.

9. Non-Functional Requirements

NFR-1 — Every feature must work properly. Provenance: explicit (hard constraint: "pastikan semua berpungsi dengan baik"). Rationale: the user's request binds correctness as tightly as capability. Every control on every surface must perform its stated action and report its state truthfully; no control may be decorative, inert, or misleading.

NFR-2 — The player must resemble the referenced image. Provenance: explicit (hard constraint: "seperti Poto ini"). Rationale: the referenced image was not attached, so its visual and structural intent is carried by the authoritative creative direction in Sections 6–8. The player must read as the glossy, curved, violet/magenta object that direction describes, not as a generic app shell.

NFR-3 — Readable text and controls stay whole at every viewport. Provenance: explicit (creative direction readability rule). Rationale: headlines, wordmarks, labels, numbers, and card text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them.

NFR-4 — Reduced-motion support. Provenance: explicit (creative direction motion rule). Rationale: under prefers-reduced-motion, bounces become instant state changes, the idle gloss stops, moving content stops and shows whole items, and the progress bar still fills. Every animation must leave its control clearly readable.

NFR-5 — Truthful playback state across surfaces. Provenance: required_inference. Rationale: the accepted surfaces each display current-track and progress information; for the player to be trustworthy, all of them must reflect the same true state at the same time, with no stale titles, frozen rings, or markers on tracks that are not playing.

NFR-6 — Immediate, audible control response. Provenance: required_inference. Rationale: the accepted volume control changes level "immediately and audibly," and the accepted transport controls change playback state directly. Control response must not be deferred behind a network round trip or a blocking animation.

NFR-7 — No sharp corners, no generic template look. Provenance: explicit (creative direction). Rationale: the direction forbids sharp corners, hairline borders, flat white cards, and the generic indigo/blue-on-white SaaS template. This is a binding visual constraint, not a preference.

10. Tech Stack

No technology was specified by the user. The following are coherent defaults chosen to satisfy the accepted behaviour and the authoritative visual direction, and are labeled as defaults.

• Frontend: React with TypeScript. [Default — not specified by user] Rationale: the accepted surfaces are interactive, stateful, and share live playback state across four views.
• Styling: CSS with custom properties for the colour tokens in Section 6, plus SVG/CSS gradients for the album blobs and the volume dial's gloss arc. [Default — not specified by user] Rationale: the direction requires generated two-tone gradient blobs and glossy top-edge highlights, both of which are natively expressible in CSS/SVG without photography or raster assets.
• Audio: the browser's native HTML audio capability, driven by the application's transport state. [Default — not specified by user] Rationale: playback, seeking, and volume are all native audio capabilities; no external audio service was requested.
• Backend: none required for the accepted scope. [Default — not specified by user] Rationale: no accepted requirement involves accounts, server-side catalogues, uploads, or shared state. The track list is a runtime data concern of the Music Library.
• Storage: none required for the accepted scope. [Default — not specified by user] Rationale: no accepted journey requires durable, identity-bound state to be resumed on a later visit.
• Containerization / orchestration: not required for the accepted scope. [Default — not specified by user] Rationale: the accepted delivery is a browser-delivered first-party application with no server-side component.

11. Assumptions and Constraints

Assumptions.

1. The referenced image ("Poto ini") was not attached to the request. Its visual and structural intent is therefore carried by the project's authoritative creative direction (Sections 6–8), which the user's design constraints explicitly preserve. [Assumption — source image unavailable]
2. The track list is runtime data of the Music Library. No authoritative content source supplied specific tracks, so no catalogue facts are invented in this document. [Assumption — no content_source directive]
3. Audio playback depends on the browser's audio capability and on the listener's device having working audio output. [Assumption — delivery environment]
4. The listener's session is a single continuous listening session. No accepted journey requires recognition on a later visit. [Assumption — derived from accepted access contract]

Constraints.

1. The music player must resemble the referenced image. explicit. Binding on all four surfaces.
2. All features must work properly. explicit. Binding on every control on every surface; no control may be decorative, inert, or misleading.
3. The generic indigo/blue-on-white SaaS template is forbidden. explicit. Binding on all visual work.
4. No sharp corners, hairline borders, flat white cards, or grids of identical hover-lift cards. explicit. Binding on all visual work.
5. No photography or stock imagery. explicit. Imagery is CSS/SVG gradient blobs only.
6. Forbidden typefaces: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui for headings or body. explicit.
7. No dark navy "cyber" palette with cyan glows. explicit. That is a different muse.
8. No bouncy motion that obscures state. explicit. Every animation must leave its control clearly readable.
9. Readable text and controls stay whole at 375px, 768px, and 1280px. explicit. This rule takes precedence over any direction, requirement, or brief that would crop, clip, or cover readable text or a control.
10. Scope boundary. No accounts, sign-in, profiles, social features, sharing, playlists, search, recommendations, uploads, purchases, lyrics, or server-side catalogue are part of this product. None were requested and no accepted surface owns them. explicit by omission — accepted page contract is closed at four surfaces

12. Glossary

• Music Listener — The single accepted active human persona. The person who plays audio tracks and operates the player's controls.
• Track — A single piece of audio the listener can select and play. Carries a title, secondary metadata, and a blob identity derived from its title hash.
• Current track — The track the player is presently loaded with, whether playing or paused.
• Transport — The play/pause, previous, and next controls on the Player surface.
• Scrubber — The thick pill-shaped progress control on the Player, carrying the chunky magenta playhead knob and the violet→magenta gradient fill.
• Playhead knob — The draggable magenta knob on the scrubber that sets the playback position; scales to 1.15 while grabbed.
• Blob — The unique two-tone gradient shape (violet + magenta + a rotating third hue) generated from a track's title hash, used as its album-art chip and as the hero's oversized decorative form.
• Gloss arc — The visible highlight on the volume dial that follows the current level.
• Active marker — The hot-magenta indicator marking the currently playing track in the Music Library.
• Now-playing chip — The small lower-left element on Landing showing the current track with a live progress ring.
• Capsule — The shared control shape: a fully rounded button or slider with a top-edge gloss highlight.
• Reduced motion — The prefers-reduced-motion state in which bounces become instant state changes, the idle gloss stops, and moving content stops and shows whole items.