# Forslag: Tekst-primitiv

## 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:

```sql
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"