System Requirements Document for steganography-fe00

1. Introduction

steganography-fe00 is a Variable Selector FE00 steganography tool delivered as a single self-contained HTML file. Its purpose is to let a user conceal a secret payload inside ordinary-looking cover text by embedding the payload as non-visible characters, and to let a recipient recover that payload from the encoded text.

The product intent is a precise, trustworthy, offline instrument for people who already understand what steganography is: a technician or enthusiast who wants to hide a message in plain sight and read one back. The app must be neat, uncluttered, and simple, presenting exactly three tabs — Encode, Decode, and Help — where Help opens as a popup window explaining what the app is for and how to use it.

The audience is technically curious users working directly with non-visible characters. There is no server, no account, no network call, and no external library: everything runs locally in the browser from one HTML file.

2. System Overview

The app is a single HTML file with no online dependencies or libraries. It presents a masthead, a three-tab navigation (Encode | Decode | Help), and the working surface for the selected tab. All encoding and decoding logic runs locally in the browser.

Actors

• Steganography Encoder — enters a payload and cover text, reads the hint box to learn how many cover characters are needed, produces encoded output, and copies it.
• Steganography Decoder — supplies encoded text and recovers the hidden payload.
• App Learner — opens the Help popup to read what the app is for and how to use it.

Accepted behavior

• Encode a payload into cover text using Variable Selector FE00 steganography, embedding the payload as non-visible characters.
• Show a hint box reporting how many cover characters are needed to accommodate the payload characters.
• Provide a Copy button on the payload output that copies all the included non-visible characters.
• Decode encoded text back to the hidden payload.
• Open a Help popup explaining the app's purpose and the encode/decode workflow.

Ownership and access All four surfaces (Landing, Encode, Decode, Help) are application-owned custom pages with no access requirement — the app is anonymous and local, with no identity, account, or session continuity. There is no backend, no provider surface, and no external destination.

Narrow exclusions No online dependencies or libraries. No rounded corners, soft shadows, pill buttons, glass/blur effects, gradients, hero illustrations, stock photography, or icon sets. No blue, indigo, or violet in the palette. No dark mode as the default. No account, login, or permission system.

2a. Product Interpretation and Delivery Boundary

The entire product is delivered as one HTML file that runs offline in the browser. There is no server component, no API, no database, and no third-party runtime. Because the app is anonymous and stateless, there is no identity establishment, no login, and no protected destination: every surface is reachable directly.

The current delivery horizon covers the Encode, Decode, and Help workflows and the Landing entry surface. Nothing in the accepted requirements describes a future phase, so no future capabilities are claimed. The single-file, dependency-free constraint is a hard boundary: all markup, styling, and logic live in the one file, and no external resource is fetched at runtime.

2b. Source Content Inventory

Not applicable — no reference directive declares content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: The public entry surface. A full-bleed 1px rule across the top; the wordmark STEGANOGRAPHY set in Archivo Expanded, uppercase, letter-spaced; a small mono line beneath reading VARIABLE SELECTOR / FE00; a second line reading "Conceal a payload inside ordinary text."; a third hairline rule; the three tab labels flush left.
• Primary actions: Select the Encode tab; select the Decode tab; select the Help tab.
• Supporting actions: None beyond tab selection.
• Domain entities: App identity (wordmark, version code FE00), tab set.
• Component responsibilities: Masthead band (wordmark left, version code FE00 in mono right, separated by a full-bleed 1px rule); tab bar (three uppercase labels on a hairline baseline, active tab marked by a 2px #E63312 underline); the surrounding paper-white silence.
• States: Loading — not applicable (static, no data). Empty — the default state; no tab panel content is shown until a tab is selected. Success — not applicable. Error — not applicable. Recovery — not applicable.

Encode

• Information/state: The Encode working surface. Payload field, cover field, hint box, and output field with a Copy button pinned to its top-right corner. The hint box prints a single sentence in uppercase tracked labels — COVER CHARACTERS REQUIRED: 000 — with the number in tabular mono, updating live as the payload is typed.
• Primary actions: Enter or paste the payload; enter or paste the cover text; read the hint box to learn how many cover characters are needed; produce the encoded output; click Copy to copy the payload output including all non-visible characters.
• Supporting actions: Observe the Copy button's success inversion (fill turns #111111, text turns #F4F2ED, label swaps to COPIED for 1.2s, then reverts; a small square glyph blinks once in #E63312).
• Domain entities: Payload characters; cover characters; required cover-character count; encoded output containing non-visible characters.
• Component responsibilities: Payload textarea (hard-edged box inset with a 1px rule); cover textarea (hard-edged box inset with a 1px rule); hint box (hard-edged white rectangle with a 3px #E63312 left rule, printing the required cover-character count in tabular mono); output field with Copy button pinned to its top-right corner; the 1px rule that draws left-to-right over 180ms when the hint box first appears.
• States: Loading — not applicable (local computation). Empty — no payload entered; hint box shows COVER CHARACTERS REQUIRED: 000; output field empty. Success — encoded output produced with the payload embedded as non-visible characters; Copy button available. Error — payload cannot be accommodated by the supplied cover text; the hint box reports the shortfall. Recovery — the user adds more cover characters or shortens the payload until the hint box reports sufficient cover characters, then re-encodes.

Decode

• Information/state: The Decode working surface. An input field for encoded text and a field showing the recovered payload.
• Primary actions: Paste or enter the encoded text; recover the hidden payload; read the extracted payload.
• Supporting actions: None beyond reading the recovered payload.
• Domain entities: Encoded text containing non-visible characters; recovered payload.
• Component responsibilities: Encoded-text input (hard-edged box inset with a 1px rule); recovered-payload output field.
• States: Loading — not applicable (local computation). Empty — no encoded text entered; recovered-payload field empty. Success — the original hidden payload is revealed. Error — the supplied text contains no recoverable payload; the recovered-payload field reports that no payload was found. Recovery — the user checks that the full encoded text (including its non-visible characters) was pasted, then retries.

Help

• Information/state: A popup window opened when the Help tab is clicked. A plain white rectangle with a 1px black border and no shadow, containing what the app is for and how to use it, plus a CSS-drawn diagram of a cover line with tiny squares marking the hidden character positions — the only graphic in the entire app.
• Primary actions: Read what the app is for; read how to use the encode and decode workflows; close the popup.
• Supporting actions: None.
• Domain entities: Help content (purpose, encode workflow, decode workflow); the cover-line diagram.
• Component responsibilities: Popup container (plain white rectangle, 1px black border, no shadow); purpose text; encode/decode usage text; CSS/SVG diagram (1px strokes, #111111 and #E63312) showing a cover sentence with a row of tiny squares beneath it marking the non-visible character positions; close control.
• States: Loading — not applicable. Empty — not applicable (static content). Success — the popup is open and readable. Error — not applicable. Recovery — the user closes and reopens the popup from the Help tab.

3. Functional Requirements

FR-1 — Single-file, dependency-free delivery (explicit) As a Steganography Encoder, I should receive the entire app as a single HTML file with no online dependencies or libraries, so that it runs offline with nothing fetched at runtime.

• Trigger/input: The user opens the single HTML file.
• Observable result: The app renders and all encode/decode behavior works with no network request and no external resource.
• Access state: Anonymous, local.
• Failure/recovery: If an external resource were required, the app would fail offline; the constraint forbids this, so no recovery path is needed.
• Continuation: The user proceeds to any tab.

FR-2 — Three-tab navigation (explicit) As a Steganography Encoder, I should see exactly three tabs — Encode, Decode, Help — so that I can move between the app's workflows.

• Trigger/input: The user selects a tab.
• Observable result: The selected tab's surface is shown; the active tab is marked by a 2px #E63312 underline.
• Access state: Anonymous, local.
• Failure/recovery: Not applicable.
• Continuation: The user works within the selected tab.

FR-3 — Encode a payload into cover text (explicit) As a Steganography Encoder, I should enter a payload and cover text and produce encoded output with the payload embedded as non-visible characters, so that the secret is concealed inside ordinary-looking text.

• Trigger/input: The user enters a payload and cover text and produces the encoded output.
• Observable result: Encoded output is produced containing the payload as non-visible characters.
• Access state: Anonymous, local.
• Failure/recovery: If the cover text cannot accommodate the payload, the hint box reports the shortfall; the user adds cover characters or shortens the payload and re-encodes.
• Continuation: The user copies the output or returns to edit the inputs.

FR-4 — Cover-character hint box (explicit) As a Steganography Encoder, I should see a hint box showing how many cover characters are needed to accommodate the payload characters, so that I know whether my cover text is sufficient before encoding.

• Trigger/input: The user types or pastes a payload.
• Observable result: The hint box prints COVER CHARACTERS REQUIRED: 000 with the number in tabular mono, updating live as the payload is typed.
• Access state: Anonymous, local.
• Failure/recovery: If the payload exceeds what the cover text can hold, the hint box reports the shortfall; the user adjusts inputs.
• Continuation: The user proceeds to encode once the hint box reports sufficient cover characters.

FR-5 — Copy button copies all non-visible characters (explicit) As a Steganography Encoder, I should click a Copy button on the payload output that copies all the included non-visible characters, so that the concealed payload survives the copy intact.

• Trigger/input: The user clicks Copy on the payload output.
• Observable result: The full output — including every non-visible character — is placed on the clipboard; the button inverts to solid #111111 with #F4F2ED text and the label swaps to COPIED for 1.2s, then reverts; a small square glyph blinks once in #E63312.
• Access state: Anonymous, local.
• Failure/recovery: If the clipboard write is unavailable, the user can select the output manually; the app does not silently drop non-visible characters.
• Continuation: The user pastes the copied output elsewhere.

FR-6 — Decode encoded text (explicit) As a Steganography Decoder, I should supply encoded text and recover the hidden payload, so that I can read the concealed message.

• Trigger/input: The user pastes or enters encoded text into the Decode tab.
• Observable result: The original hidden payload is revealed in the recovered-payload field.
• Access state: Anonymous, local.
• Failure/recovery: If the supplied text contains no recoverable payload, the recovered-payload field reports that no payload was found; the user checks that the full encoded text (including its non-visible characters) was pasted and retries.
• Continuation: The user reads the recovered payload.

FR-7 — Help popup (explicit) As an App Learner, I should click the Help tab to open a popup window where I can read what the app is for and how to use it, so that I understand the app before using it.

• Trigger/input: The user clicks the Help tab.
• Observable result: A popup window opens as a plain white rectangle with a 1px black border and no shadow, containing the app's purpose, the encode/decode usage instructions, and a CSS-drawn diagram of a cover line with tiny squares marking the hidden character positions.
• Access state: Anonymous, local.
• Failure/recovery: If the popup is closed, the user reopens it from the Help tab.
• Continuation: The user closes the popup and proceeds to Encode or Decode.

FR-8 — Neat, uncluttered, simple presentation (explicit) As a Steganography Encoder, I should experience a neat, uncluttered, simple interface, so that the tool stays focused and readable.

• Trigger/input: The user views any surface.
• Observable result: A strict single column, generous whitespace, hairline rules, and a single spot colour; no decorative clutter.
• Access state: Anonymous, local.
• Failure/recovery: Not applicable.
• Continuation: The user works without distraction.

4. User Personas

Steganography Encoder

• Product context: A technically curious user who wants to hide a secret payload inside ordinary-looking cover text using Variable Selector FE00 steganography. They work directly with non-visible characters and expect a precise, trustworthy instrument.
• Primary goal: Produce encoded text with the payload embedded as non-visible characters, and copy it intact.
• Distinct accepted responsibilities: Enter the payload and cover text; read the hint box to learn how many cover characters are needed; produce the encoded output; click Copy to copy all the included non-visible characters.
• Relevant inputs or decisions: The payload text; the cover text; the decision of whether the cover text is sufficient (informed by the hint box).
• Interactions with other accepted participants: The Encoder produces output that the Steganography Decoder later recovers; the Encoder may consult the App Learner's Help content first.
• Observable success: Encoded output is produced with the payload embedded as non-visible characters, and the Copy button places the full output — including every non-visible character — on the clipboard.

Steganography Decoder

• Product context: A user who receives or holds encoded text and wants to recover the hidden payload. They may not know the cover text's origin and must trust that the non-visible characters survived transmission.
• Primary goal: Recover the original hidden payload from encoded text.
• Distinct accepted responsibilities: Paste or enter the encoded text into the Decode tab; recover the hidden payload; read the extracted payload.
• Relevant inputs or decisions: The encoded text (including its non-visible characters); the decision of whether the recovered payload is the expected message.
• Interactions with other accepted participants: The Decoder consumes output produced by the Steganography Encoder; the Decoder may consult the App Learner's Help content first.
• Observable success: The original hidden payload is revealed in the recovered-payload field.

App Learner

• Product context: A user unfamiliar with the app who wants to understand what it is for and how to use it before committing to a workflow.
• Primary goal: Understand the app's purpose and the encode/decode workflow.
• Distinct accepted responsibilities: Click the Help tab; read what the app is for; read how to use the encode and decode workflows; close the popup.
• Relevant inputs or decisions: The Help content and the cover-line diagram; the decision of whether to proceed to Encode or Decode.
• Interactions with other accepted participants: The App Learner's understanding enables the Encoder and Decoder workflows.
• Observable success: The user understands the app's purpose and the encode/decode workflow before using it.

5. Core User Flows

Flow 1 — Encode a payload and copy the output (Steganography Encoder)

1. The user opens the single HTML file. The Landing surface appears: the wordmark STEGANOGRAPHY, the mono line VARIABLE SELECTOR / FE00, the line "Conceal a payload inside ordinary text.", and the three tab labels flush left.
2. The user selects the Encode tab. The active tab is marked by a 2px #E63312 underline, and the Encode surface appears with the payload field, cover field, hint box, and output field.
3. The user types or pastes the payload into the payload field. The hint box updates live, printing COVER CHARACTERS REQUIRED: 000 with the number in tabular mono.
4. The user types or pastes the cover text into the cover field. The hint box continues to update as the payload changes.
5. The user reads the hint box to confirm the cover text can accommodate the payload.
   • Failure/recovery: If the hint box reports a shortfall, the user adds more cover characters or shortens the payload until the hint box reports sufficient cover characters.
6. The user produces the encoded output. The output field shows the encoded text with the payload embedded as non-visible characters.
7. The user clicks Copy on the payload output. The full output — including every non-visible character — is placed on the clipboard; the button inverts to solid #111111 with #F4F2ED text and the label swaps to COPIED for 1.2s, then reverts; a small square glyph blinks once in #E63312.
8. Continuation: The user pastes the copied output elsewhere, or returns to edit the inputs and re-encode.

Flow 2 — Decode encoded text (Steganography Decoder)

1. The user opens the single HTML file and selects the Decode tab. The Decode surface appears with the encoded-text input and the recovered-payload field.
2. The user pastes or enters the encoded text into the input field, ensuring the full text — including its non-visible characters — is included.
3. The user recovers the hidden payload. The recovered-payload field shows the original hidden payload.
   • Failure/recovery: If the recovered-payload field reports that no payload was found, the user checks that the full encoded text was pasted and retries.
4. Continuation: The user reads the recovered payload.

Flow 3 — Learn how to use the app (App Learner)

1. The user opens the single HTML file and clicks the Help tab.
2. A popup window opens as a plain white rectangle with a 1px black border and no shadow.
3. The user reads what the app is for and how to use the encode and decode workflows, and studies the CSS-drawn diagram of a cover line with tiny squares marking the hidden character positions.
4. The user closes the popup.
5. Continuation: The user proceeds to the Encode or Decode tab with an understanding of the workflow.

6. Visuals Colors and Theme

Muse: Peter Saville. Headline idea: an austere code-language for a tool that hides in plain sight — a printed specification sheet, not a SaaS dashboard.

Colour tokens (light mode — primary ground):

• Background: #F4F2ED (warm paper-white)
• Surface: #FFFFFF (pure white panels for working surfaces)
• Text / primary: #111111 (near-black ink for all type and rules)
• Accent: #E63312 (Saville red-orange — used only as a code: active tab underline, Copy button fill, hint-box left rule, and the counted non-visible-character number)
• Muted: #8A867C (secondary metadata and disabled states)
• Hairline rules: #111111 or #D8D4CB

Colour tokens (dark mode — inverted logic):

• Background: #0E0E0E
• Surface: #171717
• Text: #F2F0EB
• Accent: #E63312 (unchanged)

Proportion: ~85% paper/white, ~12% ink, ~3% spot colour. Nothing else is coloured.

Typography:

• Headings: Archivo — single weight (500) at small sizes with wide tracking (+0.18em) and uppercase for all labels, tabs, and the wordmark. The one display moment (app name / hero) uses Archivo Expanded at 600 with tight leading and wide letterspacing.
• Body: Archivo.
• Scale: 1.25 modular — 12 / 13 / 16 / 20 / 28 / 44 / 72 (clamp 40→72). Body 16/1.6; labels 12/1.4 uppercase +0.18em; mono data 13/1.5.
• No bold-for-emphasis; hierarchy comes from size, case, letterspacing, and hairline rules.

Shape language: Nothing rounded. 0px radius everywhere — square corners on buttons, panels, tabs, and the hint box. Rules are 1px hairlines. The only geometric motif is a small square: the tab indicator, the copy-success flash, the character-count tick. Buttons are solid rectangles; textareas are hard-edged boxes inset with a 1px rule; the modal is a plain white rectangle with a 1px black border and no shadow.

Spacing rhythm: Gallery-like whitespace around a strict single column, max-width 720px, centred, with generous 96px top padding and 64px gutters. At 768px the hint box moves to a full-width band beneath the two text fields. At 1280px the column stays 720px and the surrounding silence grows. On mobile everything collapses to one column at 375px with 20px gutters.

Imagery style: No photography, no illustration, no decorative graphics. The only visual artefact is the product's own notation: a small inline diagram in the Help popup showing a cover sentence with the non-visible characters marked by a row of tiny squares beneath it, drawn in pure CSS/SVG (1px strokes, #111111 and #E63312). A vertical hairline "measure" rule flanks the text column. The character-count readout is set in tabular mono numerals as data typography, not an icon.

7. Signature Design Concept

The public entry is a printed specification sheet. A full-bleed 1px rule runs across the top. The wordmark STEGANOGRAPHY is set in Archivo Expanded 500, uppercase, letter-spaced +0.22em, at clamp(40px, 8vw, 72px), hugging the left edge of a 720px column. Beneath it, a small mono line reads VARIABLE SELECTOR / FE00, followed by a second line: "Conceal a payload inside ordinary text." A third hairline rule sits directly under, and the three tab labels — ENCODE, DECODE, HELP — sit flush left on that baseline, the active one marked by a 2px #E63312 underline.

The composition is asymmetric: everything hugs the left edge of the column, the right half is silence. Roughly 60% of the viewport is untouched #F4F2ED. Nothing is centred, nothing is boxed, and no button is visible until a tab is open. The dominant element is the type itself plus the surrounding paper-white emptiness — the page reads as a classified instrument, not a web app.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The wordmark STEGANOGRAPHY and the surrounding paper-white emptiness, composed as a printed specification sheet.
• Input → transformation → outcome thesis: The user opens the file → the specification sheet renders with the wordmark, the mono version line, and the three tab labels → the user selects a tab and the working surface appears. No motion is required to convey the product's meaning; the type and the silence do the work.
• Motion vocabulary: Almost none — Saville's motion ceiling is still. Permitted: a 140ms opacity/colour fade when switching tabs; an instant colour inversion on the Copy button when the copy succeeds (fill turns #111111, text turns #F4F2ED, reverting after 1.2s); a 1px rule that draws left-to-right over 180ms when the hint box first appears. No parallax, no scroll effects, no easing theatrics.
• Composed first frame: A full-bleed 1px rule across the top; the wordmark flush left in Archivo Expanded; the mono line VARIABLE SELECTOR / FE00 beneath it; the line "Conceal a payload inside ordinary text."; a third hairline rule; the three tab labels flush left with the active underline in #E63312. The right half of the viewport is untouched #F4F2ED.
• Reduced-motion state: Under prefers-reduced-motion, all transitions collapse to instant state changes. The tab switch, the Copy button inversion, and the hint-box rule appear immediately with no fade or draw.

9. Non-Functional Requirements

NFR-1 — Offline, single-file delivery (explicit) The app must be delivered as a single HTML file with no online dependencies or libraries. Rationale: the user explicitly required this, and it guarantees the tool works offline and remains self-contained.

NFR-2 — Neat, uncluttered, simple interface (explicit) The app must be neat, uncluttered, and simple. Rationale: the user explicitly required this; the design direction enforces it through a strict single column, generous whitespace, hairline rules, and a single spot colour.

NFR-3 — Copy fidelity for non-visible characters (explicit) The Copy button must copy all the included non-visible characters. Rationale: the user explicitly required this; without it the concealed payload would be lost on copy.

NFR-4 — Help opens as a popup window (explicit) The Help tab must open a popup window when clicked. Rationale: the user explicitly required this.

NFR-5 — Readable text and controls at every viewport (required_inference) Headlines, wordmarks, labels, numbers, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, with no other element covering any part of them. Rationale: the design direction requires readable text and controls to stay whole at every viewport.

NFR-6 — Reduced-motion support (required_inference) Under prefers-reduced-motion, all transitions must collapse to instant state changes. Rationale: the design direction specifies this.

10. Tech Stack

• Delivery: A single HTML file containing all markup, styling, and logic. No online dependencies or libraries. (explicit)
• Runtime: Browser-native HTML, CSS, and JavaScript only. (explicit — implied by "single html file" and "no online dependencies or libraries")
• Storage: None. The app is stateless and local; no persistence is required by the accepted requirements. (required_inference)
• Backend / API: None. (required_inference — no server behavior is accepted)
• Containerization / orchestration: None. (required_inference — a single static HTML file requires no Docker or Kubernetes)

11. Assumptions and Constraints

Assumptions

• The app is anonymous and local; no account, login, or session continuity is required. (required_inference — the accepted requirements describe no identity or persistence)
• The Variable Selector FE00 steganography method embeds the payload as non-visible characters within the cover text, and the Decode tab reverses that embedding. (required_inference — the user named the method and the encode/decode workflows but did not specify the algorithm's internals)
• The hint box reports the required cover-character count in tabular mono numerals, updating live as the payload is typed. (required_inference — the user required the hint box; the design direction specifies its presentation)

Constraints

• Single HTML file delivery. (explicit)
• No online dependencies or libraries. (explicit)
• Copy button must copy all the included non-visible characters. (explicit)
• Help opens as a popup window when the Help tab is clicked. (explicit)
• App must be neat, uncluttered, and simple. (explicit)
• Exactly three tabs: Encode, Decode, Help. (explicit)
• No rounded corners, soft shadows, pill buttons, glass or blur effects. (explicit — design direction)
• No blue, indigo, or violet in the palette; the accent is #E63312 only. (explicit — design direction)
• No gradient blobs, hero illustrations, stock photography, or icon sets. (explicit — design direction)
• No more than one typeface family and more than one weight. (explicit — design direction)
• No hover-lift cards, bouncy easing, parallax, or scroll-triggered animation. (explicit — design direction)
• No centred marketing hero with headline + subtext + button stack. (explicit — design direction)
• No decorative colour beyond the single spot accent. (explicit — design direction)
• Dark mode is not the default; paper-white is the primary ground. (explicit — design direction)

12. Glossary

• Variable Selector FE00 — The steganography method used by the app to embed a payload as non-visible characters within cover text.
• Payload — The secret message the user wants to conceal.
• Cover text — The ordinary-looking text that carries the concealed payload.
• Non-visible characters — Characters embedded in the output that are not visually apparent but are preserved when the text is copied.
• Hint box — The hard-edged white rectangle with a 3px #E63312 left rule that prints COVER CHARACTERS REQUIRED: 000, updating live as the payload is typed.
• Encoded output — The cover text with the payload embedded as non-visible characters.
• Copy button — The control on the payload output that copies all the included non-visible characters, inverting to solid #111111 with #F4F2ED text and the label COPIED for 1.2s on success.
• Tab — One of the three navigation labels — Encode, Decode, Help — on a hairline baseline, the active one marked by a 2px #E63312 underline.
• Help popup — The plain white rectangle with a 1px black border and no shadow, opened when the Help tab is clicked, containing the app's purpose, usage instructions, and a CSS-drawn cover-line diagram.