docs(plan): D3 status vocabulary — canonical 7-token set for roll-up register
Author the framework-neutral contract that fills the vocabulary reference D2 left open. Both the D2 register-form fix and the ratified ~/.claude/coord/register.md defer the status-token set to "the D3 track" without defining it (register.md lines 42-44, 73). Canonical set: planned / in-progress / partial / blocked / deferred / done / not-applicable. 'active' folded into 'in-progress' (redundant synonym). Two normative rules: - partial is transitional — its output-A prose MUST carry owner + next-step; never a terminal resting state. Output-A-local, so no conflict with D2's output-B public-safety gate. - deferred != blocked — voluntary postponement vs involuntary external wait; the distinction encodes decision information. Verified against ground truth: only planned (5x) + not-applicable (1x) in use across ~/repos/*/STATE.md; 'active' unused (safe to drop); no existing marker falls outside the set. Definition-before-use, not a migration. Contract only; no global convention edited. Ratification into register.md (replace the candidate list + '...' with the canonical set and the two rules) is the next step, per §7. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016oMpAhQcJZVGBW182stSPn
This commit is contained in:
parent
c66ccc3ed9
commit
fe6b998ac9
1 changed files with 138 additions and 0 deletions
138
docs/plan/2026-07-23-d3-status-vocabulary.md
Normal file
138
docs/plan/2026-07-23-d3-status-vocabulary.md
Normal file
|
|
@ -0,0 +1,138 @@
|
|||
# D3 — status-vokabular: kanonisk token-sett for roll-up-registeret
|
||||
|
||||
**Status:** forslag + kontraktutkast. Ingen global konvensjon er endret. Ratifiseres av operatøren.
|
||||
**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.
|
||||
2. Ratifiser inn i `~/.claude/coord/register.md`: erstatt kandidatlista (linje 42–44) med det
|
||||
kanoniske settet + reglene (§3.1, §3.2) eller peker hit; fjern `active` og `…`.
|
||||
3. catalog kan (valgfritt, deres wiring) håndheve §3.1-gaten + avvise ukjente tokens i builderen.
|
||||
Loading…
Add table
Add a link
Reference in a new issue