Files
lunarfront-app/CLAUDE.md
Ryan Moon 9400828f62 Rename Forte to LunarFront, generalize for any small business
Rebrand from Forte (music-store-specific) to LunarFront (any small business):
- Package namespace @forte/* → @lunarfront/*
- Database forte/forte_test → lunarfront/lunarfront_test
- Docker containers, volumes, connection strings
- UI branding, localStorage keys, test emails
- All documentation and planning docs

Generalize music-specific terminology:
- instrumentDescription → itemDescription
- instrumentCount → itemCount
- instrumentType → itemCategory (on service templates)
- New migration 0027_generalize_terminology for column renames
- Seed data updated with generic examples
- RBAC descriptions updated
2026-03-30 08:51:54 -05:00

3.7 KiB

LunarFront — Project Conventions

App

  • Name: LunarFront
  • Purpose: Small business management platform (POS, inventory, rentals, scheduling, repairs, accounting)
  • Company: Lunarfront Tech LLC

Tech Stack

  • Runtime: Bun
  • Language: TypeScript (strict mode, end-to-end)
  • API: Fastify with Pino JSON logging
  • ORM: Drizzle ORM (PostgreSQL 16)
  • Validation: Zod (shared schemas between frontend and backend)
  • Queue: BullMQ (Valkey-backed)
  • Cache: Valkey 8 (Redis-compatible fork)
  • Monorepo: Turborepo with Bun workspaces
  • Testing: bun test (built-in, uses bun:test imports)
  • Linting: ESLint 9 flat config + Prettier

Package Namespace

  • @lunarfront/shared — types, Zod schemas, business logic, utils
  • @lunarfront/backend — Fastify API server

Database

  • Dev: lunarfront on localhost:5432
  • Test: lunarfront_test on localhost:5432
  • Multi-tenant: company_id (uuid FK) on all domain tables for tenant isolation
  • location_id (uuid FK) on tables that need per-location scoping (inventory, transactions, drawer)
  • Migrations via Drizzle Kit (bunx drizzle-kit generate, bunx drizzle-kit migrate)

Key Entity Names

  • account — billing entity (family, individual, or business)
  • member — individual person on an account (NOT "student" — renamed to support multiple adults)
  • member.is_minor — derived from date_of_birth, controls consent/portal rules

Commands

  • bun run dev — start all packages in dev mode
  • bun run test — run all tests
  • bun run lint — lint all packages
  • bun run format — format all files with Prettier

API Conventions

  • Every endpoint that returns a list must support pagination, search, and sorting — no exceptions unless the endpoint is explicitly a lightweight lookup (see below)
    • ?page=1&limit=25 — pagination (default: page 1, 25 per page, max 100)
    • ?q=search+term — full-text search across relevant columns
    • ?sort=name&order=asc — sorting by field name, asc or desc
  • List responses always return { data: [...], pagination: { page, limit, total, totalPages } }
  • Search and filtering is ALWAYS server-side, never client-side
  • Use PaginationSchema from @lunarfront/shared/schemas to parse query params
  • Use pagination helpers from packages/backend/src/utils/pagination.ts
  • Lookup endpoints (e.g., /roles/all, /statuses/all) are the exception — these return a flat unpaginated list for populating dropdowns/selects. Use a /all suffix to distinguish from the paginated list endpoint for the same resource.

Frontend Table Conventions

  • Every table that displays data must use the shared DataTable component (components/shared/data-table.tsx)
  • All tables must support: search (via ?q=), sortable columns, and server-side pagination
  • Use the usePagination() hook (hooks/use-pagination.ts) — it manages page, search, and sort state via URL params
  • All data columns that make sense to sort by should be sortable (e.g., name, email, date, status) — don't limit to just 1-2 columns
  • Sub-resource tables (e.g., members within an account, payment methods) follow the same rules — use DataTable with pagination, not raw <Table> with unbounded queries
  • Loading states should use skeleton loading (built into DataTable), not plain "Loading..." text

Conventions

  • Shared Zod schemas are the single source of truth for validation (used on both frontend and backend)
  • Business logic lives in @lunarfront/shared, not in individual app packages
  • API routes are thin — validate with Zod, call a service, return result
  • All financial events must be auditable (append-only audit records)
  • JSON structured logging with request IDs on every log line