# Implementációs térkép — Urbino MVP **Dokumentum-típus:** implementáció-tervezési referencia (élő) **Státusz:** v1 — az MVP-scope, a függőségi gráf és a 0. réteg felmérése **Verzió:** v1.0 **Dátum:** 2026.05.19 **Cél olvasó:** senior fejlesztő + Claude Code **Épít:** `00_architektura_v4.md` 6.1, `40_riport_v1.md` 5.1, `60_tartalom_v2.md` 5.1, `90_sitemap_v3.md` 6., `00_domain_model.md` v1.2, `02_globalis_allapotgep.md`, `99_donesnaplo.md`, `20_admin_felulet/10_bejelentes_lista_es_adatlap.md` v1.1 > **Mire való ez a fájl.** Nem feature-spec. Ez a hátralévő specifikációs és > kódolási munka **sorrend-térképe**: mely feature-ök tartoznak a pilotba, mely > feature melyikre épül, és mit kell a fejlesztőkkel tisztázni, mielőtt > bármilyen feature-kód indul. A Claude Code ebből látja, **melyik feature > kódolható már** és melyik vár még egy blokkoló döntésre. > > **Mi NEM ez.** Nem dönti el a blokkoló kérdéseket — azokat rögzíti, és > megmondja, kinek a hatásköre lezárni. Nem ír felül feature-specet és nem hoz > új kanonikus döntést. > > **A névsíkok.** A feature-azonosítók (A1–A12, P1–P7) ennek a dokumentumnak a > belső jelölései; a 0. réteg tételei (Z-1–Z-5) szintén. A `kanonikus_donek.md` > (K-xxx), a `99_donesnaplo.md` (SD-xxx, Ü-xxx) és a domain-modell nyitott > kérdései (NY-xxx) változatlanul a forrásdokumentumaikban élnek — ez a fájl > **hivatkozza** őket. --- ## 0. Olvasási térkép | Szakasz | Tárgy | |---|---| | 1 | Az MVP-scope feature-listája (szerver, admin, polgári adatigény) | | 2 | A függőségi gráf — megosztott alapréteg és feature-feature függőségek | | 3 | A specifikációs és kódolási sorrend | | 4 | A 0. réteg — a feature-kódot blokkoló platform-szintű kérdések | | 5 | Felmerült fejlesztői kérdések (nem blokkoló) | | 6 | Hivatkozott dokumentumok | --- ## 1. Az MVP-scope feature-listája A pilot (első kiadás, T0 = 2026.07.01) feature-ei, a funkcionális dokumentumok pilot-scope szakaszaiból és az első feature-specből gyűjtve. Három rétegre bontva. ### 1.1 Szerver-réteg A szerver nem önálló feature-csomag — az admin- és polgári feature-ök *mind* szerver-oldali végpontot igényelnek. Két logikai része: - **S-A — platform-alapréteg.** Multi-tenancy DB-modell és tenant-resolution, Zitadel auth és `authorization.json` szerepkör-kötés, a Core↔Tenant szinkron (`User`→`TenantUser`, katalógus-provisioning), a közös API-konvenciók és a hibakód-keret. Forrás: `01_kozos_mintak.md`. Ez a 2. szakasz megosztott alaprétegének (L0) szerver-fele. - **S-B — domain-entitások és API-szerződéseik.** A 14 entitás (`00_domain_model.md` v1.2, adatszerkezeti szinten **kész**) feature-specenként kap API-szerződést, validációt, workflow-t. Ezek nem külön szerver-feature-ök — az alábbi admin-feature-ök szerver-fejezetében élnek. ### 1.2 Admin felület — feature-ök | # | Feature | Forrás | Spec-státusz | |---|---|---|---| | **A1** | Bejelentés-lista és -adatlap (triage-sáv, inline-szerkesztés, állapot-csík, belső jegyzetek, tevékenység-napló, "Hasonló bejelentések" doboz-placeholder, hét akció-végpont, `TicketNote` CRUD) | `10_triage_flow_v1.md`, `00_architektura_v4.md` 6.1 | **kész (v1.1)** | | **A2** | Manuális bejelentés-nyitás (`Manual` origin-ű `Ticket` létrehozása) | `00_architektura_v4.md` 6.1, `10_triage_flow_v1.md` | hátravan | | **A3** | Duplikáció-szűrő (a "Hasonló bejelentések" doboz tartalmi feltöltése, deterministic heurisztika, kézi összevonás, `GET /v1/tickets/{id}/similar`) | `20_duplikacio_v1.md` | hátravan | | **A4** | Dashboard (`/fooldal`, vezető-only: négy KPI-kártya + terepi csapat-tábla, KPI-lefúrás szűrt listára) | `40_riport_v1.md` 5.1 | hátravan | | **A5** | Heti PDF-riport (fix sablon, automatikus generálás + e-mail-küldés, `/riportok` archívum) | `40_riport_v1.md` 5.1 | hátravan | | **A6** | Beállítások — kategória-kezelés (kétszintű kategória-fa, `/beallitasok/kategoriak`) | `50_konfig_v2.md`, `00_architektura_v4.md` 6.1 | hátravan | | **A7** | Beállítások — csoport-kezelés (terepi munkacsoportok, `Group` + n-n `TenantUser`-tagság) | `50_konfig_v2.md` | hátravan | | **A8** | Beállítások — felhasználó-kezelés (e-mail meghívó flow, szerepkör-kötés, Zitadel invite) | `50_konfig_v2.md`, Ü-6 | hátravan | | **A9** | Beállítások — tenant-alapadatok (logó, név, kontakt, időzóna, riport-címzett-lista) | `50_konfig_v2.md`, `40_riport_v1.md` 4.5 | hátravan | | **A10** | Tartalom — hír-kezelés (lista + szerkesztő, rich-text mező, push-jelölő, Vázlat/Publikált) | `60_tartalom_v2.md` 5.1 | hátravan | | **A11** | Tartalom — városi programok (lista + szerkesztő, kötelező időpont) | `60_tartalom_v2.md` 5.1 | hátravan | | **A12** | Tartalom — városi információk (rendezett linkgyűjtemény-kezelő) | `60_tartalom_v2.md` 5.1 | hátravan | Keresztmetszeti, nem önálló feature, de pilot-scope: a **mobil-reszponzív működés a triage-folyamatra** (`00_architektura_v4.md` 5.1, Wow #6) — az A1 része, nem külön tétel. ### 1.3 Polgári mobilapp — adatigény A polgári app UX-e adott (Flutter). A specifikáció **kizárólag az adatigényt** rögzíti — mely API-kat hívja, mit küld és mit kap. UX-tervezés nincs. | # | Feature | Forrás | |---|---|---| | **P1** | Új bejelentés beküldése (GPS + kategória + fotó + leírás → `Ticket` létrehozás, `CitizenApp` origin) | `screen_uj_bejelentes_*` | | **P2** | Saját bejelentések listája és adatlapja (olvasás, polgári badge-leképezés, dedikált polgári végpont) | `screen_bejelentes_lista`, `screen_bejelentes_adatlap_*`, NY-bej-1 | | **P3** | Hírek olvasása (publikált `News`) | `screen_hirek_lista`, `60_tartalom_v2.md` | | **P4** | Városi programok olvasása (publikált `Event`) | `60_tartalom_v2.md` | | **P5** | Városi információk olvasása (publikált `CityInfo`) | `screen_varosi_informaciok_lista`, `60_tartalom_v2.md` | | **P6** | Státusz-push fogadása (a manager státuszváltása → push a polgárnak) | `screen_ertesitesek`, `10_triage_flow_v1.md` 5.2 | | **P7** | Tenant-választás / city-lista (`GET /cities`) | `01_project_instructions.md` tenant-felismerés | ### 1.4 Scope-tisztázások - **Az ötletláda és a közvélemény-szavazás kimarad a pilotból.** A `VarosApp_Projekt_Brief.md` ezeket MVP-funkcióként sorolja (F07, F08), és van rájuk Flutter-képernyő, **de** a `90_sitemap_v3.md` 6. és a `manager_felulet_atadas.md` az ötletláda-kezelőt és a közvélemény-kérdés- szerkesztőt explicit elhalasztja (6–12., illetve 12–18. hó). A funkcionális réteg az autoritatívabb (a brief az Ü-2 szerint elavult). **Döntés (alapító, 2026.05.19):** az ötletláda és a szavazás MVP után jön; a pilotban a polgári app legföljebb gyűjt, manager-oldali kezelő nélkül. *Bevezetendő a `99_donesnaplo.md`-be pilot-scope-bejegyzésként.* - **A push nem önálló feature.** A `01_kozos_mintak.md` 7.4 szerint a pilot event-driven *gondolkodású*, de nem event-driven *infrastruktúrájú* — a státuszváltás `AfterSaveAsync`-je közvetlenül indít notification-t. A push trigger az A1 (és az A10 hír-push) szerver-oldali mellékhatása; a P6 a polgári fogadó-oldal adatigénye. - **GYIK.** A polgári app olvas GYIK-et, de manager-feature nincs hozzá: a K-039 szerint Urbino-admin hatáskör, pilotra egyszeri feltöltéssel. --- ## 2. A függőségi gráf ### 2.1 A megosztott alapréteg (L0) Az L0 az a réteg, amire kivétel nélkül minden A- és P-feature épül. Négy eleme **nem egyenrangú**: kettő kész, kettő blokkoló nyitott kérdés. | L0-elem | Tartalom | Státusz | |---|---|---| | **L0-a** | Domain-modell — 14 entitás, mezők, típusok, kapcsolatok | `00_domain_model.md` v1.2 — **kész** | | **L0-b** | `Ticket` állapotgép — öt állapot, formális átmenet-tábla | `02_globalis_allapotgep.md` — **kész** (NY-Á1–Á3, lásd 4.2) | | **L0-c** | Multi-tenancy + tenant-resolution + auth + Core↔Tenant szinkron | SD-1 **deklarált, fejlesztői megerősítés nyitott** — lásd Z-1 | | **L0-d** | Jogosultsági keret — négy szerepkör → `authorization.json` | `05_jogosultsagok_v2.md` kész; SD-7 névmegerősítés nyitott (FK-2) | A kulcs: **L0-a és L0-b kész** — a feature-specek építhetnek rájuk. **L0-c blokkoló** — amíg a multi-tenancy modell fejlesztőileg nincs megerősítve, *kód* nem indulhat egyetlen tenant-adatot kezelő feature-en sem. *Spec* írható, a "TBD — multi-tenancy modell" jelöléssel (lásd `01_project_instructions.md`). ### 2.2 Feature-feature függőségek A jelölés: **A → B** azt jelenti, *A-nak szüksége van B-re*, tehát B előbb kell. A függőség típusa: `[E]` entitás-, `[API]` API-szerződés-, `[L]` lookup-szintű. **Beállítás-ág:** - `A6 (kategória)` → minden kategóriát használó feature: `A1`, `A2`, `A3`, `P1`. `[L]` kategória-lookup. Ezért A6 korai elem. - `A7 (csoport)` ← `A6` nem előfeltétele, de A7 a bejelentés-ág inputja: `A1`, `A2` → `A7`, mert a felelős-kiosztás `[E]` `assignedGroupId`-t igényel. - `A8 (felhasználó)` ugyanígy: `A1`, `A2` → `A8`, `[E]` `assignedUserId` (`TenantUser`). - `A9 (tenant-alapadat)` → `A5`, `[E]` a riport-címzett-listát A9 adja. Egyébként önálló, bármivel párhuzamosítható. **Bejelentés-ág:** - `A1` → `A2+P1`, `A3`, `P2` — az A1-ben véglegesített állapotmodell, a doboz-placeholder és a `TicketNote` a többi bejelentés-feature alapja. - `A2+P1` **közös `Ticket`-create szerződés**, két `origin`-nal (`Manual` / `CitizenApp`). Egy spec, két belépési pont. `[E][API]`. - `A2+P1` → `A3` — a duplikáció a create-úton létrejött ticketeket szűri, `[E]` `originalTicketId`. - `A1` → `A4` → `A5` — a Dashboard és a riport ugyanarra a `Ticket`- aggregátumra épül (`status`, `assignedAt`, `resolvedAt`). `[API]`. - `A1` → `P2`, `P6` — a polgári saját-lista az A1 status-modelljére és a polgári badge-leképezésre épül; a státusz-push az A1 akció-végpontjainak `AfterSaveAsync`-mellékhatása. **Tartalom-ág (a bejelentés-ágtól teljesen független):** - `A10 (hír)` → `A11 (program)` → `A12 (városi infó)` — laza sorrend, közös `ContentStatus`-váz; nincs közös entitás a `Ticket`-tel. - `A10/A11/A12` → `P3/P4/P5` — a polgári tartalom-olvasás a manager-oldalon publikált `News`/`Event`/`CityInfo` rekordokból olvas. `[E][API]`. ### 2.3 Párhuzamosítható ágak A gráf két, egymástól független ágat mutat — ezeken külön spec-szál és külön fejlesztő haladhat egyszerre: | Ág | Feature-ök | Mitől független | |---|---|---| | Bejelentés-ág | A1 → A2/A3/A4 → A5 + P1/P2/P6 | A `Ticket` és kísérői köré szerveződik | | Tartalom-ág | A10 → A11 → A12 + P3/P4/P5 | Saját entitások, nincs `Ticket`-érintkezés | | Beállítás-ág | A6, A7, A8, A9 | A6/A7/A8 a bejelentés-ág előfeltétele; A9 önálló | A beállítás-ág a bejelentés-ág **előfeltétele**, ezért nem párhuzamos vele, hanem előtte van. A9 viszont párhuzamosítható bármivel. A tartalom-ág bármely ponton indítható, akár a legelején, ha van rá külön kapacitás. --- ## 3. Specifikációs és kódolási sorrend ### 3.1 Specifikációs sorrend (a hátralévő feature-specek) 1. **A6** — kategória-kezelés. Sok feature lookup-függősége; rövid feature. 2. **A7** + **A8** — csoport- és felhasználó-kezelés. Az A1 felelős- kiosztásának előfeltételei. (A8 belső kérdése a Zitadel invite flow — lásd Z-5; spec-szinten haladhat.) 3. **A2 + P1** — manuális és polgári bejelentés-nyitás, közös `Ticket`-create szerződés, egy spec, két belépési pont. *A P1-fél Z-2-re vár.* 4. **A3** — duplikáció-szűrő. 5. **P2** — polgári saját-bejelentés-lista. *Z-2-re vár.* 6. **A4** — Dashboard, majd **A5** + **A9** — heti riport és tenant-alapadatok. 7. **A10 → A11 → A12** + **P3/P4/P5** — tartalom. Bármikor indítható párhuzamosan az 1–6-tal. 8. **P6** — státusz-push. *Z-4-re vár (OneSignal-integráció).* A polgári ág specjei (P1 create-fele, P2, P6, P7) **a spec szintjén is** Z-2-re várnak: polgári entitás-modell nélkül nincs mit specifikálni. ### 3.2 Kódolási sorrend A kódolási sorrend megegyezik a specifikációs sorrenddel, **de a kódkezdés küszöbe feature-enként:** > **Kódkezdés egy feature-en = Z-1 lezárva + az adott feature-spec kész + a > feature gráf-előfeltételei (2.2) kódolva.** Következmények: - Az **A1 az egyetlen feature, aminek a spec-je kész** — így az lesz az első kódolható feature, abban a pillanatban, amikor Z-1 lezárul ÉS A6/A7/A8 elkészül (a felelős-kiosztáshoz). Praktikusan: **Z-1 lezárása + a beállítás-ág első három spec-je** az a küszöb, ahol az éles kódolás megindul. - A **tartalom-ág kódja** Z-1 után, A10 spec-jétől indulhat — nincs más előfeltétele. - A **polgári ág kódja** Z-1 **és** Z-2 együttes lezárása után. --- ## 4. A 0. réteg — a feature-kódot blokkoló platform-szintű kérdések A 0. réteg szigorú definíciója: **csak az kerül ide, ami a rá épülő *kódot* blokkolja.** Egy nyitott kérdés, ami egy feature-en belül megtartott hiányként kezelhető, nem 0. réteg. ### 4.1 A két valódi blokkoló #### Z-1 — Multi-tenancy modell megerősítése - **A kérdés.** Az SD-1 deklarálta a kétszintű, fizikailag elkülönített modellt (Core DB + tenantonkénti Tenant DB, tenant-azonosítás a `Tenant` HTTP headerből), és ezzel **felülírja** a `project_backend` CLAUDE.md jelenlegi modelljét (egyetlen `urbino_core` DB, "there are no tenant subdomains"). Az SD-1 maga rögzít egy teendőt: a `project_backend` CLAUDE.md frissítendő, visszajelzés a kódbázis gazdájának. Amíg ez nem zárul le, a modell deklarált, de nem megerősített. - **Mit blokkol.** Lényegében minden tenant-adatot kezelő feature kódját (A1–A12 szerver-fele, P1–P7). Spec írható "TBD — multi-tenancy" jelöléssel; kód nem. - **Mire kell konkrét válasz.** (a) A kétszintű DB-modell megerősítése vagy elvetése. (b) A Core↔Tenant szinkron konkrét mintája (FK-3 — outbox / közvetlen propagálás / reconciliation-job). (c) A `project_backend` CLAUDE.md tényleges frissítése, hogy a Claude Code ne az elavult modellből dolgozzon. - **Kinek a hatásköre.** A `project_backend` kódbázis gazdája (senior fejlesztő) — architekturális döntés, nem termékdöntés. - **Forrás.** `99_donesnaplo.md` SD-1, SD-3; `01_kozos_mintak.md` 1.2; `20_admin_felulet/10_bejelentes_lista_es_adatlap.md` 8.3 feltételezés 1. #### Z-2 — Polgári identitás- és auth-modell - **A kérdés.** A `00_domain_model.md` az NY-2-ben nyitva hagyta: a `Ticket.reporterId` a polgári felhasználóra mutat, de annak entitása nincs modellezve. Az 5.1 entitás-térkép explicit kimondja, hogy a `reporter`- kapcsolatot a diagram nem rajzolja. A polgári auth, a polgári felhasználó tenant-oldali entitása és a polgár több-város-kontextusa eldöntetlen. - **Mit blokkol.** A teljes polgári ágat — P1, P2, P6, P7. **Nem blokkolja** a bejelentés-ág admin-felét: A1, A3, A4, A5 és az A2 *manuális* része a `reporterId` célentitása nélkül is halad — a `Ticket`-nek van `reporterId` mezeje, csak a célentitás hiányzik. - **Mire kell konkrét válasz.** (a) Van-e külön polgári felhasználó-entitás a Tenant DB-ben, vagy a `reporterId` másra mutat. (b) A polgári auth mechanizmusa. (c) A polgár több-város-kontextusa (`GET /cities`). - **Kinek a hatásköre.** Nem tisztán fejlesztői: a polgári adatigény-spec maga még nincs megírva, és a polgári auth-modellnek termék-/funkcionális vonzata is van. A helyes út: **a polgári adatigény-spec elkészítése** — addig a polgári ág kódja **és specje is** áll. A fejlesztők az auth-technológiát eldöntik, de az entitás-modell spec-kérdés. - **Forrás.** `00_domain_model.md` NY-2, 5.1; `20_admin_felulet/10_bejelentes_lista_es_adatlap.md` NY-bej-1; `01_project_instructions.md` tenant-felismerés; Ü-1. ### 4.2 Három feltételesen blokkoló tétel Ezek megtartott hiányként kezelhetők — a feature halad, a hiány rögzítve —, de egy-egy konkrét feature *gerincét* érinthetik, ezért nyomon követendők. | # | Tétel | Mit blokkol | Kezelés | |---|---|---|---| | **Z-3** | Az `02_globalis_allapotgep.md` három állapotgép-szintű nyitott kérdése (NY-Á1, NY-Á2, NY-Á3) | Vélhetően semmit | NY-Á3 (tömeges státuszváltás) a pilotra **lezárt** — bulk-művelet elhalasztva. NY-Á2 (összevonás-visszavonás) az A1 8.2 szerint nem-pilot. NY-Á1 gyors átnézéssel zárható. Nem a fejlesztők elé tartozik. | | **Z-4** | Az OneSignal-integráció részletei (push-trigger helye, payload, deep link) | Csak P6 kódját | Nem blokkolja A1-et/A10-et: azok "a push-trigger ponton ér véget a felelősségünk" megtartott hiánnyal haladnak. P6 gerince *maga* a push — ott dől el, a P6-spec menetében, fejlesztővel. | | **Z-5** | A Zitadel invite flow — a meghívott, még nem aktivált `User` és a Zitadel-identitás kötése (NY-5) | Csak A8 gerincét | Nem 0. réteg, hanem az A8 feature-spec belső kérdése; a `02_architekturalis_kerdeslista.md` 9. szerint Zitadel invite flow. A8 megírásakor az első tisztázandó pont. | ### 4.3 Összefoglaló — a 0. réteg | # | Tétel | Mit blokkol | Kinek a hatásköre | Súly | |---|---|---|---|---| | **Z-1** | Multi-tenancy modell megerősítése (SD-1) | Minden feature **kódját** | `project_backend` gazdája (fejlesztő) | valódi blokkoló | | **Z-2** | Polgári identitás-/auth-modell (NY-2) | A polgári ág (P1, P2, P6, P7) spec-jét és kódját | Polgári adatigény-spec (funkcionális) + fejlesztő az auth-technológiára | valódi blokkoló | | **Z-3** | Állapotgép NY-Á1–Á3 | Vélhetően semmit | Specifikáció — gyors átnézéssel zárható | feltételes | | **Z-4** | OneSignal-integráció részletei | Csak P6 kódját | Fejlesztő, a P6-spec menetében | feltételes | | **Z-5** | Zitadel invite flow (NY-5) | Csak A8 gerincét | A8 feature-spec, fejlesztőkkel | feltételes | ### 4.4 A három kérdés — összefoglalva - **(a) Mit kell a fejlesztőkkel tisztázni azonnal.** Egyetlen valódi azonnali tétel: **Z-1, a multi-tenancy modell** — az első specifikációs ülés első napirendi pontja. A **Z-2** szintén sürgős, de annak útja nem fejlesztői egyeztetés, hanem a polgári adatigény-spec elkészítése. Z-3 egy gyors átnézéssel most lezárható. Z-4 és Z-5 ráér a P6, illetve A8 megírásáig. - **(b) Milyen sorrendben készüljenek a feature-specek.** A6 → A7+A8 → A2+P1 → A3 → P2 → A4 → A5+A9 → P6; a tartalom-ág (A10→A11→A12 + P3/P4/P5) párhuzamosan, bármikor. - **(c) Mikortól indulhat a kódolás.** Feature-enként: Z-1 lezárva + az adott feature-spec kész + a gráf-előfeltételek kódolva. Az **első kódolható feature az A1**, amint Z-1 lezárul és A6/A7/A8 elkészül. A tartalom-ág kódja Z-1 után, A10-től. A polgári ág kódja Z-1 és Z-2 együttes lezárása után. --- ## 5. Felmerült fejlesztői kérdések (nem blokkoló) A scope-felmérés közben felszínre került, még megválaszolatlan kérdések. Ezek **nem** 0. réteg — a feature-specek menetében eldőlnek, vagy üzemeltetési hatáskörbe tartoznak. A `99_donesnaplo.md` "dönts a feature-spec menetében" elve szerint kezelendők. | # | Kérdés | Kinek | Státusz | |---|---|---|---| | **FK-1** | A hír/program tartalom-mezője rich-text szerkesztő vagy sima többsoros fallback (`60_tartalom_v2.md` 3.6, NY-6) | Fejlesztő (komponens-becslés) | **Nyitva** — az A10/A11 tartalom-feature-spec menetében dől el; addig megtartott hiány | | **FK-2** | A `manager` szerepkör-név megfelelő-e (SD-7) | Fejlesztő | Nyitva — egy soros csere, ha mást preferálnak; A8 előtt jó lezárni | | **FK-3** | A Core→Tenant szinkron konkrét mintája (SD-3) | Fejlesztő | Nyitva — A8 előtt eldöntendő; Z-1 része | | **FK-4** | A `TenantUser.roles` tárolási formája (NY-4) | Fejlesztő | Nem blokkol — az FK-3-mal együtt zárul | | **FK-5** | A push-szolgáltató | Fejlesztő + alapító | **Lezárva (2026.05.19): OneSignal** (APNs+FCM fölött). *Bevezetendő a `99_donesnaplo.md`-be új SD-ként.* | | **FK-6** | Az időpont-megjelenítés konverziójának helye, tenant- vagy eszköz-szinten (SD-10) | Fejlesztő | **Lezárva (2026.05.19): tenant-szinten**, a tervezett nemzetközi terjeszkedés miatt. *Az SD-10 nyitott pontja ezzel zárt.* | | **FK-7** | Az application-logging stratégia — Serilog vs. built-in, hová gyűlik (SD-13 nyitott pontja) | Üzemeltetés / DevOps | Nem blokkol feature-kódot; csak a teljesség kedvéért | --- ## 6. Hivatkozott dokumentumok - `00_architektura_v4.md` — pilot-scope (6.1), szerepkörök, navigáció - `00_domain_model.md` v1.2 — a 14 entitás, NY-2, NY-4, NY-5, NY-6, NY-7 - `01_kozos_mintak.md` — multi-tenancy, tenant-resolution, API-konvenciók, event-driven elhatárolás (7.4) - `02_globalis_allapotgep.md` — a `Ticket` állapotgépe, NY-Á1–Á3 - `10_triage_flow_v1.md` — triage, státusz-modell, elutasítás - `20_duplikacio_v1.md` — duplikáció-szűrés - `40_riport_v1.md` — Dashboard és heti riport, pilot-scope (5.1), riport- címzettek (4.5) - `50_konfig_v2.md` — Beállítások (kategória, csoport, felhasználó, tenant-adat) - `60_tartalom_v2.md` — tartalomkezelés, pilot-scope (5.1), rich-text kérdés (3.6) - `90_sitemap_v3.md` — modul-sitemap, elhalasztott nézetek (6.) - `20_admin_felulet/10_bejelentes_lista_es_adatlap.md` v1.1 — az első feature-spec, NY-bej-1, 8.3 feltételezések - `99_donesnaplo.md` — SD-1, SD-3, SD-7, SD-10, SD-13, Ü-1, Ü-2, Ü-6 - `kanonikus_donek.md` — K-016, K-039 - `VarosApp_Projekt_Brief.md` — a polgári app eredeti (Ü-2 szerint elavult) feature-listája --- ## Verziónapló - **v1.0 (2026.05.19)** — Első kiadás. Az MVP-scope feature-listája (12 admin-, 7 polgári adatigény-feature, az ötletláda/szavazás elhalasztva); a függőségi gráf (megosztott alapréteg L0, feature-feature függőségek, három párhuzamosítható ág); a specifikációs és kódolási sorrend; a 0. réteg (Z-1 — Z-5, két valódi és három feltételes blokkoló); hét felmerült fejlesztői kérdés (FK-1 — FK-7, ebből FK-5 és FK-6 lezárva).