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>
4.0 KiB
4.0 KiB
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>. LabelDiskussion= noch kein Konsens: Annahmen im PR kennzeichnen. - Betroffenes Paket bestimmen (
workspace.toml). Beisn_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ägendocs/architektur/schnittstellen.md, bei Überraschungendocs/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 insn_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.mdAbschnitt 5. - Bei Bedarf Wrapper erweitern: reales Symbol im
try-Block, Mock-Klasse imexcept-Block (Musterqgiscore_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– erzeugtdocs/tests/testkatalog.mdneu, 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.txtdes 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.mdvorbereiten; Übergabenotiz mit Skillsn-uebergabe. - Hier ist Schluss. Push, Pull Request, Merge und Tag macht der Mensch. Ebenso: Baseline ändern,
metadata.txtvon Hand anfassen, irgendetwas auf Gitea verändern.