Files
Projektwissen/.agents/skills/sn-aufgabe-bearbeiten/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

4.0 KiB
Raw Blame History

name, description
name description
sn-aufgabe-bearbeiten Standardablauf für eine Entwicklungsaufgabe an den LNO-Plugins (sn_basis, sn_verfahrensgebiet, sn_plan41, sn_widmung) von Gitea-Issue über Branch, Umsetzung und Tests bis zum vorbereiteten Pull Request mit Übergabenotiz. Verwenden bei "bearbeite Issue", "setze um", "Bugfix", "neue Funktion".

Aufgabe bearbeiten

0. Stand holen (nicht überspringen)

python scripts/hallo.py

Holt für alle Klone den Serverstand und aktualisiert die Kanal-Branches per Fast-Forward, wo das gefahrlos geht. Ohne diesen Schritt wird womöglich etwas behoben, das längst behoben ist.

1. Auftrag verstehen (nicht überspringen)

  • Issue mit Kommentaren lesen – Skill sn-ticket, python scripts/gitea.py ticket <repo> <nr>. Label Diskussion = noch kein Konsens: Annahmen im PR kennzeichnen.
  • Betroffenes Paket bestimmen (workspace.toml). Bei sn_basis: alle Fachplugins sind Nutzer.
  • Ziel, Abnahmekriterien und Grenzen in drei Sätzen zurückspiegeln, bevor Code angefasst wird. Fehlt ein Abnahmekriterium, ist das die erste Rückfrage – nicht der erste Commit.

2. Kontext laden – gezielt

  • docs/status/STATUS.md (wer arbeitet woran), docs/architektur/modulkarte.md (Dateien und Größen), bei Verträgen docs/architektur/schnittstellen.md, bei Überraschungen docs/wissen/fallstricke.md.
  • Dann grep -n "def \|class " <datei> für die Struktur, dann nur die betroffenen Abschnitte lesen.
  • Verwendungen finden: grep -rn "<funktion>" Plugin_SN_*/ --include=*.py.
  • Gibt es zu dem Ablauf eine Seite in docs/tests/? Dann zeigt sie, was heute abgedeckt ist.

3. Branch

Der Einstiegspunkt richtet sich nach dem Kanal, in dem der Fehler sitzt – nicht nach der Dringlichkeit. Neue Funktionen beginnen immer bei unstable. Vollständig: docs/leitfaden/05_git_arbeitsweise.md Abschnitt 4.

cd Plugin_SN_<Repo>
git switch unstable && git pull --ff-only     # bzw. testing / stable bei einem Fix dort
git switch -c feature/<issue-nr>-<kurzname>   # oder bugfix/… ; klein, ASCII, mit Nummer

Fix an testing oder stable: die Rückführung nach unten ist Teil der Aufgabe, nicht „später".

4. Umsetzen

  • Kleine Schritte, jeder für sich testbar. Nach jedem Schritt python scripts/run_tests.py <paket> --baseline (aus dem Projektwissen-Root, also ohne ../).
  • Regeln aus AGENTS.md: nur Wrapper-Importe, get_variable/set_variable, keine Fachlogik in sn_basis, kein Refactoring nebenbei, Stil der Datei beibehalten, Deutsch.
  • Neue Logik bekommt einen Test in tests/test_<modul>.py – unittest, Mock-Modus, kein Netzwerk, ein Test je Verhalten. Bei einem Bugfix zuerst den Test schreiben, der den Fehler zeigt.
  • Jeder neue oder geänderte Test bekommt einen deutschen Docstring, erste Zeile """Prüft, dass …""". Warum: docs/leitfaden/06_tests.md Abschnitt 5.
  • Bei Bedarf Wrapper erweitern: reales Symbol im try-Block, Mock-Klasse im except-Block (Muster qgiscore_wrapper.py).

5. Nachweis

  • python scripts/run_tests.py <paket> --baseline → keine Zeile „NEU ROT". Neu grüne Tests im PR nennen.
  • python scripts/testkatalog.py – erzeugt docs/tests/testkatalog.md neu, gehört mit in den Commit.
  • Betrifft die Änderung einen dokumentierten Fachablauf: die Seite in docs/tests/ nachziehen.
  • UI-, Layer-, WFS- oder Layoutverhalten: manueller QGIS-Test durch den Entwickler nötig → im PR als offenen Punkt eintragen, wenn du ihn nicht ausführen kannst. Nicht als erledigt ausgeben.

6. Abschluss

  • changelog.txt des Plugins: neue Zeile(n) oben vor dem ersten --- (Block ohne Versionszeile).
  • Commit-Nachrichten deutsch, Präsens, erste Zeile ≤ 72 Zeichen, Issue-Nummer am Ende.
  • Pull-Request-Text nach docs/vorlagen/pull_request.md vorbereiten; Übergabenotiz mit Skill sn-uebergabe.
  • Hier ist Schluss. Push, Pull Request, Merge und Tag macht der Mensch. Ebenso: Baseline ändern, metadata.txt von Hand anfassen, irgendetwas auf Gitea verändern.