Projektwissen: Git-Vorgaben, Ticketzugriff, Tests und Einstieg

Erster Stand des Repositories AG_QGIS/Projektwissen (bisher Arbeitstitel
"Workspace", ADR 0006). Der lokale Ordner heisst weiter AG_QGIS, weil darin
auch die Plugin-Klone liegen.

Git verbindlich (ADR 0007), aus dem bisherigen Wiki-Konzept entwickelt:
- docs/leitfaden/05_git_arbeitsweise.md mit Kanal-Kette, Branch-Namen und
  Gitea-Branch-Schutz.
- Der Einstiegspunkt eines Fixes richtet sich nach dem Kanal, in dem der
  Fehler sitzt; ein Fix an testing oder stable ist erst mit der
  Rueckfuehrung nach unten abgeschlossen. Das fehlte bisher.
- Der stabile Kanal heisst stable, nicht main: der Release-Workflow in
  Repository:hidden/workflows fuehrt git checkout "$CHANNEL" aus, der
  Branchname muss also dem Kanalnamen entsprechen. Er existiert in keinem
  Plugin-Repo und ist vom Maintainer anzulegen.
- Der Mensch drueckt ab: .claude/settings.json sperrt push, merge, tag.
- scripts/hallo.py und /hallo holen den Stand aller Klone, per
  Fast-Forward wo gefahrlos; nie mergen, stashen oder verwerfen.

Ticketzugriff:
- scripts/gitea.py liest Issues, Kommentare und PRs ueber die oeffentliche
  API, ohne Token, nur GET. Schreibendes nur als Entwurf in entwuerfe/.
- Skill sn-ticket.

Tests (ADR 0009):
- docs/leitfaden/06_tests.md: Testebenen, Testpflicht, und wie eine
  Fachperson beurteilt, ob Tests fachlich sinnvoll sind.
- scripts/testkatalog.py erzeugt docs/tests/testkatalog.md per ast-Parsing,
  ohne Import und ohne QGIS. Befund: nur 100 von 332 Tests haben einen
  Docstring, sn_basis keinen einzigen von 87.
- Vorlage und erste Testkonzept-Seite mit Mermaid. Dabei gefunden und gegen
  origin geprueft: _ermittle_gebietstyp_aus_fbschl hat keinen Test, obwohl
  PR #44/#45 genau diese Funktion tolerant gemacht hat.
- docs/konzept/07_qgis_tests_plan.md: Stufenplan fuer Tests gegen echtes
  QGIS. Dabei aufgefallen: QGIS 3.40 ist seit Januar 2026 End of Life,
  qgis_min steht aber noch darauf.

Werkzeuge (ADR 0008):
- 04_werkzeuge_einrichten.md nur noch Claude Code als CLI und in VS Code.
- .vscode/ entfernt, brauchbare Einstellungen als persoenliche Vorlage.

Ausserdem: README als Einstieg neu aufgebaut, Mermaid-Diagramm in
schnittstellen.md repariert (unmaskierte Klammern, rendert seither nicht).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.agents/skills/sn-ticket/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: sn-ticket
+description: Gitea-Tickets lesen, durchsuchen und beantworten - offene Issues auflisten, ein Issue mit allen Kommentaren holen, Issue- und Kommentartexte als Entwurf vorbereiten, den ein Mensch absendet. Verwenden bei "welche Tickets gibt es", "lies Issue", "was steht in dem Ticket", "leg ein Issue an", "kommentiere das Ticket".
+---
+
+# Tickets auf Gitea
+
+Alle Repositories der Organisation `AG_QGIS` liegen auf `entwicklung.flurneuordnung-sachsen.de`. Die API ist
+**lesend ohne Anmeldung** erreichbar; dafür gibt es `scripts/gitea.py` (nur Standardbibliothek, kein Token).
+
+> **Der Agent verändert auf dem Server nichts.** Kein Anlegen, kein Kommentieren, kein Schließen, kein Zuweisen.
+> Der Agent bereitet den Text vor, der Mensch fügt ihn ein und sendet ab. Grund: Jede Aktion trägt den Namen
+> einer Person und deren Verantwortung. Siehe `docs/leitfaden/05_git_arbeitsweise.md` Abschnitt 6.
+
+## Lesen
+
+```bash
+python scripts/gitea.py tickets                    # alle offenen Issues der Organisation
+python scripts/gitea.py tickets Basis              # nur ein Repo (Kurzname genügt)
+python scripts/gitea.py tickets --label Bug        # nach Label filtern
+python scripts/gitea.py ticket Basis 48            # ein Issue mit allen Kommentaren
+python scripts/gitea.py suche "FBSchl"             # Volltext über alle Repos
+python scripts/gitea.py pulls                      # offene Pull Requests
+```
+
+Repo-Kurznamen: `Basis`, `Plan41`, `Verfahrensgebiet`, `Widmung`, … werden auf die vollen Namen aus
+`workspace.toml` aufgelöst.
+
+**Immer `ticket` statt `tickets` verwenden, bevor mit der Arbeit begonnen wird.** Die Kommentare enthalten
+regelmäßig die eigentliche Anforderung — die Titelzeile führt in die Irre.
+
+## Ein Ticket verstehen, bevor Code angefasst wird
+
+1. Issue **mit Kommentaren** lesen (`ticket`), nicht nur den Titel.
+2. Label `Diskussion` bedeutet: es gibt noch keinen Konsens. Dann nicht umsetzen, sondern die offene Frage
+   benennen. Wird trotzdem umgesetzt, sind die Annahmen im Pull Request zu kennzeichnen.
+3. Betroffenes Paket über `workspace.toml` bestimmen. Bei `sn_basis` sind alle Fachplugins Nutzer — Änderungen
+   an öffentlichen Funktionen sind API-Änderungen.
+4. **Ziel, Abnahmekriterien und Grenzen in drei Sätzen zurückspiegeln**, bevor die erste Datei geöffnet wird.
+   Steht im Ticket kein Abnahmekriterium, ist das die erste Rückfrage — nicht der erste Commit.
+5. Fehlt fachlicher Kontext: `docs/wissen/glossar.md`, dann `docs/architektur/schnittstellen.md`.
+
+Danach weiter mit dem Skill `sn-aufgabe-bearbeiten`.
+
+## Entwurf vorbereiten
+
+```bash
+python scripts/gitea.py entwurf issue Verfahrensgebiet      # neues Issue
+python scripts/gitea.py entwurf kommentar Basis 48          # Kommentar zu Issue 48
+```
+
+Das legt eine Datei unter `entwuerfe/` an (nicht versioniert) und nennt die Gitea-URL zum Absenden. Vorgehen:
+
+1. Entwurf anlegen lassen.
+2. Text ausfüllen — bei Issues nach `docs/vorlagen/issue.md`: Ziel, Betroffen, fachlicher Hintergrund,
+   Abnahmekriterien, Nicht Teil dieses Issues.
+3. Dem Menschen den Pfad der Datei und die Ziel-URL nennen.
+4. **Dort aufhören.** Nicht versuchen, den Text per `curl`, API-Token oder auf anderem Weg abzusenden.
+
+Ein guter Issue-Entwurf ist so geschrieben, dass ein anderer Agent ihn ohne Rückfragen umsetzen kann: ein
+beobachtbares Ziel, benannte Dateien, klare Abgrenzung.
+
+## Wenn Gitea nicht erreichbar ist
+
+Das Skript meldet das im Klartext. Mögliche Ursachen: kein Netz, Proxy nicht gesetzt (`HTTPS_PROXY`), Server
+nicht verfügbar. Dann **nicht raten**, was im Ticket steht — mit der Arbeit warten oder den Menschen um den
+Ticketinhalt bitten.
+
+## Grenzen
+
+- Keine Zugangsdaten, keine personenbezogenen Daten und keine echten Verfahrensdaten in Ticket-Texten.
+- Keine Ticket-Inhalte in Zusammenfassungen erfinden oder ergänzen. Was nicht im Ticket steht, ist eine offene
+  Frage, keine Annahme.
+- Labels, Zuweisungen, Meilensteine und Status ändert der Mensch im Browser.