# Pilot T3-2026 — protokoll

> Protokollen for den reelle tertialsyklusen (T3 2026, september–desember) som skal
> avgjøre om pluginen holder i bruk, ikke bare i test. Skrevet **før** første
> live-kjøring, med vilje: en pilot som definerer suksesskriteriene sine underveis
> måler ikke noe.
>
> **Denne fila er offentlig** (`origin` = `open/okr.git`). Den inneholder derfor
> ingen organisasjonsdata, ingen dokumentnavn og ingen OKR-innhold — bare regler,
> format og kriterier. Se §4 for hvor pilotens faktiske innhold bor.
>
> Status: datagrensen (§2) og katalogprinsippet (§3) er **låst** 2026-08-11.
> Org-profil og tildelingsbrev er fortsatt **åpen post** (§8).

## 1. Hva piloten skal bevise

Én påstand står uverifisert i hele planverket: at pluginen fungerer i en ekte
styringssyklus. Alt annet er dekket av tester og fagkanon. Piloten finnes for å
erstatte den påstanden med dokumentasjon — i begge retninger. **En pilot som ikke
kan konkludere negativt, beviser ingenting.**

Konkret skal piloten svare på tre ting:

1. **Kommer man gjennom?** Lar hele styringssløyfa — tildelingsbrev inn,
   tertial-/årsrapportunderlag ut — seg faktisk kjøre på ekte dokumenter, av én
   person, uten å lese kildekoden for å komme videre?
2. **Er svarene faglig riktige når inputen er ekte?** Fikserte testdata er
   snille. Ekte tildelingsbrev er lange, vage og delvis selvmotsigende.
3. **Hvor gjør det vondt?** Friksjonene er den egentlige leveransen. Funn-loggen
   (§5) er pilotens primære produkt — ikke OKR-ene som lages underveis.

## 2. Datahåndteringsregel (LÅST 2026-08-11, operatørbeslutning G4)

**Kun offentlige dokumenter inn i pilot-treet.** Et dokument er offentlig i denne
protokollens forstand når det kan pekes til en offentlig tilgjengelig kilde —
typisk tildelingsbrev, årsrapporter, virksomhetsstrategier og tildelingsbrevets
vedlegg slik de er publisert.

Utenfor grensen, uten unntak i denne piloten:

- **E-post (`.eml`)** i enhver form, uansett innhold.
- **Interne dokumenter som ikke er publisert**, selv når de er ugraderte — internt
  arbeidsmateriale, utkast, referater, personalrelatert innhold.
- **Personopplysninger** i enhver form, inkludert navn i eksempel-OKR. Roller
  skrives som rolle («KR-eier», «avdelingsdirektør»), aldri som person.

Regelen gjelder alt som **legges i treet** (`.claude/okr/`), ikke hva operatøren
leser ved siden av. Sensitivt innhold er gatet bak 2.0.0-veiledningen
(sensitivitets-/GDPR-posisjon + `okr:rydd`) og åpnes ikke tidlig i piloten.

**Etterprøvbarhet:** ved hvert checkpoint skal hver fil i pilot-treets
`dokumenter/` og `strategisk-kontekst/` kunne pekes til sin offentlige kilde. En
fil som ikke kan det, fjernes — den er et brudd på grensen, ikke en gråsone.

## 3. Hvor piloten kjører (LÅST 2026-08-11, operatørbeslutning G4)

**Piloten kjører i en egen arbeidskatalog utenfor dette repoet.** Krav til
katalogen:

- **Ikke plugin-repoet.** Pluginens `.claude/` er riktignok gitignored, så det
  ville ikke lekket — men piloten skal teste pluginen slik en installert bruker
  møter den, ikke slik utvikleren gjør. Å blande styringsdata med plugin-utvikling
  ødelegger begge deler.
- **Ingen offentlig remote.** Enten uten remote, eller mot en privat remote.
- **Egen `STATE.md`** per kontinuitetskonvensjonen — pilot-øktene er egne økter i
  egen tab, ikke en gren av plugin-utviklingen.
- Eksakt sti fastsettes ved G4-resten (§8).

**Maskin-global tilstand — den ene ikke-reverterbare skrivingen.**
`/okr:oppsett` skriver `~/.claude/okr/org/profil.md`
(`scripts/write-org-profile.mjs:29`). Den fila ligger utenfor ethvert git-repo og
kan ikke tilbakestilles med en commit. Per 2026-08-11 **finnes den ikke**, så
første kjøring er trygg. Regelen gjelder derfor alt etterpå:

> Etter hver vellykket `/okr:oppsett`, kopier `~/.claude/okr/org/profil.md` til
> pilot-katalogen som `profil.md.pilot-backup`. Før enhver senere `/okr:oppsett`
> som kan overskrive den, verifiser at backupen er nyere enn siste bevisste
> endring.

## 4. Publiseringsgrense — hva som kan nå det offentlige speilet

Dette repoets `origin` er `open/okr.git`. Alt i `docs/` blir offentlig ved push.

| Innhold | Hvor det bor | Offentlig? |
|---|---|---|
| Denne protokollen | `docs/pilot-t3-2026.md` | Ja — org-nøytral med vilje |
| Funn-loggen | Pilot-katalogen (§3) | **Nei** |
| Pilot-treet (dokumenter, OKR, status) | Pilot-katalogen `.claude/okr/` | **Nei** |
| Konsolidert pilot-rapport (E8/E9) | `docs/` | Ja — **kun sanitert**, se under |
| CHANGELOG-referanse til piloten (2.0.0) | `CHANGELOG.md` | Ja |

**Saniteringsregel for pilot-rapporten:** rapporten som når `docs/` beskriver
*funnene* — hva som gikk galt i pluginen, hvor, og hva som ble gjort — aldri
organisasjonens innhold. Ingen KR-tekst, ingen måltall, ingen dokumentnavn, ingen
organisasjonsnavn utover det operatøren eksplisitt godkjenner ved E9. Et funn som
ikke lar seg beskrive uten organisasjonens innhold, blir stående i den private
funn-loggen og refereres i rapporten kun som antall.

## 5. Funn-logg — format

Funn-loggen bor i pilot-katalogen som `funn-logg.md` og er pilotens primære
produkt. Én oppføring per friksjon, i tabellform:

| Felt | Innhold |
|---|---|
| `ID` | `F-01`, `F-02`, … fortløpende, gjenbrukes aldri |
| `Dato` | ISO-dato for observasjonen |
| `Versjon` | Plugin-versjon som ble kjørt (`1.10.0`, …) |
| `Hvor` | Kommando, skript eller referansefil — så presist som mulig |
| `Observert` | Hva som faktisk skjedde. Skrives **før** diagnosen |
| `Forventet` | Hva operatøren ventet seg, og hvorfor |
| `Alvorlighet` | `blokkerende` \| `friksjon` \| `kosmetisk` |
| `Rute` | `patch-lane` \| `2.0.0` \| `dokumentasjon` \| `avvist` (med begrunnelse) |
| `Status` | `åpen` \| `lukket` + commit-hash |

**Alvorlighetsgradene er definert, ikke skjønn:**

- **`blokkerende`** — oppgaven lar seg ikke fullføre uten omvei operatøren måtte
  finne på selv, **eller** outputen er faglig gal (feil aritmetikk, feil doktrine,
  feil kildebruk). Et faglig galt svar som kommer pent formatert er blokkerende,
  ikke kosmetisk.
- **`friksjon`** — oppgaven lar seg fullføre, men koster manuelle steg, eller
  krever kunnskap som ikke står noe sted brukeren ville lett.
- **`kosmetisk`** — språk, formatering, ordvalg. Ingenting blir galt av det.

**Ruting:** `blokkerende` går til patch-lanen i samme uke den oppdages —
piloten kjører videre på fikset versjon, og `Versjon`-feltet gjør det mulig å se
hvilke funn som gjelder hvilken kode. `friksjon` og `kosmetisk` samles og rutes
ved neste checkpoint.

**To disiplinregler som avgjør om loggen er verdt noe:**

1. **En friksjon som ble omgått uten å bli logget, finnes ikke.** Det er den
   vanligste feilen i egen-pilotering: operatøren kjenner koden, fikser i hodet,
   går videre — og loggen kommer til å vise en plugin som fungerer bedre enn den
   gjør. Logg først, fiks etterpå.
2. **Observasjon før diagnose.** `Observert` skrives uten forklaring på hvorfor.
   En diagnose skrevet samtidig som observasjonen former observasjonen.

**Operatørens kodekjennskap er en systematisk feilkilde, og håndteres her.**
Operatøren har skrevet pluginen og vil aldri *måtte* lese kildekoden for å komme
videre — enhver suksessport formulert som «kom i mål uten å lese koden» består
derfor trivielt. Regelen som faktisk måler det: **hver gang operatøren brukte
kunnskap om pluginen som ikke står i dokumentasjonen, er det et `friksjon`-funn**,
også når det ikke kostet et sekund. Det er den knappen som skiller «fungerer» fra
«fungerer for den som bygde den».

## 6. Suksesskriterier

Kriteriene er pilotens egne, og skal ikke forveksles med organisasjonens T3-OKR
— de er *objektet* piloten tester, ikke målestokken. Skillet committed/aspirational
følger pluginens egen doktrine.

**Committed — forventning: alle møtt. Avvik krever skriftlig forklaring i rapporten.**
De er binære prosessporter, ikke metrikker, og scores derfor møtt/ikke møtt.

| # | Kriterium | Bevis |
|---|---|---|
| K1 | Hele inn-siden kjørt på ekte tildelingsbrev: `/okr:oppsett`, `/okr:governance`, `/okr:gap`, `/okr:skriv` + kvalitetssjekk — hver fullført | Pilot-tre + funn-logg |
| K2 | Hele ut-siden kjørt på ekte syklusdata ved pilot-slutt: `/okr:sporing` sluttscoring, `/okr:rapport tertial`, `/okr:oppsett arkiver`, `/okr:analyse` | Genererte filer i pilot-treet |
| K3 | Funn-loggen har én oppføring per friksjon, med `Observert` skrevet før diagnose | Loggen selv |
| K4 | Ingen `blokkerende` funn står `åpen` ved pilot-slutt | Loggen selv |
| K5 | Datagrensen (§2) holdt gjennom hele piloten — hver fil i pilot-treet kan pekes til offentlig kilde | Checkpoint-gjennomgang |

**Aspirational — stretch. `At Risk` er den forventede tilstanden, ikke et varsel.**
Scores 0–1.0 ved pilot-slutt.

| # | Kriterium |
|---|---|
| A1 | T3-OKR-ene ble brukt i minst én reell styringsdialog (ledelsesreview eller etatsstyringsmøte), og materiellet kom fra pluginen |
| A2 | Institusjonelt minne demonstrert: minst én gang svarte retrieval på et spørsmål operatøren ellers måtte lett manuelt for |
| A3 | Én annen person enn operatøren kjørte minst én kommando og kom i mål uten hjelp |

A3 avhenger av noen utenfor prosjektet og kan falle på tilgjengelighet alene. Det
er grunnen til at den er aspirational — ikke fordi den er mindre interessant.

**Piloten kan konkludere negativt.** Faller K1 eller K2, er konklusjonen at
pluginen ikke er bevist i bruk, og 2.0.0-CHANGELOGens «Validated in a real T3
cycle» skrives ikke. Det er et gyldig utfall.

## 7. Kadens

| Punkt | Uke | Hva |
|---|---|---|
| E1b — oppstart | 36 (~1. sept) | Live inn-side: `/okr:oppsett`, `/okr:governance`, `/okr:gap`, `/okr:skriv` + kvalitetssjekk. Funn-loggen opprettes |
| E6 — checkpoint 1 | 40 (okt) | Månedsrytme på ekte data: `/okr:sporing` check-in, `/okr:møter`-materiell i reelt møte. Datagrense-gjennomgang (K5). Blokkerende funn rutes |
| E7 — checkpoint 2 | 45 (nov) | Samme. I tillegg: innboks-ingestion live på offentlige dokumenter, retrieval-eval mot voksende tre |
| E8 — avslutning | 49–50 (des) | Ut-siden: sluttscoring, arkivering + retrospektiv, `/okr:analyse`. Funn-loggen konsolideres |
| E9 — rapport | des | Sanitert pilot-rapport til `docs/`, 360-re-evaluering, 2.0.0-release med go-gate |

Mellom checkpointene kjøres piloten som normal drift — funn logges når de
oppstår, ikke samlet i etterkant.

## 8. Åpne poster (resten av G4)

Må avklares før E1b starter, uke 36:

1. **Org-profilen** — hvilken organisasjon og hvilket program piloten kjører på
   (`organisasjon:`/`program:` i profilen).
2. **Tildelingsbrevet** — hvilket konkret dokument, og den offentlige kilden det
   kan pekes til per §2.
3. **Eksakt sti** til pilot-katalogen per §3.

Ingen av disse er nødvendige for protokollen, og ingen av dem skrives inn i denne
fila når de avklares — de hører hjemme i pilot-katalogens egen `STATE.md` (§4).

## 9. Verifiseringslogg

| Påstand i dette dokumentet | Verifisert mot |
|---|---|
| `/okr:oppsett` skriver `~/.claude/okr/org/profil.md`, utenfor git | `scripts/write-org-profile.mjs:29` |
| Fila finnes ikke per 2026-08-11 | `ls ~/.claude/okr/org/` → No such file or directory |
| `origin` er det offentlige speilet `open/okr.git` | `git remote -v` |
| `docs/` er tracked; `.claude/` er gitignored | `.gitignore:40` + `git check-ignore -v` |
| Kommandoene i K1/K2 finnes | `ls commands/` (16 kommandoer, alle nevnte til stede) |
| Kadensen følger fasekartet | Sesjonsplanen, fase E (E1, E6, E7, E8, E9) |
| Datagrense og katalogvalg er operatørbeslutninger | G4 i sesjonsplanens beslutningsport-tabell; besvart 2026-08-11 |

*Skrevet 2026-08-11 (E1a). Datagrensen og katalogprinsippet er låst; org-profil og
tildelingsbrev står åpne til uke 36.*