# REVIEW — átadás előtti felülvizsgálat

**Cél.** A 8. lépés (screen-mock-ok) lezárult, a 9. lépés (átadási csomag) előtt egy átfogó review-iteráción megyünk át. A review **két fázisra** bomlik:

- **Phase 1 — Átfogó review** (1 chat): dokumentációs frissítés, vizuális konzisztencia, handoff-prep
- **Phase 2 — Spec-fedés ágon** (4 chat, ág-szinten): mező-szinten ellenőrizzük, hogy minden spec-adatmodell-attribútum megjelenik-e a screen-mock-on, és fordítva: minden UI-elem megfeleltethető-e spec-adatmodellnek

**Forma.** Minden szakasz: mit nézünk · miért fontos · konkrét vizsgálandó dolgok · kimenet. A végén a **következő chat induló promptja** szó-szerinti formában.

---

# Phase 1 — Átfogó review (1 chat)

## 1.1 Dokumentációs konzisztencia

**Miért.** A `DECISIONS.md` D-1..D-12-ig terjed, de a 8. lépés során 4 új cross-cutting döntést hoztunk:
- **D-13** — Settings-nav Pattern N (LeftNav 4 leaf, SettingsSubNav elhagyva) — S6.5
- **D-14** — DateTimeRangePicker két-input minta (Pattern A) — S13
- **D-15** — A4 Dashboard spec-konform újraépítés (S9 revízió: delta törölve, hét-váltó törölve, WeeklyReportCard kivéve, „Heti riport letöltése" CTA fejlécben, Terepi csapat-teljesítmény elnevezés, isTopPerformer jelölés)
- **D-16** — ContentEditor publish-bar gomb-sorrend ([Eldobás] balra · [Vázlat-mentés][Publikálás] jobbra) — S12 finomítás

Az `ORGANISMS.md` 9 új organism-mel bővült (`tab-filter`, `publish-state-chip`, `photo-gallery`, `photo-uploader`, `rich-text-editor`, `cover-image-uploader`, `content-editor`, `date-time-range-picker`, `link-validator`) — ezek API-leírása hiányzik.

A `SITEMAP.md` használat-mátrixa a fenti organism-eket még nem tartalmazza.

**Konkrétan vizsgálandó.**
- Minden D-13..D-16 bejegyzés rögzítése a `DECISIONS.md`-ben
- `ORGANISMS.md` 9 új organism-bejegyzés (props-API, DS-deps, variációk)
- `SITEMAP.md` használat-mátrix frissítése
- `ORGANISMS.md` Tier-besorolás revízió (`KpiCard`, `MapWidget`, `LocationPicker`, új organism-ek)

**Kimenet.** Frissített `DECISIONS.md`, `ORGANISMS.md`, `SITEMAP.md`.

## 1.2 AUDIT-2.md

**Miért.** A meglévő `AUDIT.md` 2026.05.22-i, screen-fázis előtti. Új audit a fejlesztő szempontjából rögzíti a jelenlegi állapotot.

**Konkrétan vizsgálandó.**
- CSS-cruft: az `_styles.css` ~5500 sor; van-e nem használt szabály (pl. eredeti DTP-B kettős-naptár-stílusok)?
- Organism-katalógus integritása: minden organism-fájl exportál `window.X`-et? Van-e egyetlen screen sem fogyasztja?
- Mock-decentralizáció: a `mock.js` központi mock-ja kevés, a screen-fájlok mind saját inline mock-ot definiálnak
- Cross-screen layout-konzisztencia: 27 screen-fájl renderelődik tisztán?

**Kimenet.** `AUDIT-2.md`.

## 1.3 Vizuális konzisztencia-sweep

**Miért.** Minden screen-fájl saját CSS-szabályokat is hoz (`a1-page`, `a8-cta`, `a10-thumb` stb), és sokszor ismétlődő mintákat újra-deklarálnak.

**Konkrétan vizsgálandó.**
- Screen-header sablon: mind a 27 fájl egyezik-e?
- CSS link-tag-sorrend: az A10-eset (kimaradt `tabs.css`) tanulság — egyetlen include-konvenció kellene
- PageHeader title-méret konzisztencia screen-ek között
- Per-state magasság-konstansok (`H_DEFAULT`, `H_FIRST` stb)
- Ad-hoc CSS-override-ek (`.a1-page > * + *` és társai) — összevonhatóak?

**Kimenet.** `SCREEN-CONVENTIONS.md` + szükséges screen-fájl finomítások.

## 1.4 Handoff-prep

**Miért.** Mielőtt a `HANDOFF.md`-t megírjuk, néhány kérdést kell tisztáznunk.

**Konkrétan vizsgálandó.**
- PrimeNG-komponens mappelés organism-enként
- Az organism-réteg végleges szállítása (TS-organism-ek vs HTML-mock?)
- Mock-adatok átadásának módja
- `_styles.css` Angular-projekt SCSS-be vs CSS-modulba
- DS-réteg (`design-system/`) kapcsolódása (read-only, NPM, inline)

**Kimenet.** `HANDOFF-PREP.md`.

---

# Phase 2 — Spec-fedés ágon (4 chat)

**Fontos.** Minden Phase 2 chat **két passt** végez:

1. **Forward pass — spec → screen.** Végigmegyek a spec-adatmodell-attribútumokon (pl. `Ticket.citizenSuggestedCategoryId`, `Group.members[].roleSnapshot`): minden mező megjelenik-e a megfelelő screen-mock-on? Ha nem, miért és van-e szerepe a felhasználói flow-ban?
2. **Backward pass — screen → spec.** Végigmegyek a screen-mock UI-elemein (pl. az A4 dashboard greeting + summary, az A8 „Te" chip, az A12 LinkValidator favicon): minden elem megfeleltethető-e spec-adatmodellnek? Ha nem, az UI találmány — döntés: spec-be visszacsatolás, vagy törlés?

**Output formátum.** Minden chat egy `SPEC-COVERAGE-<ag>.md` fájlt szállít, amely 3 listát rögzít:
- ✅ **Spec-ben + screen-en is megvan** — semmi teendő
- ⚠ **Spec-ben van, screen-en nincs** — hiányosság, döntés: kihagyott (miért?) vagy javítandó
- 🔍 **Screen-en van, spec-ben nincs** — UI-találmány, döntés: visszacsatolás (új SD-X) vagy törlés

A kimenet egy konkrét cleanup-listát ad a 9. lépésig.

## Phase 2A — Bejelentés-ág (A1+A2+A3)

A legkomplexebb ág. A `Ticket` entitás ~25 attribútumos, plus `TicketNote` + `TicketActivityLog` + `SimilarTicket`.

**Vizsgálandó screen-ek.**
- `a1-bejelentes-lista.html` (5 state)
- `a1-bejelentes-lista-mobile.html` (4 state)
- `a1-bejelentes-adatlap.html` (4 state — Folyamatban / Új / Megoldva / Elutasítva)
- `a2-uj-bejelentes.html` (4 state)

**Forrás spec-fájlok.**
- `00_domain_model.md` §1.1-1.5 (Ticket + TicketNote + TicketActivityLog + SimilarTicket + Photo)
- `10_bejelentes_lista_es_adatlap.md` (teljes)
- `20_duplikacio_es_osszevonas.md` (teljes)
- `02_globalis_allapotgep.md` §1-4 (Ticket-állapotgép)
- `00_architektura_v4.md` §6.1 (manuális nyitás)

## Phase 2B — Riport-ág (A4+A5)

**Vizsgálandó screen-ek.**
- `a4-fooldal.html` (3 state — Normál / Healthy / First-time)
- `a5-riportok-lista.html` (3 state)
- `a5-riportok-adatlap.html` (4 state)

**Forrás spec-fájlok.**
- `00_domain_model.md` §3 (WeeklyReport entitás)
- `40_riport.md` (teljes)

## Phase 2C — Beállítás-ág (A6+A7+A8+A9)

**Vizsgálandó screen-ek.**
- `a6-beallitasok-kategoriak.html` (4 state)
- `a7-beallitasok-csoportok-lista.html` (3 state)
- `a7-beallitasok-csoportok-adatlap.html` (4 state)
- `a8-beallitasok-felhasznalok-lista.html` (4 state)
- `a8-beallitasok-felhasznalok-adatlap.html` (5 state)
- `a9-beallitasok-altalanos.html` (4 state)

**Forrás spec-fájlok.**
- `00_domain_model.md` §2 (Tenant + Category + Group + TenantUser)
- `30_beallitasok.md` (teljes)
- `20_felhasznalokezeles.md` (teljes)

## Phase 2D — Tartalom-ág (A10+A11+A12)

**Vizsgálandó screen-ek.**
- `a10-hirek-lista.html` (3 state)
- `a10-hirek-szerkeszto.html` (4 state)
- `a11-programok-lista.html` (3 state)
- `a11-programok-szerkeszto.html` (4 state)
- `a12-cityinfo-lista.html` (3 state)
- `a12-cityinfo-szerkeszto.html` (4 state)

**Forrás spec-fájlok.**
- `00_domain_model.md` §4 (News + Event + CityInfo)
- `60_tartalom.md` (teljes)

---

# Phase 3 — Átadási csomag (1 chat)

Az 5 review-fájl (DECISIONS+ORGANISMS+SITEMAP update, AUDIT-2, SCREEN-CONVENTIONS, SPEC-FEEDBACK kiegészítve a 4 SPEC-COVERAGE-X.md output-okkal, HANDOFF-PREP) ismeretében jön a végleges:
- `HANDOFF.md` — fejlesztő-átadás teljes dokumentum
- `starter/` — mini-Angular projekt (PrimeNG Aura + Tailwind v4, 1-2 demó-screennel)

---

# Konkrét teendő — chat-by-chat

Az alábbiak szó-szerinti induló promptok. Mindegyiket másold be egy új chat **első üzenetébe**, és kezdődhet a munka.

## Chat 1 — Phase 1 (átfogó review)

```
Folytatjuk az Urbino Manager projektet. A 8. lépés (screen-mock-ok)
lezárult, ez a Phase 1 átfogó review — a 9. lépés (átadási csomag) előtti
felülvizsgálat.

Olvasd el ebben a sorrendben:
1. REVIEW.md — a review-iter teljes terve, a Phase 1 szakaszai 1.1–1.4
2. Urbino Manager.html — a projekt hubja, jelen állapot
3. AUDIT.md — a 2026.05.22-i pre-screen-fázis audit
4. manager-system/DECISIONS.md (D-1..D-12)
5. manager-system/ORGANISMS.md
6. manager-system/SITEMAP.md
7. Az új organism-fájlok a manager-system/organisms/-ban:
   tab-filter.jsx, publish-state-chip.jsx, photo-gallery.jsx,
   photo-uploader.jsx, rich-text-editor.jsx,
   cover-image-uploader.jsx, content-editor.jsx,
   date-time-range-picker.jsx, link-validator.jsx

A 8. lépés során 4 új cross-cutting döntés keletkezett, amelyek még
NINCSENEK a DECISIONS.md-ben:
- D-13 — Settings-nav Pattern N (S6.5 explorer alapján)
- D-14 — DateTimeRangePicker két-input minta (S13 explorer)
- D-15 — A4 Dashboard spec-konform újraépítés
- D-16 — ContentEditor publish-bar gomb-sorrend

Working-mode (változatlan):
- 3-rétegű architektúra (DS → manager-system → app)
- spec-prioritás (csak amit uploads/urbino-docs/ mond)
- small-iteration, max 2-3 task/iter
- minden output egy fájlba megy (DECISIONS+ORGANISMS+SITEMAP frissítés,
  AUDIT-2.md, SCREEN-CONVENTIONS.md, HANDOFF-PREP.md)

Kezdj egy javasolt iter-sorrenddel (1.1 → 1.2 → 1.3 → 1.4 vagy más),
és várj jóváhagyásra mielőtt belekezdesz egy szakaszba.
```

## Chat 2 — Phase 2A (Bejelentés-ág spec-fedés) — v2 (Phase 1 tanulságai alapján)

```
Az Urbino Manager Phase 1 (átfogó review) lezárult. Most a Phase 2A
spec-fedés review következik a Bejelentés-ágra (A1+A2+A3).

Olvasd el ebben a sorrendben:
1. REVIEW.md — Phase 2 szekció + a Phase 1 tanulság-szakasz (a 4. lista 🟡
   kategória + új output-formátum)
2. uploads/urbino-docs/00_domain_model.md §1.1-1.5 (Ticket + TicketNote +
   TicketActivityLog + SimilarTicket + Photo entitás)
3. uploads/urbino-docs/20_admin_felulet/10_bejelentes_lista_es_adatlap.md
   (teljes)
4. uploads/urbino-docs/20_admin_felulet/20_duplikacio_es_osszevonas.md
   (teljes)
5. uploads/urbino-docs/02_globalis_allapotgep.md §1-4 (Ticket-állapotgép)
6. uploads/urbino-docs/00_architektura_v4.md §6.1 (manuális nyitás)

Kötelező kontextus-input (a Phase 1 négy új dokumentuma):
7. manager-system/DECISIONS.md — különösen D-4..D-7 (bejelentés-ági
   döntések) és D-13 (DataTable contract-bővítés)
8. manager-system/ORGANISMS.md — a kanonikus organism-API-k
9. manager-system/SITEMAP.md — használat-mátrix (frissített)
10. AUDIT-2.md — különösen 3.3 (inline-organism-pótlás jegyzék — A5/A7/A8;
    a Bejelentés-ág NEM érintett, de a metodológia ismerete fontos)
11. SCREEN-CONVENTIONS.md — a mock-doksi-réteg azonosítására (screen-header,
    DesignCanvas, DCArtboard mind mock-only, NEM spec-modellbe kellő elemek
    — a backward-pass-on ezeket eleve ki kell zárni)

A screen-mock-ok:
   - manager-system/preview/screens/a1-bejelentes-lista.html
   - manager-system/preview/screens/a1-bejelentes-lista-mobile.html
     (A1 mobil-vetület — közös fedés az A1-listával, a mobil eltérések
     külön altáblában)
   - manager-system/preview/screens/a1-bejelentes-adatlap.html
   - manager-system/preview/screens/a2-uj-bejelentes.html

Két passt végzünk:

(1) FORWARD pass — spec → screen.
Végigmegyünk a Ticket/TicketNote/TicketActivityLog/SimilarTicket spec-
adatmodell-attribútumain, mező-szinten. Minden attribútum (pl.
Ticket.citizenSuggestedCategoryId, Ticket.assignedGroupId,
TicketNote.isInternal, ...) megjelenik-e a megfelelő screen-mock-on?
Ha nem, miért és van-e szerepe?

(2) BACKWARD pass — screen → spec.
Végigmegyünk a screen-mock UI-elemein. Minden UI-elem (pl. „Te" chip,
„közelgő-vs-lezajlott" tab, SimilarTicketsBox amber findings-fejléc)
megfeleltethető-e:
  - spec-adatmodellnek (→ ✅),
  - egy D-X / SD-X döntésnek (→ 🟡),
  - vagy egyiknek sem (→ 🔍 UI-találmány)?

A mock-doksi-réteg elemeit (screen-header, DesignCanvas, DCArtboard label,
State<X> komponens) a backward-pass-on KIZÁRD — ezek SCREEN-CONVENTIONS.md
szerint csak mock-only, NEM kerülnek Angularra.

Output: SPEC-COVERAGE-A1A2A3.md fájl, 4 listával (Phase 1 nyomán
bővített):
- ✅ Spec-ben + screen-en megvan — semmi teendő
- ⚠ Spec-ben van, screen-en nincs — hiányosság (döntés: kihagyott vagy javítandó)
- 🟡 Screen-en van, spec-ben nincs, DE D-X döntés rögzíti — dokumentált
  UX-választás, NEM UI-találmány, NEM spec-szelídítés (a D-X hivatkozás
  kötelező)
- 🔍 Screen-en van, spec-ben nincs, NEM dokumentált — UI-találmány
  (döntés: spec-be visszacsatolás SPEC-FEEDBACK.md-be, vagy törlés)

A ⚠ és 🔍 (NEM 🟡!) tételek külön SPEC-FEEDBACK.md fájlt is megnyitnak
— ezt az ági-fejezetét hozd létre (## A1+A2+A3 spec-szelídítések), a
Phase 3 ezt konszolidálja.

Kezdj egy javasolt forward-pass listával (mely Ticket-attribútumokat
fogod ellenőrizni elsőként), és várj jóváhagyásra.
```

## Chat 3 — Phase 2B (Riport-ág spec-fedés) — v2

```
Az Urbino Manager Phase 1 + Phase 2A lezárult. Most a Phase 2B spec-fedés
review következik a Riport-ágra (A4 Dashboard + A5 Heti PDF-riport).

Olvasd el:
1. REVIEW.md — Phase 2 szekció + Phase 1 tanulság-szakasz
2. uploads/urbino-docs/00_domain_model.md §3 (WeeklyReport entitás)
3. uploads/urbino-docs/20_admin_felulet/40_riport.md (teljes)

Kötelező kontextus-input:
4. manager-system/DECISIONS.md — különösen D-12 (Dashboard eredeti) +
   D-16 (Dashboard spec-konform újraépítés — kritikus tudni: a delta
   törölve, hét-választó törölve, inline WeeklyReportCard törölve, „Heti
   riport letöltése" CTA a fejlécbe, „Terepi csapat-teljesítmény"
   elnevezés, isTopPerformer jelölés)
5. manager-system/ORGANISMS.md — kanonikus organism-API, különösen a
   KpiCard (delta deprecated) + WeeklyReportCard + TeamPerformanceTable
   (isTopPerformer mező)
6. AUDIT-2.md — különösen 3.3 (inline-organism-pótlás jegyzék):
   *** A5 RIPORT-ADATLAP `RecipientsCard` INLINE-PÓTLÁS ***
   A screen-mock egy inline `RecipientsCard` komponenst használ
   (a5-riportok-adatlap.html:382-407) a kanonikus `WeeklyReportCard +
   RecipientList` helyett. A backward-pass-on NEM tekintjük UI-találmánynak
   — meglévő organism létezik, a screen-mock inline-pótolja. A HANDOFF.md-
   ben átadási megjegyzésként szerepel.
7. SCREEN-CONVENTIONS.md — mock-doksi-réteg azonosítása

A screen-mock-ok:
   - manager-system/preview/screens/a4-fooldal.html (3 state)
   - manager-system/preview/screens/a5-riportok-lista.html (3 state)
   - manager-system/preview/screens/a5-riportok-adatlap.html (4 state)

Working-mode + output ugyanaz mint Phase 2A: forward-pass + backward-pass
→ SPEC-COVERAGE-A4A5.md fájl 4 listával (✅ ⚠ 🟡 🔍) + a SPEC-FEEDBACK.md-
be ## A4+A5 spec-szelídítések ági-fejezet.

Különös figyelem:
— Az A4 4 KPI-ja (Nyitott / Aznapi új / Késésben / Aznap lezárt)
  megegyezik-e a 40_riport.md §4.2 listájával? A backward-pass-on a
  „greeting" + „summary" + „hét-eyebrow" bevezetése valószínűleg UI-
  találmány (D-16 NEM rögzíti); itt 🔍-be kerül vagy explicit törlés
  javaslandó.
— Az A5 inline-pótlás NEM számít UI-találmánynak — l. AUDIT-2 fenti
  hivatkozás.
— Az A4 „Heti riport letöltése" CTA-elhelyezése a 40_riport §4.2 alapján
  spec-rögzített vagy D-16 nyom: ha spec rögzíti → ✅, ha csak D-16 → 🟡.

Kezdj javasolt vizsgálati-sorrenddel.
```

## Chat 4 — Phase 2C (Beállítás-ág spec-fedés) — v2

```
Az Urbino Manager Phase 1 + Phase 2A-B lezárult. Most a Phase 2C spec-
fedés review következik a Beállítás-ágra (A6 + A7 + A8 + A9).

Olvasd el:
1. REVIEW.md — Phase 2 szekció + Phase 1 tanulság-szakasz
2. uploads/urbino-docs/00_domain_model.md §2 (Tenant + Category + Group
   + TenantUser entitások)
3. uploads/urbino-docs/20_admin_felulet/30_beallitasok.md (teljes)
4. uploads/urbino-docs/20_admin_felulet/20_felhasznalokezeles.md (teljes)

Kötelező kontextus-input:
5. manager-system/DECISIONS.md — különösen D-8..D-11 (beállítás-ági iter)
   + D-14 (Settings-nav Pattern N — SettingsSubNav elhagyva, a spec
   30_beallitasok §4.1 tab-szerű sub-nav-ot ír; ez SPEC-FEEDBACK.md-be
   visszacsatolandó)
6. manager-system/ORGANISMS.md — különösen a CategoryTreeEditor, RoleEditor,
   UserInviteDialog, GroupMemberList, UserPicker, TenantInfoForm,
   LogoUploader, RecipientList API-k
7. AUDIT-2.md — különösen 3.3 (inline-organism-pótlás jegyzék):
   *** A7 CSOPORT-ADATLAP `MemberRow` INLINE-PÓTLÁS ***
   Az a7-beallitasok-csoportok-adatlap.html egy inline `MemberRow`
   komponenst (sor 372-393) + `.a7d-picker` block-ot (sor 484+) renderel
   a kanonikus `GroupMemberList` (+ beágyazott `UserPicker`) helyett.
   *** A8 INVITE-CTA STATIKUS PÓTLÁS ***
   Az a8-beallitasok-felhasznalok-lista.html csak egy `InviteCta` button-t
   renderel; a `UserInviteDialog` organism megépítve, de NEM rendererelt.
   Mindkettő a HANDOFF.md-ben átadási megjegyzés, NEM UI-találmány.
8. SCREEN-CONVENTIONS.md

A screen-mock-ok:
   - manager-system/preview/screens/a6-beallitasok-kategoriak.html (4 state)
   - manager-system/preview/screens/a7-beallitasok-csoportok-lista.html (3 state)
   - manager-system/preview/screens/a7-beallitasok-csoportok-adatlap.html (4 state)
   - manager-system/preview/screens/a8-beallitasok-felhasznalok-lista.html (4 state)
   - manager-system/preview/screens/a8-beallitasok-felhasznalok-adatlap.html (5 state)
   - manager-system/preview/screens/a9-beallitasok-altalanos.html (4 state)

Working-mode + output ugyanaz mint Phase 2A.
→ SPEC-COVERAGE-A6A7A8A9.md fájl 4 listával + SPEC-FEEDBACK.md ## A6+A7+
A8+A9 spec-szelídítések ági-fejezet.

Különös figyelem:
— D-14 Settings-nav Pattern N — a spec 30_beallitasok §4.1 tab-szerű
  sub-nav-ot ír; explicit SPEC-FEEDBACK.md-be (spec-szelídítés javaslat).
— Az A8 user-detail saját-row „Te" chip-pel: SD-38 invariáns-előjelzés-e
  vagy UI-találmány? Ha SD-38 → ✅, ha D-9-ben → 🟡, ha sehol → 🔍.
— Az A8 + A7 inline-pótlások NEM UI-találmányok, l. AUDIT-2 hivatkozás.
— D-13 (DataTable contract-bővítés) hatása az A7/A8-lista screen-eken:
  sortable + onRowClick + dim Lezárt — ezek ✅ kategóriájába kerülnek
  (mind kanonikus organism-API + D-X dokumentált).

Kezdj javasolt vizsgálati-sorrenddel.
```

## Chat 5 — Phase 2D (Tartalom-ág spec-fedés) — v2

```
Az Urbino Manager Phase 1 + Phase 2A-C lezárult. Most a Phase 2D spec-
fedés review következik a Tartalom-ágra (A10 Hírek + A11 Programok +
A12 Városi információk).

Olvasd el:
1. REVIEW.md — Phase 2 szekció + Phase 1 tanulság-szakasz
2. uploads/urbino-docs/00_domain_model.md §4 (News + Event + CityInfo
   entitások)
3. uploads/urbino-docs/20_admin_felulet/60_tartalom.md (teljes)

Kötelező kontextus-input:
4. manager-system/DECISIONS.md — D-13 (ContentEditor + 8 új tartalom-ági
   organism kiemelése) + D-15 (DateTimeRangePicker két-input minta,
   Pattern A) + D-17 (ContentEditor publish-bar gomb-sorrend)
5. manager-system/ORGANISMS.md — különösen a ContentEditor (split-view,
   extraFields, previewSlot) + RichTextEditor (pilot-szint, FK-1) +
   CoverImageUploader + PhotoGallery + PhotoUploader + PublishStateChip
   + DateTimeRangePicker + LinkValidator API-k
6. AUDIT-2.md — a Tartalom-ág NEM tartalmaz inline-organism-pótlást
   (mind a 6 új organism a screen-mockokban rendereltek)
7. SCREEN-CONVENTIONS.md — különösen a ContentEditor split-view
   convention

A screen-mock-ok:
   - manager-system/preview/screens/a10-hirek-lista.html (3 state)
   - manager-system/preview/screens/a10-hirek-szerkeszto.html (4 state)
   - manager-system/preview/screens/a11-programok-lista.html (3 state)
   - manager-system/preview/screens/a11-programok-szerkeszto.html (4 state)
   - manager-system/preview/screens/a12-cityinfo-lista.html (3 state)
   - manager-system/preview/screens/a12-cityinfo-szerkeszto.html (4 state)

Working-mode + output ugyanaz mint Phase 2A.
→ SPEC-COVERAGE-A10A11A12.md fájl 4 listával + SPEC-FEEDBACK.md
## A10+A11+A12 spec-szelídítések ági-fejezet.

Különös figyelem:
— A ContentEditor split-view (bal: szerkesztő, jobb: polgári-app preview)
  D-13 alatti UX-explorer C-4 alatt dokumentált — NEM UI-találmány, a 🟡
  kategóriába kerül.
— A LinkValidator on-blur valid/invalid/unreachable state-szett D-15-előtti
  spec-iter alatt — ha S15 explorer-jegyzettel dokumentált → 🟡, ha
  sehol → 🔍.
— A DateTimeRangePicker „azonos napon" detektor + hint-sor a D-15 alatt
  dokumentált → 🟡.
— A publish-bar gomb-sorrend ([Eldobás] bal · [Vázlat-mentés][Publikálás]
  jobb) D-17 alatt dokumentált → 🟡.
— FK-1 (RichTextEditor mibenléte) a 99_donesnaplo.md-ben spec-szintű
  nyitott kérdés — ezt SPEC-FEEDBACK.md-ben emlékeztetőként rögzítsd.

Kezdj javasolt vizsgálati-sorrenddel.
```

## Chat 6 — Phase 3 (Átadási csomag) — v2

```
Az Urbino Manager teljes 8. lépés + Phase 1 + Phase 2A-D review lezárult.
Most a 9. lépés — átadási csomag — következik.

Olvasd el ebben a sorrendben:
1. REVIEW.md — a Phase 3 szekció
2. Urbino Manager.html — a projekt jelen állapota
3. HANDOFF-PREP.md — a Phase 1.4-ban válaszolt handoff-kérdések
   (10 [★ döntés-csillag] válasszal). A Phase 2A-D futása közben új
   cross-screen-policy-tételek merültek fel (pl. a 8 P0 KRITIKUS SF-
   tétel mock-feloldása vs. átadási-megjegyzésként-marad döntés,
   SF-92 A12 per-row LinkValidator-badge háttér-job-feltevés vs.
   törlés, a SPEC-FEEDBACK.md spec-csapathoz visszacsatolási
   formátuma) — az Első iter ezeket is rögzíti új [★]-ként, és csak
   utána véglegesíti a 10+N választ.
4. SPEC-COVERAGE-A1A2A3.md, -A4A5.md, -A6A7A8A9.md, -A10A11A12.md —
   a 4 spec-fedés-output (4-listás: ✅ ⚠ 🟡 🔍; ~370 mező/végpont/UI-
   elem összesen, ebből 95 SF-tétel)
5. SPEC-FEEDBACK.md — a Phase 2 konszolidált spec-szelídítések
   (a 4 ági-fejezet SF-1..SF-95 + a Phase 1.1-ben D-14 alatt rögzített
   Settings-nav-javaslat)
6. AUDIT-2.md — a 8. lépés végi audit (a 3 inline-organism-pótlás
   jegyzéke a HANDOFF.md-be átadási megjegyzésként kerül)
7. SCREEN-CONVENTIONS.md — a 11 dimenziós szabvány (a HANDOFF.md per-
   organism Angular-skeleton-mintája ezt követi)
8. manager-system/DECISIONS.md — D-1..D-17
9. manager-system/ORGANISMS.md — 42 organism API + Tier-besorolás
10. manager-system/SITEMAP.md — használat-mátrix (frissített)

Outputok (a HANDOFF-PREP.md záró szekciójában vázolt szerkezet szerint):
- HANDOFF.md — fejlesztő-átadás teljes dokumentum (PrimeNG-mapping,
  organism-mappelés, mock-adat-formátum, Angular-projekt struktúra,
  build-utasítások, ismert inline-pótlás-jegyzék, **spec-fedés-leltár-
  konszolidáció (4 batch × ~370 elem + 95 SF-tétel + 8 P0 KRITIKUS
  pilot-blokkoló lista + ~25 spec-csapat-döntés-jelölt + ~20 átadási
  megjegyzés)**, spec-hivatkozás-konvenció)
- starter/ — mini-Angular projekt (PrimeNG Aura + Tailwind v4,
  2 demó-screen: A4 Főoldal + A1 Bejelentés-lista, MockBackendInterceptor
  + DS read-only fixture). A teljes struktúra a HANDOFF-PREP.md záró
  szekciójában dokumentált.

Első iter (két alfázis):
(a) A Phase 2A-D-ben felmerült új cross-screen-policy-kérdések
    azonosítása + új [★]-ok felvétele a HANDOFF-PREP.md-be (várhatóan
    +3-5 tétel a 10 mellé). A 95 SF-tétel áttekintése a cross-screen-
    policy-szempontból kötelező.
(b) A teljes 10+N [★] válaszának véglegesítése user-jóváhagyással —
    a HANDOFF.md TOC-szintű váza ezen alapul.

Working-mode: small-iteration, max 2-3 task/iter; minden output a
HANDOFF.md-be vagy a starter/ alá megy; a HANDOFF-PREP.md új [★]-okkal
inline-bővítve.
```

---

# Mit szállíts mindegyik chatnek

**A REVIEW.md maga + a Phase 1 4 új dokumentum.** A REVIEW.md hivatkozási
rendszere a Phase 1.1 nyomán teljesen aktualizált; a 4 új doksi (AUDIT-2,
SCREEN-CONVENTIONS, HANDOFF-PREP + a frissített DECISIONS/ORGANISMS/SITEMAP)
be van építve a chat-promptokba kötelező kontextus-input-ként.

A fájlrendszer hordozza a teljes projekt-állapotot, nem kell semmilyen
export. A REVIEW.md-ben szereplő 6 prompt **másolható-beilleszthető** az
adott új chat első üzenetébe.

---

# Sorrendi javaslat

1. **Lefutott:** Chat 1 (Phase 1 — átfogó review). 4 új dokumentum +
   DECISIONS/ORGANISMS/SITEMAP frissítés.
2. **Most:** Chat 2 → 3 → 4 → 5 (Phase 2A → 2B → 2C → 2D). Mindegyik
   egy `SPEC-COVERAGE-X.md`-t + egy SPEC-FEEDBACK.md ági-fejezetet szállít.
3. **Végén:** Chat 6 (Phase 3 — átadási csomag).

Összesen **6 chat**, becsült ~3-5 iter chat-enként. A munka során ha
valamelyik szakasz felfedez egy nagyobb javítást (pl. egy screen újra-
tervezést), azt érdemes egy intersztiális iter-rel kezelni a megfelelő
chatben — a Phase 3 nem indulhat addig, amíg a 4 SPEC-COVERAGE-X.md és
a SPEC-FEEDBACK.md teljesen kifésült.

## A Phase 1 tanulságai — összefoglaló a Phase 2-höz

**4 új output a Phase 1-ből** (mind kötelező input a Phase 2-höz):
- **DECISIONS.md** D-14..D-17 (új cross-cutting döntések) + D-13 (DataTable
  contract-bővítés, audit-meneti retrofit)
- **AUDIT-2.md** — 3 inline-organism-pótlás (A5 RecipientsCard, A7 MemberRow,
  A8 InviteCta) dokumentált
- **SCREEN-CONVENTIONS.md** — a screen-mock 11 dimenziós szabvány; a
  mock-doksi-réteg (screen-header, DesignCanvas, DCArtboard) eleve
  kizárandó a backward-pass-ból
- **HANDOFF-PREP.md** — a 10 [★ döntés-csillag] kérdés (a Phase 3 induló
  iter ezeket véglegesíti)

**Új output-formátum a Phase 2-ben — 4 lista:**
- ✅ Spec + screen-en megvan — semmi teendő
- ⚠ Spec-ben van, screen-en nincs — hiányosság
- 🟡 *(ÚJ kategória)* Screen-en van, spec-ben nincs, DE D-X döntés rögzíti
  — dokumentált UX-választás, NEM UI-találmány
- 🔍 Screen-en van, spec-ben nincs, NEM dokumentált — UI-találmány

**Új deliverable: SPEC-FEEDBACK.md** — Phase 2 minden chat egy ági
fejezetet ír hozzá (`## A1+A2+A3 spec-szelídítések`, `## A4+A5...` stb.).
A Phase 3 elején konszolidáljuk + a HANDOFF.md Q9 (spec-források) szerint
visszacsatoljuk a spec-csapatnak.

**Inline-organism-pótlások SZIGORÚAN NEM UI-találmány:** az A5/A7/A8
inline-implementációi a kanonikus organism helyett (AUDIT-2 3.3) NEM
spec-szelídítések, hanem mock-szintű kényelmes pótlások. A HANDOFF.md-ben
átadási megjegyzésként szerepelnek, NEM a SPEC-FEEDBACK.md-ben.