Pipáld ki, mit várj el
a rendszertől

# PROJEKT-SZABÁLYOK**Standard vibe coding követelményrendszer** > Ezt a fájlt a coding agentnek (és neked) szánjuk. Tedd a projektmappa gyökerébe `RULES.md` néven, és az első promptban kérd meg az agentet, hogy olvassa el teljes egészében, és a fejlesztés végéig tartsa magát hozzá.>> Összeállítva: 2026. 10. 06. · 8 szabály · DarwinAI Vibe Coding Szabály-összeállító (https://darwinai.hu/vibe-coding/szabaly-osszeallito) © 2026 DarwinAI · Budaházy Szabolcs – darwinai.huSaját (és a szervezeted) projektjeihez és oktatási célra szabadon felhasználhatod és átszabhatod. Továbbadáskor, közzétételkor vagy átdolgozott változatnál a forrás megjelölése kötelező: „DarwinAI – darwinai.hu”. ---

## 0. ALAPELV Amikor új szoftverfejlesztési projektet kezdesz, az ebben a dokumentumban szereplő – a projekt gazdája által kiválasztott – elveket, funkciókat és ellenőrzési pontokat **alapértelmezett követelményként kezeld akkor is, ha a konkrét projektleírás külön nem említi őket**. Csak akkor térj el tőlük, ha erre kifejezett utasítást kapsz, vagy az adott projekt jellegéből egyértelműen következik, hogy valamelyik pont nem releváns. Ne csak a konkrétan kért funkciót készítsd el. Gondolkodj a **teljes termékben**: - termék,- UX/UI,- technológia,- üzemeltetés,- biztonság,- mérhetőség,- dokumentáció,- láthatóság,- SEO és AI SEO,- marketing,- sales,- kommunikáció,- skálázhatóság,- későbbi továbbfejleszthetőség. A cél nem egy működő prototípus, hanem egy **publikálható, mérhető, kommunikálható és továbbfejleszthető digitális termék**.

## 1. PROJEKTINDÍTÁS Mielőtt érdemi fejlesztés kezdődik, készíts egy rövid belső projektdefiníciót. Határozd meg: - mi a probléma;- mi a megoldás;- kik a célfelhasználók;- mi az elsődleges use case;- mi a legfontosabb user journey;- mi számít sikeres használatnak;- mi az MVP;- mi kerül későbbi verzióba;- milyen külső API-kra, adatokra vagy szolgáltatásokra van szükség;- milyen technikai és üzleti kockázatok vannak. Készíts egy folyamatosan frissülő **PROJECT CHECKLISTET**, amely tartalmazza mindazokat az elemeket, amelyeket a projekt során létre kell hozni. A checklist ne csak programfunkciókat tartalmazzon, hanem például: - alkalmazás;- landing page;- adminfunkciók;- analytics;- SEO;- social preview;- dokumentáció;- marketinganyagok;- sales anyagok;- screenshotok;- videók;- eDM-ek;- publikálás;- domain;- monitoring;- backup;- launch checklist. A fejlesztés során ezt folyamatosan frissítsd.

## 2. TECHNIKAI ARCHITEKTÚRA Az alkalmazás legyen moduláris. Kerüld a monolitikus, egyetlen fájlba vagy komponensbe zsúfolt megoldásokat. Legyen világos: - frontend;- backend;- API;- database;- service;- component;- configuration;- integration struktúra. A kód legyen más fejlesztő vagy AI coding agent számára is könnyen értelmezhető. Ne over-engineereld a projektet, de ne építs olyan MVP-t sem, amelyet később csak teljes újraírással lehet továbbfejleszteni.

## 3. GITHUB, BUILD ÉS DEPLOYMENT A projekt forráskódjának **GitHub repositoryban** kell lennie. A GitHub legyen a source of truth. Alapértelmezett struktúra: GitHub  → build  → container image  → deployment  → production. Ha Docker image készül, azt lehetőség szerint **GitHub Container Registryben / GHCR-ben** tárold. A Coolify deployment- és orchestration-rétegként működjön, ne elsődleges source/image repositoryként. Legyen elkülöníthető: - development;- staging;- production. A repository ne tartalmazzon: - API kulcsokat;- jelszavakat;- production credentialt;- privát tokent. Ezek environment variable-ként vagy secret store-ban legyenek.

## 4. ERROR HANDLING Ne csak happy path létezzen. Minden fontos folyamatnál legyen: - loading state;- empty state;- success state;- error state;- timeout kezelés;- retry lehetőség;- értelmezhető hibaüzenet. A user ne kapjon nyers stack trace-t vagy értelmezhetetlen API hibát.

## 5. BIZTONSÁG Alapértelmezett biztonsági minimum: - HTTPS;- secret management;- input validation;- output escaping;- megfelelő authorization;- rate limiting ahol szükséges;- biztonságos file upload;- megfelelő CORS;- session/token security;- dependency-frissíthetőség;- minimális jogosultság elve. Soha ne bízz pusztán frontend oldali jogosultságellenőrzésben. Multi-tenant rendszernél backend szinten is biztosítsd az adatok elkülönítését.

## 6. DOKUMENTÁCIÓ Minden projektnél készüljön legalább: **README.md** amely tartalmazza: - projekt célja;- stack;- architecture;- install;- run;- environment variables;- build;- deploy;- repository structure. Ezen kívül legyen dokumentálva: - külső API-k;- database;- fontos business logic;- deployment;- backup;- restore. Egy új fejlesztő vagy AI coding agent képes legyen a dokumentációból folytatni a projektet.

## 7. TESZTELÉS Ne tekints egy funkciót késznek csak azért, mert egyszer működött. Teszteld legalább: - fő user journey;- input validation;- API error;- empty state;- mobil nézet;- desktop nézet. A kritikus business logic kapjon unit/integration tesztet. A legfontosabb end-to-end folyamatokat lehetőség szerint automatizált browser test ellenőrizze. Nem cél a 100%-os tesztlefedettség. A cél a regressziók és kritikus hibák korai felismerése.

## 8. TARTALMI MINŐSÉG Ne használj placeholdert production rendszerben. Ne maradjon: - Lorem ipsum;- „Coming soon” indokolatlanul;- fake testimonial;- fake számadat;- nem működő gomb;- # link;- placeholder kép;- demo user adat. Minden CTA működjön.

## 9. DEFINITION OF DONE A projektet ne tekintsd befejezettnek attól, hogy a fő funkció működik. A projekt akkor kész, ha legalább: - [ ] a core functionality működik- [ ] a repository rendezett- [ ] a staging és a production működik- [ ] az error state-ek működnek- [ ] a loading state-ek működnek- [ ] a biztonsági minimum ellenőrizve- [ ] a README elkészült- [ ] a környezet (environment) dokumentálva van- [ ] az alapvető tesztek lefutnak- [ ] nincs placeholder tartalom- [ ] nincs nem működő CTA

## 10. VÉGSŐ ÖNELLENŐRZÉS A projekt lezárása előtt ne azt kérdezd: > „Megcsináltam-e azt, amit a brief kért?” Hanem ezt: > „Ha ezt a terméket holnap nyilvánosan elindítanánk, mi hiányozna még ahhoz, hogy valódi emberek megtalálják, megértsék, használják, ajánlják, megvegyék, illetve hogy mi mérni, üzemeltetni és továbbfejleszteni tudjuk?” Az így talált hiányosságokat vedd fel a checklistre és – amennyiben nem igényelnek üzleti döntést, fizetős szolgáltatás aktiválását vagy új credentialt – készítsd el automatikusan.

## FŐ MŰKÖDÉSI ELV **Ne várd meg, hogy minden evidens szakmai részletet külön kérjek.** Ha egy professzionális digitális termékhez egy elem logikusan szükséges, jelezd, tervezd meg és lehetőség szerint építsd be. Ugyanakkor: - ne építs értelmetlen funkciókat;- ne növeld öncélúan a komplexitást;- ne aktiválj fizetős szolgáltatást engedély nélkül;- ne hozz üzleti vagy jogi döntést helyettem;- ne publikálj vagy küldj kommunikációt automatikusan engedély nélkül. A cél: **a lehető legkevesebb utólag eszünkbe jutó „ezt még bele kellett volna rakni” típusú hiányosság.**

--- © 2026 DarwinAI · Budaházy Szabolcs – darwinai.huForrás: DarwinAI – darwinai.hu/vibe-coding