System Requirements Document for email-address-creation

1. Introduction

email-address-creation is a website that lets a visitor create a real, working email address on the spot. The visitor chooses the local-part of the address (the name before the @) and chooses the password for that address, and the product provisions the mailbox immediately so it can be used right away — not as a mockup, demo, or placeholder.

The product intent is deliberately narrow and concrete: pick a name, pick a password, get a working inbox. The site must be detailed enough that a first-time visitor understands exactly what address they are about to create, what rules their chosen name must satisfy, how strong their password is, and what they will be able to do with the mailbox once it exists. It must be usable immediately: the created address and password must work for signing back in, and the mailbox must persist so the user can return to it and continue corresponding.

The audience is a power user or developer-adjacent user who wants a functioning mailbox with a custom address and custom password in under a minute, with no ceremony and no marketing fluff. They will judge the product by the precision of its address rules, the honesty of its password feedback, and whether the address they typed is the address they actually got.

2. System Overview

The system is a first-party web application with an application-owned identity model. It consists of:

• A public Landing surface that explains the product and hosts the live address forge.
• A Sign Up surface where a visitor establishes a new mailbox by choosing a custom address name and a custom password.
• A Login surface where a returning user verifies with the address and password they created.
• A protected Mailbox surface where the user reads received messages in the created mailbox.
• A protected Compose surface where the user writes and sends messages from the created mailbox.

Actors. The accepted active human personas are exactly two: the Email Account Creator, who needs a working address immediately and specifies its name and password, and the Mailbox User, who operates the created mailbox day to day. External recipients of sent mail are outbound-only non-persona actors: they receive messages but never interact with this product's interface.

Accepted behavior. Automatic email address creation; user-customizable address name; user-customizable email password; a detailed, immediately usable product; self-service enrollment that creates the customized address and password before mailbox use; returning verification with the created address and password before protected mailbox access; and persistence of the created mailbox and its messages so the user can return and continue.

Ownership. All five surfaces are application-owned custom pages. Mailbox and Compose require an established session; Landing, Sign Up, and Login are anonymously reachable. Mail delivery to and from external mail systems is owned by external mail infrastructure, not by this product's interface.

Narrow exclusions. This document does not add account recovery, password reset, multi-address management, contact books, folders beyond what the mailbox reading experience requires, calendar, filtering rules, or administrative consoles. None of these were requested.

2a. Product Interpretation and Delivery Boundary

The product is delivered as a first-party website with its own identity: a visitor can create a mailbox without any prior provisioning step, and a returning user signs back in with the exact address and password they created. Identity is application-owned because the accepted journey requires that a specific created address and its password remain bound to the person who created them, and that the mailbox and its messages persist across visits.

The anonymous entry boundary is real and distinct: a visitor must be able to reach the Landing surface and the Sign Up surface, and to complete address creation, before any protected state exists. The protected boundary begins at the Mailbox and Compose surfaces, which are only reachable once the created address and password have been verified. The Login surface is itself anonymously reachable — it is the interaction that establishes access to the protected surfaces, so it cannot require that access to reach itself.

Current delivery covers the five surfaces above and the end-to-end lifecycle of creating an address, signing in with it, reading mail, and sending mail. Nothing in this document is deferred to a future horizon; the accepted requirement is that the product be usable immediately.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares a content_source, so no verified external factual inventory is carried into this document.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Explains, in the first viewport, that the visitor can choose an address name and a password and receive a working inbox. Displays the address anatomy schematic (local-part · @ · domain) with hairline callouts, the address rule checklist, and a live preview of the address currently being typed.
• Primary action. "Create your address" — navigates to Sign Up, carrying the local-part currently typed in the forge so the visitor does not retype it.
• Supporting actions. Edit the local-part directly in the forge; copy the previewed address; follow the "Sign in" link to Login for returning users; open the command bar.
• Domain entities. Address preview (local-part, domain, full address), address rule set, availability state.
• Component responsibilities.
  • Top bar (56px). Wordmark, current-account chip (empty state for anonymous visitors), and a persistent 11px uppercase keyboard-shortcut hint.
  • Hero display block. Oversized flush-left headline in Space Grotesk, with the final line in tangerine over a solid tangerine block bleeding off the left viewport edge.
  • Address forge panel. Editable local-part input, @-chip showing the domain, live full-address preview in JetBrains Mono at display size, inline availability state, and a copy control that swaps to "Copied" for 1.2s.
  • Address anatomy diagram. Hairline-ruled schematic with monospace callouts and a rule checklist that ticks each satisfied rule.
  • Example address ticker. A live monospace ticker of example addresses scrolling left in JetBrains Mono at 15px.
  • Command bar. Cmd/Ctrl+K palette over a dimmed graphite field with the actions New address, Copy address, Compose, Search mail, Copy IMAP settings.
• States. Loading: the availability check renders a three-dot monospace ellipsis while it resolves. Empty: the forge shows a placeholder local-part and the preview renders the domain with an empty local-part slot. Success: the availability state snaps to a checkmark in acid green and the rule checklist is fully ticked. Error: a specific rule violation is stated in tangerine next to the offending rule. Recovery: editing the local-part immediately re-runs the check and clears the previous violation.

Sign Up

• Information and state. Anonymous identity-access surface. Single-column 480px form in the left seven columns, with a persistent right rail showing the live preview of the address being created so the consequence of every keystroke is visible. States plainly that the address name and password are the user's choice and that the mailbox becomes usable immediately.
• Primary action. "Create address" — creates the mailbox with the exact local-part and password entered.
• Supporting actions. Edit the local-part; edit the password; reveal/hide the password; copy the previewed address; follow the "Already have an address? Sign in" link to Login.
• Domain entities. Local-part, domain, full address, password, password strength score, address rule checklist, availability state.
• Component responsibilities.
  • Local-part field. 11px uppercase label, 6px radius, hairline border, 2px tangerine focus ring outside the border; live rule checklist beneath it.
  • Domain chip. 4px-radius tag showing the fixed domain, adjacent to the local-part field.
  • Address preview rail. Full address rendered in JetBrains Mono at clamp(20px, 3.4vw, 40px) with a copy control.
  • Password field. With reveal toggle and a strength meter whose bar animates width in 160ms and whose score numeral uses tabular numerals.
  • Password rule checklist. Explicit requirements ticked green as the password satisfies them.
  • Submit control. The single tangerine primary action on this screen.
• States. Loading: the availability check shows the monospace ellipsis; the submit control is disabled while the address is unresolved. Empty: both fields empty, checklist unticked, preview showing the domain only. Success: the mailbox is created and the user is taken to the Mailbox with the created address shown in the account chip. Error — address taken: the local-part field is marked and a specific message states that the name is unavailable, with the field focused for correction. Error — rule violation: the specific violated rule is named. Error — weak password: the unmet password requirement is named. Recovery: every error is corrected in place without losing the other field's value, and the address is re-checked on edit.

Login

• Information and state. Anonymous identity-access surface. Single-column 480px form in the left seven columns with the same right rail treatment, here showing the address being entered and a reminder that the password is the one chosen at creation.
• Primary action. "Sign in" — verifies the entered address and password and opens the protected mailbox.
• Supporting actions. Reveal/hide the password; follow the "Create an address" link to Sign Up.
• Domain entities. Address, password, session.
• Component responsibilities.
  • Address field. Accepts the full created address.
  • Password field. With reveal toggle.
  • Submit control. The single tangerine primary action on this screen.
  • Account chip. Populated in the top bar once verification succeeds.
• States. Loading: the submit control shows an in-progress state and is not re-submittable. Empty: both fields empty with the submit control disabled. Success: the session is established and the Mailbox opens with the created address in the account chip. Error: a single non-enumerating message states that the address and password combination was not accepted, without revealing which field was wrong. Recovery: the password field is cleared and focused, the address is preserved, and the user may retry immediately.

Mailbox

• Information and state. Protected surface. Classic three-pane power-user layout: a 240px folder rail, a 360px message list with tabular timestamps, and a flexible reading pane. The account chip shows the created address. Message counts, quota, and timestamps are set in tabular numerals with hairline rules above and below, so the list reads like an instrument readout.
• Primary action. "Compose" — opens the Compose surface.
• Supporting actions. Select a folder in the rail; select a message in the list; read the selected message in the reading pane; copy the created address; copy IMAP/SMTP settings; open the command bar; sign out.
• Domain entities. Mailbox, folder, message (sender, subject, received timestamp, body, read/unread state), quota, account address.
• Component responsibilities.
  • Folder rail. 240px, hairline-separated rows, keyboard navigable.
  • Message list. 360px, tabular timestamps, unread state, selection highlight.
  • Reading pane. Renders the selected message's sender, subject, timestamp, and body.
  • Account chip. Shows the created address with a copy control.
  • Command bar. Cmd/Ctrl+K with New address, Copy address, Compose, Search mail, Copy IMAP settings.
• States. Loading: the message list shows ruled skeleton rows in the list's own rhythm. Empty: the list states that no messages have arrived yet and offers Compose as the next step. Success: the selected message renders fully in the reading pane and its unread marker clears. Error: if the mailbox cannot be loaded, a ruled error row states the failure and offers a retry that re-requests the mailbox without losing the session. Recovery: retry restores the list; if the session has expired, the user is returned to Login with the address preserved.

Compose

• Information and state. Protected surface. Full-pane form with a fixed footer action bar. Shows the sending address (the created address) as a read-only field so the user always knows which identity the message leaves from.
• Primary action. "Send" — sends the message from the created address.
• Supporting actions. Edit recipient, subject, and body; discard the draft; return to the Mailbox; open the command bar.
• Domain entities. Outgoing message (from, to, subject, body), send state, draft.
• Component responsibilities.
  • From field. Read-only, showing the created address in JetBrains Mono.
  • To field. Recipient input.
  • Subject field. Single-line input.
  • Body field. Multi-line editor.
  • Footer action bar. Fixed, carrying the single tangerine Send action and the discard control.
• States. Loading: not applicable on entry; the form is immediately editable. Empty: recipient, subject, and body empty with Send disabled. Success: the message is handed to the mail infrastructure and the user is returned to the Mailbox with a confirmation that the message was sent. Error — invalid recipient: the recipient field is marked with a specific message and the body is preserved. Error — send failure: a ruled error bar states that the message was not sent and keeps the composed content intact. Recovery: retry re-attempts the send with the same content; the draft is never silently discarded.

3. Functional Requirements

FR-1 — Automatic email address creation As an Email Account Creator, I should be able to have an email address created automatically for me, so that I get a working address without assembling it myself.

• Provenance: explicit.
• Actor: Email Account Creator. Trigger: the visitor submits the address creation form on Sign Up.
• Observable result: a mailbox exists whose address is the exact local-part the user entered joined to the product domain, and the user is taken to the Mailbox with that address shown in the account chip.
• Access state: anonymous entry; the created mailbox is then bound to the created credentials.
• Failure/recovery: if the address cannot be created, the specific reason is stated on the form and the entered values are preserved for correction.
• Continuation: the user proceeds directly into the created mailbox.

FR-2 — Customizable email address name As an Email Account Creator, I should be able to customize the name portion of my email address, so that the address is the one I want rather than an assigned one.

• Provenance: explicit.
• Actor: Email Account Creator. Trigger: typing in the local-part field on Landing or Sign Up.
• Observable result: the full address preview updates live in JetBrains Mono at display size, the rule checklist ticks each satisfied rule, and the availability state resolves to available or to a specific rule violation.
• Access state: anonymous.
• Failure/recovery: a violated rule is named specifically and the field is corrected in place; the check re-runs on every edit.
• Continuation: once the name is available and all rules are satisfied, the user can create the address.

FR-3 — Customizable email password As an Email Account Creator, I should be able to customize the password for my email address, so that I control the credential that protects my mailbox.

• Provenance: explicit.
• Actor: Email Account Creator. Trigger: typing in the password field on Sign Up.
• Observable result: the strength meter's bar width animates in 160ms, the score numeral updates in tabular numerals, and the password rule checklist ticks each satisfied requirement.
• Access state: anonymous.
• Failure/recovery: an unmet password requirement is named specifically and the field is corrected in place without losing the address field's value.
• Continuation: once the password satisfies the stated requirements, the address can be created with that exact password.

FR-4 — Detailed, immediately usable product As an Email Account Creator, I should be able to use the product end to end the moment I arrive, so that I am not looking at a mockup or a placeholder.

• Provenance: explicit.
• Actor: Email Account Creator, then Mailbox User. Trigger: any visit to the site.
• Observable result: every surface described in this document performs its stated action against real state — the address created is the address that signs in, and the mailbox that opens is the mailbox that persists.
• Access state: anonymous for Landing, Sign Up, and Login; session-bound for Mailbox and Compose.
• Failure/recovery: any failure is stated in place with a retry that preserves the user's input.
• Continuation: the user can leave and return to the same mailbox.

FR-5 — Self-service enrollment creates the customized address and password before mailbox use As an Email Account Creator, I should be able to enroll myself by choosing my address name and password, so that the mailbox exists under my chosen credentials before I try to use it.

• Provenance: required_inference.
• Actor: Email Account Creator. Trigger: submitting the Sign Up form with an available local-part and a compliant password.
• Observable result: the mailbox is created with exactly the entered local-part and password, and the user enters the Mailbox already authenticated as that address.
• Access state: anonymous entry; the resulting session is bound to the created address.
• Failure/recovery: an unavailable name, a rule violation, or a weak password is reported specifically and the form retains the user's other input.
• Continuation: the user lands in the Mailbox with the created address in the account chip.

FR-6 — Returning verification with the created address and password As a Mailbox User, I should be able to sign in with the address and password I created, so that I can return to my mailbox and continue using it.

• Provenance: required_inference.
• Actor: Mailbox User. Trigger: submitting the Login form.
• Observable result: a session is established and the Mailbox opens with the created address in the account chip.
• Access state: Login is anonymously reachable; Mailbox and Compose require the established session.
• Failure/recovery: a single non-enumerating message states that the combination was not accepted; the password field is cleared and focused while the address is preserved, and the user may retry immediately.
• Continuation: the user proceeds into the mailbox; if the session later expires, the user is returned to Login with the address preserved.

FR-7 — Persistent mailbox and messages As a Mailbox User, I should be able to return to my mailbox and find my messages still there, so that the address I created remains genuinely usable over time.

• Provenance: required_inference.
• Actor: Mailbox User. Trigger: signing in on a later visit.
• Observable result: the mailbox opens with the same address, the same folders, and the previously received messages intact, with their read/unread state preserved.
• Access state: session-bound.
• Failure/recovery: if the mailbox cannot be loaded, a ruled error row states the failure and offers a retry that re-requests the mailbox without losing the session.
• Continuation: the user resumes reading and sending from where they left off.

FR-8 — Read received messages As a Mailbox User, I should be able to read the messages that arrive in my created mailbox, so that the address is useful for receiving mail.

• Provenance: required_inference.
• Actor: Mailbox User. Trigger: selecting a message in the message list.
• Observable result: the reading pane renders the message's sender, subject, timestamp, and body, and the unread marker clears.
• Access state: session-bound.
• Failure/recovery: if the mailbox cannot be loaded, the error row and retry described in FR-7 apply.
• Continuation: the user selects another message or moves to Compose.

FR-9 — Compose and send from the created address As a Mailbox User, I should be able to compose and send a message from my created address, so that I can conduct correspondence from the address I chose.

• Provenance: required_inference.
• Actor: Mailbox User. Trigger: opening Compose and submitting the form.
• Observable result: the message is handed to the mail infrastructure with the created address as the sender, and the user returns to the Mailbox with a confirmation that the message was sent.
• Access state: session-bound.
• Failure/recovery: an invalid recipient or a send failure is stated specifically, the composed content is preserved intact, and retry re-attempts the send with the same content.
• Continuation: the user returns to the Mailbox and may compose another message.

FR-10 — Copy the created address and its client settings As a Mailbox User, I should be able to copy my created address and the IMAP/SMTP settings for it, so that I can use the mailbox from a mail client.

• Provenance: required_inference.
• Actor: Mailbox User. Trigger: activating the copy control on the account chip or the Copy IMAP settings command.
• Observable result: the value is placed on the clipboard and the control swaps to "Copied" for 1.2s without a toast.
• Access state: the address copy is available anonymously from the Landing forge; the settings copy is available in the session-bound Mailbox.
• Failure/recovery: if the clipboard is unavailable, the value remains selectable in place so it can be copied manually.
• Continuation: the user pastes the value into their mail client.

4. User Personas

Email Account Creator

Product context. This person arrives at the site without an address and without any prior relationship to the product. They have a specific name in mind for the part before the @, and they have a specific password in mind. They are technical enough to judge the product instantly: they will test the address rules, watch the password meter, and check whether the address they typed is the address they got.

Primary goal. To have a real, working email address with the exact name and the exact password they chose, in under a minute, with no ceremony.

Distinct accepted responsibilities. Choosing the local-part of the address and reading the rule checklist as it ticks; choosing the password and reading the strength meter and password requirements; resolving an unavailable name or a rule violation; submitting the creation form; and confirming that the resulting address matches what they intended.

Relevant inputs and decisions. The local-part string; the password string; the decision to accept an available name or to change it; the decision to strengthen a password or to proceed; the decision to create the address now.

Interactions with other accepted participants. The Email Account Creator's work ends where the Mailbox User's begins: the address and password they commit become the credentials the Mailbox User signs in with. The external recipients of any mail sent later never interact with this person through the product's interface.

Observable success. The Mailbox opens immediately after creation, the account chip shows the exact address they typed, and the password they chose is the password that signs them back in.

Mailbox User

Product context. This person operates the mailbox that exists. They may be the same human who created it, returning later, or they may be the person who uses the address day to day. They arrive at Login with the created address and password, or they arrive already inside a session.

Primary goal. To read what has arrived and to send mail from the created address without any further setup.

Distinct accepted responsibilities. Verifying with the created address and password; reading the message list and opening messages in the reading pane; composing a message with a recipient, subject, and body; sending it from the created address; recovering from a rejected sign-in, an invalid recipient, or a send failure; and returning later to find the mailbox and its messages intact.

Relevant inputs and decisions. The address and password at sign-in; which folder and which message to open; the recipient, subject, and body of an outgoing message; the decision to send, to discard, or to retry after a failure.

Interactions with other accepted participants. The Mailbox User depends on the Email Account Creator having committed an address and password, and on the external mail infrastructure to deliver outgoing mail and to receive incoming mail. External recipients are outbound-only: they receive messages but have no interface in this product.

Observable success. The mailbox opens with the created address in the account chip, previously received messages are still present with their read state preserved, and a composed message is confirmed as sent from the created address.

5. Core User Flows

Flow 1 — Email Account Creator creates a customized address and password

1. The visitor arrives anonymously at Landing. The hero states the product in one line: pick a name, pick a password, get a working inbox.
2. The visitor types a local-part into the address forge panel. The full address renders live in JetBrains Mono at display size, and the address anatomy diagram's rule checklist ticks each rule the input satisfies (3–30 characters, a–z 0–9 . _ -, no leading or trailing dot).
3. While the availability check resolves, the forge shows a three-dot monospace ellipsis. It then snaps to a checkmark in acid green if the name is available, or states the specific rule violation in tangerine if it is not.
4. If the name is unavailable or violates a rule, the visitor edits the local-part in place; the check re-runs on every edit and the previous violation clears.
5. The visitor activates Create your address. The local-part they typed is carried into Sign Up so they do not retype it.
6. On Sign Up, the visitor sees the address preview rail rendering the full address they are about to create, and enters a password. The strength meter's bar animates in 160ms, the score numeral updates in tabular numerals, and the password rule checklist ticks each satisfied requirement.
7. If a password requirement is unmet, it is named specifically and the visitor corrects it in place; the address field's value is preserved.
8. The visitor submits Create address — the single tangerine primary action on the screen.
9. Observable result: the mailbox is created with exactly the entered local-part and password, and the visitor lands in Mailbox already authenticated, with the created address in the account chip.
10. Continuation: the visitor may copy the address, copy the IMAP/SMTP settings, or move straight to Compose.

Flow 2 — Mailbox User returns and verifies with the created credentials

1. The returning user arrives anonymously at Login.
2. They enter the full address they created and the password they chose, using the reveal toggle if needed.
3. They submit Sign in — the single tangerine primary action on the screen.
4. Observable result: a session is established and Mailbox opens with the created address in the account chip.
5. Failure and recovery: if the combination is not accepted, a single non-enumerating message states that the address and password combination was not accepted — it does not reveal which field was wrong. The password field is cleared and focused, the address is preserved, and the user may retry immediately.
6. Continuation: the user proceeds into the mailbox. If the session later expires while they are working, they are returned to Login with the address preserved.

Flow 3 — Mailbox User reads received mail

1. The signed-in user is on Mailbox, in the three-pane layout: folder rail, message list with tabular timestamps, reading pane.
2. They select a folder in the rail, then select a message in the list.
3. Observable result: the reading pane renders the message's sender, subject, timestamp, and body, and the message's unread marker clears.
4. Empty state: if no messages have arrived, the list states that no messages have arrived yet and offers Compose as the next step.
5. Failure and recovery: if the mailbox cannot be loaded, a ruled error row states the failure and offers a retry that re-requests the mailbox without losing the session.
6. Continuation: the user selects another message, or moves to Compose.

Flow 4 — Mailbox User composes and sends from the created address

1. The signed-in user opens Compose from the Mailbox or from the command bar (Cmd/Ctrl+K → Compose).
2. The From field shows the created address read-only in JetBrains Mono, so the user always knows which identity the message leaves from.
3. The user enters a recipient, a subject, and a body. Send is disabled until a recipient is present.
4. The user activates Send in the fixed footer action bar — the single tangerine primary action on the screen.
5. Observable result: the message is handed to the mail infrastructure with the created address as the sender, and the user returns to Mailbox with a confirmation that the message was sent.
6. Failure and recovery: an invalid recipient marks the recipient field with a specific message; a send failure shows a ruled error bar stating the message was not sent. In both cases the composed content is preserved intact and retry re-attempts the send with the same content — the draft is never silently discarded.
7. Continuation: the user returns to the Mailbox and may compose another message.

Flow 5 — Mailbox User returns later and finds the mailbox intact

1. The user signs in again through Login with the created address and password.
2. Observable result: Mailbox opens with the same address, the same folders, and the previously received messages intact, with their read/unread state preserved.
3. Continuation: the user resumes reading and sending from where they left off, with no further setup.

Flow 6 — Mailbox User copies the address and client settings

1. From Landing (anonymously) or from the Mailbox account chip (signed in), the user activates the copy control on the address.
2. Observable result: the address is placed on the clipboard and the control swaps to "Copied" for 1.2s without a toast.
3. From the Mailbox, the user opens the command bar (Cmd/Ctrl+K) and chooses Copy IMAP settings.
4. Observable result: the IMAP/SMTP settings are placed on the clipboard in the same way.
5. Failure and recovery: if the clipboard is unavailable, the value remains selectable in place so it can be copied manually.
6. Continuation: the user pastes the value into their mail client.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Rasmus Andersson, and the headline idea is an email address forge, not a SaaS landing page — systematic product craft with one hot accent, where the interface itself is the hero.

Mode. Dark mode is the primary and only specified mode.

Colour tokens by role.

Proportion: roughly 80% graphite field, 12% ink type, 5% tangerine, 3% acid green. No blue anywhere, no gradients, no glass. Tangerine carries exactly one job per screen — the primary CTA and the focused input ring. Acid green is reserved for success and availability states and is never used for buttons.

Typography.

• Headings: Space Grotesk, weights 500–700, tight tracking (−0.02em to −0.04em), sentence case for section heads, uppercase micro-labels at 11px with +0.14em tracking for field labels and panel eyebrows. Display sizes are large and flush-left, never centred.
• Body: Inter Tight.
• Addresses and data: JetBrains Mono at 600 — the generated address is the product, so it gets its own monospace voice. JetBrains Mono is reserved for addresses and data.
• Scale: 1.25 modular on a 4/8-pt rhythm — 96 / 72 / 48 / 32 / 22 / 17 / 15 / 13 / 11.
• Hero display: clamp(44px, 9vw, 112px). Section heads: clamp(28px, 4vw, 48px). Body: 15–17px at 1.55 line-height. Labels: 11px uppercase. Generated address: clamp(20px, 3.4vw, 40px) in JetBrains Mono.
• Tabular numerals (font-variant-numeric: tabular-nums) on the password strength score, character counts, quota, and message timestamps.

Shape language. Rectilinear and honest: 6px radii on inputs and buttons, 10px on panels, 1px hairline borders in muted-at-24%. No pill buttons except the single address-domain chip, which is a 4px-radius tag. No glass, no blur, no soft offset shadows — depth comes from a 1px border plus one step of surface lift (#141517 → #1C1E21), and from a 2px tangerine focus ring that sits outside the border rather than glowing.

Spacing rhythm. A 12-column grid on a 4/8-pt spacing scale, with a persistent 56px top bar carrying the wordmark, the current-account chip, and a keyboard-shortcut hint.

Imagery style. There is no photography. The imagery is the interface itself: the generated address rendered at display size in JetBrains Mono, a live password-strength meter with an explicit rule checklist, a schematic diagram of the address anatomy (local-part · @ · domain) with hairline callouts, and monospace code samples showing the SMTP/IMAP settings a user would paste into a mail client. A single small SVG "envelope-in-a-grid" mark is the only illustration, drawn on the same 8-pt grid with 1.5px strokes.

Layout behaviour. Landing is a two-thirds/one-third split: oversized flush-left display type on the left, the live address forge panel on the right. Sign Up and Login are single-column 480px forms centred in the left seven columns with a persistent right rail showing the live address preview. Mailbox is a three-pane power-user layout: 240px folder rail, 360px message list with tabular timestamps, flexible reading pane. Compose is a full-pane form with a fixed footer action bar. At 768px the right rail moves below the form; at 375px the mailbox becomes a single-pane stack with a folder drawer, and no label, value, button, or address ever wraps outside its container.

7. Signature Design Concept

The Address Forge. The public entry is built around one component that is simultaneously the product's explanation and its first working surface.

The first screen is a full-height graphite field (#141517) split 7/5. The left seven columns carry an oversized, flush-left, three-line headline in Space Grotesk at clamp(44px, 9vw, 112px) — "Pick a name. Pick a password. Get a working inbox." — with the second line indented one grid column and the final line set in tangerine #FF6A1F, stacked over a solid tangerine block that bleeds off the left viewport edge at 40% height. Beneath it, pinned to the baseline of the block, sits the primary CTA Create your address as a 6px-radius tangerine button with an ink label, and to its right a live monospace ticker of three example addresses scrolling left in JetBrains Mono at 15px.

The right five columns hold the forge panel (#1C1E21, 1px hairline border): a live, editable local-part input, an @-chip showing the domain, and a real-time rendered preview of the full address at clamp(20px, 3.4vw, 40px) in JetBrains Mono with a copy icon. Typing in the input drives the preview, the availability state, and the rule checklist at once. The availability state resolves from a three-dot monospace ellipsis to a checkmark in acid green #C6F24E or to a specific rule violation in tangerine. The copy control swaps to "Copied" for 1.2s without a toast.

The composition is type-as-architecture over a colour block, with the working product visible in the first viewport. No gradient, no blob, no centred stack, no stock photo. The forge recomposes only accepted content and controls: the local-part input, the domain, the address preview, the availability state, the rule checklist, and the copy control.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. The address forge panel and the full address it renders in JetBrains Mono at display size — the product's defining state, visible in the first viewport.
• Input → transformation → outcome thesis. The visitor types a local-part into the forge input; the panel transforms that input into a rendered full address, a resolved availability state, and a ticked rule checklist; the outcome is a copyable, real address the visitor can carry into Sign Up with one click.
• Motion vocabulary. Restrained and functional: 120–200ms transitions on cubic-bezier(0.2, 0, 0, 1) for focus rings, hover states, panel swaps, and copy confirmations. One purposeful loop only — the availability check shows a three-dot monospace ellipsis while it resolves, then snaps to a checkmark or a rule violation with no bounce. The password strength meter animates its bar width in 160ms and its score numeral ticks via tabular numerals rather than rolling digits. No parallax, no entrance choreography, no decorative motion.
• Composed first frame. Graphite field, flush-left three-line headline with the final line in tangerine over the bleeding tangerine block, the tangerine CTA pinned to the block's baseline, the monospace example-address ticker scrolling left beside it, and the forge panel on the right already rendering a preview address with its rule checklist visible.
• Reduced-motion state. prefers-reduced-motion replaces the availability ellipsis with a static "Checking…" label, makes all transitions instant, and stops the example-address ticker in place with its items wrapped into rows so each remains fully readable.

9. Non-Functional Requirements

NFR-1 — Immediate usability. The product must be usable end to end on first arrival: the address created must be the address that signs in, and the mailbox that opens must be the mailbox that persists. Provenance: explicit. Rationale: the user required a product that is "detailed and can be used immediately," not a mockup.

NFR-2 — Address rule precision. The address local-part rules (3–30 characters, a–z 0–9 . _ -, no leading or trailing dot) must be enforced and stated visibly, and the availability state must resolve before the address can be created. Provenance: required_inference. Rationale: the user must be able to trust that the address they typed is the address they got.

NFR-3 — Credential confidentiality. The password chosen at creation must be the credential that verifies the returning user, and a failed sign-in must not reveal which of the two fields was wrong. Provenance: required_inference. Rationale: the accepted returning-verification journey requires that the credential remain bound to the correct participant.

NFR-4 — Persistence. The created mailbox and its messages must persist across sessions so the user can return and continue, with read/unread state preserved. Provenance: required_inference. Rationale: the accepted requirement that the product be usable immediately implies a mailbox that is still there on the next visit.

NFR-5 — Input preservation on failure. Every failure path must preserve the user's entered values — the address field on a failed sign-in, the composed content on a failed send, the other field on a validation error — so no work is silently lost. Provenance: required_inference. Rationale: material failure and recovery must be usable without redoing accepted work.

NFR-6 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, and controls must 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). Rationale: the direction requires that readable text and controls stay whole at every viewport.

NFR-7 — Reduced motion. prefers-reduced-motion must be respected: the availability ellipsis becomes a static "Checking…" label, all transitions become instant, and the example-address ticker stops with its items wrapped into rows so each remains fully readable. Provenance: explicit (creative direction).

NFR-8 — No blue. No blue or indigo may appear in the primary or accent band. Provenance: explicit (creative direction). Rationale: the product's visual argument is a non-blue accent on graphite.

10. Tech Stack

• Frontend: React, delivered as a web application. [Default — not specified by user]
• Backend: Python with FastAPI, serving the address creation, verification, mailbox, and send endpoints. [Default — not specified by user]
• Storage: A relational database for accounts (address, password credential, created timestamp) and for mailbox messages (folder, sender, subject, received timestamp, body, read/unread state), plus a session store for authenticated sessions. [Default — not specified by user]
• Mail delivery: External mail infrastructure owns SMTP/IMAP delivery to and from external recipients; the product hands outgoing messages to it and receives incoming messages from it. The product exposes the IMAP/SMTP settings for the created address so the user can paste them into a mail client.
• Packaging: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required by any accepted requirement and is not included. [Default — not specified by user]

11. Assumptions and Constraints

Constraints (explicit).

• The email address name and the email password must both be user-customizable.
• The site must be detailed and immediately usable — working end to end, not a mockup.

Constraints (from the creative direction).

• Dark mode on a graphite ground with tangerine as the single hot accent and acid green reserved for success and availability.
• Space Grotesk for headings, Inter Tight for body, JetBrains Mono for addresses and data only.
• 6px radii on controls, 10px on panels, 1px hairline borders, no glass, no blur, no gradients.
• No blue or indigo in the primary or accent band.
• Motion is restrained, 120–200ms, with no parallax, no entrance choreography, and no decorative motion.

Assumptions.

• The domain portion of the created address is fixed by the product; only the local-part is user-customizable. [Default — not specified by user]
• The address local-part rules are 3–30 characters from a–z, 0–9, ., _, -, with no leading or trailing dot. [Default — not specified by user]
• The password requirements are stated explicitly in the Sign Up checklist and enforced at creation. [Default — not specified by user]
• The Mailbox and Compose surfaces require an established session; Landing, Sign Up, and Login are anonymously reachable. [Required inference from the accepted access contract]
• External recipients of sent mail are outbound-only and have no interface in this product.
• No account recovery, password reset, multi-address management, contact book, calendar, filtering rules, or administrative console is included; none was requested.

12. Glossary

• Address forge — the live panel on Landing where a visitor types a local-part and sees the full address, availability state, and rule checklist render in real time.
• Address name / local-part — the portion of an email address before the @, which the user customizes.
• Availability state — the resolved result of checking whether a chosen local-part can be used: checking, available, or a specific rule violation.
• Created address — the full email address produced by joining the user's chosen local-part to the product domain.
• Email Account Creator — the accepted persona who chooses an address name and password and creates the mailbox.
• Mailbox — the persistent store of received messages belonging to a created address, and the protected surface where those messages are read.
• Mailbox User — the accepted persona who operates the created mailbox: reading, composing, and sending.
• Password rule checklist — the explicit list of password requirements that tick green as the entered password satisfies each one.
• Rule checklist — the explicit list of address local-part rules that tick green as the entered name satisfies each one.
• Session — the established authenticated state that grants access to Mailbox and Compose after verification with the created address and password.
• Tabular numerals — the numeral rendering used for the password strength score, character counts, quota, and message timestamps so values read as an instrument readout.