docs(brief): verify VURDERING-V2 §5.2 claims against actual code

Self-serve handoff from claude-playlist-corpus's YouTube-corpus
assessment. Confirms the burst and edit-ratio heuristics in
tool-tracker.mjs are structurally blind to task type (bulk reads
trigger the same false positives as actual rapid-fire editing or
stuck/spiral sessions) — verified directly against the code, not
taken on the source's word. The two specific historical incidents
cited are unverifiable from this repo's own plugin data (no records
for the claimed date). Recommends a minimal task-type calibration
over the source's full labeled-corpus proposal. Stops before any
implementation per the handoff contract.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015TdjcTbNKKuBpew5HMaeDo

docs/BRIEF-vurdering-v2.md

@@ -0,0 +1,132 @@
+# Brief — VURDERING-V2 for ai-psychosis
+
+**Kilde:** `/Users/ktg/repos/claude-playlist-corpus/docs/VURDERING-V2.md` §5.2 (dette
+repoet) + §3 (G1–G8, generelle tiltak). Ekstern vurdering bygget på 442 YouTube-
+videoanalyser fra en «Claude»-spilleliste, syntetisert 2026-07-18. Repo-faktaene i
+kilden kommer fra en subagent-survey 2026-07-17 som **ikke er re-verifisert av
+kilden selv** — minst én feil er allerede påvist der. Denne briefen re-verifiserer
+hver påstand mot faktisk kode i dette repoet før noe anbefales.
+
+**Prosess fulgt:** handoff-prompten i `OVERFORING-V2.md` §3, inkludert de to
+obligatoriske verifiseringslagene (kode i dette repoet + Claude Code-feature-
+påstander mot `claude-code-llm-wiki`-bundlen). Ingen implementering er gjort —
+denne sesjonen stopper ved brief + STATE-oppdatering, per kontrakten.
+
+---
+
+## Verifiseringstabell
+
+| # | Påstand (V2 §5.2) | Status | Grunnlag |
+|---|---|---|---|
+| 1a | Burst-heuristikken («Rapid-fire») kan ikke skille lesetempo fra redigeringstempo — leseintensivt arbeid vil trigge den | **BEKREFTET** | `hooks/scripts/tool-tracker.mjs:48-58,109-115` + `lib.mjs:127-129`: `burstCount` øker på ethvert verktøykall <30s fra forrige, uavhengig av verktøytype. En bulk-lesing (mange raske `Read`-kall) og en faktisk «rapid-fire»-editeringssekvens produserer identisk signal. Ingen `tool_name`-differensiering i denne banen. |
+| 1b | Edit-ratio-heuristikken («possible stuck/spiral») kan ikke skille analysearbeid fra fastlåsthet | **BEKREFTET** | `tool-tracker.mjs:78-80,119-121`: `editRatio = edits/totalTools`, terskel <10 % over ≥30 min. En leseintensiv analyseoppgave (mange `Read`/`Grep`, få `Edit`) har strukturelt lav edit-ratio uavhengig av om arbeidet er produktivt. |
+| 1c | De to konkrete hendelsene (v1: «possible stuck/spiral» under legitim analyse; denne sesjonen: «Rapid-fire: 5 consecutive» under en planlagt 39-fils bulk-lesning 2026-07-18) faktisk inntraff slik beskrevet | **IKKE VERIFISERBART HERFRA** | `~/.claude/plugins/data/ai-psychosis/sessions.jsonl` (dette repoets egen plugin-datakatalog) har ingen poster for 2026-07-18 — siste post er 2026-06-24. Hendelsene beskrevet i V2 skjedde etter alt å dømme i en **annen** økt/repo mens denne pluginen var globalt aktiv (den kjører uansett hvilket repo man står i), ikke i data denne økten har tilgang til. Jeg kan verken bekrefte eller avkrefte de to spesifikke hendelsene — bare at *mekanismen* som ville produsert dem er reell (1a, 1b). |
+| 2 | Duolingo-funnet (`CDqzWpwkSls`): human-in-the-loop gir ofte stempling, ikke etterforskning; tekstendring kuttet falske avvisninger 21 % | **IKKE EN KODE-PÅSTAND** | Dette er et designprinsipp fra ekstern forskning, ikke en påstand om denne pluginens nåværende tilstand. Jeg har ikke sett primærkilden (videoen) selv og tar tallene som rapportert av V2, uverifisert utover det. Relevansen for `/interaction-report`s ordlyd er en vurdering, ikke en kode-sjekk. |
+| 3 | Addy Osmani-rammeverket (`4sX_He5c4sI`): cognitive debt / cognitive surrender / orchestration tax | **IKKE EN KODE-PÅSTAND** | Samme som over — eksternt begrepsapparat foreslått som språk for rapportene, ikke en påstand om dagens kode. Uverifisert utover det V2 rapporterer. |
+| 4 | Layer-2-analytics: kun enkeltrapporter i dag, ingen trend-loop over akkumulert JSONL | **DELVIS AVKREFTET / ENDRET** | `commands/interaction-report.md:183-190,329-338`: `/interaction-report weekly` og `monthly` beregner ALLEREDE periode-over-periode-trend (samme metrikker for forrige periode, delta). V2s framing («bare enkeltrapporter») er unøyaktig. Det som derimot IKKE finnes: den spesifikke metoden V2 peker på (`B95cu7seTm8` — mine transkripter for atferdssekvens-metrikker som reads-før-edits og tests-etter-edits-ratioer). Dagens datamodell lagrer kun boolske flagg og aggregerte tellere (`events.jsonl`: `{ts, session_id, tool_name}`), ikke rekkefølge-par mellom spesifikke verktøykall — og kan strukturelt ikke uten en datamodellendring. |
+
+---
+
+## Anbefalte tiltak (prioritert)
+
+### 1. Kalibrer burst- og edit-ratio-heuristikkene mot oppgavetype (høyest prioritet)
+
+**Hvorfor:** Punkt 1a/1b over er bekreftet strukturelt i koden — ikke en hypotese.
+Uten dette lærer operatøren å ignorere varsler, og en falsk-positiv-tung plugin blir
+netto negativ for akkurat den atferden den skal bygge («treningsmerke»-logikken i
+Duolingo-funnet, punkt 2, gjelder direkte her selv om selve tallet der er
+uverifisert).
+
+**Konkret, minimal endring som løser den bekreftede mekanismen** (ikke V2s fulle
+forslag om et merket korpus — se «Forkastet» under):
+- Burst-tellingen (`tool-tracker.mjs:48-58`) kan differensiere på verktøytype: en
+  sekvens av kun `Read`/`Grep`/`Glob` (les-tunge verktøy) bør ikke telle mot
+  `THRESHOLD_HARD_BURST` på samme måte som en sekvens med `Edit`/`Write`/`Bash`
+  innblandet. Dette er en liten, lokal endring i eksisterende logikk, ikke et nytt
+  delsystem.
+- Edit-ratio-varselet (`tool-tracker.mjs:119-121`) kan legge til en enkel
+  read-tung-signatur som demper eller omformulerer meldingen («possible stuck/
+  spiral» vs. «leseintensiv analyse — normalt for research/audit-oppgaver») når
+  toolCount er høyt og verktøyene er overveiende lesing.
+- Begge er implementerbare uten å bryte privacy-designet (ingen ny loggføring av
+  innhold — kun `tool_name`, som allerede logges i `events.jsonl`).
+
+### 2. Nyansér rapportspråket bort fra godkjenning, mot undersøkelse
+
+**Hvorfor:** Selv om Duolingo-tallene (punkt 2) er uverifisert av meg, er
+designprinsippet i seg selv billig å vurdere og krever ingen nye data — bare
+ordlyd i `commands/interaction-report.md` og varseltekstene i `tool-tracker.mjs`.
+«Utform for etterforsker, ikke validator» og «logg diffen, ikke bare ja/nei» er
+konkrete nok til å sjekkes mot dagens varseltekster direkte:
+`hooks/scripts/tool-tracker.mjs:112,115,121` skriver i dag korte, konklusive
+setninger («possible stuck/spiral», «Rapid-fire: N consecutive») uten kontekst om
+*hvorfor* eller *hva bør sjekkes*. Et lite ordlyds-tiltak, ikke en arkitekturendring.
+
+### 3. Utvid trend-seksjonen — ikke bygg en ny (lav prioritet, betinget)
+
+**Hvorfor:** Punkt 4 er delvis avkreftet — periode-over-periode-trend finnes
+allerede. Det V2 faktisk mangler er sekvens-metrikker (reads-før-edits,
+tests-etter-edits), som krever en datamodell-endring (logge rekkefølge, ikke bare
+tellere) — det er en større, ikke triviell utvidelse, og bør ikke igangsettes før
+tiltak 1 og 2 er på plass og målt. Nevnes som mulig neste steg, ikke anbefalt nå.
+
+---
+
+## Forkastede tiltak
+
+- **Fullt merket benign/problem-sesjonskorpus med presisjon/recall-måling per
+  heuristikk** (V2s fulle forslag for punkt 1). Forkastet i denne formen: det
+  krever et treningsdatasett denne pluginen med vilje ikke samler (prompt-tekst
+  lagres aldri, jf. `README.md` Privacy-seksjonen) og et evalueringsrammeverk som
+  ikke finnes i noen av de 17 repoene ennå (V2 §3 G1 bekrefter dette generelt).
+  Den minimale kode-endringen i «Anbefalte tiltak» punkt 1 løser den bekreftede
+  mekanismen uten å bygge et evalueringssystem for et enkelt plugin først. Hvis
+  presisjon/recall skal måles seriøst, hører det hjemme i G1-arbeidet på tvers av
+  repoer (`config-audit`, `llm-security` er navngitt som første kandidater i V2),
+  ikke som et engangsprosjekt her.
+- **Layer-2 transkript-mining for atferdssekvenser** (fullt forslag i punkt 4).
+  Forkastet *for nå*: krever en datamodell-utvidelse (logge rekkefølge av
+  verktøykall-par, ikke bare tellere) som ikke er trivielt forenlig med dagens
+  minimale, personvern-førte lagringsformat uten videre design. Nevnt som mulig
+  fremtidig retning i tiltak 3, ikke anbefalt som umiddelbart arbeid.
+- **G1/G2 som skrevet i V2 §3** (skill-evals og CI) gjelder eksplisitt for dette
+  repoet ifølge overføringsprompten, men begge er repo-på-tvers-initiativer (V2
+  peker selv på `config-audit` og `llm-security` som første kandidater for G1; G2
+  peker på `catalog` og sikkerhetsgrense-repoene først). Ingen av dem er forkastet
+  som idé — de er utenfor omfanget for en enkelt-repo-brief og hører hjemme i en
+  operatørbeslutning på tvers av repoer, ikke i dette dokumentet.
+
+---
+
+## Åpne spørsmål til operatøren
+
+1. Skal tiltak 1 (kalibrering av burst/edit-ratio mot oppgavetype) tas som egen
+   TDD-oppgave nå, eller vente til flere reelle FP-hendelser er observert (den
+   nåværende plugin-datakatalogen har ingen data etter 2026-06-24 — vet vi om
+   pluginen faktisk kjører aktivt for øyeblikket)?
+2. Er de to spesifikke hendelsene fra V2 (v1-sesjonen, og bulk-lesningen
+   2026-07-18) verifiserbare fra `claude-playlist-corpus`s egen side — altså i
+   DERES plugin-datakatalog, siden hendelsene sannsynligvis skjedde der pluginen
+   var aktiv mens claude-playlist-corpus-repoet ble jobbet i? Det ville gjort
+   punkt 1c om fra uverifiserbart til bekreftet/avkreftet.
+3. Skal G1 (skill-evals) og G2 (CI) — som V2 selv sier gjelder på tvers av repoer
+   med andre repoer som første kandidater — tas opp igjen for ai-psychosis når de
+   initiativene eventuelt starter andre steder, eller behandles de som ute av
+   scope for dette repoet permanent?
+
+---
+
+## Bundle-gap
+
+`§5.2` i V2 inneholder ingen direkte Claude Code-plattform-feature-påstander (de
+fire punktene er alle eksternt forskningsmateriale — Duolingo-video, Wharton-
+studie, Osmani-rammeverk, JSONL-mining-video — ikke påstander om hva Claude Code
+kan eller ikke kan). Det var derfor ingenting konkret å sjekke `claude-code-llm-
+wiki`-bundlen mot for denne spesifikke seksjonen. Ingen wiki-side lest ga grunn
+til å endre noe i tabellen over.
+
+Notert for oversikten (gjelder hele V2, ikke spesifikt for dette repoet): kjent
+gap i bundlen er 8 av 344 release-sider med `date` lik ingest-datoen 2026-07-16
+(`v0.2.21/26/63/75/82`, `v1.0.97`, `v2.1.43`, `v2.1.46`) — ingen av disse
+versjonene er relevante for noe i denne briefen, så gapet påvirker ikke
+konklusjonene her.