Chimti Product Knowledge
This is a living information file for Chimti. Add raw product rules, client setup notes, demo points, training points, and operating decisions here first. Later this can be reorganized into proper team documentation, client demo material, and training SOPs.
Knowledge Maintenance Rule
Whenever an important Chimti product decision, business rule, architecture change, workflow decision, client/model detail, pricing/services logic, user-role rule, or long-term structure decision is made in chat, add the durable rule to this file along with any code or UI changes. This file is the continuity source for future chats and team documentation, so do not leave important decisions only in implementation code or conversation history.
Documentation Repository Rule
`otlugroup/chimti-docs` is the central repository for long-lived Chimti documentation, including product knowledge, handoffs, architecture notes, app runbooks, deployment notes, workflows, pricing/services rules, and roles/permissions rules. During the transition, this admin-app product knowledge file should remain updated as the working continuity file, and the same durable knowledge should be copied or migrated into `chimti-docs` so documentation does not stay scattered across app repos.
Platform Account Domain
Chimti's primary product/domain identity is `chimti.ai`. Internal platform admin accounts, seed data, setup scripts, login placeholders, and future handoff docs should use `@chimti.ai` addresses instead of `@chimti.io`. The old `@chimti.io` addresses are legacy values only and should be migrated to the matching `@chimti.ai` account if they appear in a database or setup script.
Local Workspace Structure
Local repos under `/Users/jagjeetsinghsethi/Downloads/Code` are organized by product/client group. Chimti repos live under `/Users/jagjeetsinghsethi/Downloads/Code/Chimti`, Otlu repos under `/Users/jagjeetsinghsethi/Downloads/Code/Otlu`, Linklu repos under `/Users/jagjeetsinghsethi/Downloads/Code/Linklu`, and Kelme repos under `/Users/jagjeetsinghsethi/Downloads/Code/Kelme`. Future local path references and handoff docs should use this grouped structure instead of assuming all repos sit directly under `Code`.
Product UI Rules
List Pagination
All main list/register pages in both the user app and admin app should show 10 rows per page by default. This applies to pages such as All Orders, All Customers, Team, Users, Brands, Clients, Modules, Subscriptions, Payments, Shipments, Inventory, Processing Queue, Ads, and other table-based registers. After 10 rows, the page should use Previous / Next pagination with a clear "Showing X-Y of Z" count.
User Creation Team Rule
No user can be created without assigning a team. Every user creation and onboarding flow must require Team, and the save/API layer must reject missing team values instead of silently assigning a fallback.
User App Location Details
The User App must support a dedicated location detail route at `/locations/:locationId`. The Locations list opens this page for the selected store/location. The page should give operators one place to review Overview, Services, Team, Orders & Activity, Shipments, and Settings for that location. Until location-wise service overrides are enabled, the Services and Settings sections should clearly show that pricing, billing modes, turnaround time, processing location, and catalogue rules are inherited from the brand/workspace service setup.
Admin Live Notifications
The Admin App notification center is for live operational alerts, not demo/test controls. Visible test notification buttons should not be shown in production UI. WhatsApp and email notifications should surface as rich alerts with channel, priority where relevant, source/mailbox or business inbox, sender/customer context, message preview, timestamp, and direct actions to open the related module, mark read/unread, resolve, or remove. Toast notifications and the notification drawer should use the same alert data so operators can react quickly without losing context.
Client Operating Models
Chimti should be able to manage the following client operating models.
Store Only
The client runs one or more stores where most work is managed at the store level. Customer intake, tagging, billing, order handling, and handover can happen from the store. This model fits small operators or brands where each store is operationally independent.
Single Workshop
The client has one main workshop or operations hub. All brands, orders, processing, packing, pickup coordination, and delivery coordination are managed from that single location. This is the current Otlu model.
Store + Workshop
The client has customer-facing stores plus a central workshop. Stores handle intake, tagging, customer communication, and handover. The workshop handles processing, cleaning, packing, and operational production flow.
Hub and Spoke
The client has a main hub/workshop and multiple collection points, counters, stores, or pickup points connected to it. Spokes collect orders and move them to the hub for processing. This model is useful when the brand wants wider area coverage but centralized production control.
Franchise Network
The client or parent group manages multiple franchise locations under one or more brands. Each franchise can have its own store, staff, customers, and local operations, while the parent team can still monitor brand-level performance, permissions, billing, and reporting.
Service Based
Different services can follow different processing paths. For example, laundry may go to a workshop, steam iron may happen at store level, sofa or carpet cleaning may happen at the customer site, and premium dry cleaning can follow a separate workflow. This model is useful when routing depends on service type rather than only store or workshop structure.
Demo Clients by Operating Model
These demo clients are created in the database for demos, training, and internal testing. They are demo-phase records and should not be treated as real customers.
| Operating Model | Demo Client | Demo Brand | What This Demo Shows |
| --- | --- | --- | --- |
| Store Only | NeatNest Care Group | NeatNest Laundry | Two store-led locations where stores manage intake, tagging, billing, handover, and local operations. |
| Single Workshop | AquaFold Works | AquaFold Laundry | One shared workshop/operations hub where all work is managed from a single location. |
| Store + Workshop | WhiteWave Care Group | WhiteWave Laundry | Two customer-facing stores connected to one central workshop for processing and packing. |
| Hub and Spoke | SpinRoute Services | SpinRoute Cleaners | One central hub with multiple collection points/spokes routing work into the hub. |
| Franchise Network | Freshora Care Network | Freshora Laundry | Multiple franchise stores under one parent/brand setup with central visibility and reporting. |
| Service Based | FabricMint Services | FabricMint Care | Different service types route differently: store, workshop, and customer-site service base. |
Demo User App Superadmins
Each demo client has one user app superadmin account. These accounts are for demos, training, and internal testing only.
| Demo Client | Demo Brand | User App Email | Password | Role / Scope |
| --- | --- | --- | --- | --- |
| NeatNest Care Group | NeatNest Laundry | superadmin@neatnest.demo | ViNXa@uALb4433cT@G | Brand Superadmin / Brand scope |
| AquaFold Works | AquaFold Laundry | superadmin@aquafold.demo | pkrZ6QfBCH2AmMr#t# | Brand Superadmin / Brand scope |
| WhiteWave Care Group | WhiteWave Laundry | superadmin@whitewave.demo | h6hGQ35XUiw8BeyN!X | Brand Superadmin / Brand scope |
| SpinRoute Services | SpinRoute Cleaners | superadmin@spinroute.demo | bNLQbRP5B%XWPiRzjh | Brand Superadmin / Brand scope |
| Freshora Care Network | Freshora Laundry | superadmin@freshora.demo | wC@E8bGCkDGA7Xg?VG | Brand Superadmin / Brand scope |
| FabricMint Services | FabricMint Care | superadmin@fabricmint.demo | cacWzLtc7bG7To@i%5 | Brand Superadmin / Brand scope |
Client-Side User Role Options
When creating users for a client/brand workspace, use these role options. The old "Owner" wording should be shown as "Superadmin" in the product UI.
| Role Label | Scope | Typical Use |
| --- | --- | --- |
| Brand Superadmin | Client / Brand | Full workspace control for the business owner or top decision maker. |
| Brand Admin | Brand | Day-to-day setup, stores, services, users, reports, and operations control. |
| Store Manager | Store / Location | Store-level team, customer intake, billing, exceptions, and handover. |
| Store Staff | Store / Location | Counter work, walk-in orders, tagging, payments, and receipts. |
| Operations Manager | Workshop / Hub | Processing queues, QC, production stages, staff, and operational exceptions. |
| Operations Staff | Workshop / Hub | Assigned washing, dry cleaning, ironing, packing, QC, and processing tasks. |
| Customer Care | Brand / Queue | Calls, WhatsApp, pickup booking, customer lookup, complaints, and follow-ups. |
| Accounts User | Brand / Finance | Invoices, dues, payment tracking, settlements, refunds, and finance reports. |
| Field Manager | Field Team | Pickup/delivery assignment, route follow-up, rider exceptions, and field status. |
| Field Executive | Mobile App | Pickup, delivery, customer-site handover, item photos, and task completion. |
Creating the 11th User Type
New user types should be created from the admin app, not by hardcoding a new dropdown value.
Flow:
1. Open Admin App -> Permissions.
2. Switch to Client Role Templates.
3. Click Add User Type.
4. Enter user type name, scope, team, app access, and optional description.
5. Optionally copy permissions from an existing role.
6. Create the role, then open its permission detail page and fine-tune permissions.
7. After save, the role should automatically appear in user creation role dropdowns.
Role metadata:
| Metadata | Purpose |
| --- | --- |
| Scope | Defines whether the role belongs to brand, store/location, workshop/hub, field, finance, or customer experience context. |
| Team | Used for operating team grouping and reporting. |
| App Access | Defines whether the role is mainly for user app, mobile app, or both. |
| Permissions | Controls what modules/actions this user type can access. |
Architecture Decisions - 28 May 2026
These decisions summarize the current intended long-term Chimti structure.
Client, Brand, Location Hierarchy
Chimti should treat Client as the parent group/company and Brand as the operating/billing workspace.
Rules:
1. One client can have one brand or multiple brands.
2. Plans, billing, feature access, module access, service catalog, pricing rules, and TAT rules are brand-level.
3. Users are created in brand/workspace context because future billing can depend on users.
4. A user can later be granted access to multiple brands under the same client without needing a separate login for every brand.
5. Locations are brand-level by default, not client-level.
6. Locations can be Store, Workshop/Hub, Processing Unit, Collection Centre, Service Site, or another configured type.
7. If multiple brands under one client share a hub/factory/workshop, that sharing must be explicitly configured for that client/brand setup. It should not happen automatically.
Billing Level
Billing should be brand-level.
Reason:
- Plans/features are selected per brand.
- Store count, user count, module access, service scope, and operating model can differ by brand.
- A parent client can still receive consolidated reporting later, but commercial entitlement should sit on the brand workspace.
Brand Services Scope
Each brand should define whether services/pricing/TAT are:
1. Universal / Brand-level: all locations follow the same setup.
2. Location-wise: each location can override or maintain its own services/pricing/TAT setup.
Switching this setting should show a warning because it can affect existing pricing and operations.
Service Setup Structure
Services setup should not duplicate "select services" above and "configure details" below. The enabled toggle and configuration should be part of the same section.
Service setup flow:
1. Show main services as expandable rows/cards.
2. Each main service has a proper On/Off toggle.
3. When a main service is on, show its internal service items/types.
4. Every internal service item/type can have its own billing mode, TAT, pricing rule, urgent rule, and processing location.
5. Do not rely on one default TAT when item-level TAT is needed.
6. Show only the next relevant fields after previous choices are made.
Pricing rules:
- Fixed Rate.
- Price Range.
- Decide on Order.
Laundry example:
- Laundry is the main service.
- Wash & Fold, Wash & Iron, Premium Laundry, and similar are internal service types.
- Each internal service type can separately be Per Kg or Per Piece, have separate TAT, and have separate price.
Module Launch Structure
Admin App -> Modules controls global launch status for User App modules.
Rules:
1. "Module Launch" should be called "Modules".
2. Launch status and global visibility are treated as one practical concept.
3. Launched modules are available for brand-level setup.
4. Planned modules are hidden globally and should not appear in brand module enable screens.
5. Brand-level module settings can enable/disable only launched modules for that brand.
6. User role permissions then decide which user can see/use enabled modules.
7. Module list should be alphabetical and use the same list pattern as All Orders / All Customers.
8. Module detail page controls display tag/badge such as New, Beta, Planned, etc.
Current planned/hidden modules:
- AI POS Assistant
- Calls
- Campaigns & Loyalty
- Customer Experience
- Delivery Tracking
- Internal Chat
- Inventory
- Support
- WhatsApp AI
Current enabled User App modules from this launch list:
- Chimti Genie
- Processing Queue
Codex-Backed AI Layer
Chimti's AI layer should be available inside the client-facing User App, not only the internal Admin App. The first provider should be Codex CLI installed on the Chimti server, with every AI-enabled Chimti user connecting their own Codex account/profile.
Durable rules:
1. The AI layer must use a backend provider abstraction. Codex CLI is the first provider, but future providers such as OpenAI API, Gemini, Anthropic, or another provider should be pluggable without rebuilding the User App UI.
2. Each Chimti user must have an isolated server-side AI profile for Codex-backed access. One user's Codex account, auth files, usage limits, and outputs must not be shared with another user.
3. User email must not be used directly as an AI profile folder name. Use an internal user id or hashed/safe profile id.
4. Codex CLI must run only on the server side. The frontend must never receive Codex auth files, tokens, profile paths, or raw credentials.
5. The User App AI experience can later support chat, AI CEO summaries, workflow help, customer/order lookup, reply drafting, follow-up tasks, reports, and other controlled actions.
6. AI must receive compact, permission-scoped Chimti business context rather than raw database dumps. Context can include current user, role, brand, location, page/module context, recent orders, customers, payments, WhatsApp/call summaries, and relevant links only when the user has access.
7. AI must not get direct database write permission. AI can propose an intent/action; the backend must validate permissions, required fields, business rules, and safety before executing controlled functions.
8. AI access should be controlled by module/plan/role permissions. Brand Superadmin and Brand Admin can be default eligible users when enabled; other roles need explicit AI permission.
9. Codex-backed AI usage should integrate with the prepaid credits/usage ledger where Chimti bears cost or provides paid automation. Even bring-your-own Codex account usage should be logged for audit, limits, support, and abuse protection.
10. Deployment must provide persistent storage for per-user AI profiles and generated AI artifacts if the backend is containerized.
11. Detailed concept note lives in `chimti-docs/architecture/codex-ai-layer.md`.
12. First implementation stores AI setup in `AiSetting`, saved conversations in `AiChat`, and saved messages in `AiMessage`.
13. First API surface uses `/v1/ai/account/status`, `/v1/ai/account/login`, `/v1/ai/models`, `/v1/ai/account/model`, and `/v1/ai/chats/*`.
14. Codex device login is backend-owned: the User App only receives the login URL/code, while the backend runs Codex with a per-user `CODEX_HOME`.
15. Initial Codex message execution uses `codex exec` with read-only sandbox, no approval prompts, an isolated working directory, timeout control, and no direct Chimti database write/action access.
16. Chimti Genie (`/ai-chatbot`) is now treated as a live/default-visible User App module, not a planned hidden module.
17. Chimti should support a Daily AI Business Report for the client-facing User App. It should summarize yesterday's dashboard data, predict today's business risks/opportunities, and recommend clear actions for brand/store users.
18. Daily AI Business Report delivery should default to every morning in the brand's local timezone, available inside the User App dashboard, with optional email/WhatsApp/notification delivery based on module permissions and communication credits.
19. Daily AI Business Report metrics must come from deterministic scoped queries; AI should write the explanation, prediction reasoning, and recommendations. AI predictions must show confidence and must not be presented as guaranteed outcomes.
20. Daily AI Business Report guardrails: AI cannot directly change orders, send campaigns, apply discounts, or assign staff without explicit automation rules, permission checks, and user confirmation where required.
21. Detailed Daily AI Business Report concept and sample live in `chimti-docs/product/daily-ai-business-report.md`.
Activity and Audit
Activity and Audit are different.
Activity:
- User-facing operational timeline.
- Shown in user app on orders, customers, items, shipments, etc.
- Examples: order created, pickup scheduled, delivery assigned, payment recorded, note added.
Audit:
- Internal compliance/security log.
- Should be shown in admin app, not user app.
- Every button/action/change should create an audit log.
- Business actions should also create entity activity events.
Shipment Model
Shipment is used whenever articles move from one location to another.
Required flow:
1. Create shipment.
2. Scan articles to add them.
3. Send shipment from source location.
4. Receive shipment at destination location.
5. Reconcile expected vs received articles.
Desktop scanning can use USB scanner keyboard input. Mobile scanning should use camera.
Order Lifecycle Model
Order activity should be nested by domain:
- Order activity.
- Pickup activity.
- Delivery activity.
- Payment activity.
- Order-level processing activity.
- Item-level processing activity.
Order confirmation rule:
1. Order Received is created automatically when order is created manually or through automation.
2. Order Confirmed must be a manual action.
3. Team should not proceed to next operational steps until order is confirmed.
Pickup flow:
1. Pickup Scheduled.
2. Pickup Assigned.
3. Pickup Accepted / Rejected / Cancelled by field executive.
4. Reached Pickup Location.
5. Items Received From Customer.
6. Pickup Completed.
7. Handover.
Delivery flow:
1. Delivery Scheduled.
2. Delivery Assigned.
3. Delivery Accepted.
4. Out for Delivery.
5. Reached Customer Location.
6. Handovered to Customer.
7. Delivered.
Customer Communication and Credits
V1 customer communication is for outbound order updates over WhatsApp and SMS.
User app module status:
1. WhatsApp Inbox is enabled as a live user-app module.
2. WhatsApp AI remains separate from the normal WhatsApp Inbox module and should not be treated as automatically enabled by this rule.
3. WhatsApp Inbox should let clients manage customer WhatsApp conversations inside Chimti after connecting their own WhatsApp Business API/provider.
4. Client-owned WhatsApp API setup should support inbound replies, outbound replies, and order/customer context, not only automated order-status messages.
5. WhatsApp Inbox V1 should include Inbox, API Setup, Templates, and Logs sections.
6. Inbox should support conversation status, assignment, quick replies, customer/order context, order-status reply, payment-link reply, and complaint escalation.
7. API Setup should support client-owned providers and Chimti API mode from the same module, while respecting the provider ownership and prepaid-credit rules below.
8. Templates should manage WhatsApp order-event messages and allow event-level enable/disable.
9. Logs should show attempted, sent, held, skipped, and failed WhatsApp outbox messages.
10. Admin app must expose the cross-client Communications/WhatsApp API view inside the Clients section, not as a separate primary sidebar module. It should show, brand-wise and store-wise, whether each scope uses client-owned API, Chimti API, or no provider.
11. Admin Communications view should show wallet balance, used credits, held messages, provider enabled/status, and whether a store setting is direct or inherited from brand/global settings.
12. Actual admin setup for WhatsApp/API ownership must live inside `Clients -> Brand Details -> Communications`, not only in the cross-client report.
13. The Brand Details Communications setup must follow the same mental model as service pricing: select Brand Default for universal setup, or Location Override for a store-specific setup.
14. Store/location WhatsApp settings are configured from the brand context by selecting the store; if no store override is saved, the store inherits the brand default.
15. The Brand Details Communications section should include provider mode, provider credentials, enabled status, connection test, Chimti credits, order-event rules, and recent outbox logs for the selected brand/store scope.
16. A brand may connect multiple WhatsApp Business phone numbers. Every number must be stored as a separate WhatsApp connection with its provider, WABA id, provider phone-number id, display number, ownership mode, connection status, and brand/store routing scope.
17. Incoming WhatsApp webhooks must be resolved by provider plus provider phone-number id before loading tenant data. The resolved connection determines the client, brand, store/location, inbox queue, wallet/provider mode, and permitted users.
18. All providers must normalize inbound messages, outbound messages, delivery/read statuses, contacts, conversations, templates, and errors into Chimti-owned communication models so the User App inbox does not depend on one provider's payload format.
19. The WhatsApp Inbox must support number, brand/store, status, assignee, and team filters. A conversation must remain attached to the receiving WhatsApp connection so replies always leave through the correct number.
20. Chimti WhatsApp connections have three distinct modes: `CHIMTI_PLATFORM`, `CLIENT_PROVIDER`, and `CHIMTI_DIRECT`. These modes must not be merged into a single generic client-owned/chimti-owned switch.
21. Chimti may expose a normalized Messaging API and outbound webhooks to approved clients so their systems can send messages, read conversation events, and synchronize statuses through Chimti. Client API credentials must be Chimti-issued credentials; raw Meta/provider tokens must not be given out as the Chimti API.
22. Provider access tokens, API keys, signing secrets, and webhook secrets must stay encrypted server-side and must never be exposed to the browser after setup.
WhatsApp connection modes:
1. `CHIMTI_PLATFORM`: Chimti/Otlu owns and operates multiple WhatsApp numbers for Chimti's own business communication. Each number has a declared purpose such as public-lead follow-up, client onboarding, billing/service notices, platform support, or internal operational alerts. These numbers belong to a system/platform workspace and must not be silently treated as a client's brand/store number.
2. `CLIENT_PROVIDER`: A client connects an existing third-party WhatsApp provider account such as WATI by supplying the provider endpoint/account identifiers and API credentials, then configuring the provider webhook to Chimti. Chimti normalizes that provider's inbound messages, outbound messages, statuses, templates, and errors into the shared inbox. The client keeps and pays for the provider subscription, and available functionality depends on that provider and subscription plan.
3. `CHIMTI_DIRECT`: Chimti directly provisions WhatsApp Business Platform access for the client's own business through Meta Embedded Signup as a Meta Tech Provider/solution integration. The client owns its Meta Business Portfolio, WABA, phone number, display name, and business identity; Chimti receives authorized access to operate the number inside Chimti. The client does not need a separate WATI or other BSP subscription.
4. `CHIMTI_DIRECT` onboarding requires more than business verification: the client must complete Meta authorization, WABA/number selection or creation, number OTP registration where required, display-name approval, permissions, terms/payment setup where applicable, and webhook subscription. Chimti should present this as one guided `Connect directly with Chimti` flow.
5. `CHIMTI_DIRECT` commercial treatment is separate from a third-party subscription. Meta messaging charges and Chimti's own platform/communication-credit or service fee rules may still apply even though no WATI subscription is required.
6. The User App API Setup screen should present the client-facing choices as `Connect existing provider` and `Connect directly with Chimti`. `CHIMTI_PLATFORM` numbers are administered only by Chimti staff in the Admin App.
7. Initial Meta production topology should use one Meta Business app associated with the verified OTLU business portfolio, one Chimti-owned WABA, and multiple purpose-scoped `CHIMTI_PLATFORM` phone numbers inside that WABA. Do not create a separate Meta app for every phone number.
8. The initial Chimti-owned number purposes should be separated into public leads/demo follow-up and client success/support. A separate system-notification number may be added later when notification volume or operational risk justifies it.
9. Chimti-owned phone numbers must be permanently controlled by the company, remain recoverable for OTP/verification, and must not depend on an employee's personal WhatsApp number or personal Meta assets.
10. Real WhatsApp traffic uses a dedicated connection/conversation/message/event data layer rather than forcing Chimti-owned numbers into a client brand. Every Meta webhook is resolved by `provider + provider phone-number id`, verified with `X-Hub-Signature-256`, deduplicated before processing, and retained with its connection for audit and retries. A connection may remain platform-scoped with no client brand, or be explicitly routed to a brand/store later.
11. The production Meta callback is the Chimti API endpoint `/v1/whatsapp/webhooks/meta` on `api.chimti.ai`. Verify tokens, Meta app secrets, permanent access tokens, WABA ids, and phone-number ids are deployment secrets; they must not be committed, returned to browsers, written into product docs, or copied into client-visible provider settings.
12. The first Chimti-owned Meta number is represented as a `CHIMTI_PLATFORM` connection. Incoming messages must enter Chimti's shared WhatsApp inbox even when no client brand is assigned; client-owned and client-routed numbers continue to use explicit brand/store scope.
13. The first production Chimti-owned WhatsApp display number is `+91 93101 44080` with display name `Chimti`. It is a platform-scoped Meta Cloud API number for Chimti lead follow-up, onboarding, support, and system/client communication, not a client brand/store number.
14. The Admin App must expose a live WhatsApp Inbox for Chimti platform conversations. Messages received on `CHIMTI_PLATFORM` numbers should be visible to authorized Chimti internal/admin users even when no client brand or store is assigned.
15. Client self-serve WhatsApp onboarding for `CHIMTI_DIRECT` must use Meta Embedded Signup, not manual token copy/paste. The client should click `Connect directly with Chimti`, log in to Meta, select or create their Business Portfolio, WABA, and phone number, verify the number, approve the display name and permissions, then return to Chimti.
16. Chimti must exchange the Meta authorization result server-side, fetch the WABA id and provider phone-number id, subscribe that WABA/phone to Chimti's webhook, and store provider tokens encrypted. Raw Meta tokens must never be shown in the User App, Admin App, docs, logs, or client-visible settings.
17. A completed `CHIMTI_DIRECT` connection must be stored with ownership mode, provider, WABA id, provider phone-number id, display number, display name, business/account metadata, brand/store routing scope, connection status, template/status sync state, and audit timestamps.
18. For `CHIMTI_DIRECT`, the client owns the Meta Business Portfolio, WABA, phone number, display name, templates, Meta quality limits, and Meta billing/payment obligations where applicable. Chimti owns the product workflow, inbox, permissions, audit logs, normalized messaging API, support/service fees, and prepaid-credit rules.
19. Inbound and outbound messages for client-connected direct numbers must use the same connection/conversation/message/event layer as Chimti-owned numbers, with routing by provider plus provider phone-number id. Replies must always leave through the same client-owned number that received the conversation unless an authorized user explicitly moves the conversation.
20. Meta Developer Apps should be isolated by owned product/legal entity when failure isolation, separate brand review, separate tokens, and separate operational ownership matter. Chimti and OTLU must not share the same Meta Developer App for production WhatsApp; PracharX and Chaak should use their own apps/business portfolios because they are separate legal entities.
21. Do not create a separate Meta Developer App for every Chimti laundry client. Normal Chimti clients connect through Chimti's `CHIMTI_DIRECT` Embedded Signup flow and remain separate through their own Business Portfolio/WABA/phone number plus Chimti's brand/store routing.
22. The backend must support app-scoped Meta configuration instead of assuming one global Meta app forever. Each owned app should have its own app id, app secret, verify token, WABA/phone assets, webhook subscription, deployment secret set, and audit label.
23. When multiple owned Meta apps use Chimti infrastructure, use a webhook strategy that can select the correct app secret before signature verification, preferably an app-scoped webhook route such as `/v1/whatsapp/webhooks/meta/:appKey`. Webhook payloads must still be verified with `X-Hub-Signature-256` before processing.
24. New inbound WhatsApp customer messages should surface in the top notification system for authorized users. Notifications should increment the bell badge, show a toast, play the existing notification sound, dedupe by message id, and open the WhatsApp inbox from the notification action.
Provider ownership:
1. A brand or store can use its own client-owned provider credentials.
2. A brand or store can explicitly select Chimti API as the primary provider.
3. If a client-owned provider fails, the system must not automatically fallback to Chimti API.
4. Store-level communication settings are a full override of brand settings for that channel or event; if no store setting exists, brand settings apply.
Prepaid credits:
1. Chimti API messages are prepaid-credit based.
2. Credits live in a brand-level communication wallet.
3. Store usage debits the parent brand wallet.
4. WhatsApp and SMS currently cost 1 credit per outbound message unless pricing is changed later.
5. If Chimti API is selected and the brand wallet has insufficient credits, the message must be held/logged instead of sent.
6. Client-owned provider messages do not debit Chimti prepaid credits.
Compliance and audit:
1. Customer `communicationOptIn` must be respected before sending WhatsApp or SMS updates.
2. Every attempted, skipped, held, or sent customer message should be visible in communication outbox history.
Call and AI voice agent direction:
1. Chimti should support brand/store-assigned virtual phone numbers for inbound calls, missed calls, call logs, and callback from the app.
2. Call numbers follow the same brand/store scope model as services and WhatsApp: brand default number first, optional store/location override.
3. The calls module must be AI voice agent-ready, not only human callback. AI agents should be able to answer qualifying calls, fetch customer/order context from Chimti, create follow-up tasks, and hand off to a human user when needed.
4. For India-first telephony, prefer a compliant local telephony provider with virtual numbers, click-to-call, recording, status webhooks, and bidirectional real-time voice streaming to a bot service.
5. The AI voice agent layer should remain provider-pluggable: telephony provider owns numbers/call routing, while Chimti owns customer/order context, permissions, logs, credits/billing rules, and AI tools.
Branding
1. Chimti admin app and user app primary logo surfaces, including login headers and sidebar headers, should use the standalone Chimti wordmark only.
2. OTLU should be presented as a subtle maker/parent-company attribution, not as an inline co-logo with Chimti. Use `A product by` plus the high-quality supplied OTLU SVG from `Downloads/Otlu text/Red Dot + Black “O” on a White Background 2.svg` in the login panel footer/maker line.
3. App-level Chimti branding should not use the icon-only Chimti mark, inline `BY OTLU` lockup, or logo animation unless this decision is explicitly changed later.
Website Launch Page
Before full product launch, Chimti website may use a temporary launching-soon page.
Launch-page rules:
1. Temporary launch page should use the existing website visual language, especially the light gray page background, rounded Chimti-logo blue gradient hero panel using `#18b9fe`, `#14aaf4`, `#0a81d9`, and `#0058be`, oversized white hero text, black/white CTAs, and rounded white content sections.
2. Primary CTA is `Book Early Demo`.
3. Secondary CTA is `Join Early Access`.
4. Founding brand slots should be positioned as priority onboarding, launch pricing discussion, and migration/workflow mapping support, not as a paid preorder unless pricing/payment/legal rules are finalized.
5. Launch-page lead capture should ask for name, business/laundry brand name, work email, phone/WhatsApp, stores or operating units, operating model, and interested workflows.
6. Launch-page positioning should present Chimti as an AI-based laundry operating system: a single dashboard and "AI CEO" for orders, stores, customers, WhatsApp, calls, delivery, payments, reporting, and daily decisions.
7. When using the temporary Mistral-style website shell for Chimti, the global header must use Chimti's own text logo instead of the reference site's mark.
8. Chimti's temporary website header should use the normal full Chimti wordmark only. Do not show the `BY` label, OTLU text logo, icon-only Chimti mark, or logo animation unless this decision is explicitly changed later.
9. The temporary Mistral-style home page should use Chimti logo colors for important brand moments and accents, especially `#18b9fe`, `#14aaf4`, `#0a81d9`, and `#0058be`; avoid leaving primary accents in the reference site's orange/red palette.
10. The active temporary website folder is connected to the `otlugroup/chimti-website` GitHub repository. As of June 5, 2026, the active public website work should be promoted to `main`; `v1` preserves the previous `main`, and `v2` remains as the preserved working branch. The archived original website remains separate and should not be overwritten unless explicitly requested.
11. Chimti website favicon should use the colored Chimti icon SVG, served from `/favicon.svg`, and should be linked across all mirrored website pages.
12. Chimti website home-page copy should stay within the existing Mistral-style sections while replacing reference-site messaging with Chimti-specific positioning: an AI-based laundry operating system and "AI CEO" for orders, stores, customers, WhatsApp, calls, delivery, payments, reporting, client/store setup, credits, printing, and launch support.
13. The pre-launch website page lives at `/pre-launch/` in the website repo. It should use launch-specific copy with `Launching Soon` as the launch timing message and must not show a launch date unless explicitly decided later.
14. For now, Chimti website's blue hero animation should remain the original animation from the temporary website shell. Do not replace it with custom laundry icon or command-center/dashboard visuals unless a new direction is explicitly approved.
15. Chimti website top header menu should use five primary items in this order: `Features`, `Solutions`, `Pricing`, `Developers`, and `Company`. Keep `Pricing` as a top-level direct link. Avoid separate top-level `Updates`, `Clients`, `Modules`, or `API & agents` labels unless this navigation structure is explicitly changed later.
16. Chimti website `Solutions` dropdown should be grouped by customer operating model and workflow, not by internal admin capabilities. Business-type entries should include Single stores, Multi-store brands, Workshops & hubs, Pickup & delivery, Franchise networks, and Online laundry platforms. Workflow entries should include Orders & billing, WhatsApp & calls, Delivery & pickups, and AI CEO dashboard. Until dedicated solution pages are built, business-type links may point to `/solutions/`.
17. Public website feature messaging should focus on the client-facing User App and Mobile App, not Chimti's internal Admin App. Admin App capabilities are for Chimti/Otlu team control and should not be positioned as customer product features unless a specific internal/admin-facing page is being written.
18. Chimti website `Features` dropdown should list these 10 client-facing User App feature groups: AI CEO Dashboard, Orders & Billing, Customer CRM, Pickup & Delivery Management, Store & Workshop Operations, Article Tags & Scanning, WhatsApp & Customer Communication, Calls & Follow-ups, Shipments & Location Transfers, and Reports, Team & Permissions.
19. Chimti website `Features` dropdown items should keep the original website shell's icon-led navigation style: each item gets a sharp 40px solid-color square icon tile with a white feature mark, the hover-in arrow on the left, and the trailing pixel arrow on the right.
20. Each of the 10 `Features` dropdown items should have a dedicated website page under `/features/`: `/features/ai-ceo-dashboard/`, `/features/orders-billing/`, `/features/customer-crm/`, `/features/pickup-delivery-management/`, `/features/store-workshop-operations/`, `/features/article-tags-scanning/`, `/features/whatsapp-customer-communication/`, `/features/calls-follow-ups/`, `/features/shipments-location-transfers/`, and `/features/reports-team-permissions/`. The dropdown links should point directly to these pages.
21. Chimti website feature detail pages must include an explicit fixed-header top offset so the eyebrow/breadcrumb and hero content never sit behind the fixed global header.
22. Chimti website About page should position Chimti as an AI operating system for laundry businesses. It should focus on laundry operations, store/counter/workshop/customer workflows, and OTLU ownership, and must avoid unverified founder, customer-logo, or broad AI-lab claims.
23. Chimti website hero live-operations card should preserve the approved compact live-feed/table visual style over the blue hero animation: a white terminal-like card with `LIVE AI CEO · OPERATIONS`, timestamp, tag-led rows, and payment/alert/customer-operation signals. Avoid bulky KPI strips or separate suggestion panels in this hero card unless a redesign is explicitly requested.
24. Chimti public feature and pricing-page messaging should lead with unique, useful laundry operations capabilities instead of generic admin software bullets. Priority examples include detailed garment tracking and unified order intake.
25. Detailed Garment Tracking is a core marketable Chimti feature: each garment/article should be trackable with tag, stain, rack/location, workflow status, and history wherever practical.
26. Chimti should support unified order intake: orders from counter, WhatsApp, website, mobile app, third-party systems, or partner integrations should land in one Chimti order inbox. Chimti can provide APIs so external order sources can create or sync orders into the same operational flow.
27. Chimti should let clients connect their own payment gateway where feasible, so payment collection and reconciliation can be managed against orders from the same system.
27. Chimti should provide GST-ready sales, invoice, and payment data exports/reports so clients can share return-supporting data with accountants or finance teams more easily. Chimti should position this as data support for GST returns, not as tax filing/legal advice unless a filing partner/service is explicitly added.
28. Chimti dashboards should make business decisions easier by showing operational and commercial patterns, including where orders are coming from on maps, which service categories are selling most, revenue/payment trends, delays, and repeat-customer behavior.
29. Chimti analytics should help owners decide marketing direction: which areas to target, which services to promote, which customer segments to reactivate, and where pickup/delivery demand is strongest.
30. New product features described during pricing/planning should first be added to the lower pricing comparison table as an unassigned feature list with plan availability marked as `To decide`. Final mapping of each feature to Starter, Growth, Scale, or Enterprise will be decided later.
31. Chimti website pricing FAQs should answer laundry-business buying questions, not generic AI/model questions. Priority FAQ topics include plan choice, 14-day trial, per-active-store billing, prepaid credits, unified order intake/API, payment gateway reconciliation, GST-ready data, business dashboard insights, and Enterprise rollout scope.
32. Chimti website footer should use the Chimti wordmark/logo prominently and position Chimti as an AI operating system for laundry businesses. Footer branding must be universal across the website, just like the global header, and the Chimti logo should replace the reference-site footer mark in the same footer logo slot rather than being added as a one-page or misplaced custom block. Avoid leaving reference-site footer marks or generic AI-lab branding in public website footer areas.
33. Chimti should support local-language usage for owners, counter staff, workshop teams, and customer-facing workflows. Current launch positioning can state support for 8 local languages; exact language list should be finalized before publishing detailed language claims.
34. Chimti website active implementation should be a root Node.js app that serves the approved `public/` website pages through `server.mjs`. The previous `react-site/` React/Next.js experiment should not be used as the active website source unless a future migration is explicitly approved and visually matched.
35. Chimti website deployment should use the Node.js runtime and the repo `Dockerfile`, not an Nginx-only static container. The Node server should expose `/health` and `/api/health`, serve the existing static pages/assets, and keep correct MIME types for SVG, Lottie, WASM, video, and other website assets.
36. For current website edits, preserve the approved Mistral-style visual language and make scoped content/layout fixes inside `public/` unless a redesign or source-framework migration is explicitly requested.
37. Chimti website should have dedicated solution pages for all 10 Solutions dropdown entries: `/solutions/single-stores/`, `/solutions/multi-store-brands/`, `/solutions/workshops-hubs/`, `/solutions/pickup-delivery/`, `/solutions/franchise-networks/`, `/solutions/online-laundry-platforms/`, `/solutions/orders-billing/`, `/solutions/whatsapp-calls/`, `/solutions/delivery-pickups/`, and `/solutions/ai-ceo-dashboard/`. The `/solutions/` index should show the same entries grouped as `By Business Model` and `By Workflow`. The full website `/solutions/` page and the pre-launch landing `#solutions` section should use the approved Mistral-style solution showcase pattern: left category selector, right two-column bordered solution cards, large card headings, short workflow/business copy, and visual icon tiles; mobile should collapse this into a single-column stack without changing the visual system.
38. Old cloned/reference solution pages such as `/solutions/coding/`, `/solutions/speech/`, `/solutions/document-ai/`, and `/solutions/custom-model-training/` should stay accessible only by direct URL for now, but should not be used in visible navigation or sitemap entries.
39. Chimti website should have a `/features/` index page that lists and links to the 10 existing client-facing feature detail pages without changing those feature detail page URLs.
40. Chimti website `/contact/` should be a Chimti/laundry demo lead form asking for business context such as laundry business name, number of stores or operating units, operating model, WhatsApp/calls/API interest, and workflow needs.
41. The separate `chimti-pre-launch-landing-page` repo should be a true single-page launch/demo page, not a mini full website. Its header, footer, sitemap, and CTAs should use anchor-only navigation for `Product`, `Features`, `Solutions`, `Plans`, `FAQ`, and `Book demo`; primary CTA is `Book demo`; copy should say `Launching Soon` with no launch date; and the visual language should preserve the current Chimti website style.
42. The pre-launch landing page `Features` section should mirror the approved main website home feature spotlight style for every listed feature: desktop uses one left-rail shortcut icon per feature with stacked bordered feature panels, each panel with a heading/CTA row, large visual, and compact workflow chips; mobile follows the main website home mobile pattern with no icon rail, collapsed bordered spoiler rows, a small arrow toggle on the right, and expanded content showing copy, visual, and vertically stacked chips. Do not replace it with generic feature cards unless a new design direction is explicitly approved.
43. Mobile feature spotlight accordions on both the main website home page and the pre-launch landing page should use the same pixel-arrow toggle icon style and single-open behavior: when one feature row opens, any previously open feature row closes.
44. Public lead capture is centralized through the API route `/v1/public/leads`. The full website contact form and pre-launch landing page demo form must submit there, create an admin `LeadRecord`, send a confirmation email to the submitter, and notify the configured Chimti internal mailbox distribution. Email delivery uses API service env configuration (`SMTP_*` or `RESEND_API_KEY`), and lead saving must still succeed even if email delivery is temporarily unavailable.
45. Chimti Admin App `Leads` should use the same register pattern as `Clients`: metric summary first, then a searchable, filterable, sortable, paginated table with lead ID, stage, source, POC, contact, follow-up, note, and created time. It should not fall back to fake demo leads when the API returns an empty lead list.
46. Chimti Admin App lead rows should open a dedicated Lead Details page at `/leads/:leadId`. The details page should follow the same detail-record pattern as Clients and Brands: bordered header, breadcrumbs back to Leads, section tabs, Overview, Contact, Timeline, Demo, Notes, copyable IDs/contact fields, and visible demo meeting context when available.
47. All Chimti transactional email, including public lead confirmations and login one-time codes, should use the Chimti sender identity `Chimti <no-reply@chimti.ai>` through SMTP or the approved email provider. SMTP usernames, passwords, and mailbox credentials must stay in service environment variables and must never be committed to tracked files.
48. Chimti Admin App must include an `Emails` module for central Chimti-owned email operations. It should support multiple configured Chimti mailboxes, All Mail/Inbox/Sent/Drafts/Junk/Trash/Archive/Custom/Failed views, unread filtering, message detail history, attachment metadata, composing new outbound emails, and a backend-saved audit trail of each email. Mailbox credentials and providers stay in API environment variables.
49. Chimti public website and pre-launch landing page may use the blue Chimti helper mascot as a bottom-right interactive assistant. Its motion should stay subtle and useful: soft idle bob/breathing, occasional attention nudge, and label pulse are allowed; avoid loud, cartoonish, layout-shifting, or distracting animation.
50. If the helper mascot is animated from separate SVG body parts, the SVGs must be treated as a rigged puppet: first crop each part to its visible bounding box, then position/scale it in a fixed character canvas with explicit z-indexes and transform origins. Do not raw-stack full-artboard SVG exports, because isolated body-part SVGs do not automatically share the final mascot layout.
51. Approved Chimti-owned mailboxes are `no-reply@chimti.ai` for automated transactional sending; `superadmin@chimti.ai`, `jagjeet@chimti.ai`, `founder@chimti.ai`, and `admin@chimti.ai` for ownership/platform administration; `support@chimti.ai`, `care@chimti.ai`, `hello@chimti.ai`, and `info@chimti.ai` for customer communication; `notifications@chimti.ai`, `alerts@chimti.ai`, `updates@chimti.ai`, and `reports@chimti.ai` for system and report communication; `accounts@chimti.ai`, `billing@chimti.ai`, and `sales@chimti.ai` for commercial operations; `newsletter@chimti.ai`, `community@chimti.ai`, `marketing@chimti.ai`, and `careers@chimti.ai` for growth and hiring; `karan@chimti.ai`, `abhay@chimti.ai`, `amandeep@chimti.ai`, `praveen@chimti.ai`, and `gurnoor@chimti.ai` for named team mailboxes; and `noreply@chimti.ai` as a separate legacy/alternate no-reply mailbox if provisioned. Distribution lists must remain environment-configurable; passwords must not be stored in product documentation or tracked source files.
52. Chimti Admin App `Emails` is a unified multi-mailbox workspace for all approved Chimti-owned mailboxes. Accounts are config-source-of-truth records with stable IDs, so the same email address may be connected on multiple providers only when each provider has a distinct account ID. Outbound delivery uses mailbox-specific SMTP authentication; provider folders are discovered over secure IMAP; UID state is stored per account/folder; Inbox, Sent, Drafts, Junk, Trash, Archive, and custom folders sync incrementally; read/archive/trash/junk actions should be reflected on the provider mailbox where an IMAP source record exists; and new unread inbound messages should surface through the Admin App notification center. Email credentials remain deployment secrets, while mailbox names, roles, sync limits, provider hosts, and password env-var names stay environment-configurable.
53. Chimti Admin App `Emails` should follow familiar desktop mail-client information architecture while preserving the existing Chimti admin visual system: the active mailbox selector and All Mail/Inbox/Sent/Drafts/Junk/Trash/Archive/Custom/Failed folders stay in a left rail, the message list is the primary surface, no message opens automatically, reading a message uses a focused popup, and composing/replying uses a separate popup. On mobile, mailbox controls stack above the message list and all folders remain directly visible without horizontal page overflow.
54. The Admin App `Emails` page must render already-saved database emails immediately. IMAP refresh is a background job and must not block the visible message list, because multiple Chimti-owned mailboxes can make provider sync slow or partially unavailable. Initial page load should fetch accounts/messages from Chimti DB first, then refresh Inbox in the background; manual Sync can run a wider mailbox/folder refresh.
55. The Admin App `Emails` message list should behave like a normal mail client: newest emails first based on actual sent/received email time, account switching in the top action area, folder navigation in the left rail, paginated message rows with selectable page size, and formatted message reading for both plain text and HTML email bodies.
56. Email attachments should not be eagerly stored as binary files in Chimti. The sync process stores attachment metadata on the email record, and attachment open/download endpoints refetch the original IMAP message by account/folder/UID and attachment index when needed.
57. The Admin App must update email lists and email notifications without requiring a browser refresh. Saved database email polling should run frequently and on window focus/visibility return, while IMAP sync remains a separate background refresh. Notification polling should read Chimti DB first, dedupe by email message id, notify recent/new unread inbound emails, and only then run provider sync in the background so slow mailbox sync does not block live alerts.
58. Chimti email account configuration must allow provider-specific extra mailboxes without replacing the base Chimti-owned mailbox list. `CHIMTI_EMAIL_ACCOUNTS_EXTRA_JSON` appends extra accounts such as Google Workspace mailboxes, each with its own stable account id, provider, IMAP/SMTP host settings, and password env var. `jagjeet@chimti.ai` may be connected as a Google Workspace mailbox through this extra-account mechanism while credentials remain deployment secrets.
Pricing and Credits
1. Chimti public pricing should use four launch plan names: `Starter`, `Growth`, `Scale`, and `Enterprise`.
2. Launch pricing guidance: Starter is `₹4,999/store/month`; Growth is `₹9,999/store/month`; Scale is `₹19,999/store/month`; Enterprise is custom for franchise networks, aggregators, high-volume operators, or custom rollouts.
3. Subscription pricing covers platform access and included user/operation limits. Usage-heavy communication and AI work should remain prepaid through credits or wallet balance.
4. Credits should cover WhatsApp, SMS, AI replies, AI summaries, call handling, AI voice-agent minutes, and future image/OCR processing.
5. Subscription is billed per active store per month. For non-store business models, Chimti can map an active workshop, hub, pickup/delivery zone, franchise location, or brand/client workspace to a store-equivalent billing unit after workflow review.
6. Additional active stores should be charged at the selected plan's per-store rate. Communication and AI usage remains separate through prepaid credits or wallet balance.
7. Chimti offers a 14-day platform trial before paid subscription billing starts. The trial covers platform access; WhatsApp, SMS, calls, AI replies, AI summaries, voice-agent minutes, and other usage-heavy work still use prepaid credits or explicitly approved trial credits.
8. Chimti website pricing page should preserve the existing Mistral-style visual layout, cards, tabs, spacing, and interaction language; pricing changes should be content-only unless a redesign is explicitly requested.
9. Chimti website pricing page should use the right-side pricing toggle as `Monthly` / `Yearly` billing. Yearly launch pricing should show 10 months of billing for 12 months of access on a per-store basis: Starter `₹49,990/store/year`, Growth `₹99,990/store/year`, and Scale `₹1,99,990/store/year`, displayed as "2 months included."
10. The pricing-page billing toggle must be implemented as a Chimti-owned static control, not the inherited Mistral currency-switch custom element, because that component can hydrate into a broken state and show only `Yearly` while prices remain monthly.
11. Public pricing URLs may persist the billing state with `?billing=yearly`; `/pricing` without that query should default back to `Monthly`.
12. Chimti website pricing page should keep the reference-style comparison and FAQ presentation: stable Monthly/Yearly segmented control with no delayed color transition, grouped feature-comparison rows under large section headings, compact plan CTAs in the comparison header, and a two-column FAQ layout with the large heading on the left and accordion rows on the right.
Deployment
1. Chimti development deployments live in Coolify under the `Otlu` project, `development` environment, on the Otlu server.
2. Every Chimti repo should have a deployable service record in that Coolify development environment so repo status can be verified from one place.
3. Current development service domains should use the `chimti-*.otlu.io` pattern:
- API: `https://chimti-api.otlu.io`
- User app: `https://chimti-user-app.otlu.io`
- Admin app: `https://chimti-admin-app.otlu.io`
- Website: `https://chimti-website.otlu.io`
- Customer app: `https://chimti-customer-app.otlu.io`
- User mobile web: `https://chimti-user-mobile-app.otlu.io`
- Docs: `https://chimti-docs.otlu.io`
- Print agent dev service: `https://chimti-print-agent.otlu.io`
4. The website deployment tracking must use the `development` branch for development environments and the `production` branch for production environments. The `main` branch is deprecated and removed.
5. The deployed print-agent service is only a development/reference service. Real printing still requires the local print agent installed on the store desktop connected to the USB printer.
6. Admin and user web apps must set their app variant explicitly at build/deploy time. The admin app must build with `VITE_APP_VARIANT=admin`; if this is missing, it can render user/workspace login copy and user-facing access rules on the admin domain. The admin app repo should default to admin mode as a fallback.
7. The website Coolify service should prefer Dockerfile mode (configured as a multi-stage Next.js standalone container). The repo also carries a Nixpacks fallback that runs `npm run build` as a validation step and starts the standalone Next.js server with `node .next/standalone/server.js`.
8. The website Coolify service must expose/proxy internal port `3000`, not `80`. Its healthcheck must use `GET http://127.0.0.1:3000/` (the root path, returning HTTP 200 OK); using `/health` returns 404 on the static Next.js setup and causes rollback. The runner stage of the Dockerfile must include `curl` (`apk add --no-cache curl`) for container health checks, and bind using `ENV HOSTNAME="0.0.0.0"`.
9. The pre-launch public website lives in its own repo, `otlugroup/chimti-pre-launch-landing-page`, and deploys from `development` or `production` branches to `https://chimti-pre-launch.otlu.io`. It is a homepage-only copy of the website and uses single-page fallback routing. The main `otlugroup/chimti-website` repo contains the full public website.
10. Production Chimti public/domain mapping should use `https://chimti.ai` for the pre-launch/public website, `https://app.chimti.ai` for the client-facing User App, `https://api.chimti.ai` for the backend API, and `https://admin.chimti.ai` for the Chimti/Otlu admin app. The `www.chimti.ai` host should redirect to `https://chimti.ai`.
11. Production `chimti.ai` domains must be deployed as separate Coolify applications under the `Otlu` project `production` environment. Do not move or overwrite the existing `development` environment apps when cutting over a production domain.
12. The canonical login entry URLs are the root app domains: `https://app.chimti.ai` for client users and `https://admin.chimti.ai` for platform admins. Public links should not include `/login`; if `/login` is opened while signed out, the app should replace it with `/` and show the same login screen.
13. The `chimti-*.otlu.io` domains are development/staging domains and should remain attached to the Coolify `development` environment. Public links, form metadata, WhatsApp/Meta app settings, sitemap URLs, and customer-facing copy should use the `chimti.ai` production domains.
14. Production API deployments must allow CORS/origins from `https://chimti.ai`, `https://www.chimti.ai`, `https://app.chimti.ai`, and `https://admin.chimti.ai`. Development API deployments should allow the matching `chimti-*.otlu.io` origins. Public lead forms should route by hostname: `chimti.ai` to `https://api.chimti.ai/v1/public/leads`, and `*.otlu.io` development hosts to `https://chimti-api.otlu.io/v1/public/leads`.
15. Future optional production subdomains should follow the same pattern: `customer.chimti.ai` for the Customer App, `docs.chimti.ai` for public documentation if ever exposed, and `print.chimti.ai` only for a central print-agent management service, not for local USB print-agent runtime.
16. Admin and user app login is email-first and supports both password login and an emailed one-time code. The initial form shows only email; once an email is entered, password login and `Log in with one-time code` become available. Login codes are six digits, expire after 10 minutes, are single-use, are limited to five verification attempts, and create the same backend session and role/scope enforcement as password login.
17. Login security is a product-level requirement. Admin/user login endpoints must keep route-level rate limits plus DB-backed abuse tracking by email+IP for password login, OTP request, and OTP verification. Repeated failed attempts should lock the email+IP pair for a short window, OTP request responses should remain generic to avoid account enumeration, and proxy/body-size limits should be configurable through API environment variables.
18. Admin and user app idle auto-logout is a per-user preference stored at `uiPreferences.session.autoLogoutEnabled`. It defaults to enabled, should be configurable from Profile > Security, and when disabled the frontend must not start the 30-minute inactivity warning / 2-minute logout timer for that user. Token/session expiry and explicit logout still apply.
19. Chimti ecosystem file storage should not use app/server folders or long-lived database base64 blobs as the primary file store. Uploaded operational files from admin, user, mobile, and future customer apps should go through the backend file-storage layer to Google Drive through the approved Apps Script connector. The database remains the system of record for business data and stores only file metadata, Drive ids/links, audit context, and signed/proxied access references. Current Drive-backed file types include order item photos, staff documents, user avatars, and brand/platform logos; old database `imageDataUrl` files are legacy-readable only. Canonical Drive paths are `Chimti Files/platform/...` for Chimti-owned/user/workspace files and `Chimti Files/brands/{brandId}/stores/{storeId}/...` for brand/store operational files. Reserved future buckets include client contracts/KYC/onboarding, call recordings and voice notes, invoice/receipt PDFs, AI-generated reports/summaries, and print/tag/template files.
20. Chimti Admin should include an internal read-only Drive Files module for founder/internal admins to inspect the Google Drive storage folder structure, file metadata, and Drive links. The module should never expose storage secrets and should not provide destructive file operations unless an explicit audited workflow is designed.
21. The parent company and legal owner/developer of Chimti is **Oteloo Ventures Private Limited** (brand: **OTLU**). All legal documents (Privacy, Terms, Refund policies) and email signatures must explicitly reference **Oteloo Ventures Private Limited**. The website uses `.ai` exclusively for domains (e.g. `chimti.ai`, `jagjeet@chimti.ai`) and must never use `.com` domains. The `/contact` page form is purely for general inquiries (Action: "Send message", API Payload: "contact-inquiry"); demo requests are distinct B2B actions that will live on a separate page.
Printing and Tags
Chimti uses article tags for garment tracking.
Current tag printer assumptions:
- TSC 244 Pro style USB printer.
- Waterproof tafetta roll.
- 75mm roll was tested.
- Design should assume 55mm usable tag width.
Browser limitation:
- Deployed web app cannot directly print to USB printer.
- A local print agent must run on every desktop computer that has the USB printer connected.
Tag content:
- QR code.
- Useful/random part of Order ID.
- Service.
- Special instructions.
- Article sequence such as 1/3, 2/3, 3/3.
- Item/category detail.
User App UI Rules
1. Sidebar modules should load only after module configuration is known, so hidden/planned modules do not flash before disappearing.
2. Admin app should not have menu customization.
3. User app menu customization should save only when the user clicks Save.
4. All list/register pages should show 10 rows per page.
5. Popups should be centered, content-sized, Esc-closeable, and should warn once if unsaved data exists.
6. Audit should not show in user app.
7. Notes are append-only and cannot be edited/deleted.
8. Breadcrumbs should appear on detail pages.
9. Details pages should use tabs that switch content, not scroll anchors.
10. Details pages should avoid list counters at the top.
11. Admin and user app list/module pages should avoid top counter/stat strips. Dashboards and detail overviews may still use metrics where the page purpose is summary/analysis.
12. Order item photos are item-level proof records and must be uploaded/removed through dedicated order-item photo endpoints, not through the general order item patch flow. User app should render item photos as an image-first proof gallery where the photo itself is the visible content; filenames, size, timestamps, and storage metadata should not dominate the Photos tab. While photos upload, the user app should show a bottom-right upload progress toast and immediately show local image previews; after upload completes, temporary previews should be replaced by saved photo records without forcing a refresh. Clicking a photo should open an in-app preview modal with previous/next controls instead of opening a browser tab. Users should be able to download one item photo from the tile or preview modal and download all uploaded item photos from the Photos tab. Compact overlay actions such as delete/open/download are allowed. New order item photos must be stored in Google Drive via the backend storage layer; DB base64 is legacy-only for old records.
New Chat Handoff
A fuller continuation summary was saved at:
`/Users/jagjeetsinghsethi/Downloads/Code/Chimti/chimti-docs/handoffs/2026-05-28-new-chat-handoff.md`