work

docs/evaluation.md

@@ -0,0 +1,23 @@
+# Evaluering
+
+## Hvad fungerede godt
+- SvelteKit gjorde det hurtigt at samle UI og backend i samme repo.
+- Login og beskyttede routes gav et klart brugerflow.
+- Projekter og tasks kan udvides uden at ændre arkitekturen meget.
+- GitHub App-installationsflowet (redirect → callback → repo selection → project link) er en komplet brugerrejse.
+- Callback'et håndterer manglende private key graceful uden at crashe.
+
+## Hvad var udfordrende
+- GitHub App kræver en PEM-private key, som skal formateres korrekt i `.env` (enkelt linje, `\n` for line breaks).
+- Flere komponenter (callback, repo listing, issue sync) crashede uden private key — krævede `hasGitHubAppPrivateKey()` gates.
+- `githubRepositoryLink.installationId` forvekslede intern DB-id med GitHub's `installationId`, hvilket gav 404 ved issue-sync.
+- Rigtig GitHub-sync kræver provider-specifik auth og API-håndtering (JWT, access tokens, installation tokens).
+- Realtidsopdateringer skal afstemmes med deploy-miljø og connection limits.
+- Progressberegning skal være konsistent, når tasks ændres samtidigt.
+
+## Hvordan kan SvelteKit bruges professionelt
+- Som ramme til interne værktøjer og dashboards, hvor SSR og form actions reducerer klient-kompleksitet.
+- Til applikationer med behov for hurtig første render og god SEO gennem SSR.
+- Til realtime-funktionalitet med SSE, hvor tunge websocket-løsninger ikke er nødvendige.
+- Sammen med Drizzle ORM til typesikker databaseadgang i full-stack TypeScript-projekter.
+- Til prototyper og MVP'er der skal kunne skaleres til produktion uden at skifte framework.

docs/technical-decisions.md

@@ -0,0 +1,47 @@
+# Tekniske Valg
+
+## Hvad jeg byggede
+En SvelteKit-baseret produktivitetsapp med login, projekter, tasks, GitHub App installation, repository linking, issue-sync og live opdateringskanal (SSE).
+
+## Hvorfor SvelteKit
+- Server `load` gør det enkelt at hente data tæt på routen.
+- Form actions passer godt til mutationer uden tung klientlogik.
+- SSR giver hurtig første render og bedre default UX.
+- SSE passer til lette live-opdateringer uden fuld websocket-kompleksitet.
+
+## Hvordan det virker i praksis
+- Brugeren logger ind via Better Auth (GitHub OAuth).
+- Dashboardet henter projekter, tasks og issues server-side.
+- Brugeren kan oprette projekter og tasks via form actions.
+- Projekter har en GitHub App-installationsknap, der sender brugeren til GitHub.
+- GitHub App installeres på en konto, og der vælges repositorier på GitHub's side.
+- Efter installation redirectes brugeren til en setup-side i appen, hvor de vælger et projekt og krydser repos fra.
+- De valgte repos gemmes som `githubRepositoryLink`-rækker.
+- På projektets detailside kan brugeren synce issues fra det linkede repo via GitHub App's installation access token.
+- SSE-endpoint (`/api/events`) sender notifikationer om task-ændringer og issue-sync, så klienten reloader data.
+
+## GitHub App flow i detaljer
+1. `getGitHubInstallUrl()` genererer en URL med en HMAC-signeret state (indeholder `userId` og `redirect`).
+2. GitHub sender brugeren tilbage til `GITHUB_APP_SETUP_URL` med `installation_id` og `state`.
+3. Callback-validering: state afkodes og verficeres, `installation_id` gemmes i `githubInstallation`.
+4. Hvis `GITHUB_APP_PRIVATE_KEY` er sat, hentes account-login fra GitHub API. Ellers bruges en fallback.
+5. Brugeren redirectes til `/install/setup?installation={id}` for at vælge repos og projekt.
+6. Setup-siden bruger `listGitHubInstallationRepositories()` til at vise repos.
+7. Form action opretter `githubRepositoryLink`-rækker og redirecter til projektet.
+
+## Hvad der virkede godt
+- SvelteKit gjorde dataflowet kort og tydeligt (load → form action → redirect).
+- Server actions holdt mutationerne samlede og eliminerede behov for klient-state.
+- Drizzle passede godt til schema-drevet udvikling med relations og foreign keys.
+- GitHub App JWT-auth var overskuelig med `node:crypto` og RS256-signering.
+- HMAC-signeret state gav en sikker callback-verifikation uden session storage.
+
+## Hvad der var udfordrende
+- GitHub App kræver en PEM-private key, som skal formateres som en enkelt linje med `\n` i `.env`.
+- Private key skal være til stede før JWT-signerede API-kald kan fungere.
+- `githubRepositoryLink.installationId` er en foreign key til den interne `githubInstallation.id`, ikke GitHub's `installationId` — skal joins for at få den rigtige værdi.
+- SSE er nemt til énvejskommunikation, men websocket kan blive nødvendig senere.
+- Progress bør helst beregnes robust i databasen eller via en service.
+
+## Professionel brug
+Løsningen kan bruges som intern project tracker, support-overblik eller developer dashboard med integrerede GitHub issues og statusopdateringer.

docs/weekly-plan.md

@@ -0,0 +1,18 @@
+# Weekly Plan
+
+## Uge 1
+- Planlæg et lille MVP-projekt i SvelteKit.
+- Implementer login, dashboard, projekter og opgaver.
+- Dokumenter hvorfor SvelteKit passer til SSR, form actions og realtime opdateringer.
+
+## Uge 2
+- Tilføj GitHub App-integration med installationsflow.
+- Implementer repository selection ved installation.
+- Byg issue-sync fra GitHub repos.
+- Arbejd med live opdateringer via SSE.
+- Dokumenter de tekniske valg undervejs.
+
+## Leverancer
+- Kort teknisk dokumentation.
+- Kildekode med projekter, tasks, GitHub-installationer og issue-overblik.
+- En evaluering af styrker og begrænsninger.