System Requirements Document for rencana-kopi

1. Introduction

RENCANA KOPI is a coffee shop operations application. It connects the sellable menu to raw material inventory so that what the shop can sell stays honest against what the shop actually has on hand, and it raises automated notifications when raw material stock runs low. It runs the counter: taking orders, applying discount vouchers linked to WhatsApp numbers, and printing receipts wirelessly to a Bluetooth thermal printer. It keeps the books: detailed daily sales reports for business analysis with PDF export. It keeps the shop's identity: a customizable store profile whose logo and business address appear on every printed receipt. It manages the back room: an inventory menu for product data and categories. And it controls who may do what through user access controls.

The audience is the people behind a small-to-mid coffee shop counter: the owner/manager who owns the business outcome, the cashier/barista who rings up orders and prints receipts during a rush, and the inventory/stock staff who keep product data and raw material counts accurate so shortages are caught before they cost a sale.

2. System Overview

RENCANA KOPI is a first-party application with an application-owned identity. Staff reach an anonymous Landing page that explains the shop application and its operational capabilities; identity is established or verified on the Login page, which supports invitation-based first-use access and returning verification. Once inside, the working surfaces are ruled panels reached from a left rail of chunky tab buttons: Menu, Inventory, Products, POS, Users, Reports, Store Profile, and Vouchers.

Current delivery covers: menu-to-inventory integration; automated low-stock notification processing against durable inventory records; POS printer selection and wireless Bluetooth thermal receipt printing; user access controls; detailed daily sales reports with PDF export; store profile settings for logo and business address used on printed receipts; an inventory menu for product data and categories; and discount vouchers linked to WhatsApp numbers.

Actors are the three accepted human personas — Coffee Shop Owner / Manager, Cashier / Barista (POS Operator), and Inventory / Stock Staff — plus typed non-persona actors: the Bluetooth thermal printer (an external device the application sends receipt data to), the PDF document generator (a system process producing an export artifact), and the automated low-stock notification processor (a background system process). WhatsApp numbers are recorded voucher identifiers; the application does not own a WhatsApp messaging surface.

Narrow exclusions: no online storefront, no customer-facing ordering, no delivery or courier workflow, no payment-gateway processing, no loyalty points program, no multi-branch or franchise consolidation, no supplier purchase-order workflow, no payroll or scheduling, and no WhatsApp messaging client inside the application.

2a. Product Interpretation and Delivery Boundary

RENCANA KOPI is delivered as a first-party custom application with application-owned identity and custom UI. The Landing page is anonymously reachable and carries no protected operational state. Login is the access boundary: it is anonymously reachable so that it can establish first use from an invitation or provisioning and verify returning staff, and it never exposes protected operational records before identity is established. Every operational destination — Menu, Inventory, Products, POS, Users, Reports, Store Profile, Vouchers — is role-restricted and requires an established identity.

Access control is a first-class accepted capability, not a convention: the owner/manager configures which users exist and what they may reach, and the role-restricted destinations honor that configuration. Application identity and session continuity are used for continuity and access control only; they do not by themselves create differentiated visibility beyond what the owner/manager configures on the Users page.

Two capabilities are owned outside the application's own screens and are treated as such: wireless receipt printing is delivered to a Bluetooth thermal printer that the operator selects and pairs, and PDF export produces a generated document artifact. Automated low-stock notification processing runs as a background system process against durable inventory records and surfaces its results as stamped badges in the top bar and on inventory rows — it is not a separate destination.

Everything described in this document is current. No future-horizon requirements were accepted.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Product name RENCANA KOPI as a stamped wordmark; the headline "KOPI DIHITUNG. STOK DIJAGA."; a subline in all-caps Oswald; a ruled capability list of five rows separated by 2px ink rules, each row a thick-line icon plus an all-caps label: MENU ↔ STOK, NOTIFIKASI STOK RENDAH, CETAK STRUK BLUETOOTH, LAPORAN HARIAN + PDF, VOUCHER WHATSAPP. No protected operational data is shown.
• Primary action: Enter the application (routes to Login).
• Supporting actions: Read the capability rows; view the halftone shop photograph band.
• Domain entities: None persisted. Presentation only.
• Component responsibilities: Badge-poster hero (stacked headline left, circular stamp mark right, bleeding off the right edge at desktop, moving above the headline and scaling to 160px on mobile); full-width 3px ink rules above and below the hero; ruled capability list with the last row carrying the primary CTA button in burnt orange; full-bleed halftone photograph band of the actual shop (counter, grinder, hands tamping) used once.
• States: Loading — static content, no spinner required. Empty — not applicable. Success — page renders with hero, stamp, capability list, and CTA. Error — not applicable for static content; if the entry route fails, the CTA remains visible and retryable. Recovery — CTA remains whole and inside the viewport at 375px, 768px, and 1280px.

Login

• Information/state: Anonymous access boundary. Invitation/provisioning context when arriving from an invitation; returning-verification context otherwise. No protected operational records are displayed before identity is established.
• Primary action: Establish first use from an invitation or provisioning, or verify identity as a returning staff member.
• Supporting actions: Correct an entry error and retry; return to Landing.
• Domain entities: Staff identity, invitation/provisioning record, session.
• Component responsibilities: Label-above-input fields with 2px ink borders (no floating labels); primary submit button in ink with a 4px radius and a 2px ink shadow that shifts to 4px on hover; inline error region; link back to Landing.
• States: Loading — submit button shows a pressed/disabled state during verification. Empty — fields render empty with all-caps 13px labels. Success — identity established, session begins, and the user continues to the destination their access permits. Error — invalid or expired invitation, or failed verification, shows a plain-language message with the field preserved for correction. Recovery — the user can retry, or return to Landing and re-enter.

Menu

• Information/state: The sellable coffee menu, with each menu item's availability linked to raw material inventory. Shows item name, category chip, price, and inventory-linked availability. Low-stock conditions that affect menu availability are visible as stamped badges.
• Primary action: Create, edit, and remove menu items and set their price and category.
• Supporting actions: Link a menu item to the raw materials it consumes; view which raw materials constrain an item; filter by category chip.
• Domain entities: Menu item, category, raw material link, availability state.
• Component responsibilities: Ruled table with a 2px ink header rule, all-caps Oswald 13px labels, left-aligned text and right-aligned tabular numerals; category chips as solid-fill small stamps in mustard, forest, denim, and orange; row-level stamped low-stock badge; item editor panel with label-above-input fields.
• States: Loading — ruled table skeleton with header rule in place. Empty — a stamped empty state with a thick-line coffee cup icon and a prompt to add the first menu item. Success — the item appears in the ruled table with its category chip and availability. Error — a failed save keeps the editor open with the entered values intact and a plain-language message. Recovery — retry the save, or discard and return to the table.

Inventory

• Information/state: Raw material records with current stock levels, units, and restock thresholds. Automated low-stock notifications surface here as circular stamped badges in burnt orange with a 2px ink outline and a hard 3px offset shadow, on the affected inventory rows and in the top bar.
• Primary action: Record raw material stock levels and adjust them as stock moves.
• Supporting actions: Set or change a raw material's restock threshold; acknowledge a low-stock notification; filter to low-stock rows.
• Domain entities: Raw material, stock level, unit, restock threshold, low-stock notification.
• Component responsibilities: Ruled table with 2px ink header rule and right-aligned tabular numerals; stamped low-stock badge component; threshold editor with label-above-input fields; top-bar notification badge.
• States: Loading — ruled table skeleton. Empty — stamped empty state with a bean sack icon and a prompt to add the first raw material. Success — the stock level is recorded and any threshold breach raises a stamped low-stock badge. Error — a failed stock update leaves the previous value displayed and shows a plain-language message. Recovery — retry the update; the notification badge persists until the stock level is corrected or acknowledged.

Products

• Information/state: The inventory menu workspace for product data and categories. Shows product records with their category assignment and the data fields that describe them.
• Primary action: Create, edit, and remove product data.
• Supporting actions: Create, rename, and remove categories; assign a product to a category; filter the product list by category chip.
• Domain entities: Product, category, product data fields.
• Component responsibilities: Ruled product table with 2px ink header rule; category chip stamps; category management panel; product editor with label-above-input fields and 2px ink borders.
• States: Loading — ruled table skeleton. Empty — stamped empty state with a tag icon and a prompt to add the first product or category. Success — the product or category appears in the ruled table with its chip. Error — a failed save keeps the editor open with values intact and a plain-language message. Recovery — retry the save, or discard and return to the table.

POS

• Information/state: The counter sales surface. Shows the current order's line items in a ruled table with a 2px ink header rule, all-caps Oswald 13px labels, and right-aligned tabular numerals; the running total in Oswald 600–700 with tabular alignment; the applied voucher and its WhatsApp-linked discount; and the configured Bluetooth thermal printer's connection state.
• Primary action: Ring up an order and print the receipt wirelessly to the configured Bluetooth thermal printer.
• Supporting actions: Add and remove line items; apply a discount voucher by its WhatsApp-linked number; select the POS printer; retry a failed print.
• Domain entities: Order, order line item, menu item, voucher, WhatsApp number, printer configuration, receipt.
• Component responsibilities: Ruled line-item table; tabular-numeral total block; voucher application field; printer selection and connection indicator; print action with a 3-frame stamp animation; receipt preview in 58mm thermal-paper format with a torn top edge.
• States: Loading — the menu list loads into the item picker with a ruled skeleton. Empty — no line items yet, with a stamped empty state and a prompt to add the first item. Success — the order total is correct, the voucher discount is reflected, and the receipt prints to the Bluetooth thermal printer. Error — the printer is unavailable or the print fails: the order is preserved, a plain-language message names the printer problem, and the print action remains available to retry. Recovery — reconnect or reselect the printer and retry the print without re-entering the order.

Users

• Information/state: The application's user access controls. Shows each user, their role, and what they may reach. Reflects the owner/manager's configuration of access.
• Primary action: Configure user access controls — create a user, assign a role, and set what that role may reach.
• Supporting actions: Invite or provision a staff member for first use; change a user's role; deactivate a user's access.
• Domain entities: User, role, permission assignment, invitation/provisioning record.
• Component responsibilities: Ruled user table with 2px ink header rule; role assignment control; invitation/provisioning action; access editor with label-above-input fields.
• States: Loading — ruled table skeleton. Empty — stamped empty state with a badge icon and a prompt to add the first user. Success — the user appears in the ruled table with their role, and their access takes effect on the role-restricted destinations. Error — a failed save keeps the editor open with values intact and a plain-language message. Recovery — retry the save, or discard and return to the table.

Reports

• Information/state: Detailed daily sales reports for business analysis. Shows the day's sales broken down in detail, with totals in Oswald 600–700 using tabular numerals at 39px mobile → 61px desktop.
• Primary action: Review a day's detailed sales report.
• Supporting actions: Select the day to report on; export the report data to PDF.
• Domain entities: Daily sales report, sales line, totals, PDF export artifact.
• Component responsibilities: Ruled report table with a 2px ink header rule, all-caps Oswald 13px labels, and right-aligned tabular numerals; large tabular-numeral total block; day selector; PDF export action; the exported PDF shares the same visual grammar as the POS screen and the receipt.
• States: Loading — ruled report skeleton with the header rule in place. Empty — a stamped empty state with a chart icon indicating no sales recorded for the selected day. Success — the detailed daily report renders and the PDF export produces the document. Error — a failed export shows a plain-language message and leaves the on-screen report intact. Recovery — retry the export; the report remains readable and re-exportable.

Store Profile

• Information/state: The store's identity as it appears on printed receipts. Shows the selected logo inside a circular ink-outlined stamp badge, the business address, and a live receipt preview that mimics 58mm thermal paper with a torn top edge.
• Primary action: Select the store logo and set the business address that appear on printed receipts.
• Supporting actions: Replace or remove the logo; edit the business address; preview the receipt with the current logo and address.
• Domain entities: Store profile, logo asset, business address, receipt preview.
• Component responsibilities: Stamp-press logo upload presented as a circular ink-outlined badge; address fields with label-above-input 2px ink borders; live 58mm receipt preview with torn top edge.
• States: Loading — the profile and preview load with a ruled skeleton. Empty — no logo selected: the stamp badge shows a placeholder mark and the preview shows the address only. Success — the logo and address are saved and the receipt preview reflects them. Error — an unsupported logo file or a failed save shows a plain-language message and keeps the previous logo and address in place. Recovery — choose a different file or retry the save; the previous receipt identity remains valid until a new one is saved.

Vouchers

• Information/state: Discount vouchers linked to WhatsApp numbers. Shows each voucher's discount, its linked WhatsApp number, and its state.
• Primary action: Create and manage discount vouchers linked to WhatsApp numbers.
• Supporting actions: Edit a voucher's discount; change the linked WhatsApp number; deactivate a voucher.
• Domain entities: Discount voucher, discount value, linked WhatsApp number, voucher state.
• Component responsibilities: Ruled voucher table with 2px ink header rule; WhatsApp number field with label-above-input 2px ink border; discount value field with tabular numerals; voucher editor panel.
• States: Loading — ruled table skeleton. Empty — stamped empty state with a tag icon and a prompt to create the first voucher. Success — the voucher appears in the ruled table with its linked WhatsApp number and is available to apply at POS. Error — a failed save keeps the editor open with values intact and a plain-language message. Recovery — retry the save, or discard and return to the table.

3. Functional Requirements

FR-1 — Application identity and purpose (explicit) As a Coffee Shop Owner / Manager, I should run a coffee shop application named "RENCANA KOPI" so that my shop's operations live in one named place.

• Trigger/input: The application is opened.
• Observable result: The application presents itself as RENCANA KOPI.
• Access state: Landing is anonymously reachable; operational destinations require an established identity.
• Failure/recovery: Not applicable.
• Continuation: The user proceeds to Login or to a destination their access permits.

FR-2 — Menu integrated with raw material inventory (explicit) As an Inventory / Stock Staff member, I should have the menu integrated with raw material inventory so that what the shop sells stays tied to what the shop actually has.

• Trigger/input: A menu item is created or edited, or a raw material stock level changes.
• Observable result: The menu item's availability reflects its linked raw material inventory.
• Access state: Menu is role-restricted.
• Failure/recovery: A failed link or save keeps the previous menu item state and shows a plain-language message; the user retries.
• Continuation: The linked availability is visible on the Menu page and constrains what can be sold at POS.

FR-3 — Automated low-stock notification (explicit) As an Inventory / Stock Staff member, I should receive an automated notification when raw material stock runs low so that I restock before a shortage affects sales.

• Trigger/input: A raw material stock level falls to or below its restock threshold.
• Observable result: A circular stamped low-stock badge in burnt orange with a 2px ink outline and a hard 3px offset shadow appears in the top bar and on the affected inventory row.
• Access state: Inventory is role-restricted; the notification surfaces to users with access to inventory records.
• Failure/recovery: If notification processing fails, the durable inventory record remains correct and the badge appears once processing succeeds; the user can also see the low stock directly on the Inventory page.
• Continuation: The user records a restock, which clears the condition, or acknowledges the notification.

FR-4 — POS printer selection and wireless receipt printing (explicit) As a Cashier / Barista (POS Operator), I should select a POS printer and print receipts wirelessly in Bluetooth thermal printer formats so that I hand the customer a receipt without leaving the counter.

• Trigger/input: The operator selects the POS printer and triggers a print for a completed order.
• Observable result: The receipt prints wirelessly to the selected Bluetooth thermal printer in its thermal format, with a 3-frame stamp animation shown during printing.
• Access state: POS is role-restricted.
• Failure/recovery: If the printer is unavailable or the print fails, the order is preserved, a plain-language message names the printer problem, and the print action remains available to retry.
• Continuation: The operator reconnects or reselects the printer and retries the print without re-entering the order.

FR-5 — User access controls (explicit) As a Coffee Shop Owner / Manager, I should configure user access controls so that only the right staff reach protected operational work.

• Trigger/input: The owner/manager creates a user, assigns a role, and sets what that role may reach.
• Observable result: The user appears in the ruled user table with their role, and their access takes effect on the role-restricted destinations.
• Access state: Users is role-restricted to the owner/manager.
• Failure/recovery: A failed save keeps the editor open with values intact and shows a plain-language message; the user retries.
• Continuation: The configured access governs what each staff member reaches on their next visit.

FR-6 — Detailed daily sales reports (explicit) As a Coffee Shop Owner / Manager, I should review detailed daily sales reports so that I can analyze how the business is performing.

• Trigger/input: The owner/manager selects a day to report on.
• Observable result: The day's sales render in detail in a ruled report table with right-aligned tabular numerals and a large tabular-numeral total block.
• Access state: Reports is role-restricted to the owner/manager.
• Failure/recovery: If the report fails to load, a plain-language message appears and the day selector remains available to retry.
• Continuation: The owner/manager reads the report or exports it to PDF.

FR-7 — PDF export of report data (explicit) As a Coffee Shop Owner / Manager, I should export report data to PDF so that I can keep or share the analysis outside the application.

• Trigger/input: The owner/manager triggers the PDF export from the Reports page.
• Observable result: A PDF document is generated containing the report data, sharing the same visual grammar as the POS screen and the receipt.
• Access state: Reports is role-restricted to the owner/manager.
• Failure/recovery: If the export fails, a plain-language message appears and the on-screen report stays intact and re-exportable.
• Continuation: The owner/manager retries the export or continues reading the on-screen report.

FR-8 — Customizable store profile for receipts (explicit) As a Coffee Shop Owner / Manager, I should select a store logo and set the business address so that printed receipts carry the shop's identity.

• Trigger/input: The owner/manager selects a logo and enters the business address on the Store Profile page.
• Observable result: The logo displays inside a circular ink-outlined stamp badge and the address is saved; both appear on printed receipts, previewed live in 58mm thermal-paper format with a torn top edge.
• Access state: Store Profile is role-restricted to the owner/manager.
• Failure/recovery: An unsupported logo file or a failed save shows a plain-language message and keeps the previous logo and address in place.
• Continuation: The next printed receipt carries the saved logo and address.

FR-9 — Inventory menu for product data and categories (explicit) As an Inventory / Stock Staff member, I should manage product data and categories in the inventory menu so that the shop's product records stay accurate and organized.

• Trigger/input: The staff member creates, edits, or removes a product or a category, or assigns a product to a category.
• Observable result: The product or category appears in the ruled table with its category chip stamp.
• Access state: Products is role-restricted.
• Failure/recovery: A failed save keeps the editor open with values intact and shows a plain-language message; the user retries.
• Continuation: The updated product data and categories are available to the Menu and Inventory pages.

FR-10 — Discount vouchers linked to WhatsApp numbers (explicit) As a Coffee Shop Owner / Manager, I should create and manage discount vouchers linked to WhatsApp numbers so that a customer's number identifies the discount they are entitled to.

• Trigger/input: The owner/manager creates or edits a voucher with a discount value and a linked WhatsApp number.
• Observable result: The voucher appears in the ruled voucher table with its linked WhatsApp number and is available to apply at POS.
• Access state: Vouchers is role-restricted.
• Failure/recovery: A failed save keeps the editor open with values intact and shows a plain-language message; the user retries.
• Continuation: The voucher can be applied at POS by its WhatsApp-linked number.

FR-11 — Applying a WhatsApp-linked voucher at POS (explicit) As a Cashier / Barista (POS Operator), I should apply a discount voucher by its WhatsApp-linked number at POS so that the customer receives the discount they are entitled to.

• Trigger/input: The operator enters the voucher's WhatsApp-linked number against the current order.
• Observable result: The voucher's discount is reflected in the order total, shown in tabular numerals.
• Access state: POS is role-restricted.
• Failure/recovery: If the number matches no active voucher, a plain-language message appears and the order total is unchanged; the operator can retry or continue without the voucher.
• Continuation: The operator completes the order and prints the receipt.

FR-12 — Staff invitation or provisioning before first use (required_inference) As a Coffee Shop Owner / Manager, I should invite or provision a staff member before their first use so that they can establish access to the protected operational records they need.

• Trigger/input: The owner/manager invites or provisions a staff member from the Users page.
• Observable result: An invitation/provisioning record exists for that staff member, and they can establish first use on the Login page.
• Access state: Users is role-restricted to the owner/manager; Login is anonymously reachable so it can accept the invitation.
• Failure/recovery: An invalid or expired invitation shows a plain-language message on Login with the field preserved for correction.
• Continuation: The staff member establishes first use and reaches the destinations their role permits.

FR-13 — Returning identity verification (required_inference) As a Cashier / Barista (POS Operator), I should verify my identity when I return to the application so that I resume my own access to protected operational records.

• Trigger/input: The staff member submits their credentials on the Login page.
• Observable result: Identity is established, a session begins, and the user continues to a destination their access permits.
• Access state: Login is anonymously reachable; no protected operational records are displayed before identity is established.
• Failure/recovery: Failed verification shows a plain-language message with the field preserved for correction; the user retries or returns to Landing.
• Continuation: The user proceeds to their permitted destination.

FR-14 — Roles and permissions configured before protected work (required_inference) As a Coffee Shop Owner / Manager, I should have user roles and permissions configured before protected operational work is performed so that access control is real rather than assumed.

• Trigger/input: The owner/manager assigns a role and its reach on the Users page.
• Observable result: Role-restricted destinations honor the configured access.
• Access state: Users is role-restricted to the owner/manager; the configured access governs Menu, Inventory, Products, POS, Reports, Store Profile, and Vouchers.
• Failure/recovery: A failed configuration save keeps the editor open with values intact and shows a plain-language message; the user retries.
• Continuation: The configured access applies to each staff member's next visit.

FR-15 — Bluetooth thermal printer availability and configuration (required_inference) As a Cashier / Barista (POS Operator), I should have the Bluetooth thermal printer available and configured so that wireless receipt printing works when I need it.

• Trigger/input: The operator selects the POS printer and the application establishes its availability.
• Observable result: The printer's connection state is shown on the POS page, and printing proceeds in Bluetooth thermal printer format.
• Access state: POS is role-restricted.
• Failure/recovery: If the printer is unavailable, a plain-language message names the problem and the print action remains available to retry after reconnecting or reselecting.
• Continuation: The operator prints the receipt for the current order.

FR-16 — Automated low-stock processing against durable inventory records (required_inference) As an Inventory / Stock Staff member, I should have low-stock notification processing run against durable inventory records so that a notification reflects real stock rather than a transient reading.

• Trigger/input: A raw material stock level is recorded or adjusted.
• Observable result: The durable inventory record is updated, and notification processing evaluates it against its restock threshold.
• Access state: Inventory is role-restricted; processing runs as a background system process.
• Failure/recovery: If processing fails, the durable inventory record remains correct and the badge appears once processing succeeds.
• Continuation: The low-stock badge persists until the stock level is corrected or acknowledged.

FR-17 — PDF report generation (required_inference) As a Coffee Shop Owner / Manager, I should have the PDF report generated as a document so that the export is a real artifact I can keep or share.

• Trigger/input: The owner/manager triggers the PDF export from the Reports page.
• Observable result: A PDF document is produced containing the report data.
• Access state: Reports is role-restricted to the owner/manager.
• Failure/recovery: If generation fails, a plain-language message appears and the on-screen report stays intact and re-exportable.
• Continuation: The owner/manager retries the export or continues reading the on-screen report.

4. User Personas

Coffee Shop Owner / Manager

Product context: The owner/manager runs the business and owns its outcome. They are not necessarily behind the counter all day, but they are accountable for whether receipts print correctly with the right branding and whether daily sales data is available for analysis.

Primary goal: Keep the shop's identity, access, and numbers correct — receipts that carry the right logo and address, staff who can reach only what they should, and daily sales data they can actually analyze.

Distinct accepted responsibilities: Configuring the store profile (logo and business address used on printed receipts); setting up user access controls, including inviting or provisioning staff and assigning roles and permissions; selecting the POS printer for wireless Bluetooth thermal receipt printing; reviewing detailed daily sales reports and exporting them to PDF; creating and managing discount vouchers linked to WhatsApp numbers.

Relevant inputs or decisions: Which logo and business address represent the shop on receipts; which staff exist and what each role may reach; which POS printer is the shop's printer; which day's sales to analyze; which vouchers to create and which WhatsApp numbers they link to.

Interactions with other accepted participants: Invites or provisions the Cashier / Barista and the Inventory / Stock Staff and configures their access. Their store profile decisions determine what appears on the receipts the Cashier / Barista prints. Their voucher decisions determine which discounts the Cashier / Barista can apply at POS.

Observable success: Receipts print with the correct logo and business address; each staff member reaches only their permitted destinations; the daily sales report renders in detail and exports to PDF.

Cashier / Barista (POS Operator)

Product context: The cashier/barista works the counter during service, often under time pressure, with a customer waiting. They need the till screen to be fast and legible and the receipt to come out without fiddling with settings.

Primary goal: Ring up orders quickly, apply the right discount, and hand over a printed receipt without leaving the counter.

Distinct accepted responsibilities: Taking orders from the menu at POS; applying discount vouchers by their WhatsApp-linked number; printing receipts wirelessly to the configured Bluetooth thermal printer; verifying their identity when returning to the application.

Relevant inputs or decisions: Which menu items make up the order; whether the customer has a voucher and what WhatsApp number it is linked to; which POS printer to print to; whether to retry a failed print.

Interactions with other accepted participants: Relies on the owner/manager's store profile so the receipt carries the right logo and address, on the owner/manager's printer selection, and on the owner/manager's voucher records so a WhatsApp-linked number resolves to a discount. Relies on the Inventory / Stock Staff keeping stock accurate so menu availability is truthful.

Observable success: The order total is correct, the voucher discount is reflected, and the receipt prints wirelessly to the Bluetooth thermal printer without manual reconfiguration.

Inventory / Stock Staff

Product context: The inventory/stock staff member works the back of house, keeping product records and raw material counts accurate. They are the person who notices a shortage before it becomes a lost sale.

Primary goal: Keep stock records current so shortages are caught before they affect sales, and keep product data and categories organized.

Distinct accepted responsibilities: Maintaining product data and categories in the inventory menu; keeping raw material stock levels accurate so the menu stays linked to inventory; responding to the automated low-stock notification system by restocking.

Relevant inputs or decisions: Which products exist and how they are categorized; current raw material stock levels and units; restock thresholds; whether to acknowledge a low-stock notification or record a restock.

Interactions with other accepted participants: Their stock accuracy determines what the Cashier / Barista can actually sell from the menu. Their product and category records feed the Menu page. Their low-stock responses clear the badges the owner/manager and other staff see.

Observable success: Stock records are current, low-stock badges appear when thresholds are breached and clear when stock is restored, and product data and categories are accurate.

5. Core User Flows

Flow 1 — Owner/Manager: Set up the shop's receipt identity

1. The owner/manager opens RENCANA KOPI and lands on the anonymous Landing page, which presents the RENCANA KOPI wordmark, the headline "KOPI DIHITUNG. STOK DIJAGA.", and the ruled capability list.
2. They enter the application and verify their identity on Login.
3. They open Store Profile from the left rail.
4. They select the store logo. The logo displays inside a circular ink-outlined stamp badge, presented as a stamp press.
5. They enter the business address in the label-above-input fields.
6. They view the live receipt preview in 58mm thermal-paper format with a torn top edge, confirming the logo and address appear as they will on a printed receipt.
7. They save. Observable result: the logo and address are saved and the preview reflects them.
8. Failure/recovery: if the logo file is unsupported or the save fails, a plain-language message appears and the previous logo and address remain in place; the owner/manager chooses a different file or retries the save.
9. Continuation: the next receipt printed at POS carries the saved logo and address.

Flow 2 — Owner/Manager: Configure user access controls

1. The owner/manager verifies their identity on Login and opens Users.
2. They create a user, assign a role, and set what that role may reach.
3. Observable result: the user appears in the ruled user table with their role.
4. They invite or provision a staff member for first use. Observable result: an invitation/provisioning record exists for that staff member.
5. Failure/recovery: if a save fails, the editor stays open with values intact and a plain-language message appears; the owner/manager retries.
6. Continuation: the configured access takes effect on the role-restricted destinations — Menu, Inventory, Products, POS, Reports, Store Profile, and Vouchers — on each staff member's next visit.

Flow 3 — Owner/Manager: Select the POS printer for wireless receipt printing

1. The owner/manager verifies their identity on Login and opens POS.
2. They select the POS printer and the application establishes its availability. Observable result: the printer's connection state is shown on the POS page.
3. Failure/recovery: if the printer is unavailable, a plain-language message names the problem and the selection remains available to retry.
4. Continuation: the selected Bluetooth thermal printer is the printer receipts print to.

Flow 4 — Owner/Manager: Create a discount voucher linked to a WhatsApp number

1. The owner/manager verifies their identity on Login and opens Vouchers.
2. They create a voucher, entering the discount value and the linked WhatsApp number.
3. Observable result: the voucher appears in the ruled voucher table with its linked WhatsApp number.
4. Failure/recovery: if the save fails, the editor stays open with values intact and a plain-language message appears; the owner/manager retries.
5. Continuation: the voucher is available to apply at POS by its WhatsApp-linked number.

Flow 5 — Owner/Manager: Review and export a daily sales report

1. The owner/manager verifies their identity on Login and opens Reports.
2. They select the day to report on.
3. Observable result: the day's sales render in detail in a ruled report table with right-aligned tabular numerals and a large tabular-numeral total block.
4. They trigger the PDF export. Observable result: a PDF document is generated containing the report data, sharing the same visual grammar as the POS screen and the receipt.
5. Failure/recovery: if the export fails, a plain-language message appears and the on-screen report stays intact and re-exportable; the owner/manager retries.
6. Continuation: the owner/manager keeps or shares the PDF, or continues reading the on-screen report.

Flow 6 — Cashier / Barista: Ring up an order, apply a voucher, and print the receipt

1. The cashier/barista verifies their identity on Login and opens POS.
2. They add menu items to the order. Observable result: line items appear in the ruled table with all-caps Oswald 13px labels and right-aligned tabular numerals, and the running total updates in tabular numerals.
3. The customer presents a voucher. The cashier/barista enters the voucher's WhatsApp-linked number against the order.
4. Observable result: the voucher's discount is reflected in the order total.
5. Failure/recovery: if the number matches no active voucher, a plain-language message appears and the order total is unchanged; the cashier/barista retries or continues without the voucher.
6. They trigger the print. Observable result: the receipt prints wirelessly to the selected Bluetooth thermal printer in its thermal format, with a 3-frame stamp animation shown during printing, carrying the store logo inside its circular stamp badge and the business address.
7. Failure/recovery: if the printer is unavailable or the print fails, the order is preserved, a plain-language message names the printer problem, and the print action remains available; the cashier/barista reconnects or reselects the printer and retries without re-entering the order.
8. Continuation: the receipt is handed to the customer and the cashier/barista starts the next order.

Flow 7 — Inventory / Stock Staff: Maintain product data and categories

1. The inventory/stock staff member verifies their identity on Login and opens Products.
2. They create or edit a product, entering its data in the label-above-input fields.
3. They create or rename a category and assign the product to it. Observable result: the product appears in the ruled table with its category chip stamp.
4. Failure/recovery: if a save fails, the editor stays open with values intact and a plain-language message appears; the staff member retries.
5. Continuation: the updated product data and categories are available to the Menu and Inventory pages.

Flow 8 — Inventory / Stock Staff: Keep stock accurate and respond to a low-stock notification

1. The inventory/stock staff member verifies their identity on Login and opens Inventory.
2. They record raw material stock levels and adjust them as stock moves, setting or changing restock thresholds as needed.
3. Observable result: the stock level is recorded. When a level falls to or below its threshold, a circular stamped low-stock badge in burnt orange with a 2px ink outline and a hard 3px offset shadow appears in the top bar and on the affected inventory row.
4. They respond by recording a restock. Observable result: the condition clears and the badge is removed.
5. Failure/recovery: if a stock update fails, the previous value stays displayed with a plain-language message and the staff member retries; if notification processing fails, the durable inventory record remains correct and the badge appears once processing succeeds.
6. Continuation: the corrected stock level flows through to the menu's inventory-linked availability, so the Cashier / Barista sells only what the shop actually has.

Flow 9 — Inventory / Stock Staff: Keep the menu linked to raw material inventory

1. The inventory/stock staff member verifies their identity on Login and opens Menu.
2. They create or edit a menu item, setting its price and category, and link it to the raw materials it consumes.
3. Observable result: the menu item appears in the ruled table with its category chip, and its availability reflects its linked raw material inventory.
4. Failure/recovery: if a link or save fails, the previous menu item state is kept and a plain-language message appears; the staff member retries.
5. Continuation: the linked availability constrains what can be sold at POS.

Flow 10 — Cashier / Barista: Establish first use from an invitation

1. The owner/manager has invited or provisioned the cashier/barista from Users.
2. The cashier/barista opens RENCANA KOPI and lands on the anonymous Landing page.
3. They enter the application and establish first use on Login using the invitation or provisioning.
4. Observable result: identity is established, a session begins, and they continue to a destination their access permits.
5. Failure/recovery: if the invitation is invalid or expired, a plain-language message appears with the field preserved for correction; they retry or return to Landing.
6. Continuation: they reach POS and begin taking orders.

6. Visuals Colors and Theme

Muse: Aaron Draplin. Headline direction: Bold, honest, hand-built — a coffee counter that looks like it was stamped, not templated. The interface is a poster system applied to panels: strong hierarchy, sturdy rules, readable labels, kraft-and-ink ground with a single hot accent.

Colour tokens — light mode

Contrast: ink on kraft ≈ 13:1; ink on card ≈ 15:1; orange on ink ≈ 5.4:1, used for text only at 16px+ or as a fill behind white/ink text. Secondary supporting colours appear only as small solid chips or stamps, never as a section background.

Typography

• Headings: Alfa Slab One, all-caps, tight tracking (-0.01em) for the wordmark, page titles, and numeric totals. Weight is inherently heavy, so size does the work.
• Body and labels: Oswald. Body copy 16–17px with 0.01em tracking; all-caps labels 12–13px with 0.14em tracking for field names, table headers, and badge text.
• Numbers: Oswald 600–700 with font-feature-settings: 'tnum' for tabular alignment in reports and POS totals.
• Scale: 1.25 modular on a 16px base — 12 / 13 / 16 / 20 / 25 / 31 / 39 / 49 / 61 / 76. Display headline clamps 40px mobile → 76px desktop. Page titles 31px mobile → 49px desktop. Section labels 13px caps. Body 16px, never below 15px. Report totals 39px mobile → 61px desktop.

Shape language

Chunky and hand-built. 4px radii on buttons and inputs — nearly square, like a printed stamp. 8px radii on cards and panels. Borders: 2px solid ink for primary containers, 1px solid rgba(27,23,19,0.18) for internal rules. Badges and stamps are circles or rounded rectangles with a 2px ink outline and a solid fill. No soft shadows; instead a hard 3px offset shadow in ink or a doubled border so a card feels pressed onto the page. Section dividers are 3px solid ink rules running the full width, sometimes with a small stamped label sitting on the rule.

Layout

Poster-like sections stacked on a 12-column grid with a 24px gutter and a max width of 1240px. Each major section opens with a full-width 3px ink rule and a small all-caps label sitting on it, like a chapter tab. Inside the app, screens are ruled panels: a left rail of chunky tab buttons (Menu, Inventory, Products, POS, Users, Reports, Store Profile), a main panel with a header strip, and a bordered content card. Tables are ruled with 1px lines and 2px header rules, aligned left, numbers right. Every form field is a label above a 2px-bordered input; no floating labels. At 375px the rail collapses to a horizontal scrollable tab strip pinned under the top bar and all panels become single column.

Imagery

Thick-line vector icons drawn on a 24px grid with a 2.5px stroke — coffee cup, grinder, bean sack, printer, tag, receipt, chart. Icons are the primary imagery and appear in badges, tab rails, empty states, and category chips. Supporting imagery is limited to two things: a halftone-treated photograph of the actual shop (counter, grinder, hands tamping) used once as a full-bleed band on the landing page, and badge/stamp marks for the store logo slot. No stock photography, no 3D renders, no gradient meshes, no illustration for decoration. The store profile logo upload is presented as a stamp press: the uploaded logo sits inside a circular ink-outlined badge.

7. Signature Design Concept

The Printed Badge Poster. The public entry is a printed badge poster, not a SaaS hero. A 3px ink rule runs the full viewport width above the hero and below it. Left two-thirds: an oversized stacked headline in Alfa Slab One at clamp(40px, 8vw, 76px), all caps, in ink on the kraft ground, reading KOPI DIHITUNG. STOK DIJAGA., with a smaller Oswald all-caps subline beneath. To its right, bleeding off the right edge at desktop, a large circular stamp mark (240–320px) in burnt orange with a 3px ink outline containing a thick-line coffee cup and the RENCANA KOPI wordmark wrapped around the circle; on mobile the stamp moves above the headline and scales to 160px, fully inside the viewport. Beneath the headline, a ruled capability list of five rows separated by 2px ink rules, each row a thick-line icon plus an all-caps label — MENU ↔ STOK, NOTIFIKASI STOK RENDAH, CETAK STRUK BLUETOOTH, LAPORAN HARIAN + PDF, VOUCHER WHATSAPP — with the last row carrying the primary CTA button in orange. No centred text, no gradient, no floating cards. The concept recomposes only accepted content, states, and controls: it introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The circular burnt-orange stamp mark containing the thick-line coffee cup and the wrapped RENCANA KOPI wordmark, paired with the stacked Alfa Slab One headline.
• Input → transformation → outcome thesis: As the visitor arrives, the hero composes itself like a stamp coming down — the ink rules settle, the headline and stamp land, and the ruled capability list resolves row by row — so the visitor reads the shop's operational capabilities and reaches the orange CTA. The transformation uses only accepted content and the accepted entry action; it produces no new behaviour.
• Motion vocabulary: Restrained and mechanical, like a stamp coming down. 140–180ms transitions with a slight overshoot on press (scale 0.98 → 1.0). Tabs and buttons carry a 2px ink shadow that shifts to 4px on hover, giving a physical press. No parallax, no particles, no ambient loops.
• Composed first frame: Kraft ground #F2E9DA; a full-width 3px ink rule at the top; the stacked headline in ink at its clamp size on the left; the circular orange stamp mark at the right edge, bleeding off at desktop and fully inside the viewport at 160px on mobile; beneath, the five ruled capability rows with the orange CTA on the last row; a full-width 3px ink rule below.
• Reduced-motion state: With prefers-reduced-motion, every transition becomes an instant state change — the hero renders fully composed in its first frame, with no settle, no overshoot, and no shadow shift.

9. Non-Functional Requirements

NFR-1 — Wireless Bluetooth thermal receipt printing (explicit) Receipt printing must be wireless and must support Bluetooth thermal printer formats. Rationale: the operator prints at the counter without a cable and the printer consumes the thermal format it supports. The receipt preview on Store Profile mimics 58mm thermal paper with a torn top edge so the on-screen preview matches the printed artifact.

NFR-2 — Receipt branding (explicit) The store logo and business address must appear on printed receipts. Rationale: the store profile's purpose is receipt identity. The logo displays inside a circular ink-outlined stamp badge everywhere it appears.

NFR-3 — Voucher linkage (explicit) Discount vouchers are linked to WhatsApp numbers. Rationale: the WhatsApp number is the voucher's identifying link. The application records and resolves that number; it does not own a WhatsApp messaging surface.

NFR-4 — Report detail and export (explicit) Sales reports must be detailed and daily, with PDF export available. Rationale: the reports exist for business analysis, and the PDF is the artifact that leaves the application.

NFR-5 — Access control enforcement (explicit, with required_inference mechanics) User access controls must govern the role-restricted destinations. Rationale: access control is an accepted capability, and the configured roles and permissions must actually determine what each staff member reaches. Login is anonymously reachable so it can establish first use and verify returning staff; no protected operational records are displayed before identity is established.

NFR-6 — Automated low-stock processing durability (required_inference) Automated low-stock notification processing runs against durable inventory records. Rationale: a notification must reflect real stock, so the record it evaluates must persist independently of any single screen session.

NFR-7 — PDF generation (required_inference) PDF report generation must produce a real document artifact. Rationale: the accepted export must be usable outside the application.

NFR-8 — Readable text and controls at every viewport (explicit direction constraint) Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, 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. Moving and scrollable content may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. With prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto).

NFR-9 — Motion restraint (explicit direction constraint) Motion is restrained and mechanical: 140–180ms transitions with a slight overshoot on press (scale 0.98 → 1.0); a 2px ink shadow on tabs and buttons shifting to 4px on hover; low-stock alerts entering with a single 200ms slide-and-settle and no looping pulse; receipt printing showing a 3-frame stamp animation. No parallax, no particles, no ambient loops. With prefers-reduced-motion, everything becomes an instant state change.

NFR-10 — Visual system integrity (explicit direction constraint) The interface uses the kraft/ink/burnt-orange palette, Alfa Slab One and Oswald only, 4px button and input radii, 8px card radii, 2px ink borders on primary containers, 1px internal rules, and hard 3px offset shadows instead of soft shadows. The generic indigo/blue-on-white SaaS template is forbidden.

10. Tech Stack

• Frontend: React, delivering the custom UI surfaces described in this document. [Default — not specified by user]
• Backend: Python with FastAPI, providing the application's API, the durable inventory records that low-stock processing evaluates, the daily sales report data, and the PDF report generation. [Default — not specified by user]
• Storage: A relational database for menu items, raw materials and stock levels, products and categories, orders and order line items, vouchers and their linked WhatsApp numbers, users, roles and permissions, the store profile, and daily sales report data. [Default — not specified by user]
• Receipt printing: Bluetooth thermal printer integration from the POS surface, producing Bluetooth thermal printer formats wirelessly. (explicit)
• PDF export: Server-side PDF document generation for daily sales reports. (required_inference)
• Packaging and local run: Docker and docker-compose. [Default — not specified by user]
• Deployment: Kubernetes is not required for this project's current delivery. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A1: The three personas in Section 4 are the complete active human set for this project. (required_inference, from the accepted persona catalog)
• A2: Staff reach the application through an invitation or provisioning for first use and verify their identity on return. (required_inference)
• A3: The owner/manager configures roles and permissions before protected operational work is performed, and the role-restricted destinations honor that configuration. (required_inference)
• A4: A Bluetooth thermal printer is available to the shop and is selected and paired from the POS surface before wireless receipt printing. (required_inference)
• A5: Automated low-stock notification processing runs as a background system process against durable inventory records and surfaces its results as stamped badges rather than as a separate destination. (required_inference)
• A6: PDF report generation produces a document artifact from the daily sales report data. (required_inference)
• A7: The application records and resolves WhatsApp numbers as voucher identifiers; it does not own a WhatsApp messaging surface. (explicit constraint, interpreted by its stated scope)

Constraints

• C1: Receipt printing must be wireless and must support Bluetooth thermal printer formats. (explicit)
• C2: The store logo and business address must appear on printed receipts. (explicit)
• C3: Discount vouchers are linked to WhatsApp numbers. (explicit)
• C4: Sales reports must be detailed and daily, with PDF export available. (explicit)
• C5: The Landing page is anonymously reachable and carries no protected operational state; Login is anonymously reachable so it can establish first use and verify returning staff; every operational destination is role-restricted. (from the accepted page and access contract)
• C6: The visual system is fixed to the kraft/ink/burnt-orange palette, Alfa Slab One and Oswald, chunky 4px/8px shape language, ruled tables, and stamped badges; the generic indigo/blue-on-white SaaS template is forbidden. (explicit direction constraint)
• C7: Readable text and controls stay whole and inside the viewport and their container at 375px, 768px, and 1280px. (explicit direction constraint)
• C8: No future-horizon requirements were accepted for this project; everything in this document is current. (from the accepted planning scope)

12. Glossary

• RENCANA KOPI — The name of this coffee shop application.
• Menu — The set of sellable coffee shop items, each linked to the raw material inventory it consumes.
• Raw material inventory — The durable record of raw materials, their stock levels, units, and restock thresholds.
• Low-stock notification — The automated notification raised when a raw material's stock level falls to or below its restock threshold, surfaced as a circular stamped badge in burnt orange with a 2px ink outline and a hard 3px offset shadow.
• POS — The counter sales surface where orders are rung up, vouchers are applied, and receipts are printed.
• Bluetooth thermal printer — The external wireless printer that receipts are sent to, consuming Bluetooth thermal printer formats.
• Receipt — The printed artifact produced at POS, carrying the store logo inside a circular stamp badge and the business address.
• Store profile — The shop's receipt identity: the selected logo and the business address.
• Discount voucher — A discount record linked to a WhatsApp number, applied at POS by that number.
• WhatsApp number — The identifier a discount voucher is linked to; the application records and resolves it and does not own a WhatsApp messaging surface.
• Daily sales report — The detailed, per-day record of sales used for business analysis.
• PDF export — The generated document artifact containing report data.
• User access controls — The configuration of users, roles, and what each role may reach, set by the owner/manager on the Users page.
• Role-restricted — A destination that requires an established identity and honors the configured access for that user's role.
• Category chip — A solid-fill small stamp in mustard, forest, denim, or orange used as the only colour in an otherwise kraft-and-ink interface.
• Stamp badge — A circular or rounded-rectangle badge with a 2px ink outline and a solid fill, used for low-stock alerts and the store logo.