System Requirements Document for garnet-keuangan

1. Introduction

garnet-keuangan is a sophisticated, aesthetic web application for personal finance, built for a global, general audience. It is not a private single-user tool and not a business accounting package: it is a public-facing finance website that any everyday person worldwide can use to record income and expenses, manage monthly budgets, and read their own financial reports and charts.

The product intent, derived from the authoritative requirement thread, is threefold:

1. Canggih (sophisticated) — the site must feel like a precision instrument, not a template dashboard. This is realized through the authoritative creative direction (a luxury-instrument aesthetic with gauge rings, ruled data rows, and a dark titanium ground).
2. Estetik (aesthetic) — the visual experience is a first-class requirement, not decoration. The palette, typography, shape language, layout grid, and motion described in Sections 6–8 are binding.
3. Berguna untuk keuangan (useful for finance) — the site must actually do financial work: capture transactions, hold monthly budgets, and produce reports and charts the user can rely on daily.

Audience: the general public, globally. The single accepted active persona is the Pengguna Umum (Pencatat Keuangan Pribadi) — an everyday person who wants a tidy, trustworthy picture of their own money and wants to open it every day.

2. System Overview

garnet-keuangan is delivered as a first-party web application with a custom user interface and an application-owned backend. The current delivery consists of seven pages in a fixed, ordered contract:

Actors

• Human (accepted persona): Pengguna Umum (Pencatat Keuangan Pribadi) — the only active human persona in the closed catalog.
• System (non-persona): the garnet-keuangan backend, which durably stores transactions, budgets, and report data, and the application identity service that binds durable financial state to the correct person.

Accepted behavior in scope: self-service sign-up, returning login, recording and editing income and expense transactions, browsing transaction history, managing monthly budgets, and viewing reports and charts of personal finances.

Narrow exclusions: no business/enterprise accounting scope, no multi-user collaboration or shared ledgers, no provider-owned financial-data aggregation, no advisory or investment-execution capability. Nothing in the sources authorizes these, and they are not inferred.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. garnet-keuangan is a first-party web product. The application owns its own identity (self-service sign-up and login), its own custom interface, and its own backend storage for transactions, budgets, and report data. There is no external provider surface and no headless-only delivery: every accepted capability is exercised through the application's own pages.

Access boundary. The Landing page is the anonymous public entry and is the surface that introduces the product to a global audience. Sign Up and Login are themselves anonymously reachable — a person who has no account yet must be able to reach the interaction that creates one, and a returning person must be able to reach the interaction that verifies them. Transactions, Transaction Details, Budgets, and Reports are protected: they hold durable, person-specific financial state and require an established, verified identity before that state is shown or changed.

Current vs. future. Everything described in Sections 3–5 is current. No future-horizon requirements were stated by the user; Section 11 records this explicitly rather than inventing a roadmap.

Global/general scope. The product targets a worldwide general audience. This is a scope statement about who the product is for, not a mandate for any specific localization feature; no language, currency, or regional capability was requested and none is added.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source authority, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information / state: the product's identity and promise for a global general audience; the three headline financial measures the product is built around — income, spending, and budget remaining — presented as an instrument cluster rather than as marketing copy.
• Primary action: enter the product (proceed to Sign Up for a first-time visitor; proceed to Login for a returning visitor).
• Supporting actions: read the headline statement; read the instrument cluster figures; navigate to Login.
• Domain entities: none persisted on this page; the cluster is illustrative of the product's measures (income, spending, budget remaining).
• Component responsibilities:
  • Hero headline block — oversized condensed uppercase headline stacked in three tight lines across the left seven columns, with the single amber CTA pinned directly beneath it.
  • Instrument cluster — three concentric champagne-gold gauge rings occupying the right five columns, with tabular numerals inside each ring.
  • Titanium ground — full-bleed dark surface with a macro-lit brushed-metal texture bleeding off the right edge.
  • Entry routing control — the one amber element on the screen; routes to Sign Up, with a secondary text route to Login.
• States:
  • Loading: gauge rings render at rest; numerals count up to their values on reveal.
  • Empty: not applicable — the page holds no user data.
  • Success: the visitor understands the product and selects an entry route.
  • Error / recovery: if the entry route cannot be resolved, the visitor remains on Landing and can retry the control; no partial state is shown.
  • Reduced motion: gauges show final values instantly, counting stops, parallax flattens.

Sign Up

• Information / state: the fields required to establish a first identity, and the fact that this is the first step before any financial data can be stored.
• Primary action: submit the sign-up form to create the account.
• Supporting actions: move to Login if an account already exists; correct field-level errors in place.
• Domain entities: user identity (credential and identifying fields).
• Component responsibilities:
  • Credential form — collects the identifying and secret fields; inline validation per field.
  • Submit control — the single amber element on the screen.
  • Login cross-link — routes an already-registered visitor to Login.
  • Error region — surfaces submission failures without discarding entered values.
• States:
  • Loading: submit control enters a pending state; the form is not double-submitted.
  • Empty: pristine form with no errors.
  • Success: identity established; the visitor is taken into the product to begin recording.
  • Error / recovery: field-level validation errors are shown inline; a submission failure (for example, an identifier already in use) is shown in the error region with the entered values preserved so the visitor can correct and resubmit.

Login

• Information / state: the fields required to verify a returning identity.
• Primary action: submit credentials to verify and resume.
• Supporting actions: move to Sign Up if no account exists; correct field-level errors in place.
• Domain entities: user identity (credential).
• Component responsibilities:
  • Credential form — collects the identifying and secret fields.
  • Submit control — the single amber element on the screen.
  • Sign Up cross-link — routes a visitor without an account to Sign Up.
  • Error region — surfaces verification failure without revealing which field was wrong.
• States:
  • Loading: submit control enters a pending state.
  • Empty: pristine form with no errors.
  • Success: identity verified; the visitor resumes at their financial data.
  • Error / recovery: a failed verification shows a single non-specific error and keeps the identifier value so the visitor can retry; repeated failure does not lock the visitor out of retrying.

Transactions

• Information / state: the saved list of the user's income and expense records, with each row's date, description, amount, and type; the running set the user browses.
• Primary action: open a transaction to view or change it.
• Supporting actions: browse and scan the list; start a new transaction; filter or scan by type (income vs. expense).
• Domain entities: Transaction (date, description, amount, type), Category.
• Component responsibilities:
  • Ruled transaction list — hairline-ruled rows in the chronograph-dial idiom, each a label/value pair aligned to the grid; the live/active row carries the single amber signal.
  • New-transaction control — routes to Transaction Details in create mode.
  • Row control — routes to Transaction Details for the selected record.
  • Empty-state block — shown when the user has no records yet.
• States:
  • Loading: ruled row placeholders at the final row height; no layout shift on arrival.
  • Empty: an explicit empty state that explains no transactions exist yet and offers the new-transaction control.
  • Success: the list renders with the user's records in order.
  • Error / recovery: if the list cannot be loaded, an error state with a retry control replaces the list; the user's other pages remain reachable.

Transaction Details

• Information / state: the full field set of one transaction — amount, type (income or expense), date, description, and category — in either create mode (blank) or edit mode (populated).
• Primary action: save the transaction.
• Supporting actions: change the type between income and expense; set the date; enter the amount; enter a description; choose a category; cancel and return to Transactions.
• Domain entities: Transaction (amount, type, date, description, category), Category.
• Component responsibilities:
  • Field set — amount, type, date, description, category, each with inline validation.
  • Save control — the single amber element on the screen.
  • Cancel control — returns to Transactions without persisting.
  • Error region — surfaces save failures without discarding entered values.
• States:
  • Loading: in edit mode, fields populate from the stored record; controls are inert until populated.
  • Empty: create mode — blank fields with sensible defaults for date and type.
  • Success: the record is persisted and the user returns to Transactions with the change visible.
  • Error / recovery: validation errors are shown inline per field; a save failure is shown in the error region with all entered values preserved so the user can retry without re-entering.

Budgets

• Information / state: the user's monthly budgets, each with its period and its limit, and the relationship between each budget and the spending recorded against it.
• Primary action: set or update a monthly budget.
• Supporting actions: review existing budgets by period; adjust a limit; remove a budget that is no longer wanted.
• Domain entities: Budget (period, limit, category), Category, Transaction (as the spending measured against the budget).
• Component responsibilities:
  • Budget gauge — each budget's remaining amount rendered as a concentric champagne-gold ring with tabular numerals inside, not a flat stat card.
  • Ruled budget rows — label/value pairs aligned to the grid; the live/active row carries the single amber signal.
  • Budget editor — sets the period and limit for a budget.
  • Empty-state block — shown when no budgets exist for the current period.
• States:
  • Loading: gauge rings render at rest and rows hold their final height.
  • Empty: an explicit empty state explaining no budget is set for the period, with the control to create one.
  • Success: the budget is stored and its gauge reflects the updated remaining amount.
  • Error / recovery: a failed save shows an error with the entered period and limit preserved; the previously stored budget remains intact and visible.

Reports

• Information / state: the user's financial reports and charts — income versus expense over time, spending by category, and budget performance for the selected period.
• Primary action: read the report for a chosen period.
• Supporting actions: change the reporting period; read individual figures as label/value pairs; scan the ruled report rows.
• Domain entities: Transaction (aggregated), Budget (aggregated), Category, Report period.
• Component responsibilities:
  • Gauge cluster — key figures (balance, monthly spend, budget remaining) as concentric champagne-gold rings with tabular numerals.
  • Engineered charts — income/expense and category charts drawn as engineered diagrams, not decorative illustrations.
  • Ruled report rows — hairline-ruled label/value rows aligned to the grid; the live/active row carries the single amber signal.
  • Period selector — changes the window the report covers.
  • Empty-state block — shown when the selected period contains no data.
• States:
  • Loading: gauges render at rest; needles sweep and numerals count to their final values on reveal, then hold still.
  • Empty: an explicit empty state for a period with no recorded activity, with a route to record a transaction.
  • Success: the report renders for the selected period.
  • Error / recovery: if the report cannot be computed or loaded, an error state with a retry control replaces the charts; the period selection is preserved.
  • Reduced motion: needles show final positions instantly and counting stops.

3. Functional Requirements

Each requirement below is a distinct story point with its provenance, lifecycle facts, and observable acceptance.

FR-1 — Sophisticated, aesthetic finance website (explicit) As a visitor or user, I should experience garnet-keuangan as a sophisticated and aesthetic finance website, so that I trust it with my money and want to open it daily.

• Trigger/input: any visit to any page.
• Observable result: every page conforms to the authoritative creative direction — dark titanium ground, champagne-gold instrument metal, at most one amber signal per screen, condensed uppercase headings, tabular numerals, hairline-ruled rows, sharp 4px panel corners, no blue, no pill buttons, no gradient-blob or glassmorphism treatment.
• Access state: applies to anonymous and authenticated pages alike.
• Failure/recovery: a page that violates the direction is a defect; there is no user-facing recovery path because this is a conformance requirement.
• Continuation: the user proceeds with the page's own task.

FR-2 — Global / general audience (explicit) As a member of the worldwide general public, I should be able to use garnet-keuangan for my own personal finances, so that the product is not restricted to a private individual or to a specific business.

• Trigger/input: any person reaching the Landing page.
• Observable result: the product presents itself as a general-purpose personal finance tool; nothing in the interface presumes a specific country, employer, or business type.
• Access state: the Landing page is anonymously reachable.
• Failure/recovery: not applicable — this is a scope constraint on presentation and audience.
• Continuation: the visitor chooses an entry route.

FR-3 — Useful for finance: record income and expenses (explicit) As a Pengguna Umum, I should record my income and expenses as transactions, so that I have a durable, accurate record of my money.

• Trigger/input: the user selects the new-transaction control from Transactions, or opens an existing record.
• Observable result: a transaction with amount, type (income or expense), date, description, and category is persisted and appears in the Transactions list.
• Access state: login required.
• Failure/recovery: validation errors are shown inline per field; a save failure preserves all entered values so the user can retry without re-entering.
• Continuation: the user returns to Transactions and sees the new or updated record.

FR-4 — Useful for finance: manage monthly budgets (explicit) As a Pengguna Umum, I should set and manage monthly budgets, so that I can hold myself to a spending limit each month.

• Trigger/input: the user sets or updates a budget for a period.
• Observable result: the budget's period and limit are persisted, and its gauge shows the remaining amount against recorded spending.
• Access state: login required.
• Failure/recovery: a failed save shows an error with the entered period and limit preserved; the previously stored budget remains intact.
• Continuation: the user returns to the budget list and sees the updated gauge.

FR-5 — Useful for finance: view reports and charts (explicit) As a Pengguna Umum, I should view reports and charts of my finances, so that I can see where my money is going.

• Trigger/input: the user opens Reports and selects a period.
• Observable result: income versus expense over time, spending by category, and budget performance are rendered as engineered charts and gauge figures for the selected period.
• Access state: login required.
• Failure/recovery: if the report cannot be computed or loaded, an error state with a retry control replaces the charts and the period selection is preserved.
• Continuation: the user changes the period or returns to Transactions or Budgets.

FR-6 — Self-service sign-up before first durable storage (required_inference) As a first-time visitor, I should be able to create my own account, so that my financial records can be stored durably and bound to me.

• Trigger/input: the visitor selects the entry route on Landing and submits the sign-up form.
• Observable result: an identity is established and the visitor enters the product able to record financial data.
• Access state: the Sign Up page is anonymously reachable — a person without an account must be able to reach the interaction that creates one.
• Failure/recovery: field-level validation errors are shown inline; a submission failure (for example, an identifier already in use) is shown with entered values preserved so the visitor can correct and resubmit.
• Continuation: the newly registered user proceeds to record a transaction.

FR-7 — Login to verify and resume (required_inference) As a returning user, I should verify my identity before reaching my financial data, so that my records remain private to me and I can resume where I left off.

• Trigger/input: the returning user opens Login and submits credentials.
• Observable result: identity is verified and the user reaches their own transactions, budgets, and reports.
• Access state: the Login page is anonymously reachable; the protected pages remain unavailable until verification succeeds.
• Failure/recovery: a failed verification shows a single non-specific error and keeps the identifier value so the user can retry.
• Continuation: the verified user resumes at their financial data.

FR-8 — Durable backend storage for transactions, budgets, and reports (required_inference) As a Pengguna Umum, I should have my transactions, budgets, and report data stored durably, so that my financial picture survives across sessions and devices.

• Trigger/input: any save from Transaction Details or Budgets.
• Observable result: the record is persisted server-side and is present on the next visit after login.
• Access state: login required for all reads and writes of this data.
• Failure/recovery: a failed write surfaces an error on the originating page with the user's input preserved; the previously stored state is not corrupted.
• Continuation: the user retries the save or continues browsing unaffected data.

FR-9 — Browse and review saved transactions (required_inference) As a Pengguna Umum, I should review and browse my saved income and expense records, so that I can check what I have recorded.

• Trigger/input: the user opens Transactions.
• Observable result: the saved records render as ruled rows with date, description, amount, and type.
• Access state: login required.
• Failure/recovery: if the list cannot be loaded, an error state with a retry control replaces the list.
• Continuation: the user opens a record, or starts a new one.

FR-10 — Focused create/edit of a single transaction (required_inference) As a Pengguna Umum, I should create or change one transaction in a focused view, so that I can enter or correct a record without distraction.

• Trigger/input: the user arrives from Transactions in create mode or edit mode.
• Observable result: the transaction's amount, type, date, description, and category are captured and saved.
• Access state: login required.
• Failure/recovery: inline validation per field; a save failure preserves all entered values.
• Continuation: the user returns to Transactions with the change visible.

4. User Personas

Pengguna Umum (Pencatat Keuangan Pribadi)

Product context. An everyday person anywhere in the world who wants a sophisticated, aesthetic tool for their own money. They are not an accountant and not running a business ledger; they are managing a personal financial life and want it to look and feel as considered as the rest of the instruments they rely on. They arrive at garnet-keuangan from the open web, with no prior relationship to the product.

Primary goal. To hold a tidy, trustworthy picture of their personal finances that they can open every day — income and expenses recorded, a monthly budget they can see themselves against, and reports that show where the money actually went.

Distinct accepted responsibilities.

• Establishing their own access: creating an account on first use, and verifying themselves on return, because their financial records must remain bound to them.
• Recording income and expenses as transactions, including correcting a record they entered wrongly.
• Browsing their saved transaction history to check what they have recorded.
• Setting and maintaining monthly budgets, and reading each budget's remaining amount against recorded spending.
• Reading reports and charts for a chosen period to understand income versus expense, spending by category, and budget performance.

Relevant inputs and decisions. The amount, type (income or expense), date, description, and category of each transaction; the period and limit of each budget; the reporting period they want to examine. Their recurring decision is whether a given record is income or expense and which category it belongs to, and whether a budget limit still reflects what they intend to spend.

Interactions with other accepted participants. The persona is the only active human actor in this product. Their counterpart is the system: the application identity service that binds durable financial state to the correct person, and the backend that stores transactions, budgets, and report data. There is no second human participant, no shared ledger, and no counterparty whose approval the persona waits on.

Observable success. The user can open the product, verify themselves, and immediately see their own figures — balance, monthly spend, budget remaining — rendered as instrument readings rather than as a generic dashboard. A transaction they enter appears in their history and is reflected in their budget gauge and their reports. Their budget shows how much remains. Their report shows the period they selected. Nothing they entered is lost between sessions.

What makes this role's work different. The persona's work is a measurement discipline, not an administrative one. Every action they take is either feeding a measurement (recording a transaction, setting a budget limit) or reading one (browsing history, reading a report). That is why the product's identity is built around gauges, ruled rows, and tabular numerals rather than around forms and tables: the persona's recurring need is to read a value accurately and trust it, and their recurring obligation is to enter values accurately enough that the reading stays true.

5. Core User Flows

Flow A — First-time visitor discovers the product and creates an account

1. Starting context: an anonymous visitor anywhere in the world arrives at the Landing page. No account exists.
2. On Landing, the visitor reads the oversized condensed uppercase headline stacked in three tight lines across the left seven columns, and sees the instrument cluster on the right — three concentric champagne-gold gauge rings for income, spending, and budget remaining, with tabular numerals counting up to their values on load.
3. The visitor selects the single amber CTA pinned beneath the headline. This is the only amber element on the screen.
4. Owner: the application routes the visitor to Sign Up.
5. On Sign Up, the visitor completes the credential form. Field-level validation runs inline as they type.
6. The visitor submits. The submit control enters a pending state and the form is not double-submitted.
7. Observable result (success): an identity is established and the visitor enters the product able to record financial data.
8. Failure and recovery: if a field is invalid, an inline error appears against that field. If submission fails — for example, the identifier is already in use — the error region shows the failure and all entered values are preserved, so the visitor corrects the offending field and resubmits without re-entering anything.
9. Continuation: the newly registered user proceeds to Flow C to record their first transaction.

Flow B — Returning user verifies and resumes

1. Starting context: a person who already has an account arrives at Landing (or directly at Login).
2. On Landing, the visitor takes the secondary text route to Login rather than the primary CTA.
3. On Login, the returning user enters their credentials and submits. The submit control enters a pending state.
4. Observable result (success): identity is verified and the user reaches their own financial data — their transactions, budgets, and reports.
5. Failure and recovery: a failed verification shows a single non-specific error that does not reveal which field was wrong, and keeps the identifier value so the user can retry immediately. Repeated failure does not prevent retrying.
6. Continuation: the verified user resumes at their financial data, typically at Transactions.

Flow C — Recording an income or expense transaction

1. Starting context: a logged-in user is on Transactions.
2. The user selects the new-transaction control.
3. Owner: the application routes to Transaction Details in create mode, with blank fields and sensible defaults for date and type.
4. On Transaction Details, the user sets the type (income or expense), enters the amount, sets the date, enters a description, and chooses a category. Inline validation runs per field.
5. The user selects the save control — the single amber element on the screen.
6. Observable result (success): the transaction is persisted durably and the user returns to Transactions, where the new record appears as a ruled row with its date, description, amount, and type.
7. Failure and recovery: if a field is invalid, an inline error appears against it. If the save fails, the error region shows the failure and all entered values are preserved, so the user retries without re-entering the transaction.
8. Continuation: the user records another transaction, or moves to Budgets or Reports to see the effect of what they just entered.

Flow D — Correcting an existing transaction

1. Starting context: a logged-in user is on Transactions, reviewing their saved records.
2. The user selects a row. The active row carries the single amber signal.
3. Owner: the application routes to Transaction Details in edit mode, with the stored record's amount, type, date, description, and category populated.
4. The user changes the fields that are wrong.
5. The user selects the save control.
6. Observable result (success): the corrected record is persisted and the user returns to Transactions with the change visible.
7. Failure and recovery: a save failure preserves all edited values so the correction is not lost; the previously stored record remains intact until a save succeeds.
8. Continuation: the user continues browsing, or leaves the page via the cancel control, which returns to Transactions without persisting.

Flow E — Setting and maintaining a monthly budget

1. Starting context: a logged-in user is on Budgets.
2. The user reviews existing budgets by period, each rendered as a concentric champagne-gold gauge ring with tabular numerals showing the remaining amount, alongside ruled label/value rows.
3. The user sets or updates a budget for a period, entering the period and the limit.
4. Observable result (success): the budget is stored durably and its gauge reflects the updated remaining amount against the spending recorded for that period.
5. Failure and recovery: if the save fails, an error is shown with the entered period and limit preserved, and the previously stored budget remains intact and visible.
6. Continuation: the user adjusts another budget, or moves to Reports to see budget performance for the period.

Flow F — Reading financial reports and charts

1. Starting context: a logged-in user is on Reports.
2. The user selects the reporting period they want to examine.
3. Observable result: the report renders for that period — income versus expense over time, spending by category, and budget performance — as engineered charts and gauge figures. Key figures (balance, monthly spend, budget remaining) appear as concentric champagne-gold rings with tabular numerals; needles sweep and numerals count to their final values on reveal, then hold still.
4. Empty state: if the selected period contains no recorded activity, an explicit empty state explains this and offers a route to record a transaction.
5. Failure and recovery: if the report cannot be computed or loaded, an error state with a retry control replaces the charts, and the period selection is preserved so the user can retry the same view.
6. Continuation: the user changes the period, or returns to Transactions or Budgets to act on what the report showed.

Flow G — Browsing transaction history

1. Starting context: a logged-in user is on Transactions.
2. The user scans the ruled rows, each a label/value pair aligned to the grid, and filters or scans by type (income versus expense).
3. Empty state: if the user has no records yet, an explicit empty state explains that no transactions exist and offers the new-transaction control.
4. Failure and recovery: if the list cannot be loaded, an error state with a retry control replaces the list; the user's other pages remain reachable.
5. Continuation: the user opens a record (Flow D) or starts a new one (Flow C).

6. Visuals, Colors and Theme

The authoritative creative direction is "Precision luxury instrument for personal finance", with MARQ by Garmin as the muse. The headline idea: personal finance is a measurement discipline — balances, budgets, and reports are gauges and dials — so the product is built as a well-machined instrument you rely on daily, projecting trust, precision, and calm confidence.

Color tokens (dark mode)

No blue anywhere. The generic indigo/blue-on-white SaaS template is explicitly forbidden for this project.

Typography

• Headings: Barlow Condensed — condensed technical sans, uppercase for section labels and data headers, semibold-to-bold weights, tight tracking (-0.01em) so numbers read as instrument markings.
• Body: Saira at 400/500 with generous line-height for readability.
• Numerals: always tabular.
• Scale: 1.25 modular, mobile → desktop — display 40→96px, h1 32→64px, h2 24→40px, h3 20→28px, body 16→18px, data label 12→13px uppercase, mono numerals 14→16px.
• Forbidden typefaces: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui for headings or body.

Shape language

• Circular gauges and bezels are the core motif.
• Ruled data rows in the chronograph-dial idiom.
• Sharp 4px corners on panels, with 1px hairline borders.
• Edge-to-edge macro surfaces where imagery bleeds.
• Rounded-rectangle controls only where a button must be pressed — radius 6px, never pill-shaped.
• No blobs, no soft shadows: depth comes from hairline rules and slight surface lifts.

Layout

A strict instrument grid: 12 columns, 8pt baseline, wide outer margins. The hero is asymmetric — an oversized condensed headline stacked over an edge-to-edge dark titanium surface, with a live dial/gauge cluster occupying the right third. Dashboard screens use ruled rows and circular gauges rather than card grids; each figure sits in a label/value pair aligned to the grid, like a watch face's subdials.

Imagery

Macro photography of brushed titanium, sapphire glass edges, topographic contour lines, and dial textures; dark studio lighting with a single warm metallic highlight. No stock people, no clip art. Charts and gauges are drawn as engineered diagrams, not decorative illustrations.

Readability at every viewport

Readable text and controls stay whole at 375px, 768px, and 1280px: headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, with no other element covering any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, provided they cover no readable text or control. Where the direction asks for a cropped or bleeding gesture, the gesture is carried by imagery or decoration, never by readable text or a control.

7. Signature Design Concept

The Instrument Panel Entry.

The Landing page is composed as a single machined face rather than a marketing page. A full-bleed dark titanium surface (#0E1113) fills the viewport, with a macro-lit brushed-metal texture bleeding off the right edge — the texture is allowed to run past the viewport boundary, because it is decoration, not readable content.

The left seven columns carry the headline: "KENDALI PENUH ATAS UANG ANDA" set in Barlow Condensed uppercase at clamp(40px, 8vw, 96px), stacked in three tight lines, with tight -0.01em tracking so the letterforms read as instrument markings. Directly beneath it, pinned — never centred — sits the single amber CTA (#D98A2B). It is the only amber element on the screen.

The right five columns carry the live instrument cluster: three concentric champagne-gold (#C9A96A) gauge rings showing income, spending, and budget remaining, each with tabular numerals inside the ring. On load, the needles sweep and the numerals count up to their values, then hold still. The rings are drawn as engineered diagrams — hairline bezels, ruled tick marks — not as decorative illustration.

The composition is deliberately asymmetric and deliberately scarce: one headline, one CTA, three gauges, one amber signal. Everything else is titanium, champagne gold, or warm off-white. This is the product's whole argument in one frame — that a money tool can be read like a precision instrument.

The concept recomposes only accepted content and controls: the product's identity, its three headline measures, and the entry route into Sign Up (with the secondary route to Login). It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: dimensional_css

Landing Hero Motion Brief

• Focal subject: the live instrument cluster — three concentric champagne-gold gauge rings (income, spending, budget remaining) with tabular numerals inside, set against a macro-lit brushed-titanium surface that bleeds off the right edge.
• Input → transformation → outcome thesis: on load, the gauge needles sweep from rest to their positions (600–900ms ease-out) while the tabular numerals count up to their values; the headline layer and the titanium surface behind it separate slightly under scroll-linked parallax. The outcome is a first frame that reads as an instrument coming to life and settling — the visitor sees the product's three measures as readings, not as claims.
• Motion vocabulary: precise, never playful. Needle sweeps on gauge load, numbers counting up to their value on reveal, slow product turntables on hero imagery, scroll-linked parallax between the headline layer and the titanium surface behind it. No bounce, no springy easing, no confetti, no particle effects.
• Composed first frame: full-bleed #0E1113 ground; the oversized Barlow Condensed uppercase headline stacked in three tight lines across the left seven columns; the single amber CTA pinned directly beneath it; the three gauge rings at rest in the right five columns with their numerals at zero, about to count. No centred headline, no gradient blob, no blue button.
• Reduced-motion state: with prefers-reduced-motion, gauges show their final values instantly, counting stops, and parallax flattens — the first frame is the settled instrument, fully readable, with no motion at all.

Scroll-linked dial sweep

As the user scrolls from the hero into the reports section, the gauge needles sweep and the numbers count to their final values, then hold still. This is the direction's signature scroll gesture and applies to gauge figures on the Landing hero and to the gauge cluster on Reports.

Global motion rules

• All motion respects prefers-reduced-motion: gauges show final value instantly, counting stops, parallax flattens.
• Motion is precise and needle-like throughout; playful bounce, springy easing, confetti, and particle effects are excluded.
• Moving and scrollable content (tickers, horizontally scrollable rows) may cross the viewport or container edge by design; every item must become 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) whose further items are reached by scrolling.

9. Non-Functional Requirements

NFR-1 — Visual sophistication and aesthetic quality (explicit) The interface must satisfy the authoritative creative direction in Sections 6–8. This is a hard constraint from the user ("canggih + estetik"), not a preference. Rationale: the user stated it as a primary product requirement.

NFR-2 — Global/general audience scope (explicit) The product must present itself as a general-purpose personal finance tool for the worldwide public, not as a private tool or a business-specific system. Rationale: explicit user constraint ("Untuk gelobal / umum").

NFR-3 — Readability and containment at all viewports (explicit, from the creative direction) Readable text and controls must stay whole and fully 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. Rationale: stated as a binding rule in the creative direction, and it takes precedence over any direction gesture that would crop readable text or a control.

NFR-4 — Accessible contrast (required_inference) Warm off-white #F4F1EA text on the #0E1113 ground holds AA contrast; muted slate #7C858C is reserved for secondary labels. Rationale: the direction specifies the pairing for exactly this reason; it is the minimum needed to keep the instrument readings legible.

NFR-5 — Reduced-motion compliance (required_inference) Every animated behavior must have a reduced-motion state in which gauges show final values instantly, counting stops, and parallax flattens. Rationale: the direction states this as a rule; without it the motion vocabulary would be unusable for motion-sensitive users.

NFR-6 — Durable storage of financial data (required_inference) Transactions, budgets, and report data must be stored durably server-side and must survive across sessions. Rationale: the accepted journeys require the user's financial picture to persist; without durability the product is not "berguna untuk keuangan".

NFR-7 — Identity-bound data isolation (required_inference) A user's transactions, budgets, and reports must be bound to that user's verified identity and must not be reachable without verification. Rationale: the accepted journeys require durable, person-specific financial state; binding it to the correct participant is the minimum needed for the records to be trustworthy.

NFR-8 — No blue in the interface (explicit, from the creative direction) No blue or indigo primary or accent on a white ground. The generic indigo/blue-on-white SaaS template is forbidden for this project. Rationale: explicit direction constraint.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults, labeled as such.

• Frontend: React — a single-page web application serving the seven-page contract. [Default — not specified by user]
• Styling: CSS with custom properties for the color, type, and spacing tokens in Section 6; clamp() for the responsive type scale. [Default — not specified by user]
• Backend: Python with FastAPI — serves the identity endpoints and the transaction, budget, and report data endpoints. [Default — not specified by user]
• Storage: a relational database for users, transactions, budgets, and categories, with report aggregations computed from stored transactions and budgets. [Default — not specified by user]
• Containerization: Docker with docker-compose for local development and deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required at the current scope; the accepted behavior does not demand it. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A-1 — The product is a web application accessed through a browser; no native mobile application was requested. [Default — not specified by user]
• A-2 — Identity is application-owned and self-service: a person creates their own account on Sign Up and verifies on Login. No invitation, provisioning, or deployment-bootstrap path was requested. (required_inference, from the accepted planning scope)
• A-3 — A single user's data is their own; there is no sharing, collaboration, or multi-user ledger. (derived from the accepted persona catalog, which contains exactly one active human role)
• A-4 — Categories are a supporting attribute of transactions and budgets, used to make reports meaningful; no separate category-management capability was requested and none is added. (required_inference)
• A-5 — The gauge figures on the Landing page are illustrative of the product's three measures (income, spending, budget remaining) and are not the visitor's own data, since the visitor is anonymous. (required_inference)

Constraints

• C-1 — The interface must be sophisticated and aesthetic, conforming to the creative direction in Sections 6–8. (explicit)
• C-2 — The audience is global and general — not restricted to a private individual or a specific business. (explicit)
• C-3 — No blue anywhere; the indigo/blue-on-white SaaS template is forbidden. (explicit)
• C-4 — Readable text and controls stay whole and uncovered at 375px, 768px, and 1280px. (explicit)
• C-5 — The page contract is fixed at exactly seven pages: Landing, Sign Up, Login, Transactions, Transaction Details, Budgets, Reports. No page is added, removed, merged, split, renamed, or reordered. (from the accepted page contract)
• C-6 — Landing, Sign Up, and Login are anonymously reachable; Transactions, Transaction Details, Budgets, and Reports require login. (from the accepted access contract)
• C-7 — No future-horizon requirements were stated by the user. Nothing is deferred and nothing is added beyond the current scope. (explicit — absence of a stated future horizon)

12. Glossary

• Pengguna Umum (Pencatat Keuangan Pribadi) — the single accepted active human persona: an everyday person, anywhere in the world, who records and reviews their own personal finances.
• Transaction — a single recorded income or expense, with amount, type, date, description, and category.
• Type — whether a transaction is income or expense.
• Category — the classification attached to a transaction or budget, used to make reports meaningful.
• Budget — a monthly spending limit for a period, with a remaining amount measured against the spending recorded for that period.
• Report — the aggregated view of a user's finances for a selected period: income versus expense over time, spending by category, and budget performance.
• Gauge ring — the product's core data motif: a concentric champagne-gold ring with tabular numerals inside, used for key figures (balance, monthly spend, budget remaining) instead of a flat stat card.
• Ruled row — a hairline-ruled label/value row in the chronograph-dial idiom, used for transaction, budget, and report rows.
• Amber signal — the single #D98A2B element permitted per screen: the primary CTA or the active/live value.
• Instrument metal — champagne gold (#C9A96A), used for bezels, rules, gauge rings, and key figures.
• Titanium ground — the dark #0E1113 background that carries the whole product.
• Durable state — financial data persisted server-side and bound to a verified identity, surviving across sessions.