System Requirements Document for dashboard-aplikasi-web

1. Introduction

dashboard-aplikasi-web is an existing Indonesian-language web dashboard project that must be hardened into a complete, functional, permanently release-ready application. The product intent is not to invent a new product but to make the current dashboard genuinely whole: every page, button, and navigation element must work with no dead buttons, broken links, or click errors; every displayed value must come from a real state-management, database, or API connection instead of static mock data; the codebase must be tidied with unused code removed and no browser-side console errors; and the build configuration (package.json, framework config files, .env variables) must be correct so the code can be deployed smoothly to a hosting platform such as Vercel or Netlify.

The audience is twofold. The Dashboard Owner / Project Requester is the person who owns the existing GitHub repository, directs the hardening work, reviews the repaired surfaces, confirms that data is genuinely connected, and approves the deployment configuration before the app goes live. The Dashboard End User is the person who lives inside the tool day to day — scanning dense numeric data, moving through navigation, and using controls and data views — and who needs every interaction to complete without errors and every number to be real rather than mock.

Work is performed directly on the user's existing GitHub repository, with changes committed to that repository, and the user must be informed of anything important that requires their confirmation.

2. System Overview

dashboard-aplikasi-web is delivered as a first-party web application with four custom pages: Landing, Dashboard, Data, and Deployment. The application is a keyboard-first operations console: a fixed left navigation rail, a persistent top status bar that carries environment, short commit SHA, and a live "API terhubung" indicator, and content laid out on a strict 12-column grid with hairline dividers. The interface is the product's imagery — schematic, honest, and dense — and the acid-lime status color always means "this is real, not mock."

Actors are the Dashboard Owner / Project Requester and the Dashboard End User. Both are active human participants. The application itself owns the dashboard shell, navigation, data views, and deployment-readiness review. The hosting platform (Vercel or Netlify) is an external destination that receives the built application; the data source or API is an external system that supplies live values. Neither is a persona.

Current accepted behavior covers four workstreams: (1) feature inspection and repair across every page, button, and navigation element; (2) genuine data/backend integration replacing static mock data; (3) code cleanup — tidy file structure, removal of unused code, and zero browser console errors; and (4) deployment preparation for Vercel or Netlify. The application also surfaces, in-product, the deployment-readiness state of the real configuration items so the owner can review and confirm them.

Narrow exclusions: this document does not introduce new product capabilities beyond repairing, connecting, cleaning, and preparing the existing dashboard for release. It does not add account management, role-based permissions, analytics suites, or adjacent modules. The hosting platform and the data source remain external owners of their own responsibilities.

2a. Product Interpretation and Delivery Boundary

The product is delivered as a first-party web application that runs in the browser and is deployed to a hosting platform the user names — Vercel or Netlify. All four pages are application-owned and reachable without an account: the source establishes no application-owned identity requirement, no private per-user state that must be resumed, and no commitment or value transfer that must remain bound to a specific participant. Access to Landing, Dashboard, Data, and Deployment is therefore open, and no authentication, sign-up, or account-management capability is introduced.

The data source or API connection is external and provider-owned: the application consumes it, displays its values, and reports connection state, but does not own the data store's lifecycle. The hosting platform is likewise external: the application produces a correct build and configuration, and the platform performs the deployment. The application's own responsibility ends at a verified, deployable configuration and a truthful readiness review.

Current horizon: repair of pages, buttons, and navigation; genuine data connection; code cleanup; deployment configuration; direct commits to the existing repository; and informing the user of anything needing confirmation. No future-horizon capabilities are accepted in the source, so none are specified as current.

2b. Source Content Inventory

The reference directive for the user's current GitHub repository declares content_source authority. The repository is an existing artifact whose concrete contents (file tree, existing pages, existing buttons, existing navigation entries, existing mock data, existing configuration files, existing environment variable names) are the factual content to be inspected and corrected. Because the repository contents are not enumerated in the authoritative thread, this inventory records the verified factual categories the inspection must cover rather than inventing specific file names, values, or data records:

• Existing pages in the dashboard, each to be inspected for dead buttons, broken links, and click errors.
• Existing buttons and interactive controls, each to be verified as functional.
• Existing navigation elements, each to be verified as resolving correctly.
• Existing displayed data, each value to be traced to a genuine state-management, database, or API source rather than a static mock.
• Existing file structure, to be tidied, with unused code removed.
• Existing package.json, to be verified and corrected for build and deployment.
• Existing framework configuration files, to be verified and corrected.
• Existing .env variables, to be verified and corrected for the deployment target.
• Existing browser console output, to be driven to zero errors.

No specific file names, data records, dates, contacts, links, or media references are asserted here because the authoritative thread does not enumerate them; the inspection itself supplies them.

2c. Page Content and Component Coverage

Landing

• Information and state: The public entry surface. Presents the product identity DASHBOARD-APLIKASI-WEB with a status micro-label reading STATUS: SIAP RILIS, a two-line headline describing the hardened, release-ready dashboard, and a live miniature of the actual dashboard showing a real metric tile with a counting numeral, a lime "connected" chip, and a sparkline.
• Primary action: Enter the dashboard (tangerine rectangular CTA, not a pill).
• Supporting action: A secondary link rendered as monospace text pointing to the deployment-readiness view.
• Domain entities: Product identity, release status, live connection state, headline metric value.
• Component responsibilities: 9-column flush-left headline block; 3-column live dashboard miniature panel on #1C1E21 with hairline border; tangerine micro-label; monospace secondary link; persistent top status bar.
• States: Loading — the miniature's metric tile shows a placeholder numeral and the connection chip is neutral until the live value resolves. Empty — if no live value is available, the miniature shows the chip in a non-connected state and the numeral area shows a dash rather than a fabricated number. Success — numeral counts up once on first paint (600ms, no bounce) and the chip reads connected in lime. Error — if the connection cannot be established, the chip states the connection is unavailable and the secondary link to Deployment remains available. Recovery — the connection state re-resolves on reload; the page never blocks entry to the dashboard.

Dashboard

• Information and state: The repaired dashboard shell and its controls. Leads with a 4-up metric strip where oversized tabular numerals are the hero, followed by a two-thirds/one-third split of a live data table and a side panel. Carries the 64px left nav rail with a 3px tangerine active-edge bar and the 56px top status bar showing environment, short commit SHA, and the pulsing lime "API terhubung" dot.
• Primary actions: Navigate between dashboard destinations via the nav rail; activate every button and control on the page; focus and open a table row.
• Supporting actions: Keyboard navigation across rail, table rows, and controls; open the right-hand detail drawer on Enter.
• Domain entities: Metric values, table rows, row detail, environment name, commit SHA, connection state.
• Component responsibilities: Nav rail (icon + label, tangerine active bar, collapses to a bottom tab bar at 375px); top status bar; 4-up metric strip; live data table; side panel; detail drawer; focus rings as 2px tangerine outlines on every interactive element.
• States: Loading — metric numerals and table rows show skeleton placeholders; the freshness dot pulses to indicate the connection is live. Empty — the table shows an explicit no-records state rather than blank space, and metric tiles show a dash. Success — numerals count up once on first load; rows render with tabular alignment; every button and navigation element resolves without error. Error — a failed data fetch shows an inline error in the affected panel with a retry control; a failed navigation target is reported rather than silently doing nothing. Recovery — retry re-issues the fetch; the shell and navigation remain usable while a panel is in error.

Data

• Information and state: The full-width data view that must render values from genuine state management or a database/API connection instead of static mock data. Sticky table header, tabular alignment, and a right-hand detail drawer.
• Primary actions: Browse and scroll the data table; focus a row; open the detail drawer on Enter.
• Supporting actions: Refresh the data; read the freshness indicator to confirm values are live.
• Domain entities: Data records and their fields, record detail, data source identity, freshness timestamp.
• Component responsibilities: Full-width table with sticky header; tabular-aligned cells; right-hand detail drawer; freshness pulse; refresh control; hairline column dividers.
• States: Loading — table shows skeleton rows while the source resolves. Empty — an explicit no-data state that distinguishes "connected but no records" from "not connected." Success — records render from the live source with a freshness timestamp. Error — a connection or fetch failure is stated plainly with a retry control, and no mock values are substituted. Recovery — retry re-issues the request; the last successfully loaded data remains visible and clearly marked as stale until fresh data arrives.

Deployment

• Information and state: A deployment-readiness review rendered as a ruled spec sheet. Each row is a label/value pair in monospace with a pass/fail chip, mapping to one real configuration item: package.json, framework configuration files, .env keys, and the build command. Includes a small inline SVG topology diagram showing repo → build → host.
• Primary actions: Review each configuration row and its pass/fail state; identify items that need the owner's confirmation.
• Supporting actions: Read the target platform (Vercel or Netlify); read the build command and environment key names.
• Domain entities: Configuration item name, its value or key name, pass/fail status, target platform, build command, repository-to-host topology.
• Component responsibilities: Ruled spec-sheet rows; monospace label/value pairs; pass/fail chips; inline SVG topology diagram; code blocks in JetBrains Mono with graphite syntax highlighting.
• States: Loading — rows resolve their status as configuration is read. Empty — an item with no configured value shows an explicit "not set" state rather than a blank cell. Success — each row shows a pass chip in lime when the item is correctly configured. Error — a failing or missing item shows a fail chip and the specific item that needs attention. Recovery — the owner corrects the item and the row re-resolves to pass; items requiring the owner's confirmation are surfaced explicitly.

3. Functional Requirements

FR-1 — Inspect and repair every page, button, and navigation element As a Dashboard Owner / Project Requester, I should have every page, button, and navigation element in the existing dashboard inspected and repaired so that there are no dead buttons, broken links, or errors when clicked.

• Provenance: explicit.
• Trigger/input: The owner directs the inspection of the existing dashboard surfaces.
• Observable result: Every button activates its intended behavior, every navigation element resolves to its target, and no click produces an error.
• Access state: Open; no account required.
• Failure/recovery: Any element found dead, broken, or erroring is repaired; if a target cannot be resolved, the element is corrected rather than left inert.
• Continuation: The owner reviews the repaired surfaces on Dashboard and confirms they work.

FR-2 — Replace static mock data with a genuine connection As a Dashboard Owner / Project Requester, I should have all displayed data genuinely connected rather than static mock data, using solid state management or an appropriate database/API.

• Provenance: explicit.
• Trigger/input: The owner directs the data integration work; the data source or API connection is configured.
• Observable result: Values shown on Dashboard and Data originate from the live state-management, database, or API source, and the connection state is visible.
• Access state: Open; no account required.
• Failure/recovery: When the source is unreachable, the affected view states the failure and offers retry rather than substituting mock values.
• Continuation: The owner confirms on Data that displayed values are live.

FR-3 — Clean up the codebase As a Dashboard Owner / Project Requester, I should have the codebase cleaned up — file structure tidied, unused code removed, and no browser-side console errors.

• Provenance: explicit.
• Trigger/input: The owner directs the cleanup work.
• Observable result: The file structure is orderly, unused code is removed, and the browser console shows no errors during normal use.
• Access state: Open; no account required.
• Failure/recovery: Any console error surfaced during use is traced and eliminated.
• Continuation: The owner verifies the console is clean while exercising the dashboard.

FR-4 — Prepare deployment configuration As a Dashboard Owner / Project Requester, I should have the build configuration — package.json, framework configuration files, and .env variables — correct so the code can be deployed smoothly to a hosting platform such as Vercel or Netlify.

• Provenance: explicit.
• Trigger/input: The owner directs the deployment preparation; the target platform is Vercel or Netlify.
• Observable result: The configuration items are correct and their readiness is reviewable on Deployment.
• Access state: Open; no account required.
• Failure/recovery: Any incorrect or missing configuration item is identified with a fail state and corrected.
• Continuation: The owner reviews the readiness rows and approves deployment.

FR-5 — Work directly on the existing GitHub repository As a Dashboard Owner / Project Requester, I should have the work performed on my existing GitHub repository, with the necessary code changes or additions committed directly to that repository.

• Provenance: explicit.
• Trigger/input: The owner's existing repository is available for inspection and direct commits.
• Observable result: The required changes and additions are committed to the existing repository.
• Access state: Open; no account required.
• Failure/recovery: If the repository is unavailable for inspection or commits, the work cannot proceed and the owner is informed.
• Continuation: The owner reviews the committed changes.

FR-6 — Be informed of anything needing confirmation As a Dashboard Owner / Project Requester, I should be informed about anything important that needs my confirmation.

• Provenance: explicit.
• Trigger/input: An item arises during the work that requires the owner's decision or confirmation — for example, a required deployment environment variable or hosting configuration.
• Observable result: The owner receives a clear statement of the item needing confirmation.
• Access state: Open; no account required.
• Failure/recovery: If confirmation is withheld, the dependent item remains unresolved and is shown as such rather than assumed.
• Continuation: The owner confirms and the dependent work proceeds.

FR-7 — Navigate the dashboard without broken navigation As a Dashboard End User, I should navigate the dashboard and use its controls and data views without encountering dead buttons, broken links, or click errors.

• Provenance: required_inference (indispensable participant response to the accepted repair outcome).
• Trigger/input: The end user activates a navigation element, button, or control on Dashboard.
• Observable result: The intended destination or action completes; the active nav item is marked with the tangerine edge bar.
• Access state: Open; no account required.
• Failure/recovery: A failed navigation or action reports the failure instead of silently doing nothing.
• Continuation: The end user continues through the dashboard.

FR-8 — Read live data values As a Dashboard End User, I should see data values that are genuinely live rather than mock, with a visible indication that the connection is real.

• Provenance: required_inference (indispensable participant response to the accepted data-integration outcome).
• Trigger/input: The end user opens Dashboard or Data.
• Observable result: Values render from the live source, the freshness dot pulses, and the connection chip reads connected in lime.
• Access state: Open; no account required.
• Failure/recovery: When the source is unavailable, the view states the failure and offers retry; stale data is clearly marked.
• Continuation: The end user continues reading or refreshes.

FR-9 — Review deployment readiness As a Dashboard Owner / Project Requester, I should review the deployment-readiness state of each real configuration item — package.json, framework configuration files, .env keys, and the build command — with a pass/fail indication.

• Provenance: required_inference (indispensable participant response to the accepted deployment-preparation outcome).
• Trigger/input: The owner opens Deployment.
• Observable result: Each configuration row shows its label, value or key name, and pass/fail chip; the target platform and build command are visible.
• Access state: Open; no account required.
• Failure/recovery: A failing or unset item shows a fail state and the specific item needing attention; items requiring the owner's confirmation are surfaced.
• Continuation: The owner corrects or confirms the item and the row re-resolves.

4. User Personas

Dashboard Owner / Project Requester

Product context. This persona owns the existing GitHub repository for dashboard-aplikasi-web and is the person who asked for the project to be made whole, functional, and permanently release-ready. They are not a passive stakeholder: they direct the hardening work across four fronts — feature repair, data integration, code cleanup, and deployment preparation — and they are the one who decides when the dashboard is ready to go live.

Primary goal. A working, error-free dashboard that they can deploy to Vercel or Netlify and keep running permanently, with confidence that what users see is real data and that nothing is broken.

Distinct accepted responsibilities. They direct the inspection and repair of every page, button, and navigation element; they direct the replacement of static mock data with a genuine state-management, database, or API connection; they direct the code cleanup including removal of unused code and elimination of browser console errors; they direct the preparation of package.json, framework configuration files, and .env variables for the deployment target; they review the deployment-readiness rows on Deployment and approve them; and they receive and act on anything important that needs their confirmation.

Relevant inputs and decisions. They supply the existing repository for inspection and direct commits; they name Vercel or Netlify as the deployment target; they decide whether the repaired surfaces and connected data meet their standard; they confirm required deployment environment variables and hosting configuration before release.

Interactions with other accepted participants. They are the counterparty to the Dashboard End User's experience: the end user's ability to navigate without errors and read live values is the outcome the owner is accountable for. They do not manage the end user's account, because no account capability exists.

Observable success. Every button and navigation element works; displayed values come from the live source; the browser console is clean; the Deployment page shows passing configuration rows; and the app deploys smoothly to the named platform.

Dashboard End User

Product context. This persona lives inside the dashboard. They scan dense numeric data, move through the navigation rail, and use the controls and data views as part of their regular work. They did not build the dashboard and do not configure it; they depend on it.

Primary goal. Complete their dashboard interactions — navigation, control use, and data reading — without errors or broken navigation, and trust that the numbers they see are live rather than mock.

Distinct accepted responsibilities. They navigate the dashboard and activate its controls; they read the metric strip, data table, and detail drawer; they rely on the freshness indicator and connection chip to judge whether values are current; and they retry when a view reports a connection failure.

Relevant inputs and decisions. They choose which destination to open, which row to focus and open in the detail drawer, and whether to refresh when data is marked stale. They decide whether the displayed values are trustworthy based on the visible connection state.

Interactions with other accepted participants. Their experience is the outcome the Dashboard Owner / Project Requester is accountable for. They interact with the application's navigation, controls, and data views; they do not interact with the owner through the product, and no account or permission relationship exists between them.

Observable success. Navigation resolves, buttons respond, the active nav item is marked, values render from the live source with a pulsing freshness dot and a connected chip, and no click produces an error.

5. Core User Flows

Flow 1 — Owner inspects and repairs pages, buttons, and navigation

1. The Dashboard Owner / Project Requester opens the existing GitHub repository and makes it available for inspection and direct commits.
2. The owner directs the inspection of every page, button, and navigation element in the dashboard.
3. Each page is opened and each button and navigation element is activated to determine whether it is dead, broken, or erroring.
4. Every element found dead, broken, or erroring is repaired so that it activates its intended behavior or resolves to its target.
5. The owner reviews the repaired surfaces on Dashboard, moving through the nav rail and activating controls.
6. Observable result: every button activates, every navigation element resolves, and no click produces an error.
7. Failure/recovery: if a target cannot be resolved, the element is corrected rather than left inert; the owner is informed of anything requiring confirmation.
8. Continuation: the owner proceeds to confirm the data connection.

Flow 2 — Owner connects displayed data to a genuine source

1. The owner directs the replacement of static mock data with a genuine connection.
2. The data source or state-management/API connection is configured as a prerequisite.
3. Displayed values on Dashboard and Data are rewired to read from that source instead of static mock values.
4. The owner opens Data and reads the values, checking the freshness timestamp and the connection chip.
5. Observable result: values originate from the live source, the freshness dot pulses, and the chip reads connected in lime.
6. Failure/recovery: if the source is unreachable, the affected view states the failure and offers retry; no mock values are substituted; the owner is informed of anything requiring confirmation.
7. Continuation: the owner proceeds to code cleanup.

Flow 3 — Owner cleans up the codebase

1. The owner directs the code cleanup.
2. The file structure is tidied and unused code is removed.
3. The dashboard is exercised in the browser while the console is observed.
4. Any console error surfaced during use is traced and eliminated.
5. Observable result: the file structure is orderly, unused code is gone, and the browser console shows no errors during normal use.
6. Failure/recovery: a console error that reappears is re-traced until it is eliminated.
7. Continuation: the owner proceeds to deployment preparation.

Flow 4 — Owner prepares and reviews deployment configuration

1. The owner directs the deployment preparation and names Vercel or Netlify as the target platform.
2. package.json, the framework configuration files, and the .env variables are verified and corrected for that target.
3. The owner opens Deployment and reviews the ruled spec sheet.
4. Each row presents one real configuration item — package.json, framework configuration files, .env keys, and the build command — as a monospace label/value pair with a pass/fail chip; the inline SVG topology diagram shows repo → build → host.
5. Observable result: correctly configured items show a pass chip in lime; the target platform and build command are visible.
6. Failure/recovery: a failing or unset item shows a fail state and names the specific item needing attention; required environment variables and hosting configuration that need the owner's confirmation are surfaced explicitly, and the owner confirms them.
7. Continuation: the owner approves the configuration and the app is deployed to the named platform.

Flow 5 — End user navigates the dashboard and reads live data

1. The Dashboard End User opens Landing and sees the product identity, the STATUS: SIAP RILIS micro-label, and the live miniature with a counting numeral and a connected chip.
2. The end user enters the dashboard via the tangerine CTA.
3. On Dashboard, the metric numerals count up once on first load and the freshness dot pulses; the end user moves through the nav rail, where the active item is marked with the tangerine edge bar.
4. The end user activates buttons and controls and focuses a table row, opening the detail drawer with Enter.
5. The end user opens Data and reads the full-width table with its sticky header and tabular alignment, checking the freshness timestamp.
6. Observable result: navigation resolves, controls respond, and values render from the live source with a connected chip.
7. Failure/recovery: if a fetch fails, the affected panel states the failure and offers retry; the last successfully loaded data remains visible and clearly marked as stale until fresh data arrives; a failed navigation or action reports the failure instead of silently doing nothing.
8. Continuation: the end user continues through the dashboard or refreshes.

Flow 6 — Owner is informed of items needing confirmation

1. During any of the above flows, an item arises that requires the owner's decision or confirmation — for example, a required deployment environment variable or hosting configuration.
2. The item is surfaced to the owner with a clear statement of what needs confirmation.
3. Observable result: the owner receives the statement and the dependent item is shown as unresolved until confirmed.
4. Failure/recovery: if confirmation is withheld, the dependent item remains unresolved and is shown as such rather than assumed.
5. Continuation: the owner confirms and the dependent work proceeds.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Rasmus Andersson; the headline is "Systematic product craft with graphite ground and tangerine signal — an operations console with a real point of view."

Color tokens (dark mode):

Ratio: roughly 80% graphite surfaces, 15% text, 5% tangerine + lime combined. Accents must feel earned. Bootstrap blue or indigo (#0057FF, #2563EB, #4F46E5, #7C3AED and neighbours) is forbidden anywhere in the palette, as is a white or near-white page ground with blue accents.

Typography:

• Headings: Space Grotesk at 500/600 with tight tracking (−0.02em to −0.03em), sentence case for section titles.
• Micro-labels: uppercase 11px with 0.14em tracking, used for every panel header and table column group.
• Numbers: Inter Tight with tabular-nums at 600 weight, oversized (clamp 40px → 72px) so the data itself is the typographic gesture.
• Body: Inter Tight.
• Monospace: JetBrains Mono for IDs, timestamps, env keys, and code snippets.
• Scale: 1.25 modular on a 4pt baseline — 11 (micro-label, uppercase) / 13 (table, meta) / 15 (body) / 19 (panel title) / 28 (page title) / clamp(40px, 6vw, 72px) (hero metric numerals).
• Line-height: 1.5 body, 1.15 display.
• Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are forbidden as heading or body families.

Shape language: Rectilinear and honest. 6px radius on panels and inputs, 4px on chips and buttons, 2px on the nav rail's active marker. No pills, no blobs, no continuous curves. Structure is expressed with 1px hairlines (#2A2D31) and a visible 12-column grid the user can actually see in the layout rhythm. The single decorative flourish allowed is a 3px tangerine left-edge bar on the active nav item and on the focused row.

Spacing rhythm: 4pt baseline with 24px gutters on the 12-column grid; a 64px fixed left nav rail and a 56px top status bar.

Imagery style: The interface is the imagery. Where visuals are needed they are schematic and honest — a small inline SVG topology diagram on Deployment showing repo → build → host, hairline chart lines for data sparklines, and code blocks in JetBrains Mono with graphite syntax highlighting. No stock photography, no 3D renders, no gradient blobs, no illustration for decoration.

7. Signature Design Concept

The Landing hero is not a centered headline with a button. It is a 9-column flush-left stack on the graphite ground:

• An 11px uppercase tangerine micro-label reading DASHBOARD-APLIKASI-WEB / STATUS: SIAP RILIS.
• Beneath it, a two-line Space Grotesk headline at clamp(40px, 7vw, 96px) spanning the full column width, describing the hardened, release-ready dashboard.
• To its right, occupying the remaining 3 columns, a live miniature of the actual dashboard: a real metric tile with a counting numeral, a lime "connected" chip, and a sparkline, inset in a #1C1E21 panel with a hairline border.
• The CTA sits beneath the headline as a tangerine rectangle, not a pill, with the secondary link rendered as monospace text.

The composition reads as an instrument panel, not a marketing page. It recomposes only accepted content — the product identity, the release status, the live connection state, and the headline metric value — and introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The live dashboard miniature — a real metric tile with a counting numeral, a lime "connected" chip, and a sparkline, inset in a #1C1E21 panel with a hairline border.
• Input → transformation → outcome thesis: On first paint, the live value resolves from the genuine data source; the numeral counts up once (600ms, no bounce) and the connection chip flips to lime, so the visitor sees the product's defining claim — that the data is real, not mock — demonstrated rather than asserted.
• Motion vocabulary: Functional only, 120–200ms with cubic-bezier(0.2, 0, 0, 1) — hover states, chip color flips, focus rings. One purposeful ambient loop: the lime data-freshness dot pulses softly to prove the connection is live. No parallax, no scroll-jacking, no decorative entrances.
• Composed first frame: The 9-column flush-left stack on the graphite ground with the tangerine micro-label, the two-line Space Grotesk headline, the tangerine rectangular CTA, the monospace secondary link, and the 3-column live miniature panel to the right — all fully composed before any motion begins.
• Reduced-motion state: With prefers-reduced-motion, the count-up is skipped and the numeral renders at its final value immediately; the freshness pulse stops and the dot renders in a steady lime state; all text and controls remain whole and fully readable.

9. Non-Functional Requirements

• No dead buttons, broken links, or click errors. Every page, button, and navigation element in the dashboard must function without error when activated. Provenance: explicit. Rationale: the user's first stated focus.
• No static mock data in displayed views. All displayed data must be connected to genuine state management or a database/API. Provenance: explicit. Rationale: the user's second stated focus.
• No browser-side console errors. The browser console must show no errors during normal use. Provenance: explicit. Rationale: the user's third stated focus.
• Tidy file structure and no unused code. The codebase must be organized with unused code removed. Provenance: explicit. Rationale: the user's third stated focus.
• Correct build configuration. package.json, framework configuration files, and .env variables must be correct for smooth deployment. Provenance: explicit. Rationale: the user's fourth stated focus.
• Deployment target compatibility. The configuration must target Vercel or Netlify. Provenance: explicit. Rationale: the user names these platforms.
• Direct commits to the existing repository. Changes and additions must be committed directly to the user's existing GitHub repository. Provenance: explicit. Rationale: the user's stated working method.
• Owner notification of confirmation items. The owner must be informed of anything important that requires their confirmation. Provenance: explicit. Rationale: the user's closing instruction.
• Readable text and controls stay whole at every viewport. Headlines, wordmarks, labels, numbers, cards' text, and controls must 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, with no other element covering any part of them. Provenance: explicit (creative direction). Rationale: the direction's readability rule, which takes precedence for readable text and controls.
• Keyboard navigability. Interactive elements must be keyboard-navigable with visible 2px tangerine focus rings, and table rows must open the detail drawer on Enter. Provenance: explicit (creative direction). Rationale: the direction specifies a keyboard-first console.

10. Tech Stack

• Frontend: React (web application). Provenance: required_inference — the project is an existing web dashboard being hardened; React is the appropriate web framework for the accepted custom-UI delivery shape.
• State management / data connection: A solid state-management layer plus a database or API connection supplying live values, replacing static mock data. Provenance: explicit — the user requires genuine connection via solid state management or an appropriate database/API.
• Backend integration: Required. The application consumes a data source or API; the source itself remains externally owned. Provenance: explicit (data integration requirement) with required_inference for the connection prerequisite.
• Build and deployment configuration: package.json, framework configuration files, and .env variables configured for Vercel or Netlify. Provenance: explicit.
• Hosting: Vercel or Netlify. Provenance: explicit.
• Typography: Space Grotesk (headings), Inter Tight (body and numerals), JetBrains Mono (monospace). Provenance: explicit (creative direction).

11. Assumptions and Constraints

Constraints (binding):

• Work is performed on the user's existing GitHub repository, with changes committed directly to that repository.
• Deployment target platforms named by the user are Vercel or Netlify.
• The user must be informed of anything important that requires their confirmation.
• Bootstrap blue or indigo (#0057FF, #2563EB, #4F46E5, #7C3AED and neighbours) is forbidden anywhere in the palette.
• Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are forbidden as heading or body families.
• A white or near-white page ground with blue accents is forbidden; the ground is graphite.
• Gradient-blob heroes, glassmorphism, frosted panels, floating gradient cards, grids of identical hover-lift cards with soft drop shadows, centered headline + subtext + blue button + illustration hero compositions, pill-shaped buttons, blob shapes, continuous-curve radii, and decorative animation, parallax, or scroll-jacking are forbidden.
• Readable text and controls stay whole at every viewport; where a direction asks readable text or a control to be cropped, clipped, covered, or run off an edge, it is kept whole and the gesture is carried with imagery or decoration instead.

Assumptions (narrow, labeled):

• [Assumption — required_inference] The existing GitHub repository is available for inspection and direct commits; without it the accepted work cannot proceed.
• [Assumption — required_inference] The data source or state-management/API connection must be configured before connected data can replace static mock data.
• [Assumption — required_inference] Required deployment environment variables and hosting configuration must be confirmed before release.
• [Assumption — required_inference] The existing repository's concrete file names, page inventory, button inventory, navigation entries, mock data, and configuration values are supplied by the repository itself during inspection; this document does not invent them.
• [Default — not specified by user] No application-owned identity, authentication, or account-management capability is required; all four pages are openly reachable.
• [Default — not specified by user] No role-based permissions or differentiated visibility are required; the source establishes none.

12. Glossary

• dashboard-aplikasi-web — The project name; the existing Indonesian-language web dashboard being hardened into a complete, functional, permanently release-ready application.
• Dashboard Owner / Project Requester — The accepted persona who owns the existing GitHub repository, directs the hardening work, reviews the repaired surfaces and connected data, and approves the deployment configuration.
• Dashboard End User — The accepted persona who navigates the dashboard, uses its controls, and reads its data views.
• Dead button — A button that produces no effect when activated.
• Broken link — A navigation element that does not resolve to its intended target.
• Mock data — Static placeholder values that are not connected to a genuine state-management, database, or API source.
• Genuine connection — A data path in which displayed values originate from a live state-management layer, database, or API rather than static mock values.
• Console error — An error emitted to the browser's developer console during normal use.
• Deployment configuration — The package.json, framework configuration files, and .env variables that determine whether the application builds and deploys correctly.
• Deployment readiness — The pass/fail state of each real configuration item, reviewed on the Deployment page.
• Freshness pulse — The softly pulsing acid-lime dot that indicates the data connection is live.
• Connection chip — The acid-lime status chip reading connected/live, reserved strictly for status.
• Nav rail — The 64px fixed left navigation rail with a 3px tangerine active-edge bar, collapsing to a bottom tab bar at 375px.
• Top status bar — The persistent 56px bar carrying environment, short commit SHA, and the freshness pulse.
• Spec sheet — The Deployment page's ruled layout of label/value rows in monospace with pass/fail chips.
• Detail drawer — The right-hand panel that opens on Enter when a table row is focused.