Täydellinen opas Karpathyn LLM-wiki-työnkulkuun

Viisi päivää sen jälkeen, kun Andrej Karpathy julkaisi "LLM-wiki"-työnkulkunsa, internet oli jo tuottanut yli viisitoista toimivaa toteutusta, tapaustutkimuksen 2 500 päiväkirjamerkinnästä sekä jatkuvan väittelyn siitä, onko tämä kaikki vain RAG ylimääräisin vaihein. Twiittiä on katsottu kuusitoista miljoonaa kertaa. Sitä seurannut gist on kerännyt yli viisituhatta tähteä ja 1 483 forkkausta. Ihmiset eivät lue tätä kommenttina — he lukevat sen ohjeena.

Tämä opas on toiseen leiriin kuuluville lukijoille. Se käy läpi mitä Karpathy todella rakensi, tarkat työkalut jotka hän nimesi, hakemistorakenteen joka pitää kokonaisuuden koossa, community-toteutukset jotka vievät ideaa hyödyllisiin suuntiin, ja paikat joissa se hiljaa särkyy. Se olettaa, että haluat rakentaa sellaisen itse.

Mitä Karpathy todella rakensi

Huhtikuun 2. päivänä 2026 Karpathy julkaisi lyhyen viestin X:ssä ja pidemmän gistin, joka kuvasi henkilökohtaista tietotyönkulkua. Kehystys merkitsi yhtä paljon kuin sisältö. Hän kirjoitti, että "iso osa viimeaikaisesta token-läpimenostani menee vähemmän koodin manipulointiin ja enemmän tiedon manipulointiin" — huomionarvoinen myönnytys joltakulta, jonka julkinen identiteetti rakentuu viime vuosikymmenen luetuimman syväoppimiskoodin kirjoittamiselle.

Ydinselitys gististä on yksi lause, joka on syytä lainata tarkasti:

"I index source documents into a raw/ directory, then I use an LLM to incrementally 'compile' a wiki, which is just a collection of .md files in a directory structure."

Tämä on koko mekanismi. Raakainputti menee yhteen kansioon. LLM lukee ne ja tuottaa linkitettyjä markdown-tiedostoja toiseen kansioon. LLM vastaa ristiviittauksista, indeksistä, otsikoista, muotoilusta ja — kriittisesti — aiempien sivujen päivittämisestä uuden tiedon saapuessa. Ihminen käyttää wikiä Obsidianin kautta, ei oman käyttöliittymän kautta.

Karpathy kehysti sen "vibe-koodatuksi" henkilökohtaiseksi järjestelmäksi, ei tuotteeksi. Tämä kehystys on osa syytä miksi se levisi: se oli selvästi toistettavissa kenelle tahansa jolla on terminaali ja LLM-avain. 48 tunnin sisällä ihmiset forkkasivat gistin ja pushasivat toimivia repoja. Viidessä päivässä ekosysteemissä oli tarpeeksi vaihtelua best practicesien keskustelemiseksi.

Tarkat työkalut joita Karpathy käyttää

Karpathy oli yksityiskohtainen stackinsa suhteen. On syytä listata osat kokonaisuudessaan, koska suuri osa toissijaisesta kommentista on ollut huolimatonta tältä osin.

• Obsidian — frontend ja IDE. Karpathy selaa, kyselee ja muokkaa wikiä Obsidianin markdown-natiivin käyttöliittymän kautta. Hän ei rakentanut omaa UI:ta. Tämä on tietoinen erottelu: AI kirjoittaa tiedostot, Obsidian lukee ne.
• Obsidian Web Clipper — ingestointireitti verkkoartikkeleille. Se muuntaa sivut puhtaaksi markdowniksi joka laskeutuu raw/-kansioon ilman manuaalista kopiointia.
• Oma, vibe-koodattu CLI/verkkohakutyökalu — Karpathy mainitsee pienen hakukerroksen jonka hän kirjoitti itse lähdedokumenttien löytämiseen. Hän ei julkaissut sitä. Se on erikoinen pala, jonka useimmat uudelleentoteutukset korvaavat ripgrepillä tai kolmannen osapuolen haulla.
• qmd Tobi Lütkeltä — Shopifyn toimitusjohtaja julkaisi hybridi BM25 + vector search -työkalun, jota Karpathy kehui skaalauspoluksi kun wiki kasvaa yhden indeksitiedoston rajat ylittäen. qmd on vastaus kysymykseen "mitä teen kun index.md ei enää mahdu kontekstiin."
• Marp — markdown slideiksi. Karpathy käyttää wikiään totuuslähteenä esitelmilleen. Diaesitys on vain yksi kompiloitu tuotos samasta sisällöstä.
• Dataview — Obsidian-plugin frontmatteriin kyselemiseen. Jos jokaisella sivulla on confidence: 0.7- tai stale: true-kenttä, Dataview muuttaa vaultin kyselykelpoiseksi tietokannaksi poistumatta markdownista.
• matplotlib — Karpathy antaa LLM:n generoida Python-kuvaajia strukturoidusta datasta wikissä ja renderöidä ne kuviksi tekstin viereen. Kaaviot ovat kompiloituja, ei käsin piirrettyjä.
• Git — versionhallinta sekä raw/- että wiki/-kansiolle. Jokainen LLM-muokkaus tulee commitiksi, mikä tarkoittaa että voit diffata mitä malli teki ja palauttaa kun se hallusinoi.

Hän ei nimennyt tiettyä LLM:ää. Mutta hänen gistinsä skeematiedosto on nimeltään CLAUDE.md, joka on Claude Coden käyttämä konventio. Community on ottanut tämän vahvaksi vihjeeksi siitä, että pääajuri on Claude Code, joka operoi paikallisessa hakemistossa.

Arkkitehtuuri: raw/ vs wiki/

Hakemistorakenne on kantava idea. Lähes jokainen virhe varhaisissa uudelleentoteutuksissa jäljittyy näiden kahden kansion rajan hämärtämiseen.

knowledge/
├── raw/           # immutable source documents (never edited by LLM)
│   ├── articles/
│   ├── papers/
│   ├── notes/
│   └── transcripts/
├── wiki/          # LLM-owned markdown (rewritten on every ingest)
│   ├── index.md
│   ├── people/
│   ├── concepts/
│   └── projects/
└── CLAUDE.md      # schema, conventions, instructions for the agent

raw/ on muuttumaton. Pudotat tiedostoja sisään, LLM lukee ne, mikään ei kirjoita takaisin. Jos muokkaat raakatiedostoa, muokkaat lähteitäsi, ja wiki muuttuu valheeksi. Kohtele sitä read-only-arkistona. Useimmat toteutukset pakottavat tämän git pre-commit -hookilla tai yksinkertaisella chmodilla.

wiki/ on LLM:n omistama. Et muokkaa wiki-sivuja käsin. Jos teet niin, seuraava ingestointi kirjoittaa muutoksesi hiljaa yli. Jos haluat korjata jotain, korjaa joko perustana oleva raakadokumentti tai lisää ohje CLAUDE.md-tiedostoon. Tämä tuntuu tiukalta, ja on sitä, mutta se on ainoa tapa jolla "itse-ylläpitävä"-ominaisuus kestää.

CLAUDE.md (tai AGENTS.md) on skeematiedosto. Se kertoo agentille mitä konventioita käytetään: miten tiedostot nimetään, mitä frontmatter-kenttiä vaaditaan, millaisessa tyylissä teksti on, miten ristiriitoja käsitellään, milloin luodaan uusi sivu vastaan päivitetään olemassa olevaa. Tämä tiedosto on lähin mitä työnkululla on konfiguraatiokerrosta.

Tätä rakennetta vastaan ajetaan kolme operaatiota:

1. Ingest — uusi tiedosto laskeutuu raw/-kansioon. Agentti lukee sen, tunnistaa mihin olemassa oleviin wiki-sivuihin se vaikuttaa, ja päivittää noin kymmenestä viiteentoista sivua yhdellä ajolla: uuden aihesivun, indeksin, ristiviitatut konseptit, olennaiset henkilösivut. Tämä on kallis operaatio. Täällä "kompilointi" tapahtuu.
2. Query — kysyt kysymyksen. Agentti lukee wiki/index.md:n, päättää mitkä sivut ovat relevantteja, avaa ne sivut ja syntetisoi vastauksen. Kriittisesti se kyselee kompiloitua wikiä, ei raaka-arkistoa. Kompilointityö maksaa itsensä takaisin täällä.
3. Lint — ajetaan aikataulutetusti tai pyynnöstä. Agentti tarkastaa wikin ristiriitojen varalta ("sivu A sanoo X, sivu B sanoo ei-X"), orpoja sivuja (joihin mikään ei linkitä) ja vanhentuneita väitteitä (joiden lähde raw/-kansiossa on korvattu). Tämä operaatio estää rappeutumista.

Mitä ihmiset todella rakentavat

Viiden päivän sisällä alkuperäisestä viestistä GitHubissa oli yli viisitoista uudelleentoteutusta. Kourallinen on tarpeeksi sisällöllisiä opiksi otettavaksi.

Ar9av/obsidian-wiki kohtelee agenttikerrosta plug-in-tyyppisenä. Sama wiki voidaan ajaa Claude Codella, Codexillä, Cursorilla, Windsurfilla, Copilotilla tai Geminillä, vaihtaen skills-pohjaisen arkkitehtuurin kautta joka käärii kunkin tarjoajan. Tämä on hyödyllistä, jos haluat välttää koko setupin lyömistä yhden toimittajan hinnoittelukäyrän varaan.

nvk/llm-wiki on NVK:lta, pitkän linjan Bitcoin-kehittäjältä, ja se on tähän mennessä mielipiteisin toteutus. Se tuo kolme kyselysyvyyttä (fast, deep, exhaustive), eksplisiittisen confidence-pisteytyksen jokaiselle väitteelle, ja dual-linkingin — jokainen wiki-sivu linkittää sekä raakalähteisiin joista se on rakennettu että muihin wiki-sivuihin joihin se liittyy. Dual-linking on varastettava idea.

ussumant/llm-wiki-compiler julkaisi tähän mennessä ainoan todellisen benchmarkin. Testattuna 383 markdown-tiedoston korpuksella (13,1 MB) se raportoi noin 84 % vähemmän tokeneita kyselysession kohden verrattuna raakatiedostojen suoraan lataamiseen — noin 3 200 kontekstirivistä sessiota kohti noin 330:een. Tämä on empiirinen tulos jota kukaan ei ole nostanut prominentisti, ja se on vahvin kvantitatiivinen argumentti koko lähestymistavalle.

kenhuangus/llm-wiki ajaa koko pipelinen paikallisilla malleilla — LM Studio tarjoaa Gemma 4:n — ja lisää automatisoidun arXiv- ja CVE-feedien seurannan jatkuvina ingest-lähteinä. Ei pilveä, ei API-laskuja, ja wiki päivittää itse itseään yöllä kun kone on joutilaana.

iamsashank09/llm-wiki-kit toteuttaa koko jutun MCP-palvelimena. CLI:n sijaan se tarjoaa ingest/query/lint MCP-työkaluina, joita Cursor tai Claude Code voi kutsua suoraan. Tämä on luultavasti mihin ekosysteemi on menossa.

swarajbachu/cachezero oli ensimmäinen Show HN -julkaisu alueella, markkinoiden itseään "Karpathyn LLM-wiki-idea yhtenä NPM-asennuksena". Se on pienimmän kitkan tapa kokeilla mallia, jos haluat toimivan vaultin pystyyn alle kymmenessä minuutissa.

Farzapedia-tapaustutkimus

Näyttävin harjoittajaesimerkki on Farza Majeediltä (@FarzaTV). Farza syötti noin 2 500 merkintää henkilökohtaisesta päiväkirjastaan, Apple Notesista ja iMessage-keskusteluista Karpathyn tyyliseen pipelineen ja kutsui tulosta "Farzapediaksi". Tuloksena oli noin 400 linkitettyä wiki-artikkelia, jotka kattoivat ystävät, aiemmat startupit, tutkimusintressit ja — koska tämä on Farza — useita anime-syväsukelluksia.

Farzapedian tekee kiinnostavaksi lähdemateriaali. Se ei ole tutkimuskorpus. Se on elämän järjestäytymätöntä oheisdataa: tekstiviestejä, heitettyjä muistiinpanoja, päivättyjä päiväkirjamerkintöjä. Kompilointivaihe veti kaiken navigoitavaksi. Karpathy itse siteerasi twiitissä tätä, kutsuen syntynyttä muistiartefaktia "eksplisiittiseksi ja navigoitavaksi" — huolellinen fraasi. Pointti ei ole että wiki tietäisi enemmän kuin Farzan muistiinpanot. Pointti on että wikissä voi vaeltaa.

Tämä on tähän mennessä vakuuttavin olemassaolotodiste sille, että malli yleistyy Karpathyn oman tutkimustyönkulun ulkopuolelle.

Best practicet jotka syntyivät päivissä

Lyhyestä aikajanasta huolimatta on muodostunut karkea konsensus siitä mikä toimii.

YAML-frontmatter confidence- ja staleness-kentillä. Jokainen wiki-sivu saa otsikon kuten:

---
title: "Pipeline v2 architecture"
confidence: 0.8
last_ingested: 2026-04-06
sources: [raw/notes/2026-03-22-sync.md, raw/articles/pipeline-blog.md]
content_hash: 8f3a...
stale: false
---

Dataview-kyselyt nostavat sitten matalan confidencen sivut, vanhentuneet sivut tai orvot suoraan Obsidianissa.

Tiukka raw/ vs wiki/ -erottelu. Jo käsitelty yllä, mutta tämä on käytäntö joka useimmiten rikotaan varhaisissa forkeissa, ja sillä on pahin vikatila.

Steph Angon vault-erottelumalli. Steph Ango (@Kepano), Obsidianin toimitusjohtaja, kirjoitti viikolla että agenttien tulisi "make a mess in their own space" sen sijaan että muokkaisivat ihmisen henkilökohtaista vaultia. Hänen suosituksensa on pitää käsinkirjoitetut Obsidian-muistiinpanot yhdessä vaultissa ja osoittaa LLM-wiki erilliseen, uhrattavaan vaultiin. Tämä estää sen minkä hän kutsuu hallusinaatiokontaminaatioksi — tilanteen jossa malli keksii faktan, kirjoittaa sen luotettuihin muistiinpanoihisi, ja lukee sen sitten takaisin seuraavalla viikolla kuin se olisi totuutta. Kun hallusinoitu linkki on kerran grafissasi, se vahvistuu jokaisella seuraavalla ingestillä.

Content hash -tunnistus. Hashaa jokainen raakatiedosto ingestattaessa. Jos hash muuttuu, merkitse jokainen sitä siteerannut wiki-sivu vanhentuneeksi. Tämä on halvin mahdollinen lint-askel ja nappaa suurimman osan rappeutumisesta.

qmd haun skaalaukseen. Yhden indeksitiedoston malli toimii noin 100–150 artikkeliin asti. Sen yli index.md itse tulee suuremmaksi kuin mukava kontekstiruutu, ja agentti alkaa jauhaa. Tobi Lütken qmd antaa hybridi BM25/vector retrieval -kerroksen jota agentti voi kutsua työkaluna, joten indeksistä tulee API-kutsu tiedoston lukemisen sijaan. Tämä on ainoa puhdas skaalauspolku jota kukaan on julkaissut.

Skeematiedostot konventioina. CLAUDE.md ja AGENTS.md konvergoituvat kahdeksi tiedostonimeksi joita agentit etsivät. Laita tyylioppaasi, vaaditut frontmatter-kentät, ristiinlinkityssäännöt ja disambiguaatiosäännöt jompaankumpaan näistä tiedostoista. Kaikki muu seuraa.

Missä se pettää

Tämä on osa työnkulusta jonka suurin osa entusiastikattavuudesta ohittaa. Malli on hyvä. Se ei ole valmis.

Indeksi kasvaa yli kontekstiruudun. Muutamien satojen artikkelien yli wiki/index.md muuttuu hankalaksi. Voit tiivistää sitä, shardata, tai siirtyä qmd:hen, mutta mikään näistä ei ole ilmaista. Jokainen skaalausratkaisu tuo retrievalin, ja retrieval on se jota malli oli tarkoitus korvata. Jollain korpuskoolla työnkulusta tulee hiljaa RAG-kompiloidun-markdownin-yli, mikä on puolustettavissa mutta myöntämisen arvoista.

Lainaustarkkuus on heikko. Wiki voi sanoa "tämä päätös tehtiin 22. maaliskuuta" ja siteerata raw/notes/2026-03-22-sync.md:tä, mutta se ei voi helposti siteerata "sivu 47, kappale 3". Tutkimustyölle jossa proveniens on tärkeää, tämä on aukko. Ainoa tähän mennessä tunnettu kiertotie on esikäsitellä raakatiedostoja tarpeeksi pieniin paloihin, jotta tiedostonimi on tarpeeksi tarkka — mikä, jälleen, alkaa näyttää chunkingilta.

Hallusinaatiokontaminaatio on todellinen. Jos LLM keksii linkin ingestattaessa, linkki pysyy. Seuraavalla ingestillä malli lukee oman keksintönsä lähdemateriaalina ja vahvistaa sitä. Steph Angon erillis-vault-malli lieventää tätä; lint-askelet nappaavat osan; mutta kenelläkään ei ole periaatteellista ratkaisua. Wiki voi ajautua pois raaka-arkistosta eikä ole automaattista hälytystä.

Token-kustannukset skaalassa ovat julkaisemattomia. Kukaan wikiä tuotannossa ajava ei ole julkaissut oikeita lukuja. Ingest-operaatio koskettaa kymmentä-viittätoista sivua uuden dokumentin kohdalla, jokainen täydellinen luku-ja-kirjoitus. Claude Sonnet -hinnoilla kiireinen tietotyöläinen voisi polttaa merkittäviä rahoja kuukaudessa, mutta emme vielä tiedä onko se kymmenen dollaria vai kaksisataa. Ussumantin benchmark koskee kyselyajan säästöjä, ei ingest-ajan kustannuksia.

"Tämä on vain RAG" -keskustelu. Merkittävä osa teknisestä kommentista on jokin variaatio lauseesta "kompiloi markdown sitten kysele siitä on kirjaimellisesti retrieval-augmented generation". Säilytettävä ero on että kompilointi on lossy ja mielipiteinen — LLM tekee toimituksellisia päätöksiä ingestattaessa jotka klassinen RAG lykkää kyselyaikaan. Lasketaanko tämä uudeksi paradigmaksi vai saman työn sijoittamiseksi uudelleen, on määritelmäkysymys, eikä se ratkea twiitillä.

Kokoustranskriptien mahdollisuus

Karpathy listasi useita lähdetyyppejä gistissä. Yksi rivi on siteerattava kokonaisuudessaan, koska se osoittaa aukkoon jota kukaan ei ole täyttänyt:

"Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. The wiki stays current because the LLM does the maintenance that no one on the team wants to do."

Tämä lause sisältää sanomattoman teesin jokaisesta kokous-AI-työkalusta markkinoilla. Kokoustranskriptit ovat korkeimman tuoton input Karpathyn tyyliselle wikille: ne generoituvat automaattisesti, ne ovat relaationaalisia, ne kumuloituvat, eikä kukaan halua ylläpitää niitä käsin. Ne ovat juuri sellaisia dokumentteja, jotka hyötyvät kompiloinnista pikemminkin kuin varastoinnista.

Ja silti, tällä viikolla, ei ole olemassa tuotetta joka automaattisesti syöttäisi kokouskeskustelut kumuloivaan Karpathy-tyyliseen wikiin. Lähimmät vertaistyökalut pysähtyvät kokouskohtaisiin yhteenvetoihin. Aukko välillä "tässä yhteenveto tämän päivän puhelusta" ja "tässä ylläpidetty wiki-sivu Q3-hinnoittelupäätökselle, päivitetty niiden seitsemän kokouksen yli joissa se nousi esiin" on suuri, ja se on yhä enimmäkseen tyhjä.

Proudfrog miettii tätä ongelmaa, ja aiempi teksti Karpathyn wikistä ja kokoustiedosta menee syvemmälle arkkitehtuurisiin seurauksiin. Laajemmalle argumentille siitä miltä kompiloitu kokoustietograf näyttää päivittäisessä käytössä, ks. knowledge worker -työnkulku, ominaisuudet-sivu tai hinnoittelu.

Lyhyesti: Karpathy osoitti miltä määränpää näyttää. Mielenkiintoinen työ nyt on putkien vetäminen paikkoihin, joissa raakamateriaalia jo tuotetaan.

---

Usein kysytyt kysymykset

Mitä LLM:ää Karpathy käyttää wikissään?

Karpathy ei nimennyt eksplisiittisesti mallia alkuperäisessä viestissä tai gistissä. Hänen julkaisemansa hakemistorakenteen skeematiedosto on kuitenkin nimeltään CLAUDE.md, joka on Anthropicin Claude Coden käyttämä konventio. Communityn konsensus on, että pääajuri on Claude Code joka ajetaan paikallista hakemistoa vastaan, vaikka toteutuksia on julkaistu GPT-pohjaisella Codexillä, Geminillä, Cursorilla ja paikallisilla malleilla LM Studion kautta. Työnkulku on malliagnostinen — se mikä merkitsee on, että agentti voi lukea ja kirjoittaa tiedostoja hakemistossa.

Pitääkö minun olla kehittäjä rakentaakseni oman LLM-wikin?

Sinun täytyy olla mukavasti terminaalin, gitin ja LLM-koodausagentin kuten Claude Coden tai Cursorin kanssa. Sinun ei tarvitse kirjoittaa koodia alusta — useat uudelleentoteutukset (cachezero, llm-wiki-kit, obsidian-wiki) asentuvat muutamassa minuutissa ja antavat sinulle toimivan vaultin. Jatkuva työ on skeematiedoston kuratointia, päätöstä siitä mitä menee raw/-kansioon, ja sen tarkistamista mitä agentti kirjoittaa. Ajattele sitä järjestelmän operointina pikemminkin kuin rakentamisena.

Miten tämä eroaa RAG:stä?

Klassinen RAG chunkkaa dokumentit, embeddaa ne ja hakee samankaltaisia chunkkeja kyselyaikaan. Haku on samankaltaisuuspohjainen ja tapahtuu kun kysyt kysymyksen. Karpathyn wiki kompiloi raakadokumentit strukturoituun, linkitettyyn markdowniin ingest-aikana, ja LLM tekee toimituksellisia päätöksiä — mikä on tärkeää, mikä linkittyy mihin, mitä päivitetään — ennen kuin mitään kysymystä on esitetty. Kyselyaikaan malli lukee kompiloitua wikiä, ei raaka-arkistoa. Muutamien satojen artikkelien yli ero hämärtyy koska indeksiä itseään on haettava, mutta henkilökohtaisessa mittakaavassa kompilointivaihe kantaa merkityksellistä informaatiota jonka puhdas samankaltaisuushaku heittää pois.

Mitä tapahtuu kun wiki tulee liian suureksi kontekstiruutuun?

Yhden indeksitiedoston malli rikkoutuu noin 100–150 artikkelin kohdalla, kun wiki/index.md lakkaa mahtumasta mukavasti kontekstiin. Puhtain tähän mennessä julkaistu skaalauspolku on qmd Tobi Lütkeltä, hybridi BM25- ja vector search -työkalu jota agentti kutsuu retrieval-askeleena. Sen yli aloitat wikin shardaamisen aiheen tai aikajakson mukaan. Tämä on rehellinen paikka jossa malli tuo retrievalin takaisin, ja sitä kannattaa suunnitella jos korpuksesi kasvaa.

Voinko käyttää tätä kokoustranskripteilleni?

Periaatteessa kyllä — pudota transkriptit raw/transcripts/-kansioon ja anna agentin kompiloida ne. Käytännössä kokoustranskriptit ovat meluisia, puhujakohtaisia ja aikaleimattuja, eikä yleinen wiki-agentti tiedä miten painottaa päätöksiä, poimia toimenpiteitä tai deduplikoida toistuvia keskusteluja. Tämä on se aukko jota Proudfrog työstää. Syvemmälle käsittelylle siitä miltä kokous-natiivi kompiloitu wiki näyttäisi, ks. Karpathyn LLM-wiki ja mitä se merkitsee kokoustiedolle.

Mikä on ero raw/- ja wiki/-kansioiden välillä?

raw/ pitää lähdedokumenttejasi — artikkeleita, papereita, muistiinpanoja, transkriptejä — ja on muuttumaton. LLM lukee siitä mutta ei koskaan kirjoita takaisin. wiki/ pitää kompiloitua markdownia jonka LLM omistaa kokonaan: se luo, päivittää ja uudelleenjärjestää sivuja uusien lähteiden saapuessa. Et muokkaa wiki/-tiedostoja käsin, koska seuraava ingest kirjoittaa ne yli. Jos tarvitset korjata jotain, korjaa perustana oleva lähde raw/:issa tai päivitä säännöt CLAUDE.md:ssä. Näiden kahden kansion pitäminen tiukasti erillään on työnkulun tärkein yksittäinen konventio, ja se on se joka useimmiten rikotaan varhaisissa forkeissa.