Regeln
Erstellt: 2025-12-27 | Aktualisiert: 2025-12-27
Verbindliche Entwicklungs- und Betriebsregeln für das Campus-System. Diese Regeln werden durch Hooks und Quality-Gates durchgesetzt.
1. Kein Git
| Regel | Git ist auf diesem Server verboten |
|---|
| Grund | File-Backup via Hooks ersetzt Versionierung |
|---|
| Alternative | file_backup_hook.py sichert jede Änderung automatisch |
|---|
2. MCP nutzen
| Regel | Kein direkter Datenbankzugriff via mysql/mariadb CLI |
|---|
| Grund | Validierung, Logging, Security durch MCP |
|---|
| Durchsetzung | block_direct_db.py Hook blockiert CLI-Zugriffe |
|---|
Statt:
mysql -u root -p ki_dev -e "SELECT * FROM tasks"
Verwende:
mcp__mcp-db__db_select("SELECT * FROM tasks", database="ki_dev")
Verfügbare MCP-Server
| Server | Zweck | Wichtige Tools |
|---|
| MCP-DB | Datenbankzugriff | db_select, db_insert, db_update, db_delete |
| MCP-Tasks | Task-Management | tasks_create, tasks_status, tasks_result |
| MCP-Contracts | Contract-Validierung | contracts_validate, contracts_list |
| MCP-Docs | Dokumentation | docs_get, docs_search, docs_update |
| MCP-Code | Code-Analyse | code_search, code_impact, code_dependents |
3. Dev first
| Regel | Entwicklung immer auf dev.campus.systemische-tools.de |
|---|
| Grund | Keine Risiken für Produktion |
|---|
| Workflow | dev → Testen → sync-dev-prod.sh → prod |
|---|
Umgebungen
| Umgebung | URL | Pfad |
|---|
| Development | dev.campus.systemische-tools.de | /var/www/dev.campus.systemische-tools.de/ |
| Production | campus.systemische-tools.de | /var/www/prod.campus.systemische-tools.de/ |
4. Quality vor Sync
| Regel | /var/www/scripts/php-check.sh muss bestehen |
|---|
| Grund | Keine Fehler in Produktion |
|---|
| Durchsetzung | sync-dev-prod.sh bricht bei Fehlern ab |
|---|
Quality-Checks
- PHPStan: Typen, Null-Safety, Bugs
- PHP-CS-Fixer: PSR-12 Code Style
- Composer Audit: Dependency CVEs
- Semgrep: OWASP Security
- Contracts: Architecture + View-Struktur
Manuell prüfen
/var/www/scripts/php-check.sh /var/www/dev.campus.systemische-tools.de
5. Task-Pflicht
| Regel | Für jede Anforderung tasks_create() nutzen |
|---|
| Grund | Nachvollziehbarkeit, Protokollierung |
|---|
| Durchsetzung | task_completion_guard.py prüft Result vor Completion |
|---|
Workflow
# 1. Task erstellen
tasks_create(title="Feature X implementieren", type="ai_task")
# 2. Status setzen
tasks_status(id=123, status="in_progress")
# 3. Arbeit dokumentieren
tasks_result(id=123, response="...", executor="claude", executor_type="claude")
# 4. Abschließen
tasks_status(id=123, status="completed")
6. Layer-Grenzen
| Regel | Controller → UseCase → Repository (nie direkt) |
|---|
| Grund | Clean Architecture, Testbarkeit |
|---|
| Durchsetzung | architecture_guard.py + Quality-Gates |
|---|
Erlaubt
// Controller → UseCase → Repository
$this->createTaskUseCase->execute($data);
Verboten
// Controller → Repository direkt
$this->taskRepository->save($task);
7. HTMX statt fetch()
| Regel | Frontend-Interaktionen via HTMX Attribute |
|---|
| Grund | Server-Rendering, weniger JavaScript |
|---|
| Dokumentation | HTMX Patterns |
|---|
Beispiel
<button hx-post="/tasks/123/complete"
hx-headers='{"X-CSRF-TOKEN": "..."}'
hx-confirm="Wirklich abschließen?">
Abschließen
</button>
Zusammenfassung
| # | Regel | Durchsetzung |
|---|
| 1 | Kein Git | file_backup_hook.py |
| 2 | MCP nutzen | block_direct_db.py |
| 3 | Dev first | sync-dev-prod.sh |
| 4 | Quality vor Sync | php-check.sh + contracts |
| 5 | Task-Pflicht | task_completion_guard.py |
| 6 | Layer-Grenzen | architecture_guard.py |
| 7 | HTMX statt fetch() | Quality-Gates |
Verwandte Themen