Rusukh · Client handover

The Admin Panel and Customer Portal, in full

Every screen, every role, every rule — and a photograph of each one, taken from the running application rather than drawn for the document.

Generated: 2026-09-05
Evidence: 118 screenshots, captured automatically
Database: rusukh_demo
Roles documented: 14
Permissions: 288
Approval rules: 18

How this document was produced

This is not a written description of the software. Every screenshot below was taken by a script that signed in as a real seeded user, navigated to a real URL, and photographed whatever came back. The red outline in each image was drawn by that same script around the element the caption refers to, so the caption cannot drift away from the picture.

The whole document regenerates from three commands:

npx playwright test -c e2e/evidence/evidence.config.ts
DB_DATABASE=rusukh_demo php artisan handbook:export-reference
node e2e/evidence/build-handbook.mjs

What that buys you

No screenshot can be stale without the document noticing. The capture clears the previous run's images first, and this generator drops any figure whose file is not on disk, so a screen that has been removed cannot leave a convincing old photograph behind.
No screen can be photographed while broken. Each capture asserts the response was below HTTP 400 before the shutter. A 403 or a 500 fails the run rather than becoming a figure — with one deliberate exception, the refusal in §4, where the error is the evidence.
No rule is retyped. The role, permission and approval tables come from handbook:export-reference, which reads them out of the database. Change a threshold and regenerate, and this document changes with it.

Which database these pictures came from, and why it matters

Everything here was photographed against rusukh_demo, built from an empty database by the documented migrate:fresh --seed and verified before use. That choice is deliberate and worth explaining, because it is the difference between evidence and decoration.

The everyday development database looks identical on screen and is not honest: it was seeded before the stage-gate work landed, so it carries 286 gate rows with zero evidence rows behind them. The gate board renders green, and the first attempt to actually advance a garment is refused — because the evaluator recomputes each gate from its evidence every time it is asked and never trusts the stored flag. A handbook illustrated from that database would be showing you a board that does not mean what it appears to mean.

The number that separates the two: 151 stage gates standing on 569 evidence rows, all 151 of which re-evaluate as genuinely passing. That check is part of the release procedure in 04-TESTING-AND-VERIFICATION.md §7.

One difference between these pictures and a brand-new installation

The dashboards below show real computed figures — pipeline value, QC pass rate, delivery success. A freshly seeded installation will not. Every dashboard tile reads "awaiting data" under a banner saying the figures are not being computed yet, and that is correct rather than broken: the KPI engine writes a snapshot on a nightly schedule, at 01:00, and a database created this afternoon has not had one yet. The application deliberately shows an em dash rather than a zero, because a fabricated zero on a quality metric would read as an accusation.

These screenshots were taken after running that job by hand against the demo database, so the handbook shows what the panel looks like in use rather than on its first day. Two things follow for a real deployment. The scheduler entry must be installed — one * * * * * php artisan schedule:run line — and a queue worker must be running, because schedule:run only places these jobs on the maintenance queue. Without a worker the dashboards stay empty forever and nothing reports an error. See 03-PRODUCTION-DEPLOYMENT.md §4.

How much data is behind these screens

Table	Rows
`users`	16
`customers`	8
`orders`	114
`order_items`	142
`stage_gates`	151
`stage_gate_evidence`	569
`approval_requests`	12
`payments`	6
`shipments`	6
`delivery_attempts`	5
`alteration_jobs`	5
`commissions`	14
`journal_entries`	2

Signing in — addresses and credentials

Two separate front doors, two separate guards. Staff and customers do not share a login, a session, or a permission set, and no staff account can act as a customer — a point §3 returns to, because it surprises people.

Who	Address	Lands on
Staff	`/login`	`/admin/dashboard`
Customers	`/customer/login`	`/account`
Customer self-registration	`/customer/register`	`/account` after email verification
Password reset (customer)	`/customer/forgot-password`	emailed link

The seeded staff roster

These are the accounts a fresh migrate:fresh --seed creates, and the accounts every screenshot in this document was taken with. All thirteen share one password on a seeded installation.

Change every one of these before the system carries real work. They exist so a new installation can be explored and demonstrated immediately; they are published in this document and in the repository, so they are not secrets and must never be treated as any.

Role	Permissions	Seeded email	Seeded password
`super_admin`	272	`root@rusukh.pk`	`Rusukh#Staff2026`
`management`	270	`tariq.jamil@rusukh.pk`	`Rusukh#Staff2026`
`customer_service`	88	`nadia.iqbal@rusukh.pk`	`Rusukh#Staff2026`
`operations_coordinator`	48	`rehan.aziz@rusukh.pk`	`Rusukh#Staff2026`
`measurement_rep`	48	`imran.sheikh@rusukh.pk`	`Rusukh#Staff2026`
`finance`	106	`shahid.kamal@rusukh.pk`	`Rusukh#Staff2026`
`inventory_procurement`	46	`zubair.lakhani@rusukh.pk`	`Rusukh#Staff2026`
`production_manager`	58	`arif.sattar@rusukh.pk`	`Rusukh#Staff2026`
`cutter`	17	`yousuf.dawood@rusukh.pk`	`Rusukh#Staff2026`
`tailor`	18	`salim.khatri@rusukh.pk`	`Rusukh#Staff2026`
`qc_officer`	31	`naveed.anwar@rusukh.pk`	`Rusukh#Staff2026`
`finishing_packing`	18	`junaid.habib@rusukh.pk`	`Rusukh#Staff2026`
`rider`	22	`kashif.ali@rusukh.pk`	`Rusukh#Staff2026`
`customer`	16	`—`	—

The seeded customers

All customer logins share the password Rusukh#Client2026.

ahmed.raza@gmail.com
bilal.siddiqui@gmail.com
faisal.malik@gmail.com

Two-factor authentication

Seeded accounts are not enrolled. finance and super_admin are the two roles the middleware treats as requiring it, so signing in as either lands on the enrolment screen at /admin/identity/security/two-factor rather than the dashboard. That is the guard working, not a failed login — the session is valid either way, and navigating to the dashboard works normally.

The role model — who may do what

Rusukh has 14 roles and 288 named permissions. A role is a bundle of permissions; a user holds a role. Nothing in the application asks "is this person an admin" — every gate asks for a specific named permission, which is why the sidebar a role sees and the routes it may open are the same list.

Permissions by family

Each permission is named <area>.<thing>.<verb>. The families:

Family	Permissions
`production.*`	39
`crm.*`	32
`orders.*`	26
`finance.*`	21
`identity.*`	21
`inventory.*`	19
`audit.*`	18
`account.*`	16
`shipping.*`	15
`catalog.*`	14
`commission.*`	12
`payments.*`	12
`measurements.*`	9
`approvals.*`	8
`analytics.*`	7
`core.*`	6
`system.*`	6
`notifications.*`	4
`gates.*`	2
`team.*`	1

The one thing a super administrator cannot do

super_admin holds 272 of the 288 permissions. The 16 it does not hold are the account.* family — the customer portal's own permissions.

A super administrator cannot act as a customer. They cannot approve a specification on a patron's behalf, submit measurements as them, or pay their invoice from inside their account. Those acts have to come from the customer, which is what makes a customer approval worth anything when a dispute turns up later.

Roles that exist to be narrow

3 staff roles hold fewer than twenty permissions each, and that is the design rather than an incomplete setup: a cutter has 17; a tailor has 18; a finishing_packing has 18. Each can do their station and see what they need to do it, and nothing else. The evidence for that claim is in the next section — including one screenshot of the refusal itself, because a hidden link and a blocked route are very different things and only one of them is security.

What each role actually sees

The navigation is generated from the signed-in user's own permissions, so a photograph of it is a photograph of that role's reach. Thirteen roles, thirteen sidebars, all taken in the same session against the same database.

The last figure in this section is the important one. Everything above it shows what a role is offered; that one shows what happens when somebody ignores the offer and types the URL.

Figure 1 **super_admin — the whole panel as this role sees it**

Figure 2 **management — the whole panel as this role sees it**

Figure 3 **customer_service — the whole panel as this role sees it**

Figure 4 **operations_coordinator — the whole panel as this role sees it**

Figure 5 **measurement_rep — the whole panel as this role sees it**

Figure 6 **rider — the whole panel as this role sees it**

Figure 7 **finance — the whole panel as this role sees it**

Figure 8 **inventory_procurement — the whole panel as this role sees it**

Figure 9 **production_manager — the whole panel as this role sees it**

Figure 10 **cutter — the whole panel as this role sees it**

Figure 11 **tailor — the whole panel as this role sees it**

Figure 12 **qc_officer — the whole panel as this role sees it**

Figure 13 **finishing_packing — the whole panel as this role sees it**

Figure 14 **A cutter opening the general ledger directly — HTTP 403**

The approval rules

Rusukh has two kinds of approval and they are not variations on each other. Customer approvals are the patron agreeing to something about their own order. Internal approvals are a second member of staff signing for a decision the first one is not permitted to take alone. Both are enforced in the application, not in a policy document: the act is refused until the approval exists.

Customer approvals — the seven sign-offs

These are the points at which the patron, and only the patron, decides. Each one blocks the work that comes after it; C1–C3 in particular hold the cutting desk, because cut cloth cannot be uncut.

Code	What is being approved	Requested by	Threshold	SLA
`C1_FABRIC_COLOUR`	Fabric & Colour Approval The customer must approve the fabric and colour before it is cut.	`measurement_rep`	always	24 h
`C2_STYLE_QUANTITY`	Style & Number of Suits The customer must confirm the style and how many suits are being ordered.	`measurement_rep`	always	24 h
`C3_MEASUREMENTS_FIT`	Measurements or Reference Fit The customer must sign off the measurements, or the reference garment fit, before cutting.	`measurement_rep`	always	24 h
`C4_PRICE_CHARGES`	Price & Charges The customer must approve the quoted price and any listed charges before the order is confirmed.	`customer_service`	always	12 h
`C5_DELIVERY_DATE`	Delivery Date The customer must agree the promised delivery date.	`customer_service`	always	12 h
`C6_DESIGN_CHANGE`	Design Changes Control rule U2: any unapproved design change invalidates the prior approval and must be re-confirmed.	`measurement_rep`	always	24 h
`C7_ADDITIONAL_COST`	Additional Cost No extra cost may be added to an order without customer approval.	`customer_service`	always	12 h

Two different things are both numbered G1–G13, and it is worth separating them once.

The thirteen stage gates are the order's own checkpoints — G7 is "cutting complete", G9 is "QC approved" — and they are what the gate register in §7 lists. The approval codes below are a separate scheme from SOP §78: G3_FABRIC_CUTTING is the authorisation to start cutting, not the stage gate that records it as finished.

Where this document says a customer approval "holds G3", it means the approval code — the customer has not yet signed the specification, so cutting cannot be released.

Internal approvals — SOP §78

Each of these names an approver role, a money threshold where one applies, and a service level. Below the threshold the act proceeds untouched — a control that fires on ordinary work is one people learn to route around, so a Rs 500 purchase order does not wait for anybody.

Code	What it governs	Approver	Threshold	SLA
`G1_QUOTATION_DISCOUNT`	Large Discount Authorisation A discount beyond the standard band requires management sign-off before it is applied.	`management`	Rs 5,000	4 h
`G13_PERIOD_LOCK_OVERRIDE`	Financial Period Lock Override Reopening or adjusting a closed accounting period is a Super Root exception, logged with full audit.	`super_admin`	always	24 h
`G2_FABRIC_PURCHASE`	Fabric Purchase Authorisation A fabric purchase order beyond the standard value requires management authorisation.	`management`	Rs 20,000	8 h
`G3_FABRIC_CUTTING`	Fabric Cutting Release Control rule U2: cutting may not proceed while a customer approval or specification question is open.	`production_manager`	always	2 h
`G4_URGENT_ORDER`	Urgent-Order Acceptance Accepting an order outside the normal production calendar requires management approval before it is confirmed.	`management`	always	1 h
`G5_FABRIC_QC_DEVIATION`	Fabric QC Deviation Clearance A minor fabric defect found at inspection may be cleared for use rather than rejected, on production sign-off.	`production_manager`	always	2 h
`G6_REFUND_APPROVAL`	Refund Approval A refund beyond the standard threshold requires finance sign-off before it is processed.	`finance`	Rs 3,000	8 h
`G7_FREE_ALTERATION_EXCEPTION`	Free Alteration Outside Policy An alteration offered free of charge outside the standard policy (not a Rusukh-error correction) requires sign-off.	`production_manager`	always	4 h
`G8_DISPATCH_WITH_BALANCE`	Dispatch With Outstanding Payment Control rule: dispatching before the balance is fully collected is an exception, not a default, and needs finance sign-off.	`finance`	always	1 h
`G9_ORDER_CLOSURE_EXCEPTION`	Order Closure Exception Closing an order with an unresolved payment or alteration requires management approval.	`management`	always	8 h
`remake`	Remake Authorisation SOP §43/§60: root cause first, then a management approval before a fresh garment is cut. Matches the required_role Production's RequestRemakeAction already stamps directly.	`management`	always	48 h

What each one is actually protecting

G1 — discount. Stops a quotation being discounted into a loss by whoever wants the sale.
G2 — fabric purchase. The person placing a supplier order cannot also be the person who approves the spend.
G3 — cutting release. A cutting job cannot open against a specification the customer has not agreed to. This is the irreversible one.
G4 — urgent order. Accepting a rush job reshuffles everybody else's promised dates, so somebody owns that decision.
G5 — fabric QC deviation. A tolerance call on incoming cloth is recorded against a name instead of waved through.
G6 — refund. Money leaving the business above the threshold needs finance.
G7 — free alteration. A giveaway and a genuine Rusukh-error correction look identical in the ledger unless somebody signs for the difference.
G8 — dispatch with balance. Sending goods before payment is a credit decision, not a dispatch decision.
G9 — order closure. Closing an order writes it off in every report afterwards. It must not close while money is owed or work is outstanding.
G13 — period-lock override. Reopening closed accounts is the only approval reserved to the super administrator, with the longest SLA in the set.

Where you will see these. Every raised request lands in the Approval Centre at /admin/approvals/desk, photographed in §7. Every decision on one is written to the audit trail at /admin/audit/activity, photographed at the end of that same section — a signature nobody can look up later is not a control.

Booking an order, step by step

This is a real order, created during the capture run, through the same four-step wizard an operator uses. Nothing here is a mock-up; the order number in the final figure was issued by the application while these pictures were being taken.

The fourth figure is the refusal, and it is deliberately included. A handbook that only shows the clean path teaches nothing about the day the form says no.

Figure 15 **Step 1 — choose the customer**

Figure 16 **Step 2 — what is being sold**

Figure 18 **Validation — the wizard refuses an empty order**

Figure 19 **Step 4 — review before issuing**

Figure 20 **The order exists — evidence, not a mock-up**

An order's life, station by station

From the board an order lands on to the ledger entry it eventually becomes. Each station below is photographed in its real seeded state — work genuinely sitting in it — rather than driven forward by the capture script.

Why these are not one continuous click-through. Advancing a single garment through all thirteen stage gates from a browser is a working day of clicking, and a capture run that mutated its way through production could not be re-run. What is shown instead is each station as it looks with real work in it, on a database whose gates were verified to re-evaluate as passing rather than merely stored as green. The click-through proof that each transition works is the automated suite — 2744 backend tests and 262 browser tests, summarised in §11.

Figure 21 **Stage 1 — the orders board**

Figure 22 **Stage 2 — the thirteen stage gates**

Figure 23 **Stage 3 — the approval centre**

Figure 24 **Stage 4 — buying the cloth**

Figure 25 **Stage 5 — the 6-point fabric quality check**

Figure 26 **Stage 6 — the cutting desk**

Figure 27 **Stage 7 — the tailoring station**

Figure 28 **Stage 8 — dual quality control**

Figure 29 **Stage 9 — alterations and remakes**

Figure 31 **Stage 11 — packing and manifest verification**

Figure 32 **Stage 12 — the shipments board**

Figure 33 **Stage 13 — Karachi rider manifests**

Figure 34 **Stage 14 — proof of delivery**

Figure 35 **Stage 15 — COD cash custody**

Figure 36 **Stage 16 — the payment desk**

Figure 37 **Stage 17 — the general ledger**

Figure 38 **Stage 18 — daily closings and period locks**

Figure 39 **Stage 19 — the commission ledger**

Figure 40 **Stage 20 — the audit trail**

The screen atlas — all 61 admin screens

Every screen in the panel, grouped as the sidebar groups them, each opened as a role confirmed able to reach it. Where a screen is shown under a modest role — the cutting desk as a QC officer, the catalogue as a production manager — that is itself the evidence: the least privileged person who needs that screen can genuinely open it.

Analytics & Insights · 4 screens

Figure 41 **Analytics & Insights → Executive Dashboard**

Figure 42 **Analytics & Insights → Financial Dashboard**

Figure 43 **Analytics & Insights → Agent Leaderboard**

Figure 44 **Analytics & Insights → Production Board**

Governance & Approvals · 1 screen

Figure 45 **Governance & Approvals → Approval Center**

Settings · 9 screens

Figure 50 **Settings → Business settings**

Figure 51 **Settings → Roles & permissions**

Figure 54 **Settings → Measurement templates**

Catalog · 4 screens

Commission Ledger · 3 screens

Figure 59 **Commission Ledger → Commissions Desk**

Figure 60 **Commission Ledger → Wallets & Payouts**

Figure 61 **Commission Ledger → My Commission**

Sales · 5 screens

Figure 64 Sales → Measurements

/admin/measurements/profiles — opened as measurement_rep (imran.sheikh@rusukh.pk). The outlined entry is where this screen lives in the sidebar.

signed in as measurement_rep /admin/measurements/profiles Outlined in the image: Sales → Measurements

Figure 65 **Sales → Reference garments**

Customers · 3 screens

Overview · 3 screens

Finance & Accounting · 3 screens

Figure 73 **Finance & Accounting → Daily Closings**

Figure 74 **Finance & Accounting → General Ledger**

Figure 75 **Finance & Accounting → P&L & Financial Reports**

Inventory · 6 screens

Figure 76 **Inventory → Customer Fabric Custody**

Figure 77 **Inventory → 6-Point Fabric Quality Check**

Figure 78 **Inventory → Goods Receipt (GRN)**

Figure 79 **Inventory → Purchase Orders**

Figure 80 **Inventory → Stock Lots & Warehouse**

Figure 81 **Inventory → Suppliers & Mills**

Communication Logs · 4 screens

Figure 82 **Communication Logs → Notification Logs**

Figure 83 **Communication Logs → Customer Preferences**

Figure 84 **Communication Logs → Mail Preview**

Figure 85 **Communication Logs → Email Templates**

Orders · 4 screens

Payments & Cashier · 1 screen

Figure 90 **Payments & Cashier → Payment Desk**

Workshop / Production · 7 screens

Figure 91 **Workshop / Production → Alterations & Remakes**

Figure 92 **Workshop / Production → Cutting Desk**

Figure 93 **Workshop / Production → Production Files**

Figure 94 **Workshop / Production → Finishing**

Figure 95 **Workshop / Production → Packing**

Figure 96 **Workshop / Production → Quality Control**

Figure 97 **Workshop / Production → Tailoring Station**

Logistics & Shipping · 4 screens

Figure 98 **Logistics & Shipping → COD Cash Custody**

Figure 99 **Logistics & Shipping → Karachi Rider Manifests**

Figure 100 **Logistics & Shipping → Proof of Delivery (POD)**

Figure 101 **Logistics & Shipping → Shipments Board**

The customer's own account

The portal is a separate application behind a separate guard, and every query in it is scoped to the signed-in patron. A customer cannot see another customer's order, cannot select one in a dropdown, and cannot reach one by editing a URL.

The payment sequence at the end is real. A payment was genuinely taken during the capture run against a seeded balance, and the receipt in the figure is the one that transaction produced.

Figure 104 **Approvals the customer owes**

Figure 112 Profile and addresses

Identity and delivery addresses. CNIC and bank fields are encrypted at rest through Laravel's encrypted cast, keyed by APP_KEY. Signed in as ahmed.raza@gmail.com at /account/profile.

signed in as customer /account/profile Outlined in the image: Profile and addresses

Figure 113 **Paying — choosing the order**

Figure 114 **Paid — the receipt this run produced**

Figure 115 **Validation — nothing outstanding to pay**

The same screens on a phone and a tablet

Three widths are supported and all three are tested: 375, 768 and 1440. The figures below are the same screen at each, and each was checked programmatically for horizontal overflow at the moment it was photographed — the check the whole responsive requirement comes down to in practice.

This is a sample rather than the whole proof. Every screen tagged responsive in the browser suite runs at all three widths on every run; that is 261 browser tests, not three pictures.

Figure 116 **Mobile — 375px — the orders board**

Figure 117 **Tablet — 768px — the orders board**

Figure 118 **Desktop — 1440px — the orders board**

The verification record

What has actually been run against the code these screenshots came from, on 2026-09-05 against PHP 8.2.28. The full procedure, including how to re-run each suite and how to tell a real failure from a saturated dev server, is in 04-TESTING-AND-VERIFICATION.md.

Suite	What it proves	Result
Pest — unit & feature	Every screen against every role, the money chain, the state machines	2716 passed, 0 failed 13,372 assertions
Pest — concurrency	Twelve documented races, with real OS processes at a wall-clock barrier	28 passed, 0 failed
Architecture	Module boundaries, no float money, no raw status queries, no hand-built Actions	267 passed, 0 failed
Playwright	A real browser at 375, 768 and 1440	262 passed, 0 failed
Clean install	`migrate:fresh --seed` from an empty database	no error
Seeded gate integrity	151 gates re-evaluated from 569 evidence rows	151 of 151 passing

Nothing was skipped, deleted or weakened to reach those numbers. A suite that goes green by removing a test proves less than the red one it replaced — and this project has been bitten more than once by a test that passed while covering nothing at all.

How this document was produced

What that buys you

Which database these pictures came from, and why it matters

One difference between these pictures and a brand-new installation

How much data is behind these screens

Signing in — addresses and credentials

The seeded staff roster

The seeded customers

Two-factor authentication

The role model — who may do what

Permissions by family

The one thing a super administrator cannot do

Roles that exist to be narrow

What each role actually sees

The approval rules

Customer approvals — the seven sign-offs

Internal approvals — SOP §78

What each one is actually protecting

Booking an order, step by step

An order's life, station by station

The screen atlas — all 61 admin screens

Analytics & Insights · 4 screens

Governance & Approvals · 1 screen

Settings · 9 screens

Catalog · 4 screens

Commission Ledger · 3 screens

Sales · 5 screens

Customers · 3 screens

Overview · 3 screens

Finance & Accounting · 3 screens

Inventory · 6 screens

Communication Logs · 4 screens

Orders · 4 screens

Payments & Cashier · 1 screen

Workshop / Production · 7 screens

Logistics & Shipping · 4 screens

The customer's own account

The same screens on a phone and a tablet

The verification record

The rest of the handover