dynamisk-rettsstat/skills/forbedre/SKILL.md

name

description

forbedre

Hjelper den som vil endre eller utvide modellen i notatet Den dynamiske rettsstaten: avklarer om det er andre forutsetninger (et scenario), en ny mekanisme (en utvidelse ved siden av kjernen, med et grensetilfelle som gjenskaper kjernen eksakt) eller en endring i kjernens ligninger; lager en arbeidskopi brukeren eier, finner ligning, funksjon og parameter i modellkartet, og kontrollerer etterpå hvilke av notatets resultater som flytter seg. Sier også hvordan forbedringen sendes tilbake. Bruk når noen vil forbedre, endre, utvide eller kalibrere modellen, legge til en mekanisme, endre en ligning eller sjekke en endring. Utløses av «forbedre modellen», «endre modellen», «legg til en mekanisme», «utvid modellen», «jeg vil endre ligningen for», «lag en arbeidskopi», «sjekk endringen min», «kjør kontrollen», «improve the model», «add a mechanism to the model».

Forbedre modellen

Ferdigheten hjelper den som vil endre eller utvide modellen i notatet Den dynamiske rettsstaten. Endringen gjøres i en kopi brukeren eier, og en kontroll sier etterpå om notatets resultater står fast, eller hvilke som har flyttet seg og hvor mye. Den trenger Python 3; kontrollen og kjøringene trenger i tillegg numpy og scipy.

Brukeren er oftest forsker, men ikke nødvendigvis programmerer. Snakk vanlig norsk. Forklar hva du gjør i koden med ord; vis kode når brukeren vil se den.

Regler

• Én endring om gangen. To endringer samtidig gjør det umulig å si hva som ga hvilket utslag.
• Hypotesen og grensetilfellet før koden. Si hva mekanismen skal gjøre, og for hvilken verdi den forsvinner.
• Hver påstand bygger på en kjøring. Si aldri at en endring «gir» noe før en kjøring har vist det, og gjengi skriptets tall ordrett.
• Kontroll etter hver endring, og les dommen for brukeren (trinn 6).
• Modellen er stilisert. Parameterne er ikke kalibrert på norske data, og kjøringene er ikke prognoser. Det gjelder også en forbedret modell, til den er kalibrert og prøvd mot data.
• Installer aldri noe uten å spørre.
• Pluginens egen modell endres aldri. Alt gjøres i kopien.

1. Hva vil brukeren endre?

Avklar hvilken av tre ting det er. Spør med vanlige ord, og foreslå svaret når det er opplagt:

Brukeren vil	Det er	Slik gjøres det
prøve andre verdier for parameterne, en annen styringsregel, beslutningsregel, sjokk eller tiltak	et scenario: ingen kode endres	ferdigheten simuler
legge til noe modellen ikke har (for eksempel kø i et ledd til, målestøy, forskyvning mellom kategorier)	en utvidelse: en ny mekanisme ved siden av kjernen, med et grensetilfelle som gjenskaper kjernen eksakt	trinn 2–7
endre ligningene modellen allerede har (en annen funksjonsform, en annen tilbakekobling)	en endring i kjernen	trinn 2–7

Mye som ser ut som en endring, er et scenario: alle kjernens parametere kan overstyres i en scenariofil (se ${CLAUDE_PLUGIN_ROOT}/docs/scenarioformat.md), og et pådrag som varierer over tid finnes alt som utvidelsen paadrag_tidsserie. Er det et scenario, si det og gå over til ferdigheten simuler. Unntaket er beslutningsreglene for påtale og budsjett (simulate_endo) med en annen strøm av saker ved start, for eksempel mer effektivt politi: den stopper scenariokjøreren, fordi regelen i kjernen bruker notatets startstrøm. Det er en endring i kjernen.

Kan mekanismen stå ved siden av kjernen, anbefal en utvidelse framfor å endre kjernen: notatets resultater ligger da fast, og grensetilfellet viser at de gjør det.

2. Lag en arbeidskopi

Endringer gjøres i en kopi brukeren eier. Si i én setning hvorfor: «Pluginen byttes ut når den oppdateres, så endringer der ville forsvinne; kopien er din.» Spør før du lager den, og foreslå mappa rettsstat-modell i brukerens arbeidsmappe:

python3 "${CLAUDE_PLUGIN_ROOT}/modell/kjor.py" --data "${CLAUDE_PLUGIN_DATA}" arbeidskopi <arbeidsmappe>/rettsstat-modell

• På Windows heter tolken python. Bruk hele stien.
• Kopien har modellen, eksemplene, fasiten, testene, dokumentasjonen og en LES-MEG.md. Den trenger ikke numpy og scipy for å lages.
• Finnes mappa og er ikke tom, nekter kommandoen (den skriver aldri over noe). Den nekter også en mappe inne i pluginen. Har brukeren en kopi fra før, kjør kontrollen på den (trinn 6) og si nivået før du bygger videre.
• Ferdighetene diagnose, forlop og simuler spør om de skal bruke kopien når arbeidsmappa har en rettsstat-modell/, og sier hvilket nivå kontrollen gir den.
• modell/kontroll.py i kopien har notatets sjekksummer som faste verdier; det er dem kontrollen måler mot. Endre den ikke: da sier kontrollen ikke lenger noe om notatet.
• Ligger kopien et sted brukeren ikke åpner selv (i Cowork kjører kommandoene i øktas egen Linux-maskin, og kopien havner der), si hvor den ligger, og tilby å gi den som en zip-fil sammen med hele utskriften fra kontrollen.

Forskere som bruker git kan i stedet klone pluginens repository (https://git.fromaitochitta.com/open/dynamisk-rettsstat.git), endre der og starte Claude Code med pluginen fra klonen: claude --plugin-dir . i mappa. Da bruker ferdighetene klonens modell direkte, og endringene kan sendes tilbake med git format-patch. En klone er ikke merket som arbeidskopi, så ved «endret» sier kontrollen at det er en feil hvis det er pluginen slik den er installert, og en opplysning hvis modellen er endret med vilje. Si til brukeren hvilket av de to det er.

3. Finn stedet i modellen

Les ${CLAUDE_PLUGIN_ROOT}/docs/modellkart.md (kopien har den samme i docs/). Den går fra notatets ligninger til funksjonene og parameterne i modell/kjerne/sim.py:

• del (a): tilstanden og ligningene slik koden regner dem;
• del (b): parameterne, verdiene og hvor de står i notatet;
• del (c): ligning → funksjon → status (implementert, forenklet, ikke implementert);
• del (d): de fem simulatorene og hvilke av notatets datafiler og figurer hver gir;
• del (e): grensetilfellene koden selv skriver ut.

Vis brukeren hvilken ligning, funksjon og parameter endringen gjelder, med linjenummer, og hvilken simulator det er enklest å bygge på.

Merk for endringer i kjernen: modell/kjerne/diagnose.py har egne kopier av regelverdiene, og modell/kjerne/forlop.py har en egen kopi av løkka i simulate_endo (modellkartet, «Konstanter i diagnose.py og forlop.py»). Endres de i sim.py, må kopiene endres likt; forløpet stopper ellers med «Intern kontroll feilet».

4. Hypotese og grensetilfelle

Skriv ned med brukeren, før noen kode:

• Hypotesen: hva mekanismen eller endringen skal gjøre i modellen, og hvorfor (gjerne med henvisning til litteratur eller data).
• Grensetilfellet: verdien av den nye parameteren der mekanismen forsvinner (en faktor lik 1, et ledd lik 0, en kapasitet lik uendelig). I den verdien skal modellen gi nøyaktig kjernens tall, største avvik 0.0, ikke bare lite.
• Hvilke av notatets resultater endringen kan tenkes å flytte (for en endring i kjernen), og hvilke den ikke skal røre.

Få et ja på dette før du skriver kode.

5. Gjør endringen

En utvidelse. Følg ${CLAUDE_PLUGIN_ROOT}/docs/utvidelser.md: grensesnittet (NAVN, BESKRIVELSE, PARAMETERE, simuler, grensetilfelle, og valgfritt BRUKER, sjekk og GJENSKAPER_NOTATET), malen mellom <!-- mal:start --> og <!-- mal:slutt --> og trinnene der. Kort:

• Fila er rettsstat-modell/modell/utvidelser/<navn>.py, og NAVN er filnavnet uten .py.
• Kopier løkka fra simulatoren du bygger på uendret, og legg mekanismen inn slik at den forsvinner i grensetilfellet. Bruk kjernens funksjoner der det går, og endre ikke rekkefølgen på regnestegene.
• Standardverdiene i PARAMETERE bør være grensetilfellet.
• grensetilfelle() kjører utvidelsen i grensetilfellet og kjernen med de samme forutsetningene, og returnerer største absolutte avvik.
• Gjenskaper utvidelsen med standardverdiene en av notatets scenariofiler, oppgi dem i GJENSKAPER_NOTATET. Da sjekker testene grensetilfellet også uavhengig av utvidelsens egen grensetilfelle(), mot notatets datafiler.

En endring i kjernen. Endre rettsstat-modell/modell/kjerne/sim.py (og kopiene i diagnose.py og forlop.py når det trengs). Endre bare det hypotesen gjelder.

Skriv en test. Grensetilfellet i hver utvidelse testes allerede automatisk (tests/test_utvidelser.py i kopien). Skriv i tillegg en test i tests/ for det mekanismen skal gjøre utenfor grensetilfellet, for eksempel retningen på utslaget. Testene kjøres med python3 -m pytest i kopien og trenger pytest; finnes det ikke, spør før du installerer det.

6. Kontroller

Kjør kontrollen på kopien etter hver endring:

python3 "${CLAUDE_PLUGIN_ROOT}/modell/kjor.py" --data "${CLAUDE_PLUGIN_DATA}" --modell <hele stien til rettsstat-modell/modell> kontroll

• Den fulle kontrollen kjører hele notatets simulering og tar et par minutter. Mens du prøver deg fram, kan du legge til --rask (hopper over den fulle kjøringen av sim.py); kjør den fulle før du sier hva endringen gjør.
• Utskriften viser de 40 første linjene som er ulike i hver sammenligning, og teller resten («… linjer til»). Vil brukeren se alt som har flyttet seg, eller skal utskriften sendes med en forbedring, legg til --alt.
• Kontrollen måler mot notatets egne sjekksummer, som står fast i modell/kontroll.py, ikke mot filene i kopien. Den har seks deler, nummerert slik i utskriften:
  1. kjernen (sim.py, diagnose.py, forlop.py) og fasiten (27 filer) mot notatets sjekksummer;
  2. diagnosen på begge eksempelfilene mot fasit, tegn for tegn;
  3. forløpet på begge eksempelfilene mot fasit;
  4. full kjøring av sim.py: de 22 datafilene og utskriften mot fasit (ikke med --rask);
  5. grensetilfellet i hver utvidelse, som skal gi avvik eksakt 0.0;
  6. scenariokjøreren: notatets scenariofiler kjørt gjennom kopiens kjører, mot fasit (13 filer med --rask, 14 i den fulle).

Exit-koder: 0 bit for bit eller innenfor toleranse, 1 endret, 2 feil bruk, 3 numpy eller scipy mangler. Ved 3 er bare kjernen, fasiten og diagnosen kontrollert. Spør: «Kontrollen trenger to vanlige regnebiblioteker for Python, numpy og scipy. Skal jeg installere dem i en egen mappe for denne pluginen?» Bare hvis svaret er ja:

python3 "${CLAUDE_PLUGIN_ROOT}/modell/kjor.py" --data "${CLAUDE_PLUGIN_DATA}" miljo --opprett

Gjengi det kommandoen sier, og kjør kontrollen på nytt.

Les dommen for brukeren. Den står i linja som begynner med «Nivå», nederst:

• «bit for bit som notatet»: endringen flytter ingen av notatets resultater. For en utvidelse er det det som skal skje, og grensetilfellet er eksakt. Står det «(uten full kjøring, --rask)», er sim.py ikke kjørt i sin helhet; si ikke at endringen er kontrollert før den fulle kontrollen er kjørt.

• «innenfor toleranse»: hvert tall avviker med høyst én enhet i siste viste siffer, som med andre versjoner av numpy og scipy. Notatets resultater står.

• «ingen avvik i det som ble kjørt (…). Ikke kontrollert: …»: numpy eller scipy mangler. Si hva som ikke er kontrollert, med kontrollens ord. Det er ikke en dom over endringen.

• «endret: …»: noe har flyttet seg. Si det rett ut, og si hva:

  • hvilke datafiler som er endret, og største absolutte avvik per kolonne (står i detaljene, under del 4 og 6). Bruk modellkartet, del (d), til å si hvilken figur eller tabell i notatet hver datafil hører til;
  • hvilke linjer i diagnosen, forløpet og utskriften fra sim.py som er endret (detaljene viser dem som «notatet» og «nå»), med tallene slik de står;
  • om kjernen eller fasiten er endret (del 1). Er fasiten endret, sier sammenligningene mot den ingenting om notatet.

  En endret kjerne er en opplysning, ikke en feil: kontrollen sier det selv i en arbeidskopi. Men det skal sies tydelig, og brukeren avgjør om endringen var ment. Var den ment, gå videre.

• En utvidelse som ikke gjenskaper kjernen (del 5: «… gjenskaper ikke kjernen i grensetilfellet. Det er en feil i utvidelsen …»): det er en feil, også i en arbeidskopi, og resultatene utvidelsen gir, kan ikke brukes før den er rettet. Finn feilen før du går videre.

Gjengi tallene fra kontrollen slik de står. Regn ikke ut egne avvik.

7. Prøv endringen

Kjør et scenario med kopien for å se hva endringen gjør, med ferdigheten simuler (den bruker kopien med --modell). For en utvidelse er "modell": "utvidelse:<navn>" og parameterne under "utvidelse"; et sveip over utvidelsens parameter, med grensetilfellet som én av verdiene, viser utslaget mot kjernen i samme tabell.

Si hva kjøringen viser, med skriptets tall, og ta med forbeholdet: parameterne er notatets stiliserte verdier, og kjøringene viser modellens dynamikk, ikke prognoser. Neste endring kommer først når denne er kontrollert.

8. Send forbedringen tilbake

Vil brukeren dele forbedringen, står framgangsmåten i ${CLAUDE_PLUGIN_ROOT}/BIDRA.md. Kort: en e-post til hello@fromaitochitta.com med endringen (en patch eller de endrede filene), utskriften fra kontrollen og scenariofilene som viser virkningen. Én mekanisme eller endring om gangen, med grensetilfelle og test, og ingen persondata eller data fra enkeltsaker. Det er et privat prosjekt, og det er ikke lovet noe svar innen en bestemt tid.