Schemas als Quelle

Deine api/*.yml-Dateien sind durch JSON-Schemas geprüft. Die Schemas liegen in tibi-types/schemas/config/. Jede YML-Datei verweist oben per $schema-Zeile auf ihr Schema.

Schema-Liste

Das Verzeichnis enthält 17 Dateien:

Schema	Gilt für	Pflichtfelder
project.schema.json	api/config.yml	namespace
collection.schema.json	api/collections/*.yml	name, permissions
field.schema.json	einzelnes Feld	Typ-abhängig
field-list.schema.json	Feld-Listen	—
field-meta.schema.json	meta: an Feldern	keine (alle optional)
collection-meta.schema.json	meta: an Collections	keine (alle optional)
permissions.schema.json	permissions:-Block	public, user
hooks.schema.json	hooks:-Block	keine (get, post, put, delete, audit optional)
job.schema.json	Jobs in config.yml	type, file
action.schema.json	Actions in config.yml	name
asset.schema.json	Assets in config.yml	name, path
image-filter.schema.json	imageFilter: an Collections	—
projections.schema.json	projections:-Block	—
snapshot.schema.json	Snapshots in config.yml	name
openapi.schema.json	OpenAPI-Metadaten je Collection	keine
defs.schema.json	nur $ref-Bausteine, kein eigenes Ziel	—
embedding.schema.json	embedding: in der Server-config.yml	keine (Provider und Gruppen sind optional)

Vollständige Property-Matrix

Jede Property jedes Schemas — Typ, Pflicht, Vorgabe und Beschreibung — steht in der Schema-Properties-Referenz. Diese Seite hier bleibt der Einstieg: welches Schema wofür gilt und wie du die Dateien verdrahtest. Die Property-Tabellen dort erzeugt npm run gen:schemas direkt aus den JSON-Schemas; nichts davon ist von Hand abgeschrieben.

Dateinamen und Auflösung

• Dein Projekt liegt unter api/: api/config.yml (Schema project.schema.json) plus api/collections/*.yml (je Datei collection.schema.json).
• Viele Stellen akzeptieren Dateipfad oder Inline-Objekt: In der Typ-Spalte der Property-Matrix erkennst du das an string oder … — etwa bei collections, fields, permissions, hooks oder meta. Ein string verweist auf eine weitere Datei (z. B. eine Collection- oder Hook-Datei), ein Objekt steht direkt an Ort und Stelle.
• Die Reihenfolge der Auflösung ist dabei immer gleich: Datei lesen, $schema-Form prüfen, dann Referenzen (string-Pfade, $ref-Bausteine aus defs.schema.json) auflösen.

Lesart

Kopfzeile

api/collections/content.yml

# yaml-language-server: $schema=../../tibi-types/schemas/config/collection.schema.json
name: content
permissions:
  public:
    methods:
      get: true

Der Editor prüft live gegen das Schema. Tippfehler in Schlüsseln meldet er sofort.

Pflicht gegen Code prüfen

Das Schema prüft die Form. Ob der Server die Werte so versteht, steht im Code:

• collection.schema.json verlangt permissions — was public und user dürfen, entscheidet internal/models/permission.go im tibi-server.
• field.schema.json kennt Typen wie string, number, date — was davon wirklich validiert wird, steht in internal/controller/validator.go.
• project.schema.json kennt admin.tokens — was diese Tokens dürfen, steht in internal/config/admin_token.go.

Schema deckt nicht alles ab

Ein grünes Schema heißt nur: die Datei ist wohlgeformt. Falsche Token-Namen oder fehlende Berechtigungen meldet erst der Server zur Laufzeit. Lies dazu die Seiten zu Token-Köpfen und Fehlerbildern.

Text-Diagramm: Wo was geprüft wird

Prüfebenen im Überblick

api/config.yml ──$schema──▶ project.schema.json (Form)
       │
       ▼
tibi-server beim Reload (Bedeutung)
  ├── permission.go       → wer darf was?
  ├── validator.go        → ist der Datensatz gültig?
  └── admin_token.go      → welches Token gilt wofür?

Nächste Schritte

• Lege ein neues Projekt an: Einstieg Neues Projekt.
• Schlage einen Hook-Kontext nach: Hook-Kontexte.
• Verstehe Fehlermeldungen: Fehlerbilder.

Verifiziert am 3bf8055 2026-10-17 (tibi-types, 17 JSON-Schemas einschließlich embedding.schema.json)