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>

.agents/skills/sn-release/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: sn-release
+description: Release eines LNO-Plugins über den Gitea-Tag-Workflow (Kanäle unstable/testing/stable, Versionsschema JJ.M.N, changelog, metadata.template, Feeds in Repository). Verwenden bei "Release", "Version veröffentlichen", "Tag setzen", "testing/unstable bauen". Nur für Maintainer; Agenten bereiten vor, taggen nicht.
+---
+
+# Release erstellen
+
+Ablauf und Fallstricke: `docs/architektur/schnittstellen.md` Abschnitt 9, `docs/wissen/fallstricke.md` (Release).
+
+## Vorbereitung (Agent darf)
+1. Kanal-Branch prüfen: `git switch unstable && git pull --ff-only` (bzw. `testing`). **Gebaut wird der Kopf dieses Branches, nicht der getaggte Commit.**
+2. `changelog.txt`: Block über dem ersten `---` enthält die Einträge seit dem letzten Release; darüber Zeile `Version <JJ.M.N>-<kanal>:` ergänzen (Muster im Verlauf der Datei). Er wird zum Release-Text.
+3. `.gitea/templates/metadata.template` prüfen: Name, Beschreibung, URLs zeigen auf **dieses** Repo (bekannte Fehler: Plan41 → Test_Action, FLT → `Plugin_SN_Neu`). Version wird vom Workflow gesetzt.
+4. Tests: `python scripts/run_tests.py <paket> --baseline` ohne NEU ROT. Bei Fachplugins prüfen, ob die verwendete `sn_basis`-Version passende Schnittstellen hat (Änderungen seit letztem Basis-Release im Changelog).
+5. Version wählen: `JJ.M.N` = Jahr.Monat.Laufnummer im Monat (z. B. `26.9.1`). Unstable und testing zählen getrennt hoch.
+
+## Auslösen (nur Maintainer)
+```bash
+git tag v26.9.1-u        # -u unstable, -t testing, ohne Suffix stable (derzeit ohne Branch – nicht verwenden)
+git push origin v26.9.1-u
+```
+Der Repo-Workflow schickt einen Payload an `Repository` (Branch `hidden/workflows`); dieser baut das ZIP unter dem
+Gitea-Variablennamen `ZIP_FOLDER`, erzeugt `metadata.txt` aus dem Template, legt das Gitea-Release an und aktualisiert
+`plugins-<kanal>.xml`.
+
+## Prüfen
+- Gitea → Repo → Releases: Eintrag `Version 26.9.1-unstable` mit ZIP-Asset.
+- `Repository/plugins-unstable.xml` enthält die neue Version.
+- QGIS mit Feed `unstable`: Plugin-Aktualisierung sichtbar, Installation startet ohne Fehler.
+
+## Nach dem Release
+- `docs/status/STATUS.md`: Versionen je Kanal nachtragen.
+- Bekannter offener Punkt: Release-ZIPs enthalten derzeit `AGENTS.md`, `CLAUDE.md`, `docs/`, `tests/` (Excludes im zentralen Workflow ergänzen).