woon-woo/original-otomotiv

1. Overall shape: this repo is a three-surface system built around a single Supabase backend. The surfaces are: the public/admin web app in apps/web, the internal iOS/macOS-style terminal app in apps/ogot, and the shared database/auth/storage layer in supabase.

2. Public + admin web app (apps/web): Next.js App Router is used for both the public storefront and the protected admin panel. The site has public routes for the homepage, about page, product/part listings, and store pages, while the panel lives under /panel and is split into many domain areas such as catalog, products, members, suppliers, records, deletion requests, and store management.

3. Authentication and session flow on the web: login and account-recovery flows are separated into dedicated routes and server actions (/giris, /sifremi-unuttum, /sifre-belirle, /auth/confirm). There is also a multi-factor authentication section under /panel/mfa, which includes setup, email challenge/verification, and verification display screens. The web app uses Supabase client/server/admin helpers to enforce this boundary.

4. Protected operations in the web panel: the protected layout under /panel/(protected) indicates that most mutation-heavy behavior is server-side and gated. Each major admin area has its own actions.ts, so form submissions and record changes happen through server actions rather than direct client-side API calls. There is also a dedicated export route for Sahibinden integration, which matches the repository’s “Sahibinden taxonomy 1:1” model.

5. Frontend domain model: the public catalog and admin panel are centered on automotive inventory concepts: parts/products, brands, categories, lists, stores, members, suppliers, shelves, depots, and vehicle filters. The presence of CatalogUI, VehicleFilter, ProductRow, and rich-text/photo components suggests the UI is built around structured product metadata plus media and search/filtering.

6. Backend data layer (supabase): Supabase is the system of record and contains the schema evolution for auth profiles, audit logging, catalog data, vehicles, inventory, suppliers/printing, multi-tenant stores, store owner privacy, account deletion, email 2FA, category trees/sorting, and denormalized storefront views. RLS is a core architectural boundary: the README states all tables use RLS, with soft delete and audit logs everywhere important.

7. How data is exposed from the backend: the migration set shows a deliberate split between authoritative tables and derived/public-facing shapes. That includes denormalized storefront data, category trees, store-only anonymous columns, and RPCs for read/search operations. This is a strong signal that the web and OGOT clients consume curated views and RPCs rather than raw tables for many paths.

8. Internal staff app (apps/ogot): OGOT is a separate Swift/SwiftUI app for internal warehouse or counter workflows. Its screens suggest login, depot management, product browsing, shelf/location operations, QR scanning, label printing, and add-product flows. It is not just a thin web wrapper; it is its own client with native UI and device capabilities.

9. Printing subsystem (NiimbotKit): this Swift package isolates Niimbot B1 label printing. The package has packet/command/printer abstractions plus QR rendering and bitmap conversion, with separate debug and verification executables and tests. In architecture terms, it is a device-driver-like boundary used by OGOT for QR label output over Bluetooth/CoreBluetooth.

10. Operational integrations: the product flow avoids online checkout; the purchase path is a WhatsApp handoff, reflected by whatsapp.ts and static wa.me links. There are also support utilities for email, thumbnails, sanitization, logging, and anti-bot protection via Turnstile, which all sit around the core catalog/auth flows.

11. Security and governance: the repo emphasizes admin MFA, audit history, account deletion, and store-owner privacy. The combination of RLS, login tracking, audit tables, and soft delete means the system is designed for traceability and controlled access rather than a simple CRUD app.

12. Repo boundaries for a diagram: draw the web app and OGOT app as separate clients, both talking to the same Supabase backend; draw NiimbotKit as a native-printing submodule only used by OGOT; and show public storefront reads separated from protected admin mutations by auth/RLS/server-actions boundaries. The most important shared domain is catalog/inventory/store management, with web focused on public commerce/admin and OGOT focused on in-person operations and label printing.