chore(repo): checkpoint current capakraken implementation state

This commit is contained in:
2026-03-29 12:47:12 +02:00
parent beae1a5d6e
commit 47e4d701ff
94 changed files with 4283 additions and 1710 deletions
+1 -1
View File
@@ -8,4 +8,4 @@ Most of this plan has already been implemented:
- admin system settings for AI configuration
- AI summary generation and resource detail UI
Do not use this file as an active backlog. Remaining product work belongs in [docs/product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md), and completed implementation detail is reflected in the codebase and [LEARNINGS.md](/home/hartmut/Documents/Copilot/planarchy/LEARNINGS.md).
Do not use this file as an active backlog. Remaining product work belongs in [docs/product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md), and completed implementation detail is reflected in the codebase and [LEARNINGS.md](/home/hartmut/Documents/Copilot/capakraken/LEARNINGS.md).
@@ -12,4 +12,4 @@ Examples that are no longer current:
- Redis-backed SSE work has already landed
- Playwright E2E coverage is no longer empty
Use [product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md) for the active backlog and [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/planarchy/research/v2-architecture-proposal-2026-03-11.md) for the still-relevant strategic direction.
Use [product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md) for the active backlog and [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/capakraken/research/v2-architecture-proposal-2026-03-11.md) for the still-relevant strategic direction.
@@ -1,3 +1,3 @@
# Archived Proposal Note
The CGI workbook analysis and implementation proposal were merged into [estimating-extension-design.md](/home/hartmut/Documents/Copilot/planarchy/docs/estimating-extension-design.md) so the estimating work now has one canonical document.
The CGI workbook analysis and implementation proposal were merged into [estimating-extension-design.md](/home/hartmut/Documents/Copilot/capakraken/docs/estimating-extension-design.md) so the estimating work now has one canonical document.
@@ -1,3 +1,3 @@
# Archived Mapping Note
The field mapping table was merged into [estimating-extension-design.md](/home/hartmut/Documents/Copilot/planarchy/docs/estimating-extension-design.md) so the estimating design, workbook analysis, and implementation plan live in one canonical file.
The field mapping table was merged into [estimating-extension-design.md](/home/hartmut/Documents/Copilot/capakraken/docs/estimating-extension-design.md) so the estimating design, workbook analysis, and implementation plan live in one canonical file.
+1 -1
View File
@@ -16,4 +16,4 @@ Still conceptually relevant, but no longer the canonical backlog:
- staffing suggestion scalability
- index strategy for larger datasets
Use [product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md) for active prioritization and keep this file only as archive context.
Use [product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md) for active prioritization and keep this file only as archive context.
+1 -1
View File
@@ -8,4 +8,4 @@ That work is now only partially relevant as an archive:
- several sorting/view-state pieces were implemented
- Blueprints parity still appears open
The active backlog now lives in [docs/product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md).
The active backlog now lives in [docs/product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md).
+1 -1
View File
@@ -2,7 +2,7 @@
This sprint plan mixed active refactor work with implementation mechanics that are now stale.
The still-relevant backlog from this document is tracked centrally in [product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md):
The still-relevant backlog from this document is tracked centrally in [product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md):
- widget config typing and layout versioning
- registry-driven dashboard rendering
@@ -0,0 +1,237 @@
# Technischer Rename: capakraken → capakraken — Migrationsplan
## Uebersicht
| Kategorie | Dateien | Vorkommen | Aufwand | Risiko |
|-----------|---------|-----------|---------|--------|
| **A: Package-Namen & Imports** | 277 | 548 | 3 Std | KRITISCH |
| **B: Datenbank & Docker** | 26 | 32 | 30 Min | KRITISCH |
| **C: CI/CD & Scripts** | 13 | 45 | 15 Min | HOCH |
| **D: Dokumentation** | 30 | 200+ | 1 Std | MITTEL |
| **E: Test-Daten & Emails** | 35 | 85 | 30 Min | HOCH |
| **Gesamt** | **372** | **910+** | **~5 Std** | |
---
## Phase 1: Package-Namen & Imports (KRITISCH)
### 1.1 Package-Namen umbenennen (12 package.json)
| Alt | Neu |
|-----|-----|
| `@capakraken/api` | `@capakraken/api` |
| `@capakraken/application` | `@capakraken/application` |
| `@capakraken/db` | `@capakraken/db` |
| `@capakraken/engine` | `@capakraken/engine` |
| `@capakraken/shared` | `@capakraken/shared` |
| `@capakraken/staffing` | `@capakraken/staffing` |
| `@capakraken/ui` | `@capakraken/ui` |
| `@capakraken/web` | `@capakraken/web` |
| `@capakraken/eslint-config` | `@capakraken/eslint-config` |
| `@capakraken/prettier-config` | `@capakraken/prettier-config` |
| `@capakraken/tsconfig` | `@capakraken/tsconfig` |
### 1.2 Import-Statements (277 Dateien, 548 Vorkommen)
```bash
# Globaler Find+Replace
find . -type f \( -name "*.ts" -o -name "*.tsx" \) \
-not -path "*/node_modules/*" -not -path "*/.next/*" \
-exec sed -i 's/@capakraken\//@capakraken\//g' {} +
```
### 1.3 tsconfig.json Path-Mappings (8 Dateien)
```
"@capakraken/*" → "@capakraken/*"
```
### 1.4 next.config.ts transpilePackages
```
"@capakraken/api" → "@capakraken/api" (6 Eintraege)
```
---
## Phase 2: Datenbank & Docker (KRITISCH)
### 2.1 Docker Compose (2 Dateien, 32 Vorkommen)
| Alt | Neu |
|-----|-----|
| `POSTGRES_DB: capakraken` | `POSTGRES_DB: capakraken` |
| `POSTGRES_USER: capakraken` | `POSTGRES_USER: capakraken` |
| `POSTGRES_PASSWORD: capakraken_dev` | `POSTGRES_PASSWORD: capakraken_dev` |
| `capakraken_pgdata` (Volume) | `capakraken_pgdata` |
| `capakraken_prod_pgdata` | `capakraken_prod_pgdata` |
| `capakraken_prod_redis` | `capakraken_prod_redis` |
| `admin@capakraken.dev` (pgAdmin) | `admin@capakraken.dev` |
### 2.2 Datenbank migrieren
```bash
# 1. Backup erstellen
docker exec capakraken-postgres-1 pg_dump -U capakraken capakraken > backup.sql
# 2. Neue DB + User erstellen
docker exec capakraken-postgres-1 psql -U postgres -c "
CREATE USER capakraken WITH PASSWORD 'capakraken_dev';
CREATE DATABASE capakraken OWNER capakraken;
GRANT ALL PRIVILEGES ON DATABASE capakraken TO capakraken;
"
# 3. Daten importieren
docker exec -i capakraken-postgres-1 psql -U capakraken capakraken < backup.sql
# 4. .env.local aktualisieren
DATABASE_URL=postgresql://capakraken:capakraken_dev@localhost:5433/capakraken
```
### 2.3 Environment-Dateien (3 Dateien)
```
DATABASE_URL=postgresql://capakraken:capakraken_dev@localhost:5433/capakraken
→ DATABASE_URL=postgresql://capakraken:capakraken_dev@localhost:5433/capakraken
```
---
## Phase 3: CI/CD & Scripts (HOCH)
### 3.1 GitHub Actions (.github/workflows/ci.yml, 25 Vorkommen)
```bash
sed -i 's/@capakraken\//@capakraken\//g' .github/workflows/ci.yml
sed -i 's/capakraken_test/capakraken_test/g' .github/workflows/ci.yml
sed -i 's/POSTGRES_USER: capakraken/POSTGRES_USER: capakraken/g' .github/workflows/ci.yml
sed -i 's/pg_isready -U capakraken/pg_isready -U capakraken/g' .github/workflows/ci.yml
```
### 3.2 Root package.json Scripts (9 Vorkommen)
```bash
sed -i 's/@capakraken\//@capakraken\//g' package.json
```
### 3.3 Start/Stop/Restart Scripts
```bash
sed -i 's/capakraken/capakraken/g' scripts/start.sh scripts/stop.sh scripts/restart.sh
```
### 3.4 Dependabot
```bash
sed -i 's/capakraken/capakraken/g' .github/dependabot.yml
```
---
## Phase 4: Test-Daten & Emails (HOCH)
### 4.1 Seed-Dateien (2 Dateien)
```
admin@capakraken.dev → admin@capakraken.dev
manager@capakraken.dev → manager@capakraken.dev
viewer@capakraken.dev → viewer@capakraken.dev
```
### 4.2 E2E-Tests (11 Spec-Dateien)
```bash
find apps/web/e2e -name "*.spec.ts" \
-exec sed -i 's/@capakraken\.dev/@capakraken.dev/g' {} +
```
### 4.3 LocalStorage-Keys
```
capakraken_theme → capakraken_theme
capakraken_sidebar_collapsed → capakraken_sidebar_collapsed
capakraken_prefs → capakraken_prefs
capakraken_dashboard_v1 → capakraken_dashboard_v1
capakraken_pwa_dismiss → capakraken_pwa_dismiss
capakraken-chat-messages → capakraken-chat-messages
```
### 4.4 Email-Defaults (3 Dateien)
```
noreply@capakraken.app → noreply@capakraken.app
```
---
## Phase 5: Dokumentation (MITTEL)
### 5.1 Kern-Dokumente
```bash
# Globaler Replace in allen .md Dateien
find . -name "*.md" -not -path "*/node_modules/*" \
-exec sed -i 's/capakraken/capakraken/g; s/CapaKraken/CapaKraken/g; s/plANARCHY/CapaKraken/g' {} +
```
### 5.2 CLAUDE.md aktualisieren
- Projektname, Monorepo-Struktur, Package-Referenzen
### 5.3 Code-Kommentare
```bash
grep -rn "capakraken" --include="*.ts" --include="*.tsx" . \
| grep -v node_modules | grep -v .next | grep "\/\/"
# Manuell pruefen und aendern
```
---
## Phase 6: Verzeichnis-Umbenennung (OPTIONAL)
### Nicht umbenennen (zu riskant):
- `packages/` Verzeichnisnamen bleiben (`packages/api/`, nicht `packages/capakraken-api/`)
- Git-Remote URL aendern ist ein separater Schritt beim Hoster
### Umbenennen (sicher):
- Docker-Container-Namen aendern sich automatisch durch docker-compose Aenderungen
---
## Phase 7: Verifikation
```bash
# 1. Node Modules neu installieren
rm -rf node_modules apps/web/node_modules packages/*/node_modules
pnpm install
# 2. Prisma regenerieren
pnpm db:generate
# 3. TypeScript pruefen
pnpm --filter @capakraken/web exec tsc --noEmit
# 4. Unit Tests
pnpm test:unit
# 5. Build
pnpm --filter @capakraken/web exec next build
# 6. E2E (nach Seed mit neuen Emails)
pnpm --filter @capakraken/db db:seed
pnpm test:e2e
```
---
## Risiken
| Risiko | Mitigation |
|--------|-----------|
| **pnpm Workspace-Aufloesung bricht** | Nach Rename sofort `pnpm install` ausfuehren |
| **Import-Pfade nicht komplett ersetzt** | `grep -rn "@capakraken" --include="*.ts"` als Kontrolle |
| **Docker Volumes mit alten Namen** | Alte Volumes manuell loeschen: `docker volume rm capakraken_pgdata` |
| **Bestehende User-Sessions invalide** | Alle User muessen sich neu einloggen (NEXTAUTH_SECRET bleibt gleich) |
| **LocalStorage-Keys veraltet** | Alte Keys werden ignoriert, neue Defaults greifen |
| **Git-History referenziert alten Namen** | Kein Problem — History bleibt unveraendert |
---
## Empfohlene Reihenfolge
1. **Backup erstellen** (DB + Git Tag)
2. **Phase 1** durchfuehren (Package-Namen + Imports)
3. `pnpm install` → pruefen ob Workspace funktioniert
4. **Phase 2** (Docker + DB Migration)
5. **Phase 3** (CI/CD + Scripts)
6. **Phase 4** (Tests + Emails)
7. `pnpm test:unit` → alle Tests gruen?
8. **Phase 5** (Dokumentation)
9. **Phase 7** (Vollstaendige Verifikation)
10. **Commit + PR** als einzelner "chore: rename capakraken → capakraken" Commit
@@ -0,0 +1,77 @@
# Review-Report — 2026-03-15 (3D Computation Graph)
## Ergebnis: ✅ Bestanden
Alle Quality Gates bestanden. Keine kritischen Probleme. Zwei Minor-Empfehlungen.
## Quality Gates
| Gate | Status | Details |
|------|--------|---------|
| Engine Tests | ✅ | 283/283 (19 files) |
| Staffing Tests | ✅ | 37/37 (3 files) |
| API Tests | ✅ | 209/209 (21 files) |
| Application Tests | ✅ | 67/67 (15 files) |
| TypeScript (web) | ✅ | 0 errors (excl. BlueprintFieldEditor TS2589) |
| TypeScript (api) | ✅ | 0 errors |
## Code-Review-Checkliste
### Architektur
- [x] Keine zirkulaeren Abhaengigkeiten — `api → engine/shared/db` (erlaubt)
- [x] `engine` und `staffing` unveraendert, keine DB-Imports
- [x] Neuer Router `computationGraph` in `index.ts` registriert
- [x] Keine SSE-Events noetig (read-only Feature, keine Mutations)
### TypeScript & Typsicherheit
- [x] `any`-Types nur an `react-force-graph-3d`-Grenzen mit `eslint-disable` Kommentar (6 Stellen)
- [x] Prisma-Enums gecastet: `pa.status as unknown as string` + `as Parameters<typeof computeBudgetStatus>[2]`
- [x] JSONB-Feld gecastet: `commercialTerms as { contingencyPercent?: number; ... } | null`
- [x] `scheduleRules as SpainScheduleRule | null` korrekt
- [x] `exactOptionalPropertyTypes` beachtet: `...(formula ? { formula } : {})` Pattern
### Datenbank & Prisma
- [x] Keine Schema-Aenderungen — rein lesende Queries
- [x] Geldbetraege in Integer-Cents: `lcrCents`, `dailyCostCents`, `budgetCents` etc.
- [x] Kein Seed noetig (kein neues Modell)
### UI & Komponenten
- [x] `"use client"` Direktive gesetzt
- [x] Three.js via `dynamic(() => import(...), { ssr: false })` — kein SSR-Problem
- [x] Neue Seite in AppShell-Navigation ergaenzt ("Computation Graph" unter Analytics)
- [x] Opake Hintergruende: `bg-zinc-50`, `bg-zinc-900/95` (95% ist akzeptabel fuer Tooltip)
### Sicherheit
- [x] Beide Procedures nutzen `controllerProcedure` (ADMIN + MANAGER + CONTROLLER)
- [x] Keine Raw-Queries — nur Prisma `findMany`/`findUniqueOrThrow`
- [x] Keine sensiblen Daten im Response — nur berechnete Werte und Formeln
## Gefundene Probleme
### Kritisch
Keine.
### Minor
1. **Duplizierte Types**`GraphNode`, `GraphLink`, `Domain` sind sowohl in `packages/api/.../computation-graph.ts` als auch `apps/web/.../domain-colors.ts` definiert. Funktioniert (tRPC inferiert die Typen), aber bei Aenderungen muss man beide Stellen anpassen. Empfehlung: Types nach `@capakraken/shared` verschieben wenn sie stabil sind.
2. **`project.list` Query** — Der Client castet das Ergebnis via `(projectData as any)?.projects ?? (projectData as any)`. Das deutet auf Unsicherheit ueber das Return-Format hin. Sollte nach dem Merge geprueft werden, ob `.projects` oder direkt das Array zurueckkommt.
### Empfehlungen
1. **Bundle Size Monitoring**`three` und `react-force-graph-3d` fuegen ~700KB (gzipped) hinzu. Dank `dynamic import` + `{ ssr: false }` trifft das nur die Computation Graph Seite. Trotzdem: bei der naechsten Bundle-Analyse verifizieren.
2. **E2E-Test** — Aktuell kein Test fuer die neue Seite. Ein Playwright-Smoke-Test (`navigate to /analytics/computation-graph, expect canvas element`) waere sinnvoll.
3. **Link Formula Labels** — Plan sah Three.js Text-Sprites auf Kanten vor (E3). Die Formeln sind in den Link-Daten vorhanden (`formula` Feld), werden aber aktuell nur bei Hover (indirekt ueber Node-Tooltip) sichtbar. Kann als Follow-up ergaenzt werden.
## Learnings-Vorschlag fuer LEARNINGS.md
```markdown
### react-force-graph-3d in Next.js 15
- Muss als `dynamic(() => import("react-force-graph-3d"), { ssr: false })` geladen werden
- React 19 Kompatibilitaet: funktioniert, aber TypeScript-Generics sind loose — `as any` Cast + eslint-disable noetig bei Callbacks (`onNodeClick`, `nodeThreeObject`, `linkColor`)
- Node-Rendering via Canvas-basierte Three.js Sprites (nicht HTML-Overlays) — performanter bei 50+ Knoten
- `warmupTicks={50}` + `cooldownTicks={0}` verhindert die Kraft-Simulation und nutzt stattdessen die fixen `fx/fy/fz` Positionen
```