Reservations → Service form fields

In the admin UI (Services/page.tsx), Name, Category, and Service Type are all just text inputs — the user types anything. No dropdown, no validation against any lookup table.

Entity Types → Categories → Service Structure

From schema.sql:

CREATE TABLE entity_types (entity_type TEXT PRIMARY KEY, ...);
CREATE TABLE categories (
  id TEXT PRIMARY KEY,
  entity_type TEXT NOT NULL REFERENCES entity_types(entity_type) ON DELETE CASCADE,
  name TEXT NOT NULL,
  ...
  UNIQUE(entity_type, name)
);

•  
•  
•  
• entity_types — a single-row-per-type table (e.g. auto-shop, bookkeeper, repair-shop). These are top-level business verticals used to organize content across the whole admin (videos, posts, pages, etc.).
• categories — a child of entity_types via FK. Each category belongs to exactly one entity type and is unique per type. E.g. under auto-shop: Oil Change, Brake Service, Tire Rotation… (seeded in seed_entity_types_categories.sql).
• These are the managed, validated taxonomies surfaced in "Settings → Entity Types" and "Settings → Categories", and in the Editor's CategoryManager modal.

  There is currently no "service" entity type tied to reservations — the seeded types (auto-shop, bookkeeper, repair-shop) are for content organization, not booking.

  The Key Difference

  The two are completely separate systems today:

   

   

   

• Data source: The Services page stores directly into reservation_services with free text. Entity Types/Categories are separate tables (entity_types, categories) that are not referenced anywhere in reservation_services — there is no FK and no query join.

•  

•  

• Validation: Service category/service_type accept any string. Entity Type/Category are validated, unique-per-type, CRUD-managed.

•  

•  

• Semantics:

•  

•  

• In Reservations, "Category" is a loose grouping label for a bookable service (e.g. "Maintenance", "Detailing").

•  

•  

• In Entity Types, "Category" only exists within an entity type, and "Service" isn't a field at all — it's just an example of what a business in an auto-shop type might offer.

  Where They Could Connect

  If you want the Services page's "Category" (and possibly "Service Type") to be driven by the Entity Type/Category taxonomy instead of free text, that would be a schema + UI + API change:

   

• Add a nullable FK column like category_id TEXT REFERENCES categories(id) (or entity_type + category_id) to reservation_services.

•  

•  

• Change the Services form's Category field from text input to a dropdown populated from /admin/categories?entity_type=... (or a reservation entity type).

•  

•  

• Keep service_type as either free text or map it to something else.

  Do you want me to plan that integration (making Service Category a managed dropdown backed by the categories table), or did you want the explanation only? If you want the integration, let me know what the "service" entity type should be called (e.g. add a reservation entity type, or reuse auto-shop) and whether "Service Type" should also become a controlled list.

•  

•  

•  

•  

•  

•  

•  

•  

•  

   

   

   

•  

•  

   

   

   

   

•  

•  

•  

•  

•  

•  

•  

•  

•  

•  

•  

•  

•