System Requirements Document for abhi-jha

1. Introduction

abhi-jha is a small, deliberately scoped authentication product: a basic authentication form (login) plus a sign-up form, presented through a front door that explains itself. The product intent derived from the authoritative requirement thread is threefold:

1. Build a basic authentication form.
2. Build it with a sign-up form alongside it.
3. Give the user the roadmap of how the build will be done, presented as part of the product rather than as an off-product aside.

The audience is a single accepted human role, the Account Holder: a person who needs to get into the app through its front door. They create an account through the sign-up form and then log in through the authentication form. Their recurring responsibility is supplying their credentials and completing the form successfully; their successful outcome is being authenticated and admitted to the app.

The product is intentionally narrow. It is an authentication surface, not an application platform: no additional product capabilities were requested, and none are added here.

2. System Overview

abhi-jha is a first-party web application with application-owned identity and custom UI. It consists of three pages in a fixed order — Landing, Sign Up, Login — all reachable anonymously, because a protected destination cannot own the interaction that establishes access to itself.

Current delivery covers:

• An anonymous Landing page that states what the product is, presents the numbered roadmap of the build (01 ROADMAP / 02 SIGN UP / 03 LOGIN), and offers the two entry actions into account access.
• A Sign Up page where a visitor establishes an account by supplying an email and a password, sees their own input rendered back as data, and receives confirmation that the account exists.
• A Login page where a registered Account Holder supplies credentials, is verified, and is admitted to the app.

Actors:

• Account Holder (accepted human persona, closed set) — the only human actor.
• Authentication Service (non-persona system actor) — the backend that stores account records, verifies credentials, and issues the session credential.
• Session Credential (JWT) (non-persona artefact) — the token-shaped credential the service issues on successful sign-up and login.

Narrow exclusions: no password reset, no email verification delivery, no social or federated sign-in, no profile management, no role or permission differentiation, no administrative surface, and no post-login application content beyond admission. These are not requested and are not built.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. abhi-jha is delivered as a first-party web application with its own custom interface and its own backend integration. Identity is application-owned: the account record, the credential check, and the session credential all belong to this product, not to an external provider. There is no provider-owned sign-in surface and no external identity destination in the current scope.

Access ownership. All three pages are anonymously reachable. Landing is the public entry surface. Sign Up and Login are identity-access surfaces that must be reachable before identity exists — that is precisely their purpose — so neither is gated. After a successful sign-up or login, the Account Holder is admitted to the app; the admitted state is the product's terminal outcome in the current scope, and no further first-party destination is defined for it.

Current versus future. Current: the three pages above, the sign-up lifecycle, the login lifecycle, the roadmap presentation, and the session credential. Future (explicitly not current, not built, not accepted): password recovery, email verification, federated identity, account settings, and any application content behind the front door. These are recorded in Section 11 as horizon boundaries only.

Roadmap as product content. The user asked for the roadmap of how the build will be done, alongside the request to build it with a sign-up form. That roadmap is therefore rendered as first-class content on the Landing page — a numbered specification table, not marketing prose — and it is the only place the plan is presented.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source authority, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

Information and state. The product wordmark abhi-jha; a single uppercase micro-line reading SIGN UP · LOGIN · JWT; the numbered roadmap of the build; a live credential card that renders typed input as data; a JWT anatomy diagram. No account state is required to view this page.

Primary actions.

• Navigate to Sign Up (primary entry action).
• Navigate to Login (secondary entry action).

Supporting actions.

• Type into the credential card's email field to see the value rendered as a monospace string.
• Read the roadmap steps 01–03.

Domain entities. Roadmap step (index, title, deliverable, status); credential preview (email string, password length); JWT segment (header, payload, signature).

Component responsibilities.

• Wordmark block — abhi-jha set at display scale, flush-left, wrapping to two lines, spanning the viewport width without clipping.
• Micro-line — 12px uppercase mono, SIGN UP · LOGIN · JWT.
• Vertical numbered rail — 01 ROADMAP / 02 SIGN UP / 03 LOGIN, tabular numerals, tangerine, marking the three sections.
• Roadmap spec table — steps 01–03, each with a 2px tangerine left rule, a tabular index column, a mono deliverable column, and a hairline divider. This is the page's main content.
• Credential card panel — raised surface, hairline border, a real email field with a tangerine focus ring, and a mono token chip in lime showing eyJhbGciOiJIUzI1NiJ9….
• JWT anatomy diagram — three hairline-bordered segments (header / payload / signature) colour-coded ink, tangerine and lime; the signature segment is drawn as a dashed line until sign-up succeeds.
• Side-rail annotation — 12px uppercase mono printing the current route, HTTP method and payload shape in tabular alignment.

States.

• Loading — none; the page is static content plus local field state.
• Empty — credential card email field empty, showing placeholder in muted grey; token chip shows the truncated prefix only.
• Success — after a successful sign-up elsewhere in the session, the JWT signature segment renders as a solid line and the token chip reads as verified in lime.
• Error — none on this page; the page performs no submission.
• Recovery — not applicable; no failing operation originates here.

Sign Up

Information and state. Page heading; email field; password field; live credential readout; character meter; submit control; inline helper and error lines; side-rail annotation. Anonymous access.

Primary actions.

• Submit the sign-up form to create an account.

Supporting actions.

• Type an email; type a password; observe the live credential readout and character meter update.
• Navigate to Login if an account already exists.

Domain entities. Account (email, password credential); credential preview (email string, password length); session credential (JWT) issued on success.

Component responsibilities.

• Form column — max 420px, containing the fields and submit control.
• Email field — label, input, helper line, error line; 6px radius; hairline border; 2px tangerine focus ring.
• Password field — label, input, helper line, error line; same treatment.
• Live credential card — re-renders the typed email and password length as a monospace string with a lime character meter, so the form shows its own state as data.
• Submit control — tangerine primary button; disabled while a submission is in flight.
• Side-rail — persistent mono annotation of route, method and payload shape; folds under the form below 768px.
• Cross-link — "already have an account" link to Login.

States.

• Loading — submit control shows an in-flight state; fields remain readable and are not covered.
• Empty — both fields empty; helper lines visible in muted grey; credential readout shows an empty mono string and a zero-length meter.
• Success — account created; confirmation shown; the Account Holder is admitted and the session credential is issued.
• Error — field-level errors for missing or malformed email and for a password that does not meet the stated minimum; form-level error when the email is already registered; form-level error when the service is unreachable.
• Recovery — errors render as a helper line that slides open in 140ms beneath the offending field; the entered values are preserved so the Account Holder can correct and resubmit without retyping.

Login

Information and state. Page heading; email field; password field; submit control; inline helper and error lines; side-rail annotation. Anonymous access.

Primary actions.

• Submit the login form to verify credentials and be admitted.

Supporting actions.

• Type an email; type a password.
• Navigate to Sign Up if no account exists yet.

Domain entities. Account (email, password credential); session credential (JWT) issued on success.

Component responsibilities.

• Form column — max 420px, containing the fields and submit control.
• Email field and Password field — label, input, helper line, error line; 6px radius; hairline border; 2px tangerine focus ring; mono label flips from muted grey to ink on focus.
• Submit control — tangerine primary button; disabled while a submission is in flight.
• Side-rail — persistent mono annotation of route, method and payload shape; folds under the form below 768px.
• Cross-link — "need an account" link to Sign Up.

States.

• Loading — submit control shows an in-flight state; fields remain readable and are not covered.
• Empty — both fields empty; helper lines visible in muted grey.
• Success — credentials verified; the Account Holder is admitted and the session credential is issued.
• Error — field-level errors for missing email or password; form-level error for credentials that do not match an account; form-level error when the service is unreachable.
• Recovery — the error helper line slides open in 140ms; the email value is preserved and the password field is cleared and refocused so the Account Holder can retry immediately.

3. Functional Requirements

FR-1 — Basic authentication form (login). explicit As an Account Holder, I should be able to submit my email and password on a basic authentication form so that I am verified and admitted to the app.

• Trigger/input: the Account Holder opens Login and submits an email and password.
• Observable result: on success, the credentials are verified and the Account Holder is admitted with a session credential issued; on failure, an error is shown and the form remains usable.
• Access state: Login is anonymously reachable.
• Failure/recovery: missing fields produce field-level errors; non-matching credentials produce a form-level error; an unreachable service produces a form-level error. The email value is preserved and the password field is cleared and refocused for retry.
• Continuation: the Account Holder is admitted to the app, or corrects the input and resubmits.

FR-2 — Sign-up form alongside the login form. explicit As a visitor, I should be able to create an account through a sign-up form that sits alongside the login form so that I have credentials to log in with.

• Trigger/input: the visitor opens Sign Up and submits an email and a password.
• Observable result: on success, an account record exists and the Account Holder is admitted with a session credential issued; on failure, an error is shown and the form remains usable.
• Access state: Sign Up is anonymously reachable.
• Failure/recovery: missing or malformed email and an insufficient password produce field-level errors; an already-registered email produces a form-level error; an unreachable service produces a form-level error. Entered values are preserved so the Account Holder can correct and resubmit.
• Continuation: the Account Holder is admitted, or corrects the input and resubmits, or follows the cross-link to Login.

FR-3 — Roadmap of the build. explicit As an Account Holder, I should be able to read the roadmap of how the build is done so that I understand what the product consists of before I use it.

• Trigger/input: the Account Holder opens Landing.
• Observable result: a numbered roadmap of steps 01–03 is presented as a specification table with a tabular index column, a mono deliverable column, a 2px tangerine left rule per step, and hairline dividers.
• Access state: Landing is anonymously reachable.
• Failure/recovery: not applicable; the roadmap is static content with no failing operation.
• Continuation: the Account Holder follows the roadmap's numbered rail into Sign Up or Login.

FR-4 — Self-service account enrollment through Sign Up. required_inference As a visitor, I should be able to enroll myself without an invitation or an administrator so that the accepted sign-up journey is executable.

• Trigger/input: the visitor arrives at Sign Up from Landing or from the Login cross-link.
• Observable result: the visitor can complete enrollment unaided and becomes an Account Holder.
• Access state: anonymous; no prior identity required.
• Failure/recovery: as FR-2.
• Continuation: admission, or correction and resubmission.

FR-5 — Returning-user verification through Login. required_inference As an Account Holder, I should be able to verify myself on return so that my existing account is recognized and I am admitted again.

• Trigger/input: the Account Holder arrives at Login from Landing or from the Sign Up cross-link and submits credentials.
• Observable result: the existing account is recognized and the Account Holder is admitted.
• Access state: anonymous; the page itself is the entry boundary.
• Failure/recovery: as FR-1.
• Continuation: admission, or correction and resubmission.

FR-6 — Live credential readout on Sign Up. required_inference As a visitor, I should be able to see my typed email and password length rendered back as data while I fill the sign-up form so that I can confirm what I am about to submit.

• Trigger/input: the visitor types into the email or password field on Sign Up.
• Observable result: the credential card re-renders the typed email as a monospace string and shows a lime character meter for password length.
• Access state: anonymous.
• Failure/recovery: not applicable; the readout is local and cannot fail.
• Continuation: the visitor submits, or continues editing.

FR-7 — Session credential issuance. required_inference As an Account Holder, I should receive a session credential on successful sign-up or login so that my admitted state is bound to my account.

• Trigger/input: a successful sign-up or login submission.
• Observable result: a JWT-shaped session credential is issued and the Account Holder is admitted; the Landing page's JWT signature segment renders solid and the token chip reads as verified in lime.
• Access state: issued only after successful verification.
• Failure/recovery: if issuance fails, the Account Holder is not admitted and a form-level error is shown with the form preserved for retry.
• Continuation: the Account Holder proceeds into the app.

FR-8 — Anonymous entry to all three pages. required_inference As a visitor, I should be able to reach Landing, Sign Up and Login without already having an account so that the access-establishing interaction is not locked behind the access it establishes.

• Trigger/input: any first visit.
• Observable result: all three pages render fully without a prior session.
• Access state: anonymous on all three.
• Failure/recovery: not applicable.
• Continuation: the visitor chooses Sign Up or Login.

4. User Personas

Account Holder

Product context. The Account Holder is the only accepted human role in abhi-jha. They arrive at a product whose entire surface is a front door: a page that explains what the thing is, a form that creates an account, and a form that verifies one. They are not browsing a catalogue or managing a workspace — they are getting in.

Primary goal. To be authenticated and admitted to the app, with the least friction and the most honest feedback the interface can give them.

Distinct accepted responsibilities.

• Reading the roadmap on Landing to understand what the product consists of before committing to it.
• Creating an account through the sign-up form by supplying an email and a password.
• Supplying credentials on the login form and completing it successfully.
• Correcting their own input when validation or verification fails, using the preserved values and the error helper lines.

Relevant inputs and decisions.

• Inputs: an email address; a password; the choice between Sign Up and Login.
• Decisions: whether they already have an account (Login) or need one (Sign Up); whether to correct a rejected field or abandon the attempt.

Interactions with other accepted participants. The Account Holder has no human counterparty in this product. Their only counterparty is the Authentication Service, which stores the account record, verifies the credential, and issues the session credential. The Account Holder's observable side of that interaction is the confirmation on success and the error line on failure; the service's side is the account record and the issued token.

Observable success. The Account Holder is admitted to the app with a session credential issued, and — on Landing — sees the JWT signature segment render solid and the token chip read as verified in lime.

What makes this role distinct. The Account Holder's work is credential work: it is entirely composed of typing into fields, reading validation states, and interpreting a token. They are treated as someone who knows what a JWT is and who will judge the form by its focus rings, its error copy and its tabular numerals. That is why the interface shows them their own input as data rather than hiding it behind a spinner, and why the roadmap is rendered as a specification table rather than as reassurance copy.

5. Core User Flows

Flow A — Visitor reads the roadmap and chooses an entry point

1. The visitor arrives at Landing with no account and no session. The page renders anonymously: the abhi-jha wordmark at display scale, the micro-line SIGN UP · LOGIN · JWT, and the vertical numbered rail 01 ROADMAP / 02 SIGN UP / 03 LOGIN.
2. The visitor reads the roadmap spec table: steps 01–03, each with a 2px tangerine left rule, a tabular index column, a mono deliverable column, and a hairline divider. The roadmap steps reveal in 60ms sequence with their left rules drawing downward; with prefers-reduced-motion they snap instantly to their end state.
3. The visitor inspects the credential card on the right, which is bled to the viewport edge. They type an email into its field; the tangerine focus ring lights and the typed value re-renders as a monospace string. The token chip shows eyJhbGciOiJIUzI1NiJ9… in lime, and the JWT anatomy diagram shows its signature segment as a dashed line because no account exists yet.
4. The visitor decides: they have no account, so they follow the rail to Sign Up. Observable result: the Sign Up page renders. Next step: Flow B.

Flow B — Visitor creates an account through Sign Up

1. The visitor arrives at Sign Up anonymously. The form column (max 420px) shows an email field and a password field; the side-rail prints the route, HTTP method and payload shape in tabular alignment.
2. The visitor types an email. The live credential card re-renders the typed email as a monospace string. The field's mono label flips from muted grey to ink and a 2px tangerine ring appears — no glow, no shadow, no scale.
3. The visitor types a password. The character meter fills in lime and the password length appears as a tabular numeral beside it. The form is now showing its own state as data.
4. The visitor submits. The submit control enters its in-flight state; the fields remain readable and are not covered.
5. Failure branch. If the email is malformed, the password is below the stated minimum, or the email is already registered, the helper line beneath the offending field slides open in 140ms with the error copy. The entered values are preserved. The visitor corrects the field and resubmits from step 4. If the service is unreachable, a form-level error appears and the same recovery applies.
6. Success. The account is created, the session credential is issued, and the Account Holder is admitted to the app. Observable result: confirmation on Sign Up, and — back on Landing — the JWT signature segment now renders as a solid line and the token chip reads as verified in lime. Next step: the Account Holder is inside the app; on a later visit they begin at Flow C.

Flow C — Account Holder logs in on return

1. The Account Holder arrives at Login anonymously, either from Landing or from the Sign Up cross-link. The form column shows an email field and a password field; the side-rail prints the route, method and payload shape.
2. The Account Holder types their email and password. Focus rings light in tangerine; labels flip from muted grey to ink.
3. The Account Holder submits. The submit control enters its in-flight state.
4. Failure branch. If a field is empty, a field-level error appears. If the credentials do not match an account, a form-level error appears. In both cases the error helper line slides open in 140ms, the email value is preserved, and the password field is cleared and refocused so the Account Holder can retry immediately from step 2. If the service is unreachable, a form-level error appears with the same recovery.
5. Success. The credentials are verified, the session credential is issued, and the Account Holder is admitted to the app. Observable result: admission, plus the verified token state reflected on Landing. Next step: the Account Holder is inside the app.

Flow D — Visitor with an account is redirected to the right form

1. A visitor arrives at Sign Up but realizes they already have an account.
2. They follow the cross-link to Login. Observable result: the Login page renders with the same two-pane layout and side-rail. Next step: Flow C from step 2.

Flow E — Visitor without an account is redirected to the right form

1. A visitor arrives at Login but has no account.
2. They follow the cross-link to Sign Up. Observable result: the Sign Up page renders with the live credential card. Next step: Flow B from step 2.

6. Visuals, Colors and Theme

Muse and headline. Rasmus Andersson. The read is a developer-flavoured authentication product — login plus sign-up, JWT-shaped credentials — built for one Account Holder who wants a front door that feels engineered rather than marketed. The register is not "welcome to our brand"; it is "this was built by someone who cares about the machine." The roadmap the user explicitly asked for is rendered as a numbered, tabular, schematically honest artefact rather than marketing prose.

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

Colour tokens by role.

No blue or indigo appears anywhere in the system.

Typography.

• Headings: Space Grotesk 500/600, tracking −0.02em to −0.04em, sentence case for section heads and uppercase for micro-labels. The landing wordmark is set at enormous scale so abhi-jha reads as an object, not a logo lockup.
• Body and form labels: Inter Tight 400/500 at 15–17px with generous line-height.
• Field values and credential strings: JetBrains Mono, so a JWT actually looks like a JWT.
• Scale: 1.25 modular on a 4/8pt base — 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49 / 61 / 76 / 96. Landing display clamp(48px, 11vw, 120px); page H1 clamp(32px, 5vw, 52px); section H2 clamp(22px, 3vw, 31px); body 16–17px; micro-label 12px uppercase at 0.12em tracking. Tabular numerals everywhere numbers appear.

Shape language. Compact, machined rectangles: 6px radii on inputs and buttons, 10px on panels, 999px only on status chips. 1px hairline borders in rgba(242,239,233,0.10) on the graphite ground. A 2px tangerine ring on focus — never a soft glow. A 2px left rule as the accent mark on numbered roadmap steps. No soft shadows for depth; depth comes from surface value steps (#141517 → #1C1E21 → #24262A) and hairlines.

Spacing rhythm. Everything on the 8pt scale. A strict 12-column grid at 1280px, 8 at 768px, 4 at 375px.

Layout. The landing page is an asymmetric editorial split: a giant stacked wordmark and a numbered roadmap column on the left seven columns, and a live credential card panel occupying the right five, bled to the viewport edge. Auth pages use a two-pane layout — a narrow form column (max 420px) with a persistent mono side-rail showing route, method and payload shape — collapsing to a single column with the rail folding under the form at 768px and 375px. Every number in the roadmap, every field index and every character counter is tabular-aligned in its own column.

Imagery style. No photography, no illustration, no 3D. The imagery is the interface itself: a live credential card that renders the typed email as a mono string; a JWT anatomy diagram drawn with hairlines and three colour-coded segments (header / payload / signature) in ink, tangerine and lime; schematic line diagrams for the sign-up → verify → login flow. Any decoration is a diagram that carries information.

Readable-text integrity. Headlines, the wordmark, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit. No element covers any part of them. Decoration and diagrams may bleed off an edge; readable text and controls may not.

7. Signature Design Concept

The machine face. The first screen is not a centred headline with a button. It is a full-bleed graphite field (#141517) composed as an asymmetric editorial split, and it is the product's defining statement: this is a tool, not a landing page.

• Left seven columns. The wordmark abhi-jha set in Space Grotesk at clamp(48px, 11vw, 120px), flush-left, tight leading, wrapping to two lines so it spans the viewport width. Directly beneath it, a single 12px uppercase mono line reads SIGN UP · LOGIN · JWT. Down the left edge, a vertical numbered rail — 01 ROADMAP / 02 SIGN UP / 03 LOGIN — marks the three sections, each number tabular and tangerine.
• The roadmap as the main content. Beneath the wordmark, the roadmap renders as a numbered spec table rather than a bullet list: steps 01–03, each with a 2px tangerine left rule, a tabular index column, a mono deliverable column, and a hairline divider. The plan the user asked for is the landing page's primary content.
• Right five columns, bled to the viewport edge. A raised #1C1E21 credential panel with a hairline border, a real email field with a tangerine focus ring already lit, and a mono eyJhbGciOiJIUzI1NiJ9… token chip in lime. Below it, the JWT anatomy diagram: three hairline-bordered segments — header, payload, signature — colour-coded ink, tangerine and lime, with the signature segment drawn as a dashed line until sign-up succeeds.
• The side-rail annotation. A 12px uppercase mono rail prints the current route, HTTP method and payload shape in tabular alignment — a permanently visible annotation of what this page does to the backend.

Nothing is centred; nothing floats. The composition is a machine face, not a marketing page. Every element in it is either accepted content, an accepted control, or a diagram of accepted state.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. The abhi-jha wordmark and the numbered roadmap spec table on the left, with the live credential card and JWT anatomy diagram on the right.
• Input → transformation → outcome thesis. The visitor's typed email enters the credential card's field; the card transforms that input into a rendered monospace string and a lime character meter; the outcome is that the form shows its own state as data before anything is submitted. The JWT anatomy diagram's signature segment stays dashed until a sign-up succeeds, at which point it becomes solid — the diagram's state is the product's state.
• Motion vocabulary. Fast and functional: 120–200ms cubic-bezier(0.2, 0, 0, 1) on focus rings, label float, chip and button states. One purposeful entrance — the roadmap steps reveal in 60ms sequence with their left rules drawing downward. Nothing else loops. Field validation slides its helper line open in 140ms.
• Composed first frame. Full-bleed graphite. The wordmark flush-left at display scale, wrapping to two lines. The micro-line beneath it. The numbered rail down the left edge. The roadmap spec table with its tangerine left rules. The credential panel bled off the right edge with its focus ring already lit and its lime token chip visible. The JWT diagram with a dashed signature segment.
• Reduced-motion state. With prefers-reduced-motion, everything snaps instantly to its end state: the roadmap steps appear fully drawn with no sequence, the helper line opens without sliding, and focus rings and chip states change without transition.

9. Non-Functional Requirements

NFR-1 — Anonymous reachability of all three pages. required_inference Landing, Sign Up and Login must all render fully without a prior session. Rationale: a protected destination cannot own the interaction that establishes access to itself, and the accepted sign-up and login journeys both begin before identity exists.

NFR-2 — Credential confidentiality. required_inference Passwords must never be rendered back into the interface, logged, or displayed in the credential readout. The live credential card shows the email string and the password length only. Rationale: the accepted live-readout behaviour must not become a credential disclosure.

NFR-3 — Form state preservation on failure. explicit (derived from the accepted error/recovery behaviour) On a failed submission, entered values must be preserved so the Account Holder can correct and resubmit without retyping — except the password field on a failed login, which is cleared and refocused.

NFR-4 — Readable-text integrity at all target viewports. explicit (user design constraint) Headlines, the wordmark, labels, numbers, card text 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.

NFR-5 — Reduced-motion compliance. explicit (user design constraint) With prefers-reduced-motion, all motion snaps instantly to its end state.

NFR-6 — Contrast. explicit (user design constraint) Body and label text at #F2EFE9 on #141517 holds ~15:1; muted text at #8A8F98 holds 4.5:1 or better on the graphite ground.

NFR-7 — Keyboard-native focus treatment. explicit (user design constraint) Focus is a 2px tangerine ring plus a mono label that flips from muted grey to ink — no glow, no shadow, no scale.

NFR-8 — Backend integration for identity. required_inference Account records, credential verification and session-credential issuance are backend responsibilities; the front end must not treat a client-side check as authentication.

10. Tech Stack

• Frontend: React, with the three pages (Landing, Sign Up, Login) as first-party custom UI.
• Backend: Python / FastAPI, providing account creation, credential verification, and session-credential (JWT) issuance.
• Storage: a persistent store for account records (email and password credential), sufficient for the accepted sign-up and login lifecycles.
• Containerization: Docker and docker-compose for local and single-host operation.
• Kubernetes: not required by any accepted requirement; omitted.

No source-specified technology was overridden. Where the source did not specify, the choices above are the minimal set needed to deliver the accepted behaviour.

11. Assumptions and Constraints

Constraints (binding).

• C-1. Scope is a basic authentication form; no additional product capabilities were requested. explicit
• C-2. The page contract is fixed and ordered: Landing, Sign Up, Login. No page is added, removed, merged, split, renamed, reordered, or given different access. explicit
• C-3. The active human persona catalog is closed at exactly one role: Account Holder. No additional personas are created. explicit
• C-4. The generic indigo/blue-on-white SaaS template is forbidden for this project. explicit
• C-5. No blue or indigo anywhere in the system; lime is reserved for success and verified-token states and is never the primary CTA. explicit
• C-6. No photography, illustration, or 3D imagery; decoration must be a diagram that carries information. explicit

Assumptions (narrow, labeled).

• A-1. [Default — not specified by user] The password minimum length and email format rules are enforced as field-level validation; the exact thresholds are implementation defaults, not user-specified values.
• A-2. [Default — not specified by user] The session credential is a JWT signed with a server-held secret, consistent with the JWT-shaped credential the design direction depicts.
• A-3. [Default — not specified by user] "Admitted to the app" is the terminal observable outcome of the current scope; no post-login application content is defined.
• A-4. [Default — not specified by user] The roadmap's three steps (01 ROADMAP / 02 SIGN UP / 03 LOGIN) are the roadmap content, matching the accepted page contract.

Future horizon (explicitly not current; not built, not accepted, not reachable).

• Password recovery and reset.
• Email verification delivery.
• Federated or social sign-in.
• Account settings and profile management.
• Role-based or permission-differentiated access.
• Any application content behind the front door.

12. Glossary

• Account Holder — the single accepted human persona; the person who creates an account via Sign Up and logs in via Login.
• Authentication form — the login form on the Login page; the basic authentication form the user asked for.
• Sign-up form — the account-creation form on the Sign Up page, built alongside the authentication form.
• Roadmap — the numbered specification table on Landing (steps 01–03) presenting how the build is done.
• Credential card — the live panel on Landing and Sign Up that re-renders typed input as a monospace string with a lime character meter.
• JWT (JSON Web Token) — the token-shaped session credential issued on successful sign-up or login; depicted on Landing as a three-segment anatomy diagram (header / payload / signature).
• Session credential — the issued token that binds an admitted state to an account.
• Authentication Service — the non-persona backend actor that stores account records, verifies credentials, and issues the session credential.
• Side-rail — the persistent 12px uppercase mono annotation printing the current route, HTTP method and payload shape.
• Admission — the observable outcome of a successful sign-up or login: the Account Holder is inside the app with a session credential issued.