wip: Sicherungs-Commit aller Änderungen seit April + Arbeitsstruktur (CLAUDE.md, ROADMAP.md, PROGRESS.md, Autopilot)
6 Wochen uncommittete Arbeit (Voice-Channels, LiveKit-Manager, Settings-Modal u.v.m.) als ein WIP-Commit gesichert, damit nichts verloren geht und der Pi den aktuellen Stand klonen kann. Thematische Aufarbeitung: siehe ROADMAP M0. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01CPrAGBxBT6GfPXzeWQ4AXb
This commit is contained in:
Bernd Steckmeister
co-authored by
Claude Fable 5
Claude Fable 5
parent
d706ace35f
commit
25ed765a03
@@ -0,0 +1,70 @@
|
||||
# Pyramid – Arbeitsregeln für Claude
|
||||
|
||||
Pyramid ist Bernds eigener Matrix-Client (Flutter, kein FluffyChat-Fork). Bernd ist
|
||||
**kein Entwickler** – er gibt Ziele und Prioritäten vor, Claude trifft die technischen
|
||||
Entscheidungen und erklärt sie in einfachem Deutsch. Die App ist bei echten Nutzern im
|
||||
Einsatz (u. a. Uta) – Stabilität und Datensicherheit gehen vor Feature-Tempo.
|
||||
|
||||
**Dies ist das einzige aktuelle Repo:** `C:\Users\nordm\pyramid - Kopie\`.
|
||||
(`C:\Users\nordm\pyramid` und `C:\Users\nordm\MatrixPi\pyramid` sind veraltete
|
||||
April-Schnappschüsse – dort NIE arbeiten.)
|
||||
|
||||
## Infrastruktur
|
||||
|
||||
- Homeserver: Continuwuity auf dem Pi5 (`steggi-matrix.work`)
|
||||
- LiveKit/TURN: Hetzner „Leuchtturm" → `wss://livekit.steggi-matrix.work` (API-Key LKMatrixPi), coturn 94.130.78.116:3478
|
||||
- Git-Remote: Gitea auf dem Pi (`http://192.168.178.71:3000/steggi/pyramid.git`) – Push = Backup
|
||||
- Push-Benachrichtigungen: FCM + Sygnal auf dem Pi (Memory „Pyramid Push" lesen, bevor daran gearbeitet wird)
|
||||
- Vollbackup vom 2026-07-03: `MatrixPi\backups\pyramid-kopie_backup_2026-07-03.tar.gz`
|
||||
|
||||
## Arbeitszyklus (IMMER einhalten)
|
||||
|
||||
Jede Session – egal ob frisch gestartet oder fortgesetzt – läuft so:
|
||||
|
||||
1. **Einlesen:** `PROGRESS.md` (letzter Stand, Stolperfallen) und `ROADMAP.md`
|
||||
(nächster offener Punkt) lesen. NIE Arbeit doppelt machen, die dort als erledigt steht.
|
||||
2. **Einen Punkt nehmen:** den obersten nicht abgehakten Punkt des aktuellen Meilensteins
|
||||
aus `ROADMAP.md` – nicht mehrere gleichzeitig, keine Sprünge in spätere Meilensteine.
|
||||
3. **Umsetzen & prüfen:** Nach der Änderung mindestens `flutter analyze` sauber bekommen;
|
||||
wo sinnvoll `flutter test` und `flutter run -d windows` (schnellster Praxistest).
|
||||
4. **Protokollieren:** `PROGRESS.md` aktualisieren (Format siehe dort) und den Punkt in
|
||||
`ROADMAP.md` abhaken.
|
||||
5. **Commit + Push:** kleiner `git commit` (`feat:`/`fix:`/`refactor:`/`chore:`) und
|
||||
`git push origin master` (Gitea = Backup). Lieber 5 kleine Commits als ein riesiger.
|
||||
6. Weiter mit dem nächsten Punkt, solange Kontingent/Zeit da ist.
|
||||
|
||||
Wird eine Session mitten in einem Punkt abgebrochen (Limit erreicht), MUSS der letzte
|
||||
Eintrag in `PROGRESS.md` den Zwischenstand beschreiben: was halb fertig ist, welche
|
||||
Dateien angefasst wurden, was der nächste konkrete Handgriff ist.
|
||||
|
||||
## Qualitätsleitplanken
|
||||
|
||||
- **Kein Aussperren, kein Datenverlust:** Alles rund um Login, Sessions, Verschlüsselung
|
||||
und Key-Backup ist heilig. Der Uta-Random-Logout-Bug zeigt: Fehlerpfade dürfen NIE in
|
||||
einem stillen Logout enden. Änderungen daran immer mit Test: Login → Nachrichten →
|
||||
Logout → erneuter Login → alte verschlüsselte Nachrichten noch lesbar?
|
||||
- **Nach dem Refactoring (M2) gilt:** keine Verhaltensänderung ohne Not – Refactoring
|
||||
heißt gleiche Funktion, bessere Struktur. Nach jedem Refactoring-Schritt App starten
|
||||
und Kernflows prüfen (Login, Raum öffnen, Nachricht senden, Voice-Channel beitreten).
|
||||
- **Keine Secrets ins Repo:** Tokens, Recovery-Keys, Passwörter, Keystore-Dateien
|
||||
niemals committen (Signing-Keys liegen in `Documents\pyramid_keys_20260425.txt`).
|
||||
- **Modularität (Bernd wichtig!):** Die Architektur muss aus austauschbaren Bausteinen
|
||||
bestehen – jedes Feature (Calls, Streaming, Push, Chat-Timeline, …) hinter einer klaren,
|
||||
schmalen Schnittstelle, sodass man einen alten Baustein durch einen neuen ersetzen kann,
|
||||
ohne den Rest anzufassen. Beim Refactoring (M2) ist das DAS Leitprinzip; bei jedem neuen
|
||||
Feature fragen: „Könnte man dieses Modul in einem Jahr komplett neu schreiben, ohne
|
||||
andere Module zu ändern?"
|
||||
- **Abhängigkeiten:** neue Pakete nur mit gutem Grund, etabliert und gepflegt.
|
||||
- **Umgebung beachten:** Auf dem Pi (SSH/tmux-Sessions) ist evtl. kein Flutter-Toolchain
|
||||
verfügbar. Dann trotzdem sauber arbeiten, aber jeden Schritt in PROGRESS.md als
|
||||
„UNGETESTET (Pi)" markieren – der nächste PC-Lauf holt `flutter analyze` + Praxistest nach.
|
||||
- **Bernd fragen** nur bei echten Richtungsentscheidungen (UX-Geschmack, Priorität) –
|
||||
Fragen in PROGRESS.md unter „Fragen an Bernd" sammeln statt die Session zu blockieren.
|
||||
|
||||
## Nützliches Wissen
|
||||
|
||||
- Discord ist die UX-Referenz für Calls/Voice-Channels (Join/Leave, Nutzer-Lautstärke,
|
||||
Geräteauswahl, Noise Suppression, Streaming-Qualitätswahl).
|
||||
- `CHANGES.md` ist ein automatisches Änderungslog (Hook) – nicht von Hand pflegen.
|
||||
- Windows-Build ist der schnellste Testweg; Android-Release über das Release-Skript
|
||||
(siehe Commit d706ace), signiert – Play-Protect-Warnung siehe ROADMAP M6.
|
||||
Reference in New Issue
Block a user