System Requirements Document for tough-rancangan

1. Introduction

tough-rancangan is a public web presence built from the uploaded design/planning document a77a3078_peranjangan_kelompok_3_.pdf — the group-3 design proposal ("perancangan kelompok 3"). The product intent is to turn that coursework proposal into a finished, studio-grade web presentation: the proposal's own content is the exhibit, presented as a floating pearl-white document sheet inside a dark architectural stage, so that a reviewer skimming on a phone sees a confident, designed pitch rather than a homework PDF.

The audience is Neza and their group-3 classmates, their lecturer/reviewer, and anyone who opens the live preview link. The site must be legible at 375px, 768px and 1280px, and must derive its content from the uploaded document.

2. System Overview

The current delivery is a single first-party web application with four pages: Landing, Planning, Build, and Live Preview. All four are application-owned custom pages with no access requirement (anonymous reachable). The only accepted active human persona is Neza.

Accepted current behavior:

• A public Landing page introduces the tough-rancangan website derived from the uploaded design document, with a hero wordmark, a gold capsule CTA ("Buka Live Preview") and a ghost-outline CTA ("Lihat Dokumen") that scrolls to the embedded proposal viewer.
• A Planning page runs or reruns the required planning sequence producing requirements, user flow, design, architecture, and tasks.
• A Build page builds the website after the planning sequence has completed.
• A Live Preview page provides the requested destination for viewing the built tough-rancangan website.

Hard constraint: no website, pages, or live preview link exist until planning completes and the site is built. The website content must derive from the uploaded design document a77a3078_peranjangan_kelompok_3_.pdf.

Narrow exclusions: no account system, no authentication, no role-based permissions, no commerce, no stock photography, no blue-indigo palette, no white/near-white page ground.

2a. Product Interpretation and Delivery Boundary

The product is a presentation surface for a student design proposal, plus the minimal workflow Neza needs to reach it. Delivery is first-party and headless-free: the application itself owns the Landing, Planning, Build, and Live Preview pages. Access is anonymous — the source establishes no identity requirement, no private durable state, and no commitment or value transfer bound to a participant, so no application-owned identity is introduced. The Planning and Build pages are the accepted workflow steps that must complete before a live preview link exists; the Live Preview page is the destination Neza repeatedly asks for.

Current horizon: Landing, Planning, Build, Live Preview, and the planning→build→preview sequence. Future horizon: none stated by the user.

2b. Source Content Inventory

The reference directive for a77a3078_peranjangan_kelompok_3_.pdf declares uses: ["content_source", "structure_reference"] with authority: authoritative. The document is the authoritative content source for the website: its proposal pages, diagrams, and data are the material rendered in the embedded proposal viewer and in the spec rows. The document's own structure (its sections and schedule-style data) is the structure reference for how that content is laid out. No verified factual entities, collection items, field values, dates, contacts, or links beyond the document's own proposal content were supplied in the requirement thread; the document's pages are rendered as-is rather than paraphrased into invented facts.

2c. Page Content and Component Coverage

Landing

• Information/state: Project name "TOUGH-RANCANGAN" as an oversized left-aligned Jost wordmark; a small uppercase gold micro-label above it ("PERANCANGAN KELOMPOK 3 — PROPOSAL"); one plain-language line beneath; a fixed section index numbered 01–05; the embedded proposal viewer further down the page.
• Primary actions: "Buka Live Preview" gold capsule CTA (navigates to Live Preview); "Lihat Dokumen" ghost-outline CTA (scrolls to the embedded proposal viewer).
• Supporting actions: Section index jump links (01–05) that scroll to each section; horizontal scrollable chip row replacing the index below 1024px.
• Domain entities: Proposal document (a77a3078_peranjangan_kelompok_3_.pdf), proposal pages, section entries, spec rows.
• Component responsibilities: Hero stage (full-bleed charcoal, parametric ribbon form, wordmark, micro-label, plain-language line, two CTAs); section index (fixed left/right gutter with hairline flow line, numbered 01–05); proposal viewer (floating pearl-white gallery sheet with perspective tilt, 1px luminous edge, slow crossfade page turns); spec rows (ruled architectural schedule lines, label flush-left, value flush-right, tabular numerals); section boundaries (arc-shaped or diagonal cuts with gold hairline animating 0→100% width on entry).
• States: Loading — hero ribbon form initializing, proposal viewer fetching document pages. Empty — proposal viewer placeholder sheet with luminous edge before pages load. Success — wordmark, CTAs, section index, and proposal pages all rendered and readable. Error — proposal viewer shows a framed error sheet with a retry control; hero and CTAs remain usable. Recovery — retry reloads the proposal document; section index remains navigable.

Planning

• Information/state: Current planning status; the five planning outputs (requirements, user flow, design, architecture, tasks); indication that no website, pages, or live preview link exist until planning completes.
• Primary actions: Start planning; rerun planning.
• Supporting actions: Review each planning output as it is produced.
• Domain entities: Planning run, planning outputs (requirements, user flow, design, architecture, tasks).
• Component responsibilities: Planning status panel; output list with per-output state; start/rerun control.
• States: Loading — planning run in progress with per-output progress. Empty — no planning run yet, start control prominent. Success — all five outputs produced, continuation to Build offered. Error — a planning output fails, error shown with rerun control. Recovery — rerun restarts the planning sequence.

Build

• Information/state: Build readiness (planning complete), build status, and the resulting live preview link once the build succeeds.
• Primary actions: Build the website.
• Supporting actions: Open Live Preview once the build succeeds.
• Domain entities: Build run, built website, live preview link.
• Component responsibilities: Build status panel; build control; live preview link surface.
• States: Loading — build in progress. Empty — planning not yet complete, build control disabled with explanation. Success — build complete, live preview link available. Error — build fails, error shown with retry control. Recovery — retry rebuilds the website.

Live Preview

• Information/state: The built tough-rancangan website rendered for viewing; the live preview link.
• Primary actions: View the built website; open the live preview link.
• Supporting actions: Return to Landing, Planning, or Build.
• Domain entities: Built website, live preview link.
• Component responsibilities: Preview frame; link surface; navigation back to the workflow pages.
• States: Loading — preview frame initializing. Empty — no build yet, explanation that no live preview link exists until planning completes and the site is built. Success — built website rendered in the preview frame. Error — preview fails to load, error shown with retry control. Recovery — retry reloads the preview.

3. Functional Requirements

FR-1 — Build the website from the uploaded design document (explicit) As Neza, I should have a website built from the uploaded design document a77a3078_peranjangan_kelompok_3_.pdf, so that the group-3 proposal is presented as a finished web presence.

• Trigger/input: the uploaded design document.
• Observable result: a website whose content derives from that document.
• Access state: anonymous.
• Failure/recovery: if the document cannot be read, the build reports the failure and can be retried.
• Continuation: the built website is reachable from Live Preview.

FR-2 — Project name is tough-rancangan (explicit) As Neza, I should see the project named "tough-rancangan" throughout the site, so that the deliverable is identifiable as this project.

• Trigger/input: none (static identity).
• Observable result: the name "tough-rancangan" appears as the project identity.
• Access state: anonymous.
• Failure/recovery: not applicable.
• Continuation: not applicable.

FR-3 — Run planning before the site can be built (explicit) As Neza, I should run planning (requirements, user flow, design, architecture, tasks) before the site can be built and a live preview link obtained, so that the build has a complete plan behind it.

• Trigger/input: Neza starts planning.
• Observable result: the five planning outputs are produced.
• Access state: anonymous.
• Failure/recovery: a failed planning output is reported and planning can be rerun.
• Continuation: once planning completes, the Build step becomes available.

FR-4 — Open the Live Preview to see the website (explicit) As Neza, I should open the Live Preview to see the website, so that I can view the built result.

• Trigger/input: Neza opens Live Preview.
• Observable result: the built tough-rancangan website is rendered for viewing.
• Access state: anonymous.
• Failure/recovery: if the preview fails to load, an error is shown with a retry control.
• Continuation: Neza can return to Landing, Planning, or Build.

FR-5 — Planning sequence produces the five named outputs (required_inference) As Neza, I should receive requirements, user flow, design, architecture, and tasks from the planning sequence, so that the planning step is complete and the build can proceed.

• Trigger/input: a planning run.
• Observable result: each of the five named outputs is present and reviewable.
• Access state: anonymous.
• Failure/recovery: a missing or failed output is reported and planning can be rerun.
• Continuation: Build becomes available.

FR-6 — Website content derives from the uploaded document (required_inference) As Neza, I should see website content that derives from a77a3078_peranjangan_kelompok_3_.pdf, so that the site faithfully presents the group-3 proposal.

• Trigger/input: the uploaded document.
• Observable result: the proposal's pages, diagrams, and data appear in the site's proposal viewer and spec rows.
• Access state: anonymous.
• Failure/recovery: if the document content cannot be loaded, the viewer shows an error sheet with retry.
• Continuation: the viewer remains reachable from the Landing page.

FR-7 — Build the website once planning is complete, before opening Live Preview (required_inference) As Neza, I should build the website once planning is complete and before opening Live Preview, so that a live preview link exists to open.

• Trigger/input: Neza triggers the build after planning completes.
• Observable result: the website is built and a live preview link becomes available.
• Access state: anonymous.
• Failure/recovery: a failed build is reported and can be retried.
• Continuation: Neza opens Live Preview.

FR-8 — No website, pages, or live preview link exist until planning completes and the site is built (explicit constraint) As Neza, I should see that no website, pages, or live preview link exist until planning completes and the site is built, so that the workflow order is honest.

• Trigger/input: any attempt to reach the site before planning and build complete.
• Observable result: the Planning and Build pages explain the missing state; Live Preview shows an empty state rather than a link.
• Access state: anonymous.
• Failure/recovery: not applicable (this is the pre-completion state).
• Continuation: completing planning and build produces the site and link.

4. User Personas

Neza

Product context: Neza is the named user who requested the website from the uploaded design document a77a3078_peranjangan_kelompok_3_.pdf and who repeatedly asks for the web link and how to proceed. Neza is working on a group-3 coursework proposal and wants it presented as a real studio pitch rather than a homework PDF.

Primary goal: Get the planned website built and reachable via a live preview link.

Distinct accepted responsibilities: Neza starts or reruns the planning sequence that produces requirements, user flow, design, architecture, and tasks; Neza triggers the build once planning is complete; Neza opens the Live Preview tab to view the resulting site.

Relevant inputs or decisions: The uploaded design document; the decision to start or rerun planning; the decision to build; the decision to open Live Preview.

Interactions with other accepted participants: None — Neza is the only accepted active human persona. The lecturer/reviewer and classmates are part of the audience the site is presented to, but they are not accepted active product actors in this generation.

Observable success: The built tough-rancangan website is rendered in Live Preview and its content derives from the uploaded document.

What makes this role's work different: Neza is both the requester and the operator of the planning→build→preview workflow; the role's work is sequencing the workflow correctly so that a live preview link exists at all, not consuming a finished product.

5. Core User Flows

Flow 1 — Neza runs planning

1. Neza opens the Planning page (anonymous, no access requirement).
2. The page shows that no planning run exists yet and presents the start control prominently.
3. Neza starts planning.
4. The planning status panel shows the run in progress with per-output progress for requirements, user flow, design, architecture, and tasks.
5. Each of the five outputs is produced and becomes reviewable.
6. Failure/recovery: if a planning output fails, the error is shown with a rerun control; Neza reruns planning and the sequence restarts.
7. Continuation: once all five outputs are present, the Build step becomes available.

Flow 2 — Neza builds the website

1. Neza opens the Build page (anonymous, no access requirement).
2. If planning is not yet complete, the build control is disabled with an explanation that no website, pages, or live preview link exist until planning completes and the site is built.
3. Once planning is complete, Neza triggers the build.
4. The build status panel shows the build in progress.
5. Failure/recovery: if the build fails, the error is shown with a retry control; Neza retries and the website is rebuilt.
6. Success: the build completes and a live preview link becomes available on the Build page.
7. Continuation: Neza opens Live Preview.

Flow 3 — Neza opens the Live Preview

1. Neza opens the Live Preview page (anonymous, no access requirement), either from the Build page's live preview link or from the Landing page's "Buka Live Preview" gold capsule CTA.
2. If no build exists yet, the page shows an empty state explaining that no live preview link exists until planning completes and the site is built.
3. Once a build exists, the preview frame initializes and the built tough-rancangan website is rendered for viewing.
4. Failure/recovery: if the preview fails to load, an error is shown with a retry control; Neza retries and the preview reloads.
5. Continuation: Neza can return to Landing, Planning, or Build.

Flow 4 — Neza views the proposal on the Landing page

1. Neza opens the Landing page (anonymous, no access requirement).
2. The hero stage renders: the "TOUGH-RANCANGAN" wordmark in Jost 300, the uppercase gold micro-label "PERANCANGAN KELOMPOK 3 — PROPOSAL", one plain-language line, the "Buka Live Preview" gold capsule CTA, and the "Lihat Dokumen" ghost-outline CTA.
3. Neza selects "Lihat Dokumen".
4. The page scrolls to the embedded proposal viewer, where the proposal's pages are presented as a floating pearl-white gallery sheet with perspective tilt, a 1px luminous edge, and slow crossfade page turns.
5. Failure/recovery: if the proposal document cannot be loaded, the viewer shows a framed error sheet with a retry control; the hero and CTAs remain usable.
6. Continuation: Neza can use the section index (01–05) to jump through the proposal, or select "Buka Live Preview" to go to the Live Preview page.

6. Visuals Colors and Theme

Muse: Zaha Hadid. Headline direction: Fluid parametric grandeur for a student design proposal — a charcoal-pearl architectural stage where the proposal itself is the exhibit.

Mode: dark.

Colour tokens (exact hex by role):

No blue-indigo anywhere. Luminous moments are cyan-teal and gold, reading as light on curved metal.

Typography:

• Headings: Jost, weight 300–400, wide tracking 0.02em–0.06em, sentence case for section titles, uppercase only for micro-labels. Hero wordmark clamp(2.5rem, 9vw, 7.5rem); section titles clamp(2rem, 5vw, 4rem); line-height 0.95–1.05.
• Body: Manrope 400/500 at 17–19px with 1.65 line-height.
• Scale: 1.25 modular on a 4/8px baseline — 96/64/48/32/24/19/17/14 px; hero display clamped 40px mobile → 120px desktop; section titles 32px → 64px; body 17px → 19px; labels 12–14px uppercase +0.14em.

Shape language: Continuous sweeping curves. Section boundaries are soft diagonal or arc-shaped cuts rather than straight rules. Cards use 24–40px radii on two corners and 4px on the opposing two, reading as sliced surfaces. Every panel has a 1px luminous edge rgba(242,240,236,0.10) plus a very soft long-throw shadow. Buttons are elongated capsules with a gold hairline. The document viewer is a pearl-white sheet floating on charcoal with a subtle perspective tilt. Nothing is a perfect square unless it is a data table cell.

Layout: Asymmetric architectural grid — 12-column desktop grid with content pushed to the left 7 columns and a tall negative-space gutter on the right carrying a thin vertical flow line and section numbering; hero is full-bleed. Sections alternate between full-bleed dark bands and a centred "gallery plaque" block with 96–160px vertical rhythm. Fixed left-edge section index (numbered 01–05, hidden below 1024px, replaced by a horizontal scrollable chip row). At 375px everything collapses to one column with 20px margins; each section title, paragraph, spec row and control stays fully inside the viewport, wrapping rather than scaling down.

Imagery style: The proposal itself is the hero image — the PDF's pages rendered as pearl-white sheets floating in dark space with shadow and slight perspective, plus one abstract parametric ribbon form (CSS/SVG flowing surface with cyan edge-light and gold rim). No stock photography, no people, no clip art — only the document, diagrams pulled from it as paper-white line drawings on charcoal, and the flowing 3D form. Decorative ribbons and curves may bleed off the viewport edge; all readable text and controls stay whole.

7. Signature Design Concept

The public entry is a dark architectural stage, not a centred SaaS stack. A single flowing parametric ribbon-form sweeps from the bottom-left off the right edge, edge-lit in #7FD8E8 with a gold rim, sitting behind everything at low opacity. Over it, left-aligned in the upper two-thirds, the project name TOUGH-RANCANGAN is set in Jost 300 at clamp(40px, 9vw, 120px), tracking wide, wrapping to two lines on mobile. Above it sits a small uppercase gold label ("PERANCANGAN KELOMPOK 3 — PROPOSAL"); beneath it, one 60-character plain-language line. Directly under the headline, a single gold capsule CTA ("Buka Live Preview") sits on the dark ground, and to its right a ghost-outline CTA ("Lihat Dokumen") that scrolls to the embedded proposal viewer. A thin vertical flow line with 01–05 section numbers runs down the right gutter on desktop. Nothing is centred, nothing is a gradient blob, and the first screen is unmistakably an architectural unveiling.

The concept recomposes only accepted content and controls: the project name, the proposal document, the two CTAs, and the section index. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the flowing parametric ribbon-form, edge-lit in #7FD8E8 with a gold rim, sweeping from the bottom-left off the right edge behind the wordmark.
• Input → transformation → outcome thesis: as Neza scrolls the Landing page, the ribbon form rotates and drifts a few degrees (scroll-linked parallax), so the hero reads as a structure being unveiled rather than a static banner; the wordmark, micro-label, plain-language line, and both CTAs remain whole and readable throughout.
• Motion vocabulary: one scroll-linked parallax on the hero's flowing form; section titles sweeping in from a 24px offset with a 600ms cubic-bezier(0.16,1,0.3,1) ease; the gold hairline under a title drawing from 0 to 100% width on entry; slow crossfades between the proposal's document pages. No bounces, no particles, no autoplaying carousels.
• Composed first frame: full-bleed charcoal #0E1013 stage; the ribbon form entering from the bottom-left, edge-lit cyan with a gold rim, at low opacity behind everything; the "TOUGH-RANCANGAN" wordmark left-aligned in the upper two-thirds in Jost 300; the gold micro-label above it; the plain-language line beneath; the gold capsule CTA and ghost-outline CTA directly under the headline; the thin vertical flow line with 01–05 section numbers down the right gutter on desktop.
• Reduced-motion state: with prefers-reduced-motion, the hero form holds still and sections simply appear — a static layout with no parallax, no sweep-in, no hairline draw, and no crossfade.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

One crafted real-time object: a single continuous parametric ribbon surface, built as a flowing swept form with a cyan #7FD8E8 edge light and a gold #C9A227 rim, standing in for the project's built idea. The scene shows the product's defining state — a proposal becoming a built thing — by having the ribbon form hold its composed pose at rest and rotate/drift a few degrees as the Landing page scrolls. The form bleeds off the right edge by design; the wordmark, micro-label, plain-language line, and both CTAs stay whole and uncovered at 375px, 768px and 1280px. Under prefers-reduced-motion the form holds still.

9. Non-Functional Requirements

• NFR-1 — Readable text and controls stay whole (explicit, creative direction): headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit; no other element covers any part of them. Imagery, decoration and motion may be cropped, bled off an edge, rotated, overlapped or cut as the direction asks, as long as it covers no readable text or control.
• NFR-2 — Reduced-motion support (explicit, creative direction): with prefers-reduced-motion, provide a usable static arrangement — the hero form holds still, sections simply appear, and any horizontally scrollable row wraps into rows or allows horizontal scrolling so each item can be brought fully into view.
• NFR-3 — No blue-indigo, no white ground (explicit, creative direction): any blue–indigo primary or accent and any white/near-white page ground are forbidden; the ground is charcoal #0E1013.
• NFR-4 — No forbidden typefaces (explicit, creative direction): Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui are not used for headings or body.
• NFR-5 — No glassmorphism or pastel gradients (explicit, creative direction): no frosted blur tiles, glassmorphism panels, or pastel multicolour gradients; surfaces are opaque charcoal with luminous edges.
• NFR-6 — No bouncy micro-interactions (explicit, creative direction): motion stays slow, sweeping and architectural; no bouncy, springy or playful micro-interactions.
• NFR-7 — No stock photography, clip art, or decorative icons (explicit, creative direction): imagery is limited to the document, diagrams pulled from it, and the flowing 3D form.
• NFR-8 — Accent restraint (explicit, creative direction): gold and cyan are accents only — gold for one CTA and hairlines, cyan for edge light only — so contrast stays high; neither fills large areas.
• NFR-9 — Content derives from the uploaded document (explicit constraint): the website content must derive from a77a3078_peranjangan_kelompok_3_.pdf.
• NFR-10 — No site before planning and build (explicit constraint): no website, pages, or live preview link exist until planning completes and the site is built.

10. Tech Stack

• Frontend: React (web).
• Backend: Python / FastAPI.
• Storage: appropriate storage for planning runs, build runs, and the built website artifact.
• Containerization: Docker / docker-compose.
• Kubernetes: only if deployment requires it.

Source-specified technology is preserved; no substitutions are made.

11. Assumptions and Constraints

• Assumption (narrow): The uploaded document a77a3078_peranjangan_kelompok_3_.pdf is readable and its pages can be rendered in the proposal viewer. If it is not readable, the viewer's error state and retry control apply.
• Assumption (narrow): The planning sequence's five outputs (requirements, user flow, design, architecture, tasks) are the complete set named by the user; no additional planning outputs are introduced.
• Constraint (explicit): No website, pages, or live preview link exist until planning completes and the site is built.
• Constraint (explicit): The website content must derive from the uploaded design document a77a3078_peranjangan_kelompok_3_.pdf.
• Constraint (explicit): Project name is tough-rancangan.
• Constraint (creative direction): The palette, typography, shape language, layout, motion, and imagery rules in sections 6–8 are authoritative for this project.
• Constraint (access): All four pages are anonymous with no access requirement; no account system, authentication, or role-based permissions are introduced.
• Exclusion: No commerce, no stock photography, no blue-indigo palette, no white/near-white page ground, no glassmorphism, no bouncy micro-interactions.

12. Glossary

• tough-rancangan — the project name for this website.
• Perancangan Kelompok 3 — "group 3's design/planning document"; the source proposal a77a3078_peranjangan_kelompok_3_.pdf.
• Planning sequence — the required run producing requirements, user flow, design, architecture, and tasks.
• Build — the step that produces the website after planning completes.
• Live Preview — the destination for viewing the built tough-rancangan website.
• Proposal viewer — the embedded pearl-white gallery sheet on the Landing page that renders the proposal document's pages.
• Spec row — a ruled architectural schedule line presenting the proposal's own data (label flush-left, value flush-right, tabular numerals).
• Section index — the fixed 01–05 numbered index with a hairline flow line, collapsing to a horizontal scrollable chip row below 1024px.
• Parametric ribbon form — the flowing 3D hero subject, edge-lit in cyan with a gold rim, standing in for the project's built idea.