# Terminológiai jegyzék — Urbino Specifikációs projekt

**Dokumentum-típus:** terminológiai referencia
**Státusz:** munkadokumentum — átnézésre kész
**Verzió:** v0.5
**Dátum:** 2026.05.20
**Cél olvasó:** senior fejlesztő + Claude Code
**Épít:** `kanonikus_donek.md`, `80_modulok/manager_felulet/` funkcionális
dokumentumok, `01_kozos_mintak.md`, a két `CLAUDE.md`

> **Mire való ez a fájl.** Egységes szókincs az egész Specifikációs projektnek.
> Minden fogalom **magyarul és angolul** — mert a felületi szöveg magyar
> (`hu.json`), az entitás- és kódnevek viszont angolul lesznek (PascalCase az
> entitásoknak/típusoknak, camelCase a mezőknek/JSON-nak). A `00_domain_model.md`
> és minden feature-spec **ezt a jegyzéket** használja; ha egy fogalomra
> többféle szó merül fel, itt egységesítünk, nem a feature-specben.
>
> **Három névsík.** Minden domain-objektumnak akár három neve is van, és ezt
> tudatosan kezeljük:
> - **Felületi terminus (magyar)** — amit a felhasználó lát az admin felületen
>   és a polgári appban. Ez a `hu.json`-ba kerül.
> - **Köznyelvi szinonima (magyar)** — amit a beszélgetésben és a funkcionális
>   dokumentumokban használunk; nem feltétlenül azonos a felületi terminussal.
> - **Kódbeli név (angol)** — az entitás/mező neve a szerveren és az API-ban.
>
> **A jegyzék nem hoz új terméktani döntést.** A fogalmakat a kanonikus
> állítások és a funkcionális dokumentumok már definiálták; ez a fájl
> **összevonja és egységesíti** őket. Ahol a forrásanyagok ingadoztak, azt a
> "Tisztázott ingadozások" szakasz (lásd lent) külön jelzi.

---

## 0. A legfontosabb tisztázás — "bejelentés", "ügy", "ticket"

Ez a projekt központi objektuma, és a forrásanyagok **háromféle szót**
használnak rá. A tisztázás:

> **A "bejelentés", az "ügy" és a "ticket" UGYANARRA AZ EGY objektumra
> vonatkozik. Nem három fogalom — egy fogalom, három névsíkon.**

| Névsík | Szó | Hol használjuk |
|---|---|---|
| Felületi terminus (magyar) | **bejelentés** | Az admin felületen, a polgári appban, minden polgárinak látható szövegben — K-028 |
| Köznyelvi szinonima (magyar) | **ügy** | A funkcionális dokumentumokban és a beszélgetésben váltogatva ("lezárt ügyek", "az ügy elindult") — **stilisztikai szinonima, nem külön fogalom** |
| Kódbeli név (angol) | **`Ticket`** | A szerveren az entitás neve, az API-ban (`/v1/tickets`), a fejlesztői dokumentumokban — K-005, K-028 |

**Miért nem külön fogalom az "ügy".** A `10_triage_flow` és a koncepció
szóhasználata — *"itt dől el, hogy egy ticket »ügy« lesz vagy »zaj«"* —
**retorikai**, nem definíciós. A stratégiai dokumentum az "ügy"-et végig az
objektum köznyelvi neveként használja ("hány ügyet zártatok le", "kíséri az
ügyet"). Tehát: az `Elutasítva` állapotú `Ticket` **is** "ügy" — csak elutasított
ügy. A triage nem *teremt* ügyet; a triage egy meglévő `Ticket`-et minősít és
mozdít tovább az állapotgépben.

**Következmény a specifikációra:**
- A felületi szövegekben (`hu.json`) **"bejelentés"** áll — soha nem "ügy" és
  soha nem "ticket". A `10_triage_flow` "ügy" szóhasználata a felületi
  szövegekbe **nem** kerül át.
- A kódban, az API-ban, a `00_domain_model.md`-ben az entitás neve **`Ticket`**.
- A specifikációs prózában az "ügy" mint köznyelvi szinonima **megengedett**
  (a funkcionális dokumentumokkal való folytonosság miatt), de tudni kell:
  ugyanaz, mint a `Ticket`.

---

## 1. A három fő rendszerelem

A projekt-instrukció kötelező névhasználata. Ezek nem domain-fogalmak, hanem a
rendszer részei — a teljesség kedvéért itt is.

| Magyar (kötelező) | Angol / kód | Definíció | Tiltott megnevezés |
|---|---|---|---|
| **szerver** | (the server / API) | A .NET / ASP.NET Core API. Tárolja az adatot, kiszolgálja az API-kat | ~~backend~~ |
| **admin felület** | (the admin UI) | Az Angular SPA, amit a városgazdálkodási szerepkörök használnak böngészőben | ~~frontend~~, ~~manager felület~~* |
| **polgári mobilapp** | (the citizen app) | A Flutter alkalmazás (iOS + Android) | — |
| **terepi mobilapp** | (the field app) | A városgazdálkodási terepi dolgozók natív appja — **a specifikáció hatókörén kívül** | — |

`*` A funkcionális tervezés az admin felületet **"manager felület"** néven
tervezte. A két név **ugyanaz a dolog**; a specifikációban az **"admin
felület"** a használandó. Ahol a jegyzék vagy egy spec funkcionális
dokumentumra hivatkozik, a "manager felület" előfordulhat a forrás
megnevezéseként — de a specifikáció saját szövege "admin felület"-et ír.

---

## 2. A bejelentés és életciklusa

### 2.1 Az objektum és attribútumai

| Magyar (felületi) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **bejelentés** | `Ticket` | A városgazdálkodási probléma-objektum: a polgár vagy a diszpécser által rögzített, kategorizált, helyhez kötött, követhető ügy. A projekt központi entitása | K-005, K-028 |
| **bejelentő** | `reporter` | Az a polgár, aki a bejelentést létrehozta. Egy bejelentésnek egy bejelentője van; összevonáskor a duplikátum bejelentője az eredeti ügy értesítendői közé kerül (K-034) | K-034, `20` 4.4 |
| **cím** | `title` | A bejelentés rövid, megnevező szövege (pl. "Kátyú a Petőfi utcán") | `10` 3.2 |
| **leírás** | `description` | A polgár (vagy a diszpécser) adta bővebb szöveg a problémáról | `10` 3.2 |
| **helyszín** | `location` | A bejelentés földrajzi helye — GPS-koordináta és/vagy szöveges cím (utcanév). A polgári app-ból érkező bejelentés mindig tartalmaz koordinátát; a manuálisan nyitott esetleg csak utcanevet | `20` 2.4 |
| **fotó** | `photo` / `Attachment` | A bejelentéshez csatolt kép(ek). A polgári flow legalább egy fotót kér; a lezárás-dokumentáció is fotót tartalmazhat | Flutter `screen_uj_bejelentes_2` |
| **belső jegyzet** | `internalNote` | A diszpécser/vezető által írt, a polgárnak **nem** látható megjegyzés. A terepi dolgozó olvassa, de nem írja | `05_jogosultsagok` 6.1 |
| **tevékenység-napló** | `ActivityLog` | A bejelentés életciklus-eseményeinek append-only naplója (státuszváltás, felelős-váltás, elutasítás, visszanyitás, összevonás). Külön entitás, nem az `AuditableEntity` (J-2) | `01_kozos_mintak` 7.2 |

> **Megjegyzés a "ticket" belső használatáról.** A `Ticket` az entitás kódneve.
> A bejelentéshez kapcsolódó mezők kódnevei (`reporter`, `title`,
> `description`…) **javaslatok** — a `00_domain_model.md` véglegesíti őket
> típussal, mérettel együtt. A jegyzék itt a fogalmat rögzíti, nem a végleges
> sémát.

### 2.2 Állapotok (a státusz-modell)

A bejelentés öt állapota (K-029). A státusz **a munka állapotát** írja le, nem
az adminisztrátorét. Az állapot-átmenetek formális táblája a
`02_globalis_allapotgep.md`-be kerül; itt a **fogalmak és a nevek** rögzülnek.

| Magyar (felületi) | Angol / kód | Definíció |
|---|---|---|
| **státusz** / **állapot** | `status` | A bejelentés életciklus-állapota. A két magyar szó szinonima; a felületi terminus a **"státusz"** (a polgári app "státusz követés" szekciója nyomán) |
| **Új** | `New` | Beérkezett, triage még nem történt |
| **Kiosztva** | `Assigned` | Triage kész, felelőshöz rendelve, terepi munka még nem indult |
| **Folyamatban** | `InProgress` | A terepi munka elkezdődött |
| **Lezárt** | `Resolved` | A munka elkészült, dokumentálva — végállapot |
| **Elutasítva** | `Rejected` | Nem valós ügy, nem hatáskör, vagy duplikáció — végállapot, mellékág |

> **Az angol állapotnevekről.** Ezek **javaslatok** a kódbeli `enum`-hoz. A
> `New / Assigned / InProgress / Resolved / Rejected` készletet a `Ticket`-spec
> / a `02_globalis_allapotgep.md` erősíti meg. Megfontolandó alternatíva volt
> a `Closed` a `Resolved` helyett — de a `Resolved` pontosabb, mert a "lezárt"
> a *megoldottságot* jelenti, és a polgári badge is "Megoldott" (lásd 2.4). A
> `Rejected` és a `Resolved` is végállapot, de elkülönül: a `Resolved` a fő
> ág vége, a `Rejected` a mellékágé.
>
> **Fontos, hogy ne keveredjen:** az `Elutasítva`/`Rejected` **nem** egyenlő a
> "Duplikáció"-val. A duplikátum *egy fajta* elutasított bejelentés — az
> `Elutasítva` állapotba kerül "Duplikáció" indoklással (K-034). A
> "Duplikáció" tehát **elutasítási indok**, nem önálló állapot.

### 2.3 Állapot-átmenetek és a triage

| Magyar | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **triage** | `triage` | A diszpécseri folyamat, amely az `Új` bejelentést `Kiosztva` állapotba mozdítja: kategorizálás, prioritás, határidő, felelős. **Nem önálló állapot** — maga az `Új → Kiosztva` átmenet | K-029, K-031 |
| **a triage négy döntése** | — | Kategória, prioritás, határidő, felelős — a triage szándékosan négymezős (K-031) | K-031 |
| **kiosztás** | `assignment` | A felelős hozzárendelése a bejelentéshez. A "Triage kész — Kiosztás" gomb váltja ki, és ez véglegesíti az `Új → Kiosztva` átmenetet (Ü-3) | `10` 3.4, Ü-3 |
| **elutasítás** | `rejection` | A bejelentés `Elutasítva` állapotba mozdítása. Kötelező indoklással jár, és **nem törlés** — az `Elutasítva` látható, naplózott végállapot | K-030 |
| **elutasítási indok** | `rejectionReason` | Az elutasítás kötelező indoklása — előre definiált ok (pl. "Nem hatáskör", "Nem valós", "Duplikáció", "Magánterület") vagy szabad szöveg | K-030, `10` 5.3 |
| **korrekciós visszanyitás** | `reopen` | A `Lezárt → Folyamatban` átmenet — ha a lezárás téves volt. Csak diszpécser/vezető, kötelező indoklással | `10` 4.5 |
| **felelős-váltás** | `reassignment` | A felelős megváltoztatása egy már kiosztott bejelentésen. **Nem státuszváltás** — az állapot változatlan, csak a felelős mező | `10` 4.4 |
| **lezárás-dokumentáció** | `resolutionNote` / `Attachment` | A `Folyamatban → Lezárt` átmenethez kötelező dokumentáció — legalább egy "elvégzett munka" fotó vagy szöveges megjegyzés | `10` 4.2 |

### 2.4 A polgári oldali státusz-megjelenítés — jelzés, nem véglegesítés

A polgári mobilapp **kevesebb** állapotot mutat, mint az admin felület öt
állapota. A `10_triage_flow` 2.3 javaslata szerinti leképezés (a polgári
badge-ek a Flutter képernyőkről):

| Admin-állapot | Polgári badge (javaslat) |
|---|---|
| `New` / Új | "Beérkezett" *(javaslat)* |
| `Assigned` / Kiosztva | "Jóváhagyva" |
| `InProgress` / Folyamatban | "Folyamatban" |
| `Resolved` / Lezárt | "Megoldott" |
| `Rejected` / Elutasítva | külön kezelendő *(átadva a polgári modulnak)* |

> **Ez nem a terminológiai jegyzék által véglegesített leképezés.** A polgári
> státusz-badge-ek a polgári mobilapp funkcionális tervezésének kérdései
> (`10` 8.1, `90_sitemap` 5.4) — itt csak rögzítjük, hogy az admin
> öt-állapotú modell és a polgári badge-készlet **különböző granularitású**,
> és ez szándékos. A specifikáció a polgári adatigény-specnél tér vissza rá.
> A Flutter képernyőkön jelenleg látott badge-ek: "Jóváhagyva", "Folyamatban",
> "Megoldódott".

### 2.5 A bejelentés-nézetek fogalmai (admin felület)

A bejelentés-lista és -adatlap feature-spec
(`20_admin_felulet/10_bejelentes_lista_es_adatlap.md`) bevezetett néhány
fogalmat, amelyet a további feature-specek is használnak.

| Magyar (felületi/munka) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **bejelentés-lista** | — | A `/bejelentesek` nézet: a bejelentések oszlopos, szűrhető, lapozható listája | `90_sitemap` 2.2 |
| **bejelentés-adatlap** | — | A `/bejelentesek/details/<id>` nézet: egyetlen bejelentés teljes, szerepkör-érzékeny nézete; a triage tényleges munkaképernyője | `90_sitemap` 2.3 |
| **triage-sáv** | — | A bejelentés-adatlap felső, inline-szerkeszthető sávja a négy triage-mezővel (kategória, prioritás, határidő, felelős). Csak nem-végállapotban szerkeszthető | `10` 3.2, K-026, SD-26 |
| **tab-szűrő** | — | A bejelentés-lista fölötti előszűrő-sáv (Új · Hozzám rendelt · Késésben · Lezárt · Mind). A tab rögzített `AND`-előszűrő, a szerver oldja fel predikátummá | `00_arch` 4.1, SD-30 |
| **állapot-csík** | — | A bejelentés-adatlap vizuális folyamat-jelzője: a négy fő-ági állapotot mutatja (`Új → Kiosztva → Folyamatban → Lezárt`); a "Triage" nem szerepel rajta (nem állapot) | SD-27 |
| **inline-szerkesztés** | `inline editing` | A triage-sáv mezőinek helyben, kattintással történő szerkesztése optimistic update-tel — nincs külön szerkesztés-oldal | K-026 |
| **optimistic update** | `optimistic update` | A mezőérték a kliensen azonnal frissül, a szerver-mentés a háttérben fut; hiba esetén a kliens visszagörgeti az értéket | K-026, SD-25 |
| **concurrency-token** | — | A `Ticket.updatedAt` kettős szerepe: az inline-mentés és az akció-végpontok optimistic-concurrency ellenőrzéséhez a kliens visszaküldi a betöltött `updatedAt`-ot; eltérés esetén `409` | SD-32 |

> **A "triage-sáv" nem domain-fogalom.** UI-elem — a `Ticket` négy triage-mezeje
> (`categoryId`, `priority`, `dueDate`, felelős) egy vizuális sávban. Nincs
> hozzá entitás; a jegyzék azért rögzíti, mert több feature-spec hivatkozza.

---

## 3. Kategória, prioritás, határidő

| Magyar (felületi) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **kategória** | `Category` | A bejelentés besorolása. Kétszintű fa: **gyökér-kategória** + **alkategória** (K-036) | K-036 |
| **gyökér-kategória** | `Category` (root) | A fa felső szintje (pl. "Utak és járdák"). **Terméktulajdon** — csak az Urbino termékesített készletéből választható, a vezető nem hoz létre szabad szöveges gyökeret | K-036 |
| **alkategória** | `Category` (child) | A fa alsó szintje (pl. "kátyú"). **Tenant-tulajdon** — a vezető szabadon kezeli a saját tenantján | K-036 |
| **default kategória-katalógus** | `DefaultCategoryCatalog` | Az Urbino által termékesített kategória-fa a Core DB-ben; tenant-provisioning-időben másolódik a tenant DB-be | SD-8 |
| **prioritás** | `priority` | A bejelentés sürgőssége. Háromértékű: **Alacsony / Normál / Magas**, alapérték "Normál" | K-031 |
| **határidő** | `dueDate` | A bejelentés belső munkahatárideje. A triage automatikusan javasolja (kategória + prioritás szabály), a diszpécser felülírhatja. **Belső munkaszervezési mérce, nem ígéret a polgárnak** | K-031, `10` 3.3 |

> **A prioritás angol értékei** — javaslat a kódbeli `enum`-hoz: `Low`,
> `Normal`, `High`. A `00_domain_model.md` véglegesíti.
>
> **A "Veszélyhelyzet" — nem prioritás-érték, hanem kategória.** A
> `10_triage_flow` 3.3 / 8.3 tisztázta: a sürgősséget a prioritás ("Magas")
> viszi, a jelleget a kategória (lehet "Veszélyhelyzet" gyökér). A kettő
> független. A "Veszélyhelyzet" tehát nem negyedik prioritás-fokozat.

---

## 4. Szerepkörök és felhasználók

A négy szerepkör a `05_jogosultsagok_v2.md`-ből; a kódbeli nevek az SD-7-ből.

| Magyar (felületi) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **diszpécser** | `dispatcher` | A teljes operatív gerinc szerepköre: triage, kiosztás, duplikáció-szűrés, lezárás-felügyelet. (Anna pályája) | K-038, `05` 1. |
| **vezető** | `manager` | A diszpécser ÉS a tartalomkezelő fölérendelt halmaza — plusz Dashboard, riport, tenant-konfiguráció. A beolvadt tenant-admin jogkör. (Béla pályája) | `05` 1. |
| **tartalomkezelő** | `content_manager` | A polgári app puha tartalmát (hírek, programok, városi információk) kezeli; bejelentést nem lát | K-038 |
| **terepi dolgozó** | `field_worker` | A kiosztott ügy munkába vétele és lezárása. **Átmeneti** szerepkör (T0–T+60), utána a terepi mobilappra költözik | `05` 1. |
| **felhasználó** | `User` | A globális felhasználói fiók a Core DB-ben (név, e-mail, fiók-állapot). Egy felhasználó több tenanthoz is tartozhat | SD-1, `01_kozos_mintak` 1.3 |
| **tenant-felhasználó-projekció** | `TenantUser` | A Core `User` szűk, csak-olvasható másolata a tenant DB-ben (név, e-mail, szerepkörök) — a tenant-oldali hivatkozásokhoz | SD-2 |
| **szerepkör-hozzárendelés** | `UserTenantRole` | A Core DB-beli kötés: melyik felhasználó melyik tenanton milyen szerepkör(öke)t birtokol | SD-3, `01_kozos_mintak` 1.3 |
| **implicit unió-modell** | — | Ha egy felhasználó több szerepkört birtokol, a felület a szerepkörök **unióját** mutatja; nincs szerep-váltó UI | K-025 |
| **meghívó** | `UserInvitation` | A felhasználó-felvételhez tartozó, lejáratos, egyszer használatos belépési meghívó. A vezető küldi, a meghívott a benne lévő linkkel aktiválja a fiókját. Core DB-beli entitás, saját életciklussal | SD-34, Ü-6 |
| **meghívó beváltása** | `accept` | Az a folyamat, amellyel a meghívott felhasználó a token-linkről aktiválja a fiókját: létrejön a Zitadel-fiók, a `User` állapota `Invited`-ről `Active`-ra vált | SD-34 |
| **fiók-állapot** | `UserStatus` | A `User` globális életciklus-állapota: **Meghívva** (`Invited`) — meghívót kapott, még nem aktivált; **Aktív** (`Active`) — bejelentkezésre képes; **Letiltva** (`Disabled`) — deaktivált, de az adatai megmaradnak. A felület tegező leképezése: Meghívva / Aktív / Letiltva | SD-19, SD-39 |

> **A teljes Zitadel-szerepkör** a `tenant_<role>_<code>` mintát követi (pl.
> `tenant_dispatcher_almadi`) — SD-7. A táblázat "Angol / kód" oszlopa a
> rövid, suffix nélküli nevet adja, ahogy az `authorization.json`-ban
> szerepel.
>
> **A "polgármester" nem szerepkör.** A polgármester a heti PDF-riportot
> e-mailben kapja, de **nem lép be** az admin felületre — nincs szerepköre. A
> riport-címzettség egy **e-mail-lista**, nem szerepkör (`40` 4.5, `50` 5.2).
>
> **A "polgár" nem az admin felület szerepköre.** A polgár a polgári
> mobilapp felhasználója (a `Ticket` `reporter`-e). Az admin felület
> jogosultság-modellje nem ismeri — a polgári autentikáció külön kérdés, a
> polgári adatigény-spec dolga.

---

## 5. Szervezeti és konfigurációs fogalmak

| Magyar (felületi) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **tenant** | `Tenant` | Egy város / városgazdálkodási szervezet mint a multi-tenant rendszer egy bérlője. Saját Tenant DB-vel | K-008, SD-1 |
| **csoport** | `Group` | Terepi munkacsapat (pl. "Útkarbantartó csapat"). A triage felelős-mezője csoportra vagy személyre oszt. A pilotra: egy címke + egy taglista | `50` 3. |
| **Core DB** | `Core DB` | A tenant-független központi adatbázis: `User`, `Tenant`-regisztrum, default kategória-katalógus | SD-1 |
| **Tenant DB** | `Tenant DB` | Tenantonként egy fizikai adatbázis a tenant teljes operatív adatával | SD-1 |
| **tenant-resolution** | `tenant resolution` | A folyamat, amely a `Tenant` HTTP headerből azonosítja az aktuális tenantot és a helyes Tenant DB-re kapcsol | SD-6 |
| **tenant-alapadatok** | `Tenant.name` / `logoFileRef` / `contactAddress` / `contactPhone` / `contactEmail` | A tenant magára vonatkozó konfigurációja: név, logó, kontakt — a `/beallitasok/altalanos` oldalon. **Tartalom-paraméterek, nem brand-paraméterek** (K-037). A négy szerkeszthető mező SD-58-ban került a `Tenant` entitásra | K-037, SD-58, `50_konfig_v2.md` 5., `30_beallitasok.md` 2.1 |
| **riport-címzett-lista** | `WeeklyReportRecipient` | A heti PDF-riportot e-mailben megkapók szerkeszthető listája — a Tenant DB-beli entitás (SD-59). Nem szerepkör; a polgármester is `WeeklyReportRecipient`-ként szerepel, nem `tenant_manager`-ként | SD-59, `40_riport_v1.md` 4.5, `50_konfig_v2.md` 5.2, `30_beallitasok.md` 2.2 |

---

## 6. Riport-fogalmak

| Magyar (felületi) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **Dashboard** / **Főoldal** | `Dashboard` | A vezető belső munkaeszköze a `/fooldal`-on: négy KPI-kártya + terepi csapat-tábla. Élő, interaktív | K-035, `40` 3. |
| **heti PDF-riport** | `weekly report` | A kifelé (polgármester felé) kommunikálható, automatikusan generált, e-mailben küldött heti összegző. Fix sablon | K-035, `40` 4. |
| **heti riport entitás** | `WeeklyReport` | A heti PDF-riport perzisztált pillanatképe a Tenant DB-ben: PDF-bináris hivatkozás (S3) + strukturált `snapshotData` + generálás-/kézbesítés-státusz. Egy tenant egy hetére pontosan egy rekord (SD-55/c) | SD-49, `00_domain_model.md` 2.4, `40_riport.md` 2.2 |
| **KPI-kártya** | — | A Dashboard "Ez a hét" blokkjának egy mutatója (Nyitott ügyek, Aznapi új, Késésben, Aznap lezárt) | `40` 3.2 |
| **csapat-teljesítmény tábla** | — | A Dashboard terepi munkatársankénti tábla: lezárt, folyamatban, átlagos lezárási idő. Névre bontva **csak** a Dashboardon (a PDF név nélkül összesít — K-035) | `40` 3.2, K-035 |
| **átlagos lezárási idő** | — | A `Resolved`-be került bejelentések beérkezés→lezárás különbségének átlaga, az adott héten lezárt ügyekre | `40` 3.5 |

> **A "ma" és a "hét" definíciója** (`40` 3.5, SD-10): a "ma" a tenant-időzóna
> szerinti naptári nap (00:00–24:00); a "hét" hétfőtől vasárnapig (a magyar
> hét hétfővel kezdődik). A Dashboard és a heti PDF **ugyanazt** a
> definíciót használja — a szerver számítja, tenant-időzónában.

---

## 7. Tartalmi fogalmak (a tartalomkezelő modul)

| Magyar (felületi) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **hír** | `News` | A városvezetés hivatalos közleménye a polgári appban. Péter politikai csatornája | K-038, `60` 3.2 |
| **városi program** | `Event` | Rendezvény-jellegű tartalom — van időpontja és helyszíne | `60` 3.3 |
| **városi információ** | `CityInfo` | Külső linkre mutató hasznos tétel (strand, hivatali oldal, közmű) — lényegében rendezett linkgyűjtemény | `60` 3.4 |
| **puha tartalom** | — | Gyűjtőfogalom a hír + városi program + városi információ hármasra — a polgári app nem-bejelentés tartalma. A tartalomkezelő ezt kezeli | `60` 1. |
| **publikálás** | `publish` | A tartalom `Vázlat → Publikált` átmenete — innentől látszik a polgári appban | `60` 3.5 |
| **vázlat** | `Draft` | A tartalom állapota, amíg a tartalomkezelő dolgozik rajta — a polgári appban nem látszik | `60` 3.5 |

> **Az angol tartalom-entitásnevek** (`News`, `Event`, `CityInfo`)
> **javaslatok** — a `00_domain_model.md` véglegesíti. A "városi program"
> kódnevének az `Event`-et javaslom (rövidebb, mint `CityProgram`), de ha a
> `Ticket`-tel vagy más entitással névütközés merül fel, felülvizsgáljuk.
>
> **A GYIK nem tartozik ide.** A GYIK Urbino-hatáskör (K-039), az
> Urbino-admin modul kezeli — nem tenant-tartalom, nem a tartalomkezelő
> szerepkör eleme.

---

## 8. Duplikáció-fogalmak

| Magyar (felületi) | Angol / kód | Definíció | Forrás |
|---|---|---|---|
| **duplikáció-szűrés** | `duplicate detection` | A deterministic heurisztika, amely felismeri a lehetséges duplikátumokat (térbeli közelség ≤50 m + azonos gyökér-kategória + idő-közelség ≤14 nap) | K-032 |
| **"Hasonló bejelentések" doboz** | — | A duplikáció-szűrés UX-vetülete a bejelentés-adatlapon. Döntéstámogatás, **nem kötelező lépés** | K-033, `20` 3. |
| **összevonás** | `merge` | Amikor a diszpécser kimondja, hogy két bejelentés ugyanaz. Az egyik **eredeti** marad, a másik **duplikátum** lesz | K-034, `20` 4. |
| **eredeti** | `original` (a megmaradó `Ticket`) | Az összevonáskor megmaradó, élő bejelentés — alapból a régebben beérkezett | K-034 |
| **duplikátum** | `duplicate` | Az összevonáskor `Elutasítva` állapotba kerülő bejelentés, "Duplikáció" indoklással és az eredetire mutató hivatkozással | K-034 |

---

## 9. Tisztázott ingadozások — amit a forrásanyagok nem következetesen használtak

> Ez a szakasz **rögzíti, hol ingadoztak a források**, és melyik döntés
> érvényes. A `00_domain_model.md` és a feature-specek ezt követik.

| Ingadozás | A források | A jegyzék döntése |
|---|---|---|
| "bejelentés" vs. "ügy" vs. "ticket" | A `10_triage_flow` mindhármat használja; a koncepció "ügy lesz vagy zaj" | **Egy objektum, három névsík** (0. szakasz). Felületi: bejelentés; köznyelvi: ügy; kód: `Ticket` |
| "manager felület" vs. "admin felület" | A funkcionális tervezés "manager felület"; az instrukció "admin felület" | **"admin felület"** a specifikációban (1. szakasz) |
| "státusz" vs. "állapot" | Vegyesen mindkettő | Szinonima; a felületi terminus **"státusz"** (2.2) |
| "Lezárt" angol neve | — | **`Resolved`** (nem `Closed`) — a "megoldottság" pontosabb (2.2) |
| "Duplikáció" mint állapot vs. indok | A `20` "a duplikátum `Elutasítva`" | **Elutasítási indok**, nem önálló állapot (2.2) |
| "Veszélyhelyzet" mint prioritás vs. kategória | A `10` 8.3 jelezte a kérdést | **Kategória**, nem prioritás-fokozat (3.) |
| A polgári app neve | A `VarosApp_Projekt_Brief` "VárosApp" | **"Urbino"** — a brief elavult (Ü-2); a polgári app az Urbino polgári mobilappja |
| "vendég" / "anonim" felhasználó | A brief említi | **Nincs** anonim bejelentés (Ü-2); az admin felület nem ismer "vendég" szerepkört |

---

## 10. Nyitott terminológiai kérdések

1. **A tartalom-entitások angol nevei** (`News`, `Event`, `CityInfo`) — a
   `00_domain_model.md` véglegesíti; az `Event` névnél figyelni kell az
   esetleges ütközésre (pl. ha event-driven mintát is bevezetünk — bár a
   `01_kozos_mintak` 7.4 szerint a pilot nem event-driven infrastruktúrájú).
2. **A `Ticket` mezőneveinek** végleges kódneve (`reporter`, `title`,
   `description`, `location`, `internalNote`, `dueDate`, `rejectionReason`,
   `resolutionNote`) — javaslat-szinten itt; a `00_domain_model.md` rögzíti
   típussal.
3. **A polgári státusz-badge-ek** végleges szövege ("Beérkezett" stb.) — a
   polgári mobilapp funkcionális tervezésének kérdése, nem ezé a jegyzéké
   (2.4).

---

## Hivatkozott dokumentumok

- `kanonikus_donek.md` — K-005, K-008, K-025, K-028, K-029, K-030, K-031,
  K-032, K-034, K-035, K-036, K-037, K-038, K-039
- `01_kozos_mintak.md` — SD-1, SD-2, SD-3, SD-6, SD-7, SD-8, SD-10, J-2
- `80_modulok/manager_felulet/` — `00_architektura_v4`, `05_jogosultsagok_v2`,
  `10_triage_flow_v1`, `20_duplikacio_v1`, `40_riport_v1`, `50_konfig_v2`,
  `60_tartalom_v2`
- `99_donesnaplo.md` — Ü-2 (a `VarosApp_Projekt_Brief` elavult státusza)
- A két `CLAUDE.md` — a `Ticket`, `User`, szerepkör-névkonvenciók forrása

---

## Verziónapló

- **v0.1 (2026.05.18)** — Első terminológiai jegyzék. A központi
  "bejelentés/ügy/ticket" tisztázás (0. szakasz); a három rendszerelem; a
  bejelentés-életciklus, kategória/prioritás/határidő, szerepkörök,
  szervezeti/konfigurációs/riport/tartalmi/duplikáció-fogalmak magyar/angol
  párokkal; a tisztázott ingadozások táblája; három nyitott terminológiai
  kérdés.
- **v0.2 (2026.05.18)** — A bejelentés-lista és -adatlap feature-spec
  (`20_admin_felulet/10_bejelentes_lista_es_adatlap.md` v1.0) nyomán új 2.5
  alszakasz: a bejelentés-nézetek fogalmai (bejelentés-lista, -adatlap,
  triage-sáv, tab-szűrő, állapot-csík, inline-szerkesztés, optimistic update,
  concurrency-token). Új terméktani döntést nem hoz — UI- és
  implementáció-fogalmakat rögzít, amelyeket a további feature-specek
  hivatkoznak.
- **v0.3 (2026.05.19)** — A felhasználókezelés feature-spec
  (`20_admin_felulet/20_felhasznalokezeles.md` v1.0) nyomán a 4. szakasz három
  új fogalommal bővült: **meghívó** (`UserInvitation`), **meghívó beváltása**
  (`accept`), **fiók-állapot** (`UserStatus` — Meghívva / Aktív / Letiltva). Új
  terméktani döntést nem hoz — a meglévő felhasználó-modell fogalmait teszi
  hivatkozhatóvá.
- **v0.4 (2026.05.20)** — A Dashboard és heti PDF-riport feature-spec
  (`20_admin_felulet/40_riport.md` v1.0) nyomán a 6. Riport-fogalmak
  szakasz egy új sorral bővült: a `WeeklyReport` mint kódbeli entitás
  (SD-49). A "heti PDF-riport" sor (a funkcionális fogalom) változatlan —
  a kiegészítés a felületi fogalom és a kódbeli entitás viszonyát teszi
  explicitté. Új terméktani döntést nem hoz.
- **v0.5 (2026.05.20)** — A Beállítások feature-spec
  (`20_admin_felulet/30_beallitasok.md` v1.0) nyomán két meglévő sor
  pontosul az 5. Szervezeti és konfigurációs fogalmak szakaszban. A
  **"tenant-alapadatok"** sor kódbeli megnevezést kap (`Tenant.name` /
  `logoFileRef` / `contactAddress` / `contactPhone` / `contactEmail`,
  SD-58) — a négy szerkeszthető mező hozzákapcsolása a `Tenant` entitáshoz
  egyértelművé teszi, mit jelent a "tartalom-paraméter, nem brand-paraméter"
  határ konkrét mezőkben. A **"riport-címzett-lista"** sor kódbeli
  megnevezést kap (`WeeklyReportRecipient`, SD-59) — az eddigi "—" jelölés
  azt tükrözte, hogy a `40_riport_v1.md` 4.5 még nem dönti el az entitás-
  modellt; a `30_beallitasok` v1.0 ezt entitásként rögzítette a Tenant
  DB-ben. Új terméktani döntést nem hoz — kódbeli neveket véglegesít két
  meglévő fogalomhoz. A többi szakasz változatlan.