\# PROJEKTLEZÁRÁSI ÉS TUDÁSMENTÉSI PROTOKOLL A projekt fejlesztése befejeződött. Tekintsd át a teljes, számodra hozzáférhető projektet, majd készíts olyan önálló projektmemóriát, amelynek birtokában az eredeti munkakönyvtár később biztonságosan törölhető. \## Alapvető cél A lezárás után maradjon meg minden olyan információ, amely szükséges ahhoz, hogy egy későbbi fejlesztő vagy AI: \* megértse, mit és miért készítettünk; \* nulláról újra tudja építeni a projektet; \* folytatni vagy módosítani tudja; \* hasonló projektet tudjon készíteni; \* ne ismételje meg a már feltárt hibákat és zsákutcákat; \* fel tudja használni a jól működő módszereket; \* kevesebb felesleges művelettel és tokennel dolgozzon. \## Fontos biztonsági szabályok 1\. Ne törölj semmilyen projektfájlt. 2\. Ne módosítsd a projekt működő forráskódját, kivéve, ha a dokumentáció helyességének ellenőrzéséhez feltétlenül szükséges. 3\. A lezárási fájlokat a következő könyvtárban hozd létre: `PROJECT\_MEMORY/` 4\. Ne írj valódi jelszavakat, API-kulcsokat, tokeneket, sütiket, személyes adatokat vagy más titkokat a dokumentációba. 5\. Környezeti változóknál csak a változó nevét, célját, formátumát és beszerzési módját dokumentáld. 6\. Ne találj ki hiányzó információt. A bizonytalan vagy nem ellenőrizhető adatokat jelöld egyértelműen. 7\. Minden fontos állításnál jelezd annak forrását, például: \* forráskód; \* konfigurációs fájl; \* Git-előzmény; \* teszteredmény; \* naplófájl; \* dokumentáció; \* következtetés. 8\. A projektet csak akkor minősítsd törölhetőnek, ha a dokumentáció önmagában elegendő a lényegi működés reprodukálásához. \--- \# 1. A projekt feltérképezése Vizsgáld át az összes hozzáférhető információforrást: \* teljes könyvtárstruktúra; \* forráskód; \* konfigurációs fájlok; \* függőségi és lock fájlok; \* build-, lint- és tesztbeállítások; \* adatbázissémák és migrációk; \* API-definíciók; \* dokumentáció; \* példafájlok; \* Git-előzmények, branchek, tagek és fontos commitok; \* issue-k, TODO-k és megjegyzések; \* elérhető naplók és hibajelentések; \* telepítési és üzemeltetési konfigurációk; \* külső szolgáltatások és erőforrások. Ne csak a végső állapotot vizsgáld. A projekt történetéből azonosítsd: \* a fontos döntéseket; \* az irányváltásokat; \* a sikertelen próbálkozásokat; \* a javított hibákat; \* a visszatérő problémákat; \* azokat a megoldásokat, amelyek bizonyítottan működtek. Ha valamelyik információforrás nem érhető el, ezt külön jelezd. \--- \# 2. A projekt állapotának ellenőrzése Amennyiben biztonságosan elvégezhető: 1\. Telepítsd vagy ellenőrizd a függőségeket. 2\. Futtasd a projekt buildjét. 3\. Futtasd a teszteket. 4\. Futtasd a lintelést és a típusellenőrzést. 5\. Ellenőrizd az indítási folyamatot. 6\. Ellenőrizd a fő felhasználási folyamatokat. 7\. Vizsgáld meg, hogy egy üres környezetben reprodukálható-e a projekt. Az ellenőrzés során: \* ne módosíts éles adatokat; \* ne indíts destruktív parancsokat; \* ne telepíts vagy publikálj éles környezetbe; \* lehetőség szerint ideiglenes vagy elkülönített könyvtárat használj. Minden futtatott parancsot és annak eredményét dokumentáld. Ha valamelyik ellenőrzést nem lehet elvégezni, írd le: \* miért nem lehetett; \* milyen kockázatot jelent; \* hogyan lehetne később ellenőrizni. \--- \# 3. `PROJECT\_MEMORY/PROJECT\_REBUILD.md` Készíts részletes, önálló újraépítési kézikönyvet. A dokumentum tartalmazza legalább az alábbi fejezeteket. \## 3.1. Projektazonosítás \* projekt neve; \* rövid, egyértelmű leírás; \* létrehozásának célja; \* megoldott probléma; \* célközönség; \* lezárás dátuma; \* lezáráskori állapot; \* verzió vagy fontos Git-azonosító, ha elérhető. \## 3.2. Funkciók Sorold fel: \* a kész funkciókat; \* a részben kész funkciókat; \* a tervezett, de el nem készült funkciókat; \* a szándékosan elvetett funkciókat; \* a jelenlegi korlátozásokat. Minden fontos funkciónál röviden írd le: \* mit csinál; \* hogyan használható; \* mely komponensek valósítják meg; \* hogyan ellenőrizhető a működése. \## 3.3. Architektúra Dokumentáld: \* a rendszer fő részeit; \* a komponensek felelősségét; \* a köztük lévő adatáramlást; \* a fő belépési pontokat; \* a háttérfolyamatokat; \* a tárolási megoldásokat; \* a külső szolgáltatásokat; \* a fontos technikai döntéseket. Készíts egyszerű Mermaid-diagramot is, ha az segíti a megértést. \## 3.4. Könyvtárstruktúra Mutasd be a lényeges könyvtárakat és fájlokat. Ne másold be szükségtelenül a teljes fájllistát. Azokat a részeket emeld ki, amelyek szükségesek: \* az indításhoz; \* a fejlesztéshez; \* a konfiguráláshoz; \* a teszteléshez; \* a buildhez; \* a telepítéshez; \* az adatok kezeléséhez. \## 3.5. Technológiai környezet Dokumentáld pontosan: \* programozási nyelvek; \* keretrendszerek; \* futtatókörnyezetek; \* csomagkezelők; \* adatbázisok; \* buildeszközök; \* külső szolgáltatások; \* operációs rendszerrel kapcsolatos követelmények; \* szükséges verziók; \* ismert verzióütközések. A verziókat a projekt tényleges fájljaiból állapítsd meg. \## 3.6. Telepítés nulláról Írj sorrendhelyes, másolható lépéseket egy teljesen üres géphez vagy könyvtárhoz: 1\. előfeltételek; 2\. repository vagy fájlok létrehozása; 3\. függőségek telepítése; 4\. környezeti változók beállítása; 5\. külső szolgáltatások konfigurálása; 6\. adatbázis létrehozása vagy migrálása; 7\. build; 8\. indítás; 9\. működés ellenőrzése. Minden parancs legyen pontos és a megfelelő munkakönyvtárból futtatható. \## 3.7. Konfiguráció Minden fontos beállításnál add meg: \* a beállítás nevét; \* helyét; \* célját; \* alapértelmezett értékét; \* lehetséges értékeit; \* módosításának következményeit. Készíts környezetiváltozó-táblázatot, de valódi titkos értékeket ne szerepeltess. \## 3.8. Adatok és külső erőforrások Dokumentáld: \* adatmodellek; \* adatbázisséma; \* migrációk; \* fájlformátumok; \* import- és exportfolyamatok; \* szükséges statikus fájlok; \* modellek, médiafájlok vagy adatkészletek; \* külső API-k; \* licencköteles vagy más módon nem archiválható elemek. Minden külső elemnél írd le: \* mire szolgál; \* honnan szerezhető be; \* milyen verzió szükséges; \* mi történik, ha már nem érhető el; \* van-e helyettesítő megoldás. \## 3.9. Fejlesztési munkafolyamat Írd le: \* hogyan indítható fejlesztői módban; \* hogyan futtathatók a tesztek; \* hogyan készül a build; \* hogyan történik a hibakeresés; \* milyen formázási és kódolási szabályok vannak; \* hogyan kell új funkciót hozzáadni; \* mely fájlokat nem célszerű kézzel módosítani. \## 3.10. Tesztelés és ellenőrzés Sorold fel: \* az automatikus teszteket; \* a manuális ellenőrzéseket; \* a tesztadatokat; \* a jelenleg nem tesztelt részeket; \* az ismert hibákat; \* az elfogadható és nem elfogadható figyelmeztetéseket. Adj egy rövid „gyors egészségügyi ellenőrzés” parancssort is. \## 3.11. Build és telepítés Dokumentáld: \* buildparancsok; \* létrejövő fájlok; \* fejlesztői és éles környezet különbségei; \* deployment lépései; \* visszaállítási lehetőségek; \* hosting- és platformfüggőségek; \* ismert telepítési problémák. \## 3.12. Fontos döntések Készíts döntési naplót az alábbi formában: | Döntés | Miért ezt választottuk? | Alternatívák | Következmény | Jövőbeli felülvizsgálat | | ------ | ----------------------- | ------------ | ------------ | ----------------------- | Csak olyan döntéseket szerepeltess, amelyek bizonyíthatók vagy erősen alátámaszthatók. \## 3.13. Ismert problémák és folytatási pontok Minden nyitott problémánál add meg: \* tünet; \* valószínű ok; \* érintett fájlok; \* eddigi próbálkozások; \* ajánlott következő lépés; \* prioritás; \* kockázat. \## 3.14. Gyors kontextus egy következő AI számára Készíts egy tömör, önmagában használható részt legfeljebb körülbelül 800 szóban. Tartalmazza: \* mi a projekt; \* hogyan működik; \* melyek a kritikus fájlok; \* milyen parancsokat kell használni; \* mik a fő korlátozások; \* hol érdemes folytatni; \* mit nem szabad újra megpróbálni. A rész célja, hogy egy új AI a teljes dokumentum újraolvasása nélkül el tudja kezdeni a munkát. \## 3.15. Törölhetőségi értékelés A dokumentum végén adj egy minősítést: \* `READY\_TO\_DELETE` \* `READY\_WITH\_EXTERNAL\_DEPENDENCIES` \* `NOT\_READY\_TO\_DELETE` Indokold meg a minősítést. Sorolj fel minden olyan elemet, amely nélkül a projekt nem reprodukálható. \--- \# 4. `PROJECT\_MEMORY/LESSONS\_LEARNED.md` Ez ne egyszerű hibalista legyen. Készíts őszinte, bizonyítékokon alapuló projekt-retrospektívet. \## 4.1. Rövid összefoglalás Írd le: \* mi volt az eredeti cél; \* mi készült el; \* miben változott a cél; \* mi lett a projekt legfontosabb eredménye; \* mi volt a legnagyobb nehézség. \## 4.2. Ami jól működött Minden fontos sikeres megoldásnál add meg: \* mit csináltunk; \* miért működött; \* milyen helyzetben használható újra; \* milyen előfeltételei vannak; \* mennyire biztos a következtetés. Különítsd el: \* technikai megoldások; \* munkafolyamatok; \* hibakeresési módszerek; \* kommunikációs vagy promptolási módszerek; \* automatizálható minták. \## 4.3. Követendő utak Készíts „Ezt máskor is alkalmazzuk” listát. Minden pont tartalmazza: \* az ajánlott módszert; \* a használat feltételeit; \* egy rövid példát; \* a várható előnyt; \* az esetleges kockázatot. \## 4.4. Hibák és rossz irányok Ne csak a végső hibákat sorold fel, hanem a felesleges köröket is. Minden esetnél dokumentáld: \* mi történt; \* miért tűnt akkor jó ötletnek; \* miért nem működött; \* mi volt a valódi kiváltó ok; \* mennyi újramunkát okozott; \* milyen korai jelből lehetett volna felismerni; \* mit kell helyette csinálni; \* mikor lehet mégis indokolt ez a megközelítés. Külön jelöld: \* valódi technikai hibák; \* hibás feltételezések; \* hiányos információból eredő hibák; \* rossz sorrendben végzett lépések; \* túl korai optimalizálás; \* szükségtelen újraírás; \* ismételt vagy felesleges fájlolvasás; \* sikertelen eszköz- vagy könyvtárválasztás; \* olyan próbálkozások, amelyeket már egyszer kizártunk. \## 4.5. Zsákutcák és tiltólista Készíts jól kereshető táblázatot: | Kerülendő út | Miért rossz? | Felismerési jel | Helyette ezt használd | Kivétel | | ------------ | ------------ | --------------- | --------------------- | ------- | A tiltólista célja nem az, hogy vak szabályokat hozzon létre, hanem hogy megelőzze ugyanazon hibák automatikus megismétlését. \## 4.6. Mit csinálnánk másképpen? Írd le az ideális projektfolyamatot úgy, mintha a mostani tudással újrakezdenénk. Térj ki ezekre: \* jobb feladatbontás; \* helyes végrehajtási sorrend; \* korábbi ellenőrzési pontok; \* egyszerűbb architektúra; \* jobb tesztstratégia; \* gyorsabb hibakeresés; \* kevesebb kézi lépés; \* megfelelőbb dokumentáció; \* szükséges automatizálások. \## 4.7. Token- és kontextushatékonyság Elemezd, hol használhattunk szükségtelenül sok tokent vagy kontextust. Vizsgáld meg különösen: \* teljes fájlok ismételt beolvasását; \* ugyanazon háttérinformáció többszöri elmagyarázását; \* túl hosszú vagy pontatlan promptokat; \* céltalan kutatást; \* túl széles körű kereséseket; \* szükségtelen újragenerálást; \* teljes fájlok visszaírását kis módosítások helyett; \* ismételt próbálkozásokat új bizonyíték nélkül; \* párhuzamosan fenntartott, már elvetett megoldásokat; \* olyan feladatokat, amelyek egyszerű parancsokkal vagy scripttel automatizálhatók. Minden azonosított problémánál add meg: \* a tokenpazarlás forrását; \* a kiváltó okot; \* az ajánlott javítást; \* a becsült megtakarítást: alacsony, közepes vagy magas; \* az esetleges minőségi kockázatot. Készíts konkrét javaslatokat például: \* rövid projekt-bootstrap használata; \* géppel olvasható manifest; \* fájlútvonalakra és sorszámokra hivatkozás; \* teljes fájl helyett diff használata; \* célzott keresés; \* egyszer ellenőrzött tények rögzítése; \* döntések és elvetett utak nyilvántartása; \* rövid ellenőrzőlisták; \* ismételhető script vagy parancs készítése; \* külön stabil és ideiglenes kontextus fenntartása. \## 4.8. Mikor indokolt nagyobb tokenkeret vagy több kontextus? Írd le azokat a helyzeteket, amikor a túlzott rövidítés káros lenne, például: \* összetett architektúraváltás; \* több komponenst érintő refaktorálás; \* nehezen reprodukálható hiba; \* adatvesztési vagy biztonsági kockázat; \* ismeretlen örökölt rendszer; \* több, egymásnak ellentmondó követelmény; \* kritikus migráció. Minden ilyen helyzetnél add meg: \* milyen plusz kontextus szükséges; \* miért szükséges; \* hogyan lehet a többletkontextust strukturáltan átadni; \* mikor lehet ismét rövidebb kontextusra váltani. \## 4.9. Következő projektre használható szabályok Készíts három listát: \### Mindig csináljuk A bizonyítottan hasznos gyakorlatok. \### Előbb ellenőrizzük Azok a lépések, amelyeket csak bizonyos feltételek mellett érdemes használni. \### Ne csináljuk újra Azok a módszerek, amelyek ebben a projektben bizonyíthatóan rossz vagy felesleges iránynak bizonyultak. \## 4.10. Rövid tapasztalati memória egy következő AI számára A dokumentum végén készíts legfeljebb körülbelül 500 szavas blokkot, amely tartalmazza: \* a legfontosabb bevált módszereket; \* a fő zsákutcákat; \* a kritikus technikai sajátosságokat; \* a legfontosabb hibakeresési tapasztalatokat; \* a tokenhasználat csökkentésének módját; \* azokat az eseteket, amikor több kontextus szükséges. \--- \# 5. `PROJECT\_MEMORY/PROJECT\_MANIFEST.json` Készíts érvényes JSON-fájlt a projekt legfontosabb, stabil tényeivel. Használd legalább a következő szerkezetet: ```json { "project": { "name": "", "description": "", "version": "", "closure\_date": "", "status": "", "rebuild\_readiness": "" }, "technology": { "languages": \[], "frameworks": \[], "runtime\_versions": \[], "package\_managers": \[], "databases": \[], "external\_services": \[] }, "commands": { "install": \[], "develop": \[], "build": \[], "test": \[], "lint": \[], "typecheck": \[], "deploy": \[] }, "critical\_paths": \[], "entry\_points": \[], "environment\_variables": \[ { "name": "", "purpose": "", "required": true, "secret": false } ], "known\_issues": \[], "external\_dependencies": \[], "recommended\_patterns": \[], "avoid\_patterns": \[], "continuation\_points": \[], "verification": { "build": "", "tests": "", "lint": "", "runtime": "" } } ``` Csak ellenőrzött vagy egyértelműen jelölt adatokat írj bele. A JSON ne tartalmazzon megjegyzéseket, titkokat vagy hosszú magyarázatokat. \--- \# 6. Minőség-ellenőrzés A fájlok elkészítése után ellenőrizd: \* minden hivatkozott fájl és könyvtár létezését; \* a parancsok helyességét; \* a verziószámokat; \* a JSON szintaktikai érvényességét; \* a dokumentumok belső ellentmondásait; \* a titkos vagy személyes adatok véletlen bekerülését; \* hogy a dokumentáció nem támaszkodik-e kizárólag a jelenlegi beszélgetésre; \* hogy egy új fejlesztő értené-e a projektet előzetes ismeret nélkül; \* hogy az újraépítéshez szükséges külső erőforrások beszerezhetők-e; \* hogy a projekt törlése után nem veszne-e el pótolhatatlan információ. Ha lehetséges, végezz szimulált újraépítési ellenőrzést egy üres ideiglenes könyvtárban. \--- \# 7. Végső jelentés A munka végén ne csak azt írd, hogy elkészült. Adj tömör jelentést az alábbi formában: \## Létrehozott fájlok Sorold fel a létrehozott fájlokat és azok célját. \## Ellenőrzések Sorold fel: \* sikeres ellenőrzések; \* sikertelen ellenőrzések; \* nem végrehajtható ellenőrzések. \## Fennmaradó kockázatok Sorolj fel minden olyan hiányt vagy külső függőséget, amely akadályozhatja az újraépítést. \## Törölhetőségi állapot A végső állapot pontosan az alábbiak egyike legyen: \* `READY\_TO\_DELETE` \* `READY\_WITH\_EXTERNAL\_DEPENDENCIES` \* `NOT\_READY\_TO\_DELETE` A minősítést röviden indokold meg. \## Következő lépés Írd le, mit kell még emberileg ellenőrizni vagy külön archiválni a projekt tényleges törlése előtt. A projektet semmilyen körülmények között ne töröld automatikusan.