System Requirements Document for portal-admin

1. Introduction

portal-admin is a self-hosted content portal with a built-in admin system. It exists so that one owner — Ronald Panuju — can publish a public-facing portal whose photos and database content he can change himself, at any time, without a developer.

The product has two halves that share one machine:

• A public portal that anonymous visitors can read: a Landing page that presents the portal's photos and information.
• An admin system that the Portal Administrator signs into, where photos are uploaded, replaced and removed, and where the database records that back the portal's content are browsed and edited.

The audience is therefore twofold: the administrator, who is a non-designer and needs a tool that feels obvious and under his control, and anonymous visitors, who only need to read and browse what the administrator has published.

The product intent, stated plainly: a portal with an admin system, where photos and the database can be changed by me.

2. System Overview

portal-admin is delivered as a first-party web application with its own application-owned identity. It has two access zones:

• Public zone — the Landing page, reachable by anyone with no sign-in. It presents the portal's published photos and information.
• Administrative zone — the Photos, Photo Editor, Records and Record Editor pages, reachable only by a signed-in Portal Administrator. These pages are where photos and database records are actually changed.

Access to the administrative zone is established through two anonymous entry surfaces, Sign Up (first-use enrollment) and Login (returning verification). Neither of these surfaces is itself protected; the protected administrative pages become available only after identity is established.

The system is backed by a server-side application and a database. Photos are stored as binary media and referenced by records; database records hold the portal's content. Administrative changes made in the admin system are what the public Landing page subsequently shows.

Actors

Narrow exclusions

• Administrative capabilities — changing photos and database content — are performed through the admin system. They are not performed from the public Landing page.
• No stock photography, decorative illustration, or third-party imagery is part of the product; the only imagery is the administrator's own uploaded photos, plus the pixel-pictogram icon set.
• No multi-role permission model, team collaboration, approval workflow, or content moderation is established by the source.

2a. Product Interpretation and Delivery Boundary

Delivery. portal-admin is a first-party web application. Both the public portal and the admin system are custom UI owned by this application; there is no provider-owned or external-only surface in the current scope. The application owns its own identity: the Portal Administrator enrolls on first use and signs in on return, and that identity is what binds administrative control of portal content to the correct person.

Access ownership. The Landing page is public and requires no identity. The administrative pages — Photos, Photo Editor, Records, Record Editor — require an established Portal Administrator identity. The two identity surfaces, Sign Up and Login, are deliberately anonymous: a person who has not yet enrolled must be able to reach Sign Up, and a person who has not yet signed in must be able to reach Login. Protected administrative state is never available before identity is established.

Current vs. future. Everything described in this document is current. No future-horizon requirements were stated by the user; nothing in this document is deferred.

Boundary of inference. The user asked for a portal, an admin system, changeable photos, and a changeable database. The identity lifecycle (first-use enrollment, returning sign-in, and the distinction between the administrator's protected control and the visitor's public viewing) is inferred only because the accepted journey — an administrator who repeatedly returns to change protected content — cannot be executed without it. No adjacent account-management capability (password reset flows, profile editing, user administration, invitations, roles) is included.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source; there is no supplied factual content collection to inventory.

2c. Page Content and Component Coverage

Landing

Purpose. The public entry point. Anonymous visitors arrive here, understand what the portal is, and browse the photos and information the administrator maintains.

Information and state

• Portal identity: pixel-art portal mark and portal name in the top-left of the navigation.
• Hero headline: "Portal dengan admin yang bisa kamu ubah sendiri", set in Space Grotesk at clamp(38px, 8vw, 92px), left-aligned across 9 of 12 columns, breaking across three lines.
• Featured photo: a single square photo frame, half-bled off the right edge of the viewport at 380px, outlined in paper white — shown only when a featured photo exists.
• Hero metadata rule: a 2px paper rule along the bottom of the ink block carrying 13px uppercase mono metadata — photo count, record count, and last-updated timestamp.
• Photo gallery: a strict 12-column grid of square 1:1 thumbnails with 16px gutters, each with a 13px uppercase mono caption.
• Portal information: the text content the administrator maintains in the database records.

Primary actions

• Masuk Admin — a single solid vermilion button pinned bottom-left of the ink hero block, with a 2px paper outline and a 2px hard offset shadow. Navigates to Login.

Supporting actions

• Browse the photo gallery; open a photo to view it larger.
• Read the portal information sections.

Domain entities

• Photo (image, caption, featured flag, ordering)
• Portal content record (title, body text, metadata)

Component responsibilities

• PortalMark — 32px pixel-art mark drawn in paper white and vermilion.
• HeroBlock — full-bleed ink block; owns the headline, the featured photo frame, the admin entry button, and the metadata rule.
• PhotoGrid — 12-column square-thumbnail grid with mono captions.
• PhotoFrame — 2px-outlined square frame with checkerboard ground behind transparent images.
• InfoSection — renders portal content records as readable text.

States

• Loading — thumbnails fade in over 120ms as they load; the grid holds its column structure so nothing reflows.
• Empty — when no photos have been published, the gallery shows a 96px pixel-art empty picture frame with a short label. When no featured photo exists, the hero block renders without the right-hand frame and the headline keeps its 9-column span.
• Success — photos and information render in the grid and info sections; the metadata rule shows current counts and last-updated time.
• Error — if content cannot be loaded, the page shows a plain ink-on-paper message with a retry control; the hero block and admin entry button remain usable.
• Recovery — retry reloads content without leaving the page.

Login

Purpose. Returning verification for the Portal Administrator. This surface is anonymous and reachable without identity.

Information and state

• Portal mark and portal name.
• Email field and password field, each with a 2px outlined input and a label above the field.
• Inline validation and error state.

Primary actions

• Sign in — submits credentials and, on success, establishes the administrator session and continues to the administrative area.

Supporting actions

• Navigate to Sign Up for a person who has not yet enrolled.

Domain entities

• Administrator credential (email, password)

Component responsibilities

• AuthForm — single-column form, max 720px, label above field.
• FormField — 2px outlined input with label and inline error text.
• SubmitBar — holds the primary submit control.

States

• Loading — submit control shows a busy state; fields are disabled.
• Empty — fields render empty with labels visible.
• Success — session established; the administrator continues to the administrative area.
• Error — unrecognized credentials or a failed request show an inline message above the form; the entered email is preserved and the password field is cleared.
• Recovery — the administrator can correct the entry and resubmit, or navigate to Sign Up.

Sign Up

Purpose. First-use enrollment for the Portal Administrator. This surface is anonymous and reachable without identity.

Information and state

• Portal mark and portal name.
• Email field, password field, and password confirmation field, each with a 2px outlined input and a label above the field.
• Inline validation and error state.

Primary actions

• Create account — submits the enrollment and, on success, establishes the administrator identity and continues to the administrative area.

Supporting actions

• Navigate to Login for a person who already has an account.

Domain entities

• Administrator credential (email, password)

Component responsibilities

• AuthForm — single-column form, max 720px, label above field.
• FormField — 2px outlined input with label and inline error text.
• SubmitBar — holds the primary submit control.

States

• Loading — submit control shows a busy state; fields are disabled.
• Empty — fields render empty with labels visible.
• Success — identity established; the administrator continues to the administrative area.
• Error — an already-registered email, mismatched confirmation, or a failed request shows an inline message; entered values other than the password are preserved.
• Recovery — the administrator can correct the entry and resubmit, or navigate to Login.

Photos

Purpose. The revisitable administrative overview of every photo shown in the portal. This is where the administrator scans, finds, and selects photos to work on.

Information and state

• Full-width ruled rows, one per photo — not a grid of cards. Each row shows a square 1:1 thumbnail in a 2px-outlined frame, the photo's caption, its featured status, and its last-updated timestamp in 13px uppercase mono.
• A blue left edge snaps in on row hover.
• Row count in tabular mono numerals.

Primary actions

• Add photo — opens the Photo Editor in create mode.
• Open a row — opens that photo in the Photo Editor.

Supporting actions

• Delete — removes a photo from the portal, with a confirmation step.
• Set featured — marks a photo as the one shown in the Landing hero frame.
• Search or filter the list by caption.

Domain entities

• Photo (image, caption, featured flag, ordering, updated timestamp)

Component responsibilities

• AdminRail — 220px left rail on ink ground with pixel icons and labels; the active item carries the vermilion accent.
• AdminTopBar — 64px bar showing the signed-in administrator's name and a sign-out control.
• RuledRowList — full-width ruled rows with instant blue-left-edge hover highlight.
• RowAction — pixel-pictogram row actions (eye, pencil, trash) at 24px.
• EmptyState — 96px pixel-art empty picture frame with a short label.

States

• Loading — rows render as ruled placeholders at final row height; thumbnails fade in over 120ms.
• Empty — no photos yet: a 96px pixel-art empty picture frame, a short label, and the Add photo action.
• Success — rows list every photo with thumbnail, caption, featured status and timestamp.
• Error — a failed load shows an ink-on-paper message with a retry control; a failed delete shows an inline row-level message and the row remains.
• Recovery — retry reloads the list; a failed delete can be retried or dismissed.

Photo Editor

Purpose. Focused administrative work on one photo — adding a new one or updating an existing one.

Information and state

• The image in a 2px-outlined frame over a checkerboard transparency ground, so the administrator can see exactly what is being replaced.
• Caption field, featured toggle, and ordering value.
• Current image metadata: dimensions, file size, last-updated timestamp in tabular mono.

Primary actions

• Save — the single vermilion action on this screen. Persists the photo and returns to Photos.

Supporting actions

• Choose file — selects a replacement or new image; the frame previews it immediately.
• Cancel — discards unsaved changes and returns to Photos.
• Delete — removes the photo, with a confirmation step.

Domain entities

• Photo (image, caption, featured flag, ordering, updated timestamp)

Component responsibilities

• EditorForm — single-column form, max 720px, label above field, 2px outlined inputs.
• ImageFrame — 2px-outlined frame with checkerboard transparency ground.
• StickyFooterBar — holds Cancel and the vermilion Save.
• SaveConfirmation — a 3-frame "saved" check that holds for 900ms.

States

• Loading — the form renders with fields disabled and the image frame shows a placeholder until the image resolves.
• Empty — create mode: the image frame shows the 96px pixel-art empty picture frame and prompts for a file.
• Success — Save shows the 3-frame check for 900ms, then returns to Photos with the updated row visible.
• Error — an invalid or unreadable file, or a failed save, shows an inline message above the form; entered values are preserved so the administrator can correct and resave.
• Recovery — the administrator can choose a different file or retry the save without losing the caption and flags.

Records

Purpose. The revisitable administrative overview of the database records that back the portal's content.

Information and state

• Full-width ruled rows, one per record. Each row shows the record ID in IBM Plex Mono tabular numerals, the record's title, its type, and its last-updated timestamp.
• A blue left edge snaps in on row hover.
• Row count in tabular mono numerals.

Primary actions

• Add record — opens the Record Editor in create mode.
• Open a row — opens that record in the Record Editor.

Supporting actions

• Delete — removes a record, with a confirmation step.
• Search or filter the list by title or ID.

Domain entities

• Portal content record (ID, title, type, body, metadata, updated timestamp)

Component responsibilities

• AdminRail — 220px left rail on ink ground with pixel icons and labels; the active item carries the vermilion accent.
• AdminTopBar — 64px bar showing the signed-in administrator's name and a sign-out control.
• RuledRowList — full-width ruled rows with instant blue-left-edge hover highlight.
• RowAction — pixel-pictogram row actions (eye, pencil, trash) at 24px.
• EmptyState — 96px pixel-art blank sheet with a short label.

States

• Loading — rows render as ruled placeholders at final row height.
• Empty — no records yet: a 96px pixel-art blank sheet, a short label, and the Add record action.
• Success — rows list every record with ID, title, type and timestamp.
• Error — a failed load shows an ink-on-paper message with a retry control; a failed delete shows an inline row-level message and the row remains.
• Recovery — retry reloads the list; a failed delete can be retried or dismissed.

Record Editor

Purpose. Focused administrative work on one database record used by the portal.

Information and state

• Record ID displayed in IBM Plex Mono tabular numerals.
• Title field, type field, body field, and metadata fields, each with a 2px outlined input and a label above the field.
• Last-updated timestamp.

Primary actions

• Save — the single vermilion action on this screen. Persists the record and returns to Records.

Supporting actions

• Cancel — discards unsaved changes and returns to Records.
• Delete — removes the record, with a confirmation step.

Domain entities

• Portal content record (ID, title, type, body, metadata, updated timestamp)

Component responsibilities

• EditorForm — single-column form, max 720px, label above field, 2px outlined inputs.
• StickyFooterBar — holds Cancel and the vermilion Save.
• SaveConfirmation — a 3-frame "saved" check that holds for 900ms.

States

• Loading — the form renders with fields disabled until the record resolves.
• Empty — create mode: fields render empty with labels visible.
• Success — Save shows the 3-frame check for 900ms, then returns to Records with the updated row visible.
• Error — a validation failure or a failed save shows an inline message above the form; entered values are preserved.
• Recovery — the administrator can correct the entry and resave without losing work.

3. Functional Requirements

Public portal

FR-1 — Public portal entry point (explicit) As a Portal Visitor, I should be able to open the portal's public entry point without signing in, so that I can see what the portal contains.

• Trigger: the visitor navigates to the portal.
• Observable result: the Landing page renders with the portal mark, the hero headline, the published photos, and the portal information.
• Access state: anonymous; no identity required.
• Failure/recovery: if content fails to load, an ink-on-paper message with a retry control is shown and the page remains usable.
• Continuation: the visitor browses the gallery and information.

FR-2 — Browse published photos (explicit) As a Portal Visitor, I should be able to browse the photos the administrator has published, so that I can see the portal's imagery.

• Trigger: the visitor views the Landing page.
• Observable result: photos render as square 1:1 thumbnails in a 12-column grid with 16px gutters and 13px uppercase mono captions; thumbnails fade in over 120ms.
• Access state: anonymous.
• Failure/recovery: thumbnails that fail to load leave their frame in place; the rest of the grid remains readable.
• Continuation: the visitor opens a photo to view it larger.

FR-3 — Read portal information (explicit) As a Portal Visitor, I should be able to read the portal's information, so that I can understand what the portal is about.

• Trigger: the visitor views the Landing page.
• Observable result: the portal content records render as readable text sections in IBM Plex Sans at 16px/1.6.
• Access state: anonymous.
• Failure/recovery: if information fails to load, a retry control is offered.
• Continuation: the visitor continues browsing or leaves.

FR-4 — Featured photo in the hero (explicit) As a Portal Visitor, I should see the administrator's featured photo in the hero block, so that the portal's most important image is immediately visible.

• Trigger: the Landing page renders and a photo is marked featured.
• Observable result: a single square photo frame, half-bled off the right edge at 380px and outlined in paper white, appears in the ink hero block.
• Access state: anonymous.
• Failure/recovery: when no photo is featured, the hero renders without the frame and the headline keeps its 9-column span.
• Continuation: the visitor browses the full gallery.

FR-5 — Portal metadata rule (explicit) As a Portal Visitor, I should see the portal's current counts and last-updated time, so that I can tell how current the content is.

• Trigger: the Landing page renders.
• Observable result: a 2px paper rule along the bottom of the ink block carries 13px uppercase mono metadata — photo count, record count, last-updated timestamp.
• Access state: anonymous.
• Failure/recovery: if counts are unavailable, the rule renders with the values it has rather than breaking the layout.
• Continuation: the visitor continues browsing.

FR-6 — Admin entry from the public portal (explicit) As a Portal Visitor who is also the administrator, I should be able to reach the admin system from the public portal, so that I can go straight to managing content.

• Trigger: the visitor activates the Masuk Admin button pinned bottom-left of the ink hero block.
• Observable result: the Login page opens.
• Access state: anonymous entry; the button is visible to everyone, and protected state remains unavailable until identity is established.
• Failure/recovery: if navigation fails, the button remains available to retry.
• Continuation: the administrator signs in or enrolls.

Identity and access

FR-7 — First-use enrollment (required_inference) As a Portal Administrator, I should be able to establish my identity on first use, so that I can access the admin system.

• Trigger: the administrator opens Sign Up and submits an email, password, and password confirmation.
• Observable result: the identity is established and the administrator continues into the administrative area.
• Access state: anonymous entry surface; no identity required to reach it.
• Failure/recovery: an already-registered email, a mismatched confirmation, or a failed request shows an inline message; entered values other than the password are preserved so the administrator can correct and resubmit.
• Continuation: the administrator lands in the administrative area and can begin managing photos and records.

FR-8 — Returning sign-in (required_inference) As a Portal Administrator, I should be able to sign in again, so that I can resume managing photos and database content.

• Trigger: the administrator opens Login and submits credentials.
• Observable result: the session is established and the administrator continues into the administrative area.
• Access state: anonymous entry surface; protected administrative state remains unavailable until sign-in succeeds.
• Failure/recovery: unrecognized credentials or a failed request show an inline message above the form; the entered email is preserved and the password field is cleared so the administrator can retry.
• Continuation: the administrator resumes work in Photos or Records.

FR-9 — Protected administrative access (required_inference) As a Portal Administrator, I should be the only one who can reach the administrative pages, so that portal content is not changed by visitors.

• Trigger: any request for Photos, Photo Editor, Records, or Record Editor.
• Observable result: the request is served only when an established administrator identity is present; otherwise the person is directed to Login.
• Access state: role-restricted to the Portal Administrator; the Portal Visitor's access is public viewing only.
• Failure/recovery: an unauthenticated request is redirected to Login without exposing administrative state.
• Continuation: after signing in, the administrator reaches the requested administrative page.

FR-10 — Sign out (required_inference) As a Portal Administrator, I should be able to sign out, so that the admin system is not left open on a shared machine.

• Trigger: the administrator activates the sign-out control in the 64px admin top bar.
• Observable result: the session ends and the administrator returns to the public portal.
• Access state: available only within the administrative area.
• Failure/recovery: if sign-out fails, the administrator remains signed in and can retry.
• Continuation: the administrator can sign in again from Login.

Photo management

FR-11 — Browse and manage photos (explicit) As a Portal Administrator, I should be able to browse every photo in the portal from one administrative overview, so that I can find the photo I want to change.

• Trigger: the administrator opens Photos.
• Observable result: full-width ruled rows list every photo with a square 1:1 thumbnail in a 2px-outlined frame, its caption, its featured status, and its last-updated timestamp in 13px uppercase mono; a blue left edge snaps in on row hover.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a failed load shows an ink-on-paper message with a retry control.
• Continuation: the administrator opens a row in the Photo Editor or adds a new photo.

FR-12 — Add a photo (explicit) As a Portal Administrator, I should be able to add a photo to the portal, so that new imagery appears on the Landing page.

• Trigger: the administrator activates Add photo on Photos, chooses a file, enters a caption, and activates Save.
• Observable result: the image is previewed in a 2px-outlined frame over a checkerboard transparency ground; on save, the 3-frame "saved" check holds for 900ms and the administrator returns to Photos with the new row visible.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: an invalid or unreadable file, or a failed save, shows an inline message above the form; the caption and flags are preserved so the administrator can choose a different file or retry.
• Continuation: the new photo appears in the Photos list and, once published, on the Landing page.

FR-13 — Change an existing photo (explicit) As a Portal Administrator, I should be able to change a photo that is already in the portal, so that the portal's imagery stays correct.

• Trigger: the administrator opens a photo from Photos, replaces the image file or edits its caption, and activates Save.
• Observable result: the frame shows exactly what is being replaced over the checkerboard ground; on save, the 3-frame "saved" check holds for 900ms and the updated row is visible in Photos.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a failed save shows an inline message and preserves the entered values; the administrator can retry without losing work.
• Continuation: the Landing page shows the updated photo.

FR-14 — Remove a photo (explicit) As a Portal Administrator, I should be able to remove a photo from the portal, so that imagery I no longer want is not published.

• Trigger: the administrator activates the trash row action on Photos or the delete action in the Photo Editor and confirms.
• Observable result: the photo is removed and the row disappears from the Photos list.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a failed delete shows an inline row-level message and the row remains, so the administrator can retry or dismiss.
• Continuation: the Landing page no longer shows the photo.

FR-15 — Choose the featured photo (explicit) As a Portal Administrator, I should be able to mark which photo is featured, so that the Landing hero shows the image I want.

• Trigger: the administrator toggles the featured flag in the Photo Editor and saves.
• Observable result: the chosen photo appears in the Landing hero frame; the previously featured photo is no longer featured.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a failed save shows an inline message and the previous featured photo remains in place.
• Continuation: the administrator returns to Photos and sees the updated featured status.

FR-16 — Order photos (explicit) As a Portal Administrator, I should be able to set a photo's ordering value, so that the gallery presents photos in the sequence I intend.

• Trigger: the administrator edits the ordering value in the Photo Editor and saves.
• Observable result: the Landing gallery and the Photos list reflect the new order.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a failed save shows an inline message and preserves the entered value.
• Continuation: the administrator continues managing photos.

Database record management

FR-17 — Browse database records (explicit) As a Portal Administrator, I should be able to browse the database records that back the portal's content, so that I can find the record I want to change.

• Trigger: the administrator opens Records.
• Observable result: full-width ruled rows list every record with its ID in IBM Plex Mono tabular numerals, its title, its type, and its last-updated timestamp; a blue left edge snaps in on row hover.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a failed load shows an ink-on-paper message with a retry control.
• Continuation: the administrator opens a row in the Record Editor or adds a new record.

FR-18 — Add a database record (explicit) As a Portal Administrator, I should be able to add a database record, so that new portal content can be published.

• Trigger: the administrator activates Add record on Records, fills in the fields, and activates Save.
• Observable result: on save, the 3-frame "saved" check holds for 900ms and the administrator returns to Records with the new row visible.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a validation failure or a failed save shows an inline message above the form and preserves the entered values.
• Continuation: the new record appears in the Records list and, where it is portal content, on the Landing page.

FR-19 — Change a database record (explicit) As a Portal Administrator, I should be able to change the database content, so that the portal's information stays accurate.

• Trigger: the administrator opens a record from Records, edits its title, type, body, or metadata, and activates Save.
• Observable result: on save, the 3-frame "saved" check holds for 900ms and the updated row is visible in Records.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a validation failure or a failed save shows an inline message above the form and preserves the entered values so the administrator can correct and resave.
• Continuation: the Landing page shows the updated information.

FR-20 — Remove a database record (explicit) As a Portal Administrator, I should be able to remove a database record, so that content I no longer want is not published.

• Trigger: the administrator activates the trash row action on Records or the delete action in the Record Editor and confirms.
• Observable result: the record is removed and the row disappears from the Records list.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a failed delete shows an inline row-level message and the row remains, so the administrator can retry or dismiss.
• Continuation: the Landing page no longer shows the removed content.

FR-21 — Find a record or photo quickly (explicit) As a Portal Administrator, I should be able to search or filter the Photos and Records lists, so that I can reach a specific item without scanning every row.

• Trigger: the administrator enters a term in the search or filter control on Photos or Records.
• Observable result: the ruled-row list narrows to matching rows; the row count updates in tabular mono numerals.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: a term with no matches shows the empty state with a short label and a way to clear the term.
• Continuation: the administrator opens a matching row or clears the term.

FR-22 — Cancel an edit without saving (explicit) As a Portal Administrator, I should be able to abandon an edit, so that I am not forced to commit a change I started by mistake.

• Trigger: the administrator activates Cancel in the sticky footer bar of the Photo Editor or Record Editor.
• Observable result: unsaved changes are discarded and the administrator returns to Photos or Records.
• Access state: role-restricted to the Portal Administrator.
• Failure/recovery: if the return navigation fails, the editor remains open with the entered values intact.
• Continuation: the administrator continues from the list.

System behavior

FR-23 — Persist administrative changes (explicit) As the application, I should persist every saved photo and record change, so that the administrator's work survives and the public portal reflects it.

• Trigger: a successful Save in the Photo Editor or Record Editor, or a confirmed delete.
• Observable result: the change is written to storage and is visible on the next read of Photos, Records, and the Landing page.
• Access state: performed only for an established administrator identity.
• Failure/recovery: a failed write surfaces as an inline error in the editor and leaves the stored state unchanged.
• Continuation: the administrator retries or cancels.

FR-24 — Serve public content from stored data (explicit) As the application, I should render the Landing page from the stored photos and records, so that the public portal always shows what the administrator has published.

• Trigger: a visitor requests the Landing page.
• Observable result: the gallery, featured photo, information sections, and metadata rule are built from current stored data.
• Access state: public; no identity required.
• Failure/recovery: if stored data cannot be read, the page shows a retry control rather than failing silently.
• Continuation: the visitor browses the rendered content.

4. User Personas

Portal Administrator

Product context. Ronald Panuju runs this portal himself. He is not a designer and does not want to be one; he wants a tool that behaves the way he expects and does not hide things from him. He is the only person who changes the portal's content, and he comes back to it repeatedly — to swap a photo, correct a caption, fix a record, or add something new.

Primary goal. To change the portal's photos and database content himself, whenever he wants, without needing anyone else.

Distinct accepted responsibilities.

• Establish his own identity on first use, and sign in again on return.
• Browse every photo in one administrative overview and find the one he wants.
• Add a photo, replace an existing photo's image, edit its caption, mark which photo is featured, and set its ordering.
• Remove a photo he no longer wants published.
• Browse the database records that back the portal's content.
• Add a record, edit a record's title, type, body and metadata, and remove a record.
• Search or filter the Photos and Records lists to reach a specific item.
• Cancel an edit he started by mistake.
• Sign out when he is done.

Relevant inputs and decisions. He chooses image files, writes captions, decides which photo is featured and in what order photos appear, and decides what the portal's information says. He decides when a change is finished by activating Save, and he confirms before deleting.

Interactions with other accepted participants. He is the sole author of what the Portal Visitor sees. Every photo and every piece of information on the Landing page is something he put there or changed. He never interacts with a visitor directly; the portal is the medium.

Observable success. After he saves, the change is visible in the Photos or Records list, and the Landing page shows the updated photo or information. He can sign out and, on returning, sign in and find his content exactly as he left it.

What makes this role different. The administrator is the only actor who writes. His work is deliberate, revisitable, and protected — he returns to the same lists and editors repeatedly, and his changes persist and become public. He needs density and legibility, not marketing polish.

Portal Visitor

Product context. An anonymous person who arrives at the portal's public entry point. They have no account, no relationship with the administrator, and no interest in the admin system. They came to look.

Primary goal. To find and read the portal's content — its photos and its information — without needing admin access.

Distinct accepted responsibilities.

• Open the portal's public entry point.
• Browse the published photos in the gallery.
• Read the portal's information.
• View the featured photo in the hero block.
• See how current the content is from the metadata rule.

Relevant inputs and decisions. They decide which photos to look at and which information to read. They may notice the Masuk Admin button, but it is not their path.

Interactions with other accepted participants. They are the audience for the Portal Administrator's work. They never initiate anything the administrator must respond to; they only consume what has been published.

Observable success. They can see the photos and read the information, and nothing on the page requires them to sign in or identify themselves.

What makes this role different. The visitor is read-only and anonymous. Their entire experience is one public page, and their success is measured by whether the content is legible and reachable — not by any state they create.

5. Core User Flows

Flow A — A visitor reads the portal

1. The Portal Visitor opens the portal's public entry point. No sign-in is requested.
2. The Landing page renders: the full-bleed ink hero block with the pixel-art portal mark in the top-left, the oversized Space Grotesk headline "Portal dengan admin yang bisa kamu ubah sendiri" left-aligned across 9 of 12 columns, and the single vermilion Masuk Admin button pinned bottom-left.
3. On the right, the administrator's featured photo sits in a square frame, half-bled off the right edge at 380px, outlined in paper white. If no photo is featured, the hero renders without the frame and the headline keeps its span.
4. The visitor reads the 2px paper rule along the bottom of the ink block: photo count, record count, and last-updated timestamp in 13px uppercase mono.
5. The visitor scrolls to the gallery. Square 1:1 thumbnails fade in over 120ms in a strict 12-column grid with 16px gutters, each with a 13px uppercase mono caption.
6. The visitor opens a photo to view it larger.
7. The visitor reads the portal's information sections, rendered from the administrator's records.
8. If content fails to load: an ink-on-paper message with a retry control appears; the visitor retries and the content loads. The hero block and the Masuk Admin button remain usable throughout.
9. If no photos have been published: the gallery shows a 96px pixel-art empty picture frame with a short label instead of an empty grid.
10. The visitor leaves. Nothing was created, and no identity was required.

Flow B — The administrator enrolls on first use

1. Ronald opens the portal for the first time and activates Masuk Admin on the Landing page.
2. The Login page opens. He has no account yet, so he follows the link to Sign Up.
3. On Sign Up, he enters his email, a password, and the password confirmation in 2px outlined fields with labels above them.
4. He activates Create account. The submit control shows a busy state and the fields are disabled.
5. If the email is already registered, the confirmation does not match, or the request fails: an inline message appears above the form, his email is preserved, and he corrects the entry and resubmits.
6. On success, his identity is established and he continues into the administrative area.
7. He lands on Photos, which is empty on first use: a 96px pixel-art empty picture frame, a short label, and the Add photo action.
8. He continues to Flow C.

Flow C — The administrator adds a photo to the portal

1. From Photos, Ronald activates Add photo. The Photo Editor opens in create mode.
2. The image frame shows the 96px pixel-art empty picture frame and prompts him for a file.
3. He activates Choose file and selects an image. The image previews immediately in the 2px-outlined frame over a checkerboard transparency ground, so he can see exactly what he is adding.
4. He enters a caption, decides whether this photo is featured, and sets its ordering value.
5. He activates the vermilion Save in the sticky footer bar — the single vermilion action on this screen.
6. The Save control shows a 3-frame "saved" check that holds for 900ms.
7. He returns to Photos, where the new row is visible: a square 1:1 thumbnail in a 2px-outlined frame, the caption, the featured status, and the last-updated timestamp in 13px uppercase mono.
8. If the file is invalid or unreadable, or the save fails: an inline message appears above the form, and his caption and flags are preserved. He chooses a different file or retries the save without losing work.
9. If he changes his mind: he activates Cancel in the sticky footer bar, his unsaved changes are discarded, and he returns to Photos.
10. The photo now appears on the Landing page gallery for visitors to see.

Flow D — The administrator changes an existing photo

1. Ronald opens Photos and scans the full-width ruled rows. He hovers a row and its blue left edge snaps in.
2. He finds the photo he wants — by scanning captions, or by entering a term in the search control to narrow the list. The row count updates in tabular mono numerals.
3. He activates the pencil row action. The Photo Editor opens with that photo loaded.
4. The current image is shown in the 2px-outlined frame over the checkerboard ground, so he can see exactly what he is replacing.
5. He activates Choose file and selects the replacement image, and edits the caption if needed.
6. He activates the vermilion Save.
7. The 3-frame "saved" check holds for 900ms, and he returns to Photos with the updated row visible.
8. If the save fails: an inline message appears and his entered values are preserved; he retries.
9. The Landing page now shows the updated photo.

Flow E — The administrator chooses the featured photo

1. From Photos, Ronald opens the photo he wants in the Landing hero frame.
2. In the Photo Editor, he toggles the featured flag and activates Save.
3. The 3-frame "saved" check holds for 900ms and he returns to Photos, where the featured status is updated on the row.
4. He opens the Landing page and confirms the chosen photo now sits in the hero frame, half-bled off the right edge, outlined in paper white. The previously featured photo is no longer featured.
5. If the save fails: an inline message appears and the previous featured photo remains in place.

Flow F — The administrator removes a photo

1. From Photos, Ronald activates the trash row action on the photo he no longer wants published.
2. A confirmation step appears. He confirms.
3. The photo is removed and its row disappears from the list.
4. If the delete fails: an inline row-level message appears and the row remains; he retries or dismisses it.
5. The Landing page no longer shows the photo. If it was the featured photo, the hero renders without the right-hand frame.

Flow G — The administrator edits the portal's database content

1. Ronald signs in and opens Records from the admin rail. The active rail item carries the vermilion accent.
2. Full-width ruled rows list every record: the ID in IBM Plex Mono tabular numerals, the title, the type, and the last-updated timestamp. He hovers a row and its blue left edge snaps in.
3. He finds the record he wants — by scanning, or by entering a term in the search control.
4. He activates the pencil row action. The Record Editor opens with that record loaded.
5. He edits the title, type, body, or metadata fields, each a 2px outlined input with its label above it.
6. He activates the vermilion Save in the sticky footer bar.
7. The 3-frame "saved" check holds for 900ms, and he returns to Records with the updated row visible.
8. If validation fails or the save fails: an inline message appears above the form and his entered values are preserved; he corrects the entry and resaves.
9. If he changes his mind: he activates Cancel, his unsaved changes are discarded, and he returns to Records.
10. The Landing page now shows the updated information.

Flow H — The administrator adds a database record

1. From Records, Ronald activates Add record. The Record Editor opens in create mode with empty fields and labels visible.
2. He fills in the title, type, body, and metadata fields.
3. He activates the vermilion Save.
4. The 3-frame "saved" check holds for 900ms, and he returns to Records with the new row visible.
5. If validation fails or the save fails: an inline message appears and his entered values are preserved; he corrects and resaves.
6. The new content appears on the Landing page where it is portal content.

Flow I — The administrator removes a database record

1. From Records, Ronald activates the trash row action on the record he no longer wants published.
2. A confirmation step appears. He confirms.
3. The record is removed and its row disappears from the list.
4. If the delete fails: an inline row-level message appears and the row remains; he retries or dismisses it.
5. The Landing page no longer shows the removed content.

Flow J — The administrator returns and resumes work

1. Ronald opens the portal and activates Masuk Admin on the Landing page.
2. The Login page opens. He enters his email and password in 2px outlined fields.
3. He activates Sign in. The submit control shows a busy state and the fields are disabled.
4. If his credentials are not recognized or the request fails: an inline message appears above the form, his email is preserved, and the password field is cleared. He corrects the entry and resubmits, or follows the link to Sign Up if he needs a different account.
5. On success, his session is established and he continues into the administrative area.
6. He lands on Photos and finds his content exactly as he left it. The 64px top bar shows his name and the sign-out control.
7. He continues with any of Flows C through I.
8. When he is finished, he activates Sign out in the top bar. His session ends and he returns to the public portal.
9. If sign-out fails: he remains signed in and can retry.

Flow K — An unauthenticated request to a protected page

1. Someone requests Photos, Photo Editor, Records, or Record Editor without an established administrator identity.
2. The application does not serve administrative state. The person is directed to Login.
3. They sign in (Flow J) or enroll (Flow B).
4. After identity is established, they reach the administrative page they requested.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. The muse is Susan Kare, and the headline idea is pixel-perfect clarity for a portal you actually run yourself — charming clarity, small legible symbols with personality, grids you can feel, and a tool that respects a non-designer.

Color tokens

Light mode (public portal)

Inverted mode (admin system)

No gradients anywhere. Colour arrives in flat blocks and 2px strokes. Body copy at 16px on the paper ground passes contrast easily; ink is the only text colour.

Typography

Type scale — 1.25 modular: 56 / 44 / 34 / 26 / 20 / 16 / 13.

• Landing headline: clamp(38px, 8vw, 92px) — the biggest thing on the screen.
• Admin page titles: clamp(22px, 3vw, 30px) — compact so the tool stays dense and usable.

Shape language

• Chunky 2px ink outlines with 8px radii on cards, inputs, buttons and image frames — one stroke weight throughout, so the whole interface reads as one drawn system.
• Icons are 24px and 32px pixel-grid pictograms (camera, folder, disk, eye, pencil, trash) drawn on a 2px grid. Never rounded-line library icons.
• Buttons are solid ink or solid blue blocks with a 2px outline and a 2px hard offset shadow — no blur.
• Image thumbnails sit in square 1:1 frames with a 2px outline; the public gallery is a strict 12-column grid of squares.
• No pills, no soft shadows, no glass, no blobs.

Spacing rhythm

• Public Landing: 12-column grid on a 1200px max container; 16px gutters between gallery squares.
• Hero: 48px of air between the headline and the pinned Masuk Admin button.
• Admin: 220px left rail, 64px top bar, full-width ruled rows in the content area.
• Editors: single-column forms, max 720px, label above field.
• At 375px: single column with 20px page padding; the admin rail collapses to a horizontal icon bar under the top bar.

Imagery style

The photos the administrator uploads are the imagery — no stock photography anywhere. Public Landing shows them as square-cropped thumbnails in the grid and one larger 16:9 frame in the hero block if a featured photo exists. Empty states use pixel-art illustrations (an empty picture frame, a blank sheet) at 96px. The Photo Editor shows the image in a 2px-outlined frame with a checkerboard transparency ground so the administrator can see exactly what they are replacing. Icons and pictograms carry the visual personality; there is no decorative illustration beyond them.

7. Signature Design Concept

The first screen is a poster, not a SaaS header.

The public entry is a full-bleed ink (#1C1B18) block — not a white hero. The Space Grotesk headline, "Portal dengan admin yang bisa kamu ubah sendiri", is left-aligned, set at clamp(38px, 8vw, 92px) with tight -0.02em tracking, and spans 9 of 12 columns, breaking across three lines so the words themselves become the composition.

In the top-left corner of the ink block sits a 32px pixel-art portal mark drawn in paper white and vermilion. Bottom-left, pinned beneath the headline with 48px of air, is one solid vermilion (#E4572E) button — Masuk Admin — with a 2px paper outline and a 2px hard offset shadow. It is the only vermilion thing on the screen.

On the right, a single square photo frame — the administrator's featured photo — sits half-bled off the right edge of the viewport at 380px, outlined in paper white. It is the only photograph on the screen, and it is the administrator's own.

A thin 2px paper rule runs along the bottom of the ink block, with 13px uppercase mono metadata sitting on it: FOTO: 24 · RECORD: 118 · TERAKHIR DIPERBARUI: ….

No subtext paragraph. No gradient. No centred stack. No blue button.

Below the ink block, the gallery begins: a strict 12-column grid of square 1:1 thumbnails with 16px gutters and 13px uppercase mono captions — the same 2px outline on every frame, so the whole page looks drawn by one hand.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

Focal subject. The oversized Space Grotesk headline spanning 9 of 12 columns inside the full-bleed ink block, with the administrator's featured photo in a paper-white-outlined square frame half-bled off the right edge.

Input → transformation → outcome thesis. A visitor arrives with no identity and no context; the ink block presents the portal's purpose as a single composed statement, and the featured photo — the administrator's own image — resolves into its frame as it loads. The outcome is comprehension: the visitor understands what this portal is and that it is run by a person, without a paragraph of explanation.

Motion vocabulary. Restrained and frame-based, like an old interface breathing. Buttons depress 2px on press and release, with no easing theatrics. List rows highlight instantly on hover with a blue left edge. Thumbnails fade in over 120ms as they load. The vermilion Save button shows a 3-frame "saved" check that holds for 900ms. No parallax, no scroll-linked effects, no bouncy springs.

Composed first frame. The ink block fills the viewport. The pixel-art portal mark sits top-left. The headline occupies the left 9 columns across three lines. The featured photo frame is half-bled off the right edge, outlined in paper white. The single vermilion Masuk Admin button is pinned bottom-left with 48px of air above it. The 2px paper rule and its mono metadata sit along the bottom edge. Nothing is centred; nothing moves on load except the photo fading in over 120ms.

Reduced-motion state. Under prefers-reduced-motion, all transitions become 0ms and the saved confirmation becomes a static text label. The hero renders in its composed first frame with no fade: the featured photo appears immediately in its frame, and the layout is identical.

9. Non-Functional Requirements

NFR-1 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, card 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 and decoration may be cropped, bled off an edge, or overlapped exactly as the creative direction asks, as long as they cover no readable text or control. Rationale: the administrator is a non-designer who must be able to read and operate the tool on any device.

NFR-2 — Reduced-motion support (explicit) Under prefers-reduced-motion, all transitions become 0ms and the saved confirmation becomes a static text label. Rationale: the creative direction specifies this behavior.

NFR-3 — Administrative changes are confined to the admin system (explicit) Changing photos and database content is performed through the admin system, not from the public Landing page. Rationale: explicit hard constraint in the authoritative user evidence.

NFR-4 — Protected administrative state (required_inference) Photos, Photo Editor, Records and Record Editor are served only to an established Portal Administrator identity; unauthenticated requests are directed to Login without exposing administrative state. Rationale: the accepted journey requires that the administrator's control of portal content be bound to the correct person.

NFR-5 — Persistence of saved work (explicit) Every saved photo and record change is written to storage and is visible on the next read of Photos, Records, and the Landing page. Rationale: the user's stated goal is to be able to change photos and the database; a change that does not persist does not satisfy it.

NFR-6 — No stock or decorative imagery (explicit) The only imagery is the administrator's own uploaded photos, plus the pixel-pictogram icon set and 96px pixel-art empty-state illustrations. No stock photography, no photography of people or stock scenes, no decorative illustration beyond the pictograms. Rationale: creative direction, imagery section.

NFR-7 — No gradients, glass, or soft shadows (explicit) No gradients anywhere. No glassmorphism, backdrop blur, or frosted panels. Shadows are 2px hard offsets only — never soft or blurred. Rationale: creative direction, palette and shape language.

NFR-8 — Icon set is pixel-drawn (explicit) Icons are 24px and 32px pixel-grid pictograms drawn on a 2px grid. Rounded-line icon libraries (Feather, Lucide, Heroicons) are not used. Rationale: creative direction, signature moves.

NFR-9 — Accent rationing (explicit) The vermilion accent (#E4572E) appears on exactly one thing per screen — the Save action in editors, the active tab in the admin rail, or a single Edit affordance. Rationale: creative direction, signature moves — so the administrator always knows the one action that matters.

NFR-10 — Forbidden typography and palette (explicit) Inter, Roboto, Arial, Helvetica, Poppins and system-ui are not used for headings or body. The generic indigo/blue-on-white SaaS template — including #2563EB and #4F46E5 primary on a white or near-white ground — is forbidden for this project. Rationale: creative direction, avoid list.

NFR-11 — Admin list layout is a ledger, not a card grid (explicit) Photos and Records use full-width ruled rows with a blue left edge that snaps in on hover. A grid of identical hover-lift cards is not the primary admin layout. Rationale: creative direction, signature moves.

10. Tech Stack

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

• Frontend — React (web), single-page application serving both the public Landing page and the admin system. [Default — not specified by user]
• Backend — Python with FastAPI, serving the public content API and the protected administrative API. [Default — not specified by user]
• Storage — a relational database for portal content records and photo metadata, plus object or filesystem storage for uploaded image binaries. [Default — not specified by user]
• Identity — application-owned credential storage with hashed passwords and a session mechanism, backing the Sign Up and Login surfaces. [Default — not specified by user]
• Containerization — Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration — Kubernetes is not required; the deployment shape is a single self-hosted instance. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A-1 — The Portal Administrator is the person who requested the portal (Ronald Panuju) and is the sole administrator. No additional administrator accounts, roles, or team members are established by the source. (narrow assumption)
• A-2 — The portal is self-hosted on a single instance; no multi-tenant or multi-site behavior is established. (narrow assumption)
• A-3 — Photos are stored as binary media referenced by records; the exact storage mechanism is an implementation choice. (narrow assumption)
• A-4 — The portal's information content is held in the database records the administrator edits; the Landing page renders from those records. (narrow assumption, consistent with FR-3, FR-19, FR-24)
• A-5 — The identity lifecycle (first-use enrollment, returning sign-in, protected administrative access) is inferred only because the accepted journey — an administrator who repeatedly returns to change protected content — cannot be executed without it. No adjacent account-management capability is included. (required_inference)

Constraints

• C-1 — Administrative capabilities (changing photos and database content) are performed through the admin system. (explicit)
• C-2 — The Landing page is public and requires no identity; the administrative pages require an established Portal Administrator identity. (explicit access contract)
• C-3 — The creative direction is authoritative for palette, typography, shape language, layout, motion, and imagery. (explicit)
• C-4 — Readable text and controls stay whole at every viewport; imagery and decoration may be cropped or bled. (explicit)
• C-5 — No gradients, glassmorphism, soft shadows, rounded-line icon libraries, stock photography, or the generic indigo/blue-on-white SaaS template. (explicit)

12. Glossary

Portal Administrator — The accepted human persona who signs into the admin system and changes the portal's photos and database content. The only writing actor in the product.

Portal Visitor — The accepted human persona who browses the public portal anonymously and views the photos and information the administrator maintains.

Landing — The public entry page. Anonymous, no identity required. Presents the portal's photos and information.

Login — The anonymous identity surface where a returning Portal Administrator verifies their identity.

Sign Up — The anonymous identity surface where the Portal Administrator establishes their identity on first use.

Photos — The protected administrative overview listing every photo in the portal as full-width ruled rows.

Photo Editor — The protected administrative page for adding or updating one photo.

Records — The protected administrative overview listing the database records that back the portal's content.

Record Editor — The protected administrative page for adding or editing one database record.

Photo — A stored image with a caption, a featured flag, an ordering value, and a last-updated timestamp.

Portal content record — A database record with an ID, title, type, body, metadata, and last-updated timestamp. Rendered as portal information on the Landing page.

Featured photo — The single photo marked to appear in the Landing hero frame.

Ruled row — The admin list row pattern: full-width, with a blue left edge that snaps in on hover.

Pixel pictogram — A 24px or 32px icon drawn on a 2px grid (camera, folder, disk, eye, pencil, trash). Never a rounded-line library icon.

Ink block — The full-bleed #1C1B18 hero block on the Landing page.

Paper ground — The #F4F1E8 background of the public portal.

Vermilion accent — #E4572E, rationed to exactly one thing per screen.