140 lines
8.7 KiB
Markdown
140 lines
8.7 KiB
Markdown
# 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).
|