51 lines
2.9 KiB
Markdown
51 lines
2.9 KiB
Markdown
# KI- und Entwickler-Workflow (Pressekonto)
|
||
|
||
Kurzanleitung für Arbeit im Dev-Container: Dokumentation (Obsidian), Issues (Forgejo/`tea`), Git.
|
||
|
||
## 1. Dokumentation und Kontext (Obsidian)
|
||
|
||
- **Speicherort:** Markdown-Dateien liegen im Projekt unter **`docs/`** (im Container: `/var/www/html/docs/`). Dieser Ordner ist per Dev-Container mit dem Obsidian-Vault verbunden; Änderungen synchronisieren mit dem lokalen Vault.
|
||
- **Bei Fragen nach „Kontext“, „Briefing“ oder „Plan“:** Zuerst **`docs/`** nach passenden `.md`-Dateien durchsuchen (Dateinamen und Überschriften).
|
||
- **Neue Inhalte:** Konzepte, Pläne, Briefings und Spezifikationen **immer als `.md` in `docs/`** ablegen. Sinnvolle, stabile Dateinamen wählen (z. B. `feature-stripe-briefing.md`).
|
||
|
||
## 2. Issue-Management (Forgejo mit `tea`)
|
||
|
||
**Nur das `tea`-CLI im Terminal verwenden** — keine direkten HTTP/cURL-Aufrufe auf die Forgejo-API für Issue-Operationen.
|
||
|
||
| Aktion | Befehl |
|
||
|--------|--------|
|
||
| Issues auflisten | `tea issue list` |
|
||
| Issue anzeigen | `tea issue view <id>` |
|
||
| Neues Issue (Beschreibung aus Datei) | `tea issue create --title "Kurztitel" --description "$(cat docs/beispiel.md)"` |
|
||
| Issue aktualisieren | `tea issue edit <id> --description "$(cat docs/update.md)"` |
|
||
|
||
**Hinweise:**
|
||
|
||
- Nach `postCreateCommand` liegt `tea` typischerweise unter `~/.local/bin`; Shell neu starten oder `export PATH="$HOME/.local/bin:$PATH"` setzen, falls `tea` nicht gefunden wird.
|
||
- Remote/Ziel prüfen bei Bedarf mit `tea repos` bzw. der in `postCreateCommand` konfigurierten Login-Instanz **`gitmedia`** (`https://git.adametz.media`).
|
||
- **`tea` ist im Setup bereits authentifiziert** — keine Zugangsdaten oder Tokens im Chat abfragen oder in Repos committen. Token-Datei nur read-only gemountet (`/tmp/.forgejo_token`).
|
||
|
||
**Weitere Unterbefehle:** `tea issue --help`, `tea issue create --help`.
|
||
|
||
## 3. Git und Commits (Issue-Schließen)
|
||
|
||
1. **Conventional Commits:** Präfixe wie `feat:`, `fix:`, `refactor:`, `docs:`, `chore:` verwenden.
|
||
2. **Issue-Verknüpfung zum automatischen Schließen:** Im Commit-Text die Issue-Nummer mit **`closes`** (alternativ in vielen Gitea/Forgejo-Setups auch `fix(es)`, `resolve(s)`) angeben.
|
||
|
||
**Beispiel:**
|
||
|
||
```text
|
||
feat: Stripe-Zahlung implementiert, closes #12
|
||
```
|
||
|
||
3. **Branching:** Projekt-Branches und MR/PR-Regeln wie im Team vereinbart beibehalten.
|
||
|
||
## 4. Arbeitsweise (KI / Agent)
|
||
|
||
- Kontext zuerst aus **`docs/`**, dann Code und bestehende Projektregeln (z. B. `AGENTS.md`, `.cursorrules`).
|
||
- Terminal-Befehle direkt ausführen, wo sinnvoll; Antworten **prägnant**, Entscheidungen und Änderungen **nachvollziehbar** dokumentieren (bei Bedarf kurz in `docs/` oder im Issue).
|
||
- Keine manuelle Nachfrage nach Forgejo-Zugang **sofern `tea login` für `gitmedia` gesetzt ist**; bei `tea`-Fehlern Umgebung/Remote prüfen, nicht nach Passwörtern fragen.
|
||
|
||
---
|
||
|
||
*Letzte inhaltliche Ausrichtung: Dev-Container `workspaceFolder` `/var/www/html`, Vault-Bind nach `docs/`.*
|