docs: update agent guidelines
This commit is contained in:
parent
dcc421e984
commit
14d5ad9e2e
25
Agents.md
25
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user