Vollständige technische Spezifikation aller Directus Tabellen, Fremdschlüssel und Indizes

Datenbank-Schema & Relationen

Die Datenhaltung erfolgt in PostgreSQL, abstrahiert und verwaltet über Directus Collections.

Entity-Relationship Diagramm (ERD)

erDiagram
    series ||--o{ books : contains
    series ||--o{ lore_entities : scopes
    books ||--o{ chapters : divides
    chapters ||--o{ scenes : contains
    lore_entities ||--o{ lore_states : tracks
    chapters ||--o{ lore_states : "valid from"
    style_templates ||--o{ reference_images : includes
    style_templates ||--o{ series : "default style"

    series {
        uuid id PK
        uuid author_id FK
        uuid template_id FK
        varchar title
        text description
        jsonb universe_rules
    }

    books {
        uuid id PK
        uuid series_id FK
        uuid author_id FK
        varchar title
        varchar subtitle
        int sequence_number
        varchar language
        varchar status
    }

    chapters {
        uuid id PK
        uuid book_id FK
        int chapter_number
        varchar title
        text synopsis
    }

    scenes {
        uuid id PK
        uuid chapter_id FK
        int scene_number
        varchar title
        text raw_text
        text summary
        text prompt
    }

    lore_entities {
        uuid id PK
        uuid series_id FK
        varchar type "character|location|faction|object|rule"
        varchar name
        jsonb static_traits
    }

    lore_states {
        uuid id PK
        uuid entity_id FK
        uuid valid_from_chapter_id FK
        uuid source_scene_id FK
        jsonb state_patch
        timestamp created_at
    }

    style_templates {
        uuid id PK
        varchar slug UK
        varchar type "illustration|text|animation|audio"
        varchar name
        text description
        text prompt_modifier
        text base_system_prompt
        jsonb tags
        jsonb metadata
        boolean is_public
    }

Bitemporale Snapshot-Query-Logik

Wenn eine Szene in Kapitel $C$ für eine Entität $E$ generiert wird, führt der Service folgende Abfrage-Logik aus:

Stamm-Entität laden:

SELECT * FROM lore_entities WHERE id = :entityId;

Relevante State-Patches chronologisch ermitteln: Es werden alle State-Patches geladen, die:

Entweder global gültig sind (valid_from_chapter_id IS NULL),
Oder deren Kapitel-Sequenznummer $\le$ der Sequenznummer des aktuellen Kapitels $C$ ist.

SELECT ls.* FROM lore_states ls
LEFT JOIN chapters c ON ls.valid_from_chapter_id = c.id
WHERE ls.entity_id = :entityId
  AND (c.chapter_number <= :currentChapterNumber OR ls.valid_from_chapter_id IS NULL)
ORDER BY c.chapter_number ASC, ls.created_at ASC;

In-Memory Deep Merge (Patching): Das Basis-Objekt static_traits wird sequenziell mit den state_patch-Objekten überlagert:
```
ActiveState = deepMerge(static_traits, patch_1, patch_2, ..., patch_n)
```

Datenbank-Schema & Relationen

Datenbank-Schema & Relationen

Entity-Relationship Diagramm (ERD)

Bitemporale Snapshot-Query-Logik

On this page