Chimti New Chat Handoff - 28 May 2026

Use this file as the first context document in a new Codex chat before continuing Chimti work.

Sensitive passwords, server passwords, SSH passwords, and private tokens are intentionally not repeated here. They were shared earlier in the working thread or are available locally in environment/config where already set. Do not paste them into a public channel unnecessarily.

Current Goal

Chimti is being built as a SaaS operating system for laundry/dry-cleaning/garment-care businesses. It should support single stores, central workshops, store-plus-workshop setups, hub-and-spoke models, franchise networks, and service-based routing.

The positioning direction is:

Chimti should be sold as an operations command center for modern laundry brands, not as a simple billing/order app. Its strongest edge is garment-level tracking, operational workflows, pickup/delivery/process visibility, service/pricing configuration, brand/location structure, and multi-app ecosystem.

Repositories

Main folders under `/Users/jagjeetsinghsethi/Downloads/Code/Chimti`:

| Repo | Purpose |

| --- | --- |

| `chimti-api` | Shared backend/API that all apps should eventually use. This was created because long-term structure needs one central API instead of each app owning backend logic separately. |

| `chimti-admin-app` | Chimti internal SaaS/admin app. Used by Chimti team to manage clients, brands, modules, plans, ads, users, permissions, demos, support, etc. |

| `chimti-user-app` | Brand/team web app used by laundry business staff. Handles customers, orders, items, tags, services, shipments, team, locations, payments, reports, etc. |

| `chimti-user-mobile-app` | Mobile app for brand staff/field teams. Should mirror useful user-app workflows and include field-only modules for pickup/delivery/scanning/photo capture. |

| `chimti-customer-app` | Customer-facing app/portal. Customer logs in with phone number and can see previous orders, order status, summaries, etc. |

| `chimti-website` | Public marketing website for Chimti. Currently local server on `http://127.0.0.1:5173`. |

| `chimti-print-agent` | Local desktop print agent for USB TSC label printer. Needed because browser/deployed app cannot directly print to local USB printer. |

Local Ports Observed

| App | Local URL seen in thread |

| --- | --- |

| Website | `http://localhost:5173` |

| Admin app | `http://localhost:5184` |

| User app | `http://localhost:5185` |

Database error previously showed local Postgres at `127.0.0.1:55432`. Confirm current env files before assuming.

Deployment Plan

Deployment target is Coolify on Otlu server.

Desired subdomains:

| Service | Domain |

| --- | --- |

| API | `chimti-api.otlu.io` |

| User app | `chimti-user-app.otlu.io` |

| Admin app | `chimti-admin-app.otlu.io` |

| Website | `chimti-website.otlu.io` |

Database already exists in Coolify. It is a Postgres setup under Otlu database/service, and Chimti should use its own database/schema inside that setup. Do not create random extra DB services unless there is a strong reason.

Earlier server work:

• Consolidated project databases into shared Postgres service.
• Removed unneeded development database services where asked.
• Removed MySQL/MariaDB from production environment.
• Restored pgAdmin server entry after it disappeared.
• Checked server disk usage.
• Pruned unused Docker images when asked.
• Removed extra `social_shosha` and default `postgres` databases after confirming project data was moved into the consolidated DB.

Core Data Hierarchy

Final intended hierarchy:

Client / Parent Group

  -> Brand(s)

       -> Brand-level plan, billing, modules, services, pricing policy

       -> Location(s)

            -> Store / Workshop / Hub / Collection Centre / Service Site

            -> Optional location-specific services/pricing/TAT

       -> Users

            -> Role + team + permissions + app access

       -> Customers

       -> Orders

            -> Items

                 -> Article IDs / tags / photos / item activity

            -> Pickup activity

            -> Delivery activity

            -> Processing activity

            -> Payment activity

       -> Shipments

            -> Articles moved between locations

Important decisions:

• Client is the parent group/company container.
• One client can have one or many brands.
• Billing, plans, features, modules, services, pricing, and TAT should be at brand level.
• A brand can choose universal services/pricing or store/location-wise services/pricing.
• Locations are brand-level by default, not client-level.
• If multiple brands share one hub/factory, that sharing must be explicitly configured. It should not happen automatically for every client.
• Users should be created under brand/workspace, not just client, because users can become billable at brand/plan level.
• A future user can have access to multiple brands under one client without needing separate logins.
• Customers and orders belong to brand context.
• Shipments move articles between brand locations and reconcile via scan/send/receive.

Client Operating Models

Current supported models:

1. Store Only

2. Single Workshop

3. Store + Workshop

4. Hub and Spoke

5. Franchise Network

6. Service Based

Models explicitly removed from current list:

• Multiple Workshops
• Pickup/Delivery Only With Workshop
• Service Based Hybrid
• Marketplace / Franchise Network wording

Notes:

• Hub and Spoke and Franchise Network were later added back as useful market models.
• Service Based means routing differs by service: laundry may go to workshop, steam iron may happen at store, sofa/carpet may happen at customer site, premium dry clean may follow another process.

Real / Demo Clients

Client types across system:

• Demo
• Live / Actual / Real, final UI word should be chosen cleanly. "Live" is probably better for SaaS operations than "Actual".

Important real client setup:

Otlu

Originally "Call Your Dhobi" client was renamed to `Otlu`.

Client details captured:

• Company/legal group: Otlu Ventures Private Limited
• Contact: Jagjeet Singh
• Contact number/email were provided in the thread; avoid repeating sensitive contact details in broad summaries unless needed.
• Role/title: Founder
• Registered address: `160, Gopal Park, Chander Nagar, Krishna Nagar, Delhi - 110051`
• Workshop address: `8/3, Khureji Khas, Krishna Nagar, Delhi - 110051`
• Operating model: Single Workshop / one workshop location where all operations are managed.

Brands under Otlu:

1. Call Your Dhobi

2. Cleanium

3. Dhobi Genie

4. Intel Dhobi

5. Laundrify

6. Dhobify

For all 6 brands:

• Legal name: CYD Cleaning Solutions Private Limited
• GST number: `07AAKCC2415L1ZM`

Demo Clients by Model

Existing product knowledge file already stores demo clients and demo user app superadmins.

Demo mapping:

| Model | Demo Client | Demo Brand |

| --- | --- | --- |

| Store Only | NeatNest Care Group | NeatNest Laundry |

| Single Workshop | AquaFold Works | AquaFold Laundry |

| Store + Workshop | WhiteWave Care Group | WhiteWave Laundry |

| Hub and Spoke | SpinRoute Services | SpinRoute Cleaners |

| Franchise Network | Freshora Care Network | Freshora Laundry |

| Service Based | FabricMint Services | FabricMint Care |

Freshora is the franchise network demo client.

`Chimti Demo Group` was removed after demo clients were created.

User Accounts

Core desired accounts:

• Admin app: `superadmin@chimti.io`
• Admin app: `jagjeet@chimti.io`
• User app seed account: `jagjeet@callyourdhobi.com`

There was a rule request that no other users should exist in the ecosystem, but later demo client superadmin users were created for demo/training. Treat demo users as intentional demo exceptions.

Do not repeat passwords in new chat unless user explicitly provides them again.

Admin App Direction

Admin app is for Chimti internal SaaS/company management.

Useful admin modules currently intended:

• Dashboard
• Clients
• Modules
• Subscriptions
• Plans
• Demo Data
• Ads
• Chimti Genie
• Internal Chat
• Leads
• Support
• Reports
• Users
• Permissions
• My Profile

Modules removed or moved out:

• Brand Onboarding module removed; onboarding moved inside Clients.
• Data Control removed.
• Campaigns & Loyalty removed.
• Scope Ops removed.
• Brand Settings removed.
• Audit Logs module removed as standalone; audit/logs now live under users/client users where relevant.
• Admin app menu customization removed.

Admin Users:

• Admin app Users module shows only Chimti admin users.
• User app / brand users are managed inside Client -> Brand/User tabs.
• Admin user detail page should handle role assignment and logs.

Permissions:

• Need two layers:

- Platform/admin roles for Chimti team.

- Client/brand/user-app roles for laundry brands.

• Permissions page should have proper list + detail page.
• Role settings should happen on detail page, not cluttered on list.
• New client-side user types should be created from admin app Permissions -> Client Role Templates -> Add User Type, not hardcoded.

Clients:

• Client list should show only meaningful clients: Otlu plus demo clients.
• New Client button label should be more relevant than "New Client Onboarding", such as "Add Client" or "Create Client".
• New client modal should open like user app New Customer/New Order modal, not as page content.
• New client creation takes minimum details first: client name, official number, official email.
• POC, business details, commercial details, setup details come later on detail page.
• Client detail tabs intended order: Overview, Brands, Users, Activity.
• Some extra tabs may exist, but latest preference was to keep important tabs clear and not overloaded.
• Detail pages should have breadcrumb like `Clients > Client Details`, clickable.
• Back button should be icon-only, borderless, placed cleanly.
• "Client Master Record" text removed.
• Top quick buttons like "Next: Record Payment" and extra "Brands" button removed.
• Summary counters should show inside Overview, not as separate header clutter.

Brands in Admin:

• Brands section moved inside Clients.
• Clicking a brand in Client -> Brands opens Brand Details.
• Brand detail page should follow same pattern as client detail page with tabs.
• Brand detail should manage billing/plans/features/modules/services/locations/users where relevant.
• Brand detail Overview has toggle/switch for Services pricing scope:

- Universal / Brand-level services.

- Store-wise / Location-wise services.

• This should be a proper switch and should show warning before changing because switching can affect pricing/TAT setup.
• If universal, Services tab appears on Brand Details.
• If store/location-wise, Services section appears on Location Details.

Locations:

• Client "Stores" terminology changed to "Locations".
• Locations can be Store, Workshop/Hub/Processing Unit, Collection Centre, Service Site, etc.
• Location details should have tabs such as Overview, Services, Team, Orders/Activity, Shipments, Settings.
• Location should define what happens there: intake, tagging, processing, packing, pickup handover, delivery handover, service-site work, etc.

Modules:

• "Module Launch" renamed to "Modules".
• This page is only for global user-app module launch status, not users/permissions clutter.
• It should look like All Orders/All Customers style list.
• It should be alphabetical.
• It should have a detail page.
• Launch status and global visibility are effectively one concept:

- Launched means available globally for brand-level setup.

- Planned means not available/hidden everywhere.

• Only launched modules should appear in Brand module enable/disable settings.
• After brand-level enable, user role permissions decide which user sees what.
• Module detail controls tag/badge shown in user app, e.g. New, Beta, Planned, etc.
• Planned modules currently include:

- AI POS Assistant

- Calls

- Chimti Genie

- Customer Experience

- Delivery Tracking

- Email

- Internal Chat

- Inventory

- Processing Queue

- Support

- WhatsApp

- WhatsApp AI

• Dashboard/Customers/Orders/Team/Brands/Locations/Shipments/Services/Payments/Reports are more core/current.

Ads:

• Admin app has Ads module.
• Admin app has global ads enable/disable switch.
• User app must respect this switch immediately/persistently.
• Sponsored section should rotate 4-5 ads.
• Sometimes sponsored section should not show.
• Remove "View All Sponsors" button.
• Track impressions and clicks in admin Ads.

User App Direction

User app is the brand/team web app used by laundry operations teams.

Main UI decisions:

• Sky-blue / Chimti blue aesthetic.
• Latest Chimti logo and color palette applied.
• Top-left logo should be smaller, original artwork preserved, "by OTLU" on right.
• Avoid orange legacy palette.
• Hide scrollbars globally and in left menu.
• Left menu categories removed; modules shown directly.
• User app menu customization exists, but save-only:

- Drag-and-drop with 6-dot handle.

- No arrow move buttons.

- Hide action should use icon, not text.

- No bulky outlines around handle/module.

- Changes should not persist until Save is clicked.

• Admin app menu customization removed.
• "Live Sync" button should look premium and clearer.
• Every list page should show 10 rows per page with pagination.
• Details pages should not show list-page counters.
• Every popup should be centered vertically/horizontally, content-sized, close on Esc.
• If popup has unsaved data, show one dirty warning with save/exit choice.
• Avoid duplicate warning.
• Buttons should use icons when obvious.
• Smooth premium/iPhone-like interaction feel added: slight transitions, not heavy delays.

User app modules:

• Dashboard
• Customers
• Orders
• Team (renamed from Employees)
• Brands
• Locations
• Shipments
• Services
• Payments
• Reports
• Other launched modules depending Admin Modules config

Brands:

• Brand page exists in user app because one client can have multiple brands.
• Brand page needed UI cleanup.

Locations:

• Added as user app module.
• Shows locations list, replacing store-only mental model.

Customer Module

Customer create form:

• Split into Quick Add + Detailed Add.
• Quick Add should capture minimum required data for fast counter intake.
• Detailed Add has optional reporting/acquisition/commercial fields.
• Middle Name positioned between First Name and Last Name.
• Customer Type removed Corporate. Use Individual/Business.
• Business mode:

- Contact Person renamed POC.

- Company mobile number and POC number separate.

- Company WhatsApp number separate.

- Detailed Add business asks GST only, no PAN.

• Mobile and WhatsApp:

- Country code dropdown with all countries/tourists support.

- Dropdown searchable.

- WhatsApp same-as-mobile small/aesthetic button.

- Mobile validations: India numbers max 10 digits etc.

• Address:

- Pincode validation.

- Pincode should auto-fill City, State, Country and these should not be editable.

- Address Type dropdown differs by Individual/Business, plus Custom option for both.

Acquisition data:

• Do not make acquisition fields mandatory during quick create.
• Detailed Add should contain optional data for reporting.
• Customer list should show pending acquisition/details.
• Reminders should ask team to fill missing acquisition/profile details later.
• Final simplified channel model:

- First select Online or Offline.

- Offline only means Store Walk-in.

- If Offline/Store Walk-in, select Store/Location.

- Online subchannels: Phone Call, WhatsApp, Email, Instagram, Website.

• Subchannel filter should exist.
• Creation mode datapoint:

- Manual if created from app by team, even if source is Online/WhatsApp.

- Automatic only when website/WhatsApp/automation creates customer directly.

- Do not ask user to enter this manually.

- Show in customer detail.

Customer list:

• Title: All Customers.
• Search should be one-line, long search input, Filters button, Add Customer button.
• Filters open popup with Clear Filters and Apply Filters.
• Removed Segment and Added By Team filters.
• Search helper text should be proper English.
• 10 customers per page, then pagination.

Customer detail:

• Header should show only Back to Customers button and customer name.
• Customer details tabs context pill should show only customer name, not ID.
• Tabs should switch sections, not scroll to anchors.
• Snapshot renamed Overview everywhere.
• Activity replaces Audit in user app.
• Audit should not show in user app.
• Overview should show:

- Customer Name

- Customer ID

- Health

- Mobile with call icon button beside number

- WhatsApp with WhatsApp icon button beside number

- Email with email icon/function

- Acquisition Channel

- Customer Type

- Created

- Updated

- Address

- Business Name and GST only for Business customers

• Remove:

- Preferred Contact

- Preferred Time

- First Visit Reason

- Service Preference

- Added By Team

- Channel Detail

- Tax/PAN

• Notes tab:

- Renamed from Internal Notes to Notes.

- Append-only text entries.

- Cannot edit/delete notes.

- Show date/time added.

• Activity tab:

- Similar to order timeline/activity style.

Orders Module

Order create form:

• Do not add items while creating order.
• Items are added after order creation on Order Details.
• During create, only ask:

- Customer, searchable dropdown.

- Channel/mode/source/subchannel.

- Collection Type.

• Remove:

- Handled By

- Next Step

- Extra unnecessary fields.

• Role logic:

- Customer care user creates pickup orders; walk-in should not be available.

- Store manager/store employee gets options according to store role.

• Collection Type:

- Doorstep Pickup.

- Store Drop-off / customer gave clothes at store.

- If online order, pickup only.

- If offline/store, both store drop-off and pickup booking can be possible.

Order details:

• Header should show only Back to Orders and Order ID.
• Remove customer details and created date/time from header.
• Back button should have icon.
• Tabs:

- Overview

- Items

- Tags

- Notes

- Summary

- Invoice

- Activity

- Audit should not show in user app.

• Update tab removed.
• Timeline renamed Activity.
• Activity should show order lifecycle.
• Notes works like customer notes: append-only with date/time.

Order overview:

Remove:

• Service
• Handled By
• Pickup Agent
• Pickup Scheduled
• Picked At
• Received in Facility
• Saved Items

Add:

• Current Status from Activity current status.
• Customer ID.
• WhatsApp.
• Email.
• Amount.
• Payment Status.
• Payment Mode.
• Total Items.
• Total Articles.

Order lifecycle:

• Order Received is created when manual/automatic order is created.
• Order Confirmed must be manual.
• When opening order detail, system should prompt/notify to confirm if not confirmed.
• User should not proceed to next operational steps until order is confirmed.

Pickup lifecycle:

1. Pickup Scheduled

2. Pickup Assigned

3. Pickup Accepted / Rejected / Cancelled by field executive

4. Reached Pickup Location

5. Items Received From Customer - field/user must enter what items customer gave

6. Pickup Completed

7. Handover to store/workshop/hub

Delivery lifecycle:

1. Delivery Scheduled

2. Delivery Assigned

3. Delivery Accepted

4. Out for Delivery

5. Reached Customer Location

6. Handovered to Customer

7. Delivered

Nested activity concept:

• Order activity
• Pickup activity
• Delivery activity
• Payment activity
• Processing activity
• Item-level processing activity

Processing:

• Split into order-level processing and item-level processing.
• Each item can have its own processing steps/activity.

Items:

• Items are added on order detail page in popup.
• Popup should be full-page/centered properly.
• Item add flow:

1. Select Main Service first.

2. Based on main service, show service type/category options.

3. If selected item/category has only one billing mode, hide billing mode dropdown.

4. If multiple billing modes are enabled, show billing mode selector.

5. Per piece should show number of articles and price.

6. Per kg should show number of articles, weight, and price/kg.

• Main Service should be shown clearly large/left/top; item/category below.
• Remove from item add:

- Item name

- Tracking IDs

- Upload photos from desktop item-add form

- Tracking hierarchy

• Photos are handled from item detail/mobile camera flow.

Items display:

• All Items should look like All Orders/All Customers list.
• Clicking entire item row opens item detail.
• Remove separate open icon.
• Order item card should use less space and be easier to scan.
• Main Service displayed prominently.
• Category/item/type below.
• Item ID shown.
• Article IDs not shown in item card.
• Edit/remove buttons icon-only.

Item detail page:

• Needs breadcrumb like admin pages.
• Tabs include Overview, Activity, Photos.
• Mobile app should have camera/upload button per item.

Order Summary and Invoice:

• Invoice is generated after payment.
• Before payment, use Order Summary / Receipt.
• Summary link should be generated.
• If summary link exists, show View Summary button and open in new tab.
• Summary should include TAT:

- Individual item ready date/time based on TAT.

- Longest ready date/time for whole order.

• Item add should auto-calculate ready date/time from TAT but allow manual change.
• Invoice layout needs brand details and clean table. Earlier PDF layout had columns cramped.

Services / Preferences

Services module replaces old Preferences/Service Catalog wording.

Main services currently considered:

• Laundry
• Dry Cleaning
• Shoe Cleaning
• Sofa Cleaning
• Steam Iron
• Carpet Cleaning
• Curtain Cleaning

Billing defaults:

• Dry Cleaning: Per Piece only.
• Shoe Cleaning: Per Pair only.
• Sofa Cleaning: Per Seat only.
• Steam Iron: Per Piece only.
• Carpet Cleaning: Per Piece or Per Sqft.
• Curtain Cleaning: Per Piece only.
• Laundry is flexible and has internal services like Wash & Fold, Wash & Iron, Premium Laundry, etc.

Important latest service structure:

• Admin app Brand Details and User app Services should share same structure.
• First choose whether the brand provides a main service.
• Do not show separate top checklist and then duplicate details below.
• Each main service should expand inline.
• Inside a main service, each section/item/type gets its own setup:

- Enabled/disabled toggle.

- Billing mode.

- TAT.

- Price rule.

- Fixed rate if fixed.

- Price range if range.

- Decide on order if team decides price during order creation.

- Urgent processing/surcharge rule if available.

- Processing location/routing if applicable.

• No generic default TAT at service level if it creates confusion.
• Laundry sub-services like Wash & Fold and Wash & Iron can each have different billing, TAT, and pricing.
• UI should reveal next fields only after the needed option is selected.
• On/Off should be proper toggle switch.
• Services setup should feel like guided configuration, not a large confusing form.

Shipments

Shipment module purpose:

• Move articles from one location to another.
• Example: store to workshop, workshop to store, hub to franchise, etc.
• Articles are scanned and added to shipment.
• Sender scans articles and sends.
• Receiver scans articles and receives.
• System reconciles expected vs received articles.

Required:

• Create Shipment button.
• Shipment detail page.
• Scan to add option.
• Desktop uses USB scanner; scanner behaves like keyboard input.
• Mobile uses camera scan.
• Shipment status/activity should show send/receive/reconciliation.

Team / Employees / Users

Employees module renamed Team in user app.

Team creation:

• Employee code auto-generated and not editable.
• Mobile number and WhatsApp number both support searchable country code.
• WhatsApp same-as-mobile option.
• Joining Date field.
• Upload documents properly active.
• New employee form should not ask active/inactive or registration status.
• Dropdown z-index fixed.

Teams/roles:

Team names should be generic enough for different business models:

• Field
• Operations / Fulfillment / Production equivalent - choose wording that works for factory or store processing.
• Customer Care / Customer Experience
• Accounts / Finance
• Admin
• Management
• Store

Roles include:

• Brand Superadmin
• Brand Admin
• Store Manager
• Store Staff
• Operations Manager
• Operations Staff
• Customer Care
• Accounts User
• Field Manager
• Field Executive

Old "Owner" wording should be Superadmin.

Rule:

• No user can be created without assigning a Team.
• Team should be required in UI and API.

Mobile App

Mobile app folder: `chimti-user-mobile-app`.

Mobile app direction:

• It should mirror user app modules and detail flows where useful.
• User taps Orders -> All Orders.
• Tapping order -> Order Details with tabs.
• Same pattern for customers, shipments, locations, services, etc.
• Left menu opens from hamburger.
• Profile should be inside left menu, not top-right.
• Top-right should be a premium plus button for quick actions:

- New Customer

- New Order

• UI should take inspiration from modern mobile UI references but not blindly change structure.
• Avoid copying dark reference exactly unless user explicitly asks; earlier dark change was reverted.
• Login page should be branded and clean.

Field-only useful modules for mobile:

• Today/Pickup tasks
• Delivery tasks
• Route/assigned jobs
• Scan shipment
• Item photo capture
• Status update
• Customer call/WhatsApp action
• Issue reporting

Live Activities concept:

• iOS Live Activities can be used for active pickup/delivery task, active route, urgent order, or current order being processed.
• Needs native iOS setup; test separately on simulator/device.

Item photos:

• Mobile item row/detail should have camera/upload button.
• It should ask camera or upload.
• Camera capture uploads photo to that item.

Customer App

Customer app folder: `chimti-customer-app`.

Direction:

• Separate customer-facing app/portal.
• Customer logs in with mobile number, not just public link.
• Customer can see:

- Previous orders

- Current order status

- Order summary/receipt

- Payment/status info later

• Must work desktop and mobile responsive.

Tags and Printing

Printer:

• TSC 244 Pro style USB printer.
• Tafetta waterproof roll.
• Roll width tested around 75mm.
• Final tag design should assume 55mm usable width.

Important browser limitation:

• Deployed website/user app cannot directly access random USB printer from browser.
• Local print agent is required on every computer that has USB printer connected.
• Print agent runs locally and receives print commands from web app.

Print agent:

• Repo: `chimti-print-agent`.
• Should support Windows and Mac.
• User asked for it to be saved in Downloads and installed/run on each system.

Test learnings:

• Printer may show red error after bad print; restarting printer clears it.
• Blank/long test print worked after adjusting dimensions/margins.
• Margins needed correction; side cut happened until adjusted.
• User confirmed one print looked good after margin fix.

Tag content required:

• QR code bigger.
• Random/useful part of Order ID.
• Service name.
• Special instructions.
• Article sequence like 1/3, 2/3, 3/3.
• Item/service detail.

User app tags UI:

• Tags shown in user app should visually match printed tag.
• Hover on tag shows print icon.
• Clicking print icon prints that specific tag.
• Print All Tags prints all.
• Previous issue: hover print button click was not working and printed output did not match visible UI. Continue from there if still unresolved.

Website

Repo: `chimti-website`.

Current website direction:

• Light mode.
• New Chimti logo/icon/favicon applied.
• Use blue Chimti palette from new logo.
• Logo must remain visually same as provided, not distorted.
• Background removed from logo assets.
• Top-left logo smaller, with "by OTLU" on right.
• Hero uses Chimti dashboard image.
• Hero animation should feel premium, not too heavy.

Latest website changes completed:

• Dashboard image is `public/chimti-dashboard-hero.png`.
• Hero no longer cuts in the middle.
• `public/light-mode.css` and `public/hero-scroll.js` control light mode and hero animation.
• Hero now has:

- subtle animated grid/ribbon background

- smooth entry animation for text/buttons

- dashboard parallax/reveal

- Live Sync Ready chip

- desktop operational hotspots

- mobile hides clutter and keeps clean dashboard/status

• Build passed with `npm run build`.
• Website server running on `http://127.0.0.1:5173` during latest work.

Login Page Rules

For both admin/user app login:

• Proper branded login page.
• Remove marketing/internal text like "Role based access", "Secure workspace", "Welcome Back", reset button.
• User/admin already knows where they are logging in.
• Password show/hide should be icon-only.
• Design inspired by provided modern login references but use Chimti colors.

UI/UX Product Rules

Global:

• Use premium sky-blue/light Chimti aesthetic.
• Avoid orange legacy color.
• Avoid heavy helper text.
• Avoid details page counters; keep counters on list/dashboard pages.
• All lists show 10 rows per page with pagination.
• Popups centered and content-sized.
• Esc closes popup.
• If dirty, ask save/exit once.
• All tabs should switch visible section, not just scroll.
• Breadcrumbs on detail pages.
• Back button icon-only where possible.
• Scrollbars hidden.
• Use icons for obvious actions.
• Copy feedback should appear when copying IDs.
• Activity visible in user app; Audit hidden from user app and reserved for admin/internal governance.

Activity vs Audit:

• Activity: user-friendly operational timeline shown to teams/customers where relevant.
• Audit: internal compliance/security log of who clicked/changed what; show in admin app only.

Action logging:

• Any button/action should create audit log.
• Business-related actions should also create Activity events on the related entity.
• Examples:

- order created by X

- delivery assigned by X to Y

- pickup scheduled by X

- payment recorded by X

- customer note added by X

Dashboard / Map

User app dashboard:

• A Google-like proper map was desired.
• Map source switched toward MapCN / CARTO-like style; user wanted markers like source site.
• Customer pincode map moved to Dashboard.
• Map should show customer pincode distribution, orders, revenue, pending, pickup, risk.
• Dashboard map width requested 75%, remaining 25% should show analytics.
• Remove bottom pincode/insight cards below map.
• Map analytics ideas:

- pincode demand

- revenue concentration

- pickup-heavy zones

- pending/risk zones

- low activity zones

- customer density

- high repeat zones

Dummy Data

Data requests done/needed:

• Call Your Dhobi/Otlu brand: 10 customers and 20-25 orders with full details.
• Freshora: dummy customers and orders requested later.
• One dummy order had 10-15 items added for invoice/tag testing.
• Demo clients by operating model added.
• Demo superadmin users added for each demo client.

Market / Positioning Notes

Best things about Chimti:

• Garment/article-level tracking with QR/tag identity.
• Order ID + Item ID + Article ID structure.
• Works across store, workshop, hub, franchise, and service-site models.
• Configurable services, pricing, TAT, and processing location.
• Full operational lifecycle: customer -> order -> pickup -> items -> tags -> processing -> shipment -> delivery -> payment.
• Multi-app ecosystem: admin app, user app, mobile field app, customer app, website, API, print agent.
• Can support brand-level plans/features/modules and future usage/user/store billing.

Positioning:

• Not "laundry billing software".
• Position as "Laundry Operations Command Center" or "Garment-Care ERP for modern laundry brands".
• Emphasize operational control, tracking, brand/location setup, and customer experience.

Open / Continue Items

Likely next work areas:

1. Confirm print output matches tag UI exactly and individual tag print button works.

2. Complete backend persistence for locations/shipments/services if any UI-only pieces remain.

3. Continue admin Brand/Location Services setup UX and persist it to API.

4. Ensure user app Services module matches admin Services structure.

5. Finish item detail page with Activity and Photos tabs.

6. Finish mobile app parity for Orders, Customers, Shipments, Locations, Services.

7. Fix any iOS/Android simulator runtime/login issues.

8. Make module launch config load before sidebar renders to prevent flash of hidden modules.

9. Continue customer app with phone login and order history.

10. Deploy API/admin/user/website to Coolify subdomains.

11. Keep product knowledge updated in `chimti-admin-app/docs/chimti-product-knowledge.md`.

Existing Product Knowledge File

Main product knowledge file:

`/Users/jagjeetsinghsethi/Downloads/Code/Chimti/chimti-admin-app/docs/chimti-product-knowledge.md`

It currently stores:

• Product UI rules.
• List pagination rule.
• User creation team rule.
• Operating models.
• Demo clients.
• Demo user app superadmins.
• Client-side role options.
• Flow for creating future 11th user type.

This handoff file is broader and should be used for new-chat continuity.