tibi-docs/src/content/docs/reference/schemas.md at 1897bb50d95cba282643babf0e4a9cf188b91483

cms/tibi-docs

0 Fork 0

Files

T

Deploy tibi-docs / build-and-deploy (push) Failing after 38s

Details

Doku-Vollausbau: 62 Seiten (Projekt/Admin/Anwender/Referenz), Hook-Referenz mit Signaturen, Corporate-Screenshots, Coverage-Inventar

- Einstieg: Schnellstart + Neues Projekt aus Starter-Skill, Was-ist-Tibi mit Backend/Website-Trennung
- Projekt: Sammlungen, Felder, Abfragen, Rechte, Hooks, Dateien, i18n, Suche, SSR, Pagebuilder, Jobs, Audit, Deploy, LLM, MCP
- Hook-Referenz: 66 Symbole mit Signatur + Beispiel + Fehlerfall (5 Kapitel)
- Admin: Ansichten, Editor, Medien, Exporte, Aktionen, Rechte, KI, Setup, Customizing
- Anwender: 11 Anleitungen im professionellen Du-Ton, 30 Corporate-Screenshots
- Referenz: Schemas, Token-Köpfe, Fehlerbilder, Shortcuts, OpenAPI-Platzhalter
- ADR-0001 bis 0003, Coverage-Skript (282 Items) + Map, Plan-Dateien

2026-10-16 22:49:07 +00:00

3.3 KiB

Raw Blame History

title, description

title	description
Schemas als Quelle	Welche tibi-types-Schemas wofür gelten und wie du sie liest.

import { Aside, Tabs, TabItem } from '@astrojs/starlight/components';

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 16 Dateien (nicht 15, wie ältere Docs behaupten):

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	—

Lesart

# 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.

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.

Text-Diagramm: Wo was geprüft wird

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 4c55f82 2026-10-12 (tibi-types)