# Lezárás-fotó (`ResolutionPhoto`)

> **Modul:** `20_admin_felulet` · **Fájl:** `40_lezaras_foto.md`
> **Verzió:** 1.0 · **Dátum:** 2026.07.03
> **Státusz:** Első kiadás (MVP) — a 0–2. lépés (D1–D6) jóváhagyva.

---

## 0. Funkcionális alap

**Fedő funkcionális/spec dokumentumok:**
- `02_globalis_allapotgep.md` **3.4** (`InProgress → Resolved` lezárás-átmenet), **5.2** (a lezárás-dokumentáció előfeltétele: „legalább egy `ResolutionPhoto` **vagy** kitöltött `resolutionNote`").
- `20_admin_felulet/10_bejelentes_lista_es_adatlap.md` **3.3** (`resolve` végpont), **4.2 / 8.4** (a `ResolutionPhoto` termék-iránya, `TicketDto.attachments` `kind`-szétválasztása), **AC-E5/E6, AC-H2** (a lezárás-fotós forgatókönyvek acceptance criteria-i már megvannak).
- `00_domain_model.md` **1.3** — az `Attachment` entitás **definiált** (SD-15), itt **implementálódik** a `ResolutionPhoto`-ágra.
- `polgari_webes_funnel_v2.md` (VP-3 / „Így oldottuk meg") és **NY-bej-3** — a polgári „Megoldott" nézet lezárás-fotó igénye.

**Érintett kanonikus döntések:** K-016 (MVP-fegyelem — a fotó-feltöltés eddig iterációs volt; ez a feature a `ResolutionPhoto`-részt emeli be), K-028 (a felhasználói ügy-objektum a „bejelentés").

**Amit a réteg már eldöntött (hivatkozás, nem ismétlés):**
- Az `Attachment` modell (mezők, `AttachmentKind`, S3-`fileRef`) — SD-15, `00_domain_model.md` 1.3.
- A lezárás-előfeltétel „fotó vagy szöveg" szabálya — `02_globalis_allapotgep.md` 5.2.
- A `resolve` végpont szerződése és a `422`-előfeltétel — `10_bejelentes_lista_es_adatlap.md` 3.3.
- A `TicketDto.attachments` `kind` szerinti szétválasztása — `10_bejelentes_lista_es_adatlap.md` 8.4.
- A megépített feltöltő-infra (`TenantFileService` orphan/attach/GC, `StorageService` scope-first útvonal) — a manager rendszer kész része; lásd `99_dev_spec_elteresek.md` A10–A11 és a Storage-szakasz.

**Amit EZ a specifikáció tölt ki (a fejlesztői mélység):** az `Attachment` entitás implementációja a `ResolutionPhoto`-ágra; a lezárás-fotó feltöltő/törlő végpontja a meglévő storage-infrán; a `resolve` valódi 5.2-validációjának visszaállítása (a „szöveg mindig kötelező" ideiglenes állapot megszüntetése — a `99_dev_spec_elteresek.md` 3. döntésének lezárása); a manager-felület fotó-feltöltése a lezárás-akcióban; és a `ResolutionPhoto` polgári **adatszerződése**.

**Az SD-15 nyitott pontja itt záródik:** „A feltöltési flow (presigned URL, tömörítés, méretkorlát) a bejelentés-feltöltés feature-spec dolga" — a `ResolutionPhoto`-részre ez az a spec.

---

## 1. Cél és hatókör

A diszpécser/terepi felelős a bejelentés lezárásakor **fotóval** dokumentálhatja az elvégzett munkát („Így oldottuk meg"). Ezzel a lezárás-dokumentáció a valódi `5.2`-szabály szerint működik — **fotó vagy szöveg**, nem „mindig szöveg" —, és a polgár a mobilappban látja a lezárás-fotót (Mária „Wow #9", NY-bej-3). Üzleti érték: hiteles, vizuális lezárás-bizonyíték a polgárnak (bizalom), a városnak pedig auditálható munka-dokumentáció.

**Hatókörön kívül (ennél a feature-nél):**
- `ReportPhoto`-feltöltés a nyitóűrlapon (IT-MN-1) és a polgári oldalon — külön feature.
- A polgári „Megoldott" Flutter-**képernyő** tényleges megjelenítése (NY-bej-3 — a polgári mobilapp funkcionális tervezése). Ez a feature a **adatot** adja, a képernyőt nem.
- Galéria-finomságok: feliratok, kézi átrendezés (a `sortOrder`-en túl), képszerkesztés, thumbnail-generálás.
- Nem-kép dokumentum-csatolmány (az `Attachment` `contentType` később engedi; MVP: csak kép).
- A polgár által látott lezárás-**szöveg** (`resolutionNote` vs. külön `resolutionMessage`, VP-3) — szöveg-mező kérdés, a polgári spec dolga (lásd NY-LF-2).

---

## 2. Domain-modell

### 2.1 `Attachment` — implementáció (nincs új entitás)

Az `Attachment` entitás a `00_domain_model.md` 1.3-ban **már definiált** (Tenant DB, `AuditableEntity`, SD-15). Ez a feature **implementálja** a `ResolutionPhoto`-ágra. A mezők változatlanok; három mezőnek a domain-modell **nem rögzített méretet** — ezeket a spec a domain-modellbe visszavezeti (lásd 2.3).

| Mező | Típus | Köt. | Megjegyzés |
|---|---|---|---|
| `id` | `long` (PK) | K | — |
| `ticketId` | `FK → Ticket` | K | A bejelentés al-erőforrása |
| `kind` | `enum AttachmentKind` | K | Itt mindig `ResolutionPhoto`; a `ReportPhoto`-ág IT-MN-1 |
| `fileRef` | `string(512)` | K | S3-objektum-hivatkozás — a fájl nem a DB-ben (SD-15). **Méret visszavezetve, lásd 2.3** |
| `fileName` | `string(255)` | O | Eredeti fájlnév megjelenítéshez. **Méret visszavezetve** |
| `contentType` | `string(100)` | O | MIME (`image/jpeg`\|`image/png`\|`image/webp`). **Méret visszavezetve** |
| `sortOrder` | `int` | O | Galéria-sorrend; MVP-ben a feltöltés sorrendje (auto-inkrement, nincs kézi átrendezés) |

Az `AuditableEntity`-ből: `CreatedAt`/`CreatedBy` = a feltöltés ideje és a feltöltő `TenantUser` (nincs külön `uploadedBy` mező).

**`AttachmentKind` enum** (`00_domain_model.md` 1.4, SD-15): `ReportPhoto`, `ResolutionPhoto` — változatlan.

### 2.2 Kapcsolat és állapotgép-érintettség

- `Ticket ||--o{ Attachment` (egy bejelentéshez több csatolmány) — `00_domain_model.md` 1.4-ben már rögzített.
- **Nincs új státusz és nincs új átmenet.** A feature a meglévő `InProgress → Resolved` átmenet (`02_globalis_allapotgep.md` 3.4) **előfeltételét** teszi valóssá (5.2). A `ResolutionPhoto` feltöltése/törlése **nem** állapot-átmenet és **nem** generál `ActivityLog`-eseményt (a kurátorált napló elve, SD-79/SD-80 vezérelvével konzisztens) — a lezárás maga a meglévő `StatusChanged`-eseményt írja (3.4).

### 2.3 Domain-modell visszavezetés (kötelező, a sablon szerint)

A `00_domain_model.md` 1.3 `Attachment`-táblájába az alábbi méretek vezetendők vissza (jelenleg hiányoznak, és nem hagyhatók a Claude Code-ra):

| Mező | Rögzítendő méret | Analógia |
|---|---|---|
| `fileRef` | `string`, max **512** | `pdfFileRef` (512), `logoFileRef` (500) — SD-15-konzisztens |
| `fileName` | `string`, max **255** | szokásos fájlnév-korlát |
| `contentType` | `string`, max **100** | `CityInfo.groupLabel` (100) mintája |

> Ezt a három sort külön kis domain-modell-patch vezeti vissza (a `CHANGESET`-mintában), az `Attachment` „implementált" státuszának jelölésével együtt.

---

## 3. Szerver — API és logika

**Eltérés a mintától:** az `Attachment` **nem** `BaseController`-CRUD-ként érhető el a kliensnek, hanem a `Ticket` **al-erőforrásaként**, két célzott végponton (feltöltés multipart, törlés). Indok: (1) a feltöltés bináris/multipart, nem standard JSON-create; (2) a jogosultság és az állapot-guard a `Ticket`-hez kötött (nem-végállapot), nem az `Attachment`-hez; (3) az olvasás a `TicketDto.attachments`-en át történik (10_ 8.4), nem külön list-végponton.

### 3.1 Feltöltő végpont

```
POST /v1/tickets/{ticketId}/resolution-photos      (multipart/form-data: file)
→ 201 + AttachmentDto
```
- **Szerepkör:** `tenant_dispatcher`, `tenant_manager`, `tenant_field_worker` (azonos a `resolve`-val, `02_globalis_allapotgep.md` 3.4).
- **Logika:** a `StorageService`-en tárol (`storage://tenant/<tenantCode>/tickets/<ticketId>/<uuid>.ext`, a dev-napló Storage-konvenciója szerint), majd létrehoz egy `Attachment`-sort (`kind = ResolutionPhoto`, `fileRef`, `fileName`, `contentType`, `sortOrder = max(sortOrder)+1 az ügyön`). **Nincs orphan-ablak:** a `Ticket` már létezik, így az `Attachment` azonnal ticket-hez kötve jön létre; a 2 órás GC-re itt nincs szükség (eltér a borítókép-esettől, ahol az entitás még nem létezett).
- **Válasz `AttachmentDto`:** lásd 3.4.

### 3.2 Törlő végpont

```
DELETE /v1/tickets/{ticketId}/resolution-photos/{attachmentId}
→ 204
```
- **Szerepkör:** ua. három szerep.
- **Logika:** törli az `Attachment`-sort **és** a fizikai fájlt a `StorageService`-en.

### 3.3 `resolve` — változatlan szerződés, visszaállított validáció

**Eltérés a mintától — visszavonás:** a `POST /v1/tickets/{id}/resolve` **szerződése változatlan** (`{ resolutionNote?, expectedUpdatedAt }` → `200 + TicketDto`, `10_bejelentes_lista_es_adatlap.md` 3.3). A `99_dev_spec_elteresek.md` 3. döntése szerinti ideiglenes „szöveg mindig kötelező" megkötés **megszűnik**; a validáció visszaáll a valódi 5.2-re:

> `422`, ha **nincs** legalább egy `ResolutionPhoto` típusú `Attachment` az ügyön **és** a `resolutionNote` üres. (`02_globalis_allapotgep.md` 5.2)

### 3.4 `AttachmentDto` (manager)

| Mező | Típus | Megjegyzés |
|---|---|---|
| `id` | `long` | — |
| `kind` | `string` | `"ResolutionPhoto"` |
| `fileName` | `string?` | megjelenítéshez |
| `contentType` | `string?` | MIME |
| `sortOrder` | `int` | galéria-sorrend |
| `url` | `string` | **idő-korlátos presigned GET URL** a `StorageService`-től (a logó/borítókép GET-mintája, SD-60) |
| `createdAt` | `DateTime` | feltöltés ideje (`AuditableEntity`) |
| `createdBy` | `string` | a feltöltő (csak a manager DTO-ban; a polgári projekció ezt nem tartalmazza) |

### 3.5 Validáció (FluentValidation) — teljes szabálykészlet

**Feltöltés (`POST .../resolution-photos`):**
- `file` — **kötelező**; ha hiányzik → `422 fieldErrors.file.required`.
- `file` MIME — `image/jpeg` \| `image/png` \| `image/webp`; egyéb → `422 fieldErrors.file.invalidType` (a `01_kozos_mintak` i18n-elve: a szerver kódot ad).
- `file` méret — max **10 MB**; nagyobb → `422 fieldErrors.file.tooLarge`.
- `ticket` létezés — `404`, ha nincs ilyen `ticketId`.
- `ticket` állapot — **nem-végállapot** (`status ∉ {Resolved, Rejected}`); végállapotban → `409 { reason: "invalid_state" }` (az SD-26 „végállapotban nincs módosítás" mintája — előbb korrekciós visszanyitás).
- darabszám — max **10** `ResolutionPhoto` ügyenként; a 11. → `422 fieldErrors.file.tooMany`.

**Lezárás (`POST .../resolve`) — a meglévő szabályok + a visszaállított előfeltétel:**
- `resolutionNote` — opcionális; ha kitöltött, max **2000** (`10_` 3.3 / `00_domain_model.md`).
- előfeltétel — legalább egy `ResolutionPhoto` **vagy** `resolutionNote` kitöltött; egyik sem → `422` (5.2). `409`, ha stale (`expectedUpdatedAt`) vagy nem-`InProgress` (invalid_transition).

**Törlés (`DELETE .../resolution-photos/{id}`):**
- az `attachmentId` létezik és a `ticketId`-hez tartozik → különben `404`.
- `ticket` állapot nem-végállapot → különben `409 { reason: "invalid_state" }`.

### 3.6 Jogosultság — `authorization.json`

A `10_bejelentes_lista_es_adatlap.md` 3.6 `resolve`-sorával azonos szerepkör-készlet. Új bejegyzések:
```json
{ "method": "POST",   "path": "/v1/tickets/{ticketId}/resolution-photos",               "roles": ["tenant_dispatcher","tenant_manager","tenant_field_worker"] },
{ "method": "DELETE", "path": "/v1/tickets/{ticketId}/resolution-photos/{attachmentId}", "roles": ["tenant_dispatcher","tenant_manager","tenant_field_worker"] }
```

### 3.7 Multi-tenancy

A `Ticket` al-erőforrásaként **azonos tenant-resolution**, mint a `/v1/tickets` végpontoknál (a platform meglévő modellje szerint — nem itt döntjük el). Az `Attachment` a **Tenant DB**-ben él (`00_domain_model.md` 1.3), a fizikai fájl tenant-szegmentált a `StorageService` konvenciójával (`storage://tenant/<tenantCode>/…`).

### 3.8 Audit és naplózás

**Eltérés a standard `AuditableEntity`-n túl: nincs.** A feltöltés/törlés **nem** ír `ActivityLog`-eseményt (a kurátorált napló elve). A lezárás a meglévő `StatusChanged`-eseményt írja (3.4). A ki/mikor a `CreatedAt`/`CreatedBy`-ból adott.

---

## 4. Admin felület

### 4.1 Érintett képernyők

- **Bejelentés-adatlap** (`10_bejelentes_lista_es_adatlap.md` 4.2; referencia: `manager_bejelentes_adatlap_20260630.png`) — a **„Lezárás" akció** dialógusa és a lezárt ügy **lezárás-dokumentáció** szekciója.

### 4.2 Lezárás-dialógus — fotó-feltöltés

**Eltérés a mintától:** nem `[validationForm]` standard űrlap, hanem a meglévő **borítókép-feltöltő UI-minta** (kép-preview + feltöltés + törlés gomb, Beállítások/Tartalom) újrahasznosítása a lezárás-dialógusban.

- A dialógus tartalma: **`resolutionNote` textarea** (opcionális, max 2000) **+ fotó-feltöltő terület** (több kép, thumbnail-preview, képenként törlés).
- Interakció: minden feltöltés → `POST .../resolution-photos` (azonnali preview a válasz `url`-jével); képenkénti törlés → `DELETE …`; a „Lezárás" gomb → `POST .../resolve` (a fotók ekkor már fel vannak töltve, D3).
- A „Lezárás" gomb **tiltott**, amíg nincs sem fotó, sem kitöltött jegyzet (kliens-oldali előjelzés az 5.2-re; a szerver a `422`-t is adja, SD-28 mintája).

### 4.3 Lezárt ügy — lezárás-dokumentáció megjelenítés

- A lezárt (`Resolved`) ügy adatlapján a `ResolutionPhoto`-k **galériaként** jelennek meg (a `TicketDto.attachments` `kind = ResolutionPhoto` csoportja, `sortOrder` szerint), a `resolutionNote` mellett.
- A `ReportPhoto`-csoport (polgári nyersanyag-fotók) külön galéria (`10_` 8.4) — adat MVP-ben csak akkor van, ha a polgári/nyitóűrlap-feltöltés (IT-MN-1) él; a megjelenítő rész felkészült, üresen üres-állapotot mutat.

### 4.4 Jogosultság

Feltöltés/törlés: `tenant_dispatcher`, `tenant_manager`, `tenant_field_worker` (hivatkozás: `05_jogosultsagok_v2.md` lezárás-akció). Olvasás (galéria): aki az adatlapot látja.

### 4.5 Üres / betöltési / hibaállapot

- **Üres:** nincs lezárás-fotó → a galéria-terület üres-állapota („Nincs lezárás-fotó").
- **Betöltési:** feltöltés folyamatban → per-kép progress/skeleton.
- **Hiba:** `422 file.invalidType` / `file.tooLarge` / `file.tooMany` → mezőszintű hibaüzenet a feltöltő alatt; `409 invalid_state` → nem-blokkoló jelzés + adatlap-frissítés.

### 4.6 i18n kulcsok (`hu.json`)

A felület tegez; a szerver kódot ad, a felület fordítja (`01_kozos_mintak.md`).
```
ticket.resolution.photo.upload           = "Fotó feltöltése"
ticket.resolution.photo.delete           = "Fotó törlése"
ticket.resolution.photo.empty            = "Nincs lezárás-fotó"
ticket.resolution.gallery.title          = "Lezárás-dokumentáció"
ticket.resolution.report.gallery.title   = "Bejelentői fotók"
ticket.error.file.required               = "Válassz ki egy fotót."
ticket.error.file.invalidType            = "Csak JPEG, PNG vagy WebP kép tölthető fel."
ticket.error.file.tooLarge               = "A fotó legfeljebb 10 MB lehet."
ticket.error.file.tooMany                = "Legfeljebb 10 fotó tölthető fel egy bejelentéshez."
ticket.error.state.invalidState          = "Lezárt bejelentéshez nem tölthető fel fotó — előbb nyisd újra."
```

---

## 5. Polgári mobilapp adatigénye

### 5.1 Érintett képernyő

- **Polgári bejelentés-adatlap**, a **„Megoldott" (`Resolved`) állapot** — a „Így oldottuk meg" szekció (VP-3, NY-bej-3). Referencia: `screen_bejelentes_adatlap_1.PNG`, `screen_bejelentes_adatlap_2.PNG`.

### 5.2 API — adatszerződés (csak olvasás)

A polgári bejelentés-detail végpont egy `Resolved` ügynél a `ResolutionPhoto`-kat visszaadja, `kind`-szűrve (`WHERE kind = 'ResolutionPhoto'`, `10_` 8.4). **Polgári projekció** (a manager-mezők nélkül):

| Mező | Típus | Megjegyzés |
|---|---|---|
| `url` | `string` | idő-korlátos presigned GET URL |
| `sortOrder` | `int` | galéria-sorrend |
| `contentType` | `string?` | MIME |

- **Adatáramlás:** kizárólag **olvasás** — a polgár lezárás-fotót nem tölt fel.
- **`Rejected` ügynél** nincs `ResolutionPhoto`-megjelenítés (5.2 értelmében ott nincs lezárás-fotó).

### 5.3 Adat-szintű nyitott kérdés

- **NY-LF-1 (megtartott hiány):** a polgári „Megoldott" képernyő **megjelenítése** (a galéria UX) a polgári mobilapp funkcionális tervezése (NY-bej-3). Ez a feature az **adatot** garantálja (`kind`-szűrt `ResolutionPhoto`, presigned `url`); a Flutter-képernyő és a polgári detail-végpont bekötése a polgári spec hatásköre.

---

## 6. Acceptance criteria

- **AC-1** — *Given* egy `InProgress` ügy; *When* a felelős egy `image/jpeg`-et tölt fel `POST .../resolution-photos`-szal; *Then* `201` + `AttachmentDto` (`kind = "ResolutionPhoto"`, nem-üres `url`), egy `Attachment`-sor jön létre, a fájl a storage-ban van.
- **AC-2** *(= 10_ AC-E6)* — *Given* egy `InProgress` ügy **legalább egy** `ResolutionPhoto`-val, `resolutionNote` nélkül; *When* `resolve`; *Then* `200`, `status = Resolved` (5.2 a fotóval teljesül).
- **AC-3** *(= 10_ AC-E5)* — *Given* egy `InProgress` ügy `resolutionNote`-tal, fotó nélkül; *When* `resolve`; *Then* `200`.
- **AC-4** — *Given* egy `InProgress` ügy fotó és `resolutionNote` nélkül; *When* `resolve`; *Then* `422` (5.2 sérül).
- **AC-5** — *When* nem-kép (pl. `application/pdf`) feltöltése; *Then* `422 fieldErrors.file.invalidType`, nem jön létre `Attachment`.
- **AC-6** — *When* 10 MB-nál nagyobb fájl; *Then* `422 fieldErrors.file.tooLarge`.
- **AC-7** — *Given* egy ügy 10 `ResolutionPhoto`-val; *When* a 11. feltöltése; *Then* `422 fieldErrors.file.tooMany`.
- **AC-8** — *Given* egy `Resolved` (vagy `Rejected`) ügy; *When* fotó-feltöltés; *Then* `409 { reason: "invalid_state" }`.
- **AC-9** — *Given* egy nem-végállapotú ügy egy `ResolutionPhoto`-val; *When* `DELETE .../resolution-photos/{id}`; *Then* `204`, az `Attachment`-sor és a fizikai fájl törlődik.
- **AC-10** — *Given* egy `Resolved` ügy egy `ResolutionPhoto`-val; *When* törlés; *Then* `409 { reason: "invalid_state" }`.
- **AC-11** — *Given* egy `Resolved` ügy `ResolutionPhoto`-val; *When* a polgári detail lekérés; *Then* a válasz a `ResolutionPhoto`-kat tartalmazza (`url`, `sortOrder`, `contentType`), `kind`-szűrve; `ReportPhoto` és belső mezők (pl. `createdBy`) **nélkül**.
- **AC-12** — *Given* egy fotóval lezárt (`Resolved`) ügy; *When* korrekciós visszanyitás (`Resolved → InProgress`); *Then* a `ResolutionPhoto`-k **megmaradnak** (D6), és a következő `resolve` a meglévő fotókkal `200`.
- **AC-13** — *When* fotó-feltöltés vagy -törlés; *Then* **nem** keletkezik `ActivityLog`-bejegyzés; a `resolve` a meglévő `StatusChanged`-et írja.

---

## 7. Keresztmetszeti

- **Biztonság:** a MIME/méret/darab-validáció **szerver-oldali** (nem csak kliens); a GET presigned URL **idő-korlátos**; a storage tenant-szegmentált (`StorageService`). A presigned URL lejárata a meglévő logó/borítókép-konfigurációt követi (fejlesztői érték).
- **Teljesítmény:** MVP-ben az **eredeti** kép szolgálódik ki (max 10 MB, max 10/ügy — elfogadható). **Thumbnail-generálás iterációs** (lásd 8.).
- **i18n / időzóna:** i18n a 4.6-ban; időzóna nem releváns (a `CreatedAt` a standard `AuditableEntity`-úton, tenant-időzónában jelenik meg — nincs feature-specifikus teendő).

---

## 8. Lezárás

### 8.1 Első kiadás (MVP)
- `Attachment` implementáció a `ResolutionPhoto`-ágra (a definiált 1.3-modellel).
- `POST`/`DELETE .../resolution-photos` végpontok a meglévő `StorageService`/`TenantFileService` infrán.
- A `resolve` valódi 5.2-validációjának visszaállítása (a „szöveg mindig kötelező" ideiglenes állapot megszüntetése).
- Manager: fotó-feltöltés a lezárás-dialógusban + lezárás-fotó galéria az adatlapon.
- Polgári: a `ResolutionPhoto` adatszerződése (`kind`-szűrt olvasás, presigned `url`).

### 8.2 Következő iterációk
- `ReportPhoto`-feltöltés a nyitóűrlapon (IT-MN-1) és a polgári oldalon.
- A polgári „Megoldott" Flutter-képernyő megjelenítése (NY-bej-3).
- Galéria-finomságok: kézi átrendezés, feliratok, képszerkesztés.
- Thumbnail-generálás / kép-optimalizáció.
- Nem-kép dokumentum-csatolmány (az `Attachment` `contentType`-on át).

### 8.3 Feltételezések
- A `TenantFileService` (orphan/attach/GC) és a `StorageService` (scope-first útvonal, presigned GET) a manager rendszerben megépített módon elérhető (`99_dev_spec_elteresek.md` A10–A11, Storage-szakasz).
- A polgári bejelentés-detail végpont létezik vagy a polgári spec biztosítja (NY-bej-3); ez a feature az adatszerződést garantálja.
- A multi-tenancy resolution a platform meglévő modelljét követi (a `/v1/tickets` al-erőforrásaként).

### 8.4 Nyitott kérdések és megtartott hiányok
- **NY-LF-1 (megtartott hiány):** a polgári „Megoldott" képernyő megjelenítése — a polgári mobilapp funkcionális tervezése (NY-bej-3). Adat kész, UI a polgári spec dolga.
- **NY-LF-2:** a polgár a belső `resolutionNote`-ot látja-e, vagy külön `resolutionMessage`-t (VP-3). Szöveg-mező kérdés — polgári spec; ez a feature nem nyitja meg, csak a fotóval foglalkozik.

### 8.5 Ez a feature lezárja / visszavezeti
- **Lezárja** a `99_dev_spec_elteresek.md` 3. döntésének megtartott hiányát (a `resolve` visszaáll az 5.2-re).
- **Visszavezeti** a `00_domain_model.md` 1.3-ba az `Attachment` „implementált" státuszát és a három mezőméretet (`fileRef` 512, `fileName` 255, `contentType` 100) — külön kis domain-modell-patch (a `CHANGESET`-mintában).

### 8.6 Hivatkozott dokumentumok
`02_globalis_allapotgep.md` (3.4, 5.2) · `20_admin_felulet/10_bejelentes_lista_es_adatlap.md` (3.3, 4.2, 8.4, AC-E5/E6, AC-H2) · `00_domain_model.md` (1.3, 1.4, SD-15) · `polgari_webes_funnel_v2.md` (VP-3) · `99_dev_spec_elteresek.md` (A10–A11, Storage, 3. döntés) · `05_jogosultsagok_v2.md` · `99_donesnaplo.md` (SD-15, SD-26, SD-60, SD-78) · a `project_backend` és `project_backend_client_angular` `CLAUDE.md`.