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