synops/docs/proposals/tekst_primitiv.md

Forslag: Tekst-primitiv

Realisert: Tekst-primitiv-filosofien er nå innebygd i nodearkitekturen. Meldingsboksen er forfremmet til feature (docs/features/meldingsboks.md) og visibility-modellen fra dette dokumentet er implementert. Dokumentet er bevart som historisk referanse.

Idé

Det finnes ingen forskjell mellom en chatmelding og en artikkel — bare ulike stadier av samme ting. Enhver tekst starter som det enkleste ("hei") og kan vokse til hva som helst: få en tittel, bli rik-formatert, dras inn i en kalender, publiseres på web. Alt er samme node, samme primitiv. Brukeren bestemmer aldri "type" på forhånd — de bare skriver, og utvider når det føles naturlig.

Kjerneprinsipp: Enhver melding kan vokse

"hei"                          → ren tekst
"hei, her er mine tanker..."   → brukeren utvider → toolbar dukker opp
   + tittel                    → den har nå et navn
   + overskrifter, lister      → strukturert innhold
   + bilder, LaTeX, embeds     → rikt innhold
   + kanban_card_view          → oppgave
   + calendar_event_view       → kalenderhendelse
   + article_view              → publiserbar artikkel

Ingen "oppgradering", ingen "konvertering", ingen modusskifte i data. Noden er den samme hele veien. View-configs legges til og fjernes fritt — de er additive, aldri destruktive.

Hva dette betyr i praksis

• En chatmelding i #Mediepolitikk kan få en tittel → den er nå et notat
• Det notatet kan dras til kanban → det er nå også en oppgave
• Samme notat kan få article_view → det er nå publiserbart
• Alt uten å kopiere, flytte, eller miste kontekst (reply_to-kjeden, graf-edges, reaksjoner)

Dette er meldingsboks-filosofien tatt til sin logiske konklusjon: ikke bare "én primitiv, flere views", men "én primitiv som vokser organisk med brukerens intensjon".

Hvorfor er dette interessant?

Rekkefølgeproblemet

Brukeren vet sjelden på forhånd hva en tekst skal bli. Man skriver, tenker, og innser: "dette bør bli noe mer". Ved å la enhver melding vokse forsvinner problemet — veien fra tanke til publisering er bare å legge til, aldri å starte på nytt.

Konsistens

• Én primitiv i hele systemet (meldingsboksen)
• #-mentions fungerer overalt — chat, notater, artikler — samme mekanisme
• Graf-koblinger er universelle — en mention i chat og en mention i en publisert artikkel er identisk
• Versjonshistorikk (message_revisions) følger med uansett hvor teksten ender opp

Hva bygger den på?

• Meldingsboks — enhver tekst er en melding (node i grafen)
• Kunnskapsgraf — #-mentions oppretter graf-edges uansett kontekst
• Message revisions — revisjonshistorikk allerede på plass
• View-configs — kanban_card_view, calendar_event_view, article_view er bare pekere

Skisse

Visibility-trappen

En melding kan bevege seg gjennom synlighetsnivåer uten å endre identitet:

'private'    → kun forfatter (kladd, personlig notat)
'workspace'  → alle i workspacet (delt internt)
'link'       → hvem som helst med URL-en (Google Docs-modell, ingen indeksering)
'public'     → publisert (indeksert, i feeds, full SEO)

Hvert steg er reversibelt. En publisert artikkel kan trekkes tilbake til 'workspace'. En privat kladd kan deles med én lenke uten å bli offentlig.

Delbare URL-er

Enhver melding med visibility: 'link' eller 'public' får en URL:

sidelinja.org/delt/<uuid>                → enkel deling (lesbar med lenke, ingen SEO)
sidelinja.org/@vegard/<slug>             → publisert artikkel (SEO, feed, OG-tags)
sidelinja.org/pub/<publikasjon>/<slug>   → kuratert artikkel (se artikkel-publisering)

article_view — publiseringslaget

Når en tekst skal publiseres, legges en view-config til:

CREATE TABLE article_view (
    message_id   UUID PRIMARY KEY REFERENCES messages(id) ON DELETE CASCADE,
    slug         TEXT NOT NULL,
    status       TEXT NOT NULL DEFAULT 'draft',  -- 'draft', 'review', 'published', 'archived'
    excerpt      TEXT,
    body_html    TEXT,                           -- Pre-rendret HTML (KaTeX + editor → HTML)
    published_at TIMESTAMPTZ,
    CONSTRAINT unique_slug_per_workspace UNIQUE (message_id)
);

Offentlig vs intern kontekst

En publisert artikkel har to ansikter:

Inne i workspacet: Artikkelen er en melding i en tråd. Den har reply_to til meldingen som startet diskusjonen, interne svar, graf-koblinger. Full kontekst.

Ute på web: Artikkelen er en frittstående tekst. Den interne konteksten er usynlig. Offentlige kommentarer lever i en separat kanal (visibility: 'public') som workspace-medlemmer kan se, men som ikke blander seg med den interne diskusjonen.

article_node (melding i workspace)
├── reply_to → intern forelder (usynlig utenfra)
├── channel: #Mediepolitikk (intern diskusjon)
└── public_comment_channel (offentlige kommentarer, separat)

Åpne spørsmål

Versjoner og kladder

• Er det nok med message_revisions (lineær historikk), eller trengs navngitte versjoner / snapshots?
• Bør ulike versjoner kunne ha ulik visibility? ("kladd 1 er privat, kladd 2 er delt med lenke, publisert versjon er offentlig")
• Eller er det enklere: én tekst, én visibility, revisjonshistorikk under panseret?

Grensen melding ↔ artikkel

• Teknisk: ingen grense. En melding med article_view er en artikkel.
• UX-messig: når tilbyr systemet "vil du publisere dette?" Manuelt via meny? Automatisk forslag når teksten når en viss lengde/kompleksitet?

Offentlige kommentarer

• Hvem kan kommentere? Anonymt, autentisert, inviterte?
• Enkleste start: ingen offentlige kommentarer. Artikler er read-only for publikum. Diskusjon skjer internt eller via eksterne kanaler.

Innsats: Lav (prinsipp) / Middels (article_view + visibility)

Prinsippet krever ingen ny kode — meldingsboksen støtter det allerede. article_view-tabell og visibility-utvidelse er overkommelig. Den tunge delen er editoren (se editor.md).

Wow-faktor: Middels–Høy

Filosofien — at enhver tekst kan bli hva som helst — er enableren for personlig workspace, artikkel-publisering, samarbeid og kurasjon.

Relasjon til andre proposals

• Editor — det tekniske skriveverktøyet som gjør alt dette mulig i UI
• Personlig workspace — konteksten der brukeren kladder og publiserer
• Artikkel-publisering — publiseringsmodellen (publikasjoner, kuratorer, feeds) bygger på tekst-primitiven
• Meldingsboks (feature) — tekst-primitiven er den naturlige utviklingen: "én primitiv som vokser med brukerens intensjon"