vegard a5985ef3f8 Dokumentasjon, erfaringslogg, migrasjoner og infra-oppdateringer

- Omorganiser docs/: konsepter, features, infra og proposals i egne mapper
- Ny docs/erfaringer/ med lærdommer fra chat-implementering (Svelte 5, SpacetimeDB, adapter-mønster)
- Oppdater ARCHITECTURE.md: Lag 1 status, ny §10 Erfaringslogg, SpacetimeDB i lokal dev
- Oppdater synkronisering.md med implementeringsstatus og designvalg
- Oppdater lokal.md med SpacetimeDB og AI Gateway
- Utvid PG-skjema med channels, messages, media_files, message_revisions
- Legg til seed_dev.sql, migration_safety.md, .env.example
- Nye feature-specs: chat, kanban, whiteboard, live_ai, lydmeldinger m.fl.
- Nye konsept-specs: studioet, møterommet, redaksjonen, den asynkrone gjesten m.fl.
- SpacetimeDB og AI Gateway i docker-compose.dev.yml
- collect-docs.sh inkluderer erfaringer/

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-03-15 01:40:14 +01:00

3.1 KiB

Raw Blame History

Komponerbare sider (Dashboard-komposisjon)

Idé

Brukere ser ferdige sider (Redaksjonen, Studioet, etc.), men admin kan komponere egne sider fra tilgjengelige byggeklosser — chat, kanban, statistikk, graf-visning, whiteboard, osv.

Hvorfor interessant?

Ulike redaksjoner jobber ulikt. Noen vil ha chat + kanban side-om-side, andre vil ha statistikk + research. I stedet for å hardkode alle kombinasjoner, gir vi admin verktøy til å sette opp sider tilpasset teamets arbeidsflyt. Brukerne ser resultatet som ferdige sider i navigasjonen.

Modell

Fase 1: Forhåndsdefinerte layouts (implementeres først)

Admin velger fra en katalog av blokker (chat, kanban, statistikk, etc.)
Plasserer dem i et grid-layout med forhåndsdefinerte maler (1-kolonne, 2-kolonne, 2+1, etc.)
Lagres som JSONB i workspaces.settings (nøkkel pages)
Brukere ser sidene i navigasjonen — ingen komposisjon, bare bruk
Mobil: blokkene stacker vertikalt (grid kollapser)

// Eksempel: admin-definert side
{
  "slug": "oversikt",
  "title": "Redaksjonsoversikt",
  "layout": "two-column",        // Forhåndsdefinert mal
  "blocks": [
    { "type": "chat", "channel": "general", "span": 1 },
    { "type": "kanban", "board": "episoder", "span": 1 },
    { "type": "stats", "view": "lyttere-7d", "span": 2 }
  ]
}

Fase 2: Konfigurerbare dashboards (senere, ved behov)

Brukere kan lage egne personlige dashboards
Drag-and-drop for å endre rekkefølge og størrelse
Lagres per bruker i workspace_members.dashboard_config JSONB (PG, ikke fil)

Fase 3: Full fri tiling (trolig unødvendig)

VS Code / Bloomberg-stil fritt plassering med splitters
Ekstremt høy kompleksitet, lav marginalverdi vs. Fase 2
Unngå med mindre det er et demonstrert behov

Arkitektur-krav

Hver feature-komponent MÅ bygges som en selvstendig Svelte-komponent som:

Tar imot workspaceId (og evt. config-props som channelId, boardId)
Håndterer sin egen datahenting og tilstand
Respekterer container-størrelse (responsiv innenfor sin blokk)
Eksponerer en blockMeta-descriptor (tittel, min-bredde, ikon) for katalogen

Dette koster ingenting å gjøre fra start og gir full fleksibilitet senere.

Bygger på

Workspace-modell, SvelteKit layout
Alle feature-komponenter (chat, kanban, whiteboard, statistikk, etc.)

Innsats

Fase 1: Lav (grid-layout + JSON-config, ingen drag-and-drop)
Fase 2: Middels (svelte-grid, bruker-lagring)
Fase 3: Stor (custom tiling engine)

Wow-faktor

Middels–Høy. Gir en "dette er MITT verktøy"-følelse som skiller Sidelinja fra rigide alternativer.

Åpne spørsmål

Skal sider være workspace-globale (alle ser samme oppsett) eller per-bruker? → Fase 1: workspace-globale via workspaces.settings JSONB. Fase 2: personlige overrides i workspace_members.dashboard_config JSONB. Alt i PG — ingen filer per bruker.
Hvordan håndtere blokker som krever mye plass (whiteboard, graf) på mobil? → Fullskjerm-modus per blokk som fallback.
Bør det finnes et "standard-oppsett" per workspace-type (podcast, nyhetsredaksjon)? → Ja, som templates admin kan velge som utgangspunkt.

3.1 KiB Raw Blame History Unescape Escape