.gitea/ISSUE_TEMPLATE/bug.md

@@ -1,36 +0,0 @@
----
-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

@@ -1,41 +0,0 @@
----
-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

@@ -1,30 +0,0 @@
-## 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,32 +32,7 @@ ## 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