docs: add doc-sync cursor rule to wiki, integrate install instructions in README

Made-with: Cursor
This commit is contained in:
ValueOn AG 2026-04-05 23:47:23 +02:00
parent 9bec16960a
commit 580d663d1a
3 changed files with 62 additions and 0 deletions

View file

@ -72,6 +72,35 @@ b-reference/
---
## Cursor-Regel: Doc-Sync
Eine Cursor-Rule sorgt dafür, dass der AI-Assistent bei konzeptionellen Code-Änderungen automatisch an die Wiki-Pflege erinnert.
**Datei:** `@poweron/.cursor/rules/doc-sync.mdc` (Quelle: `wiki/d-guides/doc-sync.mdc`)
Falls die Regel lokal noch nicht existiert, kopiere sie:
```powershell
# Prüfen und kopieren (PowerShell)
$src = "wiki\d-guides\doc-sync.mdc"
$dst = ".cursor\rules\doc-sync.mdc"
if (-not (Test-Path $dst)) {
New-Item -ItemType Directory -Path ".cursor\rules" -Force | Out-Null
Copy-Item $src $dst
Write-Host "doc-sync.mdc installiert"
} else {
Write-Host "doc-sync.mdc bereits vorhanden"
}
```
**Was die Regel tut:**
- Erinnert bei Änderungen an API, Domain-Logik, Security, RBAC, Navigation, Features, Billing
- Während Arbeit: `c-work/<phase>/<feature>.md` pflegen
- Bei Abschluss: betroffene `b-reference/` Seite + `TOPICS.md` aktualisieren
- Kein Doku-Zwang bei reinen Refactors, Formatting oder Test-only Changes
---
## Für AI-Assistenten
**Immer zuerst laden:** `TOPICS.md` -- dort steht, welche Datei für welches Thema massgeblich ist.

View file

@ -43,3 +43,4 @@ Lade immer zuerst diese Datei. Dann gezielt die passende(n) Referenz-Datei(en).
| Testing-Strategie | d-guides/testing-strategy.md | Testpyramide, AC-Format, Test-Pfade |
| Deployment | d-guides/deployment.md | Release-Prozess, Environments |
| Dev-Setup | d-guides/dev-setup.md | Lokale Umgebung starten |
| Doc-Sync Cursor-Rule | d-guides/doc-sync.mdc | Cursor-Regel installieren, Doku-Workflow |

32
d-guides/doc-sync.mdc Normal file
View file

@ -0,0 +1,32 @@
---
description: Reminder to update wiki documentation when making conceptual or structural code changes
alwaysApply: true
---
# Documentation Sync
When a code change touches any of these areas, remind the user to update the wiki:
- Public API endpoints (new/changed/removed routes)
- Domain logic flow (how data moves through services)
- Security boundaries (neutralization, auth, encryption)
- RBAC model (roles, permissions, access rules)
- Navigation / routing structure
- Feature boundaries (new feature module, moved responsibilities)
- Billing / subscription logic
## During active work
Update the working document in `wiki/c-work/<phase>/<feature>.md` (Kanban: 1-plan → 2-build → 3-validate → 4-done).
## When work is done (merged/released)
- Update the affected canonical page in `wiki/b-reference/`
- Set `lastReviewed` and `verifiedAgainst` in the page header
- Check if `wiki/TOPICS.md` needs a new or changed entry
## Skip documentation for
- Pure refactors without behavior change
- Formatting, linting, dependency bumps
- Test-only changes