Files
Projektwissen/.agents/skills/sn-ticket/SKILL.md
T
AndreasTharangandClaude Sonnet 5 ab416fb34c 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>
2026-09-04 11:57:26 +02:00

3.9 KiB

name, description
name description
sn-ticket 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

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

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.