# Manager system — organism layer

**Mit ad ez a mappa.** A `design-system/` atom + molecule rétegére építkező,
**kizárólag a manager admin felülethez tartozó** organism-réteg. Itt élnek
azok az UX-blokkok, amelyek a manager-screeneken ismétlődnek, de a polgári
világban nem jelennek meg, ezért nem fértek be a megosztott DS-be.

A három réteg viszonya:

```
┌──────────────────────────────────────────────────────────┐
│  design-system/                                            │
│  ─ Atom & molecule (button, card, chip, input, …)         │
│  ─ Két világ közös vizuális szótára                       │
│  ─ Read-only innen; módosítás csak ds-patch/-en keresztül │
└──────────────────────────────────────────────────────────┘
                          ▲ szigorúan ezen épít
                          │
┌──────────────────────────────────────────────────────────┐
│  manager-system/   (ez a mappa)                            │
│  ─ Organism (AppShell, StatusTrack, TriageBar, …)          │
│  ─ Manager-specifikus UX-blokkok                           │
│  ─ Saját CSS / komponens; csak --u-* tokeneket fogyaszt    │
└──────────────────────────────────────────────────────────┘
                          ▲ ebből komponál
                          │
┌──────────────────────────────────────────────────────────┐
│  app/                                                      │
│  ─ A 12 admin screen mint vékony kompozíció                │
└──────────────────────────────────────────────────────────┘
```

## Mi tartozik ide

- **Manager-specifikus organism-ek.** AppShell (left nav + top bar + main),
  TriageBar (4-mezős inline-szerkeszthető sáv egy Ticket-en), TabFilter
  (count-badge-es tab-szűrő lista-screen tetején), ActivityTimeline
  (napló-bejegyzések időrendben), SimilarTicketsBox, ConfirmDialog
  (elutasítás/visszanyitás/összevonás), és társaik.
- **Manager-specifikus pattern-ek.** Az organism-eknél nagyobb,
  screen-szintű minták leírása: page-header sablon, empty-state-recept,
  dialog-flow-koreográfia.
- **Mock-adatok és lookup-források.** Az organism-specimen-ek + a screen-mockok
  fogyasztói; a spec szerinti enum-/lookup-értékek tükörként.

## Mi NEM tartozik ide

- **Shared atom / molecule.** Ha valami a polgári oldalon is felmerülne
  (`KpiCard` egy nyilvános városi statisztikai oldalon, `EmptyState` mint
  alap-template) — az **DS-be való**, `ds-patch/`-en keresztül.
- **Konkrét screen.** A 12 admin feature konkrét nézete az `app/`-ban él
  (vékony composition), nem itt.
- **Üzleti logika.** API-szerződés, validáció, állapotgép — a `uploads/urbino-docs/`
  specifikációban; az organism-ek azt **vizualizálják**, nem implementálják.

## Mappa-szerkezet

```
manager-system/
  README.md                ← itt vagy
  SITEMAP.md               ← a 12 admin feature → organism-használat mátrix
  ORGANISMS.md             ← organism-katalógus + építési prioritás
  PATTERNS.md              ← screen-szintű minták (page-header, empty-state, …)
  organisms/               ← egy fájl per organism
    app-shell.jsx
    status-track.jsx
    triage-bar.jsx
    ...
  organisms/_styles.css    ← organisms CSS (egy fájlban, mert konszolidálható)
  data/                    ← mock-adatok (csak ide), organism-specimens fogyasztják
  preview/                 ← organism-katalógus (vizuális index)
    index.html
```

## A "promotálás" szabálya

Ha egy `manager-system/`-beli organism kiderül, hogy **mindkét world-re érvényes**
(pl. egy `EmptyState` molecule, vagy egy `KpiCard`-szintű atom), akkor:

1. Specifikáljuk DS-szinten (`ds-patch/`-csomag, mint a page-layout-patch).
2. A DS bekapja, az organism itt **kivezetésre kerül** ugyanabban a
   commit-csomagban (ne legyen kettős forrás).
3. A consumer screenek átállnak a DS-osztályra (legtöbbször automatikus,
   ha az organism CSS-class-alapú).

A `manager-system/` ezért **élő rétegben** tartja a jelölteket — nem örök
ottlét, csak addig, amíg manager-specifikusnak bizonyul.

## Az építési sorrend

A részleteket a `SITEMAP.md` és `ORGANISMS.md` adja. Lényege:

1. **Inventory** *(SITEMAP + ORGANISMS)* — mit kell, milyen sorrendben, miért.
2. **Top-priority organism-ek** — a 4+ screenen ismétlődők először.
3. **Egy-egy ellenőrző screen** — valós content-kompozícióval validálni az organism-eket.
4. **Maradék organism-ek** + a 12 screen.

Nem mindenért építünk vizuális mockot — a `PATTERNS.md` egyes screen-eknél
elegendő szöveges handoff lehet, ha a layout triviális.