System Requirements Document for photo-editor-adobephotoshop

1. Introduction

photo-editor-adobephotoshop is an Android mobile photo editor built for people who already speak Photoshop's vocabulary — layers, masks, blend modes, curves, healing — and want that editing model on a phone, one-handed, in a dark room or outdoors with the screen turned up.

The product intent is derived directly from the authoritative requirement thread:

• Build an Android mobile photo editor application similar to Adobe Photoshop for Android.
• The app is themed/styled after the Adobe Photoshop mobile Android app.
• Editing is performed on photos within the app on an Android device.

The audience is a self-directed creative working on their own photographs. They import an image, apply and adjust edits, and export or save the finished result. The emotional register is control and precision, not play: the interface must disappear into the image, and the image must be the brightest thing on screen.

Adobe Photoshop for Android is used only as a reference for theme and editing experience — it is an inspiration-only reference, not an authoritative specification. No Photoshop feature, asset, brand copy, or proprietary capability is reproduced; only the general editing vocabulary and dark-UI register are carried.

2. System Overview

photo-editor-adobephotoshop is a single Android mobile application with two first-party destinations:

• Landing — the anonymous public entry surface that introduces the editor's Photoshop-like editing purpose before the user enters the editing workflow.
• Photo Editor — the cohesive Android editing workspace where the user opens a photo, applies and adjusts edits, and saves or exports the finished result.

Both destinations are application-owned custom pages with no access requirement: the user is not asked to create an account, sign in, or establish any identity. There is no application-owned identity, no session continuity requirement, and no differentiated permissions or role-based visibility anywhere in the product. The single active human role is Photo Editor.

The editing model is a layered, numeric, power-user model: a document with a layer stack, per-layer blend mode and opacity, a tool rail of editing tools (Crop, Adjust, Mask, Layers, Blend, Heal, Text, Filter), and a contextual parameter sheet whose every numeric value is rendered in tabular monospace so digits do not jitter while a slider is dragged. Undo and redo step the document. The finished result is saved or exported from the same workspace.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is delivered as an Android mobile application. All editing work — opening a photo, applying and adjusting edits, managing layers, and saving or exporting — happens inside the app on the Android device. There is no server-side editing service, no cloud rendering, and no provider-owned editing surface in the current scope. The app is the sole owner of the editing lifecycle.

Access ownership. Access is anonymous and local. The Landing page is reachable without any identity, and the Photo Editor is reachable without any identity. The user's photos are read from and written to the device; the app does not require an account to open, edit, or export a photo. No account creation, sign-in, invitation, provisioning, or deployment bootstrap is part of the current product.

Current boundary. Current scope is exactly: an Android photo editor with a Landing entry surface and a Photo Editor workspace, themed after the Adobe Photoshop mobile Android app, editing photos on the device, with a layered editing model and save/export of the finished result.

Future boundary. Nothing in the authoritative requirement thread establishes a future horizon. No cloud sync, collaboration, account system, social sharing, AI generation, or cross-platform client is accepted or planned. Any such capability would be a new product decision, not an extension of this document.

2b. Source Content Inventory

Not applicable. No reference directive in the planning scope declares content_source; the single reference directive (Adobe Photoshop for Android mobile app) declares only feature_reference and visual_inspiration with inspiration_only authority, and therefore supplies no factual content, entities, collections, or media references to inventory.

2c. Page Content and Component Coverage

Landing

Information and state. The Landing page is the anonymous first impression. It presents the product's identity and its Photoshop-like editing purpose, then hands the user into the editing workflow. It holds no user state, no document state, and no persisted data.

• Command bar (48px). Left: the product wordmark. Right: a single entry action into the editor. A 1px hairline rule sits beneath the bar.
• Editorial hero column. Left-aligned, sitting on the graphite margin at the top-left. An 11px uppercase mono line reading PHOTO EDITOR · ANDROID with +0.08em tracking, above the headline "Edit like you mean it" set in Space Grotesk 40px mobile / 56px desktop, tight tracking (-0.02em), in #F2EFE9.
• Mono readout row. Three small readouts beneath the headline — EXPOSURE +0.35, CLARITY 22, MASK 3 — in muted grey #8C8880 with tangerine #FF6B2C values, set in JetBrains Mono tabular figures.
• Primary entry action. A single tangerine "Open a photo" button, 6px radius, pinned left. This is the only high-emphasis control on the page.
• Full-bleed hero photograph. One photograph bleeding past the right edge of the viewport, split vertically by a hairline tangerine divider with a circular drag handle at its midpoint. The left half is desaturated and lifted; the right half is the edited result. The photograph is the dominant element at roughly 60% of the screen area.
• Darkroom-safelight ambient. One soft tangerine radial glow at 8% opacity drifting slowly behind the photograph — the only decorative motion on the page.
• Schematic diagrams. Small schematic diagrams of the healing brush and mask edge, presented as interface imagery rather than stock illustration.

Primary actions. Open a photo (enter the editing workflow). Drag the before/after divider handle to compare the unedited and edited halves of the hero photograph.

Supporting actions. None beyond the entry action and the hero comparison gesture.

Domain entities. None. The Landing page reads no document, holds no layer stack, and persists nothing.

Component responsibilities. The command bar establishes product identity and the single entry point. The editorial column carries the headline and the mono readout row. The hero photograph carries the product's core value as a single draggable gesture rather than described in copy. The ambient glow supplies the only decorative motion.

States.

• Loading: the hero photograph loads progressively; the type column and entry button render immediately and are never blocked by image load.
• Empty: not applicable — the page has no user-owned collection.
• Success: the hero photograph is displayed, the divider handle is draggable, and the entry action is available.
• Error: if the hero photograph fails to load, the graphite ground, the type column, the mono readout row, and the entry action remain fully readable and usable; the image area degrades to the graphite ground rather than to a broken-image placeholder.
• Recovery: the user can still enter the editor through the entry action regardless of hero image load state.

Photo Editor

Information and state. The Photo Editor is the cohesive editing workspace. It holds the current document: the source photograph, the layer stack with per-layer name, thumbnail, blend mode, opacity, and visibility, the active tool, the active tool's parameter values, and the undo/redo history. It is a three-zone workspace on a strict 4/8pt scale.

• Command bar (48px). Document name, undo, and redo, with a 1px rule beneath. Undo and redo are disabled when the history has no further step in that direction.
• Canvas. Edge-to-edge, the photograph letterboxed on #141517 with a thin tangerine selection marquee. Supports pinch-zoom and two-finger pan. The canvas is the brightest thing on screen; the UI never introduces a second hue.
• Tool rail (72px). A horizontally scrolling row of icon + 11px-label chips: Crop, Adjust, Mask, Layers, Blend, Heal, Text, Filter. The active tool's chip flips to a tangerine 1px border and tangerine label.
• Contextual parameter sheet. Slides up from the bottom edge above the tool rail when a tool is chosen, in 160ms. Contains the active tool's controls. Every numeric parameter — exposure, opacity, hue, blur radius, crop ratio — is rendered in JetBrains Mono tabular figures inside a value bubble that rides the slider thumb.
• Slider. The signature shape: a 2px track with a 20px tangerine circular handle and a monospace value bubble riding above the thumb.
• Layer rows (44px). A 40px thumbnail, the layer name, a blend mode dropdown, opacity in monospace right-aligned, and a tangerine visibility eye. The selected row carries a 1px tangerine left-edge bar that grows from 0 to 3px instead of a background fill.
• Save / Export action. The single high-emphasis action, using primary #F4F1EA when it must compete with the accent.

Primary actions. Open a photo into the document; select a tool from the tool rail; adjust the active tool's parameters; add, select, reorder, rename, hide, and delete layers; set a layer's blend mode and opacity; undo and redo; save or export the finished result.

Supporting actions. Pinch-zoom and two-finger pan the canvas; toggle layer visibility; dismiss the parameter sheet by selecting another tool or closing it.

Domain entities.

• Document — the open photograph plus its layer stack and edit history.
• Layer — name, thumbnail, blend mode, opacity, visibility, and position in the stack.
• Tool — one of Crop, Adjust, Mask, Layers, Blend, Heal, Text, Filter, with its own parameter set.
• Parameter — a named numeric or enumerated value belonging to the active tool (exposure, opacity, hue, blur radius, crop ratio, and so on).
• History step — an undoable/redoable document state.

Component responsibilities. The command bar owns document identity and history traversal. The canvas owns the rendered document and the zoom/pan gesture surface. The tool rail owns tool selection. The parameter sheet owns the active tool's controls and their numeric readouts. The layer list owns the stack, per-layer mode and opacity, and visibility. The save/export action owns committing the finished result.

States.

• Loading: while a photo is being decoded into the document, the canvas shows the graphite ground with a progress indication; the command bar, tool rail, and layer list remain present but their document-dependent controls are disabled.
• Empty: no document is open. The canvas shows the graphite ground with a prompt to open a photo; the tool rail, parameter sheet, layer list, undo/redo, and save/export are unavailable until a document exists.
• Success: the document is open, edits render on the canvas in real time, the layer stack reflects the current state, and save/export completes with a confirmation that the result was written.
• Error: if the selected photo cannot be read or decoded, the editor reports the failure and returns to the empty state without discarding any previously open document. If save/export fails, the document remains open and unmodified on screen, the failure is reported, and the user can retry.
• Recovery: undo steps the document back through history with a 120ms crossfade; redo re-applies a stepped-back change. A failed save/export leaves the in-progress document intact so no edit is lost.

3. Functional Requirements

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

FR-1 — Android mobile photo editor application As a Photo Editor, I should use an Android mobile photo editor application so that I can edit my photos on my Android device.

• Provenance: explicit
• Lifecycle: initiated by the Photo Editor launching the app on an Android device; observable result is a running Android photo editor application; continuation is entry into the editing workflow.
• Acceptance: the product runs as an Android mobile application and all editing work is performed on the Android device.

FR-2 — Photoshop-like theme and editing experience As a Photo Editor, I should work in an interface themed and structured after the Adobe Photoshop mobile Android app so that the editing experience matches the vocabulary and register I already know.

• Provenance: explicit
• Lifecycle: applies to every screen of the product; observable result is a dark, tool-dense editing interface with a layer stack, a tool rail, and numeric parameter controls.
• Acceptance: the app's theme and editing experience resemble Adobe Photoshop for Android; the reference is used for theme and editing experience only and supplies no product names, copy, facts, or capabilities.
• Constraint: the target platform is Android mobile.

FR-3 — Open a photo into the editor As a Photo Editor, I should open a photo from my Android device into the editor so that I have a document to work on.

• Provenance: explicit (editing is performed on photos within the app on an Android device)
• Lifecycle: initiated by the Photo Editor from the Landing entry action or from the Photo Editor's empty state; input is a photo selected from the device; observable result is the photo rendered on the canvas as the current document; continuation is tool selection.
• Failure/recovery: if the photo cannot be read or decoded, the editor reports the failure and returns to the empty state without discarding any previously open document.
• Acceptance: a selected photo appears on the canvas and becomes the document being edited.

FR-4 — Layered document model As a Photo Editor, I should work with a layer stack so that I can build an edit in layers rather than destructively.

• Provenance: required_inference (indispensable to the accepted Photoshop-like editing model; the layer stack is the state that makes per-layer blend mode, opacity, and visibility meaningful)
• Lifecycle: initiated by the Photo Editor adding a layer; observable result is a new 44px layer row with a 40px thumbnail, name, blend mode, opacity, and visibility eye; continuation is selecting and editing that layer.
• Acceptance: the document holds an ordered layer stack; each layer carries a name, thumbnail, blend mode, opacity, and visibility; the selected layer is marked by a 1px tangerine left-edge bar growing to 3px.

FR-5 — Select and manage layers As a Photo Editor, I should select, reorder, rename, hide, and delete layers so that I can control what contributes to the result.

• Provenance: required_inference (indispensable mechanics of the accepted layer stack)
• Lifecycle: initiated by the Photo Editor acting on a layer row; observable result is the changed stack order, name, visibility, or membership; continuation is further editing.
• Acceptance: selecting a layer makes it the active layer; reordering changes stack order; renaming changes the layer name; the tangerine visibility eye toggles visibility in 90ms; deleting removes the layer from the stack.

FR-6 — Per-layer blend mode and opacity As a Photo Editor, I should set each layer's blend mode and opacity so that I can control how layers combine.

• Provenance: required_inference (indispensable to the accepted blend-mode and layer vocabulary)
• Lifecycle: initiated by the Photo Editor choosing a blend mode from the layer row dropdown or dragging the opacity control; observable result is the layer's mode or opacity value updating and the canvas re-rendering; continuation is further adjustment.
• Acceptance: the blend mode dropdown sets the layer's mode; opacity is displayed in monospace right-aligned on the layer row and updates the canvas in real time.

FR-7 — Tool rail and tool selection As a Photo Editor, I should choose an editing tool from the tool rail so that I can apply the edit I want.

• Provenance: required_inference (indispensable to the accepted Photoshop-like editing experience)
• Lifecycle: initiated by the Photo Editor tapping a tool chip in the 72px horizontally scrolling rail; observable result is the active chip flipping to a tangerine 1px border and tangerine label and the contextual parameter sheet sliding up in 160ms; continuation is parameter adjustment.
• Acceptance: the rail presents Crop, Adjust, Mask, Layers, Blend, Heal, Text, and Filter as icon + 11px-label chips; exactly one tool is active at a time.

FR-8 — Adjust tool parameters As a Photo Editor, I should adjust the active tool's parameters so that I can tune the edit precisely.

• Provenance: required_inference (indispensable to the accepted editing experience; the parameter sheet is the control surface for every tool)
• Lifecycle: initiated by the Photo Editor dragging a slider or changing a control in the parameter sheet; observable result is the canvas updating in real time with no easing on the pixels themselves, and the numeric value updating in a JetBrains Mono tabular value bubble riding the slider thumb; continuation is further adjustment or tool change.
• Acceptance: every numeric parameter — exposure, opacity, hue, blur radius, crop ratio — is rendered in tabular monospace so digits do not jitter while dragging; the slider is a 2px track with a 20px tangerine circular handle.

FR-9 — Crop As a Photo Editor, I should crop the photo so that I can change its framing and aspect ratio.

• Provenance: required_inference (indispensable to the accepted editing tool set)
• Lifecycle: initiated by the Photo Editor selecting Crop; observable result is a crop region on the canvas with a tangerine marquee and a crop ratio readout in monospace; continuation is confirming or cancelling the crop.
• Acceptance: the crop region is adjustable and the crop ratio is shown as a numeric parameter.

FR-10 — Mask As a Photo Editor, I should mask parts of a layer so that edits apply only where I want them.

• Provenance: required_inference (indispensable to the accepted mask vocabulary)
• Lifecycle: initiated by the Photo Editor selecting Mask; observable result is a mask applied to the active layer with a visible mask edge; continuation is refining the mask or returning to another tool.
• Acceptance: a mask can be applied to the active layer and its effect is visible on the canvas.

FR-11 — Heal As a Photo Editor, I should heal blemishes and unwanted detail so that I can clean up the photograph.

• Provenance: required_inference (indispensable to the accepted healing vocabulary)
• Lifecycle: initiated by the Photo Editor selecting Heal and applying it to a region of the canvas; observable result is the healed region rendering in place of the original detail; continuation is further healing or another tool.
• Acceptance: the healing brush removes the targeted detail and the result renders on the canvas.

FR-12 — Text As a Photo Editor, I should add text to the photo so that I can place type on the image.

• Provenance: required_inference (indispensable to the accepted text tool)
• Lifecycle: initiated by the Photo Editor selecting Text and placing a text element on the canvas; observable result is editable text rendered on the document; continuation is editing the text or its parameters.
• Acceptance: a text element can be added to the document and edited.

FR-13 — Filter As a Photo Editor, I should apply a filter so that I can change the look of the photo quickly.

• Provenance: required_inference (indispensable to the accepted filter tool)
• Lifecycle: initiated by the Photo Editor selecting Filter and choosing a filter; observable result is the filter applied to the document and rendered on the canvas; continuation is adjusting the filter's parameters or choosing another.
• Acceptance: a filter can be applied and its effect is visible on the canvas.

FR-14 — Canvas zoom and pan As a Photo Editor, I should pinch-zoom and two-finger pan the canvas so that I can work at the scale I need.

• Provenance: required_inference (indispensable to precise one-handed mobile editing on a phone-sized canvas)
• Lifecycle: initiated by the Photo Editor's pinch or two-finger drag on the canvas; observable result is the document zooming or panning under the gesture; continuation is editing at the new scale.
• Acceptance: pinch-zoom and two-finger pan both operate on the canvas without altering the document.

FR-15 — Undo and redo As a Photo Editor, I should undo and redo my edits so that I can step back and forward through my work.

• Provenance: required_inference (indispensable to a non-destructive layered editing model)
• Lifecycle: initiated by the Photo Editor tapping undo or redo in the command bar; observable result is the canvas stepping with a 120ms crossfade; continuation is further editing.
• Acceptance: undo reverses the last history step and redo re-applies a stepped-back change; each control is disabled when no step exists in that direction.

FR-16 — Save or export the finished result As a Photo Editor, I should save or export the finished result so that I have my edited photo.

• Provenance: explicit (the accepted outcome of editing photos within the app on an Android device)
• Lifecycle: initiated by the Photo Editor tapping the save/export action; observable result is the finished result written and a confirmation shown; continuation is returning to the document or starting another edit.
• Failure/recovery: if save/export fails, the document remains open and unmodified on screen, the failure is reported, and the user can retry without losing edits.
• Acceptance: the edited photo is written out and the user receives a confirmation of completion.

4. User Personas

Photo Editor

Product context. The Photo Editor is the single active human role in photo-editor-adobephotoshop. They are a self-directed creative working on their own photographs on an Android phone. They already know Photoshop's vocabulary — layers, masks, blend modes, curves, healing — and they expect a mobile editor to speak that language rather than simplify it away. They work one-handed, often in a dark room or outdoors with the screen turned up, and they want the interface to disappear into the image.

Primary goal. Take a photograph on their Android device, apply and adjust edits in a layered, numeric editing model, and save or export the finished result.

Distinct accepted responsibilities.

• Open a photo from the device into the editor as the current document.
• Choose an editing tool from the tool rail (Crop, Adjust, Mask, Layers, Blend, Heal, Text, Filter).
• Adjust the active tool's parameters precisely, reading numeric values that do not jitter while dragging.
• Build and manage a layer stack: add, select, reorder, rename, hide, and delete layers.
• Set each layer's blend mode and opacity.
• Zoom and pan the canvas to work at the scale the edit requires.
• Undo and redo edits to step through their work.
• Save or export the finished result.

Relevant inputs and decisions. Which photo to open; which tool to reach for; how far to push each numeric parameter; how to structure the layer stack; which blend mode and opacity each layer needs; when the edit is finished and should be exported. The Photo Editor's decisions are numeric and structural — the product's value is that those numbers are legible and honest.

Interactions with other accepted participants. None. The Photo Editor is the only active human role. There is no collaborator, reviewer, approver, client, or recipient in the accepted product. The only other actor in the system is the Android device's photo storage, which supplies the source photo and receives the exported result — a non-persona system actor, not a participant whose response the Photo Editor awaits.

Observable success. The edited photograph is written out from the app, and the Photo Editor has a finished result that reflects the layer stack, tool parameters, and adjustments they made.

What makes this role's work different. The Photo Editor is not a casual one-tap filter user and not a passive viewer. Their work is precision work: they read numbers, they build structure, and they expect the editor to behave like an instrument. The interface must stay out of the way while its numbers stay legible — that is the specific tension this role's work creates, and it is why the product's chrome is graphite and its only signal colour is a single tangerine.

5. Core User Flows

Flow 1 — Enter the editor and open a photo

1. The Photo Editor opens the app and lands on Landing.
2. Landing presents the full-bleed hero photograph split by a hairline tangerine divider with a circular drag handle; the left half is desaturated and lifted, the right half is the edited result.
3. The Photo Editor may drag the divider handle to compare the two halves — the product's core value shown as a single draggable gesture.
4. The Photo Editor taps the tangerine "Open a photo" button.
5. The Photo Editor page opens. With no document yet, the canvas shows the graphite ground with a prompt to open a photo; the tool rail, parameter sheet, layer list, undo/redo, and save/export are unavailable.
6. The Photo Editor selects a photo from the Android device.
7. While the photo decodes, the canvas shows the graphite ground with a progress indication; the command bar, tool rail, and layer list are present but their document-dependent controls are disabled.
8. The photo renders on the canvas as the current document, letterboxed on #141517. The tool rail, layer list, undo/redo, and save/export become available.
9. Failure/recovery: if the photo cannot be read or decoded, the editor reports the failure and returns to the empty state without discarding any previously open document.
10. Next step: the Photo Editor selects a tool.

Flow 2 — Apply and adjust an edit

1. Starting from the Photo Editor page with a document open, the Photo Editor taps a tool chip in the 72px tool rail — for example Adjust.
2. The active chip flips to a tangerine 1px border and tangerine label, and the contextual parameter sheet slides up from the bottom edge in 160ms.
3. The Photo Editor drags a slider in the parameter sheet. The slider is a 2px track with a 20px tangerine circular handle, and a JetBrains Mono tabular value bubble rides above the thumb.
4. The canvas updates in real time with no easing on the pixels themselves; the numeric value updates without digit jitter.
5. The Photo Editor continues adjusting until the edit reads correctly.
6. Next step: the Photo Editor selects another tool, manages layers, or exports.

Flow 3 — Crop the photograph

1. Starting from the Photo Editor page with a document open, the Photo Editor selects Crop from the tool rail.
2. A crop region appears on the canvas with a tangerine marquee, and the crop ratio is shown as a numeric parameter in the parameter sheet.
3. The Photo Editor adjusts the crop region and the ratio.
4. The Photo Editor confirms the crop; the canvas re-renders to the cropped framing.
5. Next step: the Photo Editor continues editing or exports.

Flow 4 — Mask a layer

1. Starting from the Photo Editor page with a document open, the Photo Editor selects Mask from the tool rail.
2. A mask is applied to the active layer and its edge is visible on the canvas.
3. The Photo Editor refines the mask until the edit applies only where intended.
4. Next step: the Photo Editor returns to another tool or continues refining.

Flow 5 — Heal unwanted detail

1. Starting from the Photo Editor page with a document open, the Photo Editor selects Heal from the tool rail.
2. The Photo Editor applies the healing brush to a region of the canvas containing unwanted detail.
3. The healed region renders in place of the original detail.
4. Next step: the Photo Editor continues healing or selects another tool.

Flow 6 — Add text to the photograph

1. Starting from the Photo Editor page with a document open, the Photo Editor selects Text from the tool rail.
2. The Photo Editor places a text element on the canvas.
3. The text renders on the document and is editable.
4. The Photo Editor edits the text and its parameters.
5. Next step: the Photo Editor continues editing or exports.

Flow 7 — Apply a filter

1. Starting from the Photo Editor page with a document open, the Photo Editor selects Filter from the tool rail.
2. The Photo Editor chooses a filter.
3. The filter is applied to the document and renders on the canvas.
4. The Photo Editor adjusts the filter's parameters or chooses another filter.
5. Next step: the Photo Editor continues editing or exports.

Flow 8 — Build and manage the layer stack

1. Starting from the Photo Editor page with a document open, the Photo Editor selects Layers from the tool rail.
2. The layer list shows the current stack as 44px rows, each with a 40px thumbnail, name, blend mode dropdown, monospace right-aligned opacity, and a tangerine visibility eye.
3. The Photo Editor adds a layer. A new row appears in the stack.
4. The Photo Editor selects a layer. The selected row's 1px tangerine left-edge bar grows to 3px.
5. The Photo Editor reorders, renames, hides, or deletes layers as needed. Toggling visibility takes 90ms.
6. Next step: the Photo Editor sets blend mode and opacity, or returns to another tool.

Flow 9 — Set blend mode and opacity

1. Starting from the Photo Editor page with a layer selected, the Photo Editor opens the blend mode dropdown on the layer row and chooses a mode.
2. The layer's mode updates and the canvas re-renders.
3. The Photo Editor drags the opacity control. The opacity value is displayed in monospace right-aligned on the layer row and the canvas updates in real time.
4. Next step: the Photo Editor continues adjusting or exports.

Flow 10 — Zoom and pan the canvas

1. Starting from the Photo Editor page with a document open, the Photo Editor pinches the canvas to zoom.
2. The document zooms under the gesture without altering the document.
3. The Photo Editor two-finger pans to move across the image.
4. Next step: the Photo Editor continues editing at the new scale.

Flow 11 — Undo and redo

1. Starting from the Photo Editor page with edits applied, the Photo Editor taps undo in the command bar.
2. The canvas steps back with a 120ms crossfade to the previous history step.
3. The Photo Editor taps redo to re-apply a stepped-back change.
4. Each control is disabled when no step exists in that direction.
5. Next step: the Photo Editor continues editing.

Flow 12 — Save or export the finished result

1. Starting from the Photo Editor page with the edit complete, the Photo Editor taps the save/export action.
2. The finished result is written out and a confirmation is shown.
3. Failure/recovery: if save/export fails, the document remains open and unmodified on screen, the failure is reported, and the Photo Editor can retry without losing edits.
4. Next step: the Photo Editor returns to the document or starts another edit.

6. Visuals Colors and Theme

The creative direction is authoritative for this section: Darkroom instrument craft — a graphite editor with a tangerine signal, after the muse Rasmus Andersson. The headline idea is that the interface disappears into the image and the image is the brightest thing on screen.

Palette (dark mode)

Graphite #141517 is the canvas surround and app background. #1C1E21 is every panel, sheet, and toolbar surface, separated by 1px #2A2C30 hairlines — never by shadow. Text is warm paper white #F2EFE9 for labels and values, muted #8C8880 for secondary metadata such as layer opacity, file size, and EXIF. Tangerine #FF6B2C is the only signal colour: active tool, selected layer row, slider handle, applied checkmark, primary "Export" button — roughly 4% of the screen, never a background fill larger than a chip. Primary #F4F1EA is used for the single high-emphasis action (Save/Export) only when it must compete with the accent. The photograph itself supplies every other colour; the UI never introduces a second hue.

Typography

• Headings: Space Grotesk, 500/600, tight tracking (-0.02em), sentence case for tool names and screen titles; uppercase only for 11px micro-labels with +0.08em tracking (LAYERS, ADJUST, MASK). Headlines are large and quiet, never shouty.
• Body: Inter Tight.
• Numeric readouts: JetBrains Mono with tabular figures for every numeric readout — exposure, opacity, hue, crop ratio, blur radius — so digits do not jitter while a slider is dragged.
• Scale: 1.25 modular, 4px baseline. Display 40/56px (mobile 40px, desktop 56px), screen title 24px, section label 11px uppercase +0.08em, body 15px, value/numeric 13px JetBrains Mono tabular, micro 11px. Line-height 1.35 for body, 1.05 for display.

Shape language

Compact, tool-like geometry: 6px radii on buttons and chips, 10px on bottom sheets and floating panels, 2px on sliders and progress tracks. Hairline 1px borders (#2A2C30) do all the separating work; no drop shadows except one soft 24px ambient under the floating tool shelf. Sliders are the signature shape: a 2px track with a 20px tangerine circular handle and a monospace value bubble that rides above the thumb. No pills, no blobs, no glass.

Layout

A three-zone editing workspace on a strict 4/8pt scale. Top: a 48px command bar with the document name, undo/redo, and a 1px rule beneath. Middle: the canvas — edge-to-edge, the photograph letterboxed on #141517 with a thin selection marquee in tangerine, pinch-zoom and two-finger pan. Bottom: a 72px tool rail of icon + 11px-label chips (Crop, Adjust, Mask, Layers, Blend, Heal, Text, Filter) that scrolls horizontally, above a contextual parameter sheet that slides up when a tool is chosen. Layer rows are 44px tall with a 40px thumbnail, name, mode dropdown, opacity in mono, and a tangerine visibility eye. The landing page reuses the same grid: a left-aligned editorial column of type against a single full-bleed photograph, not a centred marketing stack.

Imagery

The interface is the imagery: real screenshots of the canvas mid-edit, layer stacks, histogram curves, and a monospace-drawn histogram readout. On the landing page, one full-bleed photograph — a portrait or landscape with a visible before/after split down the middle by a 1px tangerine rule with a draggable handle — plus small schematic diagrams of the healing brush and mask edge. No stock people, no device mockups, no clip art.

Avoid

Blue or indigo accents anywhere — no #2563EB, #3B82F6, #6366F1, no "Photoshop blue" toolbar. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body. Gradient-blob heroes, glassmorphism panels, frosted cards, drop-shadowed floating tiles. A grid of identical hover-lift feature cards on the landing page. Centred headline + subtext + primary button marketing stacks. Light or white-first chrome for the editor — the canvas surround stays graphite. More than one accent hue; the second colour on screen is always the user's photograph. Rounded pill buttons, blob shapes, and bouncy or springy easing. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The landing first screen is a full-bleed photograph, not a centred headline.

A single image bleeds past the right edge of the viewport, split vertically by a hairline tangerine divider with a circular drag handle at its midpoint. The left half is desaturated and lifted; the right half is the edited result. The headline "Edit like you mean it" is set left-aligned in Space Grotesk 40px mobile / 56px desktop, in #F2EFE9, sitting on the graphite margin at the top-left, with an 11px uppercase mono line above it reading PHOTO EDITOR · ANDROID. Beneath the headline, a row of three small mono readouts — EXPOSURE +0.35 · CLARITY 22 · MASK 3 — in muted grey with tangerine values, then a single tangerine "Open a photo" button, 6px radius, pinned left.

The photograph is the dominant element at roughly 60% of the screen area; the type occupies the quiet graphite margin. No gradient blob, no centred stack, no blue button.

The concept recomposes only accepted content and controls: the entry action into the Photo Editor, the product's identity line, and the before/after comparison that shows the product's core value as a single draggable gesture rather than described in copy. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

Focal subject. The full-bleed hero photograph, split vertically by a hairline tangerine divider with a circular drag handle at its midpoint — the left half desaturated and lifted, the right half the edited result.

Input → transformation → outcome thesis. The user drags the circular handle along the hairline divider; the split position follows the drag, revealing more of the desaturated original on one side and more of the edited result on the other; the outcome is that the product's core value — a photograph transformed by editing — is demonstrated as a single gesture rather than described in copy. This uses only accepted behaviour: the before/after comparison of an edited photograph.

Motion vocabulary. Functional and fast: 120–180ms ease-out on every state change, no bounce, no decoration. The only ambient motion is a single slow 8s drift of a soft tangerine glow behind the landing hero's photograph — a darkroom safelight, not a gradient blob. The divider handle tracks the drag directly, with no easing applied to the split position itself.

Composed first frame. The photograph fills roughly 60% of the screen area, bleeding past the right edge. The divider sits at the midpoint with the handle centred on it. The headline "Edit like you mean it" sits left-aligned on the graphite margin at the top-left, above the mono readout row and the tangerine "Open a photo" button. The tangerine ambient glow sits at 8% opacity behind the photograph.

Reduced-motion state. With prefers-reduced-motion, the ambient tangerine glow drift stops and the hero renders as a static composed frame: the photograph, the divider at its midpoint, the headline, the mono readout row, and the entry button all fully visible and readable. The divider handle remains draggable, since the drag is a direct manipulation of the comparison rather than decorative motion.

No 3D or WebGL scene is requested by the user or called for by the direction's hero dimensionality (flat); no Canvas, R3F, or Drei requirement applies.

9. Non-Functional Requirements

NFR-1 — Android mobile target platform The product targets Android mobile. Provenance: explicit hard constraint. Rationale: the authoritative requirement states the target platform is Android mobile, and editing is performed on photos within the app on an Android device.

NFR-2 — Photoshop-like theme and editing experience The app's theme and editing experience resemble Adobe Photoshop for Android. Provenance: explicit hard constraint. Rationale: the authoritative requirement states the app is themed/styled after the Adobe Photoshop mobile Android app. The reference is inspiration-only and supplies no product names, copy, facts, or capabilities.

NFR-3 — Real-time canvas feedback Slider and parameter changes update the canvas in real time with no easing on the pixels themselves. Provenance: required_inference. Rationale: indispensable to the accepted precision-editing experience — a numeric editor whose numbers are honest must show their effect immediately.

NFR-4 — Numeric legibility Every numeric readout is set in tabular monospace figures so digits do not jitter while a slider is dragged. Provenance: required_inference. Rationale: indispensable to the accepted precision-editing experience and to the direction's instrument register.

NFR-5 — Readable text and controls stay whole 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 creative direction asks, as long as they cover no readable text or control. The horizontally scrolling tool rail may cross the viewport edge by design; every tool chip becomes fully readable as it scrolls into view. With prefers-reduced-motion, the tool rail remains horizontally scrollable so each chip can be brought fully into view. Provenance: explicit (creative direction constraint).

NFR-6 — Single accent hue Tangerine #FF6B2C is the only signal colour; the UI never introduces a second hue, and the photograph supplies every other colour. Provenance: explicit (creative direction constraint).

NFR-7 — No identity requirement The product requires no account, sign-in, or identity establishment to open, edit, or export a photo. Provenance: explicit (planning scope access contract: both pages have access_requirement: none).

10. Tech Stack

• Client platform: Android mobile application. Provenance: explicit hard constraint.
• Client UI: custom first-party UI for both Landing and Photo Editor. Provenance: explicit (planning scope delivery_shape.custom_ui: true).
• Typography: Space Grotesk (headings), Inter Tight (body), JetBrains Mono (numeric readouts, tabular figures). Provenance: explicit (creative direction).
• Storage: on-device photo storage for reading source photos and writing exported results. Provenance: required_inference — the accepted workflow reads a photo from the Android device and writes the finished result out, which requires device-local storage access.
• Backend services: none. No server-side editing, rendering, or persistence is accepted by the requirement thread; all editing happens on the Android device. No docker-compose.yml service inventory applies to this product.

11. Assumptions and Constraints

Assumptions

• A-1. The user has at least one photograph available on their Android device to open into the editor. [Assumption — implied by the accepted workflow of editing photos on the device]
• A-2. The Android device provides the standard photo picker and file access needed to read a source photo and write an exported result. [Assumption — implied by the accepted workflow]
• A-3. The layer stack, blend modes, masks, healing, text, and filters are the accepted Photoshop-like editing vocabulary carried from the inspiration-only reference; their specific parameter sets are not enumerated by the source and are filled at implementation time within the accepted tool set (Crop, Adjust, Mask, Layers, Blend, Heal, Text, Filter). [Assumption — the source names the editing model but not each tool's parameter list]

Constraints

• C-1. Target platform is Android mobile. Provenance: explicit.
• C-2. The app should resemble Adobe Photoshop for Android in theme and editing experience. Provenance: explicit.
• C-3. Adobe Photoshop for Android is an inspiration-only reference for theme and editing experience; it is not an authoritative specification and supplies no product names, copy, facts, or capabilities. Provenance: explicit (reference directive).
• C-4. No application-owned identity, account creation, sign-in, invitation, provisioning, or deployment bootstrap is part of the current product. Provenance: explicit (planning scope access contract).
• C-5. No differentiated permissions, role-based visibility, or permission controls exist; there is a single active human role. Provenance: explicit (planning scope persona contract).
• C-6. The generic indigo/blue-on-white SaaS template is forbidden for this project. Provenance: explicit (creative direction).
• C-7. No cloud sync, collaboration, account system, social sharing, AI generation, or cross-platform client is accepted or planned. Provenance: explicit (no such capability appears in the authoritative requirement thread).

Presentation and technology defaults

• D-1. [Default — not specified by user] Exact Android API level, minimum SDK, and target SDK are not specified by the user and are chosen at implementation time.
• D-2. [Default — not specified by user] The exported file format and output resolution are not specified by the user; the implementation chooses a standard Android-supported image format and preserves the source resolution unless the user's crop or resize changes it.
• D-3. [Default — not specified by user] The specific filter set, blend mode list, and healing brush algorithm are not specified by the user and are chosen at implementation time within the accepted tool set.

12. Glossary

• Document — the open photograph plus its layer stack and edit history, as held by the Photo Editor page.
• Layer — one entry in the document's stack, carrying a name, thumbnail, blend mode, opacity, visibility, and stack position.
• Blend mode — the rule by which a layer's pixels combine with the layers beneath it.
• Opacity — the per-layer value controlling how much of the layer contributes to the result, displayed in monospace on the layer row.
• Mask — a per-layer control that limits where the layer's edit applies.
• Tool rail — the 72px horizontally scrolling row of icon + 11px-label chips (Crop, Adjust, Mask, Layers, Blend, Heal, Text, Filter) at the bottom of the Photo Editor.
• Parameter sheet — the contextual sheet that slides up above the tool rail when a tool is chosen, holding that tool's controls.
• Value bubble — the JetBrains Mono tabular numeric readout that rides above a slider's thumb.
• History step — an undoable and redoable document state.
• Landing — the anonymous public entry surface that introduces the editor's Photoshop-like editing purpose.
• Photo Editor — the cohesive Android editing workspace where the user opens a photo, applies and adjusts edits, and saves or exports the finished result.
• Photo Editor (persona) — the single active human role in the product: a self-directed creative editing their own photographs on an Android phone.
• Darkroom safelight — the single soft tangerine radial glow at 8% opacity drifting slowly behind the landing hero photograph; the only decorative motion in the product.