chore(repo): checkpoint current capakraken implementation state
This commit is contained in:
+18
-16
@@ -1,20 +1,20 @@
|
||||
# Documentation Index
|
||||
|
||||
**Date:** 2026-03-12
|
||||
**Purpose:** Single entry point for active Planarchy product and technical documentation.
|
||||
**Purpose:** Single entry point for active CapaKraken product and technical documentation.
|
||||
|
||||
## Canonical Documents
|
||||
|
||||
| Topic | File | Use |
|
||||
|---|---|---|
|
||||
| Active roadmap and open gaps | [product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md) | Primary backlog and current delivery order |
|
||||
| Estimating system design | [estimating-extension-design.md](/home/hartmut/Documents/Copilot/planarchy/docs/estimating-extension-design.md) | Workbook analysis, field mapping, and implementation plan |
|
||||
| Dispo import implementation | [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/planarchy/docs/dispo-import-implementation.md) | Clean-slate Dispo v2 import design, mapping rules, staging flow, and commit policy |
|
||||
| Dispo import ticket pack | [dispo-import-implementation-tickets.md](/home/hartmut/Documents/Copilot/planarchy/docs/dispo-import-implementation-tickets.md) | Worker-ready delivery slices, dependencies, and acceptance criteria for the Dispo import |
|
||||
| Demand/assignment cutover guide | [demand-assignment-migration-cutover.md](/home/hartmut/Documents/Copilot/planarchy/docs/demand-assignment-migration-cutover.md) | Go/no-go criteria, staged cutover, and readiness artifact policy |
|
||||
| Strategic architecture direction | [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/planarchy/research/v2-architecture-proposal-2026-03-11.md) | Longer-horizon architecture target |
|
||||
| Implementation history | [LEARNINGS.md](/home/hartmut/Documents/Copilot/planarchy/LEARNINGS.md) | Append-only decisions and lessons |
|
||||
| Agent/project guidance | [CLAUDE.md](/home/hartmut/Documents/Copilot/planarchy/CLAUDE.md) | Working conventions and quality gates |
|
||||
| Active roadmap and open gaps | [product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md) | Primary backlog and current delivery order |
|
||||
| Estimating system design | [estimating-extension-design.md](/home/hartmut/Documents/Copilot/capakraken/docs/estimating-extension-design.md) | Workbook analysis, field mapping, and implementation plan |
|
||||
| Dispo import implementation | [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/capakraken/docs/dispo-import-implementation.md) | Clean-slate Dispo v2 import design, mapping rules, staging flow, and commit policy |
|
||||
| Dispo import ticket pack | [dispo-import-implementation-tickets.md](/home/hartmut/Documents/Copilot/capakraken/docs/dispo-import-implementation-tickets.md) | Worker-ready delivery slices, dependencies, and acceptance criteria for the Dispo import |
|
||||
| Demand/assignment cutover guide | [demand-assignment-migration-cutover.md](/home/hartmut/Documents/Copilot/capakraken/docs/demand-assignment-migration-cutover.md) | Go/no-go criteria, staged cutover, and readiness artifact policy |
|
||||
| Strategic architecture direction | [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/capakraken/research/v2-architecture-proposal-2026-03-11.md) | Longer-horizon architecture target |
|
||||
| Implementation history | [LEARNINGS.md](/home/hartmut/Documents/Copilot/capakraken/LEARNINGS.md) | Append-only decisions and lessons |
|
||||
| Agent/project guidance | [CLAUDE.md](/home/hartmut/Documents/Copilot/capakraken/CLAUDE.md) | Working conventions and quality gates |
|
||||
|
||||
## Archive Policy
|
||||
|
||||
@@ -30,10 +30,12 @@ Archive-note files should point back to the relevant canonical document instead
|
||||
|
||||
All archived markdown plan and proposal files now live under `docs/old-markdowns/`.
|
||||
|
||||
- [plan.md](/home/hartmut/Documents/Copilot/planarchy/docs/old-markdowns/plan.md)
|
||||
- [PLAN_SKILLMATRIX.md](/home/hartmut/Documents/Copilot/planarchy/docs/old-markdowns/PLAN_SKILLMATRIX.md)
|
||||
- [refactor-sprint-plan.md](/home/hartmut/Documents/Copilot/planarchy/docs/old-markdowns/refactor-sprint-plan.md)
|
||||
- [estimating-field-mapping.md](/home/hartmut/Documents/Copilot/planarchy/docs/old-markdowns/estimating-field-mapping.md)
|
||||
- [cgi-breakdown-implementation-proposal.md](/home/hartmut/Documents/Copilot/planarchy/docs/old-markdowns/cgi-breakdown-implementation-proposal.md)
|
||||
- [architecture-evaluation-2026-03-06.md](/home/hartmut/Documents/Copilot/planarchy/docs/old-markdowns/architecture-evaluation-2026-03-06.md)
|
||||
- [perf-audit-2026-03-09.md](/home/hartmut/Documents/Copilot/planarchy/docs/old-markdowns/perf-audit-2026-03-09.md)
|
||||
- [plan.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/plan.md)
|
||||
- [rename-capakraken-to-capakraken-plan.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/rename-capakraken-to-capakraken-plan.md)
|
||||
- [PLAN_SKILLMATRIX.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/PLAN_SKILLMATRIX.md)
|
||||
- [refactor-sprint-plan.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/refactor-sprint-plan.md)
|
||||
- [estimating-field-mapping.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/estimating-field-mapping.md)
|
||||
- [cgi-breakdown-implementation-proposal.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/cgi-breakdown-implementation-proposal.md)
|
||||
- [architecture-evaluation-2026-03-06.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/architecture-evaluation-2026-03-06.md)
|
||||
- [perf-audit-2026-03-09.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/perf-audit-2026-03-09.md)
|
||||
- [review-report-2026-03-15-computation-graph.md](/home/hartmut/Documents/Copilot/capakraken/docs/old-markdowns/review-report-2026-03-15-computation-graph.md)
|
||||
|
||||
@@ -26,6 +26,7 @@ Trotzdem ist die Paritaet zur eigentlichen App/API noch nicht erreicht. Die groe
|
||||
|
||||
- `assistant.chat` baut den System Prompt, filtert die verfuegbaren Tools und laesst das Modell Tools aufrufen.
|
||||
- Der eigentliche Datenzugriff liegt fast komplett in `executeTool(...)` und den `executors` in `packages/api/src/router/assistant-tools.ts`.
|
||||
- Fuer Chargeability Report und Computation Graph nutzt der Assistant jetzt dieselben tRPC-Readmodels wie die eigentlichen Fachrouter, statt eine zweite Query-Logik zu pflegen.
|
||||
|
||||
### Permission-Gating
|
||||
|
||||
@@ -71,6 +72,11 @@ Es gibt aktuell vier Permission-/Scope-Ebenen:
|
||||
- basiert bereits auf denselben Timeline-Readmodels/Shift-Preview-Helfern wie die UI
|
||||
- Estimates: nur Suche, Detail und Anlegen, aber kein voller Lifecycle
|
||||
- Reports: `run_report` ist flexibel, deckt aber nicht die spezialisierten Report-/Analyse-Readmodels ab
|
||||
- Chargeability / Transparenz:
|
||||
- `get_chargeability_report`
|
||||
- `get_resource_computation_graph`
|
||||
- `get_project_computation_graph`
|
||||
- damit sind die wichtigsten tiefen Herleitungen fuer Chargeability, SAH, Feiertagsabzuege und Projektkalkulation jetzt auch im Assistant verfuegbar
|
||||
- Audit/History: nur einfache History-Abfragen, keine volle Audit-API
|
||||
- Notification/Tasking: Kernfaelle vorhanden, aber keine volle Reminder-/Task-/Notification-Paritaet
|
||||
- Country-/Location-Stammdaten: nur lesend und auch dort nur flach
|
||||
@@ -78,22 +84,18 @@ Es gibt aktuell vier Permission-/Scope-Ebenen:
|
||||
|
||||
### Vollstaendig fehlend oder fachlich nicht ausreichend
|
||||
|
||||
- Holiday-Calendar-Admin und Editor-Funktionen
|
||||
- Computation Graph fuer vollstaendige Herleitungen
|
||||
- Chargeability Report Readmodel
|
||||
- Webhook-Administration
|
||||
- System Settings / AI / SMTP / Image-Provider Administration
|
||||
- System Role Config Administration
|
||||
- Import/Export-Flows
|
||||
- User Self-Service und Preferences
|
||||
- Country- und Metro-City-Administration
|
||||
- Timeline-Mutationen und Dispo-spezifische Write-Flows
|
||||
- Voller Estimate-Lifecycle
|
||||
- Dispo-/Import-spezifische Flows
|
||||
|
||||
## Kritische Inkonsistenzen und Risiken
|
||||
|
||||
Stand 2026-03-28: Die frueheren P0s bei Notification-Scoping, `list_users`, Mutation-Audit und reinen Permission-Texten sind behoben. Die folgenden Punkte bleiben relevant.
|
||||
Stand 2026-03-29: Die frueheren P0s bei Notification-Scoping, `list_users`, Mutation-Audit und reinen Permission-Texten sind behoben. Holiday-Calendar-Lesezugriffe sowie Admin-Mutationen fuer Kalender und Entries sind jetzt im Assistant vorhanden. Die folgenden Punkte bleiben relevant.
|
||||
|
||||
### P0: Human-in-the-Loop ist serverseitig persistiert, aber noch nicht als vollwertiger Approval-Workspace ausgebaut
|
||||
|
||||
@@ -127,7 +129,7 @@ Der Assistant kann viele Kernfaelle, aber noch nicht denselben Arbeitsmodus wie
|
||||
|
||||
Konsequenz:
|
||||
|
||||
- Timeline-Readmodel-Paritaet ist jetzt fuer die wichtigsten read-only Faelle vorhanden, aber komplexe Write-, Audit-, Admin- und Estimate-Workflows bleiben teilweise unvollstaendig
|
||||
- Timeline-Readmodel- und die wichtigsten Timeline-Write-Paritaetsfaelle sind jetzt ueber dieselben Router-/Readmodel-Pfade verfuegbar, aber Audit-, Admin-, Import- und Estimate-Workflows bleiben teilweise unvollstaendig
|
||||
- tiefe Erklaerungen fuer Herleitungen und Governance sind noch nicht auf UI-Niveau
|
||||
|
||||
## Was der Assistant heute noch nicht "weiss"
|
||||
@@ -147,10 +149,21 @@ Die folgende Liste meint: Informationen, die in App/API bereits existieren oder
|
||||
Aktuell im Assistant vorhanden:
|
||||
|
||||
- aufgeloeste Feiertage nach Region oder Ressource
|
||||
- Holiday-Calendar-Stammdaten:
|
||||
- `list_holiday_calendars`
|
||||
- `get_holiday_calendar`
|
||||
- `preview_resolved_holiday_calendar`
|
||||
- Holiday-Calendar-Admin:
|
||||
- `create_holiday_calendar`
|
||||
- `update_holiday_calendar`
|
||||
- `delete_holiday_calendar`
|
||||
- `create_holiday_calendar_entry`
|
||||
- `update_holiday_calendar_entry`
|
||||
- `delete_holiday_calendar_entry`
|
||||
|
||||
Fehlend:
|
||||
Restluecke:
|
||||
|
||||
- die eigentlichen Kalenderobjekte und deren Pflegekontext
|
||||
- Country-/Metro-City-Stammdaten und tiefere Standortregeln sind weiterhin nicht in derselben Pflegebreite wie die eigentliche Admin-Oberflaeche abgedeckt
|
||||
|
||||
### Timeline und Disposition
|
||||
|
||||
@@ -160,25 +173,28 @@ Bereits vorhanden:
|
||||
- `get_timeline_holiday_overlays`
|
||||
- `get_project_timeline_context`
|
||||
- `preview_project_shift`
|
||||
- `update_timeline_allocation_inline`
|
||||
- `quick_assign_timeline_resource`
|
||||
- `batch_quick_assign_timeline_resources`
|
||||
- `batch_shift_timeline_allocations`
|
||||
- `apply_timeline_project_shift`
|
||||
- Reuse derselben Timeline-Readmodels und Shift-Preview-Helfer wie in `timelineRouter`
|
||||
- Reuse derselben Timeline-Mutationen via `createCallerFactory(timelineRouter)` statt Assistant-Sonderlogik
|
||||
- identische Manager-/Admin- und `manageAllocations`-Guards wie im normalen API-Pfad
|
||||
|
||||
Noch fehlend:
|
||||
|
||||
- vollstaendige Write-Paritaet fuer Timeline-/Dispo-Workflows
|
||||
- Inline-/Batch-Operationen der Timeline:
|
||||
- `updateAllocationInline`
|
||||
- `quickAssign`
|
||||
- `batchQuickAssign`
|
||||
- `batchShiftAllocations`
|
||||
- `applyShift`
|
||||
- Dispo-spezifische Import-/Workbook-Flows
|
||||
|
||||
Konsequenz:
|
||||
|
||||
- Der Assistant kann die wichtigsten Timeline-/Disposition-Readfaelle jetzt fachlich deutlich naeher an der UI abbilden, aber noch nicht denselben operativen Arbeitsmodus fuer Schreibaktionen und Imports.
|
||||
- Der Assistant kann die wichtigsten Timeline-/Disposition-Read- und Writefaelle jetzt fachlich und technisch auf derselben Basis wie die UI abbilden.
|
||||
- Offen bleiben vor allem Import-/Workbook-Flows und weitere Dispo-Spezialworkflows ausserhalb der Kernmutationen.
|
||||
|
||||
### Transparenz, Herleitungen und Berechnungsgraphen
|
||||
|
||||
Bereits vorhanden:
|
||||
|
||||
- Vollstaendige Computation-Graph-Daten fuer Resource- und Project-Views:
|
||||
- Herleitungsfaktoren
|
||||
- Formeln
|
||||
@@ -191,7 +207,8 @@ Konsequenz:
|
||||
|
||||
Konsequenz:
|
||||
|
||||
- Der Assistant kann zwar Teilantworten zu Chargeability/Budget geben, aber noch nicht dieselbe Erklaerungstiefe wie die spezialisierten Analyseansichten.
|
||||
- Der Assistant kann die wichtigsten Herleitungen jetzt auf derselben fachlichen Basis wie die spezialisierten Analyseansichten liefern.
|
||||
- Offen bleibt vor allem, diese Tiefe konsequent in weiteren Admin-, Audit- und Workflow-spezifischen Assistentenfaellen auszubauen.
|
||||
|
||||
### Audit, Verlauf und Governance
|
||||
|
||||
@@ -247,17 +264,19 @@ Konsequenz:
|
||||
|
||||
### Stammdaten fuer Laender und Orte
|
||||
|
||||
- Country-Details inklusive `scheduleRules`
|
||||
- Metro-City-Verwaltung
|
||||
- Country-/City-CRUD
|
||||
|
||||
Aktuell im Assistant vorhanden:
|
||||
|
||||
- `list_countries` mit relativ flachem Output
|
||||
- `list_countries` mit `scheduleRules`, Aktiv-Status und Metro-Cities
|
||||
- `get_country`
|
||||
- `create_country`
|
||||
- `update_country`
|
||||
- `create_metro_city`
|
||||
- `update_metro_city`
|
||||
- `delete_metro_city`
|
||||
|
||||
Fehlend:
|
||||
Restluecke:
|
||||
|
||||
- volle fachliche Pflege und die tieferen Standortregeln, die fuer Feiertage, SAH und Forecasts relevant sind
|
||||
- weitere standortbezogene Admin-Bereiche ausserhalb von Country/Metro-City
|
||||
|
||||
### Estimate-Lifecycle und Fachobjekte unterhalb des Estimates
|
||||
|
||||
@@ -292,7 +311,6 @@ Fehlend:
|
||||
|
||||
### Komplett fehlende Router-Paritaet
|
||||
|
||||
- `holidayCalendar`
|
||||
- `importExport`
|
||||
- `chargeabilityReport`
|
||||
- `computationGraph`
|
||||
@@ -330,7 +348,6 @@ Der Prompt suggeriert an mehreren Stellen mehr Paritaet, als technisch heute vor
|
||||
|
||||
### Problematische Aussagen
|
||||
|
||||
- "Urlaub, Feiertage" ist fuer Leseabfragen ok, aber nicht fuer Holiday-Calendar-Administration.
|
||||
- "Notifications anzeigen" ist fuer die Basisfaelle inzwischen sauberer gescoped, deckt aber weiterhin nicht die volle Notification-/Reminder-Paritaet der App ab.
|
||||
- "Dashboard-Details abrufen" stimmt nur fuer einen Teil der Dashboard-/Analysewelt.
|
||||
- "Den User zu relevanten Seiten navigieren" stimmt, ersetzt aber keine echte Daten-/Aktionsparitaet in Timeline, Holiday Editor oder Admin-Bereichen.
|
||||
@@ -405,9 +422,8 @@ Die Human-in-the-Loop-Regel ist inzwischen serverseitig erzwungen. Der Prompt so
|
||||
- update
|
||||
|
||||
3. Country-/City-Tools
|
||||
- Country-Detail
|
||||
- Country-Create/Update
|
||||
- City-Create/Update/Delete
|
||||
- Status: umgesetzt fuer Country-Detail, Country-Create/Update und City-Create/Update/Delete
|
||||
- offen bleiben nur weitergehende standortbezogene Admin-Readmodels ausserhalb dieses Stammdatenkerns
|
||||
|
||||
4. Webhook-Tools
|
||||
- list/get/create/update/delete/test
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Calculation Reference
|
||||
|
||||
How every number in Planarchy is derived. All monetary values are integer cents. All percentages are 0-100 integers unless noted.
|
||||
How every number in CapaKraken is derived. All monetary values are integer cents. All percentages are 0-100 integers unless noted.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+15
-13
@@ -1,8 +1,8 @@
|
||||
# Planarchy CI/CD Manual
|
||||
# CapaKraken CI/CD Manual
|
||||
|
||||
## Overview
|
||||
|
||||
Planarchy uses GitHub Actions for continuous integration and Docker for deployment. This document covers the full pipeline from code push to production.
|
||||
CapaKraken uses GitHub Actions for continuous integration and Docker for deployment. This document covers the full pipeline from code push to production.
|
||||
|
||||
---
|
||||
|
||||
@@ -120,7 +120,7 @@ Checks PostgreSQL and Redis connectivity. Returns 200 if all services are reacha
|
||||
|
||||
```bash
|
||||
# Build the image
|
||||
docker build -f Dockerfile.prod -t planarchy:latest .
|
||||
docker build -f Dockerfile.prod -t capakraken:latest .
|
||||
|
||||
# Test it locally
|
||||
docker compose -f docker-compose.prod.yml up -d
|
||||
@@ -142,9 +142,9 @@ The production image requires these environment variables:
|
||||
|
||||
```env
|
||||
# Required
|
||||
DATABASE_URL=postgresql://user:pass@host:5432/planarchy
|
||||
DATABASE_URL=postgresql://user:pass@host:5432/capakraken
|
||||
REDIS_URL=redis://host:6379
|
||||
NEXTAUTH_URL=https://planarchy.your-domain.com
|
||||
NEXTAUTH_URL=https://capakraken.your-domain.com
|
||||
NEXTAUTH_SECRET=<random-32-char-string>
|
||||
|
||||
# Optional
|
||||
@@ -153,7 +153,7 @@ SMTP_HOST=smtp.example.com
|
||||
SMTP_PORT=587
|
||||
SMTP_USER=notifications@example.com
|
||||
SMTP_PASSWORD=<password>
|
||||
SMTP_FROM=Planarchy <notifications@example.com>
|
||||
SMTP_FROM=CapaKraken <notifications@example.com>
|
||||
```
|
||||
|
||||
Generate a secure `NEXTAUTH_SECRET`:
|
||||
@@ -175,11 +175,11 @@ docker compose -f docker-compose.prod.yml up -d --build
|
||||
|
||||
# Run database migrations
|
||||
docker compose -f docker-compose.prod.yml exec app \
|
||||
npx prisma db push --skip-generate
|
||||
pnpm db:push
|
||||
|
||||
# Seed initial data (first deployment only)
|
||||
docker compose -f docker-compose.prod.yml exec app \
|
||||
npx prisma db seed
|
||||
pnpm db:seed
|
||||
```
|
||||
|
||||
### Manual deployment (current setup)
|
||||
@@ -188,10 +188,11 @@ Since `capakraken.hartmut-noerenberg.com` runs behind nginx:
|
||||
|
||||
```bash
|
||||
# On the server
|
||||
cd /home/hartmut/Documents/Copilot/planarchy
|
||||
cd /home/hartmut/Documents/Copilot/capakraken
|
||||
git pull origin main
|
||||
pnpm install
|
||||
pnpm --filter @capakraken/db exec prisma generate
|
||||
pnpm db:generate
|
||||
pnpm db:validate
|
||||
pnpm --filter @capakraken/web exec next build
|
||||
rm -rf apps/web/.next/cache # clear stale cache
|
||||
|
||||
@@ -283,7 +284,7 @@ Playwright test failure. Check the HTML report artifact in the GitHub Actions ru
|
||||
The Next.js process isn't running. Check:
|
||||
```bash
|
||||
ss -tlnp | grep 3100 # Is anything listening?
|
||||
tail -50 /tmp/planarchy-dev.log # Check app logs
|
||||
tail -50 /tmp/capakraken-dev.log # Check app logs
|
||||
```
|
||||
|
||||
Restart:
|
||||
@@ -296,7 +297,8 @@ pnpm dev & # or pnpm start for production mode
|
||||
|
||||
Usually a stale Prisma client after schema changes:
|
||||
```bash
|
||||
pnpm --filter @capakraken/db exec prisma generate
|
||||
pnpm db:generate
|
||||
pnpm db:validate
|
||||
rm -rf apps/web/.next
|
||||
pnpm --filter @capakraken/web exec next build
|
||||
# Restart the server
|
||||
@@ -312,5 +314,5 @@ curl -s https://capakraken.hartmut-noerenberg.com/api/ready | jq .
|
||||
If `postgres: "error"`, verify:
|
||||
```bash
|
||||
docker ps | grep postgres # Is container running?
|
||||
psql -h localhost -p 5433 -U planarchy -d planarchy # Can you connect?
|
||||
psql -h localhost -p 5433 -U capakraken -d capakraken # Can you connect?
|
||||
```
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Dispo Import Implementation Tickets
|
||||
|
||||
**Date:** 2026-03-14
|
||||
**Purpose:** Worker-ready implementation tickets for the clean-slate Dispo v2 import defined in [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/planarchy/docs/dispo-import-implementation.md).
|
||||
**Purpose:** Worker-ready implementation tickets for the clean-slate Dispo v2 import defined in [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/capakraken/docs/dispo-import-implementation.md).
|
||||
|
||||
## How To Use This Ticket Pack
|
||||
|
||||
@@ -68,7 +68,7 @@ Freeze the implementation assumptions so multiple workers do not diverge.
|
||||
|
||||
**Deliverables**
|
||||
|
||||
- decision log appended to [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/planarchy/docs/dispo-import-implementation.md)
|
||||
- decision log appended to [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/capakraken/docs/dispo-import-implementation.md)
|
||||
- explicit list of values to seed for roles and internal project buckets
|
||||
|
||||
**Acceptance Criteria**
|
||||
@@ -436,7 +436,7 @@ Apply part-time logic to resource availability without creating fake bookings.
|
||||
|
||||
**Goal**
|
||||
|
||||
Commit approved staged data into final Planarchy entities.
|
||||
Commit approved staged data into final CapaKraken entities.
|
||||
|
||||
**Scope**
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Dispo Import Implementation
|
||||
|
||||
**Date:** 2026-03-14
|
||||
**Purpose:** Canonical implementation document for replacing the current Planarchy planning dataset with a clean-slate import from the Dispo v2 Excel workbooks.
|
||||
**Purpose:** Canonical implementation document for replacing the current CapaKraken planning dataset with a clean-slate import from the Dispo v2 Excel workbooks.
|
||||
|
||||
## Scope
|
||||
|
||||
This document defines how Planarchy should ingest and normalize the following source workbooks:
|
||||
This document defines how CapaKraken should ingest and normalize the following source workbooks:
|
||||
|
||||
- `/samples/Dispov2/MandatoryDispoCategories_V3.xlsx`
|
||||
- `/samples/Dispov2/DISPO_2026.xlsx`
|
||||
@@ -13,7 +13,7 @@ This document defines how Planarchy should ingest and normalize the following so
|
||||
- `/samples/Dispov2/MV_DispoRoster.xlsx`
|
||||
- `/samples/Dispov2/Resource Roster_MASTER_FY26_CJ_20251201.xlsx`
|
||||
|
||||
The goal is not a raw workbook archive. The goal is a normalized Planarchy dataset that:
|
||||
The goal is not a raw workbook archive. The goal is a normalized CapaKraken dataset that:
|
||||
|
||||
- wipes existing database data and starts from a clean baseline
|
||||
- imports canonical reference data first
|
||||
@@ -79,7 +79,7 @@ Use as the source of:
|
||||
- resource enrichment when missing elsewhere
|
||||
- aggregate validation after commit
|
||||
|
||||
Do not treat PTD/MTD/YTD outputs as canonical source-of-truth records when Planarchy can derive them from normalized data.
|
||||
Do not treat PTD/MTD/YTD outputs as canonical source-of-truth records when CapaKraken can derive them from normalized data.
|
||||
|
||||
### 4. `MV_DispoRoster.xlsx`
|
||||
|
||||
@@ -151,20 +151,20 @@ The import commits into the existing planning model:
|
||||
|
||||
Relevant current schema anchors:
|
||||
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L178)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L235)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L334)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L372)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L460)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L754)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L780)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma#L815)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L178)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L235)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L334)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L372)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L460)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L754)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L780)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma#L815)
|
||||
|
||||
## Required Implementation Changes
|
||||
|
||||
### 1. Canonical Person Identity
|
||||
|
||||
Planarchy currently stores both `eid` and `enterpriseId` on `Resource`. The import should operate on a single canonical identity.
|
||||
CapaKraken currently stores both `eid` and `enterpriseId` on `Resource`. The import should operate on a single canonical identity.
|
||||
|
||||
Recommendation:
|
||||
|
||||
@@ -392,7 +392,7 @@ Assignments should be written only when a project or internal bucket is resolved
|
||||
| `[_NA] Public Holiday ... {NA}` | `Vacation(type=PUBLIC_HOLIDAY)` | preferred source of truth is geography-driven generation |
|
||||
| `[_NA] Weekend {NA}` | no vacation row | derive from calendar |
|
||||
|
||||
Public holiday implementation should integrate with the existing vacation planner and batch holiday support in [vacation.ts](/home/hartmut/Documents/Copilot/planarchy/packages/api/src/router/vacation.ts#L425).
|
||||
Public holiday implementation should integrate with the existing vacation planner and batch holiday support in [vacation.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/vacation.ts#L425).
|
||||
|
||||
### Availability and Part-Time Mapping
|
||||
|
||||
@@ -506,7 +506,7 @@ Recommended approach:
|
||||
|
||||
Known implementation gap:
|
||||
|
||||
- the chargeability forecast currently passes an empty `publicHolidays` list into SAH calculation in [chargeability-report.ts](/home/hartmut/Documents/Copilot/planarchy/packages/api/src/router/chargeability-report.ts#L167)
|
||||
- the chargeability forecast currently passes an empty `publicHolidays` list into SAH calculation in [chargeability-report.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/chargeability-report.ts#L167)
|
||||
|
||||
Required follow-up:
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**Date:** 2026-03-13
|
||||
**Related workbook:** `samples/CGIBreakdown_Template/Template_CGI-Breakdown+Calc_25Dez_V0.976_251212_beta_LCR-Update.xlsx`
|
||||
**Purpose:** Canonical design, field mapping, and implementation plan for a browser-based estimating system in Planarchy.
|
||||
**Purpose:** Canonical design, field mapping, and implementation plan for a browser-based estimating system in CapaKraken.
|
||||
|
||||
## Executive Summary
|
||||
|
||||
@@ -15,12 +15,12 @@ The workbook is not a simple calculator. It is a full estimating and pricing sys
|
||||
- management summaries
|
||||
- downstream export sheets
|
||||
|
||||
Planarchy can support this, but not by copying Excel cell logic into the browser. The right implementation is a dedicated estimating bounded context with:
|
||||
CapaKraken can support this, but not by copying Excel cell logic into the browser. The right implementation is a dedicated estimating bounded context with:
|
||||
|
||||
- a wizard for first-pass estimate creation
|
||||
- a workspace for iterative revisions
|
||||
- a typed calculation pipeline
|
||||
- live linkage to Planarchy resources and roles
|
||||
- live linkage to CapaKraken resources and roles
|
||||
- immutable snapshots for auditability
|
||||
|
||||
## Design Principles
|
||||
@@ -39,7 +39,7 @@ The replacement should be:
|
||||
|
||||
### 2. Reuse the current platform where it already fits
|
||||
|
||||
Useful existing Planarchy primitives:
|
||||
Useful existing CapaKraken primitives:
|
||||
|
||||
- `Resource` for roster, rates, skills, availability, and dynamic metadata
|
||||
- `Project` for schedule, budget, and project linkage
|
||||
@@ -134,7 +134,7 @@ That mix is exactly why the app needs separated models for assumptions, scope, d
|
||||
|
||||
### Mapping legend
|
||||
|
||||
- `Direct`: already maps to an existing first-class Planarchy field
|
||||
- `Direct`: already maps to an existing first-class CapaKraken field
|
||||
- `Bridge`: can be bridged short-term, but should move to estimating models
|
||||
- `Derived`: calculate it, do not persist it as manual source data
|
||||
- `New Model`: requires estimating schema
|
||||
@@ -236,7 +236,7 @@ That prevents old approved estimates from changing when roster rates or metadata
|
||||
### Phase 4. Resource linkage and planning handoff
|
||||
|
||||
- connect demand lines to resources, roles, and availability
|
||||
- add staffing suggestions from current Planarchy data
|
||||
- add staffing suggestions from current CapaKraken data
|
||||
- support conversion from approved estimate demand into downstream planning entities
|
||||
|
||||
### Phase 5. Exports and approvals
|
||||
@@ -261,7 +261,7 @@ Implemented baseline in the current codebase:
|
||||
- version submit, approve, and locked revision-cloning actions
|
||||
- export artifact scaffolding with stored serializer metadata records
|
||||
- format-specific export generation with stored payloads for JSON, CSV, XLSX, SAP, and MMP
|
||||
- live resource-linked staffing rows that can sync current Planarchy rates and persist estimate-version snapshots
|
||||
- live resource-linked staffing rows that can sync current CapaKraken rates and persist estimate-version snapshots
|
||||
- explicit live-vs-manual rate mode metadata on demand lines, with server-side recalculation before metrics are persisted
|
||||
- read-only and draft workspace visibility for manual overrides versus live resource snapshots
|
||||
- project snapshot persistence on estimate versions
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
|
||||
## Overview
|
||||
|
||||
GitLooper is a Claude Code slash command (`/gitlooper:gitlooper`) that connects to Planarchy's Gitea instance, reads open issues, triages them, and autonomously implements fixes/features using spawned sub-agents.
|
||||
GitLooper is a Claude Code slash command (`/gitlooper:gitlooper`) that connects to CapaKraken's Gitea instance, reads open issues, triages them, and autonomously implements fixes/features using spawned sub-agents.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## Ziel
|
||||
|
||||
Planarchy soll standortabhaengige Feiertage fachlich korrekt berechnen koennen, sodass zwei Personen im selben Land, aber in unterschiedlichen Regionen oder Staedten, unterschiedliche `SAH` und damit unterschiedliche Chargeability erhalten koennen.
|
||||
CapaKraken soll standortabhaengige Feiertage fachlich korrekt berechnen koennen, sodass zwei Personen im selben Land, aber in unterschiedlichen Regionen oder Staedten, unterschiedliche `SAH` und damit unterschiedliche Chargeability erhalten koennen.
|
||||
|
||||
Die Feiertagsaufloesung soll kuenftig diese Prioritaet haben:
|
||||
|
||||
|
||||
@@ -3,18 +3,18 @@
|
||||
Date: 2026-03-14
|
||||
|
||||
Source workbook:
|
||||
- `/home/hartmut/Documents/Copilot/planarchy/samples/Dispov2/MV_DispoRoster.xlsx`
|
||||
- `/home/hartmut/Documents/Copilot/capakraken/samples/Dispov2/MV_DispoRoster.xlsx`
|
||||
- Sheet: `DispoRoster`
|
||||
- Column K: `MV Ressource Type`
|
||||
|
||||
Applied rule:
|
||||
- If column K equals `Departed`, set `resource.departed = true` for the matching Planarchy resource identified by `EID`.
|
||||
- If column K equals `Departed`, set `resource.departed = true` for the matching CapaKraken resource identified by `EID`.
|
||||
|
||||
Result:
|
||||
- Workbook rows marked `Departed`: `166`
|
||||
- Matching resources found in Planarchy: `141`
|
||||
- Matching resources found in CapaKraken: `141`
|
||||
- Resources updated to `departed = true`: `141`
|
||||
- Workbook EIDs not found in Planarchy: `25`
|
||||
- Workbook EIDs not found in CapaKraken: `25`
|
||||
|
||||
Missing EIDs:
|
||||
- `antonia.melzer`
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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).
|
||||
|
||||
@@ -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
|
||||
```
|
||||
@@ -6,7 +6,7 @@ Scope: analysis only. No runtime behavior was changed in this pass.
|
||||
|
||||
## Executive Summary
|
||||
|
||||
The biggest performance costs in Planarchy currently come from three patterns:
|
||||
The biggest performance costs in CapaKraken currently come from three patterns:
|
||||
|
||||
1. Broad data fetches followed by repeated in-memory filtering/grouping.
|
||||
2. Expensive client-side derivations on screens with large datasets, especially Timeline.
|
||||
@@ -20,11 +20,11 @@ The highest-value optimization target is the Timeline stack. After that, the bes
|
||||
|
||||
Relevant files:
|
||||
|
||||
- [TimelineContext.tsx](/home/hartmut/Documents/Copilot/planarchy/apps/web/src/components/timeline/TimelineContext.tsx)
|
||||
- [TimelineView.tsx](/home/hartmut/Documents/Copilot/planarchy/apps/web/src/components/timeline/TimelineView.tsx)
|
||||
- [TimelineResourcePanel.tsx](/home/hartmut/Documents/Copilot/planarchy/apps/web/src/components/timeline/TimelineResourcePanel.tsx)
|
||||
- [TimelineProjectPanel.tsx](/home/hartmut/Documents/Copilot/planarchy/apps/web/src/components/timeline/TimelineProjectPanel.tsx)
|
||||
- [timeline.ts](/home/hartmut/Documents/Copilot/planarchy/packages/api/src/router/timeline.ts)
|
||||
- [TimelineContext.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/timeline/TimelineContext.tsx)
|
||||
- [TimelineView.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/timeline/TimelineView.tsx)
|
||||
- [TimelineResourcePanel.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/timeline/TimelineResourcePanel.tsx)
|
||||
- [TimelineProjectPanel.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/timeline/TimelineProjectPanel.tsx)
|
||||
- [timeline.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/timeline.ts)
|
||||
|
||||
Observed issues:
|
||||
|
||||
@@ -43,8 +43,8 @@ Impact:
|
||||
|
||||
Relevant files:
|
||||
|
||||
- [ChargeabilityReportClient.tsx](/home/hartmut/Documents/Copilot/planarchy/apps/web/src/components/reports/ChargeabilityReportClient.tsx)
|
||||
- [chargeability-report.ts](/home/hartmut/Documents/Copilot/planarchy/packages/api/src/router/chargeability-report.ts)
|
||||
- [ChargeabilityReportClient.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/reports/ChargeabilityReportClient.tsx)
|
||||
- [chargeability-report.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/chargeability-report.ts)
|
||||
|
||||
Observed issues:
|
||||
|
||||
@@ -62,9 +62,9 @@ Impact:
|
||||
|
||||
Relevant files:
|
||||
|
||||
- [dashboard.ts](/home/hartmut/Documents/Copilot/planarchy/packages/api/src/router/dashboard.ts)
|
||||
- [get-chargeability-overview.ts](/home/hartmut/Documents/Copilot/planarchy/packages/application/src/use-cases/dashboard/get-chargeability-overview.ts)
|
||||
- [get-overview.ts](/home/hartmut/Documents/Copilot/planarchy/packages/application/src/use-cases/dashboard/get-overview.ts)
|
||||
- [dashboard.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/dashboard.ts)
|
||||
- [get-chargeability-overview.ts](/home/hartmut/Documents/Copilot/capakraken/packages/application/src/use-cases/dashboard/get-chargeability-overview.ts)
|
||||
- [get-overview.ts](/home/hartmut/Documents/Copilot/capakraken/packages/application/src/use-cases/dashboard/get-overview.ts)
|
||||
|
||||
Observed issues:
|
||||
|
||||
@@ -80,8 +80,8 @@ Impact:
|
||||
|
||||
Relevant files:
|
||||
|
||||
- [ResourcesClient.tsx](/home/hartmut/Documents/Copilot/planarchy/apps/web/src/app/(app)/resources/ResourcesClient.tsx)
|
||||
- [resource.ts](/home/hartmut/Documents/Copilot/planarchy/packages/api/src/router/resource.ts)
|
||||
- [ResourcesClient.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/app/(app)/resources/ResourcesClient.tsx)
|
||||
- [resource.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/resource.ts)
|
||||
|
||||
Observed issues:
|
||||
|
||||
@@ -97,7 +97,7 @@ Impact:
|
||||
|
||||
Relevant files:
|
||||
|
||||
- [list-assignment-bookings.ts](/home/hartmut/Documents/Copilot/planarchy/packages/application/src/use-cases/allocation/list-assignment-bookings.ts)
|
||||
- [list-assignment-bookings.ts](/home/hartmut/Documents/Copilot/capakraken/packages/application/src/use-cases/allocation/list-assignment-bookings.ts)
|
||||
|
||||
Observed issues:
|
||||
|
||||
@@ -112,7 +112,7 @@ Impact:
|
||||
|
||||
Relevant schema:
|
||||
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/planarchy/packages/db/prisma/schema.prisma)
|
||||
- [schema.prisma](/home/hartmut/Documents/Copilot/capakraken/packages/db/prisma/schema.prisma)
|
||||
|
||||
Good coverage already exists for:
|
||||
|
||||
|
||||
+11
-11
@@ -6,12 +6,12 @@
|
||||
## Canonical Documents
|
||||
|
||||
- Active product and refactor backlog: this file
|
||||
- Estimating system design and workbook mapping: [estimating-extension-design.md](/home/hartmut/Documents/Copilot/planarchy/docs/estimating-extension-design.md)
|
||||
- Dispo clean-slate import design and field mapping: [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/planarchy/docs/dispo-import-implementation.md)
|
||||
- Dispo worker ticket pack and dependency breakdown: [dispo-import-implementation-tickets.md](/home/hartmut/Documents/Copilot/planarchy/docs/dispo-import-implementation-tickets.md)
|
||||
- Demand/assignment migration cutover and readiness policy: [demand-assignment-migration-cutover.md](/home/hartmut/Documents/Copilot/planarchy/docs/demand-assignment-migration-cutover.md)
|
||||
- Strategic longer-horizon architecture direction: [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/planarchy/research/v2-architecture-proposal-2026-03-11.md)
|
||||
- Implementation history and decisions: [LEARNINGS.md](/home/hartmut/Documents/Copilot/planarchy/LEARNINGS.md)
|
||||
- Estimating system design and workbook mapping: [estimating-extension-design.md](/home/hartmut/Documents/Copilot/capakraken/docs/estimating-extension-design.md)
|
||||
- Dispo clean-slate import design and field mapping: [dispo-import-implementation.md](/home/hartmut/Documents/Copilot/capakraken/docs/dispo-import-implementation.md)
|
||||
- Dispo worker ticket pack and dependency breakdown: [dispo-import-implementation-tickets.md](/home/hartmut/Documents/Copilot/capakraken/docs/dispo-import-implementation-tickets.md)
|
||||
- Demand/assignment migration cutover and readiness policy: [demand-assignment-migration-cutover.md](/home/hartmut/Documents/Copilot/capakraken/docs/demand-assignment-migration-cutover.md)
|
||||
- Strategic longer-horizon architecture direction: [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/capakraken/research/v2-architecture-proposal-2026-03-11.md)
|
||||
- Implementation history and decisions: [LEARNINGS.md](/home/hartmut/Documents/Copilot/capakraken/LEARNINGS.md)
|
||||
|
||||
Older plans and reviews were left in place only as archive notes so active guidance is no longer split across stale task lists.
|
||||
|
||||
@@ -409,7 +409,7 @@ Use a single orchestrator and split roadmap execution into package-owned workstr
|
||||
|
||||
| Agent | Scope | Primary Files / Packages | Deliverables | Notes |
|
||||
|---|---|---|---|---|
|
||||
| `A1-architect` | keep roadmap, contracts, and merge boundaries coherent | [docs/product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md), [docs/estimating-extension-design.md](/home/hartmut/Documents/Copilot/planarchy/docs/estimating-extension-design.md), shared contract entry points | acceptance criteria, sequencing, shared-file coordination | should not implement feature code unless integration is blocked |
|
||||
| `A1-architect` | keep roadmap, contracts, and merge boundaries coherent | [docs/product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md), [docs/estimating-extension-design.md](/home/hartmut/Documents/Copilot/capakraken/docs/estimating-extension-design.md), shared contract entry points | acceptance criteria, sequencing, shared-file coordination | should not implement feature code unless integration is blocked |
|
||||
| `C1-estimate-backend` | estimate domain, router, persistence, exports | `packages/api`, `packages/application`, `packages/engine`, `packages/db`, `packages/shared` | workspace read/write procedures, export serializers, version actions, metrics persistence | owns server-side behavior and cross-package type safety |
|
||||
| `C2-estimate-frontend` | estimates pages, wizard follow-up, workspace tabs | `apps/web/src/app/(app)/estimates`, `apps/web/src/components/estimates`, shared UI components | detail workspace, overview/assumptions/scope/rates tabs, iteration UX | should avoid editing backend contracts without handoff |
|
||||
| `T1-regression` | tests and runtime verification | `packages/*/test*`, `apps/web` verification paths, Docker runtime checks | regression tests, package typechecks, app smoke validation | runs after each integration checkpoint |
|
||||
@@ -445,7 +445,7 @@ Current target: execute the demand/assignment persistence split without blocking
|
||||
|
||||
| Topic | Canonical File | Notes |
|
||||
|---|---|---|
|
||||
| Active backlog | [product-roadmap.md](/home/hartmut/Documents/Copilot/planarchy/docs/product-roadmap.md) | Update this instead of reopening old plan files. |
|
||||
| Estimating design and field mapping | [estimating-extension-design.md](/home/hartmut/Documents/Copilot/planarchy/docs/estimating-extension-design.md) | Holds workbook analysis, mapping, and implementation plan. |
|
||||
| Strategic architecture direction | [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/planarchy/research/v2-architecture-proposal-2026-03-11.md) | Keep as strategy, not sprint backlog. |
|
||||
| Historical decisions | [LEARNINGS.md](/home/hartmut/Documents/Copilot/planarchy/LEARNINGS.md) | Append-only log. |
|
||||
| Active backlog | [product-roadmap.md](/home/hartmut/Documents/Copilot/capakraken/docs/product-roadmap.md) | Update this instead of reopening old plan files. |
|
||||
| Estimating design and field mapping | [estimating-extension-design.md](/home/hartmut/Documents/Copilot/capakraken/docs/estimating-extension-design.md) | Holds workbook analysis, mapping, and implementation plan. |
|
||||
| Strategic architecture direction | [v2-architecture-proposal-2026-03-11.md](/home/hartmut/Documents/Copilot/capakraken/research/v2-architecture-proposal-2026-03-11.md) | Keep as strategy, not sprint backlog. |
|
||||
| Historical decisions | [LEARNINGS.md](/home/hartmut/Documents/Copilot/capakraken/LEARNINGS.md) | Append-only log. |
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Planarchy v2 Refactoring Plan
|
||||
# CapaKraken v2 Refactoring Plan
|
||||
|
||||
**Date:** 2026-03-14
|
||||
**Status:** Proposed
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## Scope
|
||||
|
||||
Static security review of the current Planarchy codebase, focused on:
|
||||
Static security review of the current CapaKraken codebase, focused on:
|
||||
|
||||
- authentication and authorization boundaries
|
||||
- sensitive read/write API routes
|
||||
@@ -15,7 +15,7 @@ This review was done by parallel audit slices across API routes, auth/session co
|
||||
|
||||
## Executive Summary
|
||||
|
||||
The main security problem is not one isolated bug. It is that Planarchy currently treats "authenticated" as broadly equivalent to "allowed to see most planning data". That shows up in four places:
|
||||
The main security problem is not one isolated bug. It is that CapaKraken currently treats "authenticated" as broadly equivalent to "allowed to see most planning data". That shows up in four places:
|
||||
|
||||
1. any signed-in user can currently create a vacation request for any `resourceId`
|
||||
2. many sensitive read routes are only protected by `protectedProcedure`
|
||||
@@ -119,7 +119,7 @@ Any signed-in user connected to the timeline SSE endpoint can receive metadata a
|
||||
|
||||
**Impact**
|
||||
|
||||
Planarchy parses spreadsheet data from files, including browser-side and import-related flows, with a library version that has known high-severity issues when reading crafted workbooks. Export-only flows are lower risk; read/parse flows are the real problem.
|
||||
CapaKraken parses spreadsheet data from files, including browser-side and import-related flows, with a library version that has known high-severity issues when reading crafted workbooks. Export-only flows are lower risk; read/parse flows are the real problem.
|
||||
|
||||
**Recommended fix**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user