diff --git a/scripts/run-next-task.sh b/scripts/run-next-task.sh new file mode 100755 index 0000000..4f8a325 --- /dev/null +++ b/scripts/run-next-task.sh @@ -0,0 +1,193 @@ +#!/usr/bin/env bash +# Plukker neste ugjorte oppgave fra tasks.md og starter en Claude Code-sesjon. +# Hopper over oppgaver med [?] (åpent spørsmål) eller [!] (blokkert), +# og oppgaver som avhenger av blokkerte faser. +# +# Bruk: +# ./scripts/run-next-task.sh # kjør neste oppgave +# ./scripts/run-next-task.sh --dry # vis hvilken oppgave som er neste +# ./scripts/run-next-task.sh --status # vis status for alle oppgaver + +set -euo pipefail +ROOT="$(cd "$(dirname "$0")/.." && pwd)" +TASKS="$ROOT/tasks.md" + +# --- Avhengighetskart: fase → faser den avhenger av --- +declare -A PHASE_DEPS=( + [1]="" + [2]="1" + [3]="2" + [4]="2" + [5]="3 4" + [6]="2" + [7]="6" + [8]="5" + [9]="3" + [10]="2" + [11]="5 6 7" + [12]="1 2 3 4 5 6 7 8 9 10 11" +) + +# --- Finn blokkerte faser --- +# En fase er blokkert hvis den har en [?] eller [!] oppgave +blocked_phases() { + local phases="" + for phase in $(seq 1 12); do + # Sjekk om fasen har blokkerte oppgaver + if grep -qP "^\- \[\?\] ${phase}\." "$TASKS" 2>/dev/null || \ + grep -qP "^\- \[!\] ${phase}\." "$TASKS" 2>/dev/null; then + phases="$phases $phase" + fi + done + echo "$phases" +} + +# Sjekk om en fase er tilgjengelig (alle avhengigheter er ferdige eller i det minste ikke blokkert) +phase_available() { + local phase=$1 + local blocked="$2" + + # Sjekk om denne fasen selv er blokkert + if echo "$blocked" | grep -qw "$phase"; then + return 1 + fi + + # Sjekk om avhengige faser er blokkert + local deps="${PHASE_DEPS[$phase]}" + for dep in $deps; do + if echo "$blocked" | grep -qw "$dep"; then + return 1 + fi + # Sjekk at alle oppgaver i avhengig fase er ferdige + if grep -qP "^\- \[ \] ${dep}\." "$TASKS" 2>/dev/null; then + return 1 + fi + done + + return 0 +} + +# --- Status-visning --- +if [[ "${1:-}" == "--status" ]]; then + echo "=== Synops oppgavestatus ===" + echo "" + done=$(grep -cP '^\- \[x\]' "$TASKS" || true) + todo=$(grep -cP '^\- \[ \]' "$TASKS" || true) + questions=$(grep -cP '^\- \[\?\]' "$TASKS" || true) + blocked_count=$(grep -cP '^\- \[!\]' "$TASKS" || true) + done=${done:-0}; todo=${todo:-0}; questions=${questions:-0}; blocked_count=${blocked_count:-0} + total=$((done + todo + questions + blocked_count)) + echo "Ferdige: $done / $total" + echo "Gjenstår: $todo" + echo "Spørsmål: $questions" + echo "Blokkert: $blocked_count" + echo "" + if [[ $questions -gt 0 ]]; then + echo "--- Åpne spørsmål ---" + grep -A2 '^\- \[\?\]' "$TASKS" || true + echo "" + fi + if [[ $blocked_count -gt 0 ]]; then + echo "--- Blokkerte oppgaver ---" + grep -A2 '^\- \[!\]' "$TASKS" || true + fi + exit 0 +fi + +# --- Finn neste oppgave --- +blocked=$(blocked_phases) + +next_task="" +line_num="" +task_text="" + +while IFS= read -r line; do + num=$(echo "$line" | cut -d: -f1) + text=$(echo "$line" | cut -d: -f2- | sed 's/^- \[ \] //') + # Hent fase-nummer fra oppgave-ID (f.eks. "1.3" → "1") + phase=$(echo "$text" | grep -oP '^\d+' || echo "") + + if [[ -n "$phase" ]] && phase_available "$phase" "$blocked"; then + next_task="$line" + line_num="$num" + task_text="$text" + break + fi +done < <(grep -n '^\- \[ \]' "$TASKS") + +if [[ -z "$next_task" ]]; then + if [[ -n "$blocked" ]]; then + echo "Ingen tilgjengelige oppgaver. Blokkerte faser:$blocked" + echo "Kjør --status for detaljer." + else + echo "Alle oppgaver er gjort!" + fi + exit 0 +fi + +echo "Neste oppgave (linje $line_num):" +echo " $task_text" +echo "" + +if [[ "${1:-}" == "--dry" ]]; then + exit 0 +fi + +PROMPT="$(cat <<'PROMPT_HEADER' +Du skal implementere neste oppgave i Synops-prosjektet. +Du jobber autonomt — ingen bruker er tilgjengelig for spørsmål underveis. + +PROMPT_HEADER +) + +## Oppgave +$task_text + +$(cat <<'PROMPT_BODY' + +## Arbeidsflyt + +1. **Orienter deg.** Les `CLAUDE.md` for prosjektkontekst. Les dokumentene + som refereres i oppgaven. Les `tasks.md` for å forstå hvor prosjektet står. +2. **Implementer.** Skriv kode, kjør på server via SSH om nødvendig. +3. **Verifiser.** Kompilering, curl-test, kjør relevante tester. +4. **Oppdater dokumentasjon.** Hvis implementeringen avviker fra eksisterende + docs, oppdater dem. Nye tekniske beslutninger dokumenteres i relevante + filer under `docs/`. Docs skal alltid reflektere faktisk tilstand. +5. **Oppdater tasks.md.** Endre `- [ ]` til `- [x]` for denne oppgaven. +6. **Commit og push.** Commit alle endringer (kode + docs + tasks.md) med + en beskrivende melding. Push til forgejo (bruk `tea` / `git push forgejo`). + +## Hvis noe blokkerer + +Hvis du støter på noe som krever avklaring fra Vegard: +- Endre oppgavens status til `- [?]` i tasks.md +- Legg til innrykket tekst under oppgaven med spørsmålet: + ``` + - [?] 1.5 Authentik: opprett OIDC-provider... + > Spørsmål: Skal vi bruke implicit flow eller authorization code + PKCE? + > Kontekst: PKCE er sikrere men krever backend-støtte. + ``` +- Commit og push tasks.md slik at Vegard kan se spørsmålet. +- Avslutt sesjonen. Ikke start på neste oppgave. + +Hvis du støter på et teknisk problem du ikke kan løse: +- Endre oppgavens status til `- [!]` i tasks.md +- Dokumenter problemet under oppgaven. +- Commit og push. Avslutt. + +## Regler + +- Jobb kun på denne ene oppgaven. +- Ikke deploy til produksjon uten eksplisitt godkjenning. +- Følg eksisterende arkitektur og konvensjoner i `docs/`. +- Hold det enkelt — minimum viable for oppgaven. +- Dokumentasjon er like viktig som kode. Neste sesjon har ingen kontekst + fra denne — alt den vet kommer fra kode, docs og git-historikk. +- Skriv commit-meldinger som forklarer *hvorfor*, ikke bare *hva*. +PROMPT_BODY +)" + +echo "Starter Claude Code-sesjon..." +cd "$ROOT" +claude --print "$PROMPT" diff --git a/tasks.md b/tasks.md new file mode 100644 index 0000000..2174cdf --- /dev/null +++ b/tasks.md @@ -0,0 +1,124 @@ +# Synops — Implementeringsoppgaver + +Sekvensiell liste. Hver oppgave gjøres i én Claude Code-sesjon. +Runner-scriptet plukker første ugjorte oppgave som ikke er blokkert. + +## Statuser + +- `- [ ]` — Klar til å gjøres +- `- [x]` — Ferdig +- `- [?]` — Åpent spørsmål, trenger avklaring fra Vegard. Neste sesjon hopper over denne og alle som avhenger av den. +- `- [!]` — Blokkert av teknisk problem. Beskrivelse under oppgaven. + +Åpne spørsmål og blokkeringer skrives som innrykket tekst under oppgaven +med `>` prefix. Se eksisterende oppgaver for format. + +## Avhengigheter + +Oppgaver innen en fase er sekvensielle (1.1 før 1.2, osv). +Faser avhenger av hverandre slik: + +``` +Fase 1 (infra) → Fase 2 (maskinrommet) → Fase 3 (frontend) + ↘ Fase 4 (tilgang) +Fase 3 + 4 → Fase 5 (kommunikasjon) +Fase 2 → Fase 6 (CAS) → Fase 7 (lyd) +Fase 5 → Fase 8 (aliaser) +Fase 3 → Fase 9 (visninger) +Fase 2 → Fase 10 (AI) +Fase 5 + 6 + 7 → Fase 11 (produksjon) +Alt → Fase 12 (herding) +``` + +Hvis en oppgave er `[?]` eller `[!]`, hoppes den over — og alle +oppgaver som avhenger av den (innen fasen + avhengige faser). +Uavhengige faser kan fortsatt plukkes. + +--- + +## Fase 1: Infrastruktur-fundament + +- [ ] 1.1 PostgreSQL schema: opprett database `synops`, enums (`visibility`, `access_level`), tabeller (`nodes`, `edges`, `node_access`, `auth_identities`) med indekser. Kjør på server via SSH. Ref: `docs/primitiver/nodes.md`, `docs/primitiver/edges.md`, `docs/retninger/bruker_ikke_workspace.md`. +- [ ] 1.2 Seed-data: opprett Vegards brukernode (`node_kind='person'`, `title='Vegard'`) og `auth_identities`-rad. Opprett Sidelinja samlings-node og `owner`-edge fra Vegard. +- [ ] 1.3 SpacetimeDB modul: opprett Rust-modul med `nodes` og `edges`-tabeller som speiler PG-skjema. Grunnleggende reducers for CRUD. Deploy til server. Ref: `docs/retninger/datalaget.md`, `docs/erfaringer/spacetimedb_integrasjon.md`. +- [ ] 1.4 Caddy-config: reverse proxy for maskinrommet (api.sidelinja.org), SpacetimeDB, og SvelteKit. Auto-TLS. Ref: `docs/setup/produksjon.md`. +- [ ] 1.5 Authentik: opprett OIDC-provider og applikasjon for Synops. Konfigurer redirect URIs. Ref: `docs/erfaringer/authentik_oppsett.md`. + +## Fase 2: Maskinrommet — skjelett + +- [ ] 2.1 Rust-prosjekt: opprett `maskinrommet/` med axum, tokio, sqlx (PG), serde. Dockerfile. Kompilerer og starter. Ref: `docs/retninger/maskinrommet.md`. +- [ ] 2.2 Auth-middleware: valider Authentik JWT-tokens, slå opp `auth_identities` → node_id. Returner 401 for ugyldige tokens. +- [ ] 2.3 SpacetimeDB-klient i maskinrommet: koble til STDB, skriv noder og edges via reducers. +- [ ] 2.4 Skrivestien: `POST /intentions/create_node` — valider, skriv STDB (instant), spawn async PG-skriving. Returner node_id umiddelbart. +- [ ] 2.5 Flere intensjoner: `create_edge`, `update_node`, `delete_node`. Validering av tilgang (created_by eller owner/admin-edge). +- [ ] 2.6 Docker Compose: legg maskinrommet inn i server-stacken. Intern nettverkstilgang til PG og STDB. + +## Fase 3: Frontend — skjelett + +- [ ] 3.1 SvelteKit-prosjekt: opprett `frontend/` med TypeScript, TailwindCSS. PWA-manifest. Lokal dev med HMR. +- [ ] 3.2 Authentik login: OIDC-flow (authorization code + PKCE). Session-håndtering. Redirect til login ved 401. +- [ ] 3.3 STDB WebSocket-klient: abonner på noder og edges. Reaktiv Svelte-store som oppdateres ved endringer. +- [ ] 3.4 Mottaksflaten v0: vis noder med edge til innlogget bruker, sortert på `created_at`. Enkel liste med tittel og utdrag. +- [ ] 3.5 TipTap-editor: enkel preset (tekst, markdown, lenker). Send `create_node`-intensjon til maskinrommet ved submit. +- [ ] 3.6 Sanntidstest: åpne to faner, skriv i én, se noden dukke opp i den andre via STDB. + +## Fase 4: Tilgangskontroll + +- [ ] 4.1 `recompute_access` i maskinrommet: ved edge-endring, oppdater `node_access`-matrisen. Håndter direkte edges (owner, admin, member, reader). +- [ ] 4.2 Team-transitivitet: member_of-edge til team → arv tilgang fra teamets edges. +- [ ] 4.3 Visibility-filtrering: STDB-spørringer respekterer visibility-enum. Frontend ser bare noder brukeren har tilgang til. +- [ ] 4.4 RLS-policies på PG: `node_access`-basert filtrering for tunge spørringer. + +## Fase 5: Kommunikasjonsnoder + +- [ ] 5.1 Opprett kommunikasjonsnode: intensjon `create_communication` → node med `node_kind='communication'`, deltaker-edges, metadata (started_at). +- [ ] 5.2 Kontekst-arv: input i kommunikasjonsnode → automatisk `belongs_to`-edge. +- [ ] 5.3 Chat-visning i frontend: noder med `belongs_to`-edge til kommunikasjonsnode, sortert på tid, sanntid via STDB. +- [ ] 5.4 Én-til-én chat: opprett kommunikasjonsnode med to deltakere. Full loop: skriv melding → vis i sanntid hos begge. + +## Fase 6: CAS og mediefiler + +- [ ] 6.1 CAS-lagring: filsystem med content-addressable hashing (SHA-256). Katalogstruktur med hash-prefix. Deduplisering. +- [ ] 6.2 Upload-endepunkt: `POST /intentions/upload_media` → hash fil, lagre i CAS, opprett media-node med `has_media`-edge. +- [ ] 6.3 Serving: `GET /cas/{hash}` → stream fil fra disk. Caddy kan serve direkte for ytelse. +- [ ] 6.4 Bilder i TipTap: drag-and-drop/paste → upload → CAS-node → inline i `metadata.document` via `node_id`. + +## Fase 7: Lyd-pipeline + +- [ ] 7.1 faster-whisper oppsett: Docker-container, GPU hvis tilgjengelig, norsk modell. Ref: `docs/erfaringer/`. +- [ ] 7.2 Transkripsjons-pipeline: lydfil i CAS → maskinrommet trigger Whisper → resultat i `content`-feltet. +- [ ] 7.3 Voice memo i frontend: opptak-knapp i input-komponenten → upload → CAS → transkripsjon. +- [ ] 7.4 Lyd-avspilling: spiller av original lyd fra CAS-node. Waveform-visning. + +## Fase 8: Aliaser + +- [ ] 8.1 Alias-noder: opprett alias-node med `alias`-edge (system=true) fra hovednoden. Usynlig for traversering. +- [ ] 8.2 Kontekstbasert identitet: maskinrommet setter `created_by` til alias-node når brukeren opererer i kontekst der aliaset er vert/deltaker. + +## Fase 9: Flere visninger + +- [ ] 9.1 Kanban-visning: noder med board-edge, gruppert på status-edge. Drag-and-drop for statusendring. +- [ ] 9.2 Kalender-visning: noder med `scheduled`-edge, på tidslinje. +- [ ] 9.3 Dagbok-visning: private noder (ingen delte edges), sortert på tid. +- [ ] 9.4 Kunnskapsgraf: topic-noder, `mentions`-edges. Visuell graf-visning. + +## Fase 10: AI og beriking + +- [ ] 10.1 LiteLLM oppsett: Docker-container, API-nøkler, modell-routing. Ref: `docs/infra/ai_gateway.md`. +- [ ] 10.2 AI-foreslåtte edges: maskinrommet sender innhold til LLM → foreslår mentions, topics. +- [ ] 10.3 Oppsummering: kommunikasjonsnode → AI-generert sammendrag som ny node. +- [ ] 10.4 TTS: tekst → lyd via ElevenLabs. Mottaker-preferanse i metadata. + +## Fase 11: Produksjons-pipeline + +- [ ] 11.1 LiveKit oppsett: Docker-container for WebRTC. Ref: `docs/setup/produksjon.md`. +- [ ] 11.2 Sanntidslyd: kommunikasjonsnode med live-status → LiveKit-rom for deltakere. +- [ ] 11.3 Pruning-logikk: TTL per modalitet, signaler som forlenger levetid, disk-nødventil. +- [ ] 11.4 Podcast-RSS: samlings-node med publiserings-edges → generert RSS-feed. + +## Fase 12: Herding + +- [ ] 12.1 Observerbarhet: strukturert logging, metrikker (request latency, queue depth, AI cost). +- [ ] 12.2 Backup: PG-dump rutine, STDB → PG gjenoppbygging ved krasj. +- [ ] 12.3 Feilhåndtering: retry med backoff i skrivestien, dead letter queue for feilede PG-skrivinger. +- [ ] 12.4 Ytelse: profiler STDB-spørringer, optimaliser node_access-oppdatering.