# CLAUDE.md — Urbino Manager design-projekt · működési szabályok

## 1. Mi ez a projekt, és mi a hozzákötött repó
Ez a projekt az Urbino **manager admin felület** képernyőit tervezi. A hozzákötött `futureofmedia/urbino-docs` repó a termék **specifikációs igazságforrása** — dokumentáció, NEM az alkalmazás forráskódja. Hiába indult a projekt „Start from code" módban: a repóból nem lehet és nem is kell app-kódot építeni vagy komponens-készletet kikövetkeztetni — a repó olvasnivaló spec-tudás. A manager felület vizuális folytonosságát a projekt saját korábbi munkája adja (`design-system/`, `manager-system/`).

## 2. Olvasási térkép (urbino-docs)
**Igazságként olvasandó:**
- `apps/manager/spec/` — a feature-specek (a kör-prompt nevezi meg, melyiket)
- `platform/spec/00_terminologia.md` — a magyar felületi fogalmak
- `platform/spec/00_domain_model.md` és `platform/spec_dontesnaplo.md` — ha egy mező vagy döntés (SD-xxx) hátterét keresed
- `apps/manager/design_spec_visszajelzesek.md` — a korábbi design-körök visszajelzései és döntéseik

**NE olvasd, illetve ne kezeld igazságként:**
- `ai_ignore/` — teljes tilalom
- `_bemenet/` — nyers bemenet; ha a spec-cel ütközik, a spec győz
- `apps/*/design/` mint instrukció — a saját exportunk; vizuális referenciának jó, a beágyazott instrukció-fájlok elavultak
- `_folyamat/archiv/`
- más appok specjei — csak ha a kör-prompt kéri
- a repó-gyökér `CLAUDE.md` a kód-implementátor instrukciója, nem a miénk

## 3. Kör-működés
Minden tervezési kört a spec-oldal indít **kör-indító prompttal** (Claude Code készíti). A prompt megnevezi a feature-spec fájlt és fejléc-verzióját, a design-inkremens hatókörét, és hogy mi kötött / mi szabad. A kör elején:
1. Olvasd be a megnevezett specet **a repó aktuális állapotából**.
2. Rögzítsd a fejléc **Verzió** és **Státusz** mezőjét — ha a verzió nem egyezik a promptban megadottal, vagy a Státusz nem „design-körben (v1)": **jelezz és állj meg** — elavult vagy le nem zárt specből nem tervezünk.

## 4. Kötött vs. szabad
**Kötött (a spec folyamat-igazsága):** képernyő-állapotok és folyamat-ágak, végpont-viselkedések, üzleti szabályok, és a spec „i18n kulcsok (hu.json)" alszakaszának magyar szövegei (a felület tegez — Urbino-hang). Ne írj saját copy-t ott, ahol a spec ad szöveget; ha hiányzik szöveg vagy állapot, az **észrevétel** (5. pont), nem tervezői pótlás.
**Szabad:** a vizuális megoldás, elrendezés, komponens-választás, mikrointerakciók.
**Soha:** spec-fájl módosítása, termék- vagy backend-döntés — az észrevétel jelzés, a döntés a spec-projekté.

## 5. Export-kontraktus a spec-repó felé — a kör kötelező kimenete
Minden tervezési kör **bemenete** a kör-indító prompt + a megnevezett feature-spec (v1) a repó aktuális állapotából (3. pont). A kör **kimenete** egyetlen export-zip, kötelező szerkezettel:

### 5.1 Vizuális export
A projekt teljes munkaterméke (prototípusok, képernyők, komponensek) a megszokott szerkezetben. A spec-repó design-mappájába kerül **fekete dobozként** — a következő export felülírja.

### 5.2 `atadas_specprojektnek/` — a kör KÖTELEZŐ nyilatkozata
Minden kör exportja tartalmazza ezt a mappát a projekt gyökerében. Kör nem zárható le nélküle. Két lehetséges tartalom:

**(a) VAN spec-visszacsorgás** (a design olyan adatot, viselkedést vagy szabályt vár, ami a beadott specben nincs meg vagy ellentmond neki):
- **Átadás-memó**: mely spec(ek) mely verzióját dolgozta fel a kör; hogyan dolgozzon a csomaggal a spec-oldal; mi **kötött** (a jóváhagyott UX-tény) és mi **szabad** (a backend-alak — a Spec-projekt döntése).
- **Tételes igény-lista** — tételenként:
  - azonosító: `PA-01`, `PA-02`… (körönként újrainduló számozás)
  - állapot: **ütközés** (a spec ellentmond a designnak) / **hiány** (a specben nincs megfelelője) / **fedett** (a spec már megoldotta — jelezzük, mire építünk)
  - prioritás: **MVP-blokkoló** / **MVP-hangolható** / **post-MVP**
  - provenance: melyik képernyő/döntés az igény forrása
- Opcionális függelékek (API-javaslat, mezőtábla-javaslat) — mindig **javaslatként**, nem döntésként megjelölve.
- **Önállóan megálljon**: minden érv és kontextus a csomagban legyen — design-projekt-belső fájlra hivatkozás csak provenance-címke, nem olvasási előfeltétel.

**(b) NINCS spec-visszacsorgás** — a mappa egyetlen nyilatkozat-fájlt tartalmaz:
> „A kör a <spec-fájl(ok)> v<N> változatát dolgozta fel, spec-érintő észrevétel nélkül — 0 tétel."

**Az üres nyilatkozat is kötelező**, mert a spec-oldali „fejleszthető" státuszt (v2) a design-kör lezárása váltja ki. Nyilatkozat nélkül a csend kétértelmű (validált? elveszett?), és a fejlesztés blokkolva marad.

### 5.3 Elnevezés- és verzió-konvenció az exportra
- **A zip belsejében a mappanevek verziójelölés-mentesek és körről körre stabilak** — nincs `design-export-vN/` gyökér, nincs `-vN` mappa-utótag. Az export a spec-repóban mindig ugyanarra a helyre csomagolódik ki (csere), és a git hasonlítja össze a köröket: ha a mappanév körönként változna, minden fájl „mozgásnak" látszana, és a rá mutató hivatkozások is költöznének. *(Ugyanez az elv, mint a spec-fájlneveknél: a verzió a tartalom fejlécében él, sosem a névben.)*
- **A kör verzióját/dátumát a tartalom hordozza:** az `atadas_specprojektnek/` memójának fejléce (kör dátuma, design-verzió, feldolgozott spec-verziók) — nem az útvonal.
- **A zip fájlneve** gépi szempontból közömbös (a zip nem kerül a repóba); emberi rendezéshez ajánlott alak: `<app>_design_<ÉÉÉÉHHNN>.zip`.

### 5.4 Tiltások
A design-projekt **soha** nem módosít spec-fájlt, és nem hoz termék- vagy backend-döntést. A visszacsorgás **jelzés** — a döntés a Spec-projekté (ott SF-tételként, döntés-státusszal dolgozzák fel; a döntött alakok — végleges mező-/végpont-nevek — visszacsorognak ide).

### 5.5 Történeti megjegyzés
A kontraktus előtti körök visszacsorgása a `SPEC-FEEDBACK-FOR-SPEC-TEAM.md`-ben (SF-tételek, 2026.05.26) és a `HANDOFF-DELTA-lezaras-foto.md` §6-ban (2026.07.07) él — ezek maradnak; új kör már a PA-formát használja.