.gitea/ISSUE_TEMPLATE/bug.md

@@ -0,0 +1,36 @@
+---
+name: Bug
+about: Fehlerbericht / Regression
+title: "bug: <kurzer titel>"
+labels: ["bug"]
+---
+
+## What happened?
+<!-- Beschreibe den Bug -->
+
+## Expected behavior
+<!-- Was sollte passieren? -->
+
+## Steps to reproduce
+1. ...
+2. ...
+3. ...
+
+## Impact / Severity
+- [ ] blocker
+- [ ] high
+- [ ] medium
+- [ ] low
+
+## Logs / Screenshots
+<!-- Relevante Logs, Stacktraces, Screenshots -->
+
+## Environment
+- Branch/Commit:
+- Staging/Prod:
+- Browser (falls UI):
+- Relevant config/env:
+
+## Fix criteria
+- [ ] Repro-Test vorhanden oder neuer Test hinzugefügt
+- [ ] Fix verifiziert (lokal + staging)

.gitea/ISSUE_TEMPLATE/feature.md

@@ -0,0 +1,41 @@
+---
+name: Feature
+about: Neues Feature / Erweiterung
+title: "feat(<NNN>): <kurzer titel>"
+labels: ["feature"]
+---
+
+## Goal
+<!-- Was ist das Outcome? -->
+
+## Context
+<!-- Warum brauchen wir das? Wer nutzt es? -->
+
+## Scope
+- In:
+  - [ ]
+- Out:
+  - [ ]
+
+## Acceptance Criteria
+- [ ] ...
+- [ ] ...
+- [ ] ...
+
+## Spec (SDD)
+- [ ] `specs/<NNN>-<feature>/plan.md`
+- [ ] `specs/<NNN>-<feature>/tasks.md`
+- [ ] `specs/<NNN>-<feature>/spec.md`
+
+## Risks / Safety (Intune)
+- [ ] Dry-run/Preview möglich?
+- [ ] Audit Log Einträge nötig?
+- [ ] Confirmations / RBAC nötig?
+
+## Implementation Notes (optional)
+<!-- Hinweise: relevante Ordner/Modelle/Services, APIs, UI Stellen -->
+
+## Test Plan
+- [ ] Feature Test(s)
+- [ ] Failure path(s)
+- [ ] Manuelle Staging-Checks

.gitea/pull_request_template.md

@@ -0,0 +1,30 @@
+## Summary
+<!-- Kurz: Was ändert sich und warum? -->
+
+## Spec-Driven Development (SDD)
+- [ ] Es gibt eine Spec unter `specs/<NNN>-<feature>/`
+- [ ] Enthaltene Dateien: `plan.md`, `tasks.md`, `spec.md`
+- [ ] Spec beschreibt Verhalten/Acceptance Criteria (nicht nur Implementation)
+- [ ] Wenn sich Anforderungen während der Umsetzung geändert haben: Spec/Plan/Tasks wurden aktualisiert
+
+## Implementation
+- [ ] Implementierung entspricht der Spec
+- [ ] Edge cases / Fehlerfälle berücksichtigt
+- [ ] Keine unbeabsichtigten Änderungen außerhalb des Scopes
+
+## Tests
+- [ ] Tests ergänzt/aktualisiert (Pest/PHPUnit)
+- [ ] Relevante Tests lokal ausgeführt (`./vendor/bin/sail artisan test` oder `php artisan test`)
+
+## Migration / Config / Ops (falls relevant)
+- [ ] Migration(en) enthalten und getestet
+- [ ] Rollback bedacht (rückwärts kompatibel, sichere Migration)
+- [ ] Neue Env Vars dokumentiert (`.env.example` / Doku)
+- [ ] Queue/cron/storage Auswirkungen geprüft
+
+## UI (Filament/Livewire) (falls relevant)
+- [ ] UI-Flows geprüft
+- [ ] Screenshots/Notizen hinzugefügt
+
+## Notes
+<!-- Links, Screenshots, Follow-ups, offene Punkte -->

Agents.md

@@ -32,7 +32,32 @@ ## Workflow (Spec Kit)
 5. Implement changes in small PRs
 
 If requirements change during implementation, update spec/plan before continuing.
+## Workflow (SDD in diesem Repo)
 
+### Branching
+- Default / Integrations-Branch: `dev`
+- Neue Arbeit läuft über Feature-Branches von `dev`:
+  - `feat/<NNN>-<slug>` (Code + Spec im selben PR)
+  - optional: `spec/<NNN>-<slug>` (nur wenn wir Specs getrennt reviewen wollen)
+
+### Wo liegen Specs?
+- `.specify/` enthält SpecKit Tooling und die Constitution (Prozessregeln).
+- Feature-Specs liegen **immer** im Repo unter:
+  - `specs/<NNN>-<slug>/plan.md`
+  - `specs/<NNN>-<slug>/tasks.md`
+  - `specs/<NNN>-<slug>/spec.md`
+- `specs/` muss im `dev`-Branch immer existieren (Baseline).
+
+### Variante B Standard (Spec + Code in einem PR)
+1) Branch von `dev` erstellen: `feat/<NNN>-<slug>`
+2) Zuerst Specs erstellen/aktualisieren → erster Commit (`spec:`)
+3) Dann implementieren → weitere Commits (`feat:`, `fix:`, `test:`)
+4) PR/MR: `feat/...` → `dev`
+5) Merge nach `dev` (empfohlen: Squash)
+
+### Gate-Regel
+- Wenn Code geändert wird (z.B. `app/`, `config/`, `database/`, `resources/`),
+  muss der PR auch `specs/<NNN>-<slug>/` enthalten oder aktualisieren.
 ## Architecture Assumptions
 - Backend: Laravel (latest stable)
 - Admin UI: Filament