System Requirements Document for neon-project

1. Introduction

neon-project is a content-design workspace for a single practitioner: a Product Content Designer who writes and shapes the copy and content that describes a product. The product's intent is narrow and deliberate — it is not a website-page builder and not a social-media content tool. It is a workshop for product content: the words that ship inside a product.

The audience is one designer (the user, "deco") who wants their words to feel like a shipped product rather than a form entry. The workspace treats every piece of product copy as a tagged, versioned, quotable artifact — an industrial labeled object on a graphite ground with a neon pulse.

2. System Overview

neon-project is delivered as a first-party web application with application-owned identity and custom UI. The current delivery covers:

• An anonymous Landing surface that states the product's purpose — designing product content — and guides the visitor toward use.
• Anonymous Sign Up and Login surfaces that establish and verify the Product Content Designer's identity.
• A protected Content surface: a revisitable, ruled index of the product content being designed.
• A protected Content Editor surface: the focused writing sheet where product content is created and edited, with a persistent metadata strip (status, version, live word count).

Actors:

• Product Content Designer — the only accepted active human persona. Writes, shapes, versions, and ships product content.
• Application identity service (non-persona system actor) — establishes and verifies the designer's identity so durable content remains bound to its owner.
• Persistence layer (non-persona system actor) — stores product content, its versions, and its status.

Narrow exclusions (binding):

• The product is for designing product content, not website pages and not social-media content.
• No blue/indigo primary or accent; no white or near-white page ground on Landing or Content Editor; no gradient-blob heroes or glassmorphism; no grid of identical hover-lift cards for the content library; no rounded pill buttons or soft 16px+ radii as the default control shape; no photography of smiling people or stock office scenes; no bouncy spring easing or playful character illustrations.

2a. Product Interpretation and Delivery Boundary

Current. The designer arrives anonymously at Landing, learns that neon-project is where product copy is written and shaped, and either enrolls (Sign Up) or verifies an existing identity (Login). Once identity is established, the designer works in two protected places: Content, the ruled index of everything being designed, and Content Editor, the writing sheet where a piece of product copy is drafted, revised, and marked shipped. Identity is application-owned because the designer's content is durable, private, and must remain bound to the correct person across sessions.

Access ownership. Landing, Sign Up, and Login are anonymously reachable. Content and Content Editor require an established identity. Sign Up and Login are the only places where access to protected work is established; neither protected surface owns the interaction that grants access to itself.

Future. No future-horizon capabilities are accepted in this document. Anything not listed above is out of current scope.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous public entry. States the product's purpose — designing product content (the copy that describes a product) — and distinguishes it from website pages and social-media content. No user data is shown.
• Primary actions: Proceed to Sign Up (begin designing product content); proceed to Login (return to existing product content).
• Supporting actions: Read the purpose statement; read the DRAFT / REVIEW / SHIPPED status legend.
• Domain entities: None persisted. Product purpose copy; status vocabulary (DRAFT, REVIEW, SHIPPED).
• Component responsibilities:
  • Oversized quoted headline block — Archivo Black all-caps, literal quotation marks, spanning 9 of 12 columns from the left edge, with a safety-orange block cut into the baseline of the last line.
  • Vertical status label strip — "DRAFT / REVIEW / SHIPPED" in 12px tracked caps with a neon-lime tick on the active state.
  • Hazard-stripe band running edge to edge as the CTA's underline.
  • Exposed grid lines and industrial framing marks (crop corners, measurement ticks) as decoration only.
• States:
  • Loading: static content; no network dependency beyond the page itself.
  • Empty: not applicable (no collections).
  • Success: visitor reads the purpose and selects Sign Up or Login.
  • Error: if the page fails to load, a plain retry affordance is offered; no partial state is shown.
  • Recovery: reload returns the visitor to the same anonymous entry.

Login

• Information / state: Anonymous identity-verification surface for a returning Product Content Designer. Explains that verification resumes access to existing product content.
• Primary actions: Submit credentials to verify identity and resume access to existing product content.
• Supporting actions: Navigate to Sign Up if the visitor has no identity yet.
• Domain entities: Designer identity (email/identifier + secret).
• Component responsibilities:
  • Credential form with labeled fields in tracked uppercase labels.
  • Submit control styled as the primary safety-orange action.
  • Inline validation and error region.
  • Link to Sign Up.
• States:
  • Loading: submit control shows a mechanical in-progress state (120–180ms transitions, no bounce).
  • Empty: fields blank with helper text in muted #8A8A85.
  • Success: identity verified; designer is taken to Content.
  • Error: incorrect or unrecognized credentials produce an inline, non-destructive error; entered identifier is preserved so the designer can correct the secret.
  • Recovery: retry submission; or navigate to Sign Up.

Sign Up

• Information / state: Anonymous self-service enrollment surface for a Product Content Designer starting product-content work for the first time.
• Primary actions: Establish a new identity so durable product content can be created and owned.
• Supporting actions: Navigate to Login if an identity already exists.
• Domain entities: Designer identity (email/identifier + secret).
• Component responsibilities:
  • Enrollment form with labeled fields in tracked uppercase labels.
  • Submit control styled as the primary safety-orange action.
  • Inline validation and error region.
  • Link to Login.
• States:
  • Loading: submit control shows a mechanical in-progress state.
  • Empty: fields blank with helper text in muted #8A8A85.
  • Success: identity established; designer is taken to Content with an empty index.
  • Error: invalid or already-registered identifier produces an inline error with a route to Login.
  • Recovery: correct the field and resubmit, or switch to Login.

Content

• Information / state: Protected, revisitable index of the product content the designer is working on. Each entry shows its numbered position, its quoted title, its version, and its status (DRAFT / REVIEW / SHIPPED). Empty when the designer has not yet created content.
• Primary actions: Open an existing content item in Content Editor; start a new content item in Content Editor.
• Supporting actions: Scan the marquee ticker of content titles; read status and version chips; return to the index after editing.
• Domain entities: Product content item (title, version, status, last-modified), ordered index position.
• Component responsibilities:
  • Ruled, numbered table of labels — each row reads like 01 "HERO COPY" — v3 — DRAFT, with a punched notch and a hover that flips the label to its quoted form. Not a grid of identical hover-lift cards.
  • Marquee ticker of content titles across the top of the library.
  • Status chips (neon-lime for shipped/active ticks; muted for metadata).
  • New-content control.
  • Empty-state panel explaining that no product content exists yet, with the new-content action.
• States:
  • Loading: ruled table skeleton with exposed grid lines; ticker paused.
  • Empty: explicit empty panel with the new-content action; no fabricated rows.
  • Success: rows render with title, version, and status; selecting a row opens Content Editor.
  • Error: if the index cannot be loaded, an inline error with retry is shown; the new-content action remains available only if it can succeed.
  • Recovery: retry reloads the index; the designer is never left on a blank ruled table without explanation.

Content Editor

• Information / state: Protected focused workspace for creating and editing one piece of product content. Persistent metadata strip at top shows status chip, version, and live word count in neon-lime. The writing sheet shows its underlying 12-column grid and four crop-corner marks at all times.
• Primary actions: Write and edit the product content body; save/commit the current draft.
• Supporting actions: Change status between DRAFT, REVIEW, and SHIPPED; read the live word count; return to Content.
• Domain entities: Product content item (title, body, version, status, word count, last-modified).
• Component responsibilities:
  • Left rail: tagged content index — numbered, all-caps labels, so the designer can move between content items without leaving the editor context.
  • Right pane: the writing sheet with a visible left rule and a punched-hole margin.
  • Persistent metadata strip: status chip, version, word count in neon-lime #C6FF00.
  • Hazard-stripe save state: a 45° safety-orange/graphite hazard band that animates once on save, then collapses to a solid neon-lime "SHIPPED" chip.
  • Fixed bottom-right monospace word-count readout framed by measurement ticks, ticking live as the designer types.
  • Cursor-following highlight on the editor sheet.
• States:
  • Loading: sheet and metadata strip render in a pending state; the rail shows its skeleton.
  • Empty: a new content item opens with an empty sheet, version v1, status DRAFT, word count 0.
  • Success: save commits the body and advances the version; the hazard band animates once and collapses to the status chip.
  • Error: a failed save leaves the sheet content intact, shows an inline error, and keeps the unsaved-changes hazard indicator visible so the designer knows work is not yet committed.
  • Recovery: retry save; the designer can continue editing without losing the in-progress body.

3. Functional Requirements

FR-1 — Design product content (not pages, not social). As a Product Content Designer, I should design content for a product — the copy and content that describes a product — so that the words that ship inside the product are shaped deliberately.

• Provenance: explicit
• Trigger/input: the designer opens the workspace and begins writing product content.
• Observable result: product content exists as a durable, versioned item in the designer's index.
• Access state: requires an established identity.
• Failure/recovery: if the content cannot be persisted, the in-progress body is preserved in the editor and an inline error with retry is shown.
• Continuation: the designer returns to Content and sees the item in the index.
• Boundary: this is explicitly not website-page design and not social-media content.

FR-2 — Self-service enrollment before first durable content. As a Product Content Designer, I should be able to establish my own identity before creating durable product content, so that my content is owned by me and can be resumed later.

• Provenance: required_inference
• Trigger/input: an anonymous visitor on Landing selects Sign Up and submits enrollment details.
• Observable result: an identity is established and the designer reaches Content with an empty index.
• Access state: anonymous entry; the resulting identity grants access to Content and Content Editor.
• Failure/recovery: invalid or already-registered details produce an inline error with a route to Login.
• Continuation: the designer starts a first content item.

FR-3 — Returning verification before resuming existing content. As a Product Content Designer, I should be able to verify my identity when returning, so that I resume access to the product content I already created.

• Provenance: required_inference
• Trigger/input: a returning designer on Landing selects Login and submits credentials.
• Observable result: identity is verified and the designer reaches Content with their existing items listed.
• Access state: anonymous entry; the verified identity grants access to Content and Content Editor.
• Failure/recovery: incorrect credentials produce an inline error; the entered identifier is preserved so the secret can be corrected.
• Continuation: the designer opens an existing item in Content Editor.

FR-4 — Browse and return to product content being designed. As a Product Content Designer, I should see a revisitable index of the product content I am designing, with each item's title, version, and status, so that I can find and return to any piece of copy.

• Provenance: required_inference
• Trigger/input: the designer opens Content, or returns to it from Content Editor.
• Observable result: a ruled, numbered list of content items renders with title, version, and status; selecting a row opens that item in Content Editor.
• Access state: requires an established identity.
• Failure/recovery: if the index cannot be loaded, an inline error with retry is shown rather than a silently blank table.
• Continuation: the designer opens an item, or starts a new one.

FR-5 — Create and edit a piece of product content. As a Product Content Designer, I should write and revise the body of a product content item in a focused writing sheet, so that the copy reaches a finished state.

• Provenance: required_inference
• Trigger/input: the designer starts a new content item from Content, or opens an existing one.
• Observable result: the sheet holds the content body; the metadata strip shows status, version, and a live word count.
• Access state: requires an established identity.
• Failure/recovery: a failed save leaves the body intact, shows an inline error, and keeps the unsaved-changes hazard indicator visible.
• Continuation: the designer retries the save or continues editing.

FR-6 — Commit a draft and advance its version. As a Product Content Designer, I should save/commit the current draft so that my work becomes a durable version rather than an unsaved edit.

• Provenance: required_inference
• Trigger/input: the designer invokes save/commit in Content Editor.
• Observable result: the body is persisted, the version advances, and the hazard-stripe save state animates once and collapses to the status chip.
• Access state: requires an established identity.
• Failure/recovery: on failure, the version does not advance, the body remains editable, and the unsaved-changes indicator stays visible.
• Continuation: the designer continues editing or returns to Content.

FR-7 — Mark content status as DRAFT, REVIEW, or SHIPPED. As a Product Content Designer, I should set and see the status of each content item, so that I know what is still being written, what is under review, and what is finished.

• Provenance: required_inference
• Trigger/input: the designer changes the status control in the metadata strip, or reads the status chip on a Content row.
• Observable result: the status chip reflects the current state; a shipped item shows the solid neon-lime "SHIPPED" chip.
• Access state: requires an established identity.
• Failure/recovery: if the status change cannot be persisted, the previous status remains displayed and an inline error is shown.
• Continuation: the designer continues editing or returns to Content, where the row shows the updated status.

FR-8 — Read a live word count while writing. As a Product Content Designer, I should see a live word count as I type, so that I can judge the length of the copy against the product's needs.

• Provenance: required_inference
• Trigger/input: the designer types in the writing sheet.
• Observable result: the fixed bottom-right monospace counter in neon-lime ticks live; the metadata strip word count stays in sync.
• Access state: requires an established identity.
• Failure/recovery: if the count cannot be computed, the last known value remains displayed rather than a fabricated number.
• Continuation: the designer keeps writing.

FR-9 — Move between content items without leaving the editor context. As a Product Content Designer, I should see a tagged, numbered index of my content items inside Content Editor, so that I can switch between pieces of copy while staying in the writing workspace.

• Provenance: required_inference
• Trigger/input: the designer selects an entry in the left rail.
• Observable result: the writing sheet loads the selected item with its own status, version, and word count.
• Access state: requires an established identity.
• Failure/recovery: if the selected item cannot be loaded, the current sheet is not discarded; an inline error is shown.
• Continuation: the designer edits the newly loaded item or returns to Content.

4. User Personas

Product Content Designer

Product context. A single practitioner — the user, "deco" — who writes and shapes the copy and content that describes a product. Their work is editorial and precise: the words must feel like a shipped product, not a form entry. They are not building website pages and not producing social-media content; their material is product content.

Primary goal. Produce and shape product content until it is finished and ready to be used in the product.

Distinct accepted responsibilities.

• Establish their own identity the first time, so their content is owned and resumable.
• Verify their identity when returning, to resume existing content.
• Browse and return to the content they are designing, reading each item's title, version, and status.
• Write and revise the body of a content item in a focused writing sheet.
• Commit drafts so work becomes durable versions rather than unsaved edits.
• Set and read status — DRAFT, REVIEW, SHIPPED — so they know what is unfinished and what is done.
• Read a live word count while writing to judge length.
• Move between content items inside the editor context without losing their place.

Relevant inputs or decisions. The content body itself; the decision to commit a draft; the decision to move an item from DRAFT to REVIEW to SHIPPED; the decision to start a new item or return to an existing one.

Interactions with other accepted participants. The designer is the only active human participant. Their work is mediated by the application's identity service (which binds content to them and lets them resume it) and by the persistence layer (which holds content, versions, and status). No other human participant is affected by, or acts on, this work.

Observable success. Finished product content exists as a durable, versioned item marked SHIPPED, visible in the Content index and reopenable in Content Editor.

What makes this role's work different. The designer is simultaneously author and editor of a single body of product copy. There is no review queue, no approval chain, and no second human in the loop — the discipline is in the artifact itself: versioning, status, and the physical sense that the copy is a tagged object rather than a text field.

5. Core User Flows

Flow A — First use: enroll, then create the first piece of product content

1. The visitor arrives anonymously at Landing and reads the purpose statement: neon-project is where product content — the copy that describes a product — is designed. The status legend shows DRAFT / REVIEW / SHIPPED with a neon-lime tick on the active state.
2. The visitor selects the Sign Up action (underlined by the hazard-stripe band) and lands on Sign Up.
3. On Sign Up, the designer enters their enrollment details and submits. The submit control shows a mechanical in-progress state.
4. Observable result: identity is established and the designer arrives at Content with an empty index. The empty panel explains that no product content exists yet and offers the new-content action.
5. The designer selects the new-content action and arrives at Content Editor with an empty sheet, version v1, status DRAFT, and word count 0.
6. The designer writes the product copy. The bottom-right monospace counter in neon-lime ticks live; the metadata strip word count stays in sync.
7. The designer invokes save/commit. Observable result: the body is persisted, the version advances, and the hazard-stripe band animates once across the top strip before collapsing to the status chip.
8. Failure/recovery: if the save fails, the body stays intact in the sheet, an inline error appears, and the unsaved-changes hazard indicator remains visible. The designer retries the save.
9. Continuation: the designer returns to Content, where the item now appears as a numbered ruled row — 01 "…" — v1 — DRAFT.

Flow B — Returning: verify identity and resume existing content

1. The returning designer arrives anonymously at Landing and selects the Login action.
2. On Login, the designer submits their credentials. The submit control shows a mechanical in-progress state.
3. Observable result: identity is verified and the designer arrives at Content, where their existing items are listed with title, version, and status.
4. Failure/recovery: if the credentials are incorrect, an inline error appears and the entered identifier is preserved so the designer can correct the secret and resubmit — or navigate to Sign Up.
5. Continuation: the designer selects a row. The label flips to its quoted form on hover, and the item opens in Content Editor.

Flow C — Revise an item and mark it shipped

1. From Content, the designer opens an existing item in Content Editor. The writing sheet shows its underlying 12-column grid and four crop-corner marks; the metadata strip shows the current status, version, and word count.
2. The designer edits the body. The live word count ticks in neon-lime at the bottom right.
3. The designer moves the status from DRAFT to REVIEW using the status control in the metadata strip. Observable result: the status chip reflects REVIEW.
4. The designer continues revising, then moves the status to SHIPPED and invokes save/commit.
5. Observable result: the body is persisted, the version advances, the hazard band animates once, and it collapses to a solid neon-lime "SHIPPED" chip.
6. Failure/recovery: if the status change or the save cannot be persisted, the previous status remains displayed, the body stays editable, and an inline error is shown; the designer retries.
7. Continuation: the designer returns to Content, where the row now reads 01 "…" — v2 — SHIPPED.

Flow D — Move between content items inside the editor

1. While in Content Editor, the designer uses the left rail — a tagged, numbered, all-caps index of their content items.
2. The designer selects a different entry.
3. Observable result: the writing sheet loads the selected item with its own status, version, and word count; the cursor-following highlight tracks the designer's pointer on the sheet.
4. Failure/recovery: if the selected item cannot be loaded, the current sheet is not discarded and an inline error is shown.
5. Continuation: the designer edits the newly loaded item, or returns to Content via the index.

6. Visuals Colors and Theme

Muse and headline. Virgil Abloh — product copy as an industrial labeled artifact, glowing on graphite. The register is confident, precise, a little ironic, with a neon pulse: not corporate, not playful-childish.

Mode. Dark mode only for Landing and Content Editor. No white or near-white page ground on those surfaces.

Colour tokens (exact hex, by role).

Contrast: #F2F0EC on #0E0E0F ≈ 15:1; #FF4D00 on #0E0E0F readable at body size for labels; #C6FF00 only on dark ground. No blue, no indigo, no gradient blobs.

Typography.

• Headings: Archivo Black, all-caps, tight tracking -0.02em, heavy weight, wrapped in literal quotation marks in the UI (e.g. "PRODUCT COPY"). Never sentence case for section titles.
• Body: Space Grotesk.
• Scale: 1.25 modular, clamp-based — display 52px mobile → 132px desktop; h1 36 → 72; h2 24 → 40; body 16 → 18; label 12 → 13 uppercase tracked +0.08em.
• Forbidden for headings or body: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, system-ui.

Shape language. Hard-edged industrial rectangles with 2px hairline borders (#2A2B2E) and 0–4px radii. Label and tag motifs with a punched notch. Hazard stripe bands (45° alternating #FF4D00 and #0E0E0F) as section dividers and as the editor's unsaved-changes indicator. Exposed grid lines visible behind panels. The content canvas is a "sheet" with a visible left rule and a punched-hole margin. No rounded pill buttons; no soft 16px+ radii as the default control shape.

Layout. Full-bleed dark canvas with an asymmetric 12-column grid. Landing hero is a left-aligned stack of oversized quoted type over a graphite field, with a safety-orange block cut into the baseline. Editor is a two-pane split: left rail is a tagged content index (numbered, all-caps labels); right pane is the writing sheet with a persistent metadata strip at top. Content library is a ruled table-like grid, not a grid of identical hover-lift cards. Everything sits on a 4/8pt spacing scale.

Imagery. No photography of people. Visuals are the interface itself: exposed grid lines, label/tag cutouts, quotation-mark glyphs used as graphic elements, schematic diagrams of the content model (Product → Copy Block → Version), concrete-texture dark panels, and industrial framing marks (crop corners, measurement ticks).

Readable-content rule. Headlines, wordmarks, labels, numbers, cards, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (e.g. font-size: clamp(...) with its mobile size) to fit; no other element covers any part of them. Crops, bleeds, and off-edge placement are for decoration only — shapes, textures, rules, and background art. The one exception is moving content: marquees, tickers, carousels, and horizontally scrollable rows may cross the viewport or container edge by design, judged by whether they actually move and whether every item becomes fully readable as it passes. With prefers-reduced-motion they stop and show whole items, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto).

7. Signature Design Concept

"PRODUCT CONTENT" — the labeled artifact on graphite.

The public entry is a full-bleed graphite field (#0E0E0F) carrying a single oversized all-caps headline in Archivo Black — "PRODUCT CONTENT" in literal quotation marks — spanning 9 of 12 columns from the left edge, set at 52px on mobile and up to 132px on desktop. A safety-orange (#FF4D00) block is cut into the baseline of the last line so the type sits inside the colour, as if the words were stamped onto a shipping label.

To its right, a stacked vertical label strip reads DRAFT / REVIEW / SHIPPED in 12px tracked caps, with a neon-lime (#C6FF00) tick on the active state — the product's own status vocabulary used as the entry's graphic spine. Bottom-left, a hazard-stripe band runs edge to edge as the CTA's underline, so the way into the product is literally taped off.

Behind the type, the exposed 12-column grid and four crop-corner marks are visible at all times, so the first screen reads as a print artifact rather than a blank page. No centered headline, no subtext button pair, no gradient. The composition recomposes only accepted content — the product's purpose, its status vocabulary, and the two entry actions (Sign Up, Login).

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: flat

Landing Hero Motion Brief.

• Focal subject: the oversized quoted headline "PRODUCT CONTENT" in Archivo Black, with the safety-orange block cut into its baseline, and the vertical DRAFT / REVIEW / SHIPPED label strip to its right.
• Input → transformation → outcome thesis: as the visitor arrives, the headline's baseline block wipes in from the left edge beneath the last line of type, seating the words inside the colour; the vertical status strip's neon-lime tick steps down through DRAFT → REVIEW → SHIPPED and settles on the active state. The outcome is a first frame that reads as a finished, labeled artifact — the product's own status vocabulary demonstrated before the visitor has done anything.
• Motion vocabulary: snappy and mechanical — 120–180ms transitions, tag flips, no bouncy easing, no float. The hazard-stripe band under the CTA scrolls once on entry (not looping).
• Composed first frame: graphite field, quoted headline left-aligned and bleeding to the grid edge, orange baseline block seated, status strip with its lime tick, hazard band under the CTA, exposed grid and crop corners visible.
• Reduced-motion state: all motion resolves immediately to the composed first frame — headline seated, tick on the active status, hazard band static. No element is left mid-transition, and all text remains whole and inside the viewport at 375px, 768px, and 1280px.

Editor motion (accepted behaviour, same vocabulary). The hazard-stripe save state animates once on save and then collapses to a solid neon-lime "SHIPPED" chip — it never loops. A cursor-following highlight tracks the pointer on the editor sheet. The Content library carries a marquee ticker of content titles across its top; under prefers-reduced-motion the ticker stops and its items wrap into rows or sit in a horizontally scrollable row.

9. Non-Functional Requirements

• NFR-1 — Dark-mode-only surfaces. Landing and Content Editor must not use a white or near-white page ground. Provenance: explicit (creative direction). Rationale: the graphite ground is the product's identity, and the neon accents depend on it for contrast.
• NFR-2 — Contrast. Body text #F2F0EC on #0E0E0F must remain at approximately 15:1; #C6FF00 must only be placed on dark ground. Provenance: explicit (creative direction). Rationale: the neon-lime accent is unreadable on light ground.
• NFR-3 — Responsive integrity. Headlines, wordmarks, labels, numbers, cards, 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 oversized poster type must not clip or overlap at small widths.
• NFR-4 — Reduced motion. With prefers-reduced-motion, all motion resolves to its composed end state; the Content ticker stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row. Provenance: explicit (creative direction). Rationale: the mechanical motion vocabulary must degrade without hiding content.
• NFR-5 — Durable, owner-bound content. Product content, its versions, and its status must persist and remain bound to the identity that created them, so a returning designer resumes exactly their own content. Provenance: required_inference. Rationale: the accepted journeys depend on resuming existing content after verification.
• NFR-6 — No adjacent capabilities. The product must not add website-page design, social-media content production, review queues, approval chains, or multi-user collaboration. Provenance: explicit (source boundary). Rationale: the user's requirement is product content design by a single designer.

10. Tech Stack

• Frontend: React (web), custom UI. [Default — not specified by user]
• Backend: Python / FastAPI. [Default — not specified by user]
• Storage: a relational database for product content items, their versions, and their status. [Default — not specified by user]
• Identity: application-owned identity with self-service enrollment and returning verification. Provenance: required_inference (Planning Scope app_owned_identity: true).
• Packaging: Docker / docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required by any accepted requirement and is omitted. [Default — not specified by user]

11. Assumptions and Constraints

• A-1. The active human catalog is closed at exactly one persona: Product Content Designer. No additional personas are created.
• A-2. The page contract is closed and ordered: Landing, Login, Sign Up, Content, Content Editor. No page is added, removed, merged, split, renamed, or reordered.
• A-3. Landing, Login, and Sign Up are anonymously reachable. Content and Content Editor require an established identity. Neither protected surface owns the interaction that grants access to itself.
• A-4. Identity is application-owned and self-service; no invitation, provisioning, or deployment bootstrap is accepted.
• A-5. Identity and session continuity do not establish differentiated permissions. There is one role with full control over its own content; no RBAC or role-based visibility is specified.
• A-6. The product is for designing product content only. Website-page design and social-media content are explicitly out of scope.
• A-7. No future-horizon capabilities are accepted; the future section of the delivery boundary is empty.
• A-8. The creative direction is authoritative for palette, typography, shape, layout, imagery, and motion. Where it is silent, labelled defaults apply and do not become product behaviour.

12. Glossary

• Product content — the copy and content that describes a product; the material this workspace is for. Explicitly not website pages and not social-media content.
• Product Content Designer — the single accepted active human persona; the person who writes and shapes product content.
• Content item — one durable, versioned piece of product content, with a title, a body, a version, and a status.
• Version — the numbered revision of a content item, advanced on each successful save/commit.
• Status — the state of a content item: DRAFT, REVIEW, or SHIPPED.
• SHIPPED — the finished state of a content item, shown as a solid neon-lime chip.
• Writing sheet — the editor's content canvas, showing its underlying 12-column grid, a visible left rule, a punched-hole margin, and four crop-corner marks.
• Metadata strip — the persistent bar at the top of Content Editor showing status chip, version, and word count.
• Hazard stripe — the 45° alternating safety-orange/graphite band used as a section divider and as the editor's unsaved-changes indicator; it animates once on save and never loops.
• Tagged content index — the numbered, all-caps left rail in Content Editor listing content items.
• Ruled index — the Content surface's numbered, table-like list of content items, each row with a punched notch and a hover that flips the label to its quoted form.
• Marquee ticker — the moving strip of content titles across the top of the Content library; it stops under prefers-reduced-motion.