okr/docs/pilot-t3-2026.md

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.