100 lines
2.9 KiB
Markdown
100 lines
2.9 KiB
Markdown
# AGENTS.md
|
||
|
||
## Ziel
|
||
|
||
Codex arbeitet pragmatisch bei Aufgaben aus `NEXT.md` und User-Requests.
|
||
|
||
Ein Gitea-Issue ist optional.
|
||
|
||
## Kernregeln
|
||
|
||
1. Ein Issue ist **nicht erforderlich**, um eine Aufgabe umzusetzen.
|
||
|
||
2. Skills dürfen jederzeit verwendet werden (z. B. `gitea-issues`).
|
||
|
||
3. Ein `NEXT.md`-Punkt darf erst auf erledigt (`[x]`) gesetzt werden, wenn die Umsetzung im Code erfolgt ist.
|
||
|
||
4. Nur wenn ein Gitea-Issue konkret referenziert ist **und** durch die Änderung abgeschlossen wird, muss die Commit-Message `closes #<id>` enthalten.
|
||
|
||
5. Jede `closes`-Referenz steht in einer **eigenen Zeile**.
|
||
|
||
6. Kein `closes #<id>`, wenn das Issue nicht tatsächlich abgeschlossen ist.
|
||
|
||
7. `git push` nur auf explizite Aufforderung; standardmässig nur committen.
|
||
|
||
8. Datenbank-Updates als neue SQL-Datei in `initdb.d` mit nächsthöherer Nummer ergänzen. Standard für Codex ist `<nummer>.sql` (z. B. `00002.sql`, `00003.sql`), und nur die führende Nummer zählt; alles nach der Nummer sind persönliche Notizen.
|
||
|
||
9. Sonderfall `-live.sql`: User darf `*-live.sql` anlegen, um bereits produktiv eingespielte Änderungen zu markieren. Codex legt **keine** neuen `*-live.sql` an und erzeugt **keine** zusätzliche gleichnummerige `.sql`, wenn bereits eine passende `*-live.sql` für dieselbe Änderung existiert. Bestehende Dateien in `initdb.d` für neue DB-Änderungen nicht überschreiben.
|
||
|
||
## Verbindlicher Ablauf
|
||
|
||
1. Aufgabe umsetzen (aus `NEXT.md` oder User-Anfrage).
|
||
|
||
2. Optional Issues laden, wenn Kontext/Zuordnung nötig ist:
|
||
|
||
- `python C:/Users/s.titz/.codex/skills/gitea-issues/scripts/list_issues.py <owner> <repo> --state open --limit 100 --json`
|
||
|
||
- ignoriere Issues, die den Tag LATER haben, es sei den es wird explizit verlangt
|
||
|
||
3. `NEXT.md` bei Bedarf aktualisieren (mit oder ohne `[#<id>]`).
|
||
|
||
4. Commit erstellen.
|
||
|
||
5. Wenn Issue abgeschlossen wird, Commit-Message mit eigener `closes`-Zeile schreiben.
|
||
|
||
## Commit-Format bei Issue-Abschluss
|
||
|
||
Beispiel mit einem Issue:
|
||
|
||
```text
|
||
Kurzbeschreibung der Änderung
|
||
|
||
|
||
|
||
closes #42
|
||
```
|
||
|
||
Beispiel mit mehreren Issues:
|
||
|
||
```text
|
||
Kurzbeschreibung der Änderung
|
||
|
||
|
||
|
||
closes #12
|
||
|
||
closes #18
|
||
```
|
||
|
||
## Format für NEXT.md
|
||
|
||
- Offen ohne Issue:
|
||
|
||
- `- [ ] //TODO Backup-Runbook erstellen`
|
||
|
||
- Offen mit Issue:
|
||
|
||
- `- [ ] [#42] //TODO Backup-Runbook erstellen`
|
||
|
||
- Erledigt mit Issue:
|
||
|
||
- `- [x] [#42] Backup-Runbook erstellen`
|
||
|
||
- Erledigt ohne Issue:
|
||
|
||
- `- [x] Backup-Runbook erstellen`
|
||
|
||
## Annahme
|
||
|
||
- Gitea ist so konfiguriert, dass `closes #<id>` in Commit-Messages das Issue schliesst.
|
||
|
||
## Encoding
|
||
|
||
immer utf8 ohne BOM, es sei den es ist anders angegeben
|
||
|
||
## Sprache und Rechtschreibung
|
||
|
||
- In sichtbaren Nutzertexten immer korrekte deutsche Rechtschreibung verwenden: ä/ö/ü/Ä/Ö/Ü statt ae/oe/ue, und ß statt ss, wenn orthografisch korrekt.
|
||
|
||
- Technische Bezeichner (z. B. Variablen, Tabellen, URLs, Query-Parameter wie gebaeude) bleiben unverändert.
|