agents update

AGENTS.md

@@ -1,26 +1,45 @@
 # 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 duerfen jederzeit verwendet werden (z. B. `gitea-issues`).
+
+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 Aenderung abgeschlossen wird, muss die Commit-Message `closes #<id>` enthalten.
+
+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 tatsaechlich abgeschlossen ist.
-7. `git push` nur auf explizite Aufforderung; standardmaessig nur committen.
+
+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 noetig ist:
-   - `python C:/Users/s.titz/.codex/skills/gitea-issues/scripts/list_issues.py <owner> <repo> --state open --limit 100 --json`
+
+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
@@ -28,7 +47,9 @@ Ein Gitea-Issue ist optional.
 Beispiel mit einem Issue:
 
 ```text
-Kurzbeschreibung der Aenderung
+Kurzbeschreibung der Änderung
+
+
 
 closes #42
 ```
@@ -36,23 +57,43 @@ closes #42
 Beispiel mit mehreren Issues:
 
 ```text
-Kurzbeschreibung der Aenderung
+Kurzbeschreibung der Änderung
+
+
 
 closes #12
+
 closes #18
 ```
 
-## Format fuer NEXT.md
+## Format für NEXT.md
 
 - Offen ohne Issue:
-  - `- [ ] //TODO Backup-Runbook erstellen`
+
+  - `- [ ] //TODO Backup-Runbook erstellen`
+
 - Offen mit Issue:
-  - `- [ ] [#42] //TODO Backup-Runbook erstellen`
+
+  - `- [ ] [#42] //TODO Backup-Runbook erstellen`
+
 - Erledigt mit Issue:
-  - `- [x] [#42] Backup-Runbook erstellen`
+
+  - `- [x] [#42] Backup-Runbook erstellen`
+
 - Erledigt ohne Issue:
-  - `- [x] Backup-Runbook erstellen`
+
+  - `- [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.