portfolio-optimiser/shared/docs/plan/2026-07-23-d3-status-vocabulary.md

8.7 KiB
Raw Blame History

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 4244, 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; deferredblocked); 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.mdplanned (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 deferredblocked — 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 4244) 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 4244, 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 4244 («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 -cplanned 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).