System Requirements Document for ai-promot

1. Introduction

ai-promot is a prompt-building tool for a working JavaScript developer who already uses DeepSeek as a coding assistant but keeps getting JavaScript back that does not run. The product's intent is narrow and deliberate: take the developer's messy, informal description of a JavaScript coding need and turn it into a well-formed prompt that DeepSeek can act on, so the code that comes back is correct and usable.

The audience is a single working developer — Dimas — who reads code, works in JavaScript, and wants to see exactly what the tool is doing to his input rather than trusting a black box. The tool is therefore built as an instrument, not a chatbot: the developer's raw need sits on one side, the assembled DeepSeek prompt sits on the other, and the transformation between them is visible at every step.

The product does not call DeepSeek on the developer's behalf, does not execute or validate JavaScript, and does not manage DeepSeek accounts. It produces the prompt; the developer takes that prompt to DeepSeek.

2. System Overview

ai-promot is a browser-delivered, first-party web application with four pages in a fixed order: Landing, Task Input, Prompt Generator, and Generated Prompt. All four are anonymously reachable — no account, sign-in, or identity establishment is required anywhere in the product, because the accepted work is a single-session, self-contained transformation of text the developer supplies and reads back.

The only active human actor is the Developer/Pengguna Coding. There are no secondary human participants: nothing in the product transfers value, creates an obligation, or produces a durable state that another person must act on. DeepSeek is an external destination the developer carries the finished prompt to; it is not a participant inside the application and the application never contacts it.

The accepted behavior is a three-step lifecycle: describe the JavaScript need, generate the DeepSeek-ready prompt, review and copy the result. The application owns the description state, the generation step, and the generated artefact. The developer owns the decision to copy and the act of pasting into DeepSeek.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is delivered as a custom first-party web UI. Every page is application-owned and anonymously accessible. There is no login, no user record, no saved history, and no server-side persistence of the developer's task text or generated prompts. State lives for the duration of the working session in the browser.

Access ownership. Access is open. The Planning Scope assigns access_requirement: none to all four surfaces, and the accepted journeys contain no commitment, entitlement, or value transfer that must remain bound to a verified identity. No identity establishment, invitation, provisioning, or account-management capability is in scope, and none is inferred.

Current vs. future. Current scope is exactly the four pages and the three accepted requirements: a prompt generator for coding needs, aimed at developers using DeepSeek for JavaScript, that removes the difficulty they hit when DeepSeek produces unusable JavaScript. Anything beyond that — calling DeepSeek directly, validating generated code, saving prompt libraries, supporting other languages or other models — is out of current scope and is not built.

Hard constraint. The tool is focused on prompt creation for JavaScript coding with AI DeepSeek. This is a scoping constraint on the product's subject matter, not a prohibition on the developer pasting any text they like into the task field.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Explains, in one screen, what the tool does: it turns a JavaScript coding need into a prompt that DeepSeek can act on. States the intended user (a developer using DeepSeek for JavaScript) and the problem being solved (DeepSeek returning JavaScript that does not run). No user state is read or displayed.
• Primary action. A single vermilion call-to-action that enters the task-description step. This is the only primary action on the page.
• Supporting actions. Hovering either half of the split to shift emphasis between the editorial half and the code half. No other controls.
• Domain entities. None persisted. The page displays a static illustrative pair: a broken DeepSeek JavaScript output and a clean generated prompt.
• Component responsibilities.
  • Split hero (55/45). Left half on warm paper carries the oversized headline, two lines of muted subcopy, and the CTA pinned bottom-left. Right half is a full-bleed deep-ink code panel.
  • Headline. Instrument Sans at display scale, with the words DeepSeek and JavaScript set in JetBrains Mono inline, so the technical register leaks into the editorial half.
  • Before/after code panel. Two stacked code blocks separated by a hairline seam: the upper block shows broken JavaScript with red-underlined error lines; the lower block shows the generated prompt in warm code text with vermilion string literals.
  • Split divider. A 1px vertical rule that thickens to 2px and turns vermilion on hover, with the two halves swapping emphasis.
  • Schematic. A small task → prompt → DeepSeek diagram, drawn on the 8-pt grid with 1.5px strokes.
  • Wireframe-to-render treatment. A half-drawn box model that resolves into a finished component on hover.
• States. Loading: none — the page is static. Empty: not applicable. Success: the CTA is present and reachable at all times. Error: not applicable. Recovery: not applicable.

Task Input

• Information and state. Holds the developer's in-progress description of the JavaScript coding need. The description is the only input state on the page. A live monospace preview of the prompt being assembled is shown alongside it and updates as the description changes.
• Primary action. Submit the description to generate the prompt.
• Supporting actions. Type, edit, and clear the description; read the live preview; return to Landing.
• Domain entities. Task description — free text, authored by the developer, describing the JavaScript coding need. Prompt preview — a derived, read-only monospace rendering of the prompt under assembly.
• Component responsibilities.
  • Split layout. Left column holds the task description as a plain text area on a white panel; right column holds the live monospace preview.
  • Task description text area. White surface, ink text, vermilion caret, 6px radius, hairline warm-grey border. Accepts free text with no format requirement.
  • Live prompt preview. Deep-ink code panel with warm code text and vermilion string literals, updating as the description changes.
  • Submit control. Compact rectangular button, 6px radius, vermilion fill, ink label. Disabled while the description is empty.
  • Validation message. Muted helper text adjacent to the text area when submission is attempted with no usable description.
• States. Loading: the preview updates synchronously; no spinner. Empty: the text area is empty, the preview shows an empty prompt skeleton, and the submit control is disabled. Success: a usable description is present and submission advances to Prompt Generator. Error: submission attempted with an empty or whitespace-only description — the submit control stays disabled and a muted message states that a JavaScript task description is required. Recovery: the developer types a description and the submit control enables.

Prompt Generator

• Information and state. Shows the generation of the DeepSeek-ready prompt from the submitted task description. Displays the source description for reference and the prompt as it is assembled.
• Primary action. Run generation.
• Supporting actions. Re-run generation; return to Task Input to revise the description; continue to Generated Prompt when generation completes.
• Domain entities. Task description — the submitted text, carried forward read-only. Generated prompt — the assembled DeepSeek-ready prompt text.
• Component responsibilities.
  • Full-bleed dark code surface. Deep-ink ground with warm code text and vermilion string literals.
  • Thin left rail of controls. Compact rectangular controls at 6px radius: run generation, revise the description, continue to the result.
  • Source description strip. Read-only display of the submitted JavaScript task description.
  • Prompt assembly area. The prompt text, revealed character-by-character at 18ms per character with a blinking vermilion caret when generation completes.
  • Progress indication. A restrained functional indicator during assembly; no bounce, no decorative motion.
• States. Loading: generation is running — the assembly area shows a functional progress state and the continue control is unavailable. Empty: no description was carried in (for example, a direct visit) — the page states that a JavaScript task description is needed and offers a route back to Task Input. Success: the prompt is fully assembled, the caret stops blinking, and the continue control becomes available. Error: generation fails to produce a prompt — the assembly area shows a plain failure message and the run control remains available for a retry. Recovery: re-running generation, or returning to Task Input to revise the description and submitting again.

Generated Prompt

• Information and state. Presents the finished DeepSeek-ready prompt as a single reviewable artefact, with a metadata strip describing it.
• Primary action. Copy the generated prompt to the clipboard.
• Supporting actions. Read the full prompt; return to Prompt Generator to regenerate; return to Task Input to revise the description.
• Domain entities. Generated prompt — the final prompt text. Metadata — model (DeepSeek), language (JavaScript), and token count for the generated prompt.
• Component responsibilities.
  • Artefact card. A single white card centred on the warm paper ground, holding the prompt text in JetBrains Mono.
  • Metadata strip. Small-caps row beneath the prompt showing model, language, and token count.
  • Copy control. Compact rectangular button, 6px radius, that flashes vermilion on successful copy.
  • Copy confirmation. A brief vermilion flash plus a short confirmation label; no modal.
  • Navigation controls. Compact controls back to Prompt Generator and Task Input.
• States. Loading: none — the prompt is already assembled. Empty: no prompt is available (for example, a direct visit) — the card states that no prompt has been generated yet and offers a route to Task Input. Success: the prompt is displayed with its metadata strip and the copy control is available. Error: the clipboard write is refused by the browser — a muted message states that the copy did not succeed and the prompt text remains fully selectable for manual copying. Recovery: retry the copy, or select the prompt text manually.

3. Functional Requirements

FR-1 — Generate a coding prompt from a described need As a Developer/Pengguna Coding, I should be able to turn a description of my JavaScript coding need into a ready-to-use prompt, so that I have something concrete to give DeepSeek instead of an unstructured request.

• Provenance: explicit.
• Trigger / input: the developer submits a free-text description of a JavaScript coding need from Task Input.
• Observable result: a prompt artefact is produced and presented on Generated Prompt, with a metadata strip showing model (DeepSeek), language (JavaScript), and token count.
• Access state: anonymous; no identity required.
• Failure / recovery: if generation produces no prompt, Prompt Generator shows a plain failure message and the run control stays available for a retry; the developer may also return to Task Input to revise the description.
• Continuation: the developer copies the prompt and takes it to DeepSeek.

FR-2 — Target the prompt at DeepSeek for JavaScript As a Developer/Pengguna Coding, I should get a prompt shaped for DeepSeek and scoped to JavaScript, so that the assistant receives instructions in the form it handles best for this language.

• Provenance: explicit.
• Trigger / input: the same submission as FR-1; the tool applies its DeepSeek/JavaScript framing to the assembled prompt.
• Observable result: the generated prompt is presented as a DeepSeek prompt for JavaScript, and the metadata strip names model DeepSeek and language JavaScript.
• Access state: anonymous.
• Failure / recovery: if the assembled prompt does not carry the DeepSeek/JavaScript framing, the developer re-runs generation from Prompt Generator.
• Continuation: the developer reviews the prompt on Generated Prompt.

FR-3 — Remove the difficulty of getting usable JavaScript from DeepSeek As a Developer/Pengguna Coding, I should be able to see and shape what goes into the prompt, so that DeepSeek stops returning JavaScript that does not run.

• Provenance: explicit.
• Trigger / input: the developer types or edits the task description on Task Input.
• Observable result: a live monospace preview of the prompt under assembly updates as the description changes, so the developer can see the effect of their wording before generating.
• Access state: anonymous.
• Failure / recovery: if the preview does not reflect a change, the developer edits the description again; the preview is derived from the description and re-renders on each change.
• Continuation: the developer submits the description to generate the prompt.

FR-4 — Describe the JavaScript need in free text As a Developer/Pengguna Coding, I should be able to write my coding need in my own words without a required format, so that I can start from whatever I actually have.

• Provenance: required_inference (indispensable input mechanic for FR-1).
• Trigger / input: the developer types into the task description text area on Task Input.
• Observable result: the description is held as the page's input state and drives the live preview.
• Access state: anonymous.
• Failure / recovery: submission with an empty or whitespace-only description is refused — the submit control stays disabled and a muted message states that a JavaScript task description is required.
• Continuation: the developer submits a usable description.

FR-5 — Review and copy the generated prompt As a Developer/Pengguna Coding, I should be able to read the finished prompt in full and copy it in one action, so that I can paste it into DeepSeek without retyping it.

• Provenance: required_inference (indispensable completion mechanic for FR-1).
• Trigger / input: the developer activates the copy control on Generated Prompt.
• Observable result: the prompt text is placed on the clipboard and the copy control flashes vermilion with a short confirmation label.
• Access state: anonymous.
• Failure / recovery: if the browser refuses the clipboard write, a muted message states that the copy did not succeed and the prompt text remains fully selectable for manual copying.
• Continuation: the developer pastes the prompt into DeepSeek.

FR-6 — Regenerate or revise before committing to a prompt As a Developer/Pengguna Coding, I should be able to re-run generation or go back and change my description, so that I am not stuck with a prompt that does not fit my need.

• Provenance: required_inference (indispensable recovery and continuation mechanic for FR-1 and FR-3).
• Trigger / input: the developer activates re-run on Prompt Generator, or navigates back to Task Input and edits the description.
• Observable result: a new prompt is assembled on Prompt Generator, or the description is restored for editing on Task Input with the live preview following it.
• Access state: anonymous.
• Failure / recovery: if a re-run fails, the previous prompt remains readable and the run control stays available.
• Continuation: the developer continues to Generated Prompt with the prompt they accept.

4. User Personas

Developer/Pengguna Coding

Product context. Dimas is a working developer who writes JavaScript and already uses DeepSeek as a coding assistant. He is not looking for an introduction to AI coding tools — he is already in that workflow and it is failing him in a specific way. DeepSeek keeps returning JavaScript that does not run, and the failure is not in DeepSeek's capability but in what he is handing it: an unstructured, under-specified request. He reads code fluently, so he wants to see the machinery of the prompt, not be told to trust it.

Primary goal. Get a prompt that makes DeepSeek produce JavaScript that is correct and usable, so his coding work moves forward instead of stalling on bad output.

Distinct accepted responsibilities.

• Describing the JavaScript coding need in his own words, in free text, with no required format.
• Reading the live monospace preview of the prompt as it is assembled from his description, and adjusting his wording based on what he sees.
• Submitting the description to generate the prompt.
• Running or re-running generation, and deciding whether the result is worth keeping.
• Reviewing the finished prompt in full on the artefact card, including its metadata strip (model, language, token count).
• Copying the prompt and carrying it to DeepSeek himself.

Relevant inputs and decisions. The input is his own description of a JavaScript task. The decisions are: whether the description is specific enough to submit, whether the live preview shows the prompt he wants, whether to re-run generation or revise the description, and whether the finished prompt is good enough to copy.

Interactions with other accepted participants. None inside the product. The Developer/Pengguna Coding is the only active human actor; no other person's state, decision, or receipt depends on his work. DeepSeek is an external destination he carries the prompt to, not a participant in the application.

Observable success. He reaches Generated Prompt, reads a prompt that reflects his JavaScript need and is framed for DeepSeek, copies it in one action with a vermilion confirmation flash, and pastes it into DeepSeek.

What makes this role distinct. The work is a single-session authoring-and-handoff loop performed by one person who reads code. There is no reviewer, no approver, no recipient, and no shared state — which is exactly why the product has no accounts, no roles, and no permissions.

5. Core User Flows

Flow 1 — From a JavaScript need to a DeepSeek-ready prompt

Starting context. Dimas has a JavaScript coding need and has been getting unusable output from DeepSeek. He opens ai-promot anonymously; no sign-in is involved.

1. Landing. Dimas arrives on the split hero. The left half states what the tool does in an oversized Instrument Sans headline with DeepSeek and JavaScript set in JetBrains Mono inline; the right half shows the before/after code panel — a broken DeepSeek JavaScript output with red-underlined error lines above a clean generated prompt. He reads the comparison and recognises his own problem.
2. Enter the task step. Dimas activates the single vermilion call-to-action pinned bottom-left. The application opens Task Input.
3. Describe the need. On Task Input, Dimas types his JavaScript coding need into the plain text area on the white left panel, in his own words and with no required format.
4. Read the live preview. As he types, the right-hand deep-ink panel shows a live monospace preview of the prompt being assembled from his description. Dimas reads it, notices his description is under-specified, and edits the text. The preview follows the edit.
5. Submit. Dimas activates the vermilion submit control. The application opens Prompt Generator carrying his description.
6. Generate. On the full-bleed dark code surface, Dimas activates run generation from the thin left rail. The source description is shown read-only above the assembly area.
7. Watch the prompt assemble. The prompt types in character-by-character at 18ms per character with a blinking vermilion caret. Dimas reads it as it appears.
8. Decide. The prompt finishes assembling; the caret stops and the continue control becomes available. Dimas judges that one part of the prompt does not match his need.
9. Recover by revising. He activates the control back to Task Input, edits the description, and submits again. Prompt Generator assembles a new prompt from the revised description.
10. Review the artefact. Satisfied, Dimas continues to Generated Prompt. The prompt appears as a single white artefact card centred on the warm paper ground, in JetBrains Mono, with a small-caps metadata strip beneath it reading model: DeepSeek, language: JavaScript, and the token count.
11. Copy. Dimas activates the copy control. The button flashes vermilion and a short confirmation label appears. The prompt is on his clipboard.
12. Continue outside the product. Dimas pastes the prompt into DeepSeek. The application's part of the work is complete; it does not contact DeepSeek and does not see the result.

Failure and recovery in this flow.

• Empty description. If Dimas activates submit with an empty or whitespace-only description, the submit control stays disabled and a muted message states that a JavaScript task description is required. He types a description and the control enables.
• Generation produces nothing. If generation fails, the assembly area on Prompt Generator shows a plain failure message and the run control stays available. Dimas re-runs generation, or returns to Task Input to revise the description.
• Clipboard refused. If the browser refuses the clipboard write on Generated Prompt, a muted message states that the copy did not succeed and the prompt text remains fully selectable. Dimas selects the text manually and copies it.
• Direct visit to a later page. If Dimas opens Prompt Generator or Generated Prompt without a description or prompt in session, the page states what is missing and offers a route back to Task Input. No protected state is exposed, because there is none.

Flow 2 — Recovering from a prompt that still does not fit

Starting context. Dimas is on Generated Prompt with a prompt he has already copied, but he decides the JavaScript need was described too narrowly.

1. Return. From Generated Prompt, Dimas activates the control back to Prompt Generator.
2. Re-run. He activates run generation again. The assembly area re-runs and the prompt types in again at 18ms per character with the blinking vermilion caret.
3. Or revise at the source. If re-running is not enough, he activates the control back to Task Input, where his description is still present for editing and the live monospace preview follows his changes.
4. Resubmit. He submits the revised description and Prompt Generator assembles a new prompt.
5. Complete. He continues to Generated Prompt, reviews the new artefact card and metadata strip, and copies it.

Observable result. A prompt that matches the revised description, on the clipboard, ready for DeepSeek.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Adham Dannaway, and the headline idea is split craft: a code half and a voice half, in dialogue. The interface metaphor is the layout: the developer's messy JavaScript need on one side, the generated DeepSeek prompt on the other, with the seam between them as the product's signature.

Colour tokens — light mode

Code panel tokens. Ground #14161A; code text #F1EDE6; string literals #FF4A1C. The dark panel carries the faintest inset shadow so it reads as a physical insert set into the paper ground.

Typography. Headings use Instrument Sans at 700–800 with tight tracking (-0.03em) and sentence case. Body uses Instrument Sans. The technical half switches to JetBrains Mono at 14–16px with normal tracking and a lowercase, editor-like voice. No all-caps shouting and no thin weights.

Type scale. 1.25 modular: 72 / 56 / 40 / 28 / 18 / 16 / 14. Display on the split hero is clamp(40px, 9vw, 88px); section heads are clamp(28px, 4vw, 44px); body is 16px/1.55; code is 14px/1.6.

Shape language. Precise 8-pt spacing. Hairline 1px rules in a warm grey. Small radii of 6–10px on panels and controls; sharp corners on the split divider. Buttons are compact and rectangular with a 6px radius — no pills. The split hero divider is a 1px vertical rule that becomes a 2px vermilion line on hover.

Layout. Asymmetric split-screen is the core layout idea. The Landing hero is a 55/45 split: the left half is the editorial voice with an oversized headline, two lines of subcopy, and a single vermilion CTA pinned bottom-left; the right half is a deep-ink code panel showing a real before/after with a hairline seam between the broken output and the clean prompt. Task Input keeps the split — the left column holds the JavaScript task description as a plain text area on white, the right column is a live monospace preview of the prompt being assembled. Prompt Generator is a full-bleed dark code surface with a thin left rail of controls. Generated Prompt is a single white artefact card centred on paper with a copy button and a metadata strip.

Imagery. No stock photography and no photography of people. The imagery is the interface itself: real JavaScript snippets, the broken-output/clean-output comparison rendered as two code blocks, a small schematic showing task → prompt → DeepSeek, and a wireframe-to-render treatment on the landing where a half-drawn box model becomes a finished component on hover. Icons are 1.5px stroke, drawn on the same 8-pt grid as the layout.

Forbidden. The generic indigo/blue-on-white SaaS template. No blue–indigo primary anywhere in the UI — no #0057FF, #2563EB, #4F46E5, #6366F1, #7C3AED or neighbours. No Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui for headings or body. No identical hover-lift card grids, no glassmorphism or frosted panels, no gradient blobs, no rounded pill buttons, no oversized soft radii, and no decorative animation that does not reveal or explain the split.

Readable text and controls. 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 them. Imagery and decoration may be cropped, bled, rotated, or overlapped as the direction asks, provided they cover no readable text or control.

7. Signature Design Concept

The seam is the product. The public entry is a 55/45 split screen with no centred headline and no gradient blob. The left half sits on warm paper #F1EDE6: an oversized Instrument Sans headline at clamp(40px, 9vw, 88px) in ink, wrapping to two lines, with the words DeepSeek and JavaScript set in JetBrains Mono inside the headline so the technical half literally leaks into the editorial half. Beneath it, two lines of muted subcopy and a single vermilion #FF4A1C rectangular CTA pinned to the bottom-left of the half.

The right half is a full-bleed deep-ink code panel with a 1px seam down the middle. The top block shows a red-underlined broken JavaScript output; the bottom block shows the generated prompt in warm code text with vermilion string literals. The two halves are separated by a 1px rule that thickens and turns vermilion on hover, and the whole hero is flat — depth comes from the seam and the panel inset, not from 3D.

The concept is implementable with the accepted content alone: the headline, the subcopy, the CTA, the two code blocks, the seam, and the schematic. It recomposes accepted states and controls and introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject. The split itself: the editorial half and the deep-ink code panel, joined by the 1px seam, with the before/after code comparison as the panel's content.
• Input → transformation → outcome thesis. Hovering the code panel dims the editorial half slightly and lifts the code panel forward; hovering the editorial half does the reverse. The seam thickens from 1px to 2px and turns vermilion as emphasis crosses it. The outcome is that the developer feels the two halves as one instrument — his need on one side, the prompt on the other — before he has typed anything.
• Motion vocabulary. Reveal-by-hover across the split; the split divider animating its width on scroll; the wireframe-to-render treatment resolving a half-drawn box model into a finished component on hover; 140–200ms functional transitions everywhere else. No bounce, no parallax theatrics.
• Composed first frame. Left half on warm paper: the two-line Instrument Sans headline with DeepSeek and JavaScript in JetBrains Mono inline, muted subcopy beneath, vermilion CTA pinned bottom-left. Right half: the deep-ink panel with the broken JavaScript output above the clean generated prompt, hairline seam between them, faint inset shadow. The 1px divider sits between the halves in warm grey.
• Reduced-motion state. With prefers-reduced-motion, the split renders as a static two-column arrangement at desktop widths and stacks into a single readable column at narrow widths. The seam stays a static 1px warm-grey rule, the code panel keeps its inset shadow, and the before/after blocks remain fully readable. No hover emphasis swap, no divider width animation, and no wireframe-to-render transition — the finished component is shown directly.

Prompt preview motion. On Prompt Generator, the assembled prompt types in character-by-character at 18ms per character with a blinking vermilion caret when generation completes. Under prefers-reduced-motion, the prompt appears in full immediately with no caret animation.

9. Non-Functional Requirements

• NFR-1 — Anonymous access. All four pages are reachable without an account, sign-in, or identity establishment. Provenance: explicit Planning Scope access contract (access_requirement: none on every surface). Rationale: the accepted work is a single-session text transformation with no commitment, entitlement, or value transfer that must be bound to a verified identity.
• NFR-2 — No server-side persistence of task text or prompts. The developer's description and the generated prompt are not stored beyond the working session. Provenance: required_inference. Rationale: no accepted requirement asks for history, saved prompts, or cross-session resume, and storing them would create a durable record the source never accepted.
• NFR-3 — No outbound call to DeepSeek. The application never contacts DeepSeek or any external model provider. Provenance: explicit. Rationale: the accepted requirement is to produce a prompt the developer carries to DeepSeek; the source assigns DeepSeek to the developer's own use, not to the application.
• NFR-4 — Readable text and controls at every viewport. Headlines, labels, numbers, card text and controls remain entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, with nothing covering them. Provenance: explicit creative direction constraint.
• NFR-5 — Reduced-motion support. With prefers-reduced-motion, the split hero renders as a usable static arrangement and the prompt preview appears in full without typing animation. Provenance: explicit creative direction constraint.
• NFR-6 — Functional motion budget. All transitions other than the split reveal and the prompt typing run at 140–200ms with no bounce. Provenance: explicit creative direction.
• NFR-7 — Clipboard access degrades gracefully. A refused clipboard write leaves the prompt text fully selectable and reports the failure in muted text. Provenance: required_inference. Rationale: copying is the accepted completion action, so its failure must not strand the developer.

10. Tech Stack

• Frontend: React, delivered as a browser web application. Provenance: required_inference — the accepted delivery shape is custom_ui: true with four first-party pages, and no source-specified framework overrides this.
• Styling: plain CSS with custom properties for the colour, type, spacing, and radius tokens in Section 6. Provenance: required_inference — the creative direction specifies exact tokens and a split-screen layout that is simplest to express directly.
• Fonts: Instrument Sans (headings and body) and JetBrains Mono (technical half, code panels, prompt text). Provenance: explicit creative direction.
• Storage: none. No database, no server-side session store, no local persistence of task text or prompts. Provenance: required_inference, consistent with NFR-2.
• Backend: none required for current scope. Prompt assembly runs in the browser. Provenance: required_inference — no accepted requirement needs server-side computation, and NFR-3 forbids outbound model calls.
• Deployment: static hosting of the built frontend. Provenance: required_inference — a client-only application with no backend has no deployment requirement beyond serving static assets.

11. Assumptions and Constraints

Constraints (binding).

• The tool is focused on prompt creation for JavaScript coding with AI DeepSeek. Provenance: explicit.
• The four pages are Landing, Task Input, Prompt Generator, and Generated Prompt, in that order, each application-owned and anonymously accessible. Provenance: explicit Planning Scope page contract.
• The only active human persona is Developer/Pengguna Coding. Provenance: explicit Planning Scope persona contract.
• The generic indigo/blue-on-white SaaS template is forbidden, along with the named blue–indigo hex values and the named typefaces in Section 6. Provenance: explicit creative direction.

Assumptions (narrow, labeled).

• Assumption 1. The developer has a DeepSeek account and access to DeepSeek outside this application. The product does not provide, manage, or verify that access. Provenance: required_inference from the accepted requirement that the developer uses DeepSeek for JavaScript coding.
• Assumption 2. The developer's session persists long enough to move from Task Input through Prompt Generator to Generated Prompt. No cross-session resume is assumed or provided. Provenance: required_inference, consistent with NFR-2.
• Assumption 3. Prompt assembly is deterministic enough to run locally in the browser without a model call. Provenance: required_inference, consistent with NFR-3.
• Assumption 4. The metadata strip's token count is a count of the generated prompt text. Provenance: required_inference from the creative direction's specification of the strip's contents.

Out of current scope. Calling DeepSeek or any model provider from the application; executing, linting, or validating generated JavaScript; saving, naming, or listing prompts; prompt history; sharing or exporting prompts to other people; supporting languages other than JavaScript; supporting models other than DeepSeek; accounts, sign-in, roles, or permissions; collaboration or review by a second person.

12. Glossary

• Prompt — the DeepSeek-ready instruction text the tool assembles from the developer's described JavaScript coding need.
• Task description — the developer's free-text statement of a JavaScript coding need, entered on Task Input.
• Prompt preview — the live, read-only monospace rendering of the prompt under assembly, shown beside the task description on Task Input.
• Generated prompt — the finished prompt artefact presented on Generated Prompt, with its metadata strip.
• Metadata strip — the small-caps row beneath the generated prompt showing model (DeepSeek), language (JavaScript), and token count.
• Split — the asymmetric two-half layout, 55/45 on Landing, in which the editorial half and the code half sit in dialogue across a hairline seam.
• Seam — the 1px vertical rule between the two halves of the split, which thickens to 2px and turns vermilion on hover.
• DeepSeek — the external AI coding assistant the developer uses; the destination for the generated prompt. It is not a participant inside the application and the application never contacts it.
• Developer/Pengguna Coding — the single active human persona: a working JavaScript developer using DeepSeek who needs better prompts.