docs(okr): pilot-protokoll for T3-2026 (fase E1a)

Datagrensen og pilot-katalogprinsippet er laast ved operatoerbeslutning
(G4, 2026-08-11): kun offentlige dokumenter i pilot-treet, og piloten
kjoerer i egen arbeidskatalog utenfor plugin-repoet.

Protokollen definerer funn-logg-format med definerte alvorlighetsgrader
og ruting, committed/aspirational suksesskriterier, kadens per fasekartet,
og en publiseringsgrense: protokollen er org-noeytral og offentlig, mens
funn-logg og pilot-tre bor privat i pilot-katalogen. Pilot-rapporten som
naar docs/ ved E9 er sanitert.

Org-profil og tildelingsbrev staar aapne til uke 36.

docs/pilot-t3-2026.md

@@ -0,0 +1,212 @@
+# 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.
+
+## 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 uten at operatøren måtte lese pluginens kildekode for å komme videre | Funn-logg + pilot-tre |
+| 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.*