System Requirements Document for noneid

1. Introduction

noneid is a dynamic website built around a live, operator-controlled interaction between two people who never need to meet: a Visitor who types into the site, and a Site Owner / Operator who watches that typing arrive in real time over a socket and then decides, with a single click, how the visitor's session ends — with an error message or with a success page.

The product intent is a live-interaction instrument. The visitor's keystrokes are streamed over a socket connection to an operator panel, where they appear as a live monospace log and as a generative visual field. The operator monitors the incoming input and, at any moment, fires one of two outcome controls: an ERROR control that delivers an error message to the visitor, or a SUCCESS control that delivers a success page to the visitor. The visitor sees the result of that decision on their own screen.

The audience is the site owner — a tinkerer, a maker, someone who wants a small instrument that feels alive and slightly uncanny. The experience is deliberately staged as surveillance-as-theatre: the visitor's own typing becomes the artwork, and the operator is the curator who ends the piece.

This document specifies the current delivery of that product: its pages, its real-time socket behavior, its two personas, its flows, and its visual and motion direction.

2. System Overview

noneid is a single web application with a real-time backend. It has two human participants and one relay service:

• The Visitor opens the site, types into a live input field, and receives either an error message or a success page chosen by the operator.
• The Site Owner / Operator opens the operator panel, watches the visitor's typing stream in live, and clicks one of two outcome controls to end the session.
• A backend socket service relays visitor typing to the operator panel in real time and relays the operator's chosen outcome back to the visitor.

The application is delivered as a dynamic website with custom first-party UI on every page. There is no account creation, no login, and no differentiated permission model: the operator panel is a first-party page reachable directly, and the visitor pages are anonymous. Identity continuity is not required by any accepted journey — the shared live session, not a user account, is what binds the visitor's typing to the operator's decision.

2a. Product Interpretation and Delivery Boundary

Current delivery. The current product is the complete live loop described above: a visitor types, the typing streams over a socket to an operator panel, the operator sees it live, and the operator clicks one button to deliver an error message or a success page to that visitor. Everything in this document is current unless it appears in a future section.

Access ownership. All six pages are first-party application pages. The Landing page, the Visitor Input page, the Error page, the Success page, and the Visitor Outcome page are anonymously reachable — a visitor never creates an account to type or to receive an outcome. The Operator Panel is likewise a first-party page reachable directly; the accepted requirements establish no account, login, or role gate for it, and none is inferred here. The shared live session is the binding mechanism between the two participants, not an identity system.

Real-time ownership. The live relay is application-owned backend work. The backend socket service accepts the visitor's typing events, forwards them to the connected operator panel, and forwards the operator's selected outcome back to the visitor's session. The operator panel must remain connected for the outcome to be delivered.

Explicit boundaries. This product does not include visitor accounts, operator accounts, authentication, authorization roles, chat between visitor and operator, message history or transcripts persisted beyond the live session, file upload, payments, or any capability beyond live typing capture and the two operator-triggered outcomes. Nothing in this document should be read as authorizing those adjacent capabilities.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

The page inventory below is the final page contract for this project: Landing, Visitor Input, Operator Panel, Error, Success, Visitor Outcome.

Landing

• Information and state. The public entry surface. It explains, before any participation, what the live visitor interaction is and that an operator controls the response the visitor will receive. It shows a live status readout of the socket relay (for example a tracked uppercase label reading LIVE SOCKET // 0 CLIENTS with a pulsing accent dot) and the current connection state of the relay.
• Primary actions. OPEN VISITOR VIEW — a hard-edged accent control that takes the user to the Visitor Input page. OPERATOR PANEL — an outlined control that takes the user to the Operator Panel page.
• Supporting actions. Scroll-linked progression into the explanatory sections below the fold; the generative field compresses into a horizontal data ribbon as the operator-panel section enters.
• Domain entities. Live session count; socket relay connection state; the two participant roles described in copy.
• Component responsibilities. Full-bleed generative canvas occupying the viewport; corner-overlaid status label; flush-left headline block; single body line; the two entry controls; below-the-fold explanatory sections on a 12-column grid.
• States. Loading: the canvas initializes and the status label reads a connecting state. Empty: zero connected clients — the field drifts and morphs on its idle cycle with no keystroke input. Success: the relay is connected and the client count is live. Error: the relay is unreachable — the status label reports the disconnected state and the entry controls remain usable so the user can still reach the visitor or operator surfaces. Recovery: the status label reconnects automatically when the relay returns.

Visitor Input

• Information and state. The visitor's typing surface. It shows the visitor's own input as they type, a thin luminous frame around the field whose border colour animates from cyan toward hot magenta in real time with the visitor's own typing speed, and an indication that the input is being streamed live.
• Primary actions. Type into the single wide input field. Submit or continue typing — the visitor's typing is streamed continuously as it is entered.
• Supporting actions. Clear the field; observe the live frame responding to typing speed.
• Domain entities. The visitor's current input text; the live session identifier; the socket connection state for this visitor.
• Component responsibilities. Centred wide input field on the void ground; thin luminous wrapping frame driven by typing velocity; live-streaming indicator; connection-state readout.
• States. Loading: the socket connection to the relay is being established. Empty: the field is empty and the frame sits at its slow-typing cyan baseline. Success: typing is being streamed and the operator can see it. Error: the socket connection drops — the visitor is told the live connection was lost and their typing is no longer being streamed. Recovery: the connection re-establishes and streaming resumes; the visitor's typed content is preserved in the field.

Operator Panel

• Information and state. The operator's instrument. It shows the visitor's live typing as a monospace log with a scrolling vertical rule, the session's keystroke count as a circular SVG gauge with a monospace numeral at its centre, a typing-velocity sparkline, and the current session identity and connection state. It shows which visitor session is currently attached.
• Primary actions. SUCCESS — a full-width hardware-style bar in the accent colour that delivers the success page to the visitor. ERROR — a full-width hardware-style bar in the alarm colour that delivers the error message to the visitor.
• Supporting actions. Watch the live keystroke stream; read the session gauge and velocity sparkline; observe the monospace confirmation line that types out TRANSMITTING… before an outcome fires.
• Domain entities. Live keystroke events; keystroke count; typing velocity over time; session identifier; session connection state; selected outcome.
• Component responsibilities. Two-zone split — left 60% live keystroke log, right 40% instrument cluster (session gauge, velocity sparkline, two stacked outcome bars); monospace confirmation line beneath the outcome controls; live-status pulse.
• States. Loading: the panel is connecting to the relay and awaiting a visitor session. Empty: no visitor session is attached — the log is empty, the gauge reads zero, and the outcome controls are visibly inactive. Success: a visitor session is attached and typing is streaming into the log; the gauge and sparkline update live. Error: the relay connection drops — the panel reports the disconnected state and the outcome controls are disabled so no outcome can be fired into a dead session. Recovery: the panel reconnects and re-attaches to the live session; the log resumes.

Error

• Information and state. The visitor's error outcome surface. It displays the error message delivered by the operator in response to the visitor's input, presented in the alarm colour register.
• Primary actions. Read the error message. Return to the Visitor Input page to type again.
• Supporting actions. None beyond returning to the input surface.
• Domain entities. The delivered error message; the session it belongs to.
• Component responsibilities. Full-bleed alarm-register surface; the error message as the primary readable element; a return control back to the Visitor Input page.
• States. Loading: the outcome is being received over the socket. Empty: no outcome has been delivered yet — the surface shows a waiting state rather than a fabricated error. Success: the operator's error message is displayed. Error: the outcome could not be received — the surface reports that the connection was lost before the outcome arrived. Recovery: the visitor can return to the Visitor Input page and start a new live session.

Success

• Information and state. The visitor's success outcome surface. It displays the success page delivered by the operator, presented in the accent colour register.
• Primary actions. Read the success result. Return to the Visitor Input page to type again.
• Supporting actions. None beyond returning to the input surface.
• Domain entities. The delivered success result; the session it belongs to.
• Component responsibilities. Full-bleed accent-register surface; the success result as the primary readable element; a return control back to the Visitor Input page.
• States. Loading: the outcome is being received over the socket. Empty: no outcome has been delivered yet — the surface shows a waiting state rather than a fabricated success. Success: the operator's success page is displayed. Error: the outcome could not be received — the surface reports that the connection was lost before the outcome arrived. Recovery: the visitor can return to the Visitor Input page and start a new live session.

Visitor Outcome

• Information and state. The visitor's received-outcome state. It owns the truth of which outcome the operator delivered to this visitor's session — error or success — and reflects that state consistently with the Error and Success surfaces.
• Primary actions. Observe the received outcome state; continue to the corresponding outcome surface.
• Supporting actions. None beyond observing and continuing.
• Domain entities. Received outcome type (error or success); the session it belongs to; the moment it was delivered.
• Component responsibilities. Outcome-state readout bound to the live session; routing into the Error or Success surface according to the delivered outcome.
• States. Loading: awaiting the operator's decision. Empty: no outcome has been delivered for this session. Success: the delivered outcome is recorded and shown. Error: the session ended before an outcome arrived — the state reports that no outcome was received. Recovery: the visitor can start a new live session from the Visitor Input page.

3. Functional Requirements

Live capture of visitor typing

FR-1 — Live keystroke streaming to the operator. As a Site Owner / Operator, I should see what the visitor is typing arrive live over a socket connection, so that I can watch a stranger think in real time.

• Provenance: explicit.
• Trigger / input: the visitor types into the Visitor Input page while a live session is active.
• Observable result: each keystroke event appears in the Operator Panel's monospace log as it is typed, and the session gauge and velocity sparkline update.
• Access state: the Operator Panel is a first-party page reachable directly; no account or login is required by the accepted requirements.
• Failure / recovery: if the relay connection drops, the panel reports the disconnected state and the outcome controls are disabled; on reconnect the panel re-attaches and the log resumes.
• Continuation: the operator continues watching until they choose to fire an outcome.

FR-2 — Visitor typing surface with live feedback. As a Visitor, I should type into a live input field that visibly responds to my own typing, so that I can see myself being watched as I write.

• Provenance: explicit (the input surface) with required_inference for the live frame feedback.
• Trigger / input: the visitor opens the Visitor Input page and begins typing.
• Observable result: the typed text appears in the field, and the thin luminous frame around the field animates from cyan toward hot magenta in real time with the visitor's typing speed.
• Access state: anonymous; no account required.
• Failure / recovery: if the socket connection drops, the visitor is told the live connection was lost and their typing is no longer being streamed; on reconnect, streaming resumes with the typed content preserved.
• Continuation: the visitor keeps typing until the operator delivers an outcome.

FR-3 — Backend socket relay. As a system, the backend socket service should relay visitor typing to the operator panel in real time, so that the accepted live-capture journey is executable.

• Provenance: required_inference.
• Trigger / input: keystroke events emitted by the visitor's client.
• Observable result: the events are delivered to the connected operator panel with live latency.
• Access state: internal service; not a human-facing surface.
• Failure / recovery: on relay failure, both the visitor surface and the operator panel report the disconnected state; the relay re-establishes connections when it returns.
• Continuation: the relay continues forwarding until the session ends.

FR-4 — Shared live session. As a Visitor and as a Site Owner / Operator, we should be joined by an active shared session before live input and outcome delivery can occur, so that the operator's decision reaches the correct visitor.

• Provenance: required_inference.
• Trigger / input: the visitor opens the Visitor Input page and the operator panel is connected.
• Observable result: the operator panel shows the attached session identity and connection state; the visitor's typing streams into that session.
• Access state: anonymous on both sides; the session, not an account, binds the two participants.
• Failure / recovery: if no visitor session is attached, the operator panel shows an empty state with inactive outcome controls; if the session ends, both sides report it.
• Continuation: the session persists until an outcome is delivered or a participant disconnects.

Operator-triggered outcomes

FR-5 — Deliver an error message to the visitor. As a Site Owner / Operator, I should be able to click a button to give the visitor an error message, so that I can end the session with a failure outcome based on what they typed.

• Provenance: explicit.
• Trigger / input: the operator clicks the ERROR control on the Operator Panel while a visitor session is attached.
• Observable result: the monospace confirmation line types out TRANSMITTING…, the error message is delivered over the socket, and the visitor's screen shows the Error surface with that message.
• Access state: first-party operator page, reachable directly; no account required by the accepted requirements.
• Failure / recovery: if the relay connection is down, the control is disabled and no outcome is fired; if delivery fails, the operator panel reports the failure and the control becomes available again.
• Continuation: the visitor can return to the Visitor Input page to start a new live session.

FR-6 — Deliver a success page to the visitor. As a Site Owner / Operator, I should be able to click a button to say success page, so that I can end the session with a success outcome based on what they typed.

• Provenance: explicit.
• Trigger / input: the operator clicks the SUCCESS control on the Operator Panel while a visitor session is attached.
• Observable result: the monospace confirmation line types out TRANSMITTING…, the success result is delivered over the socket, and the visitor's screen shows the Success surface.
• Access state: first-party operator page, reachable directly; no account required by the accepted requirements.
• Failure / recovery: if the relay connection is down, the control is disabled and no outcome is fired; if delivery fails, the operator panel reports the failure and the control becomes available again.
• Continuation: the visitor can return to the Visitor Input page to start a new live session.

FR-7 — Operator panel remains connected to deliver the outcome. As a Site Owner / Operator, I should stay connected to the relay so that the outcome I choose actually reaches the visitor, so that my decision is not silently lost.

• Provenance: required_inference.
• Trigger / input: the operator panel holds an open socket connection to the relay.
• Observable result: the live-status pulse and connection readout show the panel as connected; outcome controls are enabled only while connected.
• Access state: first-party operator page.
• Failure / recovery: on disconnect, the panel reports the disconnected state and disables both outcome controls; on reconnect, the controls re-enable and the live log resumes.
• Continuation: the operator can fire an outcome once the connection is restored.

Visitor receipt of the outcome

FR-8 — Visitor receives the operator's error message. As a Visitor, I should see the error message the operator sent me, so that I know the outcome of my input.

• Provenance: explicit.
• Trigger / input: the operator fires the ERROR control for this visitor's session.
• Observable result: the Error surface displays the delivered error message in the alarm colour register.
• Access state: anonymous; no account required.
• Failure / recovery: if the outcome cannot be received because the connection was lost, the surface reports that rather than showing a fabricated error; the visitor can return to the Visitor Input page and start a new session.
• Continuation: the visitor returns to the Visitor Input page to type again.

FR-9 — Visitor receives the operator's success page. As a Visitor, I should see the success page the operator sent me, so that I know the outcome of my input.

• Provenance: explicit.
• Trigger / input: the operator fires the SUCCESS control for this visitor's session.
• Observable result: the Success surface displays the delivered success result in the accent colour register.
• Access state: anonymous; no account required.
• Failure / recovery: if the outcome cannot be received because the connection was lost, the surface reports that rather than showing a fabricated success; the visitor can return to the Visitor Input page and start a new session.
• Continuation: the visitor returns to the Visitor Input page to type again.

FR-10 — Visitor outcome state is owned truthfully. As a Visitor, I should have a single consistent record of which outcome was delivered to my session, so that the Error and Success surfaces never disagree about what happened.

• Provenance: required_inference.
• Trigger / input: the operator delivers an error or success outcome to this session.
• Observable result: the Visitor Outcome surface reflects the delivered outcome type and routes the visitor into the corresponding Error or Success surface.
• Access state: anonymous; bound to the live session.
• Failure / recovery: if the session ends before an outcome arrives, the state reports that no outcome was received rather than inventing one.
• Continuation: the visitor can start a new live session from the Visitor Input page.

Public entry

FR-11 — Explain the live interaction before participation. As a Visitor or Site Owner / Operator, I should understand from the Landing page what the live visitor interaction is and that an operator controls the response, so that I know what I am entering.

• Provenance: required_inference.
• Trigger / input: the user opens the Landing page.
• Observable result: the page presents the live socket status readout, the headline explaining the interaction, and the two entry controls.
• Access state: anonymous; no account required.
• Failure / recovery: if the relay is unreachable, the status label reports the disconnected state and both entry controls remain usable.
• Continuation: the user proceeds to the Visitor Input page or the Operator Panel.

4. User Personas

Site Owner / Operator

Product context. The operator is the person who owns and runs noneid. They are a tinkerer and a maker who wants a small instrument that feels alive and slightly uncanny — something they can open, watch, and end with one click. They are not managing a queue of customers or a support inbox; they are watching one stranger think in real time.

Primary goal. To watch a visitor's typing arrive live and then decide, with a single click, how that visitor's session ends — with an error message or with a success page.

Distinct accepted responsibilities. The operator is the only participant who reads the live keystroke stream, the only participant who reads the session gauge and typing-velocity sparkline, and the only participant who fires an outcome. They hold the decision authority in this product: the visitor types, but the operator decides. They must also keep the panel connected, because an outcome fired into a dead connection never reaches the visitor.

Relevant inputs and decisions. Their inputs are the incoming keystroke events, the keystroke count, and the typing velocity over time. Their decision is binary and irreversible for the session: SUCCESS or ERROR. They read the monospace confirmation line to know the outcome is transmitting.

Interactions with other accepted participants. The operator never speaks to the visitor directly. Their entire relationship with the visitor is mediated by the socket relay: the visitor's typing arrives, and the operator's decision returns. The operator's action is the sole cause of the visitor's Error or Success surface.

Observable success. The visitor's screen shows the outcome the operator chose, and the operator's panel confirms the transmission.

Visitor

Product context. The visitor is an anonymous person who arrives at noneid and types into the live input field. They have no account, no profile, and no prior relationship with the site. They are, knowingly or not, the subject of the piece: their typing is the artwork the operator is watching.

Primary goal. To type into the site and see what happens as a result.

Distinct accepted responsibilities. The visitor is the only participant who produces the input that drives the entire product. They type, they see their own typing reflected in the live frame around the field, and they receive the outcome the operator chooses. They cannot choose their own outcome — that authority belongs entirely to the operator.

Relevant inputs and decisions. Their input is the text they type and the rhythm at which they type it, which drives both the live frame colour and the operator's velocity sparkline. Their only decision is whether to keep typing or to return to the input page after an outcome.

Interactions with other accepted participants. The visitor never sees the operator. They experience the operator only as the arrival of an error message or a success page on their own screen.

Observable success. The visitor sees the resulting response to their input — either the operator's error message or the operator's success page — and can start again.

5. Core User Flows

Flow A — Visitor types and is watched live

1. The Visitor opens the Landing page. The full-bleed generative canvas initializes, the corner status label reads LIVE SOCKET // 0 CLIENTS with a pulsing accent dot, and the headline WATCH THEM TYPE. DECIDE WHAT HAPPENS. sits flush-left with a single body line beneath it.
2. The Visitor selects OPEN VISITOR VIEW and arrives at the Visitor Input page.
3. The Visitor Input page establishes a live socket connection to the relay. While connecting, the page shows its loading state; once connected, the live-streaming indicator confirms the session is active.
4. The Visitor begins typing into the single wide input field. The thin luminous frame around the field animates from cyan #4DD8FF toward hot magenta #FF3D6E in real time with their typing speed, so the visitor can see themselves being watched.
5. Each keystroke is emitted over the socket and relayed by the backend socket service to the connected operator panel.
6. Failure / recovery: if the socket connection drops mid-typing, the Visitor Input page tells the visitor the live connection was lost and their typing is no longer being streamed. When the connection re-establishes, streaming resumes and the typed content is preserved in the field.
7. Continuation: the visitor keeps typing until the operator delivers an outcome.

Flow B — Operator watches the live stream

1. The Site Owner / Operator opens the Landing page and selects OPERATOR PANEL.
2. The Operator Panel opens in its loading state and connects to the relay.
3. If no visitor session is attached, the panel shows its empty state: the monospace log is empty, the circular session gauge reads zero, and both outcome controls are visibly inactive.
4. When a visitor session attaches, the panel shows the attached session identity and connection state, and the live-status pulse confirms the connection.
5. The visitor's keystrokes arrive in the left 60% of the panel as a monospace log with a scrolling vertical rule. The right 40% instrument cluster updates live: the circular SVG gauge's stroke-dasharray tracks the session's keystroke count with a JetBrains Mono numeral at its centre, and the typing-velocity sparkline traces the visitor's typing rhythm.
6. Failure / recovery: if the relay connection drops, the panel reports the disconnected state and disables both outcome controls so no outcome can be fired into a dead session. On reconnect, the panel re-attaches to the live session, the controls re-enable, and the log resumes.
7. Continuation: the operator keeps watching until they decide to fire an outcome.

Flow C — Operator delivers an error message

1. The Site Owner / Operator is on the Operator Panel with a visitor session attached and typing streaming into the log.
2. The operator reads the live keystroke stream and decides, based on what the visitor has typed, to end the session with an error.
3. The operator clicks the ERROR control — the full-width hardware-style bar in the alarm colour #FF3D6E at the bottom of the instrument cluster.
4. The monospace confirmation line beneath the control types out TRANSMITTING… before the outcome fires.
5. The backend socket service relays the error message to the visitor's session.
6. The Visitor's screen shows the Error surface with the delivered error message in the alarm colour register. The Visitor Outcome state records that an error outcome was delivered to this session, keeping the Error and Success surfaces consistent.
7. Failure / recovery: if the relay connection is down, the control is disabled and no outcome is fired. If delivery fails, the operator panel reports the failure and the control becomes available again.
8. Continuation: the visitor can return to the Visitor Input page to start a new live session.

Flow D — Operator delivers a success page

1. The Site Owner / Operator is on the Operator Panel with a visitor session attached and typing streaming into the log.
2. The operator reads the live keystroke stream and decides, based on what the visitor has typed, to end the session with a success.
3. The operator clicks the SUCCESS control — the full-width hardware-style bar in the accent colour #E8FF4D at the bottom of the instrument cluster.
4. The monospace confirmation line beneath the control types out TRANSMITTING… before the outcome fires.
5. The backend socket service relays the success result to the visitor's session.
6. The Visitor's screen shows the Success surface with the delivered success result in the accent colour register. The Visitor Outcome state records that a success outcome was delivered to this session, keeping the Error and Success surfaces consistent.
7. Failure / recovery: if the relay connection is down, the control is disabled and no outcome is fired. If delivery fails, the operator panel reports the failure and the control becomes available again.
8. Continuation: the visitor can return to the Visitor Input page to start a new live session.

Flow E — Visitor receives the outcome and starts again

1. The Visitor is typing on the Visitor Input page in an active live session.
2. The operator fires an outcome. The visitor's client receives it over the socket.
3. While the outcome is being received, the visitor's screen shows a loading state rather than a fabricated result.
4. The Visitor Outcome state resolves to the delivered outcome type and routes the visitor into the corresponding surface: the Error page for an error message, or the Success page for a success result.
5. The visitor reads the delivered message or result.
6. Failure / recovery: if the outcome cannot be received because the connection was lost, the surface reports that the connection dropped before the outcome arrived, rather than inventing an error or a success. If the session ends before any outcome arrives, the Visitor Outcome state reports that no outcome was received.
7. Continuation: the visitor selects the return control and goes back to the Visitor Input page to start a new live session.

6. Visuals, Colors and Theme

The visual direction is Data made physical: the visitor's keystrokes as a living sculpture, after the muse Refik Anadol. The headline idea: the product's core is literally data made visible — each keystroke is a data point arriving live over a socket, rendered as a generative, luminous flow. The operator panel is a museum-grade instrument; the visitor's typing is the artwork; the operator is the curator who ends the piece.

Colour tokens (dark mode)

The near-black void ground #050508 carries everything. Surfaces are a barely-lifted #0D0D14 with 1px luminous borders at 8% white. The generative keystroke field renders in a multi-hue flow that shifts with input velocity — cyan #4DD8FF at slow typing, hot magenta #FF3D6E and violet #8A5CFF as speed rises. UI chrome stays monochrome so the field is the only colour. #E8FF4D is the single hot accent, reserved for the operator's SUCCESS control and live-status pulses; #FF3D6E is the ERROR control and the alarm state. Body text #F2F0EA on #050508 gives approximately 19:1 contrast. Muted labels #6E6E7A are used only at 14px and above, uppercase with letterspacing, and never for body copy.

Typography

• Headings: Space Grotesk — wide, light-to-medium weights (300–500). Uppercase micro-labels at 11–12px with 0.18em tracking for panel metadata. The hero headline is a single sentence set in 300 weight at 40px mobile to 104px desktop with -0.02em tracking, flush-left, never centred.
• Body: Space Grotesk.
• Numerals and data: JetBrains Mono for keystroke counts, timestamps, and session IDs, so digits read as instrument readouts.
• Scale: 1.333 modular — 104 / 72 / 48 / 32 / 22 / 16 / 13 / 11. Hero clamp(40px, 8vw, 104px); section heads clamp(28px, 4.5vw, 48px); panel labels 11px uppercase 0.18em; body 16px/1.6; data rows 13px JetBrains Mono.

Shape language

Museum-instrument geometry: perfectly circular gauge rings for the live keystroke meter (SVG stroke-dasharray, no rounded rectangles pretending to be dials), thin 1px luminous hairlines at 8–14% white, hard-edged full-bleed canvases with no border radius on the generative field, and small 2px radii on controls so they read as hardware, not as app cards. Panels are flat planes separated by hairline rules and negative space — never floating glass cards with drop shadows.

Layout

The hero is a full-bleed generative canvas at 100vw/100vh with UI text overlaid in the corners, not on top of the flow's densest region. Below the fold, a strict 12-column grid with a 64px gutter at 1280px, collapsing to 4 columns at 375px. The operator panel is a two-zone split: left 60% is the live keystroke stream as a monospace log with a scrolling vertical rule; right 40% is the instrument cluster (session gauge, typing-velocity sparkline, and two oversized outcome controls stacked). The visitor input page centres a single wide field on the void with the live field wrapping it as a thin frame, never behind the text.

Imagery

The imagery is the data: a full-bleed WebGL particle/fluid render whose input is the live socket stream — no stock photography, no device mockups, no illustrated characters. Secondary imagery is generative too: a horizontal keystroke-density ribbon, a radial session gauge, a sparkline of typing velocity. The only non-generative visual is the monospace log text itself, treated as an artefact.

Avoid

Centred headline + subtext + blue button hero compositions; gradient-blob backgrounds and mesh-gradient decoration; grids of identical hover-lift cards with soft shadows; glassmorphism panels with blurred white fills; any blue/indigo primary (#0057FF, #2563EB, #4F46E5, #6366F1, #7C3AED) on a white ground; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui for any text; stock photography of people, device mockups, or flat clip-art illustration; playful bouncy easing, springy hovers, or cartoon micro-interactions. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The gallery wall with an instrument on it.

The public entry is a full-viewport near-black canvas (#050508) where a slow luminous particle field breathes in the middle-right third of the screen, its colour shifting from cyan #4DD8FF toward magenta #FF3D6E as typing velocity rises. The field is masked out of the lower-left quadrant so text contrast is untouchable.

In the top-left corner, an 11px uppercase tracked label reads LIVE SOCKET // 0 CLIENTS in #6E6E7A with a pulsing #E8FF4D dot — a live instrument readout of the relay's connected clients.

In the bottom-left, a flush-left headline in Space Grotesk 300 at clamp(40px, 8vw, 104px) spans up to 9 columns — WATCH THEM TYPE. DECIDE WHAT HAPPENS. — with a single 16px body line beneath it and two hard-edged controls pinned under that: a #E8FF4D OPEN VISITOR VIEW and an outlined OPERATOR PANEL.

Nothing is centred, nothing is a gradient blob, and the composition reads as a gallery wall with an instrument on it. The signature move is that the particle field is not decoration: its particles are literally spawned by incoming keystroke events, with hue and velocity mapped to the visitor's typing rhythm, so the hero is a live portrait of a stranger's thinking.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

Focal subject. A full-bleed WebGL particle field on the near-black void ground #050508, breathing in the middle-right third of the viewport, masked out of the lower-left quadrant where the headline and controls sit.

Input → transformation → outcome thesis. Each incoming keystroke event from the live socket stream spawns a particle burst whose hue and velocity derive from that key's dwell time. Slow typing renders cyan #4DD8FF; rising speed shifts the flow toward hot magenta #FF3D6E and violet #8A5CFF. The outcome is a field that is a live portrait of the visitor's thinking — the artwork is the data, and the data is a stranger typing.

Motion vocabulary. Continuous slow generative flow driven by an actual data feed. The field drifts and morphs on a 20–40 second cycle even when idle, so the hero is never static. Scroll-linked morphing compresses the field into a horizontal ribbon as the operator-panel section enters, turning the hero artwork into the next section's divider. Panel transitions are 240ms opacity/position crossfades, with no bounces.

Composed first frame. The field at rest in the middle-right third, drifting on its idle cycle. Top-left: LIVE SOCKET // 0 CLIENTS in 11px tracked uppercase #6E6E7A with a pulsing #E8FF4D dot. Bottom-left: the flush-left headline WATCH THEM TYPE. DECIDE WHAT HAPPENS. in Space Grotesk 300, a single 16px body line, and the two hard-edged controls — #E8FF4D OPEN VISITOR VIEW and an outlined OPERATOR PANEL.

Reduced-motion state. With prefers-reduced-motion, the canvas renders one static frame of the current data state and the keystroke log becomes a scrollable list. The headline, body line, status label, and both controls remain whole and fully readable at 375px, 768px, and 1280px.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time WebGL scene: a luminous particle field whose particles are spawned by incoming keystroke events. Each particle's hue and velocity map to the visitor's typing rhythm — dwell time drives velocity, typing speed drives the cyan-to-magenta-to-violet shift. The scene shows the product's defining state directly: a live, generative portrait of a stranger's typing, rendered as a breathing data sculpture on a near-black void. The field is masked out of the lower-left quadrant so the headline block and controls sit on clean ground.

9. Non-Functional Requirements

NFR-1 — Real-time delivery. Visitor keystrokes must reach the operator panel with live latency, because the product's entire value is watching a stranger think in real time. Provenance: explicit (the user asked to capture live what the visitor is typing with socket). Rationale: a delayed stream is not a live stream.

NFR-2 — Socket-based transport. The live capture and the outcome delivery must use a socket connection, not polling. Provenance: explicit (the user specified socket). Rationale: the user named the transport.

NFR-3 — Redis-backed session state. Redis is required for the live session state that binds a visitor's typing stream to the operator panel and carries the delivered outcome. Provenance: required_inference, consistent with the planning scope's redis_required: true. Rationale: the shared live session must survive across the relay's connections so the operator's decision reaches the correct visitor.

NFR-4 — Connection-state honesty. Both the visitor surface and the operator panel must report their true connection state, and the operator's outcome controls must be disabled whenever the relay connection is down. Provenance: required_inference. Rationale: an outcome fired into a dead connection would silently fail, and the accepted journey requires the operator's decision to actually reach the visitor.

NFR-5 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Provenance: explicit (creative direction). Rationale: the direction's full-bleed canvas and overlaid corner text must never compromise legibility.

NFR-6 — Reduced-motion support. With prefers-reduced-motion, the generative canvas must render one static frame of the current data state and the keystroke log must become a scrollable list. Provenance: explicit (creative direction). Rationale: the direction's continuous motion must have a usable still equivalent.

NFR-7 — Contrast. Body text #F2F0EA on #050508 must maintain approximately 19:1 contrast, and muted labels #6E6E7A must be used only at 14px and above, uppercase with letterspacing, never for body copy. Provenance: explicit (creative direction). Rationale: the dark palette must remain readable.

10. Tech Stack

• Frontend: React, with a WebGL renderer for the generative keystroke field (React Three Fiber / Three.js) and SVG for the circular session gauge and velocity sparkline.
• Backend: Python with FastAPI, extended with the socket relay routes and modules for the live session and outcome delivery. The relay runs inside the existing backend process, port, and deployment rather than as a separate service.
• Real-time transport: WebSocket connections between the visitor client, the backend relay, and the operator panel.
• Session state: Redis, holding the live session that binds a visitor's typing stream to the operator panel and carries the delivered outcome.
• Containerization: Docker with docker-compose.yml as the inventory of runnable services — the frontend, the backend (including the socket relay), and Redis.
• Typography: Space Grotesk (headings and body) and JetBrains Mono (numerals and data), as specified in the creative direction.

11. Assumptions and Constraints

Assumptions

• A-1. The operator panel is reachable directly as a first-party page. The accepted requirements establish no account, login, or role gate for it, and none is inferred. (Assumption — not specified by user.)
• A-2. The visitor's typed content is held only for the duration of the live session and is not persisted as a transcript or history. No accepted requirement asks for stored history. (Assumption — not specified by user.)
• A-3. The error message delivered by the operator is a message the operator sends; the accepted requirements do not specify an editable message-composition field, so the error message is delivered as the product's error outcome. (Assumption — not specified by user.)
• A-4. The success page is the product's success outcome surface, delivered by the operator's SUCCESS control. (Assumption — not specified by user.)
• A-5. One visitor session is attached to the operator panel at a time, matching the accepted journey of watching a single stranger type. (Assumption — not specified by user.)

Constraints

• C-1. The live capture must use a socket connection, as the user specified.
• C-2. The operator's two outcome controls are the only way a session ends: an error message or a success page.
• C-3. The generic indigo/blue-on-white SaaS template is forbidden for this project.
• C-4. The palette, typography, shape language, layout, and motion specified in the creative direction are binding for this project.
• C-5. No capability beyond live typing capture and the two operator-triggered outcomes is authorized by the accepted requirements.

12. Glossary

• Visitor — the anonymous person who types into the site's input field and receives the operator's chosen outcome.
• Site Owner / Operator — the person who watches the visitor's live typing on the operator panel and clicks a button to deliver an error message or a success page.
• Live session — the active shared socket session that binds a visitor's typing stream to the operator panel and carries the delivered outcome.
• Keystroke event — a single unit of visitor input emitted over the socket as the visitor types.
• Operator Panel — the first-party page where the operator watches the live keystroke stream and fires an outcome.
• Visitor Input — the first-party page where the visitor types and where the live frame responds to their typing speed.
• Error — the visitor-facing surface that displays the error message delivered by the operator.
• Success — the visitor-facing surface that displays the success page delivered by the operator.
• Visitor Outcome — the visitor's received-outcome state, which records whether an error or a success was delivered to the session.
• Socket relay — the backend socket service that forwards visitor typing to the operator panel and the operator's chosen outcome back to the visitor.
• Session gauge — the circular SVG instrument on the operator panel whose stroke-dasharray tracks the session's keystroke count.
• Velocity sparkline — the operator panel's live trace of the visitor's typing speed over time.
• Generative field — the full-bleed WebGL particle render whose particles are spawned by incoming keystroke events.