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>
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.mdAbschnitt 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
- Issue mit Kommentaren lesen (
ticket), nicht nur den Titel. - Label
Diskussionbedeutet: es gibt noch keinen Konsens. Dann nicht umsetzen, sondern die offene Frage benennen. Wird trotzdem umgesetzt, sind die Annahmen im Pull Request zu kennzeichnen. - Betroffenes Paket über
workspace.tomlbestimmen. Beisn_basissind alle Fachplugins Nutzer — Änderungen an öffentlichen Funktionen sind API-Änderungen. - 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.
- Fehlt fachlicher Kontext:
docs/wissen/glossar.md, danndocs/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:
- Entwurf anlegen lassen.
- Text ausfüllen — bei Issues nach
docs/vorlagen/issue.md: Ziel, Betroffen, fachlicher Hintergrund, Abnahmekriterien, Nicht Teil dieses Issues. - Dem Menschen den Pfad der Datei und die Ziel-URL nennen.
- 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.