chore/agent-guidelines-and-templates (#2)

## 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 -->

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local>
Reviewed-on: #2

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