Prompt စာကြည့်တိုက်

Build a production-ready Quark App plugin for multi-branch inventory control.

## Business context
A retail / wholesale operator runs 2–20 branches. Warehouse staff and branch managers must always know on-hand quantity per product per branch. Owners need a cross-branch view and a low-stock list. Adjustments must be auditable (who / when / why) — never silent edits.

## Goal (one sentence)
Ship a calm, mobile-friendly inventory plugin where staff adjust stock with a required reason, managers export CSV, and owners compare branches — using standard Quark App services, entities, pages, and localization.

## Actors & permissions
1. Warehouse staff
   - View stock for branches they can access.
   - Create adjustments (positive or negative) with required reason + optional note.
   - View recent adjustment history for a product/branch.
2. Branch manager
   - Same as staff for their own branch only.
   - Export current stock CSV for their branch.
3. Owner / admin
   - See all branches.
   - Compare quantity of one SKU across branches.
   - Configure low-stock threshold (default 5 for v1; store in settings if easy, else hardcode with a TODO).

Deny cross-branch adjust for branch managers. Show clear empty / forbidden states.

## Primary user flows
### Flow A — Find stock
1. Open Stock list.
2. Filter by branch (required for non-admin), product name or SKU search, toggle “Low stock only”.
3. See columns: Product name, SKU, Branch, Qty, Updated at.
4. Tap a row → Stock detail (current qty + last 20 adjustments).

### Flow B — Adjust stock
1. From list or detail → Adjust.
2. Confirm product + branch (pre-filled when possible).
3. Enter delta as signed number OR “set to” absolute qty (pick one UX; prefer delta with live preview of new qty).
4. Reason: required select or short text (min 3 chars). Presets: Received, Damaged, Count correction, Return, Other.
5. Optional note (max 500 chars).
6. Save → create adjustment ledger row → update on-hand qty atomically → toast success → return to detail.
7. Validation: reject qty going below 0 unless admin override “Allow negative” (default off).

### Flow C — Low stock
1. Low stock page lists products where qty ≤ threshold.
2. Group or filter by branch.
3. One-click jump to Adjust.

### Flow D — Export
1. Manager/admin: Export CSV of current stock for selected branch (or all for admin).
2. Columns: sku, productName, branchName, quantity, updatedAt.

## Screens (v1 must-have)
1. Stock list (default landing)
2. Stock detail + embedded history
3. Adjust stock form
4. Low stock list
5. Settings stub (threshold) — optional if timeboxed; otherwise constant

UI tone: calm lists, large tap targets on mobile, status chips only where useful, no dense dashboards.

## Data model (entities)
StockBalance: id, productId, productName, sku, branchId, branchName, quantity (number), updatedAt, updatedByUserId
StockAdjustment: id, stockBalanceId, productId, branchId, delta, quantityBefore, quantityAfter, reason, note?, actorUserId, actorDisplayName, createdAt
Settings (optional): lowStockThreshold (int, default 5)

Indexes / queries: unique (productId, branchId); list by branch; search by name/sku; low-stock query.

## Edge cases
- Concurrent adjusts: last-write with optimistic quantityBefore check; show conflict message if stale.
- Missing product/branch: block save with clear error.
- Empty catalog: empty state CTA “No stock yet — adjust to create a balance row” (creating balance on first adjust is OK).
- Localization: all labels via locale keys; support en / zh / my patterns used in Quark App.

## Acceptance criteria
- [ ] Staff can adjust with required reason and see history.
- [ ] Branch manager cannot see other branches’ stock.
- [ ] Low stock list respects threshold.
- [ ] CSV export downloads for allowed scope.
- [ ] Qty never goes negative without explicit override.
- [ ] Pages wrapped in standard Page / PageTitle / PageContent patterns.
- [ ] No hardcoded user-facing English-only strings in JSX.

## Out of scope (do not build in v1)
Barcode hardware, purchase orders, inter-branch transfers, costing/FIFO/AVCO, supplier sync, batch/lot/serial, reservations, multi-UOM conversion UI.

Build a Quark App sales invoice plugin for a small B2B/B2C sales team.

## Business context
Sales people draft invoices with line items. A manager approves before the invoice is “official”. Finance marks paid and prints a simple PDF for the customer. Status must be obvious at a glance. No tax engine in v1.

## Goal
Ship draft → submit → approve/reject → mark paid → printable PDF, with clear permissions and an audit-friendly status history.

## Actors & permissions
1. Sales user: create/edit drafts; submit for approval; view own invoices (or all if policy simpler — prefer all readable, edit only draft they created).
2. Approver (manager): approve or reject pending invoices; comment required on reject.
3. Accountant / manager: mark approved invoices as paid; open PDF.

State machine (enforce server-side):
draft → pending → approved → paid
draft → pending → rejected → draft (after edit) OR stay rejected read-only
Only draft is editable. Pending locks fields. Paid is immutable.

## Primary flows
### Create & submit
1. New invoice → pick/enter customer name (partner picker if available, else free text + optional customerId).
2. Issue date (default today), due date (optional).
3. Add lines: description (required), qty (>0), unit price (≥0). Optional product link.
4. Subtotal = sum(qty * unitPrice). No tax, no discount fields in v1.
5. Save draft anytime. Submit → status pending; show banner “Waiting for approval”.

### Approve / reject
1. Approver opens pending queue.
2. Approve → status approved; record approver + time.
3. Reject → require comment (min 5 chars) → status rejected; sales can edit and resubmit (back to draft then pending).

### Mark paid & PDF
1. On approved invoice → Mark paid → paidAt = now; optional payment note.
2. Print/PDF view: company placeholder name, invoice number, customer, dates, line table, subtotal, status, paid date if any. Clean A4, printable CSS.

## Screens
1. Invoice list — filters: status, customer text, date range; status chips
2. Invoice form (create/edit)
3. Invoice detail (read) with actions by role
4. Approver queue (pending only) — can be a filter preset on list
5. Printable PDF route/view

## Data model
Invoice: id, number (human-readable, unique), customerId?, customerName, issueDate, dueDate?, status, subtotal, approverUserId?, approverComment?, approvedAt?, paidAt?, paymentNote?, createdByUserId, createdAt, updatedAt
InvoiceLine: id, invoiceId, sortOrder, description, quantity, unitPrice, lineTotal
InvoiceEvent (optional but preferred): id, invoiceId, fromStatus, toStatus, actorUserId, comment?, createdAt

Numbering: INV-YYYYMMDD-#### or sequential; never reuse.

## Validation & UX
- At least one line required to submit.
- Confirm dialog before submit / mark paid.
- Empty list states per filter.
- Mobile: stack line editor; large primary buttons.
- Localize all strings.

## Acceptance criteria
- [ ] Illegal transitions blocked with clear errors.
- [ ] Reject without comment impossible.
- [ ] PDF readable and printable.
- [ ] List filters work; status visible as chips.
- [ ] Quark App page layout + services + DTOs follow plugin standards.

## Out of scope
Tax engines, multi-currency, recurring invoices, credit notes, e-invoice networks, inventory deduction, payment gateway capture/chargebacks, multi-level approval chains.

Build a Quark App attendance plugin for shops and small offices.

## Business context
Employees punch in/out on phone or shared tablet. Managers need today’s who-is-here list and a monthly CSV for payroll prep. Late is computed simply: after 09:00 + 15 minutes grace (hardcoded v1, document as configurable later).

## Goal
Fast check-in/out, clear daily roster with late flags, month history, CSV export — list-first UI, not charts.

## Actors
1. Employee: punch in/out; see own today status and recent days.
2. Manager: today’s roster (filter branch); month list; export CSV.
3. Admin: same as manager all branches; see grace rule note in UI.

## Flows
### Punch
1. My Attendance shows big Check in if not in; Check out if in.
2. Disable double check-in same day; allow only one open session.
3. Show last punch time prominently.
4. If checkout forgotten yesterday: show banner “Yesterday still open — check out or ask manager” (manager can force close with note).

### Roster
1. Today’s roster rows: employee, branch, status (Not in / In / Out / Late), check-in, check-out.
2. Late = checked in after start+grace.
3. Pull-to-refresh / refresh button.

### Month & export
1. Pick month + optional employee.
2. Export CSV: employeeName, employeeId, date, checkInAt, checkOutAt, isLate, branch.

## Screens
1. My Attendance (employee home)
2. Today roster (manager)
3. Month records
4. Export action on month view

## Data model
AttendanceDay: id, employeeUserId, employeeName, branchId, date (calendar date), checkInAt?, checkOutAt?, isLate, forceClosedBy?, forceCloseNote?, createdAt, updatedAt
Rules constants: workdayStart="09:00", graceMinutes=15 (document in code comments)

## Edge cases
- Timezone: use server/org local consistently; store ISO timestamps; display local.
- Night shift: out of scope — assume same calendar date.
- Manager editing punches: out of scope except force-close open day.

## Acceptance criteria
- [ ] Employee can check in/out in under 2 taps.
- [ ] Late flag correct for grace rule.
- [ ] Manager CSV downloads.
- [ ] Localized labels; Quark App patterns.

## Out of scope
GPS geofencing, face recognition, shift templates, leave/time-off, overtime pay math, biometric devices.

Build a Quark App loyalty points plugin for retail counters.

## Business context
Cashiers look up customers by phone, earn points when a sale completes, and redeem points for bill discounts. Customer service needs a ledger. Rules should be easy to change later — v1 hardcodes earn/redeem rates but isolates them in one config module.

## Goal
Register customers, earn/redeem with a non-negative balance ledger, and keep every movement auditable.

## Actors
1. Cashier: lookup by phone; register; earn; redeem; see balance.
2. Customer service: read-only ledger + balance.
3. Admin: view config rates (read-only UI showing hardcoded values is OK).

## Rules (v1 constants in one file)
- Earn: 1 point per 1.00 currency unit of completed sale amount (floor to int).
- Redeem: 100 points = 1.00 currency unit discount.
- Balance never < 0.
- Redeem points must be multiples of 100 (or allow any and floor discount — pick multiples of 100 for clarity).

## Flows
### Lookup / register
1. Enter phone (normalize spaces); search.
2. If missing → Register: name + phone (unique). Soft validate phone length.

### Earn
1. From customer card → Earn.
2. Enter sale reference (text/id) + amount.
3. Compute points; confirm; write ledger earn; increase balance.

### Redeem
1. Enter points to burn; show discount preview.
2. Block if insufficient; confirm; ledger redeem; decrease balance; return discount amount for cashier to apply manually on POS (do not integrate POS in v1).

### Ledger
1. Reverse-chronological list: type, points delta, balance after, sale ref, actor, time.

## Screens
1. Customer lookup
2. Customer profile (balance + actions + recent ledger)
3. Register form
4. Earn form / Redeem form
5. Full ledger page with filters (type, date)

## Data model
LoyaltyCustomer: id, phone (unique), name, balance, createdAt, updatedAt
LoyaltyLedger: id, customerId, type ("earn"|"redeem"), pointsDelta (signed), balanceAfter, saleRef?, discountAmount?, actorUserId, note?, createdAt
LoyaltyConfig (code module): earnRate, redeemBlockSize, redeemValuePerBlock

## Edge cases
- Double-submit: idempotency key optional; at least disable button while saving.
- Race on balance: transactional update; reject if insufficient at commit.

## Acceptance criteria
- [ ] Unique phone enforced.
- [ ] Ledger explains every balance change.
- [ ] Redeem cannot overdraft.
- [ ] Config rates centralized for future admin UI.
- [ ] Localized Quark App UI.

## Out of scope
Tiers, expiry, SMS OTP, wallet apps, automatic POS injection, multi-brand point pools, referral bonuses.

Build a lightweight Quark App POS helper for a single counter.

## Business context
One cashier sells quickly: pick products, set qty, take cash or transfer, print a simple receipt. Owner glances at today’s tickets. Speed and large tap targets beat features.

## Goal
Sell → pay → receipt → today’s list, with zero multi-register complexity.

## Actors
1. Cashier: full sell flow.
2. Owner: today’s sales list + open receipt.

## Flows
### Sell
1. Home = Sell screen.
2. Product picker: search + recent/favorites grid (seed with sample products if catalog empty; prefer real products plugin if available).
3. Cart lines with +/− steppers and swipe/remove.
4. Running total always visible.
5. Clear cart with confirm.

### Pay
1. Pay sheet: Cash or Transfer.
2. Cash: amount tendered; show change; block if tendered < total.
3. Transfer: mark as paid transfer; optional reference note.
4. Complete → create ticket status completed → open receipt.

### Receipt & today
1. Receipt view: store name placeholder, ticket no, datetime, lines, total, method, tendered/change or transfer ref.
2. Print via browser print.
3. Today’s sales: reverse chrono list; tap to re-open receipt.

## Screens
1. Sell (cart)
2. Pay modal/sheet
3. Receipt
4. Today’s sales

## Data model
PosTicket: id, number, status ("completed"), total, paymentMethod ("cash"|"transfer"), amountTendered?, change?, transferRef?, createdByUserId, createdAt
PosTicketLine: id, ticketId, productId?, name, quantity, unitPrice, lineTotal

## UX constraints
- Thumb-zone primary buttons.
- Numeric keypad friendly.
- No table service, no seats, no modifiers beyond qty.
- Offline not required.

## Acceptance criteria
- [ ] Complete sale under ~15 seconds for 2-line cart (happy path).
- [ ] Change math correct.
- [ ] Receipt printable.
- [ ] Today list updates immediately after sale.
- [ ] Quark App patterns + locales.

## Out of scope
Multi-register, inventory auto-deduct (optional stub OK), barcode drivers, kitchen tickets, split bills, tips, customer display hardware.

Build a Quark App purchase order (PO) + goods receipt plugin.

## Business context
Buyers order from suppliers. Warehouse receives against PO lines, often partially. Managers track open vs closed POs. Stock posting to inventory can be a follow-up — v1 tracks qty received on the PO itself.

## Goal
Draft → ordered → partial/received, with partial receives, over-receive guard, and a receive timeline.

## Actors
1. Buyer: create/edit draft; mark ordered; cancel draft.
2. Warehouse: receive quantities against ordered/partial POs.
3. Manager: list/filter; read-only detail.

## State machine
draft → ordered → partial → received
draft → cancelled
ordered/partial cannot return to draft. Cancel only from draft.

## Flows
### Create PO
1. Choose supplier (partner or free text + id).
2. Expected date optional.
3. Lines: product, qtyOrdered > 0, unitCost ≥ 0.
4. Save draft; Mark ordered locks qtyOrdered edits.

### Receive
1. Open ordered/partial PO → Receive.
2. For each line enter qtyReceivedThisTime (≥0).
3. Cap at remaining unless “Allow over-receive” checked (permission: manager/admin).
4. Save receive event; update qtyReceived totals; if all lines complete → received else partial.
5. Timeline shows each receive batch: who, when, per-line qtys.

## Screens
1. PO list (supplier, status filters)
2. PO form
3. PO detail + timeline
4. Receive form

## Data model
PurchaseOrder: id, number, supplierId?, supplierName, status, expectedDate?, createdByUserId, orderedAt?, cancelledAt?, createdAt, updatedAt
PurchaseOrderLine: id, poId, productId?, productName, qtyOrdered, qtyReceived, unitCost
GoodsReceipt: id, poId, actorUserId, note?, createdAt
GoodsReceiptLine: id, receiptId, poLineId, qtyReceived

## Acceptance criteria
- [ ] Partial receive works across multiple sessions.
- [ ] Over-receive blocked by default.
- [ ] Status auto-updates to partial/received.
- [ ] Timeline accurate.
- [ ] Localized Quark App UI.

## Out of scope
Supplier portal, 3-way invoice match, landed cost, automatic inventory posting, approvals matrix, blanket POs.

Build a Quark App employee expense claims plugin.

## Business context
Employees submit out-of-pocket spend. Managers approve. Finance marks reimbursed. Keep a clear audit trail. Single currency. Receipt file upload is out of scope — URL text field only.

## Goal
Draft → submitted → approved/rejected → reimbursed, with mobile-friendly forms.

## Actors
1. Employee: create/edit draft; submit; withdraw submitted back to draft; view own claims.
2. Manager: queue of submitted team claims; approve/reject with comment on reject.
3. Finance: mark approved as reimbursed; set reimbursedAt + optional payment ref.

## State machine
draft → submitted → approved → reimbursed
submitted → rejected → draft (employee edits)
Employee can withdraw submitted → draft.
Only owner edits drafts.

## Flows
1. New claim: category (travel|meals|supplies|other), amount > 0, spendDate, note, optional receiptUrl.
2. Submit from detail.
3. Manager approve/reject.
4. Finance mark reimbursed.

## Screens
1. My claims list (status chips)
2. Claim form
3. Claim detail + status history
4. Manager queue
5. Finance reimbursed action on detail

## Data model
ExpenseClaim: id, employeeUserId, category, amount, currencyCode (fixed), spendDate, note?, receiptUrl?, status, managerUserId?, managerComment?, decidedAt?, reimbursedAt?, paymentRef?, createdAt, updatedAt
ExpenseClaimEvent: id, claimId, fromStatus, toStatus, actorUserId, comment?, createdAt

## Acceptance criteria
- [ ] Illegal transitions blocked.
- [ ] Reject requires comment.
- [ ] Employee cannot see others’ claims.
- [ ] Mobile form usable.
- [ ] Locales + Quark App patterns.

## Out of scope
OCR, multi-level approvals, policy engines, payroll export, card feeds, multi-currency FX.

Build a Quark App mini-CRM for sales leads.

## Business context
A small sales team captures inbound leads, assigns owners, moves stages, and logs notes. No email automation — just a trustworthy pipeline.

## Goal
Create → assign → stage changes → notes, with list/board views and lost reasons.

## Actors
1. Sales rep: CRUD own leads; notes; stage changes; sees own pipeline (and unassigned).
2. Sales lead: all leads; reassign owner.
3. Admin: same as sales lead; stages fixed in v1 but listed in settings read-only.

## Stages (fixed v1)
New → Contacted → Qualified → Won
Any stage → Lost (require lostReason)
Won/Lost are terminal unless sales lead reopens to Contacted (optional; if complex, keep terminal).

## Flows
1. Create lead: name required; phone or email required (at least one); company; source (walk-in|referral|facebook|other); owner default = creator.
2. Board or list filtered by stage/owner.
3. Detail: fields + notes timeline + stage control.
4. Add note (required non-empty).
5. Reassign owner (sales lead).

## Screens
1. Pipeline board (or list with stage groups)
2. Lead detail
3. Create/edit lead
4. My leads quick filter

## Data model
Lead: id, name, phone?, email?, company?, source, stage, ownerUserId, lostReason?, createdByUserId, createdAt, updatedAt
LeadNote: id, leadId, body, authorUserId, createdAt

## Acceptance criteria
- [ ] Cannot set Lost without reason.
- [ ] Notes newest-first.
- [ ] Owner filter works.
- [ ] Calm UI; localized; Quark App patterns.

## Out of scope
Email/WhatsApp sync, lead scoring AI, quotes, full accounts hierarchy, marketing campaigns.

Build a Quark App local delivery tracking plugin for shops with riders.

## Business context
Dispatchers create delivery jobs from order references, assign riders, and track status to delivered/failed. Customer service searches by phone or order ref. No live map in v1 — status timeline is enough.

## Goal
Job lifecycle with forced sequential statuses, fail reasons, and searchable history.

## Actors
1. Dispatcher: create jobs; assign/reassign rider; view all open jobs.
2. Rider: see assigned jobs; advance status; mark failed with reason.
3. Customer service: search; read timeline; no status edits.

## Status path (strict)
pending → assigned → picked_up → out_for_delivery → delivered
At assigned or later → failed (require failReason)
Do not skip statuses. UI only shows the next legal action(s).

## Flows
1. Create job: customerName, phone, address (textarea), orderRef, promisedWindow (text, e.g. “2–4pm”).
2. Assign rider from users flagged as riders (simple list / role tag; seed helper OK).
3. Rider updates via large status buttons.
4. Timeline event on every change: actor, from, to, time, comment.

## Screens
1. Jobs list (status, rider filters; open vs done tabs)
2. Create job
3. Job detail + timeline
4. Rider “My jobs” (assigned & active)

## Data model
DeliveryJob: id, orderRef, customerName, phone, address, promisedWindow?, riderUserId?, status, failReason?, createdByUserId, createdAt, updatedAt, completedAt?
DeliveryEvent: id, jobId, fromStatus?, toStatus, actorUserId, comment?, createdAt

## Acceptance criteria
- [ ] Illegal skips blocked.
- [ ] Failed requires reason.
- [ ] Search by phone or orderRef.
- [ ] Rider only sees own assignments (plus maybe unassigned if dispatcher shares — prefer own only).
- [ ] Localized Quark App UI.

## Out of scope
Live GPS, route optimization, SMS/push, POD photos, proof signature, COD settlement math.

Build a Quark App appointment booking plugin for a small clinic or salon (staff-operated, single location).

## Business context
Front desk books services with a staff member on a day calendar. Staff see their own schedule. Admin maintains services (name + duration) and which users are bookable staff. No public self-booking portal in v1.

## Goal
Prevent overlapping appointments per staff, support cancel/reschedule with audit note, and keep a clear day view.

## Actors
1. Front desk: book, cancel, reschedule; see all staff columns/list for a day.
2. Staff: read-only own day schedule.
3. Admin: CRUD services; mark users as bookable staff.

## Rules
- Working hours v1: 09:00–18:00 local; slot starts on 15-minute grid.
- Duration from service: 15 | 30 | 45 | 60 (admin can set any positive int multiple of 15 preferred).
- endAt = startAt + duration.
- No overlap for same staff (compare intervals).
- Buffer times: none beyond duration.
- Status: booked | cancelled | completed (optional complete button; or auto-complete after endAt — prefer manual complete + cancel).

## Flows
### Book
1. Pick date → day calendar.
2. Book: service → staff → start time (enabled slots only) → customer name + phone → optional note.
3. Validate overlap; save booked.

### Reschedule / cancel
1. From appointment: Reschedule (pick new start; same validations) or Cancel (require short reason).
2. Write audit note/event.

### Admin
1. Services list CRUD.
2. Staff list: toggle bookable + display name.

## Screens
1. Day calendar (staff columns or sections)
2. Booking form / drawer
3. Appointment detail
4. Services admin
5. Staff admin
6. My schedule (staff)

## Data model
Service: id, name, durationMinutes, active, createdAt
StaffProfile: id, userId, displayName, bookable, active
Appointment: id, serviceId, serviceNameSnapshot, staffUserId, customerName, phone, startAt, endAt, status, note?, cancelReason?, createdByUserId, createdAt, updatedAt
AppointmentEvent: id, appointmentId, type ("created"|"rescheduled"|"cancelled"|"completed"), actorUserId, message?, createdAt

## Edge cases
- Staff deactivated: block new books; existing remain visible.
- Service deactivated: hide from new books; snapshots keep old name on past appointments.
- Crossing closing time: reject start that would end after 18:00.

## Acceptance criteria
- [ ] Overlap impossible for same staff.
- [ ] Day view readable on tablet.
- [ ] Cancel/reschedule audited.
- [ ] Staff only see own schedule on My schedule.
- [ ] Localized Quark App pages/services.

## Out of scope
Online public booking, deposits/payments, SMS reminders, multi-location, resources/rooms, waitlist, recurring series.