System Requirements Document for bronze-wise

1. Introduction

bronze-wise is a focused, no-sign-in web utility that changes only the numerals in an image: Arabic numerals (٠١٢٣\xd9\xa4\xd9\xa5\xd9\xa6\xd9\xa7\xd9\xa8\xd9\xa9 / 0–9) are converted to Hindi (Eastern Arabic-Indic) numerals (०१२३४५६७८९) in place, leaving every other pixel of the image untouched. The user uploads an image that contains Arabic numerals, the product detects those numerals, converts them, and presents the converted result image.

The audience is designers, publishers, and cultural producers who need Arabic digits swapped to Eastern Arabic-Indic numerals in place, with zero sign-in and no loss of the original image. The product is a precise instrument: exacting, elegant, quietly futuristic — a luxury object rather than a generic web tool.

The single accepted active human is the Image Owner, who supplies the image, reviews the detected numerals and the converted result, and confirms the in-place change. No sign-in is required to use any planned page.

2. System Overview

bronze-wise is delivered as a small first-party web application with five anonymous, no-sign-in pages that carry the Image Owner through one continuous lifecycle:

1. Landing — the anonymous first impression that explains bronze-wise and its image numeral conversion purpose.
2. Upload — the Image Owner supplies an image containing Arabic numerals.
3. Detection — the product detects and lets the Image Owner review the Arabic numerals present in the uploaded image.
4. Conversion — the product converts only the detected Arabic numerals to Hindi numerals in place.
5. Result — the product presents the converted result image to the Image Owner.

Actors:

• Image Owner (active human, required inference) — uploads the image, reviews detection, triggers conversion, reviews and confirms the result.
• Numeral conversion service (system process) — performs detection and in-place conversion of numerals on the image; the actual AI reading and writing on the image runs after the build phase.

Ownership and boundaries:

• All five pages are first-party, application-owned, and reachable with no sign-in.
• The actual image numeral conversion (AI reading and writing on the image) runs after the build phase; planning prepares only the pages and the workflow.
• Only the numerals change. Nothing else in the image is altered.

2a. Product Interpretation and Delivery Boundary

bronze-wise is a single-purpose transformation tool. Its entire promise is in-place change: the Arabic numerals in an image become Hindi numerals in their original positions, and the rest of the image — layout, colours, typography, artwork, everything that is not a numeral — is preserved exactly.

Delivery is anonymous and first-party. There is no account, no sign-in, no profile, and no saved history: the Image Owner arrives at the Landing page, moves through Upload, Detection, Conversion, and Result within one session, and leaves with the converted image. Because no durable actor-specific state, entitlement, or value transfer must remain bound to a returning participant, no identity establishment or verification lifecycle is introduced.

The current delivery horizon covers the pages and the workflow. The actual image numeral conversion — the AI reading and writing on the image — is explicitly scheduled to run after the build phase, not during planning. This is a delivery-horizon boundary, not a prohibition on the capability: the conversion is an accepted current requirement whose execution begins after the build.

2c. Page Content and Component Coverage

Landing

• Information / state: Product name bronze-wise; the product's purpose — converting Arabic numerals in an image to Hindi (Eastern Arabic-Indic) numerals in place, changing only the numerals; the no-sign-in nature of the tool.
• Primary action: Enter the conversion flow (proceed to Upload).
• Supporting actions: Scroll through the hero and the numeral mapping reference.
• Domain entities: Numeral pair (Arabic numeral, Hindi numeral); the product's stated promise of in-place, numerals-only change.
• Component responsibilities:
  • Hero canvas: full-bleed dark charcoal ground with a single sculptural 3D numeral form floating in the right two-thirds, morphing from Arabic to Hindi numerals, rotating slowly.
  • Headline block: flush-left headline set in Jost 200 weight, overlapping the edge of the 3D form.
  • Primary CTA: single gold CTA with a hairline pearl border.
  • Numeral mapping table: a strict, hairline-ruled grid inside a curved panel, each Arabic numeral and its Hindi counterpart set in the same weight and size, with the active pair highlighted by a soft gold pulse.
  • Curved section transitions: sweeping parabolic arcs or diagonals between sections.
• States:
  • Loading: hero 3D subject initialises; the headline and CTA render immediately and remain readable.
  • Empty: not applicable — the Landing page has no user data.
  • Success: the Image Owner understands the purpose and enters the flow.
  • Error / recovery: if the 3D subject cannot initialise, the hero falls back to a static 3D render with a manual toggle to view the numeral morph; the headline, CTA, and mapping table remain fully usable.
  • Reduced motion: the hero becomes a static 3D render with a manual toggle to view the numeral morph.

Upload

• Information / state: Instruction to supply an image containing Arabic numerals; the accepted image file; the reminder that only numerals will be changed.
• Primary action: Upload an image containing Arabic numerals.
• Supporting actions: Replace the selected image before proceeding; review the selected image on the stage.
• Domain entities: Uploaded image (the Image Owner's source image containing Arabic numerals).
• Component responsibilities:
  • Curved image stage (left, ~60%): presents the selected image on a curved, luminous stage.
  • Control column (right, ~40%): upload control, file state, and the action to proceed to detection, separated by hairline rules with generous negative space.
• States:
  • Loading: upload in progress, with the stage showing progress.
  • Empty: no image selected — the stage invites the Image Owner to supply an image containing Arabic numerals.
  • Success: the image is accepted and shown on the stage; the Image Owner can proceed to Detection.
  • Error / recovery: an unsupported or unreadable file is reported in the control column and the Image Owner can select another image; the previous selection is not lost until a new one is accepted.
  • Continuation: proceed to Detection.

Detection

• Information / state: The uploaded image with the Arabic numerals the product has detected; the set of detected numerals; the reminder that only these numerals will be changed.
• Primary action: Review the detected Arabic numerals and proceed to conversion.
• Supporting actions: Inspect each detected numeral on the image; return to Upload to replace the image.
• Domain entities: Detected numeral occurrence (position on the image, Arabic numeral value, corresponding Hindi numeral).
• Component responsibilities:
  • Curved image stage (left, ~60%): the uploaded image with a slow luminous gold scan line sweeping across it; each detected numeral marked with a curved bracket that draws itself in.
  • Control column (right, ~40%): the list of detected numerals and the action to proceed to Conversion.
• States:
  • Loading: the scan sweep runs while detection proceeds.
  • Empty: no Arabic numerals detected — the Image Owner is told nothing was found and can return to Upload with a different image.
  • Success: detected numerals are marked on the image and listed; the Image Owner can proceed to Conversion.
  • Error / recovery: if detection fails, the Image Owner is told and can retry detection or return to Upload; the uploaded image is preserved.
  • Continuation: proceed to Conversion.

Conversion

• Information / state: The detected Arabic numerals and their Hindi counterparts; the in-place conversion in progress; the assurance that only the numerals are being changed.
• Primary action: Convert only the detected Arabic numerals to Hindi numerals in place.
• Supporting actions: Return to Detection to re-review the detected numerals.
• Domain entities: Numeral pair (Arabic numeral, Hindi numeral); the in-place conversion applied to the image.
• Component responsibilities:
  • Curved image stage (left, ~60%): the image during in-place conversion, with the active numeral state highlighted in bronze-gold.
  • Control column (right, ~40%): conversion status and the action to view the result.
• States:
  • Loading: conversion in progress, with the active numeral state highlighted.
  • Empty: not applicable — Conversion requires detected numerals from Detection.
  • Success: the in-place conversion completes and the Image Owner proceeds to Result.
  • Error / recovery: if conversion fails, the Image Owner is told and can retry conversion or return to Detection; the uploaded image and detected numerals are preserved.
  • Continuation: proceed to Result.

Result

• Information / state: The converted result image, in which the Arabic numerals have been replaced by Hindi numerals in their original positions and nothing else has been altered; the original image available for comparison.
• Primary action: Review and confirm the converted result image.
• Supporting actions: Toggle between the original and the converted image; start a new conversion with another image.
• Domain entities: Converted result image; original image; the before/after pair.
• Component responsibilities:
  • Curved image stage (left, ~60%): the converted image presented on a curved, luminous stage with a subtle parallax tilt on cursor move.
  • Control column (right, ~40%): the "قبل / بعد" toggle that crossfades between the original and converted image with a smooth curve wipe, and the action to start a new conversion.
• States:
  • Loading: the converted result image is being prepared for display.
  • Empty: not applicable — Result requires a completed conversion.
  • Success: the converted result image is presented and the Image Owner confirms the in-place change.
  • Error / recovery: if the result cannot be displayed, the Image Owner is told and can return to Conversion to retry; the converted result is not discarded.
  • Continuation: start a new conversion with another image, returning to Upload.

3. Functional Requirements

FR-1 — Product identity As the Image Owner, I should see the product named bronze-wise, so that I know which tool I am using.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — opening the product; observable result — the name bronze-wise is presented; access — none; failure/recovery — not applicable; continuation — proceed to the product's purpose and entry action.

FR-2 — Purpose of the product As the Image Owner, I should understand that bronze-wise converts Arabic numerals in an uploaded image to Hindi (Eastern Arabic-Indic) numerals in place, changing only the numerals, so that I know the tool does exactly what I need and nothing more.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — reading the Landing page; observable result — the purpose and the numerals-only constraint are stated; access — none; failure/recovery — not applicable; continuation — enter the conversion flow.

FR-3 — Upload an image containing Arabic numerals As the Image Owner, I should upload an image containing Arabic numerals, so that the product has the source image to work on.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — selecting an image file; input — an image containing Arabic numerals; observable result — the image is accepted and shown on the curved image stage; access — none; failure/recovery — an unsupported or unreadable file is reported and another image can be selected; continuation — proceed to Detection.

FR-4 — Detect the Arabic numerals in the uploaded image As the Image Owner, I should have the product detect the Arabic numerals present in the uploaded image, so that I can see exactly which numerals will be changed.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — the uploaded image; observable result — the detected Arabic numerals are marked on the image and listed; access — none; failure/recovery — if detection fails, the Image Owner is told and can retry detection or return to Upload with the image preserved; continuation — proceed to Conversion.

FR-5 — Review the detected numerals As the Image Owner, I should review the Arabic numerals detected in my image, so that I can confirm the product found the numerals I expect before anything is changed.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — completed detection; observable result — each detected numeral is marked on the image with a curved bracket and listed in the control column; access — none; failure/recovery — if no Arabic numerals are detected, the Image Owner is told and can return to Upload with a different image; continuation — proceed to Conversion.

FR-6 — Convert only the detected Arabic numerals to Hindi numerals in place As the Image Owner, I should have the product convert only the detected Arabic numerals to Hindi numerals in place, so that the numerals change and nothing else in the image is altered.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — the reviewed detected numerals; observable result — the detected Arabic numerals are replaced by Hindi numerals in their original positions, with the rest of the image untouched; access — none; failure/recovery — if conversion fails, the Image Owner is told and can retry conversion or return to Detection with the image and detected numerals preserved; continuation — proceed to Result.

FR-7 — Present the converted result image As the Image Owner, I should be presented with the converted result image, so that I can see the in-place change.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — completed conversion; observable result — the converted result image is presented on the curved, luminous stage; access — none; failure/recovery — if the result cannot be displayed, the Image Owner is told and can return to Conversion to retry without discarding the converted result; continuation — confirm the result or start a new conversion.

FR-8 — Compare the original and the converted image As the Image Owner, I should toggle between the original and the converted image, so that I can verify that only the numerals changed.

• Provenance: required_inference.
• Lifecycle: actor — Image Owner; trigger — the presented result; observable result — the "قبل / بعد" toggle crossfades between the original and converted image with a smooth curve wipe; access — none; failure/recovery — if the original cannot be shown, the converted result remains presented; continuation — confirm the result or start a new conversion.

FR-9 — Confirm the in-place change As the Image Owner, I should confirm the converted result image, so that the in-place change is accepted as the outcome of my work.

• Provenance: required_inference.
• Lifecycle: actor — Image Owner; trigger — reviewing the converted result; observable result — the converted result is confirmed as the outcome; access — none; failure/recovery — if the result is not acceptable, the Image Owner can return to Conversion or Detection; continuation — start a new conversion with another image.

FR-10 — Start a new conversion As the Image Owner, I should start a new conversion with another image, so that I can repeat the work without leaving the tool.

• Provenance: required_inference.
• Lifecycle: actor — Image Owner; trigger — a confirmed or reviewed result; observable result — the flow returns to Upload for a new image; access — none; failure/recovery — not applicable; continuation — upload another image containing Arabic numerals.

FR-11 — No sign-in required As the Image Owner, I should use every planned page without signing in, so that I can convert my image immediately.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — opening any planned page; observable result — the page is usable with no sign-in; access — none on all five pages; failure/recovery — not applicable; continuation — proceed with the conversion flow.

FR-12 — Conversion execution after the build phase As the Image Owner, I should have the actual image numeral conversion (AI reading and writing on the image) run after the build phase, so that the planning stage prepares only the pages and the workflow.

• Provenance: explicit.
• Lifecycle: actor — Image Owner; trigger — the built product; observable result — the actual image numeral conversion executes after the build phase; access — none; failure/recovery — not applicable; continuation — the conversion flow operates on the built product.

4. User Personas

Image Owner

• Product context: The Image Owner is the single active human in bronze-wise. They arrive with an image that contains Arabic numerals and a precise, narrow need: those numerals must become Hindi (Eastern Arabic-Indic) numerals in their original positions, and nothing else in the image may change. They are designers, publishers, or cultural producers working with Arabic-script material, and they treat the tool as a precise instrument rather than a general editor.
• Primary goal: A result image in which the Arabic numerals are replaced by Hindi numerals in place, with the rest of the image untouched.
• Distinct accepted responsibilities: Supplying the image containing Arabic numerals; reviewing the Arabic numerals the product detects; triggering the in-place conversion of only those numerals; reviewing the converted result image; confirming the in-place change; starting a new conversion with another image.
• Relevant inputs or decisions: The choice of image to upload; the judgement of whether the detected numerals are the ones expected; the decision to proceed to conversion; the judgement of whether the converted result preserves everything except the numerals; the decision to confirm or to retry.
• Interactions with other accepted participants: The Image Owner is the only active human. Their work is carried out against the product's numeral conversion service, which detects the Arabic numerals and performs the in-place conversion on the image. No other human participant is involved, and no sign-in or account is required.
• Observable success: A converted result image in which the Arabic numerals appear as Hindi numerals in their original positions and every other part of the image is unchanged, confirmed by the Image Owner.

5. Core User Flows

Flow 1 — Convert the Arabic numerals in an image to Hindi numerals in place

1. Starting context: The Image Owner has an image containing Arabic numerals and opens bronze-wise. No sign-in is required.
2. On the Landing page, the Image Owner reads the product name bronze-wise and its purpose: converting Arabic numerals in an image to Hindi (Eastern Arabic-Indic) numerals in place, changing only the numerals. The hero presents the sculptural 3D numeral form morphing from Arabic to Hindi numerals, and the numeral mapping table shows each Arabic numeral beside its Hindi counterpart.
3. The Image Owner activates the single gold CTA to enter the conversion flow and arrives at the Upload page.
4. On the Upload page, the Image Owner selects an image containing Arabic numerals. The image is accepted and shown on the curved image stage. (Failure/recovery: if the file is unsupported or unreadable, the control column reports it and the Image Owner selects another image.)
5. The Image Owner proceeds to the Detection page. A slow luminous gold scan line sweeps across the uploaded image while the product detects the Arabic numerals present in it.
6. Each detected Arabic numeral is marked on the image with a curved bracket that draws itself in, and the detected numerals are listed in the control column. The Image Owner reviews them. (Failure/recovery: if no Arabic numerals are detected, the Image Owner is told and can return to Upload with a different image; if detection fails, the Image Owner can retry detection or return to Upload with the image preserved.)
7. The Image Owner proceeds to the Conversion page. The product converts only the detected Arabic numerals to Hindi numerals in place, with the active numeral state highlighted in bronze-gold. (Failure/recovery: if conversion fails, the Image Owner is told and can retry conversion or return to Detection with the image and detected numerals preserved.)

8. The Image Owner arrives at the Result page, where the converted result image is presented on the curved, luminous stage with a subtle parallax tilt on cursor move.
9. The Image Owner uses the "قبل / بعد" toggle to crossfade between the original and the converted image with a smooth curve wipe, verifying that the Arabic numerals are now Hindi numerals in their original positions and that nothing else in the image has changed.
10. The Image Owner confirms the in-place change. Observable result: a converted result image in which the Arabic numerals appear as Hindi numerals in place and the rest of the image is untouched.
11. Continuation: The Image Owner starts a new conversion with another image, returning to the Upload page.

Flow 2 — Review and retry when the detected numerals are not as expected

1. Starting context: The Image Owner has uploaded an image and is on the Detection page.
2. The Image Owner reviews the detected Arabic numerals marked on the image and listed in the control column.
3. If the detected numerals are not the ones expected, the Image Owner returns to the Upload page and selects a different image, or retries detection on the same image.
4. The uploaded image is preserved until a new one is accepted, so no work is lost. Observable result: the Image Owner is back at a state where the correct image and its detected numerals can be reviewed.
5. Continuation: The Image Owner proceeds to Conversion once the detected numerals match expectations.

Flow 3 — Recover from a failed conversion

1. Starting context: The Image Owner has reviewed the detected numerals on the Detection page and proceeded to the Conversion page.
2. The in-place conversion of the detected Arabic numerals to Hindi numerals fails.
3. The Image Owner is told that the conversion failed and can retry the conversion or return to Detection.
4. The uploaded image and the detected numerals are preserved. Observable result: the Image Owner can retry without re-uploading or re-detecting.
5. Continuation: On a successful retry, the Image Owner proceeds to the Result page.

6. Visuals Colors and Theme

Muse and headline: Zaha Hadid — Fluid parametric precision for bronze-wise. The register is exacting, elegant, and quietly futuristic: a precise instrument that feels like a luxury object, not a generic web tool. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Mode: Dark mode.

Colour tokens (exact hex, by role):

Typography:

• Headings: Jost — wide modern geometric sans; light weights for display, medium for UI. Headlines set in 200–300 weight, tight leading, generous tracking at large sizes. Uppercase micro-labels in 500 weight with 0.2em tracking.
• Body: Jost.
• Numerals are the hero: Arabic and Hindi digits are set in the same weight as surrounding text to show the one-to-one mapping.
• Type scale: 1.25 modular — 128 / 96 / 72 / 48 / 32 / 24 / 18 / 16 / 14. Hero display clamp(64px, 12vw, 128px) mobile to desktop. Section headings 48–72px. Body 16–18px with 1.6 line-height. Micro-labels 12–14px uppercase.
• Forbidden for headings or body: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, system-ui.

Shape language: Sweeping continuous curves and parametric arcs. Section boundaries are not straight: they curve and flow into each other. Cards and panels use large, soft radii (24–40px) with one corner extended into a gentle parabolic sweep. Hairline luminous strokes trace the curves. No hard 90-degree corners except in the strict data grid of the numeral mapping table.

Layout: Asymmetric editorial grid with a 12-column base, but section transitions are diagonal or curved, not horizontal. The hero is a full-bleed dark canvas with a single sculptural 3D numeral form floating in the right two-thirds, and the headline set flush-left in the left third, overlapping the form's edge. The Upload, Detection, and Result pages use a split layout: a large curved image stage on the left (60%) and a narrow control column on the right (40%) with hairline rules and generous negative space. All controls stay within a 4/8-pt spacing rhythm.

Imagery: The hero features one crafted real-time 3D subject: a floating, sculptural numeral form that morphs from Arabic to Hindi numerals, rendered in matte bronze and pearl with a soft rim light. Supporting imagery is architectural: macro shots of engraved numerals, brushed metal textures, and the uploaded image presented on a curved, luminous stage. No stock people, no flat clip art, no gradient blobs.

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

7. Signature Design Concept

The morphing numeral, in place.

The public entry is a full-bleed dark charcoal #0B0C0E canvas. On the right two-thirds, a single large 3D numeral form — the Arabic '٣' morphing into the Hindi '३' — floats in space, rendered in matte bronze #C9A227 with pearl highlights, rotating slowly. On the left third, the headline 'حوّل الأرقام في مكانها' is set in Jost 200 weight at clamp(64px, 12vw, 128px), flush-left, overlapping the edge of the 3D form. Beneath the headline sits a single gold CTA 'ابدأ التحويل' with a hairline pearl border. There is no centred stack, no subtext paragraph, and no blue button. The 3D form is the dominant element, the type is the counterweight, and the composition is deliberately asymmetric and architectural.

The concept recomposes only accepted content and controls: the product's stated purpose, the single entry action into the conversion flow, and the numeral mapping reference. The morphing form makes the product's core promise — one numeral system becoming another, in place — visible before a single image is uploaded.

Signature moves carried through the product:

• A full-bleed, scroll-linked 3D numeral morph in the hero: the Arabic numeral '٣' continuously rotates and morphs into the Hindi numeral '३' as the user scrolls the first viewport, with the headline overlapping the form's edge.
• Curved section transitions: every major section boundary is a sweeping parabolic arc or diagonal, never a straight horizontal line, creating a continuous architectural flow down the page.
• The numeral mapping table is a strict, hairline-ruled grid inside a curved panel: each Arabic numeral and its Hindi counterpart are set in the same weight and size, with the active pair highlighted by a soft gold pulse.
• On the Detection page, a slow luminous gold scan line sweeps across the uploaded image, and each detected numeral is marked with a curved bracket that draws itself in, not a rectangular box.
• The Result page presents the converted image on a curved, luminous stage with a subtle parallax tilt on cursor move, and a 'قبل / بعد' toggle that crossfades between the original and converted image with a smooth curve wipe.

8. Interaction Model & Motion Direction

Interaction Model: Parallax Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject: A single crafted real-time 3D numeral form — the Arabic '٣' morphing into the Hindi '३' — floating in the right two-thirds of a full-bleed dark charcoal canvas, rendered in matte bronze #C9A227 with pearl highlights and a soft rim light.
• Input → transformation → outcome thesis: As the Image Owner scrolls the first viewport, the Arabic numeral '٣' continuously rotates and morphs into the Hindi numeral '३'; the headline 'حوّل الأرقام في مكانها' overlaps the form's edge throughout. The outcome is that the product's core promise — one numeral system becoming another, in place — is visible before a single image is uploaded.
• Motion vocabulary: One continuous slow orbit of the hero 3D numeral form; scroll-linked morph from Arabic to Hindi numerals across the first viewport; smooth crossfades with a subtle curve wipe on page transitions. No bounce, no particles, no playful spring.
• Composed first frame: Full-bleed #0B0C0E ground. The 3D numeral form occupies the right two-thirds, mid-orbit, reading as the Arabic '٣'. The headline is flush-left in the left third, overlapping the form's edge, with the single gold CTA 'ابدأ التحويل' and its hairline pearl border beneath it. The numeral mapping table sits below the fold.
• Reduced-motion state: The hero becomes a static 3D render of the numeral form with a manual toggle to view the numeral morph; the headline, CTA, and mapping table remain fully readable and usable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

• Object: One sculptural numeral form that morphs from the Arabic '٣' to the Hindi '३', rendered in matte bronze #C9A227 with pearl #F5F3EF highlights and a soft rim light.
• Scene: A dark charcoal #0B0C0E void with no environment clutter; the form floats in the right two-thirds of the viewport, lit from a soft rim so its parametric curves catch a luminous edge.
• Behaviour: A continuous slow orbit, with the Arabic-to-Hindi morph driven by scroll position across the first viewport. The morph is the product's defining state made visible: one numeral system becoming another, in place.
• Fallback: If WebGL is unavailable, or when prefers-reduced-motion is set, the hero renders a static 3D image of the form with a manual toggle to view the numeral morph.

9. Non-Functional Requirements

• NFR-1 — No sign-in: No sign-in is needed to use the planned pages. Every page is reachable and usable anonymously. (Provenance: explicit.)
• NFR-2 — Numerals-only change: Only the numerals are to be changed: Arabic numerals converted to Hindi numerals in place; nothing else in the image is altered. (Provenance: explicit.)
• NFR-3 — Post-build conversion execution: The actual image numeral conversion (AI reading and writing on the image) works after the build phase; during planning only the plan/pages are prepared. (Provenance: explicit.)
• NFR-4 — Readable text and controls: Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. (Provenance: explicit creative direction.)
• NFR-5 — Reduced motion: All motion respects prefers-reduced-motion: the hero becomes a static 3D render with a manual toggle to view the numeral morph, and moving or scrollable content provides a usable static arrangement. (Provenance: explicit creative direction.)
• NFR-6 — Image fidelity: The converted result image preserves the original image's layout, colours, typography, and artwork exactly, with only the detected Arabic numerals replaced by Hindi numerals in their original positions. (Provenance: required_inference — the explicit numerals-only constraint made observable.)

10. Tech Stack

• Frontend: React — the five anonymous pages (Landing, Upload, Detection, Conversion, Result) with the asymmetric editorial layout, curved section transitions, and the split image-stage/control-column layout.
• 3D hero: WebGL / React Three Fiber — the crafted real-time 3D numeral form that morphs from Arabic to Hindi numerals, with a static-render fallback for reduced motion and unavailable WebGL.
• Backend: Python / FastAPI — the numeral conversion service exposing the image conversion operation: accepts an image file and returns the image with Arabic numerals replaced by Hindi numerals.
• Storage: No durable storage is required — no sign-in, no saved history, and no account state; the uploaded image and converted result live within the session.
• Containerisation: Docker / docker-compose — the frontend and the FastAPI backend as the runnable services.

11. Assumptions and Constraints

Constraints (binding):

• Only the numerals are to be changed: Arabic numerals converted to Hindi numerals in place; nothing else in the image is altered.
• No sign-in is needed to use the planned pages.
• The actual image numeral conversion (AI reading and writing on the image) works after the build phase; during planning only the plan/pages are prepared.
• The generic indigo/blue-on-white SaaS template is forbidden for this project.
• Headings and body must not use Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui.

Assumptions (narrow, labeled):

• [Assumption] The Image Owner supplies an image containing Arabic numerals; the product does not create or source images.
• [Assumption] The conversion operates on the numerals the product detects in the uploaded image; the Image Owner reviews those detected numerals before conversion.
• [Assumption] The uploaded image and the converted result are held for the duration of the session only; no durable history is retained, consistent with the no-sign-in constraint.
• [Assumption] The numeral conversion service is a first-party backend capability of bronze-wise; the actual AI reading and writing on the image begins after the build phase.

12. Glossary

• Arabic numerals: The Western Arabic digits 0–9 and their Arabic-script forms ٠١٢٣\xd9\xa4\xd9\xa5\xd9\xa6\xd9\xa7\xd9\xa8\xd9\xa9 — the numerals present in the uploaded image before conversion.
• Hindi numerals: The Eastern Arabic-Indic digits ०१२३४५६७८९ — the numerals that replace the Arabic numerals in place.
• In place: The converted numerals occupy the original numerals' positions in the image; the surrounding image is not otherwise altered.
• Image Owner: The single accepted active human who uploads an image containing Arabic numerals, reviews the detected numerals and the converted result, and confirms the in-place change.
• Detection: The product's identification of the Arabic numerals present in the uploaded image, presented for the Image Owner's review.
• Conversion: The product's replacement of only the detected Arabic numerals with Hindi numerals in place.
• Converted result image: The image produced by the conversion, in which the Arabic numerals appear as Hindi numerals in their original positions and nothing else has changed.
• Numeral mapping table: The strict, hairline-ruled grid on the Landing page showing each Arabic numeral beside its Hindi counterpart.
• "قبل / بعد": The Result page toggle that crossfades between the original and the converted image.