System Requirements Document for solar-apk

1. Introduction

solar-apk is a single-page HTML application about "bug WA" — bugs and problems in WhatsApp. The product intent, derived from the authoritative user requirement thread ("Buatkan apk", "Buatkan html bug wa"), is to deliver a self-contained HTML page that a WhatsApp user (the owner of a phone number) can open to see and understand WhatsApp bug/masalah content, and to report a bug they are experiencing.

The audience is ordinary WhatsApp users in Indonesia who arrive anxious about a malfunction and need to be told, quickly and with a bit of delight, what the bug is and what to do. The page is a consumer-facing utility, not a corporate support article: it should feel like a living instrument whose own reactivity mirrors the glitchy, kinetic subject matter.

The request is deliberately terse. The authoritative thread does not specify the type of bug, the purpose of the page, or whether it is a tool, a report, or a demo. This SRD therefore preserves that ambiguity as a hard constraint: it commits only to what was asked — an HTML page about WhatsApp bugs — and marks every inferred mechanic explicitly.

2. System Overview

The current delivery is a single anonymous HTML page named Landing, owned by the application, reachable with no access requirement. It is the public entry surface for the product. There is no authenticated area, no account, and no differentiated permission model: the page is public and ephemeral, and no durable actor-specific state is required by any accepted journey.

The single accepted human actor is Pengguna WhatsApp (pemilik nomor) — a WhatsApp user who owns a phone number. That actor opens the Landing page, reads what the page presents about WhatsApp bugs, and can report a bug through the page's primary action.

Accepted behavior on the page:

• Present the product identity and the subject ("BUG WA") as the entry statement.
• Present a list of WhatsApp bug entries, each as a full-width ruled row with an index number, a state chip, and a one-line description.
• Present a marquee ticker of recent report strings.
• Provide a primary action, LAPORKAN BUG, that lets the user report a bug.
• Present a procedural "glitch" demonstration in which a monospace string scrambles and resolves.

Narrow exclusions and boundaries:

• No photography, illustration, or 3D imagery is used; the imagery is the interface itself.
• No account creation, login, or permission management is in scope.
• No backend, provider, or external service is named or required by the source.
• The generic indigo/blue-on-white SaaS template look is explicitly rejected.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is delivered as a first-party HTML page. The application owns the Landing surface and everything rendered on it. No provider-owned surface, external destination, or headless delivery is specified by the source, and none is introduced here.

Access ownership. The Landing page is anonymous and public: access_requirement is none. This is a hard, source-backed fact from the planning boundary. Because no accepted journey requires a human to privately own or resume durable actor-specific state, and because no commitment, decision, entitlement, or value transfer must remain bound to a particular participant, no application-owned identity is established. There is no first-use identity establishment, no returning verification, and no protected destination. The page is usable immediately on open.

Current horizon. Everything in Sections 2c, 3, and 5 is current: the Landing page, its bug list, its marquee, its glitch demonstration, and the LAPORKAN BUG action.

Future horizon. Nothing in the authoritative thread commits to future work. Any expansion of the bug catalog, any persistence of submitted reports, and any backend handling of reports are explicitly not current commitments and are recorded only in Section 11 as open questions.

Ambiguity boundary. The source does not define what "bug wa" means beyond "bugs/problems in WhatsApp." This SRD does not resolve that ambiguity by inventing a taxonomy, a diagnostic engine, or a support workflow. It commits to a page that presents bug content and accepts a bug report, and it labels the specific mechanics of both as required_inference.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares content_source, so no source content inventory is produced. All factual content on the page is either source-stated or explicitly marked as inferred.

2c. Page Content and Component Coverage

The reconciled page inventory is the single supplied page from the versioned page contract, copied exactly:

Landing

Purpose and access. Anonymous public entry surface for solar-apk. access_requirement: none. Owned by the application. No identity is established or required to view or use any part of this page.

Information and state presented

• Product identity: the wordmark/subject BUG WA, set as the hero headline.
• A one-line body statement in #F2F2F0 describing the page's subject (WhatsApp bugs/masalah).
• A list of WhatsApp bug entries. Each entry carries: a monospace index number, a state chip, and a one-line description.
• A marquee ticker of recent report strings, in 11px uppercase.
• A procedural glitch demonstration: a monospace string that scrambles and resolves.
• A permanently visible 1px hairline 12-column grid overlay.

Primary action

• LAPORKAN BUG — a full-bleed rectangular lime CTA pinned to the hero baseline. This is the page's single primary action and the only entry point into reporting.

Supporting actions and controls

• State chips on bug rows: toggling a chip flips its colour instantly, with no easing.
• Scrolling through the bug list and the marquee content.
• Cursor movement across the hero, which disturbs the dot field and the headline glyphs.

Domain entities

• Bug entry — index number, state chip value, one-line description.
• Report string — a short uppercase text item shown in the marquee.
• Bug report — the item the user submits via LAPORKAN BUG. Its fields are not specified by the source; see Section 11.

Component responsibilities

• Hero — full-viewport black ground; hosts the dot grid, the kinetic headline, the body line, the CTA, and the vermilion rule.
• Dot grid — a 1px dot field across the hero; points within 120px of the cursor displace and ease back over 400ms, leaving a visible trail.
• Kinetic headline — "BUG WA" split per character; each glyph nudges 2–4px away from the cursor and eases back, and reflows per character on scroll into view.
• Hairline grid overlay — a 1px 12-column overlay visible at all times.
• Vermilion rule — a 1px #FF4D2E horizontal rule running the full viewport width under the hero.
• Marquee ticker — recent report strings crossing the viewport edge at 11px uppercase.
• Bug list — full-width ruled rows; no cards, no hover-lift, no shadow.
• State chip — instant colour flip on toggle.
• Glitch string — a monospace string that scrambles and resolves procedurally.
• CTA slab — rectangular, 1px lime border, inverts on hover.

States

• Loading — the page is a static HTML document; no asynchronous data source is specified, so no loading state is required. If any content is later fetched, a loading state must be added at that time.
• Empty — if the bug list contains no entries, the list region shows an empty ruled row stating that no bug entries are currently listed. The hero, marquee, and CTA remain fully usable. This is required_inference: a list region with no defined empty treatment would leave the page's primary content area undefined.
• Success — the page renders the hero, the bug list, the marquee, and the CTA; the user can read bug content and reach LAPORKAN BUG.
• Error — no network or provider dependency is specified, so no runtime error state is defined for page load. If the user's report submission cannot be completed, the page must state that the report was not sent and keep the user's input available so it is not lost. This is required_inference and is bounded by Section 11.
• Recovery — the user can retry the report action, or dismiss it and continue reading the bug list. No state is lost that the user cannot re-enter.
• Reduced motion — under prefers-reduced-motion, the dot field freezes, the marquee unwraps into a static scrollable list, and headlines appear in their final state. All content remains fully readable and every control remains operable.

3. Functional Requirements

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

FR-1 — Open the WhatsApp bug page

As a Pengguna WhatsApp (pemilik nomor), I should be able to open the solar-apk HTML page and immediately see that it is about WhatsApp bugs, so that I know I am in the right place.

• Provenance: explicit
• Actor: Pengguna WhatsApp (pemilik nomor)
• Trigger/input: The user opens the HTML page in a browser.
• Observable result: The Landing page renders with the "BUG WA" headline, the body line, the bug list, the marquee, and the LAPORKAN BUG CTA visible.
• Access state: Anonymous. No identity, account, or permission is required.
• Failure/recovery: If the page fails to render, the user reloads. No partial-render state is defined.
• Continuation: The user reads the bug list or proceeds to FR-4.
• Acceptance: On open, the headline, body line, bug list, marquee, and CTA are all present and readable at 375px, 768px, and 1280px.

FR-2 — Read the list of WhatsApp bug entries

As a Pengguna WhatsApp (pemilik nomor), I should be able to read a list of WhatsApp bug entries, each with an index number, a state chip, and a one-line description, so that I can understand which bugs exist.

• Provenance: required_inference (the source asks for a page about "bug wa"; a page about bugs must present bug entries)
• Actor: Pengguna WhatsApp (pemilik nomor)
• Trigger/input: The user scrolls the Landing page.
• Observable result: Each bug entry appears as a full-width ruled row containing a monospace index number, a state chip, and a one-line description. Rows are separated by hairline rules, not cards.
• Access state: Anonymous.
• Failure/recovery: If no entries exist, the empty state in Section 2c applies.
• Continuation: The user continues scrolling, toggles a chip (FR-3), or proceeds to FR-4.
• Acceptance: Every entry's index number, chip, and description are fully readable and inside the viewport at 375px, 768px, and 1280px; no element covers any part of them.

FR-3 — Toggle a bug entry's state chip

As a Pengguna WhatsApp (pemilik nomor), I should be able to toggle a bug entry's state chip and see it change instantly, so that I can mark or inspect the state of that entry.

• Provenance: required_inference (the creative direction specifies state chips that flip colour instantly when toggled; this is the only interaction the chips are given)
• Actor: Pengguna WhatsApp (pemilik nomor)
• Trigger/input: The user activates a state chip on a bug row.
• Observable result: The chip's colour flips immediately, with no easing or transition.
• Access state: Anonymous.
• Failure/recovery: The user activates the chip again to return it to its prior state.
• Continuation: The user continues reading the list or proceeds to FR-4.
• Acceptance: The colour change is instantaneous and the chip remains fully readable and inside its row at all three breakpoints.

FR-4 — Report a bug

As a Pengguna WhatsApp (pemilik nomor), I should be able to report a bug through the page's primary action, so that the problem I am experiencing is recorded.

• Provenance: required_inference (the creative direction specifies a primary CTA labelled "LAPORKAN BUG" pinned to the hero baseline; a CTA with that label must lead to a report interaction)
• Actor: Pengguna WhatsApp (pemilik nomor)
• Trigger/input: The user activates the LAPORKAN BUG CTA.
• Observable result: The page presents the report interaction, the user supplies the report, and the page confirms that the report was received.
• Access state: Anonymous. No identity is required to report.
• Failure/recovery: If the report cannot be completed, the page states that it was not sent and keeps the user's input available so it is not lost; the user can retry or dismiss.
• Continuation: After confirmation, the user returns to the bug list and continues reading.
• Acceptance: The CTA is reachable and operable at 375px, 768px, and 1280px; the confirmation or failure message is fully readable and not covered by any other element.
• Boundary: The specific fields of a bug report and the destination of a submitted report are not specified by the authoritative source. See Section 11. This requirement commits only to the existence of the report interaction and its observable confirmation/failure outcome.

FR-5 — See recent report strings in the marquee

As a Pengguna WhatsApp (pemilik nomor), I should be able to see a marquee of recent report strings crossing the page, so that I get a sense of what other users are reporting.

• Provenance: required_inference (the creative direction specifies a vermilion marquee ticker of recent report strings at 11px uppercase)
• Actor: Pengguna WhatsApp (pemilik nomor)
• Trigger/input: The user views the hero region; the marquee moves on its own.
• Observable result: Report strings cross the viewport edge in 11px uppercase along the vermilion rule.
• Access state: Anonymous.
• Failure/recovery: Under prefers-reduced-motion, the marquee unwraps into a static scrollable list in which every item can be brought fully into view.
• Continuation: The user continues to the bug list or the CTA.
• Acceptance: Each report string becomes fully readable as it passes, or is fully readable in the reduced-motion static list. The marquee may cross the viewport edge by design.

FR-6 — See the procedural glitch demonstration

As a Pengguna WhatsApp (pemilik nomor), I should be able to see a monospace string scramble and resolve, so that the page's subject — a system misbehaving — is shown rather than described.

• Provenance: required_inference (the creative direction specifies a procedural glitch demo: a monospace string that scrambles and resolves)
• Actor: Pengguna WhatsApp (pemilik nomor)
• Trigger/input: The user views the region containing the glitch string.
• Observable result: The monospace string scrambles and then resolves to its final readable value.
• Access state: Anonymous.
• Failure/recovery: Under prefers-reduced-motion, the string is shown directly in its resolved state.
• Continuation: The user continues reading.
• Acceptance: The resolved string is fully readable and inside its container at all three breakpoints.

FR-7 — Experience the page as a reactive instrument

As a Pengguna WhatsApp (pemilik nomor), I should be able to move my cursor across the hero and see the dot field and headline respond, so that the page feels like a living instrument rather than a static article.

• Provenance: required_inference (the creative direction's signature moves: cursor-reactive dot grid and per-character kinetic headline)
• Actor: Pengguna WhatsApp (pemilik nomor)
• Trigger/input: The user moves the cursor across the hero region.
• Observable result: Dot-grid points within 120px of the cursor displace and ease back over 400ms, leaving a visible trail; headline glyphs nudge 2–4px away from the cursor and ease back.
• Access state: Anonymous.
• Failure/recovery: Under prefers-reduced-motion, the dot field freezes and headlines appear in their final state; all content and controls remain fully usable.
• Continuation: The user proceeds to the bug list or the CTA.
• Acceptance: The headline remains fully readable and inside the viewport at 375px, 768px, and 1280px throughout the motion; no glyph is permanently displaced or covered.

4. User Personas

Pengguna WhatsApp (pemilik nomor)

Product context. This person uses WhatsApp as a daily communication tool and owns the phone number their account is bound to. They arrive at solar-apk because something in WhatsApp is misbehaving — a message that will not send, a notification that does not arrive, a status that will not update — and they want to know whether the problem is a known bug and what to do about it. They are not a developer and are not looking for a technical report; they are looking for a fast, legible answer.

Primary goal. To open the page and quickly understand what WhatsApp bug content is presented, and to report the bug they are experiencing if it is not already listed.

Distinct accepted responsibilities. This persona is the sole human actor in the product. Their responsibilities are: (1) opening and reading the page, (2) reading the bug entry list and inspecting individual entries' state chips, (3) reporting a bug through the LAPORKAN BUG action, and (4) reading the marquee of recent report strings. No other human actor shares or divides this work.

Relevant inputs and decisions. The user's input is their own observation of a WhatsApp malfunction and their decision about whether to report it. They decide whether a listed bug entry matches their problem, and they decide whether to activate LAPORKAN BUG. They supply the content of their report through the report interaction.

Interactions with other accepted participants. There are none. No other accepted human persona exists in this product, and no provider, external service, or system actor is specified by the source. The user's only counterparty is the page itself.

Observable success. The user can open the page, see the "BUG WA" headline and the bug list, read each entry's index, chip, and description, and reach and complete the LAPORKAN BUG action with a visible confirmation. Under reduced-motion settings, all of this remains fully available in a static arrangement.

Constraints carried from source. The persona's recurring goals and responsibilities cannot be detailed further because the authoritative request is still very vague — the type of bug, the purpose of the page, and whether it is a tool, a report, or a demo are all undefined. This persona profile therefore describes only what the accepted behavior supports and does not invent a diagnostic role, a support role, or an administrative role.

5. Core User Flows

Flow 1 — Open the page and read the bug list

1. Starting context. The user is on their phone or desktop browser, having just experienced a WhatsApp malfunction. They have the solar-apk HTML page URL.
2. Action. The user opens the page. No login, account, or permission step occurs — the page is anonymous and public.
3. Observable result. The Landing page renders: the "BUG WA" headline in Space Grotesk 700 at clamp(56px, 14vw, 128px), a one-line body statement, the bug list, the vermilion rule with the marquee, and the LAPORKAN BUG CTA pinned to the hero baseline. The 1px hairline 12-column grid overlay is visible.
4. Action. The user scrolls down through the bug list.
5. Observable result. Each bug entry appears as a full-width ruled row with a monospace index number, a state chip, and a one-line description. Rows are separated by hairline rules; there are no cards, no hover-lift, and no shadows.
6. Decision. The user identifies whether any listed entry matches their problem.
7. Continuation. If a match exists, the user reads that entry and may toggle its state chip (Flow 2). If no match exists, the user proceeds to Flow 3.

Failure/recovery. If the bug list is empty, the list region shows a ruled row stating that no bug entries are currently listed; the hero, marquee, and CTA remain fully usable and the user can still proceed to Flow 3.

Flow 2 — Inspect a bug entry's state

1. Starting context. The user is on the Landing page, scrolled to the bug list.
2. Action. The user activates the state chip on a bug row.
3. Observable result. The chip's colour flips instantly, with no easing or transition.
4. Continuation. The user activates the chip again to return it to its prior state, or continues scrolling to the next entry.

Failure/recovery. The toggle is reversible by repeating the same action; no state is lost.

Flow 3 — Report a bug

1. Starting context. The user is on the Landing page and has determined that their WhatsApp problem is not adequately covered by the listed entries, or wishes to report it regardless.
2. Action. The user activates the LAPORKAN BUG CTA — a full-bleed rectangular slab with a 1px lime border that inverts on hover.
3. Observable result. The page presents the report interaction.
4. Action. The user supplies their report and submits it.
5. Observable result (success). The page confirms that the report was received.
6. Continuation. The user returns to the bug list and continues reading, or closes the page.

Failure/recovery. If the report cannot be completed, the page states that the report was not sent and keeps the user's input available so it is not lost. The user can retry the submission or dismiss the interaction and return to the bug list. No state is lost that the user cannot re-enter.

Boundary. The specific fields of a bug report and the destination of a submitted report are not specified by the authoritative source. This flow commits only to the existence of the report interaction and its observable confirmation or failure outcome. See Section 11.

Flow 4 — Experience the page's reactive behavior

1. Starting context. The user is on the Landing page, at the hero.
2. Action. The user moves their cursor across the hero region.
3. Observable result. Dot-grid points within 120px of the cursor displace and ease back over 400ms, leaving a visible trail. The "BUG WA" headline glyphs nudge 2–4px away from the cursor and ease back. As the user scrolls the headline into view, it reflows per character.
4. Observable result (ambient). The marquee of recent report strings crosses the viewport edge in 11px uppercase along the vermilion rule. The glitch string scrambles and resolves.
5. Continuation. The user proceeds to the bug list (Flow 1) or the CTA (Flow 3).

Failure/recovery (reduced motion). Under prefers-reduced-motion, the dot field freezes, the marquee unwraps into a static scrollable list in which every item can be brought fully into view, and headlines appear in their final state. All content remains fully readable and every control remains operable.

6. Visuals, Colors, and Theme

The creative direction is authoritative for this section. The muse is Yugo Nakamura, and the headline concept is "Kinetic signal — interaction as the diagnostic for a WhatsApp bug page." The page should feel like a living instrument, not a corporate support article: the subject is glitchy, kinetic, and reactive, and the design language mirrors that.

Color tokens (dark mode)

Ratio discipline: approximately 85% black ground, 10% off-white type, 4% lime, 1% vermilion. Colour is earned, never decorative.

Typography

• Headings: Space Grotesk, weight 700, tight tracking -0.03em, lowercase-first for a casual technical voice. Kinetic headings split per character and animate on scroll into view.
• Body: Space Grotesk.
• Micro-labels: uppercase, 11px, letter-spacing 0.18em, in lime or muted.
• Scale: 1.333 modular — display 56px mobile → 128px desktop (clamp), h2 32/48, h3 22/28, body 16/17, micro-label 11/11 uppercase.
• Line-height: 1.05 for display, 1.5 for body.

Shape language

Hard-edged rectangles and hairline 1px rules. No rounded corners on primary surfaces, so the kinetic type and cursor physics are the only softness. Buttons are full-bleed rectangular slabs with a 1px lime border that inverts on hover. A single generative grid of 1px dots sits behind the hero as a coordinate field the cursor disturbs.

Layout

Full-viewport playground hero: a 12-column grid with a 1px hairline overlay visible at all times — the "grid you can feel." Section transitions are horizontal rule sweeps, not cards. Content sections are dense, single-column on mobile, two-column asymmetric on desktop (7/5 split). No identical card grid: each bug entry is a full-width ruled row with a number, a state chip, and a one-line description.

Imagery

No photography, no illustration, no 3D. The imagery is the interface: a generative dot grid, kinetic type, a live cursor trail, and a marquee of report strings. Where a visual is needed (the glitch demo), a monospace string scrambles and resolves — procedural, not drawn.

Explicitly avoided

Blue/indigo primary on white; gradient-blob heroes or any soft gradient background; grids of identical hover-lift cards with soft shadows; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui; rounded pill buttons and 16px+ corner radii; photography, stock people, or decorative illustration; bouncy spring easing; anything that performs without responding to the cursor or scroll.

7. Signature Design Concept

The page is the bug.

The public entry is a full-bleed black viewport in which a 1px dot grid covers the entire first screen. The headline "BUG WA" is set in Space Grotesk 700 at clamp(56px, 14vw, 128px), split per character. Each glyph nudges 2–4px away from the cursor as it passes and eases back — the type itself is the interactive subject, and the page's own reactivity is the diagnostic metaphor for a system misbehaving.

Below the headline, left-aligned on the 12-column grid, sits a single line of body copy in #F2F2F0 and one rectangular lime CTA, LAPORKAN BUG, pinned to the baseline. A vermilion 1px horizontal rule runs the full viewport width under the hero, and a marquee of recent report strings crosses it in 11px uppercase. No gradient, no blob, no centred stack.

The concept recomposes only accepted content, states, and controls: the headline, the body line, the CTA, the bug list, the marquee, the glitch string, and the dot field. It introduces no new behavior, 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 "BUG WA" headline itself, set per character over a 1px dot grid that spans the full first screen. The type is the subject; the grid is its coordinate field.

Input → transformation → outcome thesis. As the user moves the cursor across the hero, dot-grid points within 120px displace and ease back over 400ms, leaving a visible trail, while each headline glyph nudges 2–4px away from the cursor and eases back. As the user scrolls the headline into view, the glyphs reflow per character into their final arrangement. The outcome is a page that visibly responds to the person reading it — the same reactive, glitchy quality as the subject it describes.

Motion vocabulary. Cursor-reactive displacement with physical ease-back (not spring); per-character kinetic type; instant, uneased state-chip colour flips; a marquee crossing the viewport edge; a procedural monospace scramble-and-resolve. Motion is reactive and physical, never playful or bouncy.

Composed first frame. Full-bleed #0B0B0C. The 1px dot grid covers the whole first screen. "BUG WA" sits large and left-aligned on the 12-column grid, with the hairline overlay visible over it. Below, the single body line in #F2F2F0 and the lime LAPORKAN BUG slab pinned to the baseline. A vermilion 1px rule runs the full viewport width beneath, with the uppercase marquee crossing it.

Reduced-motion state. The dot field freezes into a static grid, the marquee unwraps into a static scrollable list in which every item can be brought fully into view, and the headline appears in its final state with no per-character animation. All content remains fully readable and every control remains operable.

9. Non-Functional Requirements

NFR-1 — Readable text and controls stay whole at every viewport. (Provenance: explicit — creative direction.) Headlines, wordmarks, labels, numbers, and the text and controls of every row 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. No other element covers any part of them. Where the direction asks for a cropped or bled gesture, the gesture is carried by imagery or decoration instead.

NFR-2 — Moving and scrollable content is judged by its motion. (Provenance: explicit — creative direction.) The marquee and any horizontally scrollable row may cross the viewport or container edge by design. Each item must become fully readable as it passes, or be fully readable in the reduced-motion static arrangement. A scrollable row need not show every item fully at once.

NFR-3 — Reduced-motion support. (Provenance: explicit — creative direction.) Under prefers-reduced-motion, the dot field freezes, the marquee unwraps into a static list, and headlines appear in their final state. The page remains fully usable and all content remains readable.

NFR-4 — Anonymous, no-account access. (Provenance: explicit — planning boundary access_requirement: none.) The Landing page is reachable and fully usable without identity, account, or permission. No authentication step may gate any part of the page.

NFR-5 — Self-contained HTML delivery. (Provenance: explicit — "Buatkan html bug wa".) The product is delivered as an HTML page. It must render and be usable as a page, not as a native application binary.

NFR-6 — No external content dependency. (Provenance: required_inference.) Because no provider, external service, or backend is specified by the source, the page must not depend on an external content source to render its hero, bug list, marquee, or CTA. Any content shown is part of the page itself.

NFR-7 — Motion performance. (Provenance: required_inference.) The cursor-reactive dot field and per-character headline must respond without perceptible lag on a typical consumer device, since the reactive quality is the page's core design premise. The 400ms ease-back and 120px displacement radius are the specified parameters.

10. Tech Stack

The authoritative source specifies only that the product is an HTML page ("Buatkan html bug wa"). That choice is preserved exactly.

• Markup and styling: HTML and CSS, delivered as a self-contained page. No framework is specified by the source and none is required.
• Typography: Space Grotesk, loaded as a webfont.
• Motion: CSS transitions and transforms for the dot field, kinetic headline, marquee, and state chips; a small amount of JavaScript for cursor tracking, per-character splitting, the marquee, and the procedural glitch string.
• Storage: None. No persistence is specified or required by any accepted journey.
• Backend, Docker, Kubernetes: Not applicable. No server, container, or orchestration requirement exists in the source.

[Default — not specified by user]: The specific build tooling, bundler, and hosting arrangement are not specified by the user and are left to implementation.

11. Assumptions and Constraints

Hard constraints from source

C-1 — The request is ambiguous. (Provenance: explicit.) "Bug wa" is not explained further: the type of bug, the purpose of the page, and whether it is a tool, a report, or a demo are all undefined. Behavioral product detail is therefore not established by the source. This SRD commits only to what was asked and marks every inferred mechanic explicitly.

C-2 — The generic indigo/blue-on-white SaaS template is forbidden. (Provenance: explicit — creative direction.) This is a binding visual prohibition.

C-3 — No photography, illustration, or 3D imagery. (Provenance: explicit — creative direction.) The imagery is the interface itself.

C-4 — Anonymous access. (Provenance: explicit — planning boundary.) The Landing page has access_requirement: none.

Assumptions

A-1. The bug entries shown on the page are part of the page's own content, not fetched from an external source. (Assumption — no data source is specified.)

A-2. The LAPORKAN BUG action leads to a report interaction whose confirmation is shown on the page. The specific fields of a bug report and the destination of a submitted report are not specified by the authoritative source and remain open. (Assumption — bounded by C-1.)

A-3. The marquee's "recent report strings" are page content, not a live feed. (Assumption — no feed source is specified.)

A-4. The page is delivered in Indonesian-facing copy consistent with the source language, with the CTA label "LAPORKAN BUG" preserved exactly. (Assumption.)

Open questions (not current commitments)

• What specific WhatsApp bugs the page should list.
• Whether a submitted bug report is stored anywhere, and if so, where.
• Whether the page should ever expand beyond a single Landing page.

None of these are current requirements. They are recorded so that the ambiguity constraint C-1 is not silently resolved by implementation.

12. Glossary

BUG WA — The product's subject and hero headline: bugs and problems in WhatsApp.

Bug entry — A single row in the Landing page's bug list, composed of a monospace index number, a state chip, and a one-line description.

State chip — A small control on a bug row whose colour flips instantly, with no easing, when toggled.

Report string — A short uppercase text item shown in the marquee ticker of recent reports.

Bug report — The item a user submits through the LAPORKAN BUG action. Its fields are not specified by the source.

LAPORKAN BUG — The page's single primary call to action, rendered as a full-bleed rectangular lime slab pinned to the hero baseline.

Dot grid — The 1px generative dot field covering the hero, whose points displace within 120px of the cursor and ease back over 400ms.

Glitch string — A monospace string that scrambles and resolves procedurally, used as the page's only "visual."

Pengguna WhatsApp (pemilik nomor) — The single accepted human persona: a WhatsApp user who owns the phone number their account is bound to.

Landing — The single page of solar-apk: an anonymous, public entry surface owned by the application.