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

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.

Conventional Commits: Präfixe wie feat:, fix:, refactor:, docs:, chore: verwenden.
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:
```
feat: Stripe-Zahlung implementiert, closes #12
```
Branching: Projekt-Branches und MR/PR-Regeln wie im Team vereinbart beibehalten.

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