chore(repo): checkpoint current capakraken implementation state
This commit is contained in:
+4
-4
@@ -1,4 +1,4 @@
|
||||
# Planarchy – Projekt-Learnings
|
||||
# CapaKraken – Projekt-Learnings
|
||||
|
||||
## Format
|
||||
**Datum | Kategorie | Problem → Lösung**
|
||||
@@ -122,7 +122,7 @@ For modal focus trapping: create a `panelRef = useRef<HTMLDivElement>(null)`, ca
|
||||
|
||||
### 2026-03-05 | Build | MCP-Server im falschen Projektpfad registriert
|
||||
**Problem:** `claude mcp add` wurde aus einem Unterverzeichnis (`packages/db`) heraus ausgeführt. Die Server wurden unter dem Unterverzeichnis-Pfad registriert, nicht unter dem Projekt-Root.
|
||||
**Lösung:** MCP-Server-Einträge manuell in `~/.claude.json` in den richtigen Projekt-Pfad (`/home/hartmut/Documents/Copilot/planarchy`) verschieben.
|
||||
**Lösung:** MCP-Server-Einträge manuell in `~/.claude.json` in den richtigen Projekt-Pfad (`/home/hartmut/Documents/Copilot/capakraken`) verschieben.
|
||||
**Für künftige Projekte:** `claude mcp add` immer vom Projekt-Root aus ausführen.
|
||||
|
||||
---
|
||||
@@ -181,7 +181,7 @@ For modal focus trapping: create a `panelRef = useRef<HTMLDivElement>(null)`, ca
|
||||
### 2026-03-06 | Architektur | Redis Pub/Sub für SSE
|
||||
|
||||
**Problem:** SSE Event-Bus war ein In-Memory-Singleton, funktioniert nicht bei mehreren Server-Instanzen.
|
||||
**Lösung:** `ioredis` in `@capakraken/api` hinzugefügt. Publisher schreibt Events in Redis-Channel `planarchy:sse`, Subscriber auf jeder Instanz empfängt und liefert lokal aus. Graceful Degradation: bei Redis-Ausfall weiterhin lokale Delivery.
|
||||
**Lösung:** `ioredis` in `@capakraken/api` hinzugefügt. Publisher schreibt Events in Redis-Channel `capakraken:sse`, Subscriber auf jeder Instanz empfängt und liefert lokal aus. Graceful Degradation: bei Redis-Ausfall weiterhin lokale Delivery.
|
||||
**Import-Pattern:** `import { Redis } from "ioredis"` (named export, nicht default) – notwendig mit `moduleResolution: NodeNext` + ioredis v5.
|
||||
**Offene Frage:** In Dev-Umgebung reicht lokale Delivery; Redis läuft auf Port 6380 via Docker Compose.
|
||||
|
||||
@@ -313,7 +313,7 @@ prisma.user.upsert({ where: ..., update: { passwordHash: adminHash }, create: {
|
||||
|
||||
### 2026-03-06 | Architektur | Granulares RBAC-System: Permission-Override-Muster
|
||||
|
||||
**Kontext:** Planarchy hatte 3 hartkodierte Procedure-Levels (protectedProcedure → managerProcedure → adminProcedure) ohne Granularität. Ziel: neue Rolle CONTROLLER + individuelle Permission-Overrides pro User.
|
||||
**Kontext:** CapaKraken hatte 3 hartkodierte Procedure-Levels (protectedProcedure → managerProcedure → adminProcedure) ohne Granularität. Ziel: neue Rolle CONTROLLER + individuelle Permission-Overrides pro User.
|
||||
|
||||
**Lösung:** Zweigeteiltes System:
|
||||
1. **`ROLE_DEFAULT_PERMISSIONS`** — statische Lookup-Tabelle: jede SystemRole hat eine Default-Menge an PermissionKeys.
|
||||
|
||||
Reference in New Issue
Block a user