apairon
1897bb50d9
Deploy tibi-docs / build-and-deploy (push) Failing after 38s
- 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
60 lines
4.4 KiB
Markdown
60 lines
4.4 KiB
Markdown
# AGENTS.md — Tibi Doku
|
|
|
|
Regeln für alle Agenten, die an dieser Doku, am Tibi-Server / tibi-admin oder an Projekten aus `tibi-svelte-starter` arbeiten.
|
|
|
|
## 0. Benennung und Blickwinkel
|
|
|
|
- Wir nennen es **tibi-server** und **tibi-admin** (Release Nova, Repo `tibi-admin-nova`). Alte `tibi-admin`-Repos werden ignoriert.
|
|
- Backend = tibi-server (API) + tibi-admin (Bedienoberfläche). Projekte sind eigenständige Websites/Shops/Intranet aus `tibi-svelte-starter`.
|
|
- Entwickler-Doku beschreibt **Projektnutzung** (klonen, konfigurieren, bauen), keine Tibi-Core-Entwicklung.
|
|
|
|
## 1. Grundsatz
|
|
|
|
- **Single Source:** Code-Nähe schlägt Doku-Kopie. Details stehen in `tibi-server/docs/` bzw. `tibi-admin-nova/docs/` (Doku-Begriff: **tibi-admin**), diese Seite rendert nur. **Code schlägt Doku:** Bestandsdoku gilt als Behauptung, Quelle ist der Code (`internal/*`, `tibi-types/schemas`, `frontend/src/lib`, Tests, Test-Pläne).
|
|
- **Definition of Done:** Jede PR an `tibi-server` oder `tibi-admin-nova`, die API, Hooks, Collections, Permissions, Jobs, Realtime, LLM, Deploy oder UX ändert, aktualisiert auch die Docs — sonst ist die PR nicht fertig.
|
|
- **Sprache:** Deutsch, saubere Umlaute (ä ö ü ß), Du-Form, kurze Sätze. Ton: **per Du, aber professionell** — sachlich wie ein gutes Handbuch, niemals Babysprache. Keine belehrenden Binsen („wenn du nichts findest, verändere die Suche"), keine Verniedlichung („keine Angst"), keine erfundenen Floskeln. UI-Namen immer wörtlich aus `de.json` bzw. Screenshot. Anweisungen nennen den exakten Klickpfad; „Was-tun-wenn" nur für echte, am Code belegte Fälle.
|
|
|
|
## 2. Wo was hingehört — Stand: Gerüst steht, Hüllen mit Arbeitsaufträgen
|
|
|
|
Jede Hüllen-Seite enthält Abschnitt „Für spätere Agenten“ mit Quelle-der-Wahrheit (Code zuerst), Prüfschritten und Ziel-Struktur. Hüllen abarbeiten heißt: Code prüfen, Seite befüllen, `Verifiziert am <Commit> <Datum>` ergänzen.
|
|
|
|
| Ordner | Inhalt | Beispiel |
|
|
|---|---|---|
|
|
| `einstieg/` | Tutorials, Erste Schritte (Projekt-Blick) | Schnellstart, Neues Projekt, Begriffe |
|
|
| `projekt/` | Projekt-Entwickler baut eigenständige Website (Sammlungen → Deploy) | Hooks, SSR, Suche |
|
|
| `server/` | **SYNC — nicht von Hand editieren**, Quelle `../tibi-server/docs/`; dazu Handseiten Betrieb | Konfiguration, Sicherheit |
|
|
| `admin/` | Teils SYNC aus `../tibi-admin-nova/docs/`, plus Handseiten | Konzept, Editor, Exporte |
|
|
| `anwender/` | Redakteurs-Anleitungen im Verwaltungs-Backend (Aufgaben, keine Konzepte) | Anmelden, Medien |
|
|
| `reference/` | Teils **generiert — nie von Hand** (openapi), teils Code-Stand-Tabellen | Hook-Kontexte, Token-Köpfe |
|
|
| `adr/` | Architektur-Entscheide, Format siehe `adr/0000-vorlage.md` | Code-schlägt-Doku |
|
|
|
|
## 3. Neue Seite anlegen
|
|
|
|
- Datei `src/content/docs/<bereich>/<slug>.md` mit Frontmatter `title` + `description`.
|
|
- Sidebar: jede Gruppe explizit in `astro.config.mjs` eintragen (beim Neuaufbau pro Bereich ergänzen; `autogenerate` erst nutzen, sobald der Ordner gepflegt befüllt ist).
|
|
- Bilder nach `src/assets/`, max. 200 KB, deutsche Alt-Texte.
|
|
- Screenshots für Anwender-Seiten: nur Mock-Projekt `corporate` (nie `t1`), Ablauf unter `plans/t-shots-arbeitsauftrag.md`.
|
|
- Vollständigkeit: neue Fähigkeit braucht genau eine Dokustelle — Tabelle in `plans/doku-ausbau.md` („Vollständigkeit") miterweitern.
|
|
|
|
## 4. Sync-Workflow
|
|
|
|
```sh
|
|
# nach jeder Änderung in tibi-server/docs oder tibi-admin-nova/docs:
|
|
npm run sync
|
|
npm run build # muss fehlerfrei durchlaufen
|
|
```
|
|
|
|
- `server/uebersicht.md` und `admin/konzept.md` sind Handarbeit und werden vom Sync nie überschrieben (`keep`) — Sync-Ziel für Admin ist `src/content/docs/admin/` (Repo bleibt `tibi-admin-nova`).
|
|
- Sync-Artefakte werden mitcommittet (statischer Build braucht sie).
|
|
|
|
## 5. Verbote
|
|
|
|
- Keine Secrets, Tokens, Kundennamen oder interne Hosts in die Doku.
|
|
- Keine englischen Server-Docs duplizieren und übersetzen — lieber verlinken und bei Bedarf eigene deutsche Einstiegsseite.
|
|
- Keine toten Links: der Build prüft interne Links **nicht** — nach jeder Link-Änderung alle Links der Seite anklicken (lokal oder Code-URL), erst dann pushen.
|
|
|
|
## 6. Theming
|
|
|
|
- `src/styles/custom.css` ist an Nova angelehnt (Inter, `--sl-color-accent` Near-Black, Nova-Orange `#c2410c` als Zweitakzent). Farben nur dort ändern, nicht inline.
|
|
- Logo/Favicon: `src/assets/favicon.svg` (Nova-Supernova). Austausch nur gegen offizielles Nachfolge-Logo.
|