System Requirements Document for jobdesk-manager-kdkmp

1. Introduction

jobdesk-manager-kdkmp is a daily jobdesk checklist application for the KDKMP (Koperasi Desa/Kelurahan Merah Putih) store. It exists so that the KDKMP manager — and the store-floor/cashier staff who carry out the operational parts of the same daily routine — can work a fixed 17-item jobdesk from morning briefing through store closing and the profit/EBITDA check, and can see, at any point in the day, exactly which items are done and which are still open.

The product intent is a working instrument, not a marketing surface: a coded register of the day's work that can be trusted at 7am when the store opens and at 9pm when the cash drawer is counted. The audience is the KDKMP manager (who owns the full daily list and the financial target check) and the Petugas Toko/Kasir KDKMP (who performs and marks the recurring store-floor and cashier tasks on the same list).

The 17 jobdesks the application must cover are, exactly as stated by the user:

1. Melakukan briefing pagi
2. Melakukan display barang
3. Melakukan penerimaan barang (Good Receipt) WMS
4. Melakukan Quality Control
5. Melayani pembayaran
6. Memasang harga sesuai produk
7. Memindahkan barang gudang ke rak
8. Memindai barang belanjaan konsumen
9. Menawarkan produk promo upselling
10. Mencocokkan total uang tunai/non-tunai
11. Menerima barang dari Principal
12. Menerima setoran hasil bumi/ternak
13. Persiapan awal buka toko & kasir
14. Mengonsolidasikan produk local
15. Menyiapkan uang setoran bank
16. Proses Penutupan Toko (Closing & Housekeeping)
17. Mengecek target laba & EBITDA

2. System Overview

The application is a first-party web application with its own identity, its own persisted daily checklist state, and a small set of custom pages. It is delivered as a single cohesive product: an anonymous public entry, self-service enrollment and returning verification, a revisitable overview of daily checklists, a focused daily checklist workspace where each of the 17 jobdesks is viewed and marked complete, and a manager-only performance workspace for the daily profit and EBITDA target check.

Actors. Two accepted human personas use the product: Manager KDKMP, who owns the full daily jobdesk list and the profit/EBITDA oversight, and Petugas Toko/Kasir KDKMP, who performs the recurring store-floor and cashier jobdesks and marks them complete on the same daily checklist. No other human personas are in scope.

Accepted behavior. The product covers exactly the 17 listed jobdesks. It records, per day, which jobdesks are complete and which remain incomplete, so that work can be resumed later in the same day. It shows the manager the daily profit and EBITDA target check. It does not perform the underlying store operations (it does not run the WMS, process payments, print prices, or move stock); it is the checklist and record of those operations.

Ownership. All custom pages are application-owned. The application owns identity (self-service enrollment and returning verification), the daily checklist state, and the manager-only performance view. No provider-owned or external destination is part of the accepted scope.

Narrow exclusions. No inventory/WMS integration, no payment processing, no POS scanning, no pricing engine, no bank transfer execution, and no accounting ledger are in scope. The jobdesk items that name those activities are checklist items to be marked complete, not capabilities the application performs. No future-horizon requirements were stated by the user.

2a. Product Interpretation and Delivery Boundary

The user asked for one thing: a daily checklist application for the KDKMP manager's jobdesk, covering the 17 listed items. Everything in this document serves that request.

Delivery. The product is delivered as a first-party custom web application with its own backend persistence. The daily checklist is durable state: a manager or staff member who marks items during the morning shift must be able to return later the same day and see the same completion state, with the remaining items still open. That durability is why the application owns identity and storage rather than being a stateless page.

Access ownership. The public entry (Landing) is anonymously reachable and explains what the checklist is, who it is for, and that it tracks daily completion. Because the source establishes no invitation, provisioning, or pre-existing-account boundary, users begin with self-service enrollment (Sign Up) and return through verification (Login). The daily checklist surfaces and the manager performance surface are protected, because they carry durable, actor-specific daily state and manager-only financial oversight. The Performance surface is restricted to Manager KDKMP, because the profit and EBITDA target check is the manager's oversight responsibility; the daily checklist surfaces are available to both accepted personas, who work the same list.

Current vs. future. All requirements in this document are current. The user stated no future-horizon items, and none are invented here.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

The page inventory is the supplied final page contract, preserved exactly and in order: Landing, Sign Up, Login, Daily Checklists, Daily Checklist, Performance.

Landing

• Purpose and information. Anonymous public entry. Explains the KDKMP daily jobdesk checklist, its intended users (Manager KDKMP and Petugas Toko/Kasir KDKMP), and its daily completion-tracking purpose. States that the checklist covers 17 jobdesks across one day and two roles.
• Primary action. Enter the product ("Masuk"), leading to Login (or Sign Up for a first-time user).
• Supporting actions. Navigate to Sign Up for self-service enrollment.
• Domain entities. The 17 jobdesks as a named, ordered register; the day; the two roles.
• Component responsibilities.
  • Full-bleed paper-white hero field split by a single vertical 1px ink rule at the 40% mark.
  • Left of the rule: stacked display headline in Archivo 700 uppercase — "CHECKLIST HARIAN" / "MANAGER KDKMP" — at clamp(56px, 12vw, 320px), tracking −0.02em, running close to the viewport edge as a printed poster would; beneath it a 13px tracked metadata block reading "17 JOBDESK · 1 HARI · 2 PERAN"; beneath that a flat ink rectangular CTA "Masuk" with 0px radius and no shadow.
  • Right of the rule: the 24-hour clock-face diagram, ~520px, drawn in 1px ink lines, with the 17 jobdesks plotted as labelled ticks from opening at 12 o'clock to closing at 6, and the EBITDA check as the single accent-coloured tick (#E2481F). No card, no frame, sitting directly on the paper ground.
  • A single 3px accent bar runs the full viewport width at the very top of the page as the day marker.
• States.
  • Loading: static content; no data fetch required for the hero. The clock-face diagram renders as inline SVG.
  • Empty: not applicable — the page has no collection state.
  • Success: hero renders with headline, metadata block, CTA, and the 17-tick clock diagram fully legible at 375px, 768px, and 1280px.
  • Error: if the diagram fails to render, the headline, metadata block, and CTA remain fully functional and legible; the diagram area collapses without leaving a broken frame.
  • Recovery: the CTA remains the sole required path into the product; no state on this page blocks entry.

Sign Up

• Purpose and information. Self-service enrollment for a first-time user (Manager KDKMP or Petugas Toko/Kasir KDKMP). Establishes the identity that owns the user's daily checklist state.
• Primary action. Create the account and enter the product.
• Supporting actions. Navigate to Login for an existing user.
• Domain entities. User identity; role selection (Manager KDKMP / Petugas Toko/Kasir KDKMP).
• Component responsibilities.
  • One small centred artefact above the form: a single colour-code strip of six 3px bars (#E2481F, #2C4A8A, #C8A227, #1F6B4A, #6B4A8A, #111111) functioning as the identity mark.
  • Enrollment form: identity fields and role selection, 0px radius inputs with 1px ink hairline rules, 13px uppercase tracked labels, 17px body text.
  • Flat ink submit button, 0px radius, no shadow.
  • Link to Login rendered as ink text with a 1px underline (never blue/indigo).
• States.
  • Loading: submit button shows a restrained in-progress state; fields remain readable.
  • Empty: form renders with empty fields and the colour-code strip.
  • Success: account created; user proceeds into the protected product.
  • Error: field-level validation messages in ink with a 1px rule, stating exactly which field failed and why (for example, an already-enrolled identity or a missing required field); the entered values are preserved so the user does not retype.
  • Recovery: the user corrects the indicated field and resubmits; no partial account is left in a state that blocks a later retry.

Login

• Purpose and information. Returning verification for a user who already has an account, so their durable daily checklist state and (for managers) performance view can be resumed.
• Primary action. Verify identity and enter the product.
• Supporting actions. Navigate to Sign Up for a user who has not yet enrolled.
• Domain entities. User identity; role (Manager KDKMP / Petugas Toko/Kasir KDKMP).
• Component responsibilities.
  • The same six-bar colour-code strip as the identity mark, centred above the form.
  • Verification form: identity fields, 0px radius, 1px ink hairline rules, 13px uppercase tracked labels.
  • Flat ink submit button, 0px radius, no shadow.
  • Link to Sign Up as ink text with a 1px underline.
• States.
  • Loading: submit button shows a restrained in-progress state.
  • Empty: form renders with empty fields and the colour-code strip.
  • Success: identity verified; the user lands on the daily checklist surfaces, with the manager additionally able to reach Performance.
  • Error: a single clear message that the credentials were not accepted, in ink with a 1px rule; entered identity value is preserved, and the credential field is cleared.
  • Recovery: the user retries, or follows the link to Sign Up; no lockout state is invented.

Daily Checklists

• Purpose and information. Revisitable overview of daily checklists and their completion status, covering the listed KDKMP jobdesks. Shows the day's checklist(s) with a completion summary so a user can see at a glance what is done and what is open, and choose which day's checklist to open.
• Primary action. Open a specific day's checklist in the Daily Checklist workspace.
• Supporting actions. Read the completion status of each listed day without opening it.
• Domain entities. Daily checklist (one per day); the 17 jobdesks; completion state per jobdesk; completion count and incomplete count; the day's date.
• Component responsibilities.
  • Left rail (240px): the day's date block, the completion ring (a perfect 1px-stroked circle whose arc advances in accent #E2481F, with the fraction set in 40px tabular figures at its centre), and the category legend as a colour-key list — the same six-bar colour-code strip repeated as wayfinding.
  • Main column: the day's checklist entries as register rows, each with a 3px category bar at the left edge, an index number in tabular figures, the checklist title, and a metadata line (date, completion count, status) in 13px tabular muted #8A857C.
  • At 768px the rail collapses to a horizontal date/legend strip above the list; at 375px each row becomes a stacked block with the index number kept at left, never overlapping the title.
• States.
  • Loading: the rail and list render with the date block and legend visible; list rows show a restrained placeholder in the register-row shape.
  • Empty: no checklist exists for any day yet — the page states plainly that no daily checklist has been started, and offers the path to open today's checklist.
  • Success: the day's checklist(s) render with accurate completion counts and the completion ring showing the correct fraction.
  • Error: if the checklist list cannot be loaded, the page states that the list is unavailable and offers a retry; the rail's date block and legend remain readable.
  • Recovery: retry reloads the list; a failed load never shows a false "complete" state.

Daily Checklist

• Purpose and information. The focused daily workspace: every one of the 17 listed jobdesks is visible as a register row, each can be marked complete, and incomplete work can be continued later in the same day. This is the page where the day's work is actually stamped.
• Primary action. Mark a jobdesk complete (and unmark it if marked in error).
• Supporting actions. Toggle the visible 12-column grid ("Grid" control in the toolbar) to show 1px column rules and 24px gutters; read each row's metadata line (waktu, PIC, status); read the completion ring and the incomplete-item count.
• Domain entities. Daily checklist for the day; the 17 jobdesks with their exact Bahasa Indonesia wording; per-jobdesk completion state; per-jobdesk category (opening, receiving, floor & pricing, cash & bank, closing, targets & EBITDA); per-jobdesk metadata (waktu, PIC, status); completion fraction; incomplete-item count.
• Component responsibilities.
  • Left rail (240px): the day's date block, the completion ring with the fraction in 40px tabular figures at its centre, and the category legend as a colour-key list.
  • Toolbar: the "Grid" control that toggles the visible 12-column grid on and off.
  • Main column: the 17 jobdesks as full-width register rows, each row consisting of a 3px category bar at the left edge, the index number (01–17) in tabular figures, the jobdesk title in sentence case in its exact Bahasa Indonesia wording, a metadata line (waktu, PIC, status) in 13px tabular muted #8A857C, and the checkbox pinned right — a 22px square with a 1.5px ink stroke that, when complete, fills ink and takes a 3px accent corner tick like a stamped form.
  • Section headers for the category blocks, each with a 1px rule that draws left-to-right over 300ms when it enters the viewport, once.
  • At 768px the rail collapses to a horizontal date/legend strip above the list; at 375px every row becomes a stacked block with the checkbox on its own line and the index number kept at left, never overlapping the title.
• States.
  • Loading: the rail, toolbar, and the 17-row register shape render; rows show a restrained placeholder in the register-row shape.
  • Empty: no checklist exists for the day — the page states plainly that today's checklist has not been started and offers to start it; the 17 jobdesks are then shown as open items.
  • Success: each marked jobdesk shows the ink-filled checkbox with the accent corner tick, the row's status metadata updates to complete, the completion ring's arc advances with a 200ms crossfade, and the incomplete-item count decreases.
  • Error: if a completion change cannot be saved, the row reverts to its previous state and the page states that the change was not saved, so the register never shows a completion that was not persisted.
  • Recovery: the user retries the mark; the previously saved state is preserved and the day's remaining items stay open and resumable.
• Continuation. A user who leaves mid-day returns to this page and finds the same completion state, with the remaining jobdesks still open and the incomplete-item count reflecting them.

Performance

• Purpose and information. Manager-only workspace for checking the daily profit and EBITDA targets included in the jobdesk. Presents the day's financial target check alongside the day's jobdesk completion, so the manager can read the operational day and the financial result together.
• Primary action. Read the day's profit and EBITDA target figures and the day's jobdesk completion.
• Supporting actions. Read the jobdesk completion column and the financial column side by side.
• Domain entities. Daily profit figure; daily EBITDA figure; profit and EBITDA targets; the day's jobdesk completion state; the day's date.
• Component responsibilities.
  • Two-column ledger: the jobdesk completion column on the left, the financial column on the right, separated by a full-height 1px rule.
  • The EBITDA number is the one number set apart: it is the single accent-coloured (#E2481F) figure on the page, set in tabular figures.
  • All other figures in ink #111111 with tabular figures; labels in 13px uppercase tracked Archivo 500; metadata in muted #8A857C.
  • No card fills behind text; category colours appear only as bars, dots, and 1px underlines.
• States.
  • Loading: the two-column ledger structure renders with the full-height rule; figures show a restrained placeholder in the ledger shape.
  • Empty: no financial figures recorded for the day — the page states plainly that the day's profit and EBITDA figures are not yet recorded, and shows the jobdesk completion column as it stands.
  • Success: the day's profit and EBITDA figures render against their targets, with the EBITDA figure in accent #E2481F and the jobdesk completion column showing the day's completion state.
  • Error: if the financial figures cannot be loaded, the page states that the figures are unavailable and offers a retry; the jobdesk completion column remains readable.
  • Recovery: retry reloads the figures; the page never displays a stale figure as if it were the current day's.
• Access. Restricted to Manager KDKMP. A Petugas Toko/Kasir KDKMP who reaches this destination is not shown the manager financial oversight.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance. Provenance is explicit (stated by the user), basic_default (accepted default), or required_inference (indispensable inferred mechanics).

FR-01 — Daily jobdesk checklist for the KDKMP manager (explicit) As a Manager KDKMP, I should have a daily checklist application for my KDKMP jobdesk, so that I can work and track my fixed daily routine in one place.

• Trigger/input: the manager opens the application on a working day.
• Observable result: a daily checklist exists for the day, containing the 17 listed jobdesks.
• Access state: protected; requires verified identity.
• Failure/recovery: if the checklist cannot be loaded, the application states this and offers a retry; no partial checklist is presented as complete.
• Continuation: the manager proceeds to mark jobdesks complete and returns later the same day to continue.

FR-02 — Checklist covers all 17 listed jobdesks (explicit) As a Manager KDKMP, I should see all 17 listed jobdesks on the daily checklist, in their exact wording, so that no part of the daily routine is missing from the register.

• The 17 jobdesks, exactly as listed: Melakukan briefing pagi; Melakukan display barang; Melakukan penerimaan barang (Good Receipt) WMS; Melakukan Quality Control; Melayani pembayaran; Memasang harga sesuai produk; Memindahkan barang gudang ke rak; Memindai barang belanjaan konsumen; Menawarkan produk promo upselling; Mencocokkan total uang tunai/non-tunai; Menerima barang dari Principal; Menerima setoran hasil bumi/ternak; Persiapan awal buka toko & kasir; Mengonsolidasikan produk local; Menyiapkan uang setoran bank; Proses Penutupan Toko (Closing & Housekeeping); Mengecek target laba & EBITDA.
• Trigger/input: the daily checklist is opened.
• Observable result: all 17 jobdesks are present as numbered register rows (01–17), each with its exact Bahasa Indonesia wording.
• Access state: protected; requires verified identity.
• Failure/recovery: if any jobdesk fails to render, the checklist states that the register is incomplete rather than silently showing fewer than 17 items.
• Continuation: the user marks items complete from this register.

FR-03 — Mark a jobdesk complete (explicit) As a Manager KDKMP or Petugas Toko/Kasir KDKMP, I should mark a jobdesk complete on the daily checklist, so that the day's progress is recorded as a stamped fact.

• Trigger/input: the user activates the checkbox on a jobdesk row.
• Observable result: the checkbox fills ink and takes a 3px accent corner tick; the row's status metadata reads complete; the completion ring's arc advances; the incomplete-item count decreases.
• Access state: protected; requires verified identity.
• Failure/recovery: if the change cannot be saved, the row reverts to its previous state and the application states that the change was not saved.
• Continuation: the user continues with the remaining open jobdesks.

FR-04 — Unmark a jobdesk marked in error (required_inference) As a Manager KDKMP or Petugas Toko/Kasir KDKMP, I should be able to unmark a jobdesk that was marked complete in error, so that the day's register stays truthful.

• Trigger/input: the user activates the checkbox on a jobdesk row that is already complete.
• Observable result: the checkbox returns to the 1.5px ink-stroked empty square; the row's status metadata returns to open; the completion ring's arc retreats; the incomplete-item count increases.
• Access state: protected; requires verified identity.
• Failure/recovery: if the change cannot be saved, the row reverts to its previous state and the application states that the change was not saved.
• Continuation: the user re-marks the item when the work is actually done.
• Rationale: a stamped register that cannot be corrected would misreport the day; correction is causally necessary for the checklist to be a truthful record.

FR-05 — Persisted daily completion and incomplete-item status (required_inference) As a Manager KDKMP or Petugas Toko/Kasir KDKMP, I should have my daily checklist completion and incomplete-item status persisted, so that I can resume the day's work later without losing what is already done.

• Trigger/input: the user marks or unmarks a jobdesk, or leaves and returns to the application.
• Observable result: on return, the same jobdesks show the same completion state, and the incomplete-item count reflects the remaining open items.
• Access state: protected; requires verified identity, so the state is bound to the correct user.
• Failure/recovery: if persistence fails, the application states that the change was not saved and does not display the unsaved state as saved.
• Continuation: the user resumes from the remaining open jobdesks.
• Rationale: the daily checklist is durable, actor-specific state; without persistence the day's work could not be resumed, which the accepted daily lifecycle requires.

FR-06 — Revisitable overview of daily checklists (required_inference) As a Manager KDKMP or Petugas Toko/Kasir KDKMP, I should see a revisitable overview of daily checklists and their completion status, so that I can see at a glance what is done and what is open, and open the day I need.

• Trigger/input: the user opens the Daily Checklists overview.
• Observable result: the day's checklist(s) are listed with completion counts and status, and the completion ring shows the correct fraction.
• Access state: protected; requires verified identity.
• Failure/recovery: if the list cannot be loaded, the overview states that the list is unavailable and offers a retry; it never shows a false complete state.
• Continuation: the user opens a specific day's checklist in the Daily Checklist workspace.
• Rationale: the daily checklist is a revisitable, resumable artifact; an overview is the indispensable entry point that makes the day's state observable before opening it.

FR-07 — Focused daily workspace for viewing and continuing work (required_inference) As a Manager KDKMP or Petugas Toko/Kasir KDKMP, I should have a focused daily workspace where every listed jobdesk is visible, markable, and continuable, so that I can work the register row by row.

• Trigger/input: the user opens a day's checklist.
• Observable result: the 17 jobdesks render as numbered register rows with category bars, metadata lines, and checkboxes; the completion ring and incomplete-item count are visible in the left rail.
• Access state: protected; requires verified identity.
• Failure/recovery: if the workspace cannot be loaded, it states this and offers a retry; the register is never shown with fewer than the 17 items presented as if complete.
• Continuation: the user marks items and returns later the same day to continue.
• Rationale: the accepted daily lifecycle requires a single focused working context where the register is worked and resumed; the overview alone cannot carry the marking interaction.

FR-08 — Visible, toggleable 12-column grid (explicit, from creative direction) As a Manager KDKMP, I should be able to toggle a visible 12-column grid on the Daily Checklist page, so that the underlying system is inspectable as part of the interface.

• Trigger/input: the user activates the "Grid" control in the toolbar.
• Observable result: 1px column rules and 24px gutters become visible; deactivating the control hides them.
• Access state: protected; requires verified identity.
• Failure/recovery: if the toggle state cannot be applied, the register remains fully usable without the grid.
• Continuation: the user continues working the register.

FR-09 — Manager check of daily profit and EBITDA targets (explicit) As a Manager KDKMP, I should check the daily profit and EBITDA targets, so that I can see whether the day met its financial target.

• Trigger/input: the manager opens the Performance workspace.
• Observable result: the day's profit and EBITDA figures are shown against their targets, with the EBITDA figure set apart as the single accent-coloured number, alongside the day's jobdesk completion column.
• Access state: protected and restricted to Manager KDKMP.
• Failure/recovery: if the figures cannot be loaded, the workspace states that the figures are unavailable and offers a retry; it never displays a stale figure as the current day's.
• Continuation: the manager returns to the daily checklist to close out remaining items.
• Note: the jobdesk "Mengecek target laba & EBITDA" is also a checklist item on the daily register; FR-09 is the manager's oversight view of that target, and FR-03 covers marking the item complete.

FR-10 — Self-service enrollment before first use (required_inference) As a Manager KDKMP or Petugas Toko/Kasir KDKMP, I should be able to enroll myself before first use, so that I can begin using the checklist without an invitation or provisioning step.

• Trigger/input: a first-time user opens Sign Up and submits the enrollment form.
• Observable result: an account is created and the user enters the protected product.
• Access state: anonymous entry; the enrollment interaction itself is reachable without an account.
• Failure/recovery: field-level validation states exactly which field failed and why, and preserves entered values so the user can correct and resubmit.
• Continuation: the user proceeds to the daily checklist surfaces.
• Rationale: the source establishes no invitation, provisioning, provider, or pre-existing-account boundary, so self-service enrollment is the only executable first-use path.

FR-11 — Returning verification before accessing protected data (required_inference) As a Manager KDKMP or Petugas Toko/Kasir KDKMP, I should verify my identity on return, so that my durable daily checklist state and the manager's performance view are protected and correctly resumed.

• Trigger/input: a returning user opens Login and submits their credentials.
• Observable result: identity is verified and the user reaches the daily checklist surfaces; the manager can additionally reach Performance.
• Access state: anonymous entry to the Login surface; protected destinations remain unavailable until verification succeeds.
• Failure/recovery: a single clear message states that the credentials were not accepted; the identity value is preserved and the credential field is cleared, and the user may retry or go to Sign Up.
• Continuation: the user resumes the day's checklist from its persisted state.
• Rationale: the daily checklist state and the manager's financial oversight must remain bound to the correct participant, which requires returning verification.

FR-12 — Differentiated manager access for profit and EBITDA oversight (required_inference) As a Manager KDKMP, I should have access to the profit and EBITDA oversight that Petugas Toko/Kasir KDKMP do not have, so that manager-only financial oversight stays with the manager.

• Trigger/input: a user attempts to reach the Performance workspace.
• Observable result: Manager KDKMP sees the Performance workspace; Petugas Toko/Kasir KDKMP does not see the manager financial oversight.
• Access state: protected; the Performance destination is restricted to Manager KDKMP.
• Failure/recovery: a user without access is not shown the manager financial figures; the daily checklist surfaces remain fully available to them.
• Continuation: the user continues on the daily checklist surfaces.
• Rationale: the profit and EBITDA target check is the manager's oversight responsibility, and the accepted scope differentiates manager access from store/cashier access for that oversight.

4. User Personas

Manager KDKMP

Product context. The manager runs the KDKMP store's full daily routine, from the morning briefing through receiving, quality control, pricing, cash reconciliation, bank deposit preparation, and store closing, and is accountable for the day's profit and EBITDA target. The manager is the persona the user explicitly named when requesting the application.

Primary goal. Work the fixed 17-item daily jobdesk to completion and confirm whether the day met its profit and EBITDA target.

Distinct accepted responsibilities. The manager owns the complete daily list, including the items that are oversight rather than store-floor execution: Melakukan briefing pagi, Menerima barang dari Principal, Menerima setoran hasil bumi/ternak, Mengonsolidasikan produk local, Menyiapkan uang setoran bank, Proses Penutupan Toko (Closing & Housekeeping), and Mengecek target laba & EBITDA. The manager is also the only persona who checks the daily profit and EBITDA target in the Performance workspace.

Relevant inputs or decisions. Which jobdesks are done and which remain open at any point in the day; whether the day's profit and EBITDA figures meet their targets; whether a jobdesk marked complete was actually done and must be unmarked.

Interactions with other accepted participants. The manager and Petugas Toko/Kasir KDKMP work the same daily checklist. The manager's oversight of the day's completion depends on the store/cashier staff marking their operational jobdesks, and the manager's own items (briefing, receiving from Principal, hasil bumi/ternak deposits, local product consolidation, bank deposit preparation, closing, and the target check) are the manager's to complete.

Observable success. All 17 jobdesks show as complete for the day, the completion ring reads full, the incomplete-item count is zero, and the Performance workspace shows the day's profit and EBITDA figures against their targets.

Petugas Toko/Kasir KDKMP

Product context. The store-floor and cashier staff who perform the recurring operational parts of the same daily jobdesk. This role is inferred from the accepted scope: several listed jobdesks are operational store-floor and cashier tasks, and they are performed and marked on the same daily checklist.

Primary goal. Complete the day's operational store-floor and cashier jobdesks and mark them complete on the daily checklist so the day's register is accurate.

Distinct accepted responsibilities. The operational jobdesks: Melakukan display barang, Melakukan penerimaan barang (Good Receipt) WMS, Melakukan Quality Control, Melayani pembayaran, Memasang harga sesuai produk, Memindahkan barang gudang ke rak, Memindai barang belanjaan konsumen, Menawarkan produk promo upselling, Mencocokkan total uang tunai/non-tunai, and Persiapan awal buka toko & kasir. This role does not have the manager's profit and EBITDA oversight.

Relevant inputs or decisions. Which operational jobdesks are done and which remain open; whether an item marked complete needs to be unmarked because it was marked in error.

Interactions with other accepted participants. The staff member works the same daily checklist as the Manager KDKMP. Their marks are what make the day's completion state — and therefore the manager's view of the day — accurate. The manager's briefing and closing items bracket the staff member's operational day.

Observable success. The operational jobdesks the staff member is responsible for show as complete for the day, the completion ring reflects the day's progress, and the remaining open items are visible for continuation.

5. Core User Flows

Flow A — Manager KDKMP: first use and enrollment

1. The manager opens the application and lands on Landing (anonymous). The page states that this is the KDKMP daily jobdesk checklist, covering 17 jobdesks across one day and two roles, and offers the "Masuk" action.
2. The manager follows the path to Sign Up for self-service enrollment, because no invitation or provisioning step exists.
3. On Sign Up, the manager enters the enrollment form and selects the Manager KDKMP role, then submits.
4. Observable result: the account is created and the manager enters the protected product.
5. Failure/recovery: if a field fails validation, the page states exactly which field failed and why and preserves the entered values; the manager corrects the field and resubmits.
6. Next step: the manager proceeds to Daily Checklists.

Flow B — Manager KDKMP: returning verification

1. The manager opens the application and goes to Login.
2. The manager submits their credentials.
3. Observable result: identity is verified and the manager reaches the daily checklist surfaces, with Performance additionally available.
4. Failure/recovery: if the credentials are not accepted, a single clear message states this; the identity value is preserved, the credential field is cleared, and the manager retries or follows the link to Sign Up.
5. Next step: the manager resumes the day's checklist from its persisted state.

Flow C — Manager KDKMP: working the daily jobdesk register

1. The manager opens Daily Checklists and sees the day's checklist with its completion status and the completion ring showing the day's fraction.
2. The manager opens the day's checklist in Daily Checklist.
3. The manager reads the 17 jobdesks as numbered register rows (01–17), each with its category bar, its exact Bahasa Indonesia wording, and its metadata line (waktu, PIC, status).
4. The manager works the day: conducts the morning briefing, receives goods from the Principal, receives the hasil bumi/ternak deposit, consolidates local products, prepares the bank deposit money, and performs the closing and housekeeping routine — marking each jobdesk complete as it is done.
5. For each mark, the manager activates the row's checkbox. Observable result: the checkbox fills ink and takes the 3px accent corner tick, the row's status reads complete, the completion ring's arc advances with a 200ms crossfade, and the incomplete-item count decreases.
6. Failure/recovery: if a completion change cannot be saved, the row reverts to its previous state and the application states that the change was not saved; the manager retries the mark.
7. If the manager marked a jobdesk complete in error, they activate the checkbox again to unmark it. Observable result: the checkbox returns to the empty 1.5px ink square, the status returns to open, and the incomplete-item count increases.
8. Optionally, the manager activates the "Grid" control in the toolbar to inspect the 12-column grid, then deactivates it.
9. Next step: the manager leaves and returns later the same day; the persisted state shows the same completed items, with the remaining jobdesks still open and resumable.

Flow D — Manager KDKMP: checking the daily profit and EBITDA target

1. The manager opens Performance (restricted to Manager KDKMP).
2. The manager reads the two-column ledger: the day's jobdesk completion column on the left, the financial column on the right, separated by a full-height 1px rule.
3. Observable result: the day's profit and EBITDA figures are shown against their targets, with the EBITDA figure set apart as the single accent-coloured (#E2481F) number, alongside the day's jobdesk completion.
4. Failure/recovery: if the figures cannot be loaded, the workspace states that the figures are unavailable and offers a retry; it never displays a stale figure as the current day's.
5. Next step: the manager returns to Daily Checklist to close out any remaining open jobdesks, including the "Mengecek target laba & EBITDA" item.

Flow E — Petugas Toko/Kasir KDKMP: first use and enrollment

1. The staff member opens the application and lands on Landing (anonymous), which states who the checklist is for, including store/cashier staff.
2. The staff member follows the path to Sign Up and enrolls, selecting the Petugas Toko/Kasir KDKMP role.
3. Observable result: the account is created and the staff member enters the protected product.
4. Failure/recovery: field-level validation states exactly which field failed and preserves entered values for correction and resubmission.
5. Next step: the staff member proceeds to Daily Checklists.

Flow F — Petugas Toko/Kasir KDKMP: working the operational jobdesks

1. The staff member opens Daily Checklists and sees the day's checklist with its completion status.
2. The staff member opens the day's checklist in Daily Checklist.
3. The staff member performs the day's operational work — display barang, penerimaan barang (Good Receipt) WMS, Quality Control, melayani pembayaran, memasang harga sesuai produk, memindahkan barang gudang ke rak, memindai barang belanjaan konsumen, menawarkan produk promo upselling, mencocokkan total uang tunai/non-tunai, and persiapan awal buka toko & kasir — marking each jobdesk complete as it is done.
4. For each mark, the staff member activates the row's checkbox. Observable result: the checkbox fills ink and takes the 3px accent corner tick, the row's status reads complete, the completion ring's arc advances, and the incomplete-item count decreases.
5. Failure/recovery: if a completion change cannot be saved, the row reverts to its previous state and the application states that the change was not saved; the staff member retries the mark.
6. If an item was marked in error, the staff member unmarks it; the checkbox returns to the empty ink square and the incomplete-item count increases.
7. Observable result for the manager's side of the same day: the staff member's marks are what make the day's completion state accurate, so the manager's view of the day reflects the operational work actually done.
8. Next step: the staff member leaves and returns later the same day; the persisted state shows the same completed items, with the remaining jobdesks still open and resumable.

Flow G — Petugas Toko/Kasir KDKMP: no manager financial oversight

1. The staff member is working on the daily checklist surfaces.
2. The staff member does not have access to the manager's profit and EBITDA oversight in Performance.
3. Observable result: the manager financial figures are not shown to the staff member; the daily checklist surfaces remain fully available.
4. Next step: the staff member continues working the day's operational jobdesks.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Peter Saville; the headline idea is one colour code carries the whole KDKMP day — a coded register stamped with authority, not a marketing surface.

Mode. Light mode only.

Colour tokens by role.

Coded colour alphabet (category bars, dots, 1px underlines only — never fills behind text).

Proportion. ~80% paper and ink, ~15% muted grey metadata, ~5% the coded colours combined.

Typography. Headings and body: Archivo only. No italics anywhere. Numbers use tabular figures so counts and Rupiah columns align like a printed register. Case is a hierarchy tool: uppercase = system label; sentence case = the actual jobdesk wording in Bahasa Indonesia.

• Headings: Archivo 700 at display sizes, tracking −0.02em, uppercase for the wordmark and section numerals; Archivo 500 at 15–17px with 0.08em tracking and uppercase for all labels, category names, and metadata.
• Body: Archivo.
• Scale (1.25 modular): 320 / 96 / 64 / 40 / 28 / 20 / 17 / 15 / 13.
• Hero display: clamp(56px, 12vw, 320px). Page title: clamp(32px, 5vw, 64px). Section number: clamp(24px, 4vw, 40px). Card title: 20px. Jobdesk body: 17px. Label: 13px uppercase tracked. Metadata: 13px tabular.

Shape language. Rectilinear and unrounded: 0px radius on cards, buttons, inputs, and panels. 1px hairline rules — #111111 at 100% for structural rules, #8A857C at 30% for internal dividers. Where a curve is unavoidable (the progress ring, the checkbox) it is a perfect circle with a 1px stroke, never a rounded-rect. The single exception is a 2px top border on each card in its category colour, acting as the code. No shadows at all; depth is expressed by rule weight and by white panels sitting on the paper ground. Checkbox: 22px square with a 1.5px ink stroke; when complete it fills ink and takes a 3px accent corner tick, like a stamped form.

Spacing rhythm. Strict 12-column grid on a 1280px canvas with 24px gutters and a visible 1px column rule set, toggleable on the Daily Checklist page as a "Grid" control — the grid is content, not scaffolding. Left rail 240px. Register rows are full-width with consistent vertical rhythm; metadata lines sit directly under their jobdesk title.

Imagery style. No photography and no illustration. The imagery is the system itself: the colour-coded register, the grid, the completion ring, the tabular ledger, and — on the landing page — one large diagrammatic artefact: a single 24-hour clock-face diagram drawn in 1px ink lines with the 17 jobdesks plotted as labelled ticks around it, opening at the top and closing at the bottom, with the EBITDA check as the one accent-coloured tick. Category colours are the only other visual material. Sign-up and login keep one small centred artefact: a single colour-code strip of six 3px bars above the form, functioning as the identity mark.

Explicitly avoided. Blue, indigo, or violet primaries on white (no #0057FF, #2563EB, #4F46E5, #6366F1 or neighbours anywhere, including focus rings and links — links are ink with a 1px underline); rounded cards, pill buttons, soft drop shadows, glassmorphism, hover-lift card grids; gradient blobs or any gradient as a hero background; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body; emoji, checkmark illustrations, stock photography of smiling staff, warm character illustration; category colours as background fills behind text or as decorative confetti; celebratory confetti, streak animations, or gamified badges on completion; centred hero stacks and any decorative motion beyond the defined 180–300ms state changes.

Readable text and controls stay whole at every viewport. 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, and 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 they cover no readable text or control. With prefers-reduced-motion, motion stops and whole items are shown.

7. Signature Design Concept

The public entry is a printed poster of the working day, not a centred hero over a gradient.

The Landing page is a full-bleed paper-white field (#F4F2ED) split by a single vertical 1px ink rule at the 40% mark. A single 3px accent bar (#E2481F) runs the full viewport width at the very top of the page as the day marker.

Left of the rule — the poster column: a stacked display headline in Archivo 700 uppercase reading "CHECKLIST HARIAN" / "MANAGER KDKMP", set at clamp(56px, 12vw, 320px) with tight −0.02em tracking, filling the column edge to edge and deliberately running close to the viewport edge as a printed poster would. Beneath it, a small 13px tracked metadata block reads "17 JOBDESK · 1 HARI · 2 PERAN". Directly under that, a flat ink rectangular CTA "Masuk" — no radius, no shadow.

Right of the rule — the artefact: the 24-hour clock-face diagram, ~520px, drawn in 1px ink lines, with the 17 jobdesks plotted as labelled ticks from opening at 12 o'clock to closing at 6, and the EBITDA check as the single accent-coloured tick (#E2481F). It sits directly on the paper ground with no card, no frame, no glow.

The whole product is explained in that one drawn artefact: a fixed register of work plotted across a single day, with the financial target as the one number set apart. No image, no gradient, no floating card. The sign-up and login surfaces carry the same identity mark in miniature — a single colour-code strip of six 3px bars above the form — so identity and wayfinding are the same object.

8. Interaction Model & Motion Direction

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

The creative direction sets a still tempo and flat hero dimensionality; this section copies that tempo rather than re-deciding it.

Landing Hero Motion Brief

• Focal subject. The 24-hour clock-face diagram — 17 jobdesks plotted as labelled 1px ink ticks from opening at 12 o'clock to closing at 6, with the EBITDA check as the only accent-coloured tick.
• Input → transformation → outcome thesis. The page loads → the 1px ink rules of the clock face and the register ticks resolve into place, with the accent EBITDA tick the single saturated mark → the visitor reads the entire product in one artefact: a fixed 17-item day, opening to closing, with the financial target set apart. No accepted behaviour is added; the diagram only recomposes the accepted 17 jobdesks and the day.
• Motion vocabulary. Almost nothing moves. The permitted vocabulary is the direction's: a 180ms ink fill on the checkbox plus a single 3px accent tick drawing in over 120ms; a 200ms crossfade when the completion ring's arc advances; a 240ms precise fade-up of the next jobdesk row when a section is completed, with no translate beyond 4px; section headers get a 1px rule that draws left-to-right over 300ms when they enter the viewport, once. No bouncing, no spring, no parallax, no hover lift — hover is a 1px underline appearing under the jobdesk title plus the row's category bar growing from 3px to 5px in 120ms.
• Composed first frame. Paper-white field, the 3px accent day-marker bar across the top, the vertical 1px ink rule at the 40% mark, the stacked uppercase headline filling the left column with the tracked metadata block and the flat ink "Masuk" CTA beneath it, and the clock-face diagram sitting on the paper ground to the right — fully composed before any motion, legible at 375px, 768px, and 1280px.
• Reduced-motion state. With prefers-reduced-motion, all motion stops: the clock-face diagram and register render whole and static, the completion ring shows its current arc without crossfade, and no row fade-up or rule-draw occurs. Every item remains fully readable.

No user-requested 3D/WebGL is present, and the direction's hero dimensionality is flat, so no 3D scene brief is required.

9. Non-Functional Requirements

NFR-01 — Persistence of daily checklist state (required_inference) Daily checklist completion and incomplete-item status must be persisted server-side so that a user can leave and resume the same day's work. Rationale: the accepted daily lifecycle requires resumable state; without persistence the checklist could not be continued later in the day.

NFR-02 — Identity-bound state (required_inference) Persisted daily checklist state and the manager performance view must be bound to the verified user identity, so that a returning user resumes their own state and the manager's financial oversight stays with the manager. Rationale: the accepted scope requires returning verification and differentiated manager access.

NFR-03 — Truthful completion state (required_inference) The application must never display a completion state that was not successfully persisted; a failed save must revert the row and state that the change was not saved. Rationale: the checklist is a record of the day's work and must be trustworthy at the moment the cash drawer is counted.

NFR-04 — Readability at all supported viewports (explicit, from creative direction) Headlines, wordmarks, labels, numbers, card text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Rationale: the direction requires readable text and controls to stay whole at every viewport.

NFR-05 — Reduced-motion support (explicit, from creative direction) With prefers-reduced-motion, motion must stop and whole items must be shown. Rationale: the direction requires a reduced-motion state.

NFR-06 — No shadows, no gradients, no rounded surfaces (explicit, from creative direction) The interface must use 0px radius on cards, buttons, inputs, and panels; no shadows; and no gradients as backgrounds. Rationale: the direction's shape language and its explicit avoidance list.

NFR-07 — Archivo only, tabular figures (explicit, from creative direction) Headings and body must use Archivo only, with tabular figures for numbers; the forbidden font list (Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, system-ui) must not be used for headings or body. Rationale: the direction's typography rule.

NFR-08 — No blue/indigo/violet primaries (explicit, from creative direction) Blue, indigo, or violet primaries on white — including #0057FF, #2563EB, #4F46E5, #6366F1 and neighbours — must not appear anywhere, including focus rings and links. Links are ink with a 1px underline. Rationale: the direction's explicit avoidance and the project-wide prohibition on the generic indigo/blue-on-white SaaS template.

10. Tech Stack

The user specified no technology choices. The following are coherent defaults for the accepted scope, labeled as defaults.

• Frontend: React (web), single-page application. [Default — not specified by user]
• Backend: Python / FastAPI, providing identity, daily checklist persistence, and the manager performance data. [Default — not specified by user]
• Storage: a relational database for users, daily checklists, per-jobdesk completion state, and daily profit/EBITDA figures. [Default — not specified by user]
• Containerization: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Kubernetes: not required by the accepted scope; omitted. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A-01. The 17 jobdesks are a fixed daily list; the user did not state that items are added, removed, or reordered by users. [Assumption — not specified by user]
• A-02. A daily checklist exists per day, and the day's checklist is the unit that is worked and resumed. [Assumption — not specified by user]
• A-03. Both accepted personas work the same daily checklist; the manager's oversight depends on the store/cashier staff marking their operational items. [Assumption — derived from the accepted scope]
• A-04. The daily profit and EBITDA figures are recorded for the day and read by the manager in the Performance workspace; the user did not specify how those figures are entered. [Assumption — not specified by user]
• A-05. The application is a checklist and record; it does not perform the underlying store operations named in the jobdesks. [Assumption — derived from the accepted scope]

Constraints

• C-01. The checklist must cover exactly the 17 listed jobdesks, in their exact Bahasa Indonesia wording. (explicit)
• C-02. The active human personas are exactly Manager KDKMP and Petugas Toko/Kasir KDKMP. (explicit / required_inference per the accepted persona catalog)
• C-03. The page inventory is exactly: Landing, Sign Up, Login, Daily Checklists, Daily Checklist, Performance. (final page contract)
• C-04. The Performance destination is restricted to Manager KDKMP. (required_inference)
• C-05. The visual direction is binding: paper ground #F4F2ED, ink #111111, single accent #E2481F, muted #8A857C, the six-colour category alphabet, Archivo only, 0px radius, no shadows, no gradients, no blue/indigo/violet primaries. (explicit, creative direction)
• C-06. No inventory/WMS integration, payment processing, POS scanning, pricing engine, bank transfer execution, or accounting ledger is in scope. (derived from the accepted scope)

12. Glossary

• KDKMP — Koperasi Desa/Kelurahan Merah Putih; the rural Indonesian co-op store this application serves.
• Jobdesk — A single item on the daily work list; the application covers exactly 17.
• Daily Checklist — The day's register of the 17 jobdesks, with per-item completion state.
• Daily Checklists — The revisitable overview of daily checklists and their completion status.
• Completion ring — The 1px-stroked circle on the left rail whose accent arc shows the day's completion fraction.
• Incomplete-item count — The number of jobdesks on the day's checklist that are not yet marked complete.
• Category bar — The 3px colour bar at the left edge of each register row, encoding the jobdesk's category.
• Category alphabet — The six coded colours: opening #E2481F, receiving #2C4A8A, floor & pricing #C8A227, cash & bank #1F6B4A, closing #6B4A8A, targets & EBITDA #111111.
• Register row — A full-width row presenting one jobdesk: category bar, index number, title, metadata line, checkbox.
• WMS — Warehouse Management System; named in the jobdesk "Melakukan penerimaan barang (Good Receipt) WMS". The application does not integrate with it.
• Good Receipt — The receiving step named in the WMS jobdesk.
• Principal — The supplier from whom goods are received, named in the jobdesk "Menerima barang dari Principal".
• Hasil bumi/ternak — Agricultural and livestock produce deposited to the store, named in the jobdesk "Menerima setoran hasil bumi/ternak".
• EBITDA — Earnings before interest, taxes, depreciation, and amortization; the financial target the manager checks daily.
• PIC — Person in charge; shown in each register row's metadata line.
• Waktu — Time; shown in each register row's metadata line.
• Manager KDKMP — The accepted persona who owns the full daily jobdesk list and the profit/EBITDA oversight.
• Petugas Toko/Kasir KDKMP — The accepted persona who performs the recurring store-floor and cashier jobdesks on the same daily checklist.