SONAN DIGITAL RMS — Context — SONAN DIGITAL Docs

What Is SONAN DIGITAL RMS?

Repair & Retail Management System — the point-of-sale, repair-ticket, inventory, customer, employee, payments and reporting platform that runs the SONAN TECH stores (Willis, Oak Ridge North, plus the Test Lab), built as a multi-tenant SaaS so other repair / retail businesses can be onboarded as organizations. Since 2026-09 it also receives website leads from sonantech.com.

ℹ️

Source of truth lives in the repo

The living documents are in E:\xAI-Projects\sonan-digital-rms\docs\ — SESSION_HANDOFF.md (development progress), release-notes.md, known-limitations.md, architecture/*.md, plans/rms-saas-program-plan.md, system-setup/*.md. This portal page is the orientation summary; read those before development.

Repo & Folder

Item	Value
Local folder	`E:\xAI-Projects\sonan-digital-rms\` (npm)
GitHub	`https://github.com/sonantechai/sonan-digital-rms` (private)
Branches	`main` = production (frozen until the pre-ORN cutover) · `saas` = all development since 2026-09-13
Hosting	Vercel project `sonan-digital-rms` — Production from `main`, Preview from `saas`
Database	Supabase — `sonan-digital-rms-prod` (production, untouched) and `sonan-digital-rms-dev` (restored copy; every migration is proven on a local lab, then dev, never first on prod)
Sibling repo	`E:\xAI-Projects\sonan-tech-shopify` — the sonantech.com storefront theme (sends leads to RMS; never mix theme work into RMS)

Live URLs

Environment	URL	Notes
Production	rms.sonandigital.com	Pre-SaaS build until cutover. Do not test here.
Dev preview	`sonan-digital-rms-git-saas-sonan-digital.vercel.app`	Team testing; e-mail / SMS redirected to the team inbox; Stripe test mode; mock card tender available
In-app docs	`/help`, `/docs/product-guide.html`, `/docs/smoke-tests.html`, `/docs/test-plan.html`	Served only to signed-in RMS users; Help → Test plan is the tester guide
QMS	qms.sonandigital.com	Application APP-012 holds the test library (`docs/qms/*.json` imports there)

Tech Stack

Layer	Technology
App	Next.js 16 App Router, TypeScript strict, Tailwind, server actions
Data	Supabase Postgres with row-level security, definer RPCs owned by `rms_definer`, `enforce_org_write()` trigger, `tenancy_invariant_violations` view (must be empty)
Auth	Supabase Auth (shared by all tenants); organization membership decides the session role; job roles + permissions checked in UI, server actions and SQL
Integrations	Stripe (Terminal / Checkout), Shopify (orders, refunds, stock, publish), Resend, Twilio, OpenAI / Anthropic (assistant) — credentials per organization in Settings → Integrations, Vercel env only as fallback for tenant #1
Tests	Vitest (1,900+), Playwright e2e (module matrix, full-app journeys, two-organization isolation), SQL suites under `supabase/tests/` (isolation, cross-store, approvals, refunds, tenders, Shopify, product layer, one-ticket-per-checkout, build-out, employee activity, location kind, inbound leads), QMS library, manual smoke + test plan

Modules

Dashboard · POS (repairs + retail, split tenders, mock card for training) · Tickets & intake · Customers & devices · Estimates & quotes · Invoices, payments, refunds & credit memos · Registers (shifts, day close, reconciliation) · Inventory, vendor orders, trade-in, RMA · Promotions · Employees (invites, roles, activity, time clock, payroll, commissions) · Expenses · Store build-out · Leads (inbound website / partner sources, first-come claim, response target) · Reports (sales, P&L, tickets, leads …) · Settings (business profile, industry packs, modules, locations, payments, integrations, notifications, catalog, approvals, audit log) · RMS Assistant · Help center.

Tenancy model (read before touching data)

Every business table carries org_id; RLS + write trigger + definer-RPC ownership; unique constraints include org_id; storage paths are prefixed by org.
Stores inside one organization follow an owner-set cross-store policy (isolated / need-to-know / open); restricted employee actions go through approvals, never a shared PIN.
Public endpoints (webhooks, inbound leads) resolve the organization from the URL and use an org-bound service client — a key from org A can never touch org B.
Non-secret configuration is database first (company settings, org profile, integrations), Vercel env second. Secrets stay in Vercel / Supabase.

Working rules (from `AGENTS.md`)

Agents never run git in the repo; the owner commits and pushes from Windows with the command block the agent provides (npm run ci before every push).
Never touch the production database; migrations are proven on the lab, then applied on dev by the owner with the matching SQL suite pasted.
No browser alert / confirm — AppDialog / ConfirmDialog; dialogs close only by explicit buttons.
Nothing configurable is hard-coded; settings UI + database.
Every checkpoint updates: smoke tests, product guide (version + history), release notes, limitations, user guides + in-app help, QMS library (regenerate the test plan), session handoff.

How to Deploy

cd /d E:\xAI-Projects\sonan-digital-rms
git add <files>
git commit -m "..." 
npm run ci
git push origin saas          # Vercel builds the dev preview

Database changes: Supabase → dev project → SQL editor → run the migration file, then paste the matching supabase/tests/*.sql suite and expect … SUITE PASSED; select count(*) from tenancy_invariant_violations must be 0. Production follows docs/system-setup/14-saas-cutover.md (24 migrations, preflight 24 × APPLIED, then merge saas → main).

SONAN DIGITAL RMS — Context