# HANDOFF-PREP — Urbino Manager · átadás-előkészítő kérdések

**Dátum.** 2026.05.24 · **Phase.** 1.4 (záró) · **Scope.** A 9. lépés (HANDOFF.md + Angular-starter) előtti tisztázandó kérdések. **NEM döntés-dokumentum** — kérdéseket vet fel és lehetséges válaszokat (alternatívák + javaslat) ajánl. A Phase 3 HANDOFF.md ezekből emeli végleges szerződéssé.

> **Olvasási útmutató.** Minden szekció: **Kérdés** · **Miért most kell tisztázni** · **Opciók** (rövid pro/kontra) · **Javaslat**. A `[★ döntés-csillag]` jelzi, hogy a Phase 3-ban a fejlesztő-csapat (vagy a user) **explicit jóváhagyását** várjuk az adott opcióra.

**Célzott fejlesztői környezet (a teljes Phase 1 kontextus alapján fix):**
- **Angular** v17+ (standalone-components + signal-based state)
- **PrimeNG v21** (Aura theme — a DS `aura-preset.ts`-ben szabályozott; **fontos:** v21-ben a theming utilities a `@primeuix/themes` csomagba költöztek, a régi `@primeng/themes/*` import-path megszűnt — részletek a DS `tokens/README.md`-ben)
- **Tailwind v4** utility-réteg (a DS `tailwind.preset.cjs`-en át)
- **TypeScript** strict mode
- **Build/dev:** Angular CLI (`ng build`/`ng serve`)
- **A pilot deployment Balatonalmádiban 2026 közepén** — single-tenant, magyar nyelvű, desktop-first manager-felület.

---

## Q1 — Organism-réteg szállítási formátuma

### Kérdés
Hogyan szállítjuk a 42 organism-fájlt a fejlesztőnek? Kettő közül kell választani: **(a)** TS-szinten újraírva mint Angular-standalone-komponensek, vagy **(b)** a jelenlegi React-mock-mintát + screenshot + spec hivatkozást.

### Miért most kell tisztázni
A két opció **gyökeresen különböző handoff-csomagot** indukál:
- (a) → 42 `.ts` + 42 `.html` + 42 `.scss` fájl + Angular-modul-struktúra + spec-tests = ~5-10 mérnök-nap fordítási munka előzetesen.
- (b) → A jelenlegi 42 React-mock + tier-2-datatable-contract.html + a 28 screen-mock-fájl mint vizuális minta + HANDOFF.md per-organism Angular-skeleton-mintával = ~1-2 mérnök-nap.

### Opciók
- **(a) Pre-portolt TS-organismek a starter-projektben.**
  - **+** A fejlesztő gyakorlatilag `npm install`-lal kapja az UI-komponens-csomagot. A pilotra szállíthat (3-4 hét).
  - **−** A pre-portolás itt **drága + redundáns** — a Claude Code (vagy a fejlesztő) ennyi munkát mock-portolás nélkül is el tud végezni. A TS-portolás Angularra ugyanaz a kód-szintű művelet, akár a React-mock-ból, akár a spec-ből történik.
  - **−** A pre-portolt TS-fájlok mock-adattal vagy üres-state-tel? Ha üres, a fejlesztőnek mégis meg kell írnia a mock-bekötést. Ha mock-adattal, akkor 2 helyen kell karbantartani.

- **(b) React-mock-fájlok + screenshot-galéria + Angular-skeleton-minta + spec-hivatkozás.** *(javasolt)*
  - **+** A handoff scope-on belül teljesíthető (1-2 nap a starter-projektre).
  - **+** A fejlesztő látja a működő mockot, a kanonikus organism-API-t (ORGANISMS.md), és kap egy 1-2-screen-es mintát a starter-projektben. A többit ő portolja.
  - **+** A React-mock-réteg **megőrződik** mint vizuális reference — ha a Phase 2 (pilot) iteráció során újabb UX-csiszolás van, először itt érkezik meg, és csak utána Angularra portolva.
  - **−** A fejlesztő **kb 2-3 hét** Angular-portolás-munkát kap a 42 organism + 12 admin-screen mock-jából. Erős kontextus-átadás kötelező (HANDOFF.md tartalom-sűrűség).

### Javaslat
**(b) React-mock-fájlok + Angular-starter-projekt 1-2 screen-demoval.** A starter tartalma:
- A4 Főoldal (Dashboard) — egyszerű KpiCard + TeamPerformanceTable, jó "hello-world" Angular-példa
- A1 Bejelentés-lista — összetettebb (DataTable + FilterPillBar + TabFilter), demonálja a screen-konvenciók Angular-leképezését

A fejlesztő a többi 10 screent saját ütemben portolja, a HANDOFF.md per-organism Angular-skeleton-mintáival. **[★ döntés-csillag]**

### Döntés — (b) React-mock + Angular-starter 2 screen-demoval · 2026.05.26
User-jóváhagyás OK. A starter A4 + A1 demonstrálja az Angular-portolási mintát; a 42 React-mock vizuális reference-ként megmarad. A fejlesztő-csapat ~2-3 hét munkára számít a maradék 10 screen + 40 organism portolására.

---

## Q2 — PrimeNG-komponens mapping per-organism

### Kérdés
Melyik manager-organism MELYIK PrimeNG-komponensre portolódik 1-1 megfeleltetéssel, és melyik organism a "custom from-scratch" (PrimeNG-szabványból nem rakható össze)?

### Miért most kell tisztázni
A PrimeNG v21 Aura **~80 komponenst kínál**; az Urbino-manager 42 organisma közül **kb 70%** PrimeNG-alapú lehet, a többi 30% custom. Ha a HANDOFF.md erre **per-organism táblázatot** szállít, a fejlesztő pontosan tudja, melyik organism MELYIK PrimeNG-import-tal indul.

### Javasolt PrimeNG-mapping (előzetes, Phase 3-ban véglegesíthető)

| Manager-organism | PrimeNG-komponens(ek) | Megj. |
|---|---|---|
| `AppShell` (LeftNav + TopBar) | `Menu` (Vertical) + `Toolbar` | Custom layout-keret PrimeNG-stílussal |
| `PageHeader` | `Toolbar` | Custom title + actions slot |
| `EmptyState` | — | Custom |
| `UserChip` | `Avatar` + `Tag` | Avatar a polgári app-béli mintával |
| `SettingsSection` | `Panel` (toggleable=false) | Cím + leírás + content |
| `SettingsSubNav` | `TabMenu` | D-14 nyomán nem rendererelt, de a meglévő impl. ide portolódik |
| `ConfirmDialog` | `ConfirmDialog` *(PrimeNG)* | 1-1 megfeleltetés |
| `DataTable` | `Table` *(PrimeNG)* | Spec szerinti sortable + paginated + sticky-header — Aura-tematizálva |
| `FilterPillBar` | `Chip` + `InputText` *(PrimeNG)* | Chip-flavor a pill-szabványra |
| `TabFilter` | `TabMenu` + `Badge` *(PrimeNG)* | Count-badge a `Badge`-en, overdue tone a CSS-szabályon |
| `TriageBar` | `Splitter` + custom-cell | A 4 cella `Dropdown`/`Calendar`/`AutoComplete` belül |
| `TicketMetaBar` | — | Custom (cím + meta-sor) |
| `ActivityTimeline` | `Timeline` *(PrimeNG)* | 1-1 — event-type ikon a `template` slot-tal |
| `InternalNotesPanel` | `Card` + `InputTextarea` | Composer-mintával |
| `SimilarTicketsBox` | `Card` + custom-row | Findings amber-tinted header custom |
| `ActionBar` | `Toolbar` (sticky) | Sticky bottom CSS-szabállyal |
| `TicketCreateForm` | `Form` + `InputText`/`Dropdown`/`Calendar` | Nagyobb form-organism |
| `LocationPicker` | — | Custom (Leaflet-bekötés) |
| `MapWidget` | — | Custom (Leaflet) |
| `CategoryTreeEditor` | `Tree` + `Toggle` *(PrimeNG)* | Drag-handle custom |
| `IconPicker` | `OverlayPanel` + grid | Custom popover |
| `CategoryImportDialog` | `Dialog` + `Card` | Preview-card custom |
| `GroupMemberList` | `DataView` + `Avatar` | Row-lista PrimeNG-mintával |
| `UserPicker` | `AutoComplete` *(PrimeNG)* | Multiple=false, completeMethod-bekötéssel |
| `UserInviteDialog` | `Dialog` + `Form` | Modal lineáris form |
| `RoleEditor` | `Checkbox` cluster + custom-lock-tooltip | Locks-prop kezelése `Tooltip`-pal |
| `TenantInfoForm` | `Form` + `InputText` | Locked-mezők PrimeNG `disabled` |
| `LogoUploader` | `FileUpload` *(PrimeNG, mode=basic)* | Drop-zone Custom-css-szel |
| `RecipientList` | `DataView` (custom-row) + `Toggle` | Switch a PrimeNG `InputSwitch`-csel |
| `KpiCard` | `Card` + custom-grid | Sajat tabular-nums CSS |
| `TeamPerformanceTable` | `Table` *(PrimeNG, light)* | isTopPerformer custom-cell |
| `WeeklyReportCard` | `Card` + `Button` | Letöltés-CTA |
| `StatusTrack` | `Steps` *(PrimeNG)* + custom-branched-banner | StatusTrackBranched custom |
| `ContentEditor` | `Card` + custom-split-view | A `previewSlot` jobbra |
| `RichTextEditor` | `Editor` *(PrimeNG, Quill-alapú)* | Pilot-szinten elég |
| `CoverImageUploader` | `FileUpload` + `Image` | 16:9 preview |
| `PhotoGallery` | `Galleria` *(PrimeNG)* + custom-grid | Lightbox a `Galleria` show-method-ra |
| `PhotoUploader` | `FileUpload` (mode=advanced) | Drop-zone + thumbs |
| `PublishStateChip` | `Tag` *(PrimeNG)* | 1-1 |
| `DateTimeRangePicker` | `Calendar` *(PrimeNG)* × 2 | Két külön `Calendar(showTime=true)` (Pattern A — D-15) |
| `LinkValidator` | `InputText` + custom-state-icon | On-blur backend-hívás a host-on |

**Custom from-scratch (nem PrimeNG-stílusú):** `EmptyState`, `TicketMetaBar`, `LocationPicker`, `MapWidget`, `IconPicker` *(opcionálisan)*, `KpiCard`, `RecipientList`, `ContentEditor`-héj, `CoverImageUploader`.

### Miért így
A PrimeNG Aura-theme **a DS `--u-*` tokenekkel kötött** (a DS `aura-preset.ts`-ben szabályozva). Minden PrimeNG-mappelt organism örökli a manager-vizualitást automatikusan, nem kell külön override-okat írni — szignifikáns előny a CSS-mennyiség-csökkenésre.

**[★ döntés-csillag]** A Phase 3-ban a fejlesztő-csapat egy review-átfutást javasol a táblán; lehet, hogy 5-10 sor változik (pl. a `Editor` mint RichTextEditor — vagy TipTap migráció kívánatos, FK-1).

### Döntés — Táblázat változatlan átemelve · 2026.05.26
User-jóváhagyás OK. A 42-soros PrimeNG-mapping változatlanul kerül a HANDOFF.md-be (Iter 7). FK-1 lezárva (`60_tartalom.md` SD-69 + §4.6 PrimeNG Editor / Quill-alapú). A fejlesztő-csapat-átfutás (5-10 soros revíziós felület) a HANDOFF.md átadáskori review-átfutás része.

---

## Q3 — `_styles.css` portolása

### Kérdés
A 4936-soros `_styles.css` (547 `.mgr-*` osztály, 51 szekció) hogyan kerül az Angular-projektbe?

### Opciók
- **(a) Egyetlen globális `manager-styles.scss`** importálva az `angular.json` `styles[]`-be. Minimális változtatás, a `.mgr-*` osztály-családot a komponens-template-ek inheritálják.
  - **+** Triviálisan portolható.
  - **+** A 28 screen-fájl CSS-link-tag mintáját megőrzi.
  - **−** Globális CSS-szennyezés (`.mgr-*` minden komponensben elérhető). Nem-modulpattern.

- **(b) Per-organism `.scss` fájl** Angular-component-szintű enkapszulációval (`ViewEncapsulation.Emulated`). Az `_styles.css` 51 szekciója → 42 organism-komponens × ~3-4 családos SCSS-fájl.
  - **+** Angular-idiómatikus, jól skálázható.
  - **−** **Drága portolási munka.** A `.mgr-*` osztály-családokat per-organism szétbontani 2-3 mérnök-nap. A tier-0 organism-ek (AppShell, PageHeader, EmptyState) cross-cutting, mindenkire vonatkozó CSS-szel — ezek nehezen tagolhatók.

- **(c) Hybrid:** globális `manager-styles.scss` a Tier-0 + Tier-1 organism-eknek (cross-cutting), per-organism `.scss` a Tier-3 + Tier-4 organism-eknek (encapsulated). A két réteg az `angular.json`-ban + a komponensek `styleUrls`-en át kombinálva.
  - **+** Cross-cutting layout szabad, screen-szintű organism-ek encapsulated.
  - **+** A 28 screen-fájl jelenlegi link-sorrendjére portolható (DS előbb, globális mgr utoljára, per-organism scoped).
  - **−** Kettős mintázat — egy review-átfutás kell, hogy a fejlesztő ne keverje a két formátumot.

### Javaslat
**(c) Hybrid.** **[★ döntés-csillag]**

Indoklás: a 28 screen-fájl konzisztens CSS-link-tag-sorrendje (l. SCREEN-CONVENTIONS.md §2) a globális-és-encapsulated kombinációra **szándékosan** felépített. Az Angular-leképezés ennek a természetes Angular-eqvivalense.

### Döntés — (c) Hybrid · 2026.05.26
User-jóváhagyás OK. Tier-0 + Tier-1 organism-ek (AppShell, PageHeader, EmptyState, UserChip, layout + a D-19 `.u-self-chip` Iter 5-tel) **globális `manager-styles.scss`**-be az `angular.json` `styles[]`-en. Tier-3 + Tier-4 organism-ek (DataTable, TriageBar, ContentEditor, ...) **per-component `.scss`** ViewEncapsulation.Emulated mellett.

### Bonus: Tailwind v4 réteg

A DS `tailwind.preset.cjs` egy utility-réteget kínál (`u-page-*`, `u-stack-*` stb.). A starter-projektben **opcionális** a használat — a manager-felület döntően custom organism-CSS-szel él, a Tailwind utility-rétget csak ad-hoc spacing/flexbox-on érdemes használni. **A HANDOFF.md ezt explicit dokumentálja.**

---

## Q4 — Mock-data átadása

### Kérdés
A `data/mock.js` (3 hasznos kulcs + 3 halott) + a 28 screen-fájl per-screen inline-mockja hogyan kerül az Angular-projektbe?

### Opciók
- **(a) Egy konszolidált `mock.ts` a starter-projektben** (chrome-mock + a 2 demo-screen teljes mockjával). A többi 10 screent a fejlesztő portolja per-screen `.ts`-fájlokba.
- **(b) Per-screen `mock.ts`** a starter 2 demo-screen mellé, mintaként. A fejlesztő ezt a mintát követi a többi 10 screen portolásakor.
- **(c) Nincs Angular-mock** — Just a backend-stub (`assets/mock-api.json` típusú statikus JSON-fájl), amit egy `MockBackendInterceptor` szolgáltatás olvas. Egyúttal a 9. lépésen túli pilot-tesztelést is támogatja.

### Javaslat
**(c) Backend-stub + `MockBackendInterceptor`.** **[★ döntés-csillag]**

### Döntés — (c) Backend-stub + MockBackendInterceptor · 2026.05.26
User-jóváhagyás OK. A starter `MOCK_API` flaggel a Q15-szerinti `assets/mock-api/core/` + `features/` JSON-fáit olvassa. A `MOCK_API: false`-kor a backend-bekötés transzparensen átvált. HANDOFF.md per-screen mock-rekord-szerkezete táblát szállít.

Indoklás: a screen-mock-fázis (Phase 1) per-screen inline-mockja a React-mock-réteg sajátja. Az Angular-szintű pilot **éles backend-bekötést vár** (`GET /v1/bejelentesek`, `GET /v1/dashboard`, stb.). A `MockBackendInterceptor` mintával a fejlesztő a `MOCK_API: true` flag-gel a fejlesztés alatt statikus JSON-okat kap (transzparens cserélődés a Q4 backend-élesítéskor).

A starter-projektben demonáljuk a 2 demo-screen `MockBackendInterceptor`-bekötését. A HANDOFF.md per-screen "mock-rekord-szerkezete" táblát szállít, amit a fejlesztő JSON-fájlra alakít.

---

## Q5 — DS-kapcsolódás (design-system → Angular)

### Kérdés
A `design-system/` (a Urbino DS) hogyan kerül kapcsolatba az Angular-projekttel?

### Opciók
- **(a) Read-only fixture.** A DS-tartalmat (CSS-fájlok + assets + `aura-preset.ts` + `tailwind.preset.cjs`) **lokális mappaként** beemeljük az Angular-projektbe (`src/design-system/`). A frissítések manuálisan szinkronizálódnak.
- **(b) NPM dependency.** A DS publishelve egy private NPM-csomagra (`@urbino/design-system`), az Angular-projekt `package.json`-jából importálva.
- **(c) Git submodule.** A DS külön repo-ban, az Angular-projekt git-submodule-ként hivatkozik rá.

### Javaslat
**(a) Read-only fixture a pilotra → (b) NPM dependency a 2027.Q1 utáni Phase 2-re.** **[★ döntés-csillag]**

### Döntés — (a) Read-only fixture a pilotra · 2026.05.26
User-jóváhagyás OK. A DS-tartalom a starter `src/design-system/` mappa-másolataként szállítva (a colors_and_type.css + components/ + aura-preset.ts + tailwind.preset.cjs); manuális szinkronizáció pilot-szintre. A 2027.Q1+ Phase 2 (több város, több tenant) migrálhat NPM-re (`@urbino/design-system`-private-registry).

Indoklás: a pilot scope-jában (2026 közép, single-tenant Balatonalmádi) a DS-frissítések valószínűségi-szerűen havi-szintűek, manuális szinkronizáció (b)-höz képest nem dráma. A NPM-dependency a private-registry-setup-ot megköveteli, ami a pilot-elindításkor felesleges friction. A **read-only fixture** alacsony belépési költséget biztosít; a 2027.Q1-re tervezett Phase 2 (több város, több tenant) projekt ekkor migrálhat NPM-re.

---

## Q6 — Routing + Angular-projekt-struktúra

### Kérdés
A 12 admin-screen + a 2-3 dialog-flow Angular-route-térképe hogyan rendeződik?

### Javasolt route-térkép
```
/                                        → redirect /fooldal
/fooldal                                 → A4-DashboardComponent
/bejelentesek                            → A1-BejelentesekListaComponent
/bejelentesek/uj                         → A2-UjBejelentesComponent
/bejelentesek/details/:id                → A1-BejelentesAdatlapComponent (A3 dialog-ja beágyazva)
/riportok                                → A5-RiportokListaComponent
/riportok/details/:id                    → A5-RiportAdatlapComponent
/beallitasok/kategoriak                  → A6-KategoriakComponent
/beallitasok/csoportok                   → A7-CsoportokListaComponent
/beallitasok/csoportok/details/:id       → A7-CsoportAdatlapComponent
/beallitasok/felhasznalok                → A8-FelhasznalokListaComponent
/beallitasok/felhasznalok/details/:id    → A8-FelhasznaloAdatlapComponent
/beallitasok/altalanos                   → A9-AltalanosComponent
/hirek                                   → A10-HirekListaComponent
/hirek/uj | /hirek/:id                   → A10-HirSzerkesztoComponent
/programok | /programok/uj | /programok/:id → A11-ProgramokListaComponent | A11-SzerkesztoComponent
/cityinfo  | /cityinfo/uj  | /cityinfo/:id  → A12-CityInfoListaComponent | A12-SzerkesztoComponent
```

**Komponens-felelősség.** Minden route → 1 standalone Angular-component. A komponens belső felépítése az SCREEN-CONVENTIONS.md §1 4 blokk-mintájának Angular-eqvivalense: PageHeader + state-management (Signal-based) + organism-komponens-fa.

**Authz-guard.** A pilotban single-tenant, minden route a `urbino_admin` szerepkört várja — egyetlen `AuthzGuard` az `app.routes.ts`-en. Phase 2-ben a per-organism-szintű hozzáférés-kontroll (pl. `field_worker` csak az A1-mobil-vetületet) implementálódik.

**Lazy-loading.** A pilotban szándékosan **nem lazy** — a bundle <2MB, gyors first-paint, a kódbázis kicsi. Phase 2-ben Tartalom-ág + Riport-ág külön chunk.

**[★ döntés-csillag]** A route-térkép a fejlesztő-csapat review-jánál pár soron változhat (pl. `/bejelentesek/uj` mint child route vs. külön view).

### Döntés — 18-soros route-térkép elfogadva · 2026.05.26
User-jóváhagyás OK. 12 admin-screen + 5 adatlap-route + dialog-overlay-flow-ok; standalone Angular-komponens per-route; egyetlen `AuthzGuard` (single-tenant `urbino_admin`); lazy-loading NINCS a pilotra. A fejlesztő-csapat-átfutáskori 1-2 soros módosítás a HANDOFF.md review-része.

---

## Q7 — Inline-organism-pótlások ismert-jegyzéke

### Kontextus
Az AUDIT-2.md 3.3 dokumentálja a 3 inline-organism-pótlást:

| Screen-fájl | Inline-komponens | Kanonikus organism | Angular-portolási megjegyzés |
|---|---|---|---|
| `a5-riportok-adatlap.html` `RecipientsCard` | inline 382-407 | **`WeeklyReportCard` + `RecipientList`** (read-only) | A `WeeklyReportCard`-ot kanonikus organismként portold; a `RecipientList`-et `readOnly=true` flag-gel |
| `a7-beallitasok-csoportok-adatlap.html` `MemberRow` + `.a7d-picker` | inline 372-393 + 484+ | **`GroupMemberList`** (edit-mode-ban beágyazva `UserPicker`) | A `GroupMemberList` API-t kövesd (`members` + `editMode` + `candidates` + `onRemove` + `onAdd`); az inline `MemberRow`-t NE portold |
| `a8-beallitasok-felhasznalok-lista.html` `InviteCta` button | inline 265-266 | **`UserInviteDialog`** (a CTA → modal-flow) | Az invite-CTA megnyitja a `UserInviteDialog`-ot mint `dialog`-overlay |

### Miért most kell tisztázni
A 28 React-mock-fájl ezeken a 3 ponton **inline-implementációt szállít az organism helyett**. Ha a fejlesztő naivan-portolja Angularra ("amit látok, azt portolom"), 3 párhuzamos API-t kap. **A HANDOFF.md ezt explicit jegyzékként szállítja**, a fejlesztő tudja: "a screen-mock itt eltér a kanonikus organism-API-tól, kövesd ez utóbbit".

### Döntés — 3-soros AUDIT-2 §3.3 tábla változatlan átemelve · 2026.05.26
User-jóváhagyás OK. A HANDOFF.md "Ismert inline-pótlások" szövege ezt a 3-soros táblát hordozza, per-screen-en explicit Angular-portolási megjegyzéssel.

---

## Q8 — Tesztelési stratégia

### Kérdés
A pilot-átadás során milyen automatizált tesztet várunk?

### Opciók
- **(a) Unit + komponens-szintű** — Jest + Angular Testing Library. Minden organism-szintű komponens 2-3 alap-test (rendering, prop-handling, akció-callback).
- **(b) E2E happy-path** — Playwright vagy Cypress. A 12 admin-screen-en végigfutó scenario (login → új-bejelentés-felvétel → listán látszik → adatlap-megnyitás → triage → státusz-váltás → resolved).
- **(c) Csak smoke-test** — minden screen renderelődik konzol-hiba nélkül. Backend-bekötést nem tesztel.

### Javaslat
**(a) + (c) kombináció a pilotra; (b) a Phase 2 scope.** **[★ döntés-csillag]**

### Döntés — (a) Unit + (c) Smoke a pilotra; (b) E2E Phase 2 · 2026.05.26
User-jóváhagyás OK. **Unit** (Jest + Angular Testing Library): per-organism 2-3 alap-test, az API-szerződéseket rögzíti. **Smoke** (CI): minden screen render konzol-hiba nélkül. **E2E** (Playwright, Phase 2): happy-path scenario.

Indoklás: a pilot single-tenant, manuális QA elegendő az UX-validációra. A unit-tesztek (a) az organism-szintű API-szerződéseket dokumentálják (a `RoleEditor.locks` prop-ot a tesztben rögzítjük). A smoke-test (c) a CI-en bénázás-detektor. Az E2E (b) az integration-fázisra (a pilot-után 1-2 hónappal) ér rá.

---

## Q9 — Spec-források átadása

### Kérdés
A `uploads/urbino-docs/` (~50 spec-fájl, 1500+ oldal) hogyan kerül az Angular-projekt-fejlesztőhöz?

### Opciók
- **(a) A spec-fájlok az Angular-repo `docs/spec/` mappájába másolva** — a fejlesztő helyben olvassa, a komponens-kódban a kommentekben hivatkozik (pl. `// Spec: 10_bejelentes_lista_es_adatlap.md §4.2`).
- **(b) Külön spec-repo** — read-only git-submodule. A frissítések szigorú revízió-kontroll alatt.
- **(c) A spec a current-projektben marad** — a fejlesztő ezt linkeli, NEM másolja át. A current-projekt mint az "élő dokumentáció" forrás.

### Javaslat
**(a) Másolva az Angular-repo `docs/spec/`-be a pilot-átadáskor; a frissítések manuális szinkronizációja.** **[★ döntés-csillag]**

### Döntés — (a) Spec a `docs/spec/`-be másolva, manuális sync · 2026.05.26
User-jóváhagyás OK. A `uploads/urbino-docs/` teljes fájlszet átkerül a starter `docs/spec/`-be a pilot-átadáskor; spec-frissítések (ritkák) manuális sync. **Spec-hivatkozási konvenció**: `// Spec: <fájl>.md §<szám>` kötelező a komponens-kommentben.

Indoklás: a spec a kódbázis részévé válik — `git blame`, kódolt hivatkozások (`// Spec: ...`), grep-elhetőség előny. A pilot scope-on belüli spec-stabilitás (mid-2026 deadline) nem indokol külön spec-repot.

---

## Q10 — A SettingsSubNav jövője

### Kérdés
A D-14 (Pattern N) nyomán a `SettingsSubNav` organism-fájl megőrzött, de a screen-mockok NEM fogyasztják. Mit szállítunk az Angular-projektbe?

### Opciók
- **(a) Portolni** — `SettingsSubNavComponent` mint standalone-component, de a jelenlegi 4 settings-screen NEM importálja. Jövőbeli G-pattern-re visszatérés trivi.
- **(b) NEM portolni** — a `SettingsSubNav` mint React-mock-organism kihűl. A jövőbeli G-pattern-re visszatérés esetén újra-implementálás.

### Javaslat
**(a) Portolni minimális komponensként + dokumentálni, hogy nincs használva.** **[★ döntés-csillag]**

### Döntés — (a) Portolni + dokumentálni · 2026.05.26
User-jóváhagyás OK. `SettingsSubNavComponent` mint standalone-component (~30 sor TS), `// status: not-currently-used (l. D-14)` komment fejléccel. A 4 settings-screen NEM importálja. A kapcsolódó spec-szelídítés (SF-38, `30_beallitasok` §4.1 Pattern N visszacsatolás) a SPEC-FEEDBACK-FOR-SPEC-TEAM.md-be kerül (Iter 6).

Indoklás: a portolás kis munkát igényel (~30 sor TS), és az utólagos G-pattern-re visszatérés "csak importálni kell" műveletté redukálódik. A `// status: not-currently-used (l. D-14)` komment a komponens fejlécén.

---

---

# Phase 2A-D nyomán emergens kérdések (Q11–Q16)

> **Bevezetés.** A Phase 1.4 lezárása után a Phase 2A-D (4 chat × ~370 elem mező-szintű spec-fedés) **95 SF-tételt** generált — köztük 8 P0 KRITIKUS pilot-blokkoló, ~22 érdemi spec-szelídítés / spec-bővítés, ~20 mock-fix-jelölt és 4 új D-X kandidátus. Ezek cross-screen-policy-szintű kérdéseket nyitottak, amelyek **a Q1–Q10 mellé** kerülnek mint a Phase 3 induló-iter input-jai.
> **Dátum.** 2026.05.26 (Phase 3 induló iter, alfázis (a)).

## Q11 — A 13 P0 KRITIKUS pilot-blokkoló SF-tétel feloldási politikája

### Kérdés
A Phase 2A-D **13 P0 KRITIKUS SF-tétele** (Phase 2A: SF-7 Duplicate-state · SF-12 ActivityLog stable-ID · Phase 2B: SF-29 PDF-stub · SF-30 per-recipient · Phase 2C: SF-59 péntek→hétfő · Phase 2D: SF-62 pushOnPublish · SF-63 Archived 3-állapot · SF-64 kebab+publish-dropdown · SF-79 Event-koord+map · SF-86 CityInfo description quad-konfliktus · SF-87 iconRef · SF-88 groupLabel · SF-89 A12 PublishStateChip+szűrő) — **mock-fix-now vagy HANDOFF-note?**

### Miért most kell tisztázni
A SCREEN-CONVENTIONS.md scope-elve (*"ez a fájl NEM régi javításához"*) és az AUDIT-2 P0 cleanup-elve ütközik. A Phase 3-irány kell előbb.

### Opciók
- **(a) Mind a 13 mock-fix-now** — +2-3 iter Phase 3 elején; a starter csak utána.
- **(b) Mind HANDOFF-note** — gyors, de a screen-mock 13 helyen félrevezet.
- **(c) Hibrid** — *(választott)*

### Döntés — (c) Hibrid · 2026.05.26
- **Sürgős mock-szintű szöveg-csere** *(Iter 4b)*: SF-59 péntek→hétfő (4 hely a9-altalanos.html-en) + SF-50 LastManager-tooltip-szövegcsere (a8-adatlap.html). ~5 perc, 0 regresszió-kockázat. **Tone-of-voice / spec-konfliktus okán azonnali.**
- **A starter A1-en demonstrált** *(Iter 7)*: SF-7 (Duplicate-state) mint 5. artboard a starter-projekt A1-bejelentes-adatlap Angular-portolásán. Ez egyúttal a pilot Wow #4 első fele.
- **HANDOFF-note a többi 11-nek**: SF-12, SF-29, SF-30, SF-62, SF-63, SF-64, SF-79, SF-86, SF-87, SF-88, SF-89 mind a HANDOFF.md "Pilot-blokkoló P0 fix-tételek a portoláskor" szekciójába kerülnek.
- **Hatás.** A starter A1-demó **5 artboard** (Folyamatban / Új / Megoldva / Elutasítva + Duplicate); HANDOFF.md új főszekció ("P0 fix a portoláskor — 11 tétel").

---

## Q12 — SF-92 A12 per-row LinkValidator-badge: visszavonás

### Kérdés
Az A12-lista per-row `STATE_BADGE` UI-találmány **háttér-job + új DTO-mezők** spec-bővítését implikálná — a spec sehol nem rögzíti. HANDOFF.md melyik irányt javasolja?

### Opciók
- **(a) Spec-csapat-döntés-jelölt** — HANDOFF.md SF-92-re mutat, badge átmenetileg eltávolítva.
- **(b) Új D-X-ként formalizálva** — háttér-job-pilot-feltevés.
- **(c) Törlés** — *(választott)*

### Döntés — (c) Törlés · 2026.05.26
**Indoklás (user).** *"Nem volt ilyen spec-funkció."* A `STATE_BADGE` mock-renderelés a `a12-cityinfo-lista.html` `InfoRow`-on a Q14 mock-tidy iter része *(Iter 4a/4b)*; a `LinkValidator` szerkesztő-on-blur fogyasztása (A12 szerkesztő-screen) **változatlan** — az on-blur ellenőrzés spec-rögzített.

- **Hatás.**
  - `a12-cityinfo-lista.html` `STATE_BADGE` szövegcellái + `state` mock-mezok ('valid' / 'unreachable' / 'invalid' / 'checking') eltávolítva. A `host` derived-cella (SF-93) **megmarad**.
  - **SPEC-FEEDBACK.md SF-92 lezárva** (visszavont UI-találmány); NEM kerül a SPEC-FEEDBACK-FOR-SPEC-TEAM.md-be.
  - **D-20 nem keletkezik** (l. Q16).

---

## Q13 — SPEC-FEEDBACK visszacsatolási formátum + csatorna a spec-csapathoz

### Kérdés
A 95 SF-tétel (~22 érdemi spec-szelídítés/bővítés + 8 P0 + ~25 spec-csapat-döntés-jelölt) **hogyan és mikor** kerül a spec-csapathoz?

### Miért most kell tisztázni
A spec-csapat-`accepted` / `rejected` / `deferred` válasz **bemenet** a HANDOFF.md végállapotába — Phase 3 előtt ideális a stabilizálás.

### Opciók
- **(a) Önálló markdown-export** — *(választott)*
- **(b) GitHub-issue-k** — minden SF egy issue
- **(c) Inline-megjegyzések a spec-fájlokon** — PR-szerű diff
- **(d) Belső meeting-prep** — élő döntéssel

### Döntés — (a) Önálló MD + (i) Phase 3 ELŐTT · 2026.05.26
**Output.** `SPEC-FEEDBACK-FOR-SPEC-TEAM.md` *(Iter 6, új deliverable a Phase 3 megnyitása ELŐTT)*. Formátum:
- **Érthető, kérdés + javasolt megoldás struktúra** (NEM a jelenlegi `SPEC-FEEDBACK.md` belső munkaformátuma, ami a screen-mock-állapot kontextusába van ágyazva).
- Per-SF: rövid kontextus (1-2 mondat, "miért merült fel") → konkrét kérdés a spec-csapatnak → javasolt megoldás (vagy 2-3 opció).
- **Strukturálva:**
  1. **P0 KRITIKUS** (a 13 tétel a Q11 listából, MÍNUSZ az SF-7 + SF-12 amik mock/HANDOFF-szinten oldódnak) — várhatóan ~11 tétel
  2. **Érdemi spec-bővítések** (DTO-mező-bővítés, új entitás, új végpont) — várhatóan ~10 tétel
  3. **Spec-szelídítések** (1-mondat-átírás, oszlop-katalógus-revízió, pattern-revízió) — várhatóan ~12 tétel
  4. **Háttér / minor** (alacsony prioritású felülvizsgálati tételek) — várhatóan ~5 tétel
- **PDF NEM kell** (markdown elegendő).
- **A 4 SPEC-COVERAGE-X.md + a jelenlegi SPEC-FEEDBACK.md** mint forrás-anyag belső marad (a spec-csapatnak NEM küldött); a `SPEC-FEEDBACK-FOR-SPEC-TEAM.md` ennek a konszolidált, **csapat-olvasásra-szánt** rétege.

- **Hatás.**
  - **Új deliverable (Iter 6) a Phase 3 megnyitása ELŐTT** — a HANDOFF.md nem írható meg addig, amíg a spec-csapat-válaszok ~10-15 üzleti napon belül megérkeznek (a HANDOFF.md "nyitott spec-kérdés" jegyzéke a `under-review`-ben maradtakra szűkül).
  - **Time-line update:** Iter 4a-4b (mock-tidy) → Iter 5 (D-18..D-20) → **Iter 6 (SPEC-FEEDBACK-FOR-SPEC-TEAM kiírás + átadás a spec-csapatnak)** → spec-csapat-válasz-várás → **Iter 7 (HANDOFF.md + starter/)**.

---

## Q14 — `accepted-pending-mock-update` SF-tétel-csomag mock-tidy iter

### Kérdés
A 95 SF-ből **~20 tétel `accepted-pending-mock-update` státuszú** (alacsony-rizikójú szövegcsere / mock-data-bővítés / emoji-csere) — előzetes vagy halasztott?

### Opciók
- **(a) Mind elvégezve egy "mock-tidy" iter-ben** — *(választott)*
- **(b) Mind HANDOFF-note** — gyors, de screen-mock félrevezet
- **(c) Csak a sürgősek**

### Döntés — (a) Mind elvégezve · 2026.05.26
**Hatókör — ~20 SF-tétel (1-2 iter, `Iter 4a`):**

| Ág | SF-szám | Megj. |
|---|---|---|
| **Bejelentés (A1+A2)** | SF-5 (Resolved attrs törlés), SF-8 (PhotoGallery caption törlés), SF-10 (A2 ValidationBanner törlés), SF-13 (SimilarTicket updatedAt mock-bővítés), SF-15 (Reassigned mock-fix) | 5 |
| **Riport (A4+A5)** | SF-24 (A5 emoji→Lucide), SF-31 (PDF méret törlés), SF-32 (allfailed delivery mock-bővítés) | 3 |
| **Beállítás (A6+A7+A8+A9)** | SF-45 (A7 Méret-szűrő törlés), SF-46 (A7 👥 emoji), SF-50 (LastManager-tooltip-szöveg), SF-54 (A8 count-label), SF-55 (A8 👋 emoji + cím), SF-56 (A9 üres-name fallback), SF-60 (A9 @ → Lucide mail) | 7 |
| **Tartalom (A10+A11+A12)** | SF-65 (A10 default-sort), SF-70 (cím maxLength 120→200), SF-72 (Borítókép→Push pill), SF-73 (Tartalom-ág emoji-cluster, 5+ glyph), SF-80 (locationText maxLength + kötelező-jelölés) | 5 |
| **Q12-szelvény** | SF-92 (A12 per-row LinkValidator-badge törlés) | 1 |
| **Q11-szelvény** | SF-59 (péntek→hétfő, 4 hely) | 1 |

**Összesen: 22 SF mock-fix.**

- **Hatás.**
  - A SCREEN-CONVENTIONS.md "ez a fájl NEM régi javításához" elve **a Phase 3-induló iter alatt kifejezetten felülbírálva**. A 22 SF-fix konkrétan listázott, regresszió-rizikó-mentes (mind szövegcsere / mező-törlés / glyph-csere / mock-bővítés).
  - **NEM érint** a screen-fájl-struktúrát, a CSS-szabályokat, a state-artboard-számot — kizárólag a mock-data / inline-helper-szöveg / glyph-réteget.
  - A `_styles.css` `mgr-self-chip` (Q16 D-19-szelvény) az `Iter 4a`-ban kanonikus class-ként hozzáadva.
  - **A starter-projekt 2 demó-screen (A4 + A1) ezeket a fixeket már a végleges állapotban portolja**.

---

## Q15 — Mock-data konszolidáció a `starter/`-hez

### Kérdés
A Q4-szerinti `MockBackendInterceptor` + statikus JSON-fa hogyan szerveződik?

### Opciók
- **(a) Per-demo-screen JSON** — kettő különálló
- **(b) Konszolidált 8+ kulcsos `mock-api/`-fa**
- **(c) Hibrid** — *(választott)*

### Döntés — (c) Hibrid · 2026.05.26
**Output szerkezet (a `starter/src/assets/mock-api/`-ban):**

```
mock-api/
  core/                    ← közös mag, cross-screen-konzisztens
    tenant.json            ← 1 rekord (Balatonalmádi)
    users.json             ← 8 TenantUser (Tóth Béla + 7 további — A1/A7/A8/A10 mind ezt olvassa)
    groups.json            ← 4 csoport (Útkarbantartó / Közvilágítás / ... — A7/A1 mind ezt olvassa)
    categories.json        ← fa-struktúra (4 gyökér + 7 alkategória — A6/A1/A2 mind ezt olvassa)
  features/                ← demó-feature-specifikus
    dashboard.json         ← A4 KpiCards + TeamPerformanceTable + latestReport
    tickets.json           ← A1 ~12-15 ticket-rekord (subset; az A1-mock-mockja 50 elemű — itt a demó méret)
```

**Cross-screen-konzisztencia (AUDIT-2 P3 #10 lezárása):**
A `core/users.json` 8 rekordot tart, **azonos id-vel** olvasva mind az A1-listáról (`assignedUserId`-feloldás), az A7-csoport-tagok-listáról, és az A8-felhasználók-listáról. Ezt a HANDOFF.md mint "kanonikus mock-szerkezet" mintát szállítja.

**A 10 további screen (A2, A3, A5, A6, A7, A8, A9, A10, A11, A12) portolásakor** a fejlesztő új `features/<screen>.json` fájlokat ad — a mintát a 2 demó-screen pontosan adja.

- **Hatás.**
  - A `starter/` 6 JSON-fájllal szállít (4 core + 2 feature).
  - HANDOFF.md "Mock-szerkezet kanonizációja" szekció a `core/` vs. `features/` réteget magyarázza.
  - **A 28 screen-mock per-screen inline mock-jai a `starter/`-be NEM kerülnek át 1:1-ben** — a fejlesztő az új `features/<X>.json`-fájlokat per-igény portolja.

---

## Q16 — Új D-X kandidátusok rögzítése a DECISIONS.md-be Phase 3 előtt

### Kérdés
A Phase 2A-D során **3 új D-X jelölt** keletkezett (a Q12 nyomán D-20 LinkValidator-badge elesett). Formalizálás Phase 3 előtt vagy alatt?

### Opciók
- **(a) Phase 3 előtt** — *(választott)*
- **(b) Phase 3 közben**
- **(c) Csak a non-controversiálisak**

### Döntés — (a) Phase 3 előtt · 2026.05.26
**Új D-X bejegyzések (`Iter 5`, a DECISIONS.md-be):**

| D-X | Forrás SF | Tárgy | Súly |
|---|---|---|---|
| **D-18** | SF-9 | A2 Manual-eredet `PhoneBanner` — D-7 retrofit új F-4 alponttal: *"Manual-eredet vizuális kiemelése amber-tinted banner-rel a form fejlécében — 📞 Lucide-ikon + 'Telefonos bejelentés-felvétel' cím + 2-3-mondatos magyarázat."* | minor (retrofit) |
| **D-19** | SF-51 | **Self-aware "Te" identitás-chip cross-screen pattern** — új kanonikus class `.u-self-chip` az `_styles.css`-ben; cross-screen érvényesítés a manager-listákon (A8 self-row + future A7 csoport-tagok + A11 felelős-cell). Blue-50 háttér / blue-200 border / blue-700 szöveg. Reuse-konvenció. | közepes (cross-screen) |
| **D-20** | SF-83 | A11 lista `TimeCell` proximity-color (`--today` / `--soon` / `--past`) — új `cellType: 'eventTimeWithProximity'` cellrenderer. Az amber-tónus a `today`-státuszon `--u-blue-100`-ra cserélve a `--u-status-folyamatban-*`-szemantikai-overload elkerülésére. | közepes (semantic) |

**A Q12 elvetette a per-row LinkValidator-badge ötletet, ezért az eredetileg D-20-ra jelölt SF-92 NEM kerül a naplóba.**

- **Hatás.**
  - DECISIONS.md D-1..D-17 → **D-1..D-20** (3 új bejegyzés).
  - A `_styles.css` `.u-self-chip` + `.mgr-a11-time-cell--today`-revízió + D-7 §6 új F-4 alpont.
  - **HANDOFF.md** a 20-tételes naplóra hivatkozik.

---

## Záró összegzés

**16 kérdés tisztázva, 16 javaslat előterjesztve, ebből 6 ([Q11–Q16]) Phase 3-induló-iter alatt választott.** A Phase 3 HANDOFF.md az alábbi struktúrával készül:

1. **Áttekintés** — a manager-felület célja + pilot scope + design-rendszer-réteg.
2. **A 16 [★ döntés-csillag] válaszainak véglegesítése** — a Q1–Q10 user-jóváhagyásra vár (Iter 2-3, α-mode: per-[★] döntés); a Q11–Q16 már rögzítve (Iter 1, 2026.05.26).
3. **P0 fix-tételek a portoláskor** — Q11-szelvény nyomán **11 KRITIKUS pilot-blokkoló** (SF-12 + SF-29 + SF-30 + SF-62..64 + SF-79 + SF-86..89). Per-tétel: forrás-screen + spec-hivatkozás + javasolt fix-csomag.
4. **Per-organism Angular-skeleton-minta** — a PrimeNG-mapping-tábla minden organismére egy 5-10 sornyi TS-vázat ad.
5. **A 12 admin-screen Angular-route-tábla** — Q6 szerint.
6. **Mock-backend stub + kanonikus mock-szerkezet** — Q15-szelvény: `core/` (cross-screen-konzisztens) + `features/` (per-screen) rétegezés + `MockBackendInterceptor` minta.
7. **Spec-hivatkozási konvenció** — `// Spec: <fájl>.md §<szám>` mint komment.
8. **Ismert inline-pótlások jegyzéke** — Q7 szerint (A5 RecipientsCard / A7 MemberRow / A8 InviteCta).
9. **A starter-projekt szerkezete** — `npm install` + `ng serve` + 2 demó-screen (A4 + A1 — utóbbi 5 artboarddal, l. Q11 SF-7 Duplicate-state).
10. **Tesztelési minta** — Q8 szerinti unit + smoke.
11. **Hivatkozott források** — DECISIONS.md (D-1..**D-20**, Q16 nyomán D-18..D-20 új), ORGANISMS.md, SITEMAP.md, AUDIT.md + AUDIT-2.md, SCREEN-CONVENTIONS.md, Phase 2 SPEC-COVERAGE-fájlok + **SPEC-FEEDBACK-FOR-SPEC-TEAM.md** (Q13 új deliverable, Phase 3 ELŐTT kiírt + spec-csapat-választ Phase 3-szal párhuzamosan vár).

### A Phase 3 időrendje (Iter 1–7)

| Iter | Tárgy | Output | Időszükséglet |
|---|---|---|---|
| **1** ✓ | Q11–Q16 felvétele + döntések rögzítése | HANDOFF-PREP.md +200 sor | 1 chat-iter (lezárva) |
| **2** | Q1–Q5 véglegesítés (α: per-[★]) | HANDOFF-PREP.md `## Döntés` szekciók | 1 iter |
| **3** | Q6–Q10 véglegesítés (α: per-[★]) | uo. | 1 iter |
| **4a** | Mock-tidy: 22 SF-fix screen-mockon (Q11+Q12+Q14) | 12-15 screen-fájl szövegcsere | 1-2 iter |
| **4b** | Sürgős SF-szövegfix (SF-59 péntek→hétfő + SF-50 LastManager) | 2 screen-fájl | (4a részeként) |
| **5** | D-18..D-20 felvétel | DECISIONS.md + `_styles.css` `.u-self-chip` | 1 iter |
| **6** | SPEC-FEEDBACK-FOR-SPEC-TEAM.md (Phase 3 ELŐTT) | új MD a spec-csapatnak | 1-2 iter |
| **7** | HANDOFF.md + `starter/` | átadási csomag | 2-3 iter |

**Σ: ~9-12 iter a Phase 3-on belül.** A 7. iter a spec-csapat-válaszok ~10-15 üzleti napjának befogadásával nyit.

A `starter/` mappa tartalma (a Phase 3 záró deliverable):
```
starter/
  README.md                 — első-futás-instrukció, prereq-ek
  package.json              — Angular 17 + PrimeNG 21 + Tailwind 4 + deps
  angular.json
  tsconfig.json
  src/
    main.ts
    app.config.ts            — DI-bekötés (PrimeNG, MockBackendInterceptor)
    app.routes.ts            — route-térkép (Q6)
    app/
      shared/
        organisms/           — 2-3 demo-portolt organism (AppShell, PageHeader, KpiCard)
      features/
        dashboard/           — A4 demó-screen
          dashboard.component.ts
          dashboard.component.html
          dashboard.component.scss
        bejelentesek/        — A1 demó-screen
          bejelentesek-lista.component.ts
          ...
    assets/
      mock-api/              — Q15 hibrid szerkezet
        core/                — cross-screen-konzisztens mag (mind a 12 admin-screen olvassa)
          tenant.json
          users.json         — 8 TenantUser, kanonikus id-szett
          groups.json        — 4 csoport
          categories.json    — fa-struktúra (4 gyökér + 7 alkategória)
        features/            — demó-feature-specifikus
          dashboard.json     — A4 KpiCards + TeamPerformanceTable + latestReport
          tickets.json       — A1 ~12-15 ticket
      logo-mark.svg
      ...
    design-system/           — fixture-másolat (Q5)
    styles/
      manager-styles.scss    — globális Tier-0/1 organism CSS (Q3)
      aura-overrides.scss    — DS Aura-preset Angular-bekötés
```

*Ez a dokumentum az 1.4 iter (Phase 1 záró) eredménye, **Iter 1 (Phase 3 induló, 2026.05.26) Q11–Q16 bővítéssel**. Folytatás: Iter 2 (Q1–Q5 véglegesítés) → Iter 3 (Q6–Q10) → Iter 4a-7 (mock-tidy + D-18..D-20 + SPEC-FEEDBACK-FOR-SPEC-TEAM + HANDOFF.md + starter/).*