System Requirements Document for windy-infranite

1. Introduction

windy-infranite is an Android application that wraps the existing website https://infranite-ai.lovable.app inside a native WebView shell and is distributed as a downloadable APK so the requester can install it on a device and test it.

The product intent is deliberately narrow and explicit: the existing site is the content and the functionality; this project does not rebuild, restyle, or re-implement that site. The project's own deliverable is the wrapper — an Android shell that loads the target URL in a WebView, plus a first-party surface from which the built APK artifact can be downloaded for testing.

The audience is a single technical actor: the App Tester / Downloader, who must be able to (a) understand exactly what the artifact is and what it does, (b) download the APK, (c) install it on an Android device, and (d) confirm that the wrapped site loads and behaves inside the shell.

2. System Overview

The current delivery consists of two first-party surfaces and one native runtime:

• Landing — an anonymous public entry surface that presents the wrapper honestly: the target URL, the build specification, and a live WebView frame of https://infranite-ai.lovable.app (or an honest "preview unavailable" state when the site cannot be rendered at build/crawl time). It carries the primary Download APK action.
• Download — an anonymous surface that owns the artifact itself: version, size, build date, SHA-256 checksum, install steps, and the permissions / what-it-does-not-do table.
• Android WebView runtime — the installed APK, which loads https://infranite-ai.lovable.app in its WebView and hands the stage to the site.

Actors:

• App Tester / Downloader (active human persona) — obtains the artifact, installs it, and exercises the wrapped site.
• Android WebView runtime (system actor) — loads and renders the target URL inside the installed app.
• Target site https://infranite-ai.lovable.app (external, provider-owned) — supplies all wrapped content and behavior; it is not owned, rebuilt, or restyled by this project.

Narrow exclusions:

• The wrapped site's own content, pages, and functionality are not part of this build.
• The wrapper must not override, restyle, or replace the target site's look.
• No account, login, or identity system is required for either first-party surface; both are anonymous.

2a. Product Interpretation and Delivery Boundary

This project is a distribution and shell project, not a website project. The authoritative instruction is to wrap an existing website in an Android WebView APK and make that APK downloadable for testing; the site itself is explicitly out of scope for rebuilding.

Delivery ownership therefore splits cleanly:

• First-party (this project): the Android wrapper application, its WebView configuration, the build artifact, and the two anonymous surfaces that present the build facts and serve the download.
• Provider-owned (external): everything rendered inside the WebView. The wrapper presents the target URL honestly and hands control to the site; it does not author, mirror, or restyle that content.

Access boundary: both first-party surfaces are anonymous and require no identity. There is no durable actor-specific state that must be privately owned or resumed, and no commitment, entitlement, or value transfer that must remain bound to a particular participant. Application-owned identity is therefore not introduced.

Current vs. future: everything described in this document is current. No future-horizon capabilities are accepted.

2b. Source Content Inventory

The reference directive for https://infranite-ai.lovable.app declares uses: ["content_source", "feature_reference"] with authority: authoritative. However, the verified source observations record that no visible content could be retrieved from that URL — no HTML, text, links, or structural data were captured, and no fields, features, descriptions, links, or media references could be extracted or confirmed.

Consequently there are no verified content-source facts to inventory. No factual entities, collection items, field values, descriptions, dates, contacts, links, or media references from the target site can be preserved, and none are invented here. The wrapper's obligation toward that content is structural only: load the URL, render it faithfully, and never substitute fabricated content for it.

2c. Page Content and Component Coverage

Landing

Information and state

• Product identity line: the wrapper's purpose — the existing site, wrapped as an app.
• Target URL, displayed as a monospace chip reading infranite-ai.lovable.app.
• Build specification block: target URL, wrapper version v1.0.0, minSdk 24, permissions list, artifact SHA-256.
• Live WebView frame state: either the actual site rendering, or the honest fallback state "preview unavailable — the app loads this URL".
• Primary action state: Download APK available.

Primary actions

• Download APK — the primary action, presented as a signal-orange rectangular block cut into the bottom edge of the dark build-spec panel, with a for testing micro-label above it. Navigates to the Download surface / initiates the artifact download.
• Open in browser — opens the target URL in the device's external browser.
• Reload — reloads the WebView frame.
• Back — navigates the WebView frame back in its history.

Supporting actions

• Drag the vertical seam handle to shift the split ratio between the WebView half and the build-spec half.
• Scroll the WebView frame independently of the page.

Domain entities

• Wrapper build (version, minSdk, permissions, SHA-256).
• Target URL.
• WebView frame (live content or unavailable state).

Component responsibilities

• Split hero — a full-viewport two-half layout divided by a 1px ink seam with a draggable orange square handle at its midpoint. Left half: oversized headline and the live WebView frame. Right half: dark monospace build-spec panel with the Download APK block.
• WebView frame — browser-chrome-like top bar containing the URL chip, reload, back, and external-open controls; the frame body renders the target site or the honest unavailable state.
• Build-spec panel — monospace ruled label/value rows for target URL, wrapper version, minSdk, permissions, and SHA-256.
• Wrapper architecture diagram — 1px line art (Android shell → WebView → target URL) with orange accent nodes, used as the section divider between Download and Permissions.
• Visible 12-column grid — 1px column rules running the full page height behind content; section header hairlines extend to the viewport edge.

States

• Loading: the WebView frame shows a loading indication while the target URL resolves; the URL chip shows a subtle typing caret.
• Empty: not applicable — the surface always has build facts to display.
• Success: the target site renders inside the frame; the Download APK action is available.
• Error / recovery: if the target site cannot be rendered, the frame shows the honest "preview unavailable — the app loads this URL" state rather than a fake screenshot; the build facts and the Download APK action remain fully available, so the tester can still proceed.

Download

Information and state

• Artifact card: version, size, build date, SHA-256 checksum, presented in tabular monospace with ruled label/value rows.
• Install steps: numbered ruled rows, styled as a square-cornered terminal block with a 3px orange left rule.
• Permissions / what-it-does-not-do table.
• Changelog strip.
• Download availability state.

Primary actions

• Download APK — retrieves the built artifact for installation and testing.

Supporting actions

• Copy the SHA-256 checksum for verification.
• Read install steps and permissions in place.

Domain entities

• APK artifact (version, size, build date, SHA-256).
• Install steps.
• Permissions and explicit non-behaviors.
• Changelog entries.

Component responsibilities

• Artifact card — ruled monospace label/value rows for version, size, build date, and checksum, with the orange Download APK button.
• Install steps block — numbered ruled rows in a square-cornered terminal panel with a 3px orange left rule.
• Permissions table — what the app does and explicitly does not do.
• Changelog strip — build history entries.
• Visible 12-column grid — same column-rule system as Landing, with flush-left section headers and hairlines running to the viewport edge.

States

• Loading: artifact metadata resolves before the download action is enabled.
• Empty: not applicable — the artifact card always carries the current build's facts.
• Success: the APK downloads; the tester can verify the checksum against the displayed SHA-256.
• Error / recovery: if the artifact is unavailable, the surface states that plainly and keeps the build facts, checksum, and install steps visible so the tester can retry or report the exact build identity.

3. Functional Requirements

FR-1 — Wrap the existing website in an Android WebView APK (explicit) As an App Tester / Downloader, I should have an Android APK that wraps the existing website https://infranite-ai.lovable.app in a WebView, so that I can run the site as an app on a device.

• Trigger/input: the built APK is installed and launched on an Android device.
• Observable result: the app opens and its WebView loads https://infranite-ai.lovable.app.
• Access state: no identity required.
• Failure/recovery: if the target URL cannot be reached, the app surfaces the failure rather than a blank or fabricated screen, and the tester can retry.
• Continuation: the tester interacts with the site inside the shell.
• Provenance: explicit.

FR-2 — The APK must be downloadable for testing (explicit) As an App Tester / Downloader, I should be able to download the APK, so that I can install it on a device and test it.

• Trigger/input: the tester selects the Download APK action.
• Observable result: the APK artifact is retrieved to the tester's device.
• Access state: anonymous; no identity required.
• Failure/recovery: if the artifact is unavailable, the surface states this plainly and keeps the build identity (version, size, date, SHA-256) visible so the tester can retry or report the exact build.
• Continuation: the tester installs the downloaded artifact.
• Provenance: explicit.

FR-3 — The wrapped content is the existing site; the site is not rebuilt (explicit) As an App Tester / Downloader, I should see the real https://infranite-ai.lovable.app inside the wrapper, so that what I test is the actual site and not a reimplementation.

• Trigger/input: the WebView loads the target URL.
• Observable result: the site's own content and behavior render inside the shell, unmodified.
• Access state: no identity required.
• Failure/recovery: if the site cannot render, the wrapper shows an honest unavailable state instead of a fake screenshot or substitute content.
• Continuation: the tester continues using the site inside the shell.
• Provenance: explicit.

FR-4 — The Android APK must be built and made available for download (required_inference) As an App Tester / Downloader, I should have a built, versioned APK artifact available, so that the download action has something real to deliver.

• Trigger/input: the build produces the wrapper APK.
• Observable result: a versioned artifact exists with a recorded size, build date, and SHA-256 checksum.
• Access state: anonymous.
• Failure/recovery: if the build fails, no artifact is published and the Download surface reports unavailability rather than serving a stale or broken file.
• Continuation: the artifact is served from the Download surface.
• Provenance: required_inference — required to make the accepted download journey executable; introduces no new product capability.

FR-5 — The APK must load the target URL in its WebView (required_inference) As an App Tester / Downloader, I should have the wrapper's WebView pointed at https://infranite-ai.lovable.app, so that launching the app lands me on the site.

• Trigger/input: app launch.
• Observable result: the WebView navigates to https://infranite-ai.lovable.app and renders it.
• Access state: no identity required.
• Failure/recovery: navigation failure is surfaced to the tester with a retry path.
• Continuation: the tester browses the site inside the shell.
• Provenance: required_inference — required to make the accepted wrapping journey executable; introduces no new product capability.

FR-6 — Present the build facts honestly on the Landing surface (required_inference) As an App Tester / Downloader, I should see the target URL, wrapper version, minSdk, permissions, and artifact SHA-256 before downloading, so that I know exactly what I am installing.

• Trigger/input: opening the Landing surface.
• Observable result: the build-spec panel displays target URL, wrapper version v1.0.0, minSdk 24, permissions list, and SHA-256.
• Access state: anonymous.
• Failure/recovery: if the live site cannot be previewed, the frame shows the honest unavailable state while the build facts remain visible.
• Continuation: the tester proceeds to download.
• Provenance: required_inference — required to make the accepted download decision executable; introduces no new product capability.

FR-7 — Provide install steps and a permissions / what-it-does-not-do table (required_inference) As an App Tester / Downloader, I should have numbered install steps and a clear statement of what the app does and does not do, so that I can install it correctly and trust it.

• Trigger/input: opening the Download surface.
• Observable result: numbered install steps and the permissions table are displayed.
• Access state: anonymous.
• Failure/recovery: not applicable to static content; content remains readable if the artifact is unavailable.
• Continuation: the tester installs and runs the app.
• Provenance: required_inference — required to make the accepted install-and-test journey executable; introduces no new product capability.

4. User Personas

App Tester / Downloader

Product context. This is the sole active human actor for the project. They asked for an Android WebView wrapper of an existing website and for a downloadable build they can install and test. They are technical: they read build specifications, verify checksums, and judge the artifact by whether the real site loads correctly inside the shell.

Primary goal. Obtain a working, installable WebView wrapper of https://infranite-ai.lovable.app, install it on a device, and confirm that the wrapped site's pages work inside the app.

Distinct accepted responsibilities.

• Read the build facts (target URL, wrapper version, minSdk, permissions, SHA-256) and decide whether to download.
• Download the APK artifact.
• Verify the artifact against its published checksum.
• Install the APK on an Android device.
• Launch the app and confirm the WebView loads https://infranite-ai.lovable.app.
• Exercise the wrapped site's pages inside the shell to confirm it works.
• Report the exact build identity if something fails.

Relevant inputs and decisions.

• Inputs: target URL, wrapper version, minSdk, permissions list, artifact SHA-256, artifact size, build date, install steps.
• Decisions: whether the artifact is trustworthy enough to install; whether the wrapped site renders correctly; whether the build is acceptable or needs another pass.

Interactions with other accepted participants.

• With the Android WebView runtime: the tester launches the app and the runtime loads the target URL; the tester observes the result.
• With the target site (external, provider-owned): the tester interacts with the site's own content and behavior inside the shell. The wrapper neither mediates nor alters that content.

Observable success. The APK downloads, its checksum matches the published SHA-256, it installs on an Android device, and launching it renders https://infranite-ai.lovable.app inside the WebView with the site's own pages working.

What makes this role's work different. The tester is not a consumer of the wrapped site's product — they are validating the shell. Their attention is on the seam between shell and site: does the URL load, does the frame render, does the artifact match its checksum, does the app behave as the build spec claims. That is why the build facts, the checksum, and the honest unavailable state matter as much as the site itself.

5. Core User Flows

Flow 1 — Understand the wrapper and download the APK

1. The App Tester / Downloader opens the Landing surface. No identity is required.
2. The split hero renders: the left half shows the oversized headline and the live WebView frame pointed at https://infranite-ai.lovable.app; the right half shows the dark monospace build-spec panel.
3. The tester reads the build facts: target URL, wrapper version v1.0.0, minSdk 24, permissions list, and artifact SHA-256.
4. The tester optionally drags the vertical seam handle to widen the WebView half and scroll the live frame, confirming the site renders. If the site cannot be previewed, the frame shows the honest "preview unavailable — the app loads this URL" state and the tester proceeds on the build facts alone.
5. The tester selects Download APK — the signal-orange block cut into the bottom edge of the dark panel, under the for testing micro-label.
6. The Download surface opens with the artifact card: version, size, build date, and SHA-256 in ruled monospace rows.
7. The tester selects Download APK on the artifact card. The APK is retrieved to their device.
8. Failure/recovery: if the artifact is unavailable, the surface states this plainly and keeps the build identity and checksum visible so the tester can retry or report the exact build.
9. Continuation: the tester proceeds to install.

Flow 2 — Verify and install the artifact

1. The App Tester / Downloader has the downloaded APK and the published SHA-256 from the Download surface.
2. The tester copies the checksum and verifies the downloaded file against it.
3. The tester reads the numbered Install steps in the square-cornered terminal block with the 3px orange left rule.
4. The tester reads the permissions / what-it-does-not-do table to confirm what the app does and does not do.
5. The tester installs the APK on an Android device following the numbered steps.
6. Failure/recovery: if installation is blocked or the checksum does not match, the tester returns to the Download surface, re-reads the build identity, and reports the exact version and checksum.
7. Continuation: the tester launches the installed app.

Flow 3 — Confirm the wrapped site loads and works inside the shell

1. The App Tester / Downloader launches the installed windy-infranite app on the Android device.
2. The Android WebView runtime navigates its WebView to https://infranite-ai.lovable.app and renders it.
3. The tester observes the site's own content appear inside the shell — unmodified, since the wrapper does not restyle or replace it.
4. The tester exercises the wrapped site's pages inside the app, using the shell's back, reload, and external-open controls as needed.
5. Failure/recovery: if the target URL cannot be reached or the site fails to render, the app surfaces the failure rather than a blank or fabricated screen, and the tester retries. If the failure persists, the tester reports it against the build identity recorded in Flow 2.
6. Continuation: the tester continues testing the wrapped site's pages, or returns to the Landing surface to check for a newer build.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. Muse: Adham Dannaway — "two halves in dialogue." Headline idea: the site on one half, the shell on the other.

Color tokens — light mode

White text on the #0B0E13 code panel must stay at or above 7:1 contrast. Proportion: roughly 70% paper/white, 20% dark panels, 10% orange — orange never fills a large area.

Typography

• Headings: Space Grotesk, 600–700, tight tracking (−0.02em to −0.04em). Sentence case for display lines; uppercase micro-labels at 11–12px with +0.14em tracking.
• Body: Instrument Sans, 400/500, 1.55 line-height, max measure 62ch.
• Monospace voice: Space Mono, 13–15px, for URL, version, hashes, and install commands.
• Scale: 1.25 modular — 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49 / 61 / 76 / 96 / 120px. Display: clamp(3rem, 8vw, 7.5rem).

Shape language. Precise and near-square: 4px and 8px radii only (buttons 8px, chips 4px, panels 8px). 1px hairline borders in a 12% ink tint. No soft blobs; no pill buttons except the small status chip. The signature shape is the vertical seam: a 1px ink rule down the centre of the hero with a small orange square handle at its midpoint that the cursor can drag to shift the split ratio. Code blocks use a square-cornered inset panel with a 3px orange left rule.

Layout. A true split-screen hero: left half is the "design" side — the wrapped site presented as a live, scrollable WebView frame with a browser-chrome-like top bar (URL chip, reload, back, external-open); right half is the "code" side — a dark monospace panel with the build spec. Below the hero, a 12-column grid with a visible 1px column rule system (the grid is shown, not hidden) holds the Download section, install instructions as numbered ruled rows, the permissions/what-it-does-not-do table, and a changelog strip. Everything aligns to an 8-pt baseline and to the visible columns; section headers sit flush-left with a hairline that runs to the viewport edge.

Imagery. No stock photography and no illustration for its own sake. The imagery is the interface itself: a live WebView frame of https://infranite-ai.lovable.app on the left, monospace code and spec tables on the right, a schematic diagram of the wrapper architecture (Android shell → WebView → target site) drawn as 1px line art with orange accent nodes, and small pixel-precise UI details (URL chip, reload glyph, checksum block). If the live site cannot render at build time, the frame shows an honest "preview unavailable — the app loads this URL" state rather than a fake screenshot.

Avoid. Any blue/indigo primary or accent (#0057FF, #2563EB, #4F46E5, #6366F1, #7C3AED) on white; a centred SaaS hero with headline + subtext + button, or any gradient-blob background; a grid of identical hover-lift cards; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui as heading or body faces; fake or stock screenshots of the wrapped site; rebuilding or restyling the wrapped site's own content; soft pill buttons, 24px+ radii, glassmorphism or frosted panels; playful bounce easing, confetti, or motion that delays the Download action.

7. Signature Design Concept

The seam is the product. The public entry is a full-viewport split hero divided by a single 1px ink rule with a draggable orange square handle at its midpoint. The left half is the site — an oversized two-line Space Grotesk 600 headline, "The site you already have, wrapped as an app.", set flush-left and allowed to run under the left edge of a live, scrollable WebView frame whose browser-chrome top bar carries a #FF4A1C URL chip reading infranite-ai.lovable.app. The right half is the shell — a dark #0B0E13 monospace panel listing target URL, wrapper v1.0.0, minSdk 24, permissions, and SHA-256, with the primary Download APK action physically cut into its bottom edge as a signal-orange block under an 11px uppercase for testing label, so the primary action reads as a terminal command rather than a floating SaaS CTA.

Dragging the handle resizes the WebView against the spec panel. That single interaction is the whole thesis: the hero does not describe the product's dual nature, it demonstrates it. The tester can widen the site to confirm it is real, or widen the spec to read the build facts before committing to the download.

Below the hero, the visible 12-column grid carries the Download section, install steps as numbered ruled rows in a square-cornered terminal block with a 3px orange left rule, the permissions/what-it-does-not-do table, and the changelog strip — with the 1px line-art wrapper architecture diagram (Android shell → WebView → target URL, orange nodes) as the divider between Download and Permissions.

The concept recomposes only accepted content, states, and controls: the target URL, the build facts, the live-or-unavailable WebView frame, and the Download APK action. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject. The vertical seam and the two halves it divides: the live WebView frame of https://infranite-ai.lovable.app on the paper side,