vegard/synops
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
synops/tasks.md
vegard 381c0da70f Starter oppgave 23.2
2026-03-18 14:29:20 +00:00

33 KiB
Raw Blame History

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
  • - [~] — Pågår. En agent jobber på denne. Andre agenter hopper over.
  • - [x] — Ferdig
  • - [?] — Åpent spørsmål, trenger avklaring fra Vegard.
  • - [!] — Blokkert av teknisk problem.

[~], [?] og [!] blokkerer alle oppgaver som avhenger av denne. Detaljer skrives som innrykket tekst med > prefix under oppgaven. Runner-scriptet legger automatisk til > Påbegynt: <timestamp> for [~].

Hvis en [~]-oppgave har stått i >60 min uten commit, anta at sesjonen krasjet. Kjør run-next-task.sh --unstale for å frigjøre.

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)
Fase 3 + 4 → Fase 13 (traits)
Fase 6 + 13 → Fase 14 (publisering)
Fase 3 + 10 → Fase 15 (adminpanel)
Fase 11 + 13 → Fase 16 (lydmixer)
Fase 17 (lydstudio-utbedring) — ingen avhengigheter, kan kjøres parallelt
Fase 10 + 13 → Fase 18 (AI-verktøy)
Fase 3 + 13 → Fase 19 (arbeidsflaten — spatial canvas)
Fase 19 → Fase 20 (universell overføring + panelrework)
Fase 2 → Fase 21 (CLI-verktøy — unix-filosofi)
Alt → Fase 12 (herding)
Fase 12 → Fase 22 (SpacetimeDB-migrering — fullført)
Fase 22 → Fase 23 (validering — alle faser)
Fase 23 → Fase 24 (orkestrering)
Fase 24 → Fase 25 (web clipper)

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.
  • 7.5 Segmenttabell-migrasjon: opprett transcription_segments-tabell i PG. Oppdater transcribe.rs til SRT-format → parse → skriv segmenter. Miljøvariabler: WHISPER_MODEL (default "medium"), WHISPER_INITIAL_PROMPT. Ref: docs/concepts/podcastfabrikken.md § 3.
  • 7.6 Transkripsjonsvisning i frontend: segmenter med tidsstempler, avspillingsknapp per segment (hopper til riktig sted i lydfilen), redigerbare tekstfelt (setter edited = true). Universell komponent for podcast, møter, voice memos.
  • 7.7 Re-transkripsjonsflyt: ved ny transkripsjon, vis side-om-side med forrige versjon. Highlight manuelt redigerte segmenter fra forrige versjon. Bruker velger per segment.
  • 7.8 SRT-eksport: generer nedlastbar SRT-fil fra transcription_segments-tabellen.

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 13: Trait-system

  • 13.1 Trait-metadata på samlingsnoder: maskinrommet validerer metadata.traits-objektet ved create_node og update_node for samlingsnoder. Avvis ukjente trait-navn. Ref: docs/primitiver/traits.md.
  • 13.2 Trait-aware frontend: samlingssider leser traits fra metadata og rendrer kun aktive komponenter. Dynamisk komponent-lasting basert på trait-liste.
  • 13.3 Pakkevelger: UI for å opprette ny samling med forhåndsdefinert pakke (nettmagasin, podcaststudio, redaksjon osv.) eller manuelt valg av traits.
  • 13.4 Trait-administrasjon: admin-UI for å legge til/fjerne traits på eksisterende samlinger med konfigurasjon per trait.

Fase 14: Publisering

  • 14.1 Tera-templates: innebygde temaer (avis, magasin, blogg, tidsskrift) med Tera i Rust. Artikkelmal + forside-mal per tema. CSS-variabler for theme_config-overstyring. Ref: docs/concepts/publisering.md § "Temaer".
  • 14.2 HTML-rendering av enkeltartikler: maskinrommet rendrer metadata.document til HTML via Tera, lagrer i CAS. Noden får metadata.rendered.html_hash + renderer_version. SEO-metadata (OG-tags, canonical, JSON-LD).
  • 14.3 Forside-rendering: maskinrommet spør PG for hero/featured/strøm (tre indekserte spørringer), appliserer tema-template, rendrer til CAS (statisk modus) eller serverer med in-memory cache (dynamisk modus). index_mode og index_cache_ttl i trait-konfig.
  • 14.4 Caddy-ruting for synops.no/pub: Caddy reverse-proxyer til maskinrommet som gjør slug→hash-oppslag og streamer CAS-fil. Cache-Control: immutable for artikler. Kategori/arkiv/søk serveres dynamisk av maskinrommet med kortere cache-TTL.
  • 14.5 Slot-håndtering i maskinrommet: slot og slot_order i belongs_to-edge metadata. Ved ny hero → gammel hero flyttes til strøm. Ved featured over featured_max → FIFO tilbake til strøm. pinned-flagg forhindrer automatisk fjerning.
  • 14.6 Forside-admin i frontend: visuell editor for hero/featured/strøm. Drag-and-drop mellom plasser. Pin-knapp. Forhåndsvisning. Oppdaterer edge-metadata via maskinrommet.
  • 14.7 Publiseringsflyt i frontend (personlig): publiseringsknapp på noder i samlinger med publishing-trait der require_approval: false. Forhåndsvisning, slug-editor, bekreftelse. Avpublisering ved fjerning av edge.
  • 14.8 RSS/Atom-feed: samling med rss-trait genererer feed automatisk ved publisering/avpublisering. synops.no/pub/{slug}/feed.xml. Maks rss_max_items (default 50).
  • 14.9 Custom domains: bruker registrerer domene i publishing-trait. Maskinrommet validerer DNS, Caddy on-demand TLS med validerings-callback. Re-rendring med riktig canonical URL.
  • 14.10 Redaksjonell innsending: submitted_to-edge med status-metadata (pending, in_review, revision_requested, rejected, approved). Maskinrommet validerer at kun roller i submission_roles kan opprette submitted_to, og kun owner/admin kan endre status eller opprette belongs_to. Ref: docs/concepts/publisering.md § "Innsending".
  • 14.11 Redaktørens arbeidsflate: frontend-visning av noder med submitted_to-edge til samling, gruppert på status. Kanban-stil drag-and-drop for statusendring. Siste kolonne ("Planlagt") setter publish_at i edge-metadata.
  • 14.12 Planlagt publisering: maskinrommet sjekker periodisk (cron/intervall) for belongs_to-edges med publish_at i fortiden som ikke er rendret. Ved treff: render HTML → CAS → oppdater RSS.
  • 14.13 Redaksjonell samtale: ved innsending kan redaktør opprette kommunikasjonsnode knyttet til artikkel + forfatter for diskusjon/feedback utover kort notat i edge-metadata.
  • 14.14 Bulk re-rendering: batch-jobb via jobbkø ved temaendring. Paginert (100 artikler om gangen), oppdaterer renderer_version. Artikler serveres med gammelt tema til re-rendret.
  • 14.15 Dynamiske sider: kategori-sider (filtrert på tag-edges), arkiv (kronologisk med månedsgruppering), søk (PG fulltekst). Alle paginerte, cachet i maskinrommet. Om-side som statisk CAS-node.
  • 14.16 Presentasjonselementer som noder: publisert tittel, ingress, OG-bilde, undertittel er egne noder med title/summary/og_image-edges til artikkelen. Frontend for å opprette/redigere varianter. Ref: docs/concepts/publisering.md § "Presentasjonselementer".
  • 14.17 A/B-testing: maskinrommet roterer varianter ved forside-rendering, logger impressions/klikk per variant, normaliserer CTR mot tidspunkt-baseline. Etter statistisk signifikans markeres vinner. Redaktør kan overstyre. Edge-metadata: ab_status, impressions, clicks, ctr.

Fase 15: Adminpanel

  • 15.1 Systemvarsler: varslingsnode (node_kind='system_announcement') med type (info/warning/critical), nedtelling og utløp. Frontend viser banner/toast for alle aktive klienter via STDB. Ref: docs/concepts/adminpanelet.md.
  • 15.2 Graceful shutdown: admin setter vedlikeholdstidspunkt → nedtelling i frontend → nye LiveKit-rom blokkeres → jobbkø stopper → vent på aktive jobber → restart. Vis aktive sesjoner før bekreftelse.
  • 15.3 Jobbkø-oversikt: admin-UI for aktive, ventende og feilede jobber. Filtrer på type/samling/status. Manuell retry og avbryt.
  • 15.4 AI Gateway-konfigurasjon: admin-UI for modelloversikt, API-nøkler (kryptert), ruting-regler per jobbtype, fallback-kjeder, forbruksoversikt per samling. Ref: docs/infra/ai_gateway.md.
  • 15.5 Ressursstyring: prioritetsregler mellom jobbtyper, ressursgrenser per worker, ressurs-governor for automatisk nedprioritering under aktive LiveKit-sesjoner, disk-status med varsling.
  • 15.6 Serverhelse-dashboard: tjeneste-status (PG, STDB, Caddy, Authentik, LiteLLM, Whisper, LiveKit), metrikker (CPU, minne, disk), backup-status, logg-tilgang.
  • 15.7 Ressursforbruk-logging: resource_usage_log-tabell i PG. Maskinrommet logger AI-tokens (inn/ut, modellnivå), Whisper-tid (sek), TTS-tegn, CAS-lagring (bytes), LiveKit-tid (deltaker-min). Båndbredde via Caddy-logg-parsing. Ref: docs/features/ressursforbruk.md.
  • 15.8 Forbruksoversikt i admin: aggregert visning per samling, per ressurstype, per tidsperiode. Drill-down til jobbtype og modellnivå.
  • 15.9 Brukersynlig forbruk: hver bruker ser eget forbruk i profil/innstillinger. Per-node forbruk synlig i node-detaljer for eiere.

Fase 16: Lydmixer

Ref: docs/features/lydmixer.md

  • 16.1 LiveKit-klient i frontend: installer livekit-client, koble til rom, vis deltakerliste. Deaktiver LiveKit sin auto-attach av <audio>-elementer — lyd rutes gjennom Web Audio API i stedet.
  • 16.2 Web Audio mixer-graf: opprett AudioContext, MediaStreamSourceNode per remote track → per-kanal GainNode → master GainNode → destination. AnalyserNode per kanal for VU-meter.
  • 16.3 Mixer-UI (MixerTrait-komponent): kanalstripe per deltaker med volumslider (0–150%), nød-mute-knapp (stor, rød), VU-meter (canvas/CSS), navnelabel. Master-fader og master-mute. Responsivt design (mobil: kompakt fader-modus).
  • 16.4 Delt mixer-kontroll via SpacetimeDB: MixerChannel-tabell + reducers (set_gain, set_mute, toggle_effect). Frontend abonnerer og oppdaterer Web Audio-graf ved endring fra andre deltakere. Visuell feedback (sliders beveger seg i sanntid). Tilgangskontroll: eier/admin kan sette deltaker til viewer-modus.
  • 16.5 Sound pads: pad-grid UI (4×2), forhåndslast lydfiler fra CAS til AudioBuffer. Avspilling ved trykk (AudioBufferSourceNode). Pad-konfig i metadata.mixer.pads (label, farge, cas_hash). Synkronisert avspilling via LiveKit Data Message.
  • 16.6 EQ-effektkjede: fat bottom (BiquadFilterNode lowshelf ~200Hz), sparkle (BiquadFilterNode highshelf ~10kHz), exciter (WaveShaperNode + highshelf). Per-kanal toggles, synkronisert via STDB. Presets (podcast-stemme, radio-stemme).
  • 16.7 Stemmeeffekter: robotstemme (ring-modulasjon: OscillatorNode → GainNode.gain), monsterstemme (egenutviklet AudioWorkletProcessor med phase vocoder for pitch shift). Effektvelger-UI per kanal. Parameterjustering (pitch-faktor, oscillator-frekvens).

Fase 17: Lydstudio-utbedring

Ref: Kodegjennomgang av b4c4bb8 (Lydstudio: lydredigering via FFmpeg).

  • 17.1 Responsivt studio-layout: /studio/[id] sidebar stacker under waveform på mobil. Verktøypanel som modal/sheet på små skjermer. Ref: feedback om at alt UI skal være responsivt uten unntak.
  • 17.2 FFmpeg-parametervalidering: valider at alle numeriske verdier (threshold, gain, ratio, frekvenser) er innenfor sikre grenser i audio.rs før de interpoleres i filterstrenger. Avvis ugyldige verdier med feilmelding.
  • 17.3 Fade/silence-logikk: fiks negativ fade-out start (clamp til 0), og adaptiv silence-margin (margin skal ikke overstige halve regionens varighet). Gi feilmelding ved ugyldige fade-varigheter.
  • 17.4 Frontend input-begrensninger: legg til min/max på alle tallfelter i OperationPanel (silenceThreshold, fadeMs, normTarget, compRatio). Hindre ugyldig input.
  • 17.5 Job-polling opprydding: rydd opp interval/timeout ved navigering bort fra studio-siden. Vis feilmelding etter N mislykkede polling-forsøk. Wrap metadata JSON.parse i try/catch.
  • 17.6 Temp-fil opprydding: legg til periodisk jobb i maskinrommet som sletter gamle temp-filer i CAS tmp-katalog. Bruk /tmp eller sett TTL.
  • 17.7 FFmpeg feilmeldinger til bruker: propager stderr fra FFmpeg-feil til frontend via strukturert feilrespons. Vis i RenderDialog.

Fase 18: AI-verktøy (arbeidsflate)

Ref: docs/features/ai_verktoy.md, docs/retninger/arbeidsflaten.md

  • 18.1 AI-preset node-type: node_kind: 'ai_preset' med metadata (prompt, model_profile, category, icon, color). Maskinrommet validerer ved opprettelse. Seed standardprompter (rens tekst, korrektør, oppsummering, oversett, skriv om, trekk ut fakta, forenkle, endre tone).
  • 18.2 AI-prosessering endepunkt: POST /intentions/ai_process med source_node_id, ai_preset_id, direction (node_to_tool / tool_to_node). Maskinrommet henter kilde-content og preset-prompt, mapper modellprofil → LiteLLM-alias, sender til AI Gateway. Logg forbruk i ai_usage_log.
  • 18.3 Direction-logikk: tool_to_node → lagre original som revisjon, oppdater node content. node_to_tool → opprett ny node med AI-output, opprett derived_from-edge til kilde + processed_by-edge til AI-preset.
  • 18.4 AI-verktøy panel (frontend): Svelte-komponent for arbeidsflaten. Prompt-velger med standardprompter, fritekst-felt for egendefinert prompt, modell-indikator (readonly). Drag-and-drop mottak for tekstnoder.
  • 18.5 Drag-and-drop integrasjon: node → verktøy (ny node), verktøy → node (in-place revisjon). Drop-sone feedback med verktøyets farge. Inkompatibilitet for lyd/bilde-noder med forklaring.
  • 18.6 Egendefinerte presets: brukere kan opprette egne AI-preset-noder med custom prompt. Dele via edges til samling/team. Modellprofil satt av admin.

Fase 19: Arbeidsflaten — Spatial Canvas

Ref: docs/retninger/arbeidsflaten.md, docs/features/canvas_primitiv.md

  • 19.1 Canvas-primitiv Svelte-komponent: pan/zoom kamera med CSS transforms, viewport culling, pointer events (mus + touch), snap-to-grid (valgfritt), fullskjermsmodus. Ref: docs/features/canvas_primitiv.md.
  • 19.2 BlockShell wrapper-komponent: header med tittel + fullskjerm/resize/lukk-knapper, drag-handles for repositionering, resize-handles, drop-sone rendering (highlight ved drag-over). Responsivt (min-size, max-size).
  • 19.3 Arbeidsflaten layout: skriv om /collection/[id] fra vertikal stack til Canvas + BlockShell. Last brukerens lagrede arrangement eller bruk defaults fra samlingens traits. Persist arrangement i bruker-edge metadata. Desktop: spatial canvas, mobil: stacked/tabs. Ref: docs/retninger/arbeidsflaten.md § "Tre lag".
  • 19.4 Kontekst-header: header tilhører flaten, viser gjeldende node som nedtrekksmeny/kontekst-velger. Mest brukte noder øverst (frekvens/recency), søkbart. Verktøymeny for å instansiere nye paneler. Ref: docs/retninger/arbeidsflaten.md § "Kontekst-header".
  • 19.5 Snarveier: paneler kan minimeres til kompakt ikon/fane. Dobbeltklikk → minimer/gjenopprett. Bevarer posisjon og størrelse. Ref: docs/retninger/arbeidsflaten.md § "Snarveier".
  • 19.6 Personlig flate: brukerens standard arbeidsflate (node_kind: 'workspace'). Vises når ikke koblet til en annen node. Persistent layout.

Fase 20: Universell overføring + panelrework

Ref: docs/features/universell_overfoering.md, docs/retninger/arbeidsflaten.md § "Kompatibilitetsmatrise"

  • 20.1 message_placements tabell: PG-migrasjon + SpacetimeDB-modul med place_message, remove_placement, move_on_canvas reducers. Synk STDB→PG. Ref: docs/features/universell_overfoering.md § 2.
  • 20.2 source_material edge-type: legg til i edge-skjema + maskinrommet-validering. Støtt kontekst-metadata (quoted, summarized, referenced) og excerpt-felt. Ref: docs/retninger/arbeidsflaten.md § "source_material-edge".
  • 20.3 BlockReceiver interface: implementer canReceive(), receive(), renderDropZone() i alle trait-komponenter (Chat, Kanban, Kalender, Editor, Studio). Kompatibilitetsmatrise bestemmer godkjente drops. Ref: docs/features/universell_overfoering.md § 4–5.
  • 20.4 Transfer service: innholdstransfer-modus (ny node + source_material edge) og lettvekts-triage (eksisterende node + ny edge/placement). Bestem modus fra verktøy-par. Shift-modifier for override. Ref: docs/features/universell_overfoering.md § 1, 3.
  • 20.5 Panelrework — Chat: gjør ChatTrait til fullverdig BlockShell-panel med BlockReceiver, fullskjerm-toggle, og responsivt design innenfor begrenset container.
  • 20.6 Panelrework — Kanban: gjør KanbanTrait til BlockShell-panel med drag-and-drop aksept fra andre paneler, fullskjerm, responsivt.
  • 20.7 Panelrework — Kalender: gjør CalendarTrait til BlockShell-panel med drop-aksept for scheduling, fullskjerm, responsivt.
  • 20.8 Panelrework — Editor/Artikkelverktøy: gjør artikkelverktøy til BlockShell-panel med source_material mottak fra andre paneler. Ref: docs/features/artikkelverktoy.md.
  • 20.9 Panelrework — Studio: gjør StudioTrait til BlockShell-panel med drop-aksept for lydfiler, fullskjerm, responsivt.

Fase 21: CLI-verktøy — Unix-filosofi

Ref: docs/retninger/unix_filosofi.md. Bryt ut prosessering fra maskinrommet til standalone CLI-verktøy i tools/. Maskinrommet kaller dem fra jobbkøen, Claude kaller dem direkte. Samme verktøy, to brukere.

Prosessering (erstatter jobbkø-handlere)

  • 21.1 synops-transcribe: Whisper-transkribering. Input: --cas-hash <hash> --model <model> [--initial-prompt <tekst>]. Output: JSON med segmenter. Skriver segmenter til PG, oppdaterer node metadata. Erstatter transcribe.rs.
  • 21.2 synops-audio: FFmpeg-prosessering. Input: --cas-hash <hash> --edl <json>. Output: ny CAS-hash. Erstatter audio.rs. Inkluder parametervalidering (fase 17.2–17.3).
  • 21.3 synops-render: Tera HTML-rendering. Input: --node-id <uuid> --theme <tema>. Output: CAS-hash for rendret HTML. Erstatter publishing.rs.
  • 21.4 synops-rss: RSS/Atom-generering. Input: --collection-id <uuid>. Output: XML til stdout. Erstatter rss.rs.
  • 21.5 synops-tts: Tekst-til-tale. Input: --text <tekst> --voice <stemme>. Output: CAS-hash for lydfil. Erstatter tts.rs.
  • 21.6 synops-summarize: AI-oppsummering. Input: --communication-id <uuid>. Output: sammendrag som tekst. Erstatter summarize.rs.
  • 21.7 synops-suggest-edges: AI-foreslåtte edges. Input: --node-id <uuid>. Output: JSON med forslag (target, edge_type, confidence). Erstatter ai_edges.rs.
  • 21.8 synops-respond: Claude chat-svar. Input: --communication-id <uuid> --message-id <uuid>. Output: svartekst. Erstatter agent.rs sin prosessering (auth/ratelimit forblir i maskinrommet).
  • 21.9 synops-prune: Opprydding av gamle noder. Input: --dry-run for forhåndsvisning. Erstatter pruning.rs.

Oppslag (Claude-verktøy)

  • 21.10 synops-context: Hent kontekst for en samtale. Input: --communication-id <uuid>. Output: markdown med spec, deltakere, historikk, relaterte noder.
  • 21.11 synops-search: Fulltekstsøk i grafen. Input: <query> [--kind <node_kind>] [--limit N]. Output: matchende noder med utdrag.
  • 21.12 synops-tasks: Parse tasks.md og vis status. Input: [--phase N] [--status todo|done|blocked]. Output: formatert oppgaveliste.
  • 21.13 synops-feature-status: Sjekk feature-status. Input: <feature_key>. Output: spec-sammendrag, oppgavestatus, nylige commits, ubesvart feedback.
  • 21.14 synops-node: Hent/vis en node med edges. Input: <uuid> [--depth N] [--format json|md]. Output: node-data med edges.

Infrastruktur

  • 21.15 Jobbkø-dispatcher: endre maskinrommets jobbkø-handlere til å spawne CLI-verktøy (Command::new("synops-X")) i stedet for inline-kode. Stdout → jobbresultat, stderr → feillogg, exitkode → status.
  • 21.16 Felles lib: synops-common crate med PG-tilkobling, CAS-helpers, og node/edge-typer. Deles mellom alle CLI-verktøy for å unngå duplisering.

Fase 12: Herding

  • 12.1 Observerbarhet: strukturert logging, metrikker (request latency, queue depth, AI cost).
  • 12.2 Backup: PG-dump rutine.
  • 12.3 Feilhåndtering: retry med backoff i skrivestien, dead letter queue for feilede PG-skrivinger.
  • 12.4 Ytelse: profiler PG-spørringer, optimaliser node_access-oppdatering.

Fase 22: SpacetimeDB-migrering — PG LISTEN/NOTIFY

Ref: docs/retninger/datalaget.md (revidert mars 2026). Faser ut SpacetimeDB til fordel for PG LISTEN/NOTIFY + WebSocket i portvokteren. Én datakilde, ingen synk-kompleksitet.

  • 22.1 WebSocket-lag i portvokteren: implementer PG LISTEN/NOTIFY-lytter og WebSocket-endepunkt. Legg til PG-triggers (notify_node_change, notify_edge_change) for nodes og edges. Frontend kobler til begge (STDB + nytt WS) i parallell for verifisering.
  • 22.2 Frontend-migrering: erstatt SpacetimeDB-klient med vanlig WebSocket til portvokteren. Erstatt STDB-stores med reaktive stores som lytter på WebSocket. Verifiser all sanntidsfunksjonalitet (chat, kanban, kalender, mixer, canvas).
  • 22.3 Fjern STDB-skrivestien: portvokteren slutter å skrive til SpacetimeDB. All skriving går kun til PG. NOTIFY-triggere er eneste push-mekanisme. Verifiser at ingenting avhenger av STDB-data.
  • 22.4 Fjern SpacetimeDB: stopp Docker-container, fjern STDB-modul, fjern STDB-klient fra portvokteren og frontend, fjern synkroniseringskode, oppdater docs og CLAUDE.md.
  • 22.5 Opprydding: arkiver STDB-relaterte erfaringsdocs, oppdater alle docs-referanser, fjern Docker-konfig for SpacetimeDB, fjern SpacetimeDB-loven fra feedback-memories.

Fase 23: Validering — test og kvalitetssikring per fase

Hver oppgave spinner opp en ny sesjon med frisk kontekst som gjennomgår implementeringen fra den angitte fasen. Sesjonen tester, leser kode, verifiserer mot spec, og sjekker at ting faktisk fungerer. Ved funn: fiks direkte hvis det er småting, eller opprett nye work_items (tasks) med spesifikasjon for det som trenger en dedikert sesjon.

  • 23.1 Valider fase 1–2 (infra + maskinrommet): PG-skjema, indekser, auth-middleware, intensjoner, STDB-klient (nå erstattet av WS). Verifiser at skjema matcher docs, at auth fungerer, at skrivestien er konsistent.
  • [~] 23.2 Valider fase 3–4 (frontend + tilgang): SvelteKit-oppsett, OIDC-flow, sanntid, mottaksflate, TipTap-editor, node_access-matrise, team-transitivitet, visibility-filtrering.

    Påbegynt: 2026-03-18T14:29

  • 23.3 Valider fase 5–8 (kommunikasjon + CAS + lyd + aliaser): chat-loop, kontekst-arv, CAS-hashing/deduplisering, Whisper-pipeline, segmenttabell, SRT-eksport, alias-identitet.
  • 23.4 Valider fase 9–10 (visninger + AI): kanban drag-and-drop, kalender, dagbok, kunnskapsgraf, LiteLLM-ruting, AI-foreslåtte edges, oppsummering, TTS.
  • 23.5 Valider fase 11 (produksjon): LiveKit-oppsett, sanntidslyd, pruning-logikk, podcast-RSS.
  • 23.6 Valider fase 13–14 (traits + publisering): trait-validering, pakkevelger, Tera-templates, HTML-rendering, forside, slot-håndtering, redaksjonell flyt, planlagt publisering, A/B-testing.
  • 23.7 Valider fase 15–16 (admin + lydmixer): systemvarsler, graceful shutdown, jobbkø-oversikt, ressursstyring, serverhelse, Web Audio mixer, delt kontroll, sound pads, EQ, stemmeeffekter.
  • 23.8 Valider fase 17–18 (lydstudio-utbedring + AI-verktøy): responsivt layout, FFmpeg-validering, fade/silence, AI-presets, direction-logikk, drag-and-drop integrasjon.
  • 23.9 Valider fase 19–20 (arbeidsflaten + universell overføring): canvas pan/zoom, BlockShell, layout-persistering, snarveier, transfer service, alle panelreworks (chat, kanban, kalender, editor, studio).
  • 23.10 Valider fase 21 (CLI-verktøy): kjør hvert synops-*-verktøy, verifiser --help, --payload-json, output-format, feilhåndtering, synops-common integrasjon.
  • 23.11 Valider fase 22 (STDB-migrering): WebSocket-sanntid fungerer, PG LISTEN/NOTIFY-triggere, ingen STDB-rester i aktiv kode/konfig.

Fase 24: Orkestrering — trigger-drevne automatiseringer

Ref: docs/concepts/orkestrering.md. Orkestreringsnoder (node_kind: 'orchestration') med fritekst-instruksjoner som boten utfører via function calling. Strukturerte triggere, automatisk eskalering av intelligens ved feil, kompilering av velprøvde mønstre.

  • 24.1 Orchestration node-type: legg til orchestration i maskinrommets node-validering. Metadata-skjema: trigger (event + conditions), executor, intelligence, effort, compiled, pipeline. Valider trigger-events mot kjent liste.
  • 24.2 Trigger-evaluering i portvokteren: ved node/edge-events, sjekk om noen orchestration-noder matcher triggeren. Effektiv lookup (indeksert på metadata.trigger.event). Ingen LLM-kall for trigger-matching.
  • 24.3 Bot-utførelse: utvid synops-respond (eller nytt synops-orchestrate) til å ta orchestration-node som input. Bygg prompt med trigger-kontekst + instruksjoner + tilgjengelige verktøy. Function calling for hvert steg. Logg i orchestration_log.
  • 24.4 Auto-eskalering: start med lavt intelligens/effort-nivå. Ved feil (tool_error, ambiguous_instruction) bump automatisk til neste nivå og retry. Maks 3 nivåer.
  • 24.5 Orchestration UI: editor for orkestreringsnoder i frontend. Trigger-velger (dropdown), betingelser, tekstbokser per steg, "Test kjøring"-knapp (dry-run), kjørehistorikk med status.
  • 24.6 Kaskade: triggers-edge mellom orkestreringer. Output fra én trigrer neste. Syklusdeteksjon for å unngå uendelige loops.
  • 24.7 Kompilering: observer hvilke verktøy/sekvenser som gjentas. Foreslå kompilering etter N kjøringer. Kompilert pipeline med fallback: "bot". Ingen LLM for standardsteg.
  • 24.8 Seed-orkestreringer: opprett standard-orkestreringer for podcast-pipeline, publiseringsflyt, og AI-beriking basert på eksisterende hardkodet logikk i portvokteren.

Fase 25: Web Clipper — synops-clip

Ref: docs/proposals/web_clipper.md. CLI-verktøy som henter URL, parser med Readability, og oppretter innholdsnode med AI-beriking. Brukes av @bot i chat ("les denne artikkelen"), orkestreringer, og fremtidig browser-extension.

  • 25.1 synops-clip CLI: hent URL, parse med Readability (mozilla/readability via JS eller Rust-port), returner ren tekst + metadata (tittel, forfatter, dato, ingress). Fallback til headless browser (Playwright) for JS-rendrede sider. Detekter betalingsmur (kort/avkuttet innhold, "logg inn for å lese", kjente paywall-mønstre) — returner "paywall": true og tilgjengelig innhold (ingress/utdrag). Output: JSON med title, author, date, content, url, paywall.
  • 25.2 Node-opprettelse: synops-clip --write oppretter content-node med artikkelinnhold, metadata.source_url, og tagged-edge "clipped". AI-oppsummering via LiteLLM. mentions-edges til gjenkjente entiteter i kunnskapsgrafen.
  • 25.3 @bot-integrasjon: bruker limer inn URL i chat → boten gjenkjenner URL, kaller synops-clip, presenterer oppsummering i chatten, oppretter node i bakgrunnen. Ved paywall: "Denne artikkelen er bak betalingsmur. Jeg fikk med tittel og ingress — lim inn innholdet om du vil dele resten."
  • 25.4 Orkestrering-støtte: synops-clip tilgjengelig som verktøy i orkestreringer. F.eks. "Clip alle URL-er som deles i #Redaksjonen og oppsummer dem".