# D3 — status-vokabular: kanonisk token-sett for roll-up-registeret

**Status:** RATIFISERT 2026-07-24 — landet i `~/.claude/coord/register.md` (kanonisk 7-token-sett +
de to reglene inline; `active` og det åpne `…` fjernet). Denne doken er kontrakt-kilden.
**Foranledning:** D2-register-form-fiksen (`docs/plan/2026-07-23-d2-register-form-fix.md`, `c66ccc3`)
landet register-*formen* og ble ratifisert inn i `~/.claude/coord/register.md` (2026-07-23). Både
kontrakten og den globale register-fila **refererer** et status-token-vokabular men **definerer det
ikke** — begge peker eksplisitt til «D3-sporet» (register.md linje 42–44, 73; D2 §3.2). Denne doken
forfatter det vokabular-**kontrakten** HER (jf. driftsmodell: kontrakten forfattes i commons,
wiringen i catalog), til ratifisering inn i register-fila.

**Ratifiserte valg (operatør, 2026-07-23):** kanonisk 7-token-sett (`active` foldet inn i
`in-progress`); to normative regler (`partial` transitorisk; `deferred` ≠ `blocked`); leveranse =
denne proposal-doken (ingen unilateral global edit), speiler D2-mønsteret.

---

## 1. Gapet: vokabularet er referert, ikke definert

Roll-up-markøren har formen `topic: status — prosa` (utgang A / STATE.md) og `topic: status`
(utgang B / `.rollup-carrier`). Første token etter `:` er den maskinlesbare statusen. D2 fastslo at
token-settet trekkes fra «D3-status-vokabularet» men lot definisjonen stå åpen — register.md lister
et *kandidatsett* med et etterfølgende `…` (åpen-endet), ikke en normativ definisjon.

**Ground truth (verifisert 2026-07-23):** kun to tokens er i faktisk bruk på tvers av
`~/repos/*/STATE.md` — `planned` (5×) og `not-applicable` (1×). Resten av settet er prospektivt.
Dette er altså en definisjon *før* bred bruk: D3 setter den kanoniske betydningen slik at fremtidige
markører er konsistente, ikke en migrasjon av eksisterende data.

## 2. Kanonisk token-sett (normativt)

Syv tokens. `active` (i register.md-kandidatlista) droppes — det overlapper `in-progress` uten skarp
semantisk forskjell; en ekstra synonym svekker den maskinlesbare disiplinen.

| Token | Semantikk | Terminal? |
|-------|-----------|-----------|
| `planned` | Avgrenset scope, ikke startet. | Nei |
| `in-progress` | Aktivt arbeid, én eier, forventet å nå `done`. | Nei |
| `partial` | **Transitorisk.** Noen konstituerende deler ferdig, andre utestående — potensielt under ulike eiere. MÅ bære eier + neste-steg i utgang-A-prosaen (§3.1). Aldri en terminal hviletilstand. | Nei |
| `blocked` | Kan ikke fortsette — venter på en **ekstern** avhengighet. Navngir blokkereren i prosaen. | Nei |
| `deferred` | **Bevisst** utsatt — et valg om å ikke gjøre nå, ikke venting på noe. Distinkt fra `blocked` (§3.2). | Nei |
| `done` | Fullført, ingen utestående arbeid. | Ja |
| `not-applicable` | Temaet gjelder ikke dette repoet (f.eks. spec-eier uten kjørbar pipeline). | Ja |

**Terminal-klassifiseringen er informativ, ikke håndhevet:** den skiller hviletilstander (`done`,
`not-applicable`) fra tilstander som forventer videre bevegelse. Den muliggjør en fremtidig
staleness-heuristikk (en ikke-terminal markør som ikke har endret seg på lenge fortjener tilsyn),
men denne doken *innfører ingen slik gate* — det finnes ingen pålitelig tidsstempel-mekanisme i
markør-formen, og å oppfinne en her ville være spekulativt scope.

## 3. To normative regler

### 3.1 `partial` er transitorisk — krever eier + neste-steg

`partial` beskriver arbeid delt i konstituerende deler med ulik framdrift, ofte ulike eiere. Uten en
eksplisitt eier + neste-steg blir det en åpen «halvferdig»-tilstand uten vei ut. Regelen:

> En `partial`-markør hvis utgang-A-prosa mangler både en eier og et neste-steg er **malformert**.

Dette er en disiplin på **utgang A** (STATE-prosaen), ikke utgang B. Utgang B bærer kun token-et
(`topic: partial`) og er offentlig-trygg per D2 §3.2 — eier/neste-steg-prosaen forlater aldri utgang
A. Regelen kolliderer derfor ikke med D2s offentlig-trygghet (V4): den håndheves der prosaen finnes.

**Grounding:** «form→catalog, plumbing→okf, tillit→guard, spec→commons» (fra
`llm-ingestion-okf`-markøren) er nettopp den fler-eier-delingen `partial` fanger — et tema der én
eiers del kan være ferdig mens en annens er utestående.

### 3.2 `deferred` ≠ `blocked` — frivillig vs. ufrivillig

- `blocked`: arbeidet *kan ikke* fortsette; en ekstern avhengighet står i veien. Ufrivillig.
- `deferred`: arbeidet *kunne* fortsette, men er bevisst nedprioritert. Frivillig.

Skillet bærer beslutnings-informasjon: `blocked` inviterer «løs blokkereren»; `deferred` sier
«dette ligger med vilje, ikke rør». Å konflatere dem skjuler hvorvidt noen venter på noe.

**Grounding (begge fra dagens økosystem):**
- **`deferred`:** commons' «broadcast (bærer-modus per repo) **bevisst utsatt** — builder tolererer
  fravær → ingen andre repo blokkeres» (STATE). Ingenting venter; valgt å ligge. Tekstbok `deferred`.
- **`blocked`:** catalogs «ÅS#5-gatede STEG 0» var `blocked` på D2-ratifiseringen inntil commons
  varslet via coord (som *låste opp* steget). Ekstern avhengighet, ufrivillig — tekstbok `blocked`.

## 4. Konsekvens for register.md ved ratifisering

Ratifisering erstatter register.md-kandidatlista (linje 42–44) med det kanoniske settet:

- Fjern `active` (foldet inn i `in-progress`).
- Fjern det åpen-endede `…` — settet er lukket og normativt.
- Legg til de to reglene (§3.1, §3.2) eller en peker til denne doken.

Ingen eksisterende markør må endres: `planned` og `not-applicable` (de eneste i bruk) er begge i det
kanoniske settet.

## 5. Avhengigheter og grenser

- **D2** (`c66ccc3`, register.md) leverer *formen* som konsumerer dette vokabularet. D3 fyller
  vokabular-referansen D2 lot stå åpen. D3 endrer **ikke** to-utgangs-modellen, bærer-grammatikken
  eller builder-modusene.
- **catalog** eier builderens *wiring*. En builder KAN håndheve §3.1-gaten (regex på `partial`-linjer
  i utgang-A-kilden) og bør avvise ukjente tokens utenfor det kanoniske settet — men det er
  catalog-wiring, ikke denne kontrakten. Commons rører ikke catalog-moduler.
- **Ingen global konvensjon endres her.** Ratifisering (register.md-oppdateringen) er neste steg,
  etter operatør-OK.

## 6. Verifisering

Testbare kriterier som beviser at kontrakten er korrekt og ikke-regressiv:

- **V1 (ingen regresjon):** de to tokens i faktisk bruk er begge i det kanoniske settet.
  `grep -rhoE '^[a-z][a-z0-9-]+: (planned|not-applicable)' ~/repos/*/STATE.md` → treff; ingen
  eksisterende markør faller utenfor settet.
- **V2 (`active` er ikke i bruk — trygt å droppe):**
  `grep -rhE '^[a-z][a-z0-9-]+: active\b' ~/repos/*/STATE.md` → tomt. Bekrefter at å folde `active`
  inn i `in-progress` ikke bryter noen levende markør. **Verifisert 2026-07-23: tomt.**
- **V3 (register.md refererer, definerer ikke — gapet er reelt):**
  `grep -n 'D3' ~/.claude/coord/register.md` → linjene som utsetter til D3-sporet (i dag 42–44, 73).
  Etter ratifisering skal disse erstattes av den normative definisjonen.
- **V4 (`partial`-gaten er utgang-A-lokal, kolliderer ikke med D2 V4):** en `partial`-linje bærer
  eier + neste-steg kun i prosa (etter em-dash); utgang B (`.rollup-carrier`) forblir prosa-fri per
  D2 §3.2. Gaten `partial ⇒ prosa har eier+neste-steg` og D2s gate `.rollup-carrier har ingen prosa`
  gjelder to ulike utganger og kan begge holde samtidig.
- **V5 (`deferred`/`blocked`-skillet er observerbart):** dagens `deferred`-case (commons' bevisst
  utsatte broadcast) og `blocked`-case (catalogs ÅS#5-gatede STEG 0, nå løst) er distinkte i
  økosystemet (§3.2 grounding) — skillet koder reell beslutnings-informasjon, ikke en synonym.

**Nøkkelantakelser — eksplisitt testet:**

- *«Vokabularet er referert men udefinert i register.md.»* Testet: `grep -n 'D3' register.md` →
  linje 42–44 («D3 er eget spor; her *refereres* vokabularet, defineres ikke») + linje 73
  («Status-vokabularet: D3-sporet»). **Verifisert 2026-07-23.**
- *«Kun `planned` + `not-applicable` er i bruk; resten er prospektivt.»* Testet:
  `grep -rhoE ... ~/repos/*/STATE.md | sort | uniq -c` → `planned` 5×, `not-applicable` 1×, ingen
  andre. **Verifisert 2026-07-23.** D3 er en definisjon før bred bruk, ikke en migrasjon.

## 7. Ratifiseringssti

1. ~~Operatør-OK på dette vokabularet + de to reglene.~~ **GJORT** (2026-07-23).
2. ~~Ratifiser inn i `~/.claude/coord/register.md`: erstatt kandidatlista med det kanoniske settet +
   reglene; fjern `active` og `…`.~~ **GJORT** (2026-07-24): ny «Status-vokabular»-seksjon (tabell +
   regel 1/2) + kontrakt-kilde-peker; vokabular-bulleten og Eierskap-pekeren oppdatert.
3. catalog kan (valgfritt, deres wiring) håndheve §3.1-gaten + avvise ukjente tokens i builderen. — GJENSTÅR (catalog-spor).