# SPEC-FEEDBACK — visszacsatolás a spec-csapatnak

**Címzett.** A Urbino spec-csapata · **Forrás.** Urbino Manager UI-csapat · **Dátum.** 2026.05.26 · **Verzió.** v0.4 (40 SF-tétel — SF-96 hozzáadva)

## Mi ez a dokumentum?

A Urbino Manager web-felület 12 admin-screen-jének részletes spec-fedés-átvizsgálása **39 olyan kérdést** vetett fel, amelyekre az Urbino-management válaszait belefoglaltuk. Ezek a válaszok 4 szekcióban vannak rendszerezve:

1. **P0 KRITIKUS — pilot-blokkoló (12 tétel)** — funkcionális hiányosságok vagy konfliktusok, amelyek a pilot-felület teljességét érintik. **Mind a 12 management-jóváhagyással elfogadva.**
2. **Érdemi spec-bővítések (10 tétel)** — új DTO-mezok, új entitás-mezok, új végpontok, új i18n-kulcsok. **6 management-jóváhagyással elfogadva; 3 fejlesztő-/spec-csapat-eldöntésre továbbítva (`under-review`); 1 Phase 2-re halasztva (`deferred`).**
3. **Spec-szelídítések (13 tétel)** — meglévő spec 1-mondat-átírások, oszlop-katalógus-revíziók, pattern-revíziók. **Mind a 13 management-jóváhagyással elfogadva.**
4. **Háttér / minor (4 tétel)** — alacsony prioritású tételek. **Mind a 4 management-jóváhagyással elfogadva.**

## Per-SF döntés-státusz formátuma

Minden SF végén szerepel egy:

```
**Döntés-státusz · 2026.05.26:** <status> — <indok>
```

Lehetséges értékek:
- **`accepted`** — a spec módosul a javaslat szerint; a HANDOFF.md ezt a végleges állapotot szállítja a fejlesztő-csapatnak.
- **`confirmed`** — a spec már most korrekt; csak megerősítést kértünk. A HANDOFF.md a meglévő spec szerint köti a fejlesztőt.
- **`under-review`** — technikai mélységű tétel (DTO-szerződés, AutoMapper-projekció, Core-Identity-bekötés); a fejlesztő-csapat vagy a spec-csapat technikai eldöntésére hagyva. A HANDOFF.md "Nyitott spec-kérdés-jegyzék"-szekciójába kerül.
- **`deferred`** — Phase 2 / pilot utáni iterációra halasztott. A HANDOFF.md "Phase 2 backlog"-szekciójába kerül.

## Spec-szöveg-szöveg-javaslatok

Több tétel **konkrét i18n-szöveg-szövegjavaslatot** is hordoz. Ezeket a management explicit jóváhagyta — a spec-csapat a `hu.json` (vagy ekvivalens) i18n-erőforrás-fájlba vezesse át:

- **SF-9 (PhoneBanner)**: `ticket.create.phoneBanner.title = "Telefonos bejelentés-felvétel"` + `ticket.create.phoneBanner.desc = "A polgár telefonon hívott; te most a nevében veszed fel a bejelentést. Az elérhetőséget kötelező megadnod (név vagy telefonszám)."`
- **SF-21 (a)**: `dashboard.downloadReport.latestHint = "Múlt heti riport · {isoWeek}. hét"` (paraméterek: `{year}`, `{isoWeek}`)
- **SF-58**: `logoUploader.uploading = "Logó feltöltése..."` + `.error.fileTooLarge = "A fájl nagyobb, mint 1 MB."` + `.error.wrongFormat = "Csak PNG, JPG, WEBP fogadható el."` + `.error.network = "Hálózati hiba — próbáld újra."`
- **SF-59 (b)**: a `40_riport.md` §3.6 1-mondat-precízálás: *"A háttér-job hétfő reggel 06:00–07:00 között (tenant-időzónában) fut..."*
- **SF-75**: `confirm.publish.noCover` ConfirmDialog title + body szöveg
- **SF-76**: `content.action.discard = "Eldobás"` (a publish-bar bal-szélén)
- **SF-95**: `cityInfo.empty.title = "Még nincs egyetlen hasznos link sem."` + `.desc = "Kezdj a városi kórház, polgármesteri hivatal és háziorvos elérhetőségével."`

## Forrás-dokumentumok

Ez a dokumentum a Urbino Manager UI-csapat belső munkájának konszolidált terméke:

- `manager-system/preview/screens/*.html` — 12 admin-screen + 16 állapot-screen-mock (React-prototípus)
- `SPEC-COVERAGE-A1A2A3.md`, `-A4A5.md`, `-A6A7A8A9.md`, `-A10A11A12.md` — 4 spec-fedés-leltár (370+ mező/végpont/UI-elem)
- `SPEC-FEEDBACK.md` — belső munkadokumentum a teljes 95 SF-tétellel (mock-fix-jelöltek + organism-bővítések + spec-csapat-jelöltek)

A spec-hivatkozások a Urbino spec-csomag `uploads/urbino-docs/`-jának fájl + § hivatkozás-formátumát követik (pl. `10_bejelentes_lista_es_adatlap.md` §4.3).

---

# Section 1 — P0 KRITIKUS · pilot-blokkoló (11 tétel)

A 11 tétel **funkcionális hiányosságot vagy konfliktust** jelez. A pilot-átadáshoz mindenképp megoldást igényelnek — akár spec-bővítéssel, akár explicit "ezt a fejlesztő mock-ban implementálja a HANDOFF.md utasítása szerint"-megerősítéssel.

## SF-7 — A1 adatlap: redukált duplikátum-nézet 5. state mintája

**Háttér.** A `00_domain_model.md` §1.2.6 + `10_bejelentes_lista_es_adatlap.md` §4.3 SD-29 + AC-C4 előírják, hogy egy `originalTicketId`-vel rendelkező ügy redukált, csak-olvasható nézettel jelenik meg: NINCS TriageBar, NINCS akció-gombsor, NINCS duplikáció-doboz. A spec elveket rögzít, **konkrét layout-mintát nem**. A pilot Wow #4 első fele ezen az élményen áll, de a React-mock-on egyetlen állapot-screen sem reprezentálja a duplikátum-vetületet.

**Kérdés.** A `10` §4.3 SD-29 szekció kapjon-e egy explicit "5. állapot — duplikátum" layout-mintát a spec-be? Vagy a starter-mintaprojekt (HANDOFF.md melléklet) szabványosítja az 5. state-et?

**Javasolt megoldás.** A spec `10` §4.3 SD-29 alá új altémakör: *"StateDuplicate minta — TicketMetaBar (lockolt, +Duplikátum-tag), nincs TriageBar / ActionBar / SimilarTicketsBox; van: `mgr-original-link` hangsúlyos link, polgári nyersanyag (PhotoGallery + Description + MapWidget read-only), ActivityTimeline a Merged-eseménnyel, StatusTrackBranched `reason.title='Duplikáció'`."* 8-10 sornyi ASCII-mock + komponens-szerződés-pontok. A starter-projekt Angular-szintre portolja.

---

## SF-12 — ActivityLog: stable-ID DTO-szerződés vs. magyar-szöveg

**Háttér.** A `00_domain_model.md` §1.4 + `10` 3.2.2 + SD-30 explicit: az `ActivityLog` `fromValue` / `toValue` mezeje **stabil, nyelvfüggetlen azonosítót** hordoz (enum-név vagy `type:id` referencia, pl. `'group:3'`), **NEM magyar szöveget**. Az i18n-sablon (`ticket.activity.statusChanged` = `'{actor} módosította a státuszt: {from} → {to}'`) kliens-oldalon oldódik magyar szövegre. A React-mock viszont a denormalizált magyar-szöveget hordozza (`text: 'státusz: Jóváhagyva → Folyamatban'`) — a fejlesztő ezt nem veheti át 1:1-re Angular-szintre.

**Kérdés.** A fejlesztő-átadás során explicit megfogalmazzuk, hogy a `ActivityTimelineDto.events[]` szerződése a stable-ID-triplet (eventType + fromValue + toValue + actorId), és az i18n-feloldás kliens-oldali — vagy a spec már ezt írja és csak hangsúlyozni kell?

**Javasolt megoldás.** A spec NEM módosul (már most korrekt). HANDOFF.md új sora: *"az ActivityTimeline az egyetlen organism, amelyik a React-mock-on a DTO-szerződésnél lazább adat-modellt használ vizuális density-okból. Az Angular-portoláskor a stable-ID-triplet + i18n-feloldás kötelező."* — Kérjük a spec-csapat megerősítését, hogy ez korrekt értelmezése a `10` 3.2.2 + SD-30 szövegnek.

---

## SF-29 — A5 adatlap: PDF inline preview-stub visszavágás vagy formalizálás

**Háttér.** A React-mock `a5-riportok-adatlap.html` egy `PdfInlineStub` komponenst renderel a baloldalon (~1100px magasság ~80%-a), 4 sub-blokkkal (toolbar + PDF-header + "A hét számai" + "A múlt héthez képest" + "Kategória bontás" + footer). A `40_riport.md` §4.4 a riport-adatlap **5 szekcióját** rögzíti, **PDF inline preview-t nem ír**. A stub funkcionálisan duplikálja a `NumbersCard`-szekciót, és bevezet egy `prevWeek`-mock-mezőt, amit a `WeeklyReportDto` nem hordoz (a "múlt héthez képest" a generálás-időben számolódik a 2 snapshotData-ból, NEM a kliensen).

**Kérdés.** A PDF inline preview maradjon kliens-implementáció (`<iframe src="...{id}/pdf">`-mintán a R-4 binary-endpoint-tól), vagy formalizáljuk-e a `WeeklyReportDto` bővítését `prevWeek`-mezővel + 6. szekcióval (`PdfPreview`) a `40` §4.4-ben?

**Javasolt megoldás (preferált).** **Visszavágás** — a `PdfInlineStub` komponens törlése a React-mockból; a baloldalon egy `<iframe>` placeholder vagy `EmptyState`-szerű "PDF-előnézet betölt..."-blokk, ami a R-4 endpoint natív böngészős PDF-megjelenítését szuggerálja. A `prevWeek`-mező eltávolítva. A custom-HTML PDF-renderelés ne épüljön a kliens-szinten — a böngésző natív PDF-megjelenítése sokkal hűségesebb a tényleges PDF-formátumhoz.

---

## SF-30 — A5 adatlap: per-recipient delivery-status — spec EXPLICIT KIZÁRJA

**Háttér.** A React-mock `RecipientsCard` minden soron egy `r.sent ? '✓' : '✕'` ikont renderel, illetve egy `r.reason` szöveget (pl. `'Bounce — szerver elérhetetlen'`). A `40_riport.md` §2.2 SD-56 + §8.1 explicit "iterational" kategóriába teszi: *"Címzettenkénti kézbesítés-státusz (egy `WeeklyReportDelivery` aldetail) — ha a pilot kívánja"*. A `WeeklyReport` entitás csak az **összesített** `deliveryStatus` (enum) és `recipientCount`-ot tárolja; a `WeeklyReportRecipient` nem hordoz `lastDeliverySuccess`-mezőt.

**Kérdés.** A pilot-on benne maradjon az aggregátum-szintű `deliveryStatus` (preferált, NEM spec-bővítés), vagy emeljük a `§8.1 iterational`-tételt pilot-szintre új `WeeklyReportDelivery` aldetail entitással + R-7 olvasó-végponttal + `WeeklyReportDto.deliveries[]` mezővel?

**Javasolt megoldás (preferált).** **Visszavágás** — a `RecipientsCard.a5d-rec-row__icon` levétele; a `r.sent` + `r.reason` mező a mock-data-ból eltávolítva. A `deliveryStatus` aggregátum-chip a kártya-fejlécben elegendő. PartialFailure-esetben opcionális small-print hint a kártya-láblécében: *"A részletes kézbesítés-eredményt a tenant e-mail-szervere naplózza."* A `WeeklyReportDelivery` aldetail pilot-szintű bevezetése jelentős domain-bővítés (FK + új tábla + új DTO + új migrace), a pilot-élmény az aggregátummal teljes.

---

## SF-62 — A10 hír-szerkesztő: `News.pushOnPublish` mező + UI-tükör teljes hiánya

**Háttér.** A `00_domain_model.md` §4.2 + `60_tartalom.md` §2.1 + §4.2.4 ASCII-mock + §4.2.5 mezősablon + §4.5.2 i18n + §4.5.5 `confirm.publish` vs `confirm.publishWithPush` 2 variant + AC-N1.8 mind előírják a `pushOnPublish: boolean` mezőt. A `content-editor.jsx` organism + a 4 állapot-mock a `value`-ban **nem hordozza** ezt a mezőt — a tartalomkezelő nem tudja beállítani a push-tényt; AC-N1.8 UI-tesztelhetetlen; a két publikálás-dialógus-variant elveszik; a polgári mobilapp NY-T1 push-átviteli minta input-kontraktja a manager-oldalon megsérül.

**Kérdés.** A `ContentEditor` organism kapjon `kind="news"`-feltételes `pushOnPublish` checkbox-mezőt + a publikálás-confirm-dialógusra 2-variant-támogatást — vagy a pilot-on a push-funkcionalitás más mechanizmuson (default-true, vagy admin-config) megy?

**Javasolt megoldás.** `ContentEditor` organism-bővítés: `kind === 'news'` esetén jelölőnégyzet a Tartalom-mező után, label "Push-értesítés a polgári app-on" + i18n-kulcs `content.news.field.pushOnPublish.help`. Új `value.pushOnPublish: boolean` mező. A publikálás-confirm-dialógus a `pushOnPublish` szerint vagy a `confirm.publish`, vagy a `confirm.publishWithPush` i18n-kulcsot használja.

---

## SF-63 — Tartalom-ág cross-cutting: `Archived` állapot UI-tükre teljes hiánya

**Háttér.** A `00_domain_model.md` §4.1 + `60_tartalom.md` §2.9 (SD-70) háromállapotú `ContentStatus` enumot ír (Draft/Published/Archived). A `60_tartalom.md` §4.2.2 kebab-menü Archived-állapot 3-akció-szettjét, §4.5.1 i18n `content.common.status.Archived`-kulcsát, AC-T3 + AC-T4 + AC-A1 (archive-checkbox) követelményeit mind előírja. A React-mock viszont:
- `publish-state-chip.jsx` + `_styles.css` csak 2-állapotos modifier-pár (`--draft`, `--published`)
- A10 + A11 lista `TABS` szettben Archived tab nincs
- A 6 szerkesztő-mockból egyik sem `StateArchived`

**Kérdés.** A `PublishStateChip` 3-állapotos bővítését (új `--archived` modifier) + a 3 lista `TabFilter`-ébe Archived-tab vagy FilterPillBar-Archív-checkbox felvételét megerősítjük, vagy a Tartalom-ág pilot-on 2-állapotos marad (Draft + Published, Archived = Phase 2)?

**Javasolt megoldás.** Megerősíteni a 3-állapotos modellt (a spec már most ezt írja). A pilot-on a `PublishStateChip` 3-állapotos (új `.mgr-pub-chip--archived` slate-tónussal), a 3 lista vagy egy Archived-tab-ot, vagy `60_tartalom` §4.5.1 i18n `content.common.filter.showArchived`-checkboxot kap. Az SF-64-vel + SF-89-vel összefüggő tétel.

---

## SF-64 — Tartalom-ág cross-cutting: kebab + Publikálás-dropdown UI sehol nem renderelt

**Háttér.** A `60_tartalom.md` §4.2.1 `TableStateConfig.rowActions` 6 akciója (`edit/publish/unpublish/archive/republish/delete`), §4.2.2 kebab-menü állapot-érzékeny 3-akció-szettje, §4.2.6 "Publikálás ▾" dropdown (Draft "Publikálás" / Published "Archiválás" + "Visszavonás vázlatba" / Archived "Újrapublikálás"). AC-A2 + AC-T1-T6 (6 acceptance). A React-mock: a 3 lista (A10/A11/A12) `DataTable.columns` egyik sem hordoz `actions`-oszlopot; a `ContentEditor.publish-bar` 3 egyszerű gombot ad (D-17 sorrend), NEM dropdown — sem "Archiválás", sem "Visszavonás vázlatba", sem "Újrapublikálás" elérhető.

**Kérdés.** A 4 átmenet (T2/T3/T4) blokkolva van pilot-on; megerősítjük-e, hogy a fejlesztő a lista-kebab + a publish-bar-dropdown-bővítést a HANDOFF.md alapján Angular-szinten valósítja meg?

**Javasolt megoldás.** Spec-szintű megerősítés: a `60_tartalom.md` §4.2.1 + §4.2.2 + §4.2.6 a kanonikus szerződés. A fejlesztő:
- A10/A11/A12 lista `DataTable.columns`-ra `actions`-oszlop felvétele `IconKebab`-triggerrel; kebab-popover §4.2.2 spec-szerint.
- `ContentEditor.publish-bar` Publikálás-gomb → dropdown-affordancia: `state="published"`-on "Archiválás" + "Visszavonás vázlatba"; `state="archived"`-on "Újrapublikálás" gomb felülírja a Vázlat-mentés-Publikálás párt.

---

## SF-79 — A11 esemény-szerkesztő: `Event.latitude/longitude` + "Térkép megnyitása" link

**Háttér.** `00_domain_model.md` §4.3 + `60_tartalom.md` §4.3.2 + i18n `content.event.field.latitude/longitude/openMap` + AC-E1.5-1.9 (5 acceptance: páros + tartomány-validáció). A `EventExtraFields` viszont csak `DateTimeRangePicker` + `locationText`-mezőt renderel; a `value`-szerződésen `{startAt, endAt, location}` szerepel — koordináta-mezok és "Térkép megnyitása"-link sehol. A polgári app térkép-megjelenítése (`screen_kezdooldal_*`) input-kontraktja megsérül.

**Kérdés.** A `latitude`/`longitude` szám-input-páros + "Megnyitás térképen" link explicit pilot-feature, vagy kihagyható és Phase 2-re halasztva?

**Javasolt megoldás.** Pilot-feature: `EventExtraFields`-be `latitude` + `longitude` szám-input-páros (`type="number" step="any"`) + alatta szöveges link *"Megnyitás térképen"* `https://www.google.com/maps/?q={lat},{lng}` URL-mintán. Új `value.latitude/longitude` mezok. AC-E1.5-1.9 spec-szerinti tartomány-validációval.

---

## SF-86 — A12 cityinfo-szerkesztő: `CityInfo.description` típus-quad-konfliktus

**Háttér.** A React-mock `ContentEditor kind="cityinfo"` a Tartalom-mezőre `RichTextEditor`-t használ (HTML, 10 000 char, SD-69 whitelist); a `value.body` mezőnévvel; `*` kötelezőként-jelölve; mock-érték HTML-tartalommal (`'<p>24 órás...</p>'`). A spec `00_domain_model.md` §4.4 + `60_tartalom.md` §3.4.2 + §4.4.2 viszont **plain text, max 500 karakter, opcionális, mezőnév `description`** — FluentValidation `MaximumLength(500)`. Négyszeres konfliktus: mezőnév + mezőtípus + kötelező-jelölés + tartalom-formátum.

**Kérdés.** A spec `CityInfo.description` formátuma (plain text 500) megerősített, vagy a screen-mock RTE-10000 mintáját kell-e formalizálni?

**Javasolt megoldás (preferált).** **A spec marad változatlan** — `CityInfo.description` plain text, max 500, opcionális. A `ContentEditor` `kind="cityinfo"`-feltételesen `<textarea>` (NEM `RichTextEditor`); mezőnév `value.description`; label "Rövid leírás" (NEM "Tartalom *"); `*` jelölés eltávolítva; `maxLength={500}` + char-counter. Mock-data plain text formátumra cserélve.

---

## SF-87 — A12 cityinfo-szerkesztő: `CityInfo.iconRef` IconPicker-mező teljes hiánya

**Háttér.** `00_domain_model.md` §4.4 + `60_tartalom.md` §2.7 (közös ikonkészlet, max 50 glyph) + §3.4.2 (whitelist) + §4.4.2 mezősablon (ikon-választó) — a `CityInfo.iconRef`-re a polgári `screen_varosi_informaciok_lista` ikonos listát vár (§5.1). A `CityinfoExtraFields` viszont csak `LinkValidator` URL-mezőt renderel; `iconRef` IconPicker sehol; a `value`-szerződés nem hordozza.

**Kérdés.** Az `iconRef` IconPicker pilot-feature?

**Javasolt megoldás.** Pilot-feature: `CityinfoExtraFields` bővítés `iconRef`-button-popoverrel a közös `iconCatalog`-glyph-szettből (A6 D-8 C-2A IconPicker-mintán). Új `value.iconRef: string` mező. A polgári lista ikon-bal-cellája erre épül.

---

## SF-88 — A12 cityinfo-szerkesztő: `CityInfo.groupLabel` autocomplete-mező + lookup-végpont teljes hiánya

**Háttér.** `00_domain_model.md` §4.4 + `60_tartalom.md` §2.5 (SD-71, szabad-szöveg max 100) + §3.4.6 (`GET /v1/city-info-groups` distinct-lookup) + §4.4.2 mezősablon (autocomplete) + §4.5.4 i18n `content.cityInfo.field.groupLabel.placeholder = "Pl. Strandok, Hivatalok"`; AC-C2 (3 acceptance). A polgári lista szekcionálását (§5.3.3 `Strandok`/`Hivatalok`) ez a mező hajtja. A `CityinfoExtraFields` viszont csak `LinkValidator`-t renderel — `groupLabel`-autocomplete sehol.

**Kérdés.** A `groupLabel` autocomplete + `/v1/city-info-groups` distinct-lookup-végpont pilot-feature?

**Javasolt megoldás.** Pilot-feature: `CityinfoExtraFields` bővítés `groupLabel` autocomplete-input-tal (PrimeNG `p-autocomplete`-ekvivalens; host-felelős a `GET /v1/city-info-groups`-hívásért) + spec-konform placeholder. Új `value.groupLabel: string` mező. A polgári lista-szekcionálás erre épül.

---

## SF-89 — A12 cityinfo-lista: `PublishStateChip` per-row + `contentStatus`-szűrő hiánya

**Háttér.** `00_domain_model.md` §4.1 + §4.4 — a `CityInfo` ugyanazt a `ContentStatus`-enumot örökli (Draft/Published/Archived); §4.4.1 cross-reference a §4.2.1 News-konfigurációra (Status-multiselect-szűrő + Archive-toggle). A React-mock viszont:
- A12 lista `InfoRow` NEM rendereli a `PublishStateChip`-et
- Nincs `Állapot` oszlop
- A screen-header literal-szöveg explicit *"nincs publish-state-chip (minden info él)"* — **téves spec-értelmezés**
- A mock-data `state: 'valid' | 'unreachable'` (LinkValidator-state, ortogonális a `contentStatus`-szal — a SF-92 értelmében már törölve a mock-ból)

**Kérdés.** A `CityInfo` 3-állapotos PublishStateChip + lista-szintű `contentStatus`-szűrő pilot-feature (mint A10/A11), vagy a CityInfo-k mind alapból "Published"-állapotúak és a Draft/Archived a vezetőnek nem érhető el?

**Javasolt megoldás.** Pilot-feature: A12 lista `InfoRow`-on `PublishStateChip` per-row + `FilterPillBar`-ba státusz-szűrő (vagy `TabFilter` az A10/A11-mintán). A "minden info él" pozíció **visszavonandó** — téves értelmezés. Az SF-63 + SF-64 P0-csomag tagja.

---

# Section 2 — Érdemi spec-bővítések (10 tétel)

Ezek a tételek **a spec-dokumentum módosulását igénylik**: új DTO-mezok, új entitás-mezok, új végpontok, új i18n-kulcsok. Pilot-szintű döntés szükséges.

## SF-2 — `TicketListDto.assigneeType` mező hozzáadása

**Háttér.** `10_bejelentes_lista_es_adatlap.md` §3.2.1 a `TicketListDto`-n csak `assigneeLabel: string?` denormalizált stringet adja (a felelős neve). §3.2.2 detail-DTO viszont `assigneeType: "group"|"user"|null` mezőt ad. A lista-DTO-ból a kliens nem tudja, csoport vagy személy név-e az `assigneeLabel`, emiatt a rendering típus-érzéketlen kell legyen. A jelenlegi `UserChip name + role` minta személy-specifikus (a `role` mezot csoportnak nem értelmezzük).

**Kérdés.** A `TicketListDto`-ba felvegyük az `assigneeType: "group"|"user"|null` mezot?

**Javasolt megoldás.** `10` §3.2.1 bővítés: új `assigneeType` enum-mező a list-DTO-n. AutoMapper `ProjectTo<TicketListDto>()` egy `Switch`-szel olvassa az `assignedGroupId`/`assignedUserId` xor-t. Pilot-méreten elhanyagolható költség, NEM új tárolt mező — derived projekció.

---

## SF-16 — `SimilarTicketDto.attachmentCount` mező hozzáadása

**Háttér.** `20_duplikacio_es_osszevonas.md` §3.1.2 `SimilarTicketDto` mezőlistája 10-mezős (`id, displayId, title, status, categoryLabel, distanceMeters, ageDifferenceDays, createdAt, updatedAt, thumbnailRef`) — **NEM** tartalmazza az `attachmentCount`-ot. A D-6/SB-2A explicit rögzíti az UI-mintát: *"Bélyegkép balra 56×56; fotó-darabszám-badge jobb-alul."* Konfliktus: az UI az adatra hivatkozik, a DTO nem hordozza.

**Kérdés.** A `SimilarTicketDto`-ba felvegyük az `attachmentCount: int` mezot?

**Javasolt megoldás.** `20_duplikacio` §3.1.2 bővítés: új `attachmentCount` mező. Az adat triviálisan számolható szerver-oldalon (`Attachment.WHERE ticketId=findId AND kind='ReportPhoto'.COUNT`); pilot-méreten ~3-4 hasonló ügyenként ~5-10 fotó-COUNT-lekérdezés, elhanyagolható költség.

---

## SF-17 — `notes[].authorRole` detail-DTO bővítés

**Háttér.** `10` §3.2.2 detail-DTO `notes[]` beágyazása `{ id, authorId, authorName, body, createdAt }` — `authorRole` nincs. A React-mock viszont a jegyzet-soron "· diszpécser" suffix-szel renderel (a szerző tenant-szerepkörét). Pedagogikai érték: a jegyzet kontextusa ("ki írta — diszpécser, terepi, vezető?"). A `TenantUser.roles[]` cross-lookup-pal előállítható, de minden notes-betöltéskor.

**Kérdés.** A detail-DTO `notes[]` beágyazás kapjon-e `authorRole: string` mezot?

**Javasolt megoldás.** `10` §3.2.2 bővítés: új `authorRole` enum-érték (kódbeli `TenantRole`), a kliens i18n-feloldja (`hu.json` `roles.dispatcher` = "diszpécser"). Pilot-szinten kis költségű cross-DB join az AutoMapper-projekcióban (vagy denormalizált, ha a `notes[]` listanagyság indokolja).

---

## SF-43 — `Group.description` entitás-bővítés

**Háttér.** `00_domain_model.md` §2.2 `Group` 4-mezős (`id, name, isActive, members`). A React-mock viszont egy `description`-mezot is hordoz (pl. "Aszfalt-, járda-, és útburkolat-karbantartás. Kátyúzás, padka-javítás, vízelvezetés.") — pedagogikai érték. K-016 pilot-scope-on kívül, de a K-007 "tenant tartalmat konfigurál" elv mentén indokolt.

**Kérdés.** A `Group` entitásra felvegyünk-e egy `description: string` mezot (opcionális, max 500 karakter)?

**Javasolt megoldás.** `00_domain_model.md` §2.2 + `30_beallitasok.md` §3.2 + §4.3.4 mezősablon-bővítés: új `description` mező. A vezető szerkeszti az adatlap "Alapadatok" szekciójában. Opcionális, üresen hagyható. Az [validationForm]-mintába triviálisan illeszthető (textarea, max 500).

---

## SF-52 — `User.lastActiveAt` entitás-bővítés

**Háttér.** A `20_felhasznalokezeles.md` §4.3 adatlap-szekció nem hordoz user-aktivitás-mezot. A React-mock `lastActiveLabel` ("3 napja", "most aktív" stb) — a vezető szempontjából érdemi info (ki használja aktívan a felületet, ki nem). A `User.lastLoginAt` (vagy hasonló) mező a Core-Identity-szolgáltatáson már létezhet — kérdés, hogy a tenant-szintű DTO-ba átvezetjük-e.

**Kérdés.** A `User` (vagy `TenantUser`) entitásra felvegyünk-e egy `lastActiveAt: DateTimeOffset?` mezot, és a `UserDetailDto`-ban derived-megjelenítéssel?

**Javasolt megoldás.** `00_domain_model.md` §3.1 + `20_felhasznalokezeles.md` §4.3 mezősablon-bővítés. Adatforrás-eldöntés: Core-Identity-szolgáltatás vagy tenant-szinten (audit-log alapú). Pilot-szinten a tenant-szintű audit-log derived elegendő.

---

## SF-59 (b) — `40_riport.md` §3.6: pontos időpont-precízálás "hétfő reggel 06:00–07:00"

**Háttér.** A spec `40_riport.md` §1.2 + §3.6 a heti riport generálását "hétfő reggel"-re időzíti, de **konkrét óra-precízió NINCS** ("néhány órával vasárnap 24:00 után"). A vezető és a címzettek nem tudják, mikor érkezik pontosan a riport. A React-mock korábban tévesen "péntek reggel 06:00"-t írt (a SF-59 (a) mock-fix már elvégezve: "hétfő reggel" generikus szöveggel). Most a pontosabb időablakra kérünk megerősítést.

**Kérdés.** A spec rögzítse-e a konkrét időablakot, hogy a vezető explicit várakozást képezhessen?

**Javasolt megoldás.** `40_riport.md` §3.6 1-mondat-bővítés: *"A háttér-job hétfő reggel 06:00–07:00 között (tenant-időzónában) fut. A vezető és a címzettek a hét első munkanapjának reggelére érvényes várakozást képezhetnek."* A kliens UI-szintű leírások (pl. A9 description) erre épülnek.

---

## SF-61 — `Tenant.logoUploadedAt/By` audit-mezok

**Háttér.** A `Tenant` entitás `AuditableEntity`-örökölt → `updatedAt`/`updatedBy` **tenant-szinten** (nem logó-szintűen). A React-mock `LogoUploader` viszont 4 derived-mezot renderel (`filename`, `size`, `uploadedAt`, `uploadedBy`) a logó-fájl szintjén — pedagogikai érték a vezetőnek ("ki töltötte fel utoljára és mikor?"). A `filename` + `size` triviálisan S3-objektum-metadata-ból, de a `uploadedAt`/`uploadedBy` a `Tenant` entitásra extra mezok.

**Kérdés.** A `Tenant`-re felvegyünk-e két új mezot (`logoUploadedAt: DateTimeOffset?` + `logoUploadedBy: User.id?`)?

**Javasolt megoldás.** `00_domain_model.md` `Tenant` bővítés: új `logoUploadedAt` + `logoUploadedBy` mezok. A `TenantSettingsDto.logoUploadedAt` + `logoUploadedByDisplayName` (denormalizált) derived. A `filename` + `size` derived az S3-objektum-metadata-ból (lazy, kliens-kérésre).

---

## SF-21 (a) — `dashboard.downloadReport.latestHint` i18n-kulcs

**Háttér.** A `40_riport.md` §4.2 + §4.6 a `dashboard.downloadReport.*` i18n-kulcs-csoport CTA-feliratot + `disabledHint`-et tartalmaz, **`latestHint`-et NEM**. A React-mock viszont a Dashboard CTA mellett egy "Múlt heti riport · 20. hét" hint-szöveget renderel, ami a `DashboardDto.latestReport.{year,isoWeek}` mezőkre épül. A felhasználó-élmény szempontjából érdemi info (a vezető tudja, mely hét riportját kapja).

**Kérdés.** A `40` §4.6 `dashboard.downloadReport.*` csoport bővüljön egy `latestHint`-kulccsal?

**Javasolt megoldás.** `40` §4.6 i18n-bővítés: `latestHint = "Múlt heti riport · {isoWeek}. hét"`. Paraméterek `{year}`, `{isoWeek}`. A `DashboardDto.latestReport.{year,isoWeek}` mezok szabványos fogyasztói lesznek.

---

## SF-25 (b alternatíva) — `40` §4.3: PageHeader-akció "Legutóbbi riport letöltése"

**Háttér.** A React-mock A5 lista PageHeader-action-slotja `LatestCta` button-t renderel (R-5 endpoint). A `40_riport.md` §4.2 ezt a CTA-t a **Dashboard** fejlécbe köti, NEM a `/riportok` listára. A §4.3 explicit: *"A `WeeklyReport` lista csak olvasható — nincs 'Új riport' gomb"* — implicit kizárja a PageHeader-akciókat.

**Kérdés.** A `/riportok` lista PageHeader-jén legyen-e a "Legutóbbi riport letöltése"-CTA, vagy maradjon kizárólag a Dashboard fejlécén?

**Javasolt megoldás (preferált).** **Törlés a React-mockból, NEM spec-bővítés.** A `/riportok` lista akció-üres marad; a vezető a sor `Letöltés`-cellájával éri el ugyanazt. A `top-row` letöltés-gombja egyenértékű a Dashboard-CTA-val (legutóbbi riport sortírozva felülre kerül). A `40` §4.3 marad változatlan.

---

## SF-58 — A9 `LogoUploader` upload-folyamat-állapotok (pending/error)

**Háttér.** `30_beallitasok.md` §3.3.2 + AC-R2.1..R2.4 — `POST /v1/tenants/logo` multipart, max 1MB, PNG/JPG/WEBP, max 2000×2000px. `400 file_too_large` / `400 wrong_format`. A React-mock `LogoUploader` 2 állapotot mockol (empty dropzone + uploaded preview) — a pending upload (`Uploading…` overlay) + sikertelen upload (`file_too_large`, `wrong_format`) UI-mintát nem.

**Kérdés.** A `LogoUploader` organism kapjon-e `pendingState: boolean` + `errorState: 'file_too_large' | 'wrong_format' | 'network' | null` prop-bővítést, és spec-szintű i18n-szövegekkel a hibára?

**Javasolt megoldás.** `30_beallitasok.md` §4.4 i18n-bővítés: `logoUploader.uploading = "Logó feltöltése..."` + `logoUploader.error.fileTooLarge = "A fájl nagyobb, mint 1 MB."` + `logoUploader.error.wrongFormat = "Csak PNG, JPG, WEBP fogadható el."` + `logoUploader.error.network = "Hálózati hiba — próbáld újra."`. A `LogoUploader` organism-bővítés a HANDOFF.md-ben.

---

# Section 3 — Spec-szelídítések (13 tétel)

Ezek a tételek **a meglévő spec 1-mondat-átírásait, oszlop-katalógus-revízióit, pattern-revízióit** kérik. Pilot-szintű módosítások, alacsony rizikóval.

## SF-9 — A2 PhoneBanner — `01_kozos_mintak` vagy `10` §4.1 új SD-X

**Háttér.** A React-mock `a2-uj-bejelentes.html` `StatePhoneIntake` egy amber-tinted banner-t renderel, ami explicit kódolja az `origin === 'Manual'` magatartást: címmel "Telefonos bejelentés-felvétel" + magyarázattal (a diszpécser tudja, hogy a `reporterContactText` kötelezővé válik). A spec sem `01_kozos_mintak`-ban, sem `10` §4.1-ben nem említi ezt a vizuális mintát. Belső döntés-naplónk **D-18 alatt rögzítette** (2026.05.26, l. `manager-system/DECISIONS.md`), spec-csapat-megerősítést kérünk.

**Javasolt megoldás.** `01_kozos_mintak` (vagy `10` §4.1) bővítés: új SD-X "Manual-eredet vizuális kiemelése" — amber-tinted banner + Lucide `phone` ikon + 2-3 mondatos magyarázat. Spec literal-szöveg-jelölt és i18n-kulcs (`ticket.create.phoneBanner.title` + `.desc`).

---

## SF-23 — A5 lista: "Időszak" oszlop törlése (a "Hét" cella hordozza)

**Háttér.** `40_riport.md` §4.3 oszlop-tábla az "Időszak"-ot **külön oszlopként** rögzíti: szűrhető, rendezhető, alap-látható. Pilot-volumenen (heti egy sor, ~13 sor/negyedév) a "Hét DESC" szortolás 1:1 leképezés az "Időszak DESC"-re — a két oszlop közti különbség null. A React-mock 5-oszlopos (Hét / Generálva / Állapot / Kézbesítés / Letöltés), az Időszak a `WeekCell` második sorként van a Hét-oszlopban.

**Javasolt megoldás.** `40` §4.3 oszlop-tábla "Időszak" sor **törlése** — a `WeeklyReportListDto.periodStart` + `periodEnd` mezok megmaradnak, csak nem külön oszlop-renderelést kapnak. A `TableStateConfig`-vázlat alap-látható listája 5-re csökken.

---

## SF-37 — A6 alkategória-create: modal → inline-szerkesztés

**Háttér.** `30_beallitasok.md` §4.2.5: *"Új alkategória — modal-űrlap. A gyökér-csoport fejlécén az 'Új alkategória' gomb modal-űrlapot nyit."* A React-mock viszont inline-add-row affordance-t renderel (a children-lista végén "+ Új alkategória"). A D-8 explicit nem dönt a modal-vs-inline kérdésben.

**Javasolt megoldás.** `30` §4.2.5 1-mondat-átírás: *"Új alkategória — inline-szerkesztés (K-026 minta) vagy modal-űrlap; pilot-megvalósításnál inline-szerkesztés preferált (a K-026 inline-szerkesztés-elvvel és a D-8 IconPicker-popover-mintával konzisztensen)."* Az SF-42-vel + SF-37 egységes csomag.

---

## SF-38 — Beállítás-ág cross-cutting: D-14 Settings-nav Pattern N

**Háttér.** `30_beallitasok.md` §4.1: *"A főnavigáció 'Beállítások' tételére kattintva lenyíló almenü, négy aloldal-linkkel — a tétel maga nem navigál."* + Beállítások mint **szülő-csomópont** + alatta 4 sub-page. A belső D-14 (2026.05.22) viszont Pattern N-t választott: **LeftNav 4 egyenrangú leaf, SettingsSubNav törölve** — a 4 settings-screen ezt fogyasztja. A `SettingsSubNav` organism megőrződik a kódban (HANDOFF.md Q10), de nem renderelt.

**Javasolt megoldás.** `30_beallitasok.md` §4.1 spec-szöveg-módosítás: *"A LeftNav 4 egyenrangú leaf-fel hordozza a Beállítás-ág sub-page-jeit (Általános · Kategóriák · Csoportok · Felhasználók) — a 'Beállítások' önmagában **nem navigációs csomópont**, csak breadcrumb-prefix-label. A `/beallitasok` URL `/beallitasok/altalanos`-ra redirect-el. Ha a settings-sub-pagek száma 4-en túl bővül (pl. Webhook-ok, API-kulcsok), a hierarchikus modell újra-felülvizsgálandó."*

---

## SF-42 — A7 csoport-adatlap: modal → inline-szekciós szerkesztés (analóg SF-37)

**Háttér.** `30_beallitasok.md` §4.3.2: *"`name` olvasásra (a 'Szerkesztés' gomb modal-űrlapba nyit)."* A belső D-10 G-1A (2026.05.22): *"A spec 4.3.2 modal-formát javasol, de a D-9 (A8 felhasználó-adatlap) inline-szekciónkénti szerkesztést kapott — a Beállítás-ág konzisztenciája fontosabb, mint a spec-literál pontosság."* Az SF-37 + SF-42 cross-cutting csomag.

**Javasolt megoldás.** `30` §4.3.2 1-mondat-átírás: *"a 'Szerkesztés' gomb a szekciót edit-módba kapcsolja (inline-szerkesztés a Beállítás-ági pattern szerint, l. D-10 G-1A belső döntés); modal-űrlap alternatív megvalósításként megengedett."*

---

## SF-44 — A7 lista: "Létrehozta" (createdBy) oszlop a katalógusba

**Háttér.** `30_beallitasok.md` §4.3.1 4-oszlopos katalógus nem tartalmaz `Létrehozta`-oszlopot. A React-mock viszont rendereli (a `Group` `AuditableEntity` `createdBy` Core-`User.id`-feloldással). A pilot-volumenen pedagogikai érték a vezetőnek ("ki indította a csoportot?").

**Javasolt megoldás.** `30` §4.3.1 oszlop-tábla 1-sor-bővítés:
| Létrehozta | createdBy.displayName | szövegszűrő (igen) | rendezhető (igen) | denormalizált, opcionálisan rejthető |

Az AutoMapper `ProjectTo<GroupListDto>()` egy `Switch`-szel olvassa a `createdBy` Core-`User.displayName`-ét; cross-DB költség aggályos esetben `createdByDisplayName` denormalizált tárolt mező.

---

## SF-71 — A10 lista: "Szerző" oszlop alapból-látható

**Háttér.** `60_tartalom.md` §4.2.1 oszlop-katalógus: `createdByName` `visible: false` (alapból rejtve). A React-mock viszont alapból láthatóan rendereli — a pilot-volumenen (1-2 tartalomkezelő tenantonként) a "ki írta?" gyakori info. A spec szerinti `visible: false` túl restrictív.

**Javasolt megoldás.** `60_tartalom.md` §4.2.1 1-mező-szelídítés: `createdByName` `visible: true` alapból. A vezető a `TableStateConfig`-on át tudja kikapcsolni, ha sok az oszlop. Alacsony rizikó.

---

## SF-75 — `News.coverImageRef`: opcionális, DE publikáláshoz erősen javasolt

**Háttér.** `00_domain_model.md` §4.2 `coverImageRef: O` (opcionális). `60_tartalom.md` §3.2.5 nem-szerkeszthető-listán, **DE nincs explicit "kötelező a publikáláshoz" szabály**. A React-mock `StateValidationError` viszont `fieldErrors.coverImage = "Borítókép kötelező a publikáláshoz"` szöveggel jelez — a polgári app csempéjének vizuális egységessége indokolja.

**Javasolt megoldás.** `60_tartalom.md` §4.2.5 mezősablon-bővítés: `coverImageRef` opcionális, **DE** publikáláshoz erősen javasolt; **publikálás-előtti warning** ConfirmDialog-mintán (NEM error, NEM blokkolás — az SF-81 past-date-confirm-mintán). A vezető megerősítheti "Mégis publikálom" → `confirm.publish.noCover`-i18n.

---

## SF-76 — ContentEditor publish-bar: "Eldobás" megerősítés

**Háttér.** `60_tartalom.md` §4.2.4 ASCII-mock: `[Visszavonás] [Mentés] [Publikálás ▾]`. A React-mock viszont "Eldobás"-gombot rajzol (D-17 publish-bar bal-szélen). A "Visszavonás" szó kétértelmű a `content.action.unpublish = "Visszavonás vázlatba"` akcióval.

**Javasolt megoldás.** `60` §4.2.4 1-szó-szelídítés: "Visszavonás" → "Eldobás" a publish-bar bal-szélén. Spec-konzisztencia a `content.action.discard` új i18n-kulccsal.

---

## SF-82 — A11 lista: `cellType: 'titleWithLocation' + 'dateRange'`

**Háttér.** `60_tartalom.md` §4.3.1 az `endsAt` (`visible: false`) + `locationText` (`visible: false`) mezőket **külön-aktiválható oszlopokként** rögzíti. A React-mock viszont kombinálva kezel: `locationText` a TitleCell sub-sorba olvasztva (`__loc`), `endsAt` a TimeCell sub-cellába (`__time`). UX-szempontból a kombinált-cella **jobb sűrűségű**.

**Javasolt megoldás.** `60_tartalom.md` §4.3.1 oszlop-tábla bővítés új cellType-okkal: `locationText`-cell `title`-oszlopba olvasztva (`cellType: 'titleWithLocation'`), `endsAt`-cell `startsAt`-oszlopba (`cellType: 'dateRange'`). Egyszerű oszlop-katalógus-revízió, alacsony rizikó.

---

## SF-83 — A11 lista: `cellType: 'eventTimeWithProximity'` — D-20 belsőleg lefedi

**Háttér.** A React-mock A11 lista `TimeCell`-en proximity-szín-kódot használ (derived `when` mező: `today` = amber, `soon` = primary, `future` = neutral, `past` = opacity 0.55). A `today`-en az amber szemantikai-overload-kockázattal jár (`--u-status-folyamatban-*`-státusszal egyezne). Belső D-20 (2026.05.26) **rögzítette a cseré-t blue-100-ra** + új `cellType: 'eventTimeWithProximity'`-cellrenderer-mintát.

**Javasolt megoldás.** `60_tartalom.md` §4.3.1 oszlop-tábla bővítés: új `cellType: 'eventTimeWithProximity'` — input `startsAt`, derived `when` (today/soon/future/past) + color-modifier. Spec literal-megemlítés a D-20 belső dokumentumra (vagy újra-leírás a `60_tartalom`-ban).

---

## SF-84 — A11 lista: "Közelgő" / "Lezajlott" derived-szűrő-tab

**Háttér.** A React-mock A11 lista 4 tab-ot ad: `[Közelgő / Lezajlott / Vázlat / Mind]`. A `Lezajlott` derived (`when === 'past'`), **NEM** `contentStatus`-derivált. Ortogonális a `Vázlat` (state-derived) tab-tól. A `60_tartalom` §4.3.1 csak a `contentStatus`-szűrő multiselect-jét rögzíti.

**Javasolt megoldás.** Két opció:
- **(a) Mock-szintű alternatíva** — `Közelgő/Lezajlott` `startsAt`-szűrő-pill a `FilterPillBar`-ba; `TabFilter` `[Mind/Publikált/Vázlat]` A10-konzisztens.
- **(b) Spec-szövegmódosítás** — `60_tartalom.md` §4.3.1 explicit megerősítése, hogy a `Közelgő/Lezajlott` derived-tabok (az `Event` entitás idő-szempontú szűrése — a `News`+`CityInfo`-n nincs).

Pilot-szintű, **(b)** preferált.

---

## SF-93 — A12 lista: `urlHost` derived-cell

**Háttér.** A React-mock A12 lista `InfoRow` egy `row.host` derived-cellát renderel (`'korhaz.balatonalmadi.hu'` formátum, az URL `host`-jából származtatva). A `60_tartalom.md` §4.4.1 oszlop-szerződés az `url`-t (`visible: false` alapból) tartalmazza, host-derived cellát nem.

**Javasolt megoldás.** `60` §4.4.1 oszlop-tábla bővítés: új `cellType: 'urlHost'` — input `url`, derived `host` (a `URL.host`-ja). Alacsony rizikó, mono-formátum.

---

# Section 4 — Háttér / minor (4 tétel)

Alacsony prioritású tételek a spec-csapat figyelmébe — nem pilot-blokkolók, de a spec-konzisztenciát érintik.

## SF-19 — A4 Dashboard "Aznap lezárt" KPI lefúrás VF-R1 emlékeztető

**Háttér.** `40_riport.md` §8.3 VF-R1: a `10` lista bővítendő `resolvedAt`-szűrővel (dátum-tartomány). Amíg a VF-R1 nincs átvezetve, a Dashboard "Aznap lezárt"-KPI átmenetileg a `/bejelentesek?tab=lezart`-ra fúr le dátum-szűrő nélkül.

**Javasolt megoldás.** `10_bejelentes_lista_es_adatlap.md` §4.2 oszlop-katalógus-bővítés-emlékeztető: `resolvedAt`-szűrővel (dátum-tartomány, `resolvedFrom`/`resolvedTo`) a `Lezárt`-tab-on. Pilot pre-átadás (Phase 3) tételezett.

---

## SF-48 — `User.language` UI-fedés szándékos kihagyás

**Háttér.** `00_domain_model.md` §3.1 `User.language: string?` mező (felhasználói nyelvválasztás). `20_felhasznalokezeles.md` §4.3 adatlap-mezősablon ezt **nem említi**. Pilot-volumenen elhanyagolható (Balatonalmádi 100% magyar staff), de a spec szerinti mező UI-feloldása nyitva marad.

**Javasolt megoldás (preferált).** **Szándékos-kihagyás-megerősítés** — `20_felhasznalokezeles.md` §4.3 1-bekezdés: *"a `language` UI-szinten csak a saját profilról szerkeszthető (Phase 2+); más felhasználó nyelvének módosítása nem támogatott a pilot-on. A vezető-adatlap-on a `language` mező rejtve."* A "saját profil"-oldal a pilot-on nem létezik (a `language`-t a Core Identity-szolgáltatás regisztrációs flow-ja állítja).

---

## SF-49 — `UserInvitation.status` (Pending/Expired/Revoked) differenciálás

**Háttér.** `00_domain_model.md` §3.5 `UserInvitation.status` enum: `Pending` / `Accepted` / `Expired` / `Revoked`. A React-mock A8 lista `Meghívva` tab-ja egy lejárt meghívó-t (`Expired`) ugyanúgy "Meghívva" tag-gel jelenít meg, mint egy érvényeset (`Pending`). A meghívók 7-napos érvényességűek (§3.5), utána újraküldés szükséges.

**Javasolt megoldás.** `20_felhasznalokezeles.md` §4.2 oszlop-katalógus bővítés: a `Meghívva`-tab listán `expiresAt` derived-mező megjelenítése — `< now()` → "lejárt" piros mini-tag (`u-chip--danger`); `now() + 24h`-belül → "hamarosan lejár" amber mini-tag (`u-chip--warning`). Adatlap-on `Expired`-status-szerinti finomítás (a "Meghívó újraküldése" gomb hangsúlyosabb + magyarázó-hint).

---

## SF-95 — A12 lista empty-state literal-szöveg

**Háttér.** `60_tartalom.md` §4.5.6 spec-literal: *"Még nincs városi információ."* + *"Adj hozzá hasznos linkeket a polgárok számára."* A React-mock viszont: *"Még nincs egyetlen hasznos link sem."* + *"Kezdj a városi kórház, polgármesteri hivatal és háziorvos elérhetőségével."*

**Javasolt megoldás (alternatíva).** A "hasznos linkek" megfogalmazás jobban tükrözi a tartalomkezelő-szándékot (a `CityInfo` lista valójában hasznos URL-ek gyűjtése). **Spec-szelídítés-jelölt**: `60_tartalom.md` §4.5.6 i18n-szöveg-átírás a mock-ot követve. Alternatíva: mock-korrekció a spec-literal-szöveghez. Alacsony prioritás.

---

# Döntés-státusz összesítő (39/39 tétel)

**Forrás:** Urbino-management jóváhagyás · 2026.05.26 · 8 chat-batch alatt feldolgozott.

| SF | Szekció | Tárgy | Státusz | Megj. |
|---|---|---|---|---|
| SF-2  | 2 | `TicketListDto.assigneeType` mező | `under-review` | Fejlesztő-/spec-csapat dönt (technikai) |
| SF-7  | 1 | A1 adatlap 5. state (duplikátum) | **accepted** | `10` §4.3 SD-29 bővítés + starter A1-en 5. artboard |
| SF-9  | 3 | A2 PhoneBanner spec-felé | **accepted** | `01_kozos_mintak` új SD-X; i18n-szöveg jóváhagyva |
| SF-12 | 1 | ActivityLog stable-ID DTO | **confirmed** | Spec marad; HANDOFF.md hangsúlyoz |
| SF-16 | 2 | `SimilarTicketDto.attachmentCount` | `under-review` | Fejlesztő-/spec-csapat dönt |
| SF-17 | 2 | `notes[].authorRole` | `under-review` | Fejlesztő-/spec-csapat dönt |
| SF-19 | 4 | A4 KPI VF-R1 emlékeztető | **accepted** | `10` §4.2 oszlop-bővítés a `Lezárt`-tab-ra |
| SF-21a| 2 | `dashboard.downloadReport.latestHint` | **accepted** | i18n-szöveg jóváhagyva |
| SF-23 | 3 | A5 lista "Időszak" oszlop törlése | **accepted** | `40` §4.3 oszlop-tábla 1 sor törlés |
| SF-25b| 2 | `/riportok` PageHeader-akció | **accepted** | Visszavágás (NEM spec-bővítés); mock-fix |
| SF-29 | 1 | A5 PDF inline preview-stub | **accepted** | Visszavágás; `<iframe>` placeholder; mock-fix |
| SF-30 | 1 | A5 per-recipient delivery-status | **accepted** | Visszavágás; aggregátum-chip marad; mock-fix |
| SF-37 | 3 | A6 alkategória-create modal→inline | **accepted** | `30` §4.2.5 1-mondat-átírás |
| SF-38 | 3 | Beállítás-ág LeftNav Pattern N | **accepted** | `30` §4.1 spec-szöveg-módosítás (D-14) |
| SF-42 | 3 | A7 csoport-adatlap modal→inline | **accepted** | `30` §4.3.2 1-mondat-átírás |
| SF-43 | 2 | `Group.description` entitás-bővítés | **accepted** | `00_domain_model` §2.2 + `30` §3.2 új mező |
| SF-44 | 3 | A7 lista "Létrehozta" oszlop | **accepted** | `30` §4.3.1 oszlop-tábla 1 sor bővítés |
| SF-48 | 4 | `User.language` UI-fedés | **accepted** | Szándékos-kihagyás-megerősítés (`20` §4.3) |
| SF-49 | 4 | `UserInvitation.status` differenciálás | **accepted** | `20` §4.2 oszlop-katalógus + adatlap-finomítás |
| SF-52 | 2 | `User.lastActiveAt` mező | `under-review` | Fejlesztő-/spec-csapat dönt (technikai) |
| SF-58 | 2 | LogoUploader pending/error i18n | **accepted** | 4 i18n-szöveg jóváhagyva |
| SF-59b| 2 | `40` §3.6 hétfő reggel 06:00–07:00 | **accepted** | Spec 1-mondat-precízálás |
| SF-61 | 2 | `Tenant.logoUploadedAt/By` | `deferred` | Phase 2 — logo még nem jelenik meg |
| SF-62 | 1 | `News.pushOnPublish` UI-tükör | **accepted** | ContentEditor organism-bővítés; spec-konform |
| SF-63 | 1 | Tartalom-ág Archived 3-állapotos chip | **confirmed** | Spec marad; PublishStateChip 3-állapotos a portoláskor |
| SF-64 | 1 | Tartalom-ág kebab + Publish-dropdown | **confirmed** | Spec marad; lista-kebab + dropdown a portoláskor |
| SF-71 | 3 | A10 "Szerző" oszlop alapból-látható | **accepted** | `60_tartalom` §4.2.1 `visible: true` |
| SF-75 | 3 | `News.coverImageRef` publish-warning | **accepted** | `60_tartalom` §4.2.5 warning ConfirmDialog; mock-fix |
| SF-76 | 3 | ContentEditor "Eldobás" megerősítés | **accepted** | `60_tartalom` §4.2.4 1-szó-szelídítés |
| SF-79 | 1 | A11 lat/lng + Térkép-link | **confirmed** | Spec marad; `EventExtraFields`-bővítés a portoláskor |
| SF-82 | 3 | A11 cellType titleWithLocation+dateRange | **accepted** | `60_tartalom` §4.3.1 oszlop-bővítés |
| SF-83 | 3 | A11 cellType eventTimeWithProximity | **accepted** | D-20 belsőleg lefedi; spec-bővítés |
| SF-84 | 3 | A11 derived "Közelgő/Lezajlott" tab | **accepted** | `60_tartalom` §4.3.1 explicit 4-tab |
| SF-86 | 1 | A12 description quad-konfliktus | **confirmed** | Spec marad (plain 500); mock-fix |
| SF-87 | 1 | A12 `iconRef` IconPicker | **confirmed** | Spec marad; `CityinfoExtraFields`-bővítés |
| SF-88 | 1 | A12 `groupLabel` autocomplete | **confirmed** | Spec marad; `CityinfoExtraFields`-bővítés |
| SF-89 | 1 | A12 PublishStateChip per-row | **accepted** | Mock-korrekció + spec-konform a pilotra |
| SF-93 | 3 | A12 cellType `urlHost` | **accepted** | `60_tartalom` §4.4.1 új cellType |
| SF-95 | 4 | A12 empty-state literal-szöveg | **accepted** | `60_tartalom` §4.5.6 i18n-átírás; szöveg jóváhagyva |

## Σ státusz-statisztika

| Státusz | Count | % |
|---|---|---|
| **accepted** (spec módosul / mock-fix) | 27 | 69% |
| **confirmed** (spec marad; HANDOFF.md hangsúlyozó) | 7 | 18% |
| **under-review** (fejlesztő-/spec-csapat technikai döntés) | 4 | 10% |
| **deferred** (Phase 2) | 1 | 3% |
| **Σ** | **39** | 100% |

## Mock-fix-jelölt SF-ek (posztulált, az Iter 6c utáni mock-tidy-csomag számára)

A management-döntésekből **6 új mock-fix-tétel** keletkezett, amelyek a 28 screen-mockon közvetlen szövegcserét / komponens-törlést igényelnek:

| SF | Fájl | Fix |
|---|---|---|
| SF-29 | a5-riportok-adatlap.html | `PdfInlineStub` komponens törlés (a baloldal teljes ~80% magasság) + `<iframe>` placeholder + `prevWeek`-mock-mező törlés |
| SF-30 | a5-riportok-adatlap.html | `RecipientsCard.a5d-rec-row__icon` lev. + mock-data `r.sent` + `r.reason` törlés |
| SF-75 | a10-hirek-szerkeszto.html | `StateValidationError.fieldErrors.coverImage` szöveg-szelídítés ("kötelező" → "javasolt"); új `StatePublishConfirmNoCover` artboard |
| SF-86 | a12-cityinfo-szerkeszto.html | `RichTextEditor` → `<textarea>` csere + mezőnév `body` → `description` + `*`-jelölés-törlés + max 500 + mock plain-text |
| SF-89 | a12-cityinfo-lista.html | screen-header literal-szöveg javítás ("nincs publish-state-chip" → publish-state-chip per-row + state-szűrő); CITY_INFOS `contentStatus`-mező felvétele |
| SF-83 | a11-programok-lista.html | `TimeCell.--today` amber → blue-100 csere (D-20 belsőleg lefedi; Iter 7-Angular-portoláskor) |

Ezek a fix-ek **az Iter 7 (HANDOFF.md + starter/) ELŐTT** elvégzendő mock-tidy-csomag — egy záró iter (`Iter 6d — Post-decision mock-fix`).

---

## SF-96 — A12 TabFilter visszavonása (drag-drop konfliktus) — SF-63 felülbírálása az A12-re**Háttér.** Az SF-63 alatt mind a 3 listára (A10/A11/A12) `TabFilter`-bővítést jóváhagyott a management (Mind / Publikált / Vázlat / Archív 4-tag). Az A12 mock-implementáció során feltárult egy funkcionális konfliktus: az A12 a drag-drop **manuális sorrendezést** kíván (S15 + D-15 + spec `60_tartalom` §4.4 — a polgári app a manager-által-rendezett sorrendben listáz). A `TabFilter`-tab-szétválasztás (külön Vázlat / Archív / Publikált) ezt szerkezetileg lehetetlenné teszi: a drag-drop egy lista belső sorrendje; ha 4 tab-ra szétdaraboljuk a sorokat, a manuális sorrend értelmét veszti.

**Javasolt megoldás.** Az A12-re a `TabFilter`-megközelítés visszavonandó. A spec `60_tartalom` §4.5.1 `content.common.filter.showArchived`-**checkbox**-mintáját megerősítjük az A12 esetére:
- Az A12 lista alapból csak a `contentStatus === 'published'` sorokat mutatja, drag-drop sorrendben.
- Egy `Archív megjelenítése` toggle-pill (FilterPillBar-on) bekapcsolásával az archív sorok is megjelennek **a publikált lista alatt, vizuálisan elválasztva** (opacity 0.7, "Archivált (N)" alcím), drag-drop nélkül.
- A `Vázlat`-tartalmak az adminisztrációs flow-ban a Cityinfo-szerkesztő-screen-en kezelhetők (a szerkesztő-mockon `PublishStateChip state="draft"` jelzéssel — a publikálás-átmenetig).

A10 + A11 esetében **SF-63 jóváhagyás megmarad** (4-tag TabFilter), mert ott nincs manuális drag-drop sorrendezés: a hírek `publishedAt` szerint rendeződnek, az események `startsAt` szerint — természetes sorrend.

**Döntés-státusz · 2026.05.26:** **accepted** — `60_tartalom` §4.5.1 spec-szövege fenntartandó az A12 esetére; A10+A11 marad TabFilter-en. SF-63 felülbírálva az A12 vonatkozásában. **A12 mock-szinten már átvezetve.**

---

## SF-64 (update) — Lista-kebab és publish-bar dropdown vizuális mock-szinten elvetve

**Háttér.** Az SF-64 management-jóváhagyott (`confirmed`) tétele a `60_tartalom` §4.2.1+§4.2.2+§4.2.6 spec szerinti kebab-menü + Publikálás-dropdown UX-mintáját az Angular-portoláskor implementálandóként rögzítette. Az Iter 6e-3-ban (vizuális mock-átadás) a management úgy döntött, hogy ezt a UX-mintát **a screen-mockokon NEM jeleníti meg**.

**Indoklás.** A kebab + dropdown UX-minta funkcionálisan implementálható az Angular-portoláskor (PrimeNG `p-menu`-ekvivalens overlay-jel). A mock-szintű vizuális demonstrációhoz a 9 új artboard (3 lista × 3 állapot) + ContentEditor publish-bar dropdown jelentős szerkesztési munkát igényelne, és ez az UX-minta **eddig a Tartalom-ág többi screen-mockján is csak részben volt látható**. A spec-szerződés egyértelmű, a fejlesztő-csapat tudja, hogy a kebab + dropdown a P0 fix-tételek között szerepel.

**Hatás.**
- A 3 lista-mock (`a10-hirek-lista.html`, `a11-programok-lista.html`, `a12-cityinfo-lista.html`) `DataTable.columns` NEM kap `actions`-oszlopot.
- A `ContentEditor.publish-bar` mock-szinten a D-17 szerinti 3-gomb-os elrendezés marad (Eldobás / Mentés / Publikálás).
- A HANDOFF.md "P0 fix-tételek a portoláskor" szekciója **kötelezően** szállítja a §4.2.1+§4.2.2+§4.2.6 spec-szerződést a fejlesztő-csapatnak.

**Döntés-státusz · 2026.05.26:** **accepted** (spec marad változatlan) — vizuális mock-mintát NEM kapunk, a fejlesztő a spec szerint implementál.

---

# Záró összegzés

**Σ 39 SF-tétel, 4 szekcióban:**

| Szekció | Tételek | Prioritás |
|---|---|---|
| 1 — P0 KRITIKUS | 12 (SF-7, SF-12, SF-29, SF-30, SF-62, SF-63, SF-64, SF-79, SF-86, SF-87, SF-88, SF-89) | **Sürgős** |
| 2 — Érdemi spec-bővítések | 10 (SF-2, SF-16, SF-17, SF-43, SF-52, SF-59(b), SF-61, SF-21(a), SF-25(b), SF-58) | Pilot-átadás előtt |
| 3 — Spec-szelídítések | 13 (SF-9, SF-23, SF-37, SF-38, SF-42, SF-44, SF-71, SF-75, SF-76, SF-82, SF-83, SF-84, SF-93) | Pilot-átadás után is OK |
| 4 — Háttér / minor | 4 (SF-19, SF-48, SF-49, SF-95) | Phase 2 is OK |

A `manager-system/DECISIONS.md` D-18..D-20 belső döntései (PhoneBanner / Self-aware "Te" chip / A11 TimeCell proximity) a fenti listában a megfelelő SF-tételeken keresztül jelölve (SF-9 / SF-51 / SF-83). A spec-csapat válaszait a HANDOFF.md "nyitott spec-kérdés-jegyzék" szekciója fogadja.

*v0.2 — Section 3 (13 spec-szelídítés) + Section 4 (4 háttér) hozzáfűzve, záró összegzés frissítve · 2026.05.26 · Urbino Manager UI-csapat*