System Requirements Document for fierce-help

1. Introduction

fierce-help is a self-service website builder for one person who wants a small, personal site of their own — and wants to keep it alive. The product intent, derived from the authoritative requirement thread ("can you help me create a website"), is to let a single owner define what their website contains, publish it, and maintain it over time, while anonymous visitors can reach and read the published result.

The audience is therefore two-sided but asymmetric:

• The Site Owner — the person who asked for help creating a website. They are the author, editor, and maintainer. Their work is recurring: deciding what the site says, writing it, publishing it, and updating it as needs change.
• The Site Visitor — anyone who arrives at the published site. Their work is reading: they browse the owner's published content and leave having found what the owner published.

The product is deliberately small. It is a desk, not a dashboard: a place to write, a place to see what you have written and whether it is live, and a public face that presents that writing to the world.

2. System Overview

fierce-help is a first-party web application with application-owned identity and custom UI. It delivers:

• A public Landing page that presents the site and its published content to anonymous visitors.
• Anonymous Sign Up and Login surfaces through which the Site Owner establishes and re-establishes their own identity.
• A protected Content page giving the Site Owner a revisitable overview of the site's content items and their publication state.
• A protected Content Editor page giving the Site Owner a focused writing and editing workspace whose result is reflected on the published site.

Actors. The accepted active-human catalog is closed and consists of exactly two personas: Site Owner and Site Visitor. No other human roles are introduced. The application itself, its storage layer, and its publication pipeline are non-persona system actors; they execute work but are not personas and are not given pages.

Accepted behavior. The Site Owner can enroll themselves, verify themselves on return, see an overview of their content and each item's publication state, open an item into a focused editor, write and edit it, and publish it so that the Landing page reflects their intent. The Site Visitor can reach the Landing page without any account and read the published content.

Ownership. All five destinations are application-owned custom pages. Identity is application-owned: the Site Owner's content and publication state must remain bound to the correct person across sessions, so first-use enrollment and returning verification are part of the accepted lifecycle. There is no third-party identity provider, no external publishing destination, and no headless delivery in the current horizon.

Narrow exclusions. This document does not introduce multi-author collaboration, comment systems, analytics dashboards, e-commerce, newsletters, custom domains, theming marketplaces, media libraries, or any adjacent website-builder capability. None of these were requested, and none are required to make the accepted journeys executable.

2a. Product Interpretation and Delivery Boundary

Delivery. fierce-help is delivered as a first-party web application with its own custom interface and its own backend. The Site Owner's writing, the content items they create, and each item's publication state are stored durably by the application so that the owner can leave and return without losing work, and so that the published site stays live between visits. Publication is application-owned: when the owner publishes, the application makes that content available on the public Landing page. There is no external publishing service, no provider-owned authoring surface, and no headless/API-only delivery in the current scope.

Access. The public face of the product — the Landing page — is reachable by anyone, with no account and no sign-in. The authoring face — the Content overview and the Content Editor — is reachable only by the verified Site Owner, because the content and its publication state are durable, owner-specific, and must remain bound to the correct person. Sign Up and Login are themselves anonymously reachable: a person who has no account yet cannot be required to already be signed in to create one, and a person who has forgotten their session cannot be required to already have a session to restore it. Protected state is never exposed on those two surfaces; they establish or restore access, they do not grant access to content before it is established.

Current vs. future. Everything described in this document is current. No future-horizon requirements were accepted in the authoritative thread; Section 11 records the boundaries that keep the current scope narrow rather than promising later work.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source authority, so no source content inventory is produced. All product facts in this document derive from the authoritative user requirement thread and the accepted Planning Scope.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract for this generation. Each page appears exactly once.

Landing

• Purpose and access. The public entry surface. Reachable by anyone, including anonymous visitors, with no account and no sign-in. It is the only surface on which the site's published content is presented to the public.
• Information and state. The site's identity and purpose expressed as an essay opening; the published content items the Site Owner has made live; a live-status indicator reflecting that the site is published; the current publication state of the site as a whole.
• Primary actions. Read the published content; follow a content item into its full reading view; begin building by proceeding to Sign Up; proceed to Login if already enrolled.
• Supporting actions. Navigate between published sections; return to the top of the page.
• Domain entities. Published content item (title, body, publication state); site publication state.
• Component responsibilities.
  • Essay-opening hero — oversized headline, lede paragraph, and the primary "Start building" action, with an inline flat illustration bleeding off the right edge.
  • Hairline section rules — full-width rules carrying a small numbered label in the leftmost column, separating published sections.
  • Published content list — the owner's live items rendered as readable entries, each linking to its full reading view.
  • Live-status marker — a small teal dot with its label, indicating the site is published.
  • Entry actions — "Start building" (to Sign Up) and a quieter "Log in" link (to Login).
• States.
  • Loading — the hero renders immediately; the published content region shows a restrained placeholder while content is fetched.
  • Empty — when the owner has published nothing yet, the page presents the site's purpose and the entry actions, with a short, honest note that nothing has been published yet. No fabricated content is shown.
  • Success — published items render in reading order with their titles and bodies.
  • Error — if published content cannot be loaded, the page keeps the hero and entry actions intact and shows a plain message that the content could not be loaded, with a retry action.
  • Recovery — retry re-requests the published content without losing the visitor's place; the hero and entry actions remain usable throughout.

Sign Up

• Purpose and access. The first-use enrollment surface for the Site Owner. Reachable anonymously; it establishes identity and does not expose any protected content state.
• Information and state. The enrollment form; inline validation state per field; submission state; the outcome of enrollment.
• Primary actions. Submit enrollment details to create the owner's identity; proceed to Login if already enrolled.
• Supporting actions. Correct a field after a validation error; return to Landing.
• Domain entities. Owner identity (identifier and credential); enrollment attempt.
• Component responsibilities.
  • Enrollment form — the fields required to establish the owner's identity, with labels and inline error text.
  • Submit control — disabled while a submission is in flight, with a visible in-progress state.
  • Cross-link — a link to Login for people who already have an identity.
  • Outcome region — where success or failure is reported in plain language.
• States.
  • Loading — the form renders immediately; submission shows an in-progress state on the submit control.
  • Empty — the initial state: empty fields, no errors shown.
  • Success — enrollment succeeds and the owner is taken into the protected authoring experience, with their new identity in effect.
  • Error — field-level validation errors appear inline next to the offending field; a submission failure (for example, the identifier is already in use, or the service is unreachable) is reported in the outcome region with the form's entered values preserved so nothing must be retyped.
  • Recovery — the owner can correct the field or retry submission directly from the same page; no protected state is reachable until enrollment actually succeeds.

Login

• Purpose and access. The returning-verification surface for the Site Owner. Reachable anonymously; it restores access and does not expose any protected content state.
• Information and state. The verification form; inline validation state; submission state; the outcome of verification.
• Primary actions. Submit credentials to verify the returning owner; proceed to Sign Up if not yet enrolled.
• Supporting actions. Correct a field after a validation error; return to Landing.
• Domain entities. Owner identity (identifier and credential); verification attempt.
• Component responsibilities.
  • Verification form — the fields required to verify the returning owner, with labels and inline error text.
  • Submit control — disabled while a submission is in flight, with a visible in-progress state.
  • Cross-link — a link to Sign Up for people who have no identity yet.
  • Outcome region — where success or failure is reported in plain language.
• States.
  • Loading — the form renders immediately; submission shows an in-progress state on the submit control.
  • Empty — the initial state: empty fields, no errors shown.
  • Success — verification succeeds and the owner is taken into the protected authoring experience with their content and publication state intact.
  • Error — field-level validation errors appear inline; a verification failure is reported in the outcome region without revealing whether the identifier or the credential was wrong, and the entered identifier is preserved.
  • Recovery — the owner can retry directly from the same page, or follow the cross-link to Sign Up; no protected state is reachable until verification actually succeeds.

Content

• Purpose and access. The Site Owner's protected overview of the site's content and its publication state. Reachable only by the verified Site Owner.
• Information and state. The owner's content items, each with its title and its publication state (draft or published); the site's overall publication state; the count and ordering of items.
• Primary actions. Open an existing item into the Content Editor; create a new content item and open it into the Content Editor; publish or unpublish an item; return to the public Landing page to see the published result.
• Supporting actions. Reorder or scan the list; refresh the overview; sign out.
• Domain entities. Content item (title, body, publication state, last-modified time); site publication state.
• Component responsibilities.
  • Content rail — the list of content items, each rendered as an index card with a hand-drawn underline and a state dot (rust for draft, teal for published). On mobile this collapses to a horizontally scrollable strip of item chips above the editor.
  • Item state marker — the draft/published dot and its label on each card.
  • New-item control — creates a new content item and opens it in the Content Editor.
  • Publish control — per item, toggles that item between draft and published.
  • Overview header — the site's overall publication state and the entry point back to the public Landing page.
  • Empty-state art — a flat, hand-drawn illustration shown when the owner has no content items yet.
• States.
  • Loading — the rail shows restrained placeholders while items are fetched.
  • Empty — no content items yet: the empty-state illustration, a short explanation, and the new-item control as the clear next step.
  • Success — items render in order with their titles and state dots; a publish or unpublish action updates the item's dot and label immediately.
  • Error — if items cannot be loaded, the page reports it plainly with a retry action; if a publish or unpublish action fails, the item's state reverts to its previous value and the failure is reported next to that item.
  • Recovery — retry reloads the overview; a failed publish can be retried on the same item without leaving the page.

Content Editor

• Purpose and access. The Site Owner's protected, focused writing and editing workspace. Reachable only by the verified Site Owner, and reached from the Content overview for a specific item.
• Information and state. The selected content item's title and body; its current publication state; its save state (saved, unsaved changes, saving, save failed); its last-modified time.
• Primary actions. Write and edit the item's title and body; save the item; publish or unpublish the item; return to the Content overview.
• Supporting actions. Discard unsaved changes; leave the editor with a warning when there are unsaved changes.
• Domain entities. Content item (title, body, publication state, last-modified time); save operation.
• Component responsibilities.
  • Editor pane — the title field and the body writing surface, held to the same reading measure as the public page so writing feels like writing.
  • Save control and save-state indicator — reports saved, unsaved, saving, and save-failed states truthfully.
  • Publish control — toggles the item between draft and published, with the same rust/teal state language used on the Content overview.
  • Back control — returns to the Content overview.
  • Unsaved-changes guard — warns before leaving with unsaved changes.
• States.
  • Loading — the editor shows a restrained placeholder while the item is fetched.
  • Empty — a newly created item opens with an empty title and body and a clear prompt to begin writing.
  • Success — saving confirms visibly; publishing updates the item's state and makes the content available on the Landing page.
  • Error — a failed save is reported plainly with the owner's text preserved in the editor and a retry action; a failed publish leaves the item's previous publication state intact and reports the failure.
  • Recovery — retry save or retry publish directly from the editor; the owner's unsaved text is never silently discarded.

3. Functional Requirements

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

FR-1 — Create a website. As a Site Owner, I should be able to create a website of my own so that I have a place to publish what I want to say.

• Provenance: explicit.
• Actor: Site Owner.
• Trigger/input: the owner's decision to begin, entered from the Landing page.
• Observable result: the owner has a website with a public address, an authoring workspace, and durable storage for its content.
• Access state: the public face is anonymous; the authoring workspace requires the owner's verified identity.
• Failure/recovery: if the site cannot be created or loaded, the owner is told plainly and can retry without losing entered information.
• Continuation: the owner proceeds to define content (FR-5, FR-6) and publish it (FR-7).

FR-2 — Self-service enrollment for the Site Owner. As a Site Owner, I should be able to enroll myself so that I can begin creating and maintaining my website without waiting on anyone else.

• Provenance: required_inference (required to make the accepted current journey executable).
• Actor: Site Owner, acting anonymously on the Sign Up page.
• Trigger/input: the owner submits their enrollment details.
• Observable result: the owner's identity exists and is in effect; the owner is taken into the protected authoring experience.
• Access state: Sign Up is anonymously reachable and exposes no protected content state.
• Failure/recovery: field-level validation errors appear inline; a submission failure (identifier already in use, service unreachable) is reported with entered values preserved and the form immediately retryable.
• Continuation: the owner proceeds to the Content overview to create their first content item.

FR-3 — Returning verification for the Site Owner. As a Site Owner, I should be able to verify myself on return so that I can get back to my content and its publication state.

• Provenance: required_inference (required to make the accepted current journey executable).
• Actor: Site Owner, acting anonymously on the Login page.
• Trigger/input: the owner submits their credentials.
• Observable result: the owner's identity is verified and their own content and publication state are available to them again.
• Access state: Login is anonymously reachable and exposes no protected content state; protected destinations remain unavailable until verification succeeds.
• Failure/recovery: a verification failure is reported without disclosing which field was wrong; the entered identifier is preserved and the owner can retry or cross over to Sign Up.
• Continuation: the owner proceeds to the Content overview.

FR-4 — Durable storage and publication continuity for the site's content. As a Site Owner, I should be able to leave and come back without losing my work or taking my site offline, so that keeping the site alive is not a chore.

• Provenance: required_inference (required to make the accepted current journey executable).
• Actor: Site Owner (initiating and observing); the application stores and serves.
• Trigger/input: the owner saves an item, publishes an item, or leaves the application.
• Observable result: saved content persists across sessions; published content remains available on the Landing page between the owner's visits.
• Access state: stored content is bound to the owner's identity; the published projection is anonymously readable.
• Failure/recovery: a failed save or publish is reported to the owner with their text preserved and a retry available; the item's previous publication state is not silently changed.
• Continuation: the owner resumes editing or publishing from the Content overview.

FR-5 — Overview of content and publication state. As a Site Owner, I should be able to see all of my content items and whether each one is a draft or published, so that I always know what my site currently says.

• Provenance: required_inference (required to make the accepted current journey executable).
• Actor: Site Owner, on the protected Content page.
• Trigger/input: the owner opens the Content overview, or returns to it after editing.
• Observable result: every content item is listed with its title and a draft (rust) or published (teal) state marker; the site's overall publication state is visible.
• Access state: protected; reachable only by the verified Site Owner.
• Failure/recovery: if items cannot be loaded, the page reports it plainly with a retry; a failed publish/unpublish reverts the item's marker and reports the failure next to that item.
• Continuation: the owner opens an item into the Content Editor, or creates a new one.

FR-6 — Focused writing and editing. As a Site Owner, I should be able to write and edit a content item in a focused workspace, so that what I publish reflects my intent.

• Provenance: required_inference (required to make the accepted current journey executable).
• Actor: Site Owner, on the protected Content Editor page.
• Trigger/input: the owner opens an existing item or creates a new one from the Content overview, then edits its title and body.
• Observable result: the item's title and body are updated and saved; the save state is reported truthfully (saved, unsaved, saving, save failed).
• Access state: protected; reachable only by the verified Site Owner, for an item bound to that owner.
• Failure/recovery: a failed save is reported with the owner's text preserved in the editor and a retry available; leaving with unsaved changes triggers a warning rather than silent loss.
• Continuation: the owner saves, then publishes (FR-7), or returns to the Content overview.

FR-7 — Publishing content to the public site. As a Site Owner, I should be able to publish a content item so that visitors can read it on my website.

• Provenance: required_inference (required to make the accepted current journey executable).
• Actor: Site Owner (initiating); Site Visitor (observing the result).
• Trigger/input: the owner publishes an item from the Content Editor or the Content overview.
• Observable result: the item's state becomes published (teal marker) and its content becomes readable on the public Landing page; unpublishing returns it to draft and removes it from the public page.
• Access state: the publishing action is protected; the published result is anonymously readable.
• Failure/recovery: a failed publish leaves the item's previous publication state intact and reports the failure with a retry; the owner is never told an item is live when it is not.
• Continuation: the owner returns to the Content overview, or opens the Landing page to see the published result.

FR-8 — Reading the published site. As a Site Visitor, I should be able to reach the website and read what the owner published, without creating an account.

• Provenance: required_inference (required to make the accepted current journey executable).
• Actor: Site Visitor, on the anonymous Landing page.
• Trigger/input: the visitor arrives at the site's public address.
• Observable result: the site's purpose and its published content items are presented and readable; the visitor can follow an item into its full reading view.
• Access state: anonymous; no account, no sign-in, no protected state exposed.
• Failure/recovery: if published content cannot be loaded, the page keeps its identity and entry actions intact and offers a retry.
• Continuation: the visitor reads further items, or leaves having found what the owner published.

4. User Personas

Site Owner

Product context. The Site Owner is the person who asked for help creating a website. They are a single, self-starting individual — not a team, not an organization with a content department. They came to fierce-help because they want a small, personal site of their own and they want to keep it alive, not because they want to operate a publishing platform.

Primary goal. To have a working website that says what they want it to say, and to be able to change it whenever their needs change.

Distinct accepted responsibilities. The Site Owner is the only persona who authors. They enroll themselves (FR-2), verify themselves on return (FR-3), see an overview of their content and each item's publication state (FR-5), write and edit items in a focused workspace (FR-6), and decide what is live by publishing or unpublishing (FR-7). They also depend on durable storage so their work survives between visits and their site stays up (FR-4).

Relevant inputs and decisions. Their inputs are the title and body of each content item. Their decisions are: what the site contains, which items exist, and — the consequential one — whether a given item is a draft or published. That draft/published decision is the moment their private writing becomes public reading.

Interactions with other accepted participants. The Site Owner does not interact with the Site Visitor directly, and the product does not give them a channel to do so. The relationship is one-directional and mediated entirely by publication state: when the owner publishes an item, the Site Visitor can read it; when the owner unpublishes it, the visitor can no longer find it. The owner's observable success is therefore partly indirect — they confirm it by opening the public Landing page and seeing their own published content there.

Observable success. The owner can sign up, sign back in, see their items with correct draft/published markers, edit and save an item without losing text, publish it, and then see that same content readable on the public Landing page.

What makes this role different. The Site Owner is the only actor with durable, owner-bound state and the only actor who makes publication decisions. Their work is recurring and cumulative — every session adds to or revises a body of content that persists. A visitor's work is a single, stateless reading pass with nothing to resume.

Site Visitor

Product context. The Site Visitor is anyone who arrives at the published website. They have no relationship with fierce-help as a product, no account, and no awareness that an authoring tool exists behind the page they are reading. They arrived because someone shared a link, or because they searched for something the owner wrote about.

Primary goal. To read what the Site Owner published and find the information they came for.

Distinct accepted responsibilities. The Site Visitor has exactly one accepted responsibility: reach the site and read its published content (FR-8). They browse the published items presented on the Landing page and follow an item into its full reading view.

Relevant inputs and decisions. Their only input is navigation — which published item to read. They make no commitments, create no state, and are asked for nothing.

Interactions with other accepted participants. The Site Visitor never interacts with the Site Owner. They experience the owner's decisions as the page's content: what the owner published is what they can read, and what the owner left as a draft is simply not there. They are the audience for the owner's publication decision, and their reading is the outcome that decision produces.

Observable success. The visitor reaches the site without being asked to sign in, sees the site's purpose and its published content, and can read an item in full.

What makes this role different. The Site Visitor is anonymous, stateless, and read-only. They have no identity in the product, nothing to resume, no protected surface, and no failure mode beyond content failing to load. Their entire accepted lifecycle is a single anonymous reading pass — which is precisely why they must never be routed through Sign Up or Login to reach the public page.

5. Core User Flows

Flow A — The Site Owner creates their website and publishes a first item

1. Starting context. The Site Owner has no identity in fierce-help and no content. They arrive at the public Landing page, which presents the site's purpose and the entry actions.
2. Entry decision. On Landing, the owner selects Start building. This takes them to Sign Up.
3. Enrollment. On Sign Up, the owner enters the details required to establish their identity and submits. The submit control shows an in-progress state.
4. Enrollment outcome. Enrollment succeeds. The owner's identity is now in effect and they are taken into the protected authoring experience. If instead a field is invalid, an inline error appears next to that field with the entered values preserved; if the identifier is already in use or the service is unreachable, the failure is reported in the outcome region and the owner can correct and resubmit without retyping. No protected state is reachable until enrollment actually succeeds.
5. Overview. The owner lands on Content. Because they have no items yet, the page shows its empty state: a flat hand-drawn illustration, a short explanation, and the new-item control as the clear next step.
6. Create an item. The owner uses the new-item control. A new content item is created and opened in the Content Editor.
7. Write. In the Content Editor, the owner writes a title and a body. The editor pane holds the same reading measure as the public page, so the writing surface looks like the reading surface. The save-state indicator reports unsaved changes, then saving, then saved.
8. Save outcome. The save succeeds and is confirmed visibly. If the save fails, the failure is reported plainly, the owner's text stays in the editor, and a retry is available — the text is never silently discarded.
9. Publish decision. The owner selects publish. The item's state becomes published and its marker turns teal.
10. Publish outcome. The item's content becomes readable on the public Landing page. If the publish fails, the item's previous state is left intact, the failure is reported, and the owner can retry; the owner is never told an item is live when it is not.
11. Continuation. The owner returns to Content, where the item now appears as an index card with a teal published dot, or opens Landing to see the published result as a visitor would.

Flow B — The Site Owner returns and updates what the site says

1. Starting context. The Site Owner has an existing identity and existing content, and has been away. Their site is live.
2. Entry. The owner arrives at Landing and selects Log in, which takes them to Login.
3. Verification. On Login, the owner submits their credentials. The submit control shows an in-progress state.
4. Verification outcome. Verification succeeds and the owner is taken into the protected authoring experience with their own content and publication state intact. If verification fails, the failure is reported without disclosing which field was wrong, the entered identifier is preserved, and the owner can retry or follow the cross-link to Sign Up. Protected state remains unavailable until verification succeeds.
5. Overview. The owner lands on Content and sees every content item with its title and its draft (rust) or published (teal) marker, plus the site's overall publication state. If items cannot be loaded, the page reports it plainly with a retry.
6. Open an item. The owner selects an existing item, which opens in the Content Editor.
7. Edit. The owner revises the title or body. The save-state indicator tracks unsaved, saving, and saved.
8. Save outcome. The save succeeds and is confirmed. If it fails, the failure is reported with the owner's text preserved and a retry available.
9. Publication change. The owner either publishes the revised item (making the revision readable on Landing) or unpublishes it (returning it to draft and removing it from the public page). A failed publish or unpublish reverts the item's marker to its previous value and reports the failure next to that item.
10. Interruption handling. If the owner tries to leave the editor with unsaved changes, they are warned rather than losing their work silently.
11. Continuation. The owner returns to Content to see the updated markers, or opens Landing to confirm the published result. Their work persists across sessions, and their published content stays available between visits.

Flow C — The Site Visitor reads the published site

1. Starting context. The Site Visitor has no account, no session, and no relationship with fierce-help. They arrive at the site's public address.
2. Arrival. The Landing page loads. The hero renders immediately; the published content region shows a restrained placeholder while content is fetched.
3. Reading the site's purpose. The visitor reads the essay-opening hero — the headline, the lede, and the entry actions — and understands what the site is.
4. Reading published content. The published content items the Site Owner has made live render in reading order with their titles and bodies. The visitor scans them and selects one to read in full.
5. Full reading. The visitor reads the item's full content. Nothing asks them to sign in, create an account, or identify themselves.
6. Empty case. If the owner has published nothing yet, the page presents the site's purpose and entry actions with a short, honest note that nothing has been published yet. No fabricated content is shown.
7. Failure and recovery. If published content cannot be loaded, the page keeps its hero and entry actions intact and shows a plain message that the content could not be loaded, with a retry action. Retrying re-requests the content without losing the visitor's place.
8. Continuation. The visitor reads further published items, or leaves having found what the owner published. Nothing about their visit creates state, and nothing is asked of them.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. It names Frank Chimero as the muse and "A small, fierce website of your own" as the headline. The register is warm editorial: personal and handmade rather than corporate — a desk, not a dashboard.

Color tokens (light mode)

No colour is used decoratively. Every hue marks a state or a section: rust means action or draft, teal means live or focused, muted means secondary or unavailable.

Typography

• Headings: Fraunces, at a soft optical size with low contrast and slightly heavy weight (500–600), tight leading around 1.02, sentence case, no all-caps headings. Display sizes are generous and slightly over-tight so the headline feels typeset rather than set by a browser.
• Body: Literata.
• Scale: 1.333 modular — 64/48/36/27/20/17/15 on mobile, up to 128/72/44/28/20/17/15 on desktop, with clamp() used for every display size so headlines scale down to their mobile size and stay whole inside the viewport.

Shape language

Almost-square: 2px radii on inputs and buttons, 4px on cards, 1px hairlines in warm ink at 18% opacity. Rules and underlines carry the structure instead of shadows or filled borders. Illustrations are flat, hand-drawn, and slightly imperfect, sitting inline with text rather than inside cards. No drop shadow heavier than a 1px hairline.

Layout

A single-column reading measure of about 68 characters sits at the centre of a 12-column grid, with asymmetric margins so the page never feels centred for its own sake. The Landing page reads like the opening of an essay: a title, a short lede, then illustrated sections separated by full-width hairline rules. The owner workspace flips to a two-column split — a narrow left rail listing content items with their publication state, and a wide editor pane that keeps the same reading measure so writing feels like writing. On mobile the rail collapses to a horizontally scrollable strip of item chips above the editor.

Imagery

Flat warm illustration drawn in the palette's ink and rust, used as section openers and empty-state art: a hand holding a page, a small stack of cards, a watering can for the published state. Diagrams and hand-drawn arrows explain the flow from write to publish. No photography and no 3D renders.

Readability guarantee

Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Imagery and decoration may be cropped, bled off an edge, or overlapped exactly as the direction asks, as long as they cover no readable text or control. The horizontally scrollable item-chip strip on mobile is judged by whether it actually scrolls and whether every chip becomes fully readable as it passes.

7. Signature Design Concept

The essay opening. The first screen of Landing is not a SaaS hero — it is the opening of an essay, and it is the product's signature.

A full-width cream field (#F3EDE1) sits on a 12-column grid. The headline "A small, fierce website of your own" is set in Fraunces at 56px on mobile up to 120px on desktop, spanning nine columns on the left, sentence case, tight leading. Beneath it, in columns four to eight, the lede paragraph and a rust (#8C3B24) Start building button are stacked. To the right, an inline flat illustration of a hand writing on a page bleeds off the right edge of the viewport — cropped by the viewport, never covering the headline, lede, or button.

A hairline rule runs the full width under the hero. In the leftmost column, set small, are the words "Write. Publish. Keep it." On the right, a teal (#1F6F6B) dot marks the live status.

Below the rule, the page continues as illustrated sections separated by full-width hairline rules, each carrying a small numbered label in the leftmost column like a chapter mark in a book. The published content items the owner has made live appear as readable entries in the same 68-character measure, so the public page reads as one continuous piece of writing rather than a feed of cards.

The concept recomposes only accepted content, states, and controls: the site's purpose, its published items, its live-status marker, and the two entry actions (Start building → Sign Up; Log in → Login). It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

The direction specifies restrained, mostly mechanical motion with no parallax, no bounce, and no cursor-following effects. The hero is flat and composed, so no 3D or WebGL scene is required or implied.

Landing Hero Motion Brief

• Focal subject. The inline flat illustration of a hand writing on a page, bleeding off the right edge of the viewport, paired with the oversized Fraunces headline spanning nine columns.
• Input → transformation → outcome thesis. As the visitor scrolls into the hero, the headline, lede, and Start building button rise 8px and fade in over 200ms ease-out; the illustration settles into place with the same restrained timing. The outcome is a composed first frame that reads as the opening of an essay rather than a marketing panel. No accepted behaviour is added — the hero only presents the site's purpose and its two entry actions.
• Motion vocabulary. 200ms ease-out fades and 8px rises on scroll reveal; a soft rust underline that draws in from left to right in 180ms on link hover; one slow 6-second breathing loop on the landing illustration. Nothing else moves.
• Composed first frame. Cream field, headline set in Fraunces across nine columns on the left, lede and rust button stacked beneath it in columns four to eight, illustration bleeding off the right edge, hairline rule beneath with "Write. Publish. Keep it." small in the leftmost column and a teal live-status dot on the right.
• Reduced-motion state. With prefers-reduced-motion, the 8px rises and fades resolve immediately to their final positions, the illustration's 6-second loop stops on a single composed frame, and the link-hover underline appears without the draw-in. The horizontally scrollable item-chip strip on mobile stops auto-advancing and shows whole chips, reachable by scrolling. All content remains fully readable and every control remains fully operable.

9. Non-Functional Requirements

NFR-1 — Durable content persistence. Provenance: required_inference. Content items, their bodies, and their publication state must be stored durably so that the Site Owner's work survives between sessions and their published site stays available between visits. Rationale: FR-4 and FR-7 depend on continuity; without it, the accepted "keep it alive" outcome fails.

NFR-2 — Owner-bound content isolation. Provenance: required_inference. Stored content and publication state must remain bound to the Site Owner's identity, and protected destinations must not expose content to anyone who has not verified as that owner. Rationale: the content is owner-specific and durable, so it must not leak across identities or to anonymous visitors.

NFR-3 — Anonymous public readability. Provenance: required_inference. The Landing page and its published content must be reachable and readable with no account, no session, and no sign-in prompt. Rationale: FR-8 is the accepted outcome of the whole product; gating it would defeat the purpose.

NFR-4 — Anonymous reachability of identity surfaces. Provenance: required_inference. Sign Up and Login must be reachable without an existing session, and neither may expose protected content state. Rationale: a person with no identity cannot be required to already have one, and a person restoring a session cannot be required to already have one.

NFR-5 — Truthful state reporting. Provenance: required_inference. Save state, publication state, and failure states must be reported truthfully; the owner must never be shown a published state for content that is not live, or a saved state for content that was not stored. Rationale: the owner's only confirmation that their site says what they intend is the state the product reports.

NFR-6 — No silent data loss. Provenance: required_inference. Unsaved edits must be preserved on save failure and guarded on navigation away. Rationale: FR-6's recovery path depends on the owner's text surviving a failure.

NFR-7 — Readable text and controls at every viewport. Provenance: explicit (creative direction). Headlines, wordmarks, 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. Rationale: stated as a hard readability guarantee in the direction.

NFR-8 — Reduced-motion support. Provenance: explicit (creative direction). With prefers-reduced-motion, motion stops and moving or scrollable content shows whole items, wrapping into rows or sitting in a horizontally scrollable row. Rationale: stated as a hard requirement in the direction.

NFR-9 — Accessible contrast and focus. Provenance: required_inference. Text must meet accessible contrast against its ground, and focus must be visible using the teal accent as the focus ring. Rationale: the direction assigns teal specifically to focus rings, and the palette must remain usable, not merely attractive.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults for the accepted scope, labeled as such.

• Frontend: React with a component-based single-page application structure. [Default — not specified by user]
• Backend: Python with FastAPI, exposing the content, publication, and identity endpoints the pages require. [Default — not specified by user]
• Storage: A relational database for owner identities, content items, and publication state, with durable persistence across sessions. [Default — not specified by user]
• Containerization: Docker with docker-compose for local development and a single-service deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required at this scope; a single-service deployment satisfies the accepted requirements. [Default — not specified by user]
• Typography delivery: Fraunces and Literata served as web fonts. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions.

• A-1. The Site Owner is a single individual. No multi-author, team, or organizational structure was requested, and none is assumed. [Assumption — narrow, consistent with the accepted persona catalog]
• A-2. The Site Owner's identity is application-owned, established at Sign Up and verified at Login, because their content and publication state are durable and must remain bound to the correct person. [Assumption — required_inference]
• A-3. A content item consists of a title and a body. No other content fields were requested. [Assumption — narrow]
• A-4. Publication state is binary per item: draft or published. [Assumption — narrow, consistent with the direction's rust/teal state language]
• A-5. The site has one public address owned by the application. Custom domains were not requested. [Assumption — narrow]

Constraints.

• C-1. The public Landing page must remain reachable without an account or sign-in. [Explicit — derived from the accepted visitor journey]
• C-2. Sign Up and Login must be anonymously reachable and must not expose protected content state. [Explicit — derived from the accepted identity lifecycle]
• C-3. The Content and Content Editor pages are restricted to the verified Site Owner. [Explicit — page contract]
• C-4. The palette, typography, shape language, layout, imagery, and motion described in Sections 6–8 are binding and must not be substituted with a generic indigo/blue-on-white SaaS treatment. [Explicit — creative direction]
• C-5. No photography, no 3D renders, and no drop shadows heavier than a 1px hairline. [Explicit — creative direction]
• C-6. No parallax, no bounce, and no cursor-following effects. [Explicit — creative direction]

Future horizon. No future requirements were accepted in the authoritative thread. Multi-author collaboration, comments, analytics, e-commerce, newsletters, custom domains, theming marketplaces, and media libraries are explicitly out of current scope and are not promised here.

12. Glossary

• Site Owner — the single accepted human persona who authors, publishes, and maintains the website. The only actor with durable, owner-bound state.
• Site Visitor — the accepted human persona who reads the published website anonymously, with no account and no state.
• Content item — a single authored unit of the website, consisting of a title and a body, with its own publication state.
• Draft — a content item's state when it is saved but not readable by visitors. Marked with a rust dot.
• Published — a content item's state when it is readable by visitors on the Landing page. Marked with a teal dot.
• Landing — the public entry page presenting the site's purpose and its published content to anonymous visitors.
• Sign Up — the anonymously reachable first-use enrollment surface where the Site Owner establishes their identity.
• Login — the anonymously reachable returning-verification surface where the Site Owner restores access to their own content.
• Content — the protected overview page listing the Site Owner's content items and their publication state.
• Content Editor — the protected focused workspace where the Site Owner writes, edits, saves, and publishes a single content item.
• Reading measure — the roughly 68-character single-column width shared by the public page and the editor pane, so the writing surface looks like the reading surface.
• Hairline rule — a 1px full-width rule in warm ink at 18% opacity, used to carry structure and separate sections instead of shadows or filled borders.