ai-psychosis/docs/BRIEF-vurdering-v2.md

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-reports 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-corpuss 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.