129 lines
4.2 KiB
Markdown
129 lines
4.2 KiB
Markdown
|
# Agent Guidelines für ZellIDE
|
||
|
|
|
||
|
|
## Projekt-Kontext
|
||
|
|
|
||
|
|
ZellIDE ist eine Terminal-basierte IDE-Umgebung für Tim, einen erfahrenen Software-Entwickler der von VSCode zurück ins Terminal möchte. Das Projekt kombiniert Zellij (Terminal-Multiplexer), Helix (Editor), Yazi (File-Manager) und lazygit zu einer integrierten Entwicklungsumgebung.
|
||
|
|
|
||
|
|
## Lern- und Arbeits-Stil
|
||
|
|
|
||
|
|
**Tim lernt am besten durch:**
|
||
|
|
- Schrittweises Erweitern von Code-Snippets
|
||
|
|
- Konkrete Beispiele vor Theorie
|
||
|
|
- Mini-Challenges zum Festigen
|
||
|
|
- Learning by doing, nicht durch dicke Dokumentation
|
||
|
|
|
||
|
|
**Wichtig beim Entwickeln:**
|
||
|
|
- Pragmatische Lösungen vor komplexen Architekturen
|
||
|
|
- Ein Feature nach dem anderen
|
||
|
|
- Testen in echten Use-Cases (z.B. infrastructure-Repo)
|
||
|
|
- Keine Überladung mit zu vielen Optionen auf einmal
|
||
|
|
|
||
|
|
## Technische Anforderungen
|
||
|
|
|
||
|
|
### Umgebung
|
||
|
|
- **OS:** Linux (primär), auch für Remote-Server
|
||
|
|
- **Shell:** Zsh
|
||
|
|
- **Package Manager:** System-native (dnf, apt) + uv für Python
|
||
|
|
- **VPN:** Tailscale für Server-Zugriff
|
||
|
|
- **Git:** Forgejo auf zeus.turkey-court.ts.net
|
||
|
|
|
||
|
|
### Bestehende Infrastruktur
|
||
|
|
- Mehrere Server: Zeus (Hetzner), Hephaistos, BigSister (Synology), rom-master-5000 (RPi5)
|
||
|
|
- Aktuell: tmux auf allen Servern (soll zu Zellij migriert werden)
|
||
|
|
- Linear für Projekt-Management
|
||
|
|
- Git-basierte Workflows
|
||
|
|
|
||
|
|
### Ziel-Setup
|
||
|
|
- Lokale Entwicklung: ZellIDE mit vollem Feature-Set
|
||
|
|
- Remote-Server: Gleiche ZellIDE-Umgebung für Konsistenz
|
||
|
|
- Keine nested Sessions (Zellij in Zellij vermeiden)
|
||
|
|
|
||
|
|
## Code-Richtlinien
|
||
|
|
|
||
|
|
### Scripting
|
||
|
|
- **Shell-Scripts:** Bash (für Kompatibilität) oder Zsh (wenn zsh-spezifische Features genutzt werden)
|
||
|
|
- **Kommentare:** Auf Deutsch, Code-Variablen auf Englisch
|
||
|
|
- **Fehlerbehandlung:** Immer explizit prüfen, keine stillen Failures
|
||
|
|
- **Debugging:** Tim nutzt custom outputs statt Debugger
|
||
|
|
|
||
|
|
### Konfigurationsdateien
|
||
|
|
- **Format:** KDL für Zellij, TOML für Helix
|
||
|
|
- **Dokumentation:** Inline-Kommentare für nicht-offensichtliche Optionen
|
||
|
|
- **Pfade:** Absolute Pfade vermeiden, ~/ nutzen wo möglich
|
||
|
|
|
||
|
|
### Git-Workflow
|
||
|
|
- **Branches:** Main für stabile Features, Feature-Branches für Entwicklung
|
||
|
|
- **Commits:** Aussagekräftige Messages auf Deutsch
|
||
|
|
- **Remote:** zeus.turkey-court.ts.net/totlik/zellide.git
|
||
|
|
|
||
|
|
## Kommunikations-Präferenzen
|
||
|
|
|
||
|
|
**Bevorzugt:**
|
||
|
|
- Du-Form (nicht formal)
|
||
|
|
- Rückfragen stellen bei Unklarheiten
|
||
|
|
- Schritt-für-Schritt-Erklärungen
|
||
|
|
- Konkrete Code-Beispiele
|
||
|
|
|
||
|
|
**Vermeiden:**
|
||
|
|
- Zu viele Optionen gleichzeitig präsentieren
|
||
|
|
- Theoretische Abhandlungen ohne Code
|
||
|
|
- Annehmen was Tim will - lieber nachfragen
|
||
|
|
- Überspringen von Zwischen-Schritten
|
||
|
|
|
||
|
|
## Testing & Iteration
|
||
|
|
|
||
|
|
### Test-Projekte
|
||
|
|
- **Primär:** ~/git/infrastructure (Ansible, Docker-Compose, Configs)
|
||
|
|
- **Später:** Rust-Projekte nach erfolgreicher IDE-Migration
|
||
|
|
|
||
|
|
### Iterativer Prozess
|
||
|
|
1. Kleine, testbare Einheit entwickeln
|
||
|
|
2. Mit echtem Use-Case testen
|
||
|
|
3. Feedback einholen
|
||
|
|
4. Anpassen und erweitern
|
||
|
|
5. Erst dann zum nächsten Feature
|
||
|
|
|
||
|
|
### Erfolgs-Kriterien
|
||
|
|
- Fühlt sich flüssig an wie VSCode
|
||
|
|
- Keine nervigen Edge-Cases im täglichen Workflow
|
||
|
|
- Gleiche Erfahrung lokal und remote
|
||
|
|
- Tim kann seine Muscle-Memory aufbauen
|
||
|
|
|
||
|
|
## Besondere Hinweise
|
||
|
|
|
||
|
|
### Helix vs Vim
|
||
|
|
- Tim kommt von Vim-Bindings
|
||
|
|
- Helix verwendet selection-first statt verb-noun
|
||
|
|
- Geduld in der Umgewöhnungsphase
|
||
|
|
- Keybind-Referenzen bereitstellen
|
||
|
|
|
||
|
|
### Session-Management
|
||
|
|
- Session-Namen sind wichtig für Übersicht
|
||
|
|
- Präfix-System konsequent nutzen
|
||
|
|
- Keine Session-Verschachtelung
|
||
|
|
- Auto-Cleanup von alten Sessions ist nice-to-have, nicht kritisch
|
||
|
|
|
||
|
|
### Erweiterbarkeit
|
||
|
|
- System soll wachsen können
|
||
|
|
- Heute IDE, morgen vielleicht Monitor-Dashboards
|
||
|
|
- Prefix-System ermöglicht einfache Erweiterung
|
||
|
|
- Nicht zu früh über-engineeren
|
||
|
|
|
||
|
|
## Nächste Milestones
|
||
|
|
|
||
|
|
1. **Phase 1:** Basis-Setup (Zsh-Hooks, Detection, Helper-Scripts)
|
||
|
|
2. **Phase 2:** Zellij-Layout + Helix-Config für bestehende Sprachen
|
||
|
|
3. **Phase 3:** Testing mit infrastructure-Repo
|
||
|
|
4. **Phase 4:** Server-Migration vorbereiten
|
||
|
|
5. **Phase 5:** Rust-Umgebung einrichten
|
||
|
|
|
||
|
|
## Fragen bei Unsicherheit
|
||
|
|
|
||
|
|
Bevor du Code schreibst oder Entscheidungen triffst:
|
||
|
|
- Ist das die einfachste Lösung?
|
||
|
|
- Braucht Tim das wirklich jetzt?
|
||
|
|
- Passt es zum iterativen Ansatz?
|
||
|
|
- Hast du alle Informationen oder solltest du nachfragen?
|
||
|
|
|
||
|
|
**Im Zweifel: Nachfragen!** Tim gibt lieber klares Feedback als dass er später umbauen muss.
|