entity-model

Entity Model

Instructions

Create or update the entity model at docs/entity_model.md based on docs/requirements.md. The document contains an ER diagram and attribute tables.

DO NOT

• Add attributes/columns to the Mermaid diagram
• Write prose descriptions like "Key attributes: name, email..."
• Create a "Relationships" table

Document Structure

# Entity Model

## Entity Relationship Diagram

```mermaid
erDiagram
    ROOM_TYPE ||--o{ ROOM : "categorizes"
    GUEST ||--o{ RESERVATION : "makes"

ENTITY_NAME

One sentence describing the entity.

Required Format for Each Entity

Every entity MUST have:

1. A ### heading with the entity name in UPPERCASE (UPPER_SNAKE_CASE, e.g. ### ROOM_TYPE — never ### Room Type or ## Entity: Room Type)
2. One sentence description
3. An attribute table with exactly these 5 columns in this order: Attribute, Description, Data Type, Length/Precision, Validation Rules

Example Entity

ROOM_TYPE

Defines categories of rooms with shared characteristics.

Mermaid Diagram Rules

• Show entity names and relationships ONLY
• NO attributes inside entity blocks
• Use relationship syntax: ENTITY_A ||--o{ ENTITY_B : "relationship"

Data Types (use only these)

The Data Type column must use exactly these values — never SQL or ORM types such as VARCHAR, TEXT, CHAR, bigint, numeric, serial, smallint, UUID, Timestamp, or Enum:

The Length/Precision column holds the bare value (e.g. 10,2) — never a type expression like DECIMAL(10,2).

The seven types are the complete list. Binary content (a document, an image) has no type of its own: it is a String with - as Length/Precision and a Description that begins with Binary content: (Binary content: the signed contract as PDF); its Validation Rules are Not Null or Optional as for any field. The migration skill of every stack maps exactly that combination to a binary column, and the persistence code follows the column.

Validation Rules (use only these values)

Compose every Validation Rules cell from this vocabulary, using the exact wording — never a prose description, and never an empty cell, dash, or "N/A":

Examples: an email attribute is Not Null, Format: Email — never "must be a valid email address". A status attribute with a fixed set of states is Not Null, Values: Pending, Active, Completed, Cancelled — never "must be one of Pending, Active, Completed, Cancelled".

This table is a closed set: every Validation Rules cell is exactly one row from it. Do not combine rows into new patterns (Not Null, Unique, Format: Email is invalid — pick the one rule that matters most, here Not Null, Format: Email), and never write Min: without its matching Max: (Not Null, Min: 0 alone is invalid — use Not Null, Min: 0, Max: <upper bound> or just Not Null).

The same tables are available in references/REFERENCE.md. The path is relative to the folder containing this SKILL.md, not to the project root.

Multi-Column Constraints

If validation spans multiple columns, add a #### Constraints heading below the entity's attribute table and list each constraint as a bullet, one rule per bullet:

#### Constraints