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
+3 -3
View File
@@ -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**