# Urbino · Kanonikus döntések

**Státusz:** belső munkadokumentum, élő
**Frissítve:** 2026.05.14
**Cél:** tömör lista azokról az érlelt állításokról, amelyek nem vitathatók
újra, csak indokolt módosítással. Gyors hivatkozási pont új beszélgetésekhez
és a stratégiai dokumentum frissítéséhez.

---

## Hogyan használjuk ezt a listát

- **Új beszélgetés indulásakor** Claude végigfut a listán, hogy a korábbi
  kanonikus állítások aktív emlékezetben legyenek.
- **Stratégiai döntés-előkészítéskor** ellenőrizzük, hogy nincs-e ütközés a
  kanonikus állításokkal. Ha van, az **a koncepció módosítását igényli**, és
  ezt nem szabad észrevétlenül átengedni.
- **Új állítás születésekor** Claude javasolja a felvételt, dátummal,
  forrással és indoklással. Az alapító erősíti meg.
- **Régi állítás módosulásakor** a régi nem törlődik, hanem **átkerül a
  "felülírt" szakaszba**, az új mellé. Ezzel a változás követhető.

---

## Aktív kanonikus állítások

### A koncepció gyökere és hierarchiája

**K-001 — A koncepció gyökere a városgazdálkodási rendszer.**
Az Urbino B2B SaaS, amelynek szerves része egy polgári app. Konfliktus esetén
a városgazdálkodási oldal érdeke nyer. (Forrás: koncepció v0.1, 1.1.
Beszélgetés: 2026.05.12.)

**K-002 — A kommerciális vásárló a városgazdálkodási vezető.**
Az ő ROI-számítása alapján születik a szerződés, az ő büdzséjéből fizet, és a
megújulás is az ő döntése. (Forrás: koncepció v0.1, 1.3. Beszélgetés:
2026.05.12.)

**K-003 — A kapuőr a polgármester, de nem ő a vásárló.**
Nélküle nem indul a folyamat, a polgári app az ő asztalán nyitja meg a
tárgyalást, de a tartalmi és pénzügyi döntés a városgazdálkodási vezetőé.
(Forrás: koncepció v0.1, 1.3. Beszélgetés: 2026.05.12, finomítás a stratégia
v1.0 4.3-hoz képest.)

**K-004 — A három tartópillér: operatív megtakarítás, strukturált válasz,
brand-rezisztens érték.**
Minden új feature, modul, döntés ezeken mérendő. (Forrás: koncepció v0.1, 1.4.
Beszélgetés: 2026.05.12.)

### Termék-architektúra

**K-005 — Ticket-centrikus gerinc, asset-réteg ráépülve.**
Pilot és első 12 hónap: ticket-életciklus a gerinc. 12-24. hónap: asset-réteg
ráépülve (eszközkarbantartás). Nem asset-centrikus, nem civic-engagement
centrikus, nem kommunikációs-platform centrikus. (Forrás: koncepció v0.2, 2.2.
Beszélgetés: 2026.05.12, megerősítve a négy alternatíva kibeszélése után.)

**K-006 — A termék magja három felület együtt.**
Manager felület (web, reszponzív, több szerepkörrel), polgári mobilapp, terepi
mobilapp. Egyik nélkül a rendszer nem teljes. A vezetői riport-modul nem önálló
felület, hanem a manager felület egy nézete (vezető-szerepkörrel). (Forrás:
koncepció v0.2, 2.4; felülírva 2026.05.13 az architekturális tisztázás után.)

**K-007 — Egységes Urbino-brand, város mint tartalom.**
Nem fehér címkés rendszer. Egy Urbino app, amiben a polgár átvált a városai
között. Brand mindenhol Urbino, a városnév konfigurációs paraméter. Ez a
3. pillér (brand-rezisztens érték) gyakorlati megvalósulása. (Forrás: koncepció
v0.3, 1.4 és 2.8. Beszélgetés: 2026.05.12.)

**K-008 — Multi-tenant fegyelem az első naptól.**
Adatmodell tenant-kulcsolt, város-specifikus képernyő nem létezik, egy város
egy ötlete nem feature-pályázat. Két város értelmes igénye kell a termékesítéshez.
(Forrás: koncepció v0.2, 2.8.)

**K-023 — Polgári webes felület mint funnel, nem teljes webapp.**
A polgári oldal webes verziója egy konverziós funnel a mobilappra, nem a
mobilapp helyettesítője. Funkciói: nyilvános bejelentés-megtekintés (link-megosztáshoz,
Facebook screenshot-okhoz), kategória-szintű listanézet, SEO-érzékeny indexelhetőség,
és CTA az app letöltésére. Bejelentést, ötletet, szavazást NEM lehet weben
csinálni — ezek mobil-only. Indoklás: a polgári retention mobilnatív push-ra
épül (K-012), és a letöltési KPI nem sérülhet egy túl gazdag webes verzió miatt.
A SEO-érték stratégiai versenyelőny a Munipolissal szemben. (Forrás: beszélgetés
2026.05.13.)

**K-024 — Urbino-admin külön belső felület.**
Az Urbino csapat super-admin felülete (új tenant felvétel, billing, használati
monitoring, feature-flag kapcsolás) NEM a manager felület része, hanem külön
webes felület. Biztonsági szempont: egy tenant felhasználója sosem láthat más
tenantot, a super-admin többet lát. Funkcionálisan és UX-érzékenységben más,
mint a manager felület. Lehet azonos technológiai stack-en (Angular SPA),
másik route-tal és jogosultsággal. (Forrás: beszélgetés 2026.05.13.)

### Anti-termék — mi NEM vagyunk

**K-009 — Hét anti-termék kategória.**
Nem panaszkönyv. Nem közösségi háló. Nem önkormányzati hírportál. Nem
GIS-rendszer. Nem e-ügyintézési rendszer. Nem civic engagement-platform
(CitizenLab/Decidim/Consul értelemben). Nem kommunikációs platform
(Munipolis-stílusban). (Forrás: koncepció v0.3, 1.5.)

### Felhasználói pályák és wow-pillanatok

**K-010 — Hét szereplő, koncepciós hierarchia szerint differenciálva.**
Mély pálya: Béla (ügyvezető), Anna (diszpécser), József (terepi),
Mária (polgár). Közepes: polgármester. Rövid: vállalkozó. v0.4-re halasztva:
sajtó, befektető. (Forrás: koncepció v0.3, 3.2.)

**K-011 — A vásárlói átbillenés a vezetői riport-modulon dől el.**
Béla pályája megmutatja: nem a polgári app a vásárlás kulcseleme, hanem a
vezetői riport-modul. Ennek a piloton **alapszinten élesednie kell**,
nem várhat a Pro csomagig. (Forrás: koncepció v0.3, 3.3.)

**K-012 — Polgári retention "havi 2-3 érintkezés", nem napi.**
A polgári app nem Facebook-szerű napi aktivitásra optimalizál. Trigger-alapú
használat: közterületi probléma → bejelentés → lezárási élmény. (Forrás:
koncepció v0.3, 3.11.)

### Versenytárs-helyzet

**K-013 — A Munipolis a legfontosabb versenytárs, már aktív Magyarországon.**
3500+ önkormányzati ügyfél CEE-régióban, 500.000+ aktív polgár Csehországban.
Magyarországon Hódmezővásárhely, Baja, Monor, Szerencs, Csömör. Polgári app
síkon közvetlen konkurencia. A stratégia v1.0 2.2 fejezete ezt **nem ismeri
fel kellő súllyal** — v1.1-ben frissítendő. (Forrás: versenytars_tajkep_v1.
Beszélgetés: 2026.05.12.)

**K-014 — A városgazdálkodási operatív síkon érdemi üresség van Magyarországon.**
Nincs valódi versenytárs ezen a síkon (KOVIKA vertikális, ASP hivatali, a
fehér címkés szereplők sekélyek). Itt minimum 18-24 hónapnyi versenyelőny
lehetséges, ha gyorsan építünk mélységet. Ez **az Urbino győzelmi tere**.
(Forrás: versenytars_tajkep_v1.)

**K-015 — A versenystratégia magja: "Munipolis = kommunikáció; Urbino = operáció".**
A városgazdálkodási vezetők előtt élesen kommunikálni a különbséget. A polgári
app demója vonzó, de a városgazdálkodási oldal mélysége dönt a szerződésnél.
(Forrás: versenytars_tajkep_v1.)

### Pilot-stratégia

**K-016 — A pilot 0-6 hónap scope szigorú.**
Csak a gerinc és a közeli periféria alapszinten. Konfigurálható munkafolyamatok,
SLA-mátrix, részletes vezetői dashboardok, Vedd a helyit monetizáció,
asset-réteg — mind 6. hónap után. (Forrás: koncepció v0.2, 2.5.)

**K-017 — A 36 hónapos város-szám (stratégia 6.4) ambiciózus.**
A koncepció szempontjából nem a város-szám a fontos, hanem a koncepciós
érettség. 15-20 város érett koncepcióval értékesebb, mint 30 város felületes
implementációval. Stratégia v1.1-ben felülvizsgálandó. (Forrás: koncepció
v0.2, 2.6.)

### Technológiai döntések

**K-018 — Automatizált asset-felmérés stratégiai lehetőség, de NEM a piloton.**
Mapillary-alapú detektálás 12-18. hónapra időzítve. A piloton 1-2 napos
PoC-kísérlet kompetenciaépítés céljából, nem termékfejlesztés. (Forrás:
asset_felmeres_automatizalt_v1.)

### Árazás és csomagstruktúra

**K-019 — Mélység-alapú árazás, két fő csomag plusz egy kistelepülési Sub.**
A csomagok a termék mélységét árazzák, nem a használat volumenét. Két fő
csomag: Pro (a standard ajánlat) és Enterprise (asset-réteggel és
integrációkkal). Plusz egy önkiszolgáló Sub-csomag a kistelepüléseknek
(5-15 ezer fő). Minden csomag a négy felületet adja (K-006 konzisztens), csak
a mélység tér el. (Forrás: arazasi_modell_v1.)

**K-020 — Pilot árazás: alapító ár 50% kedvezménnyel a Pro listából.**
A pilot 1. évében a Pro csomag listaárából 50% kedvezmény, mérhető
cserevállalásokkal (esettanulmány, referencia, sajtó, demó-elkísérés).
A 2. évtől a teljes listaár. A korai 2-3-4. város is kaphat csökkenő alapító
kedvezményt (40%, 30%); a 6. várostól standard listaár. (Forrás:
arazasi_modell_v1.)

**K-021 — Az ár nem fejlesztési költség, hanem megtakarított munkaidő.**
A vevő ROI-számítása: egy közszférás munkatárs éves teljes költsége 5-7 millió
Ft; a rendszernek 2-4x megtérülést kell mutatnia az első évben. Az árazás
ehhez igazodik. (Forrás: arazasi_modell_v1, megerősítve stratégia v1.0 6.2.)

**K-022 — A két éves pilot 2. évi ugrás kommunikálható szintű.**
50% kedvezmény → listaár ugrás kb. 75-100%, nem 5-7-szeres mint a v1.0
névleges-díj modellben. Ezzel az érzelmi rögzülés a piloton elkerülhető.
(Forrás: arazasi_modell_v1.)

### Manager felület — funkcionális tervezés

> A K-025—K-039 a manager felület funkcionális tervezéséből származik
> (2026.05.14). Ezek **funkcionális szintű** kanonikus állítások: a manager
> felület működésének olyan döntései, amelyek a Specifikációs projektben sem
> vitathatók újra. Forrásuk a `80_modulok/manager_felulet/` dokumentumai.

**K-025 — A manager felület több szerepköre implicit unió-modellben él.**
Egy felhasználó több szerepkörhöz tartozhat, és a felület mindent egyszerre
mutat, amihez bármelyik szerepköre jogot ad. Nincs explicit szerep-váltó UI;
a profil-menü mutatja a szerepkör-listát. Tenant-váltás (több városhoz tartozó
felhasználónál) külön UI a profil-menüből, de szerep-váltás nem. Indoklás:
Linear/Asana/Jira standard; a pilotra a több-szerepkörös felhasználók száma
alacsony. (Forrás: `00_architektura` 2.2. Beszélgetés: 2026.05.14.)

**K-026 — A bejelentés-adatlap inline-szerkesztést használ a triage-folyamatra.**
A kategória, prioritás, határidő, felelős mezők kattintással, helyben
szerkeszthetők, optimistic update-tel — eltérve a meglévő admin-felület
"részletek vs. szerkesztés" elválasztásától. A többi nézeten a klasszikus
külön-oldalas modell marad. Indoklás: Anna 30 másodperces triage-ciklusa
(Wow #4, #5) csak így tartható. (Forrás: `00_architektura` 3.4. Beszélgetés:
2026.05.14.)

**K-027 — A manager felület kezdő-nézete szerepkör-érzékeny.**
A `/` URL redirect-tel vezet a szerepkörnek megfelelő kezdőnézetre:
diszpécsernél a bejelentés-lista ("Új" előszűréssel), vezetőnél a Dashboard,
tartalomkezelőnél a hír-lista. Indoklás: minden szerepkör más napi belépőt
igényel, és a felület ne kérje meg őket a manuális navigációra. (Forrás:
`00_architektura` 3.2. Beszélgetés: 2026.05.14.)

**K-028 — A "bejelentés" a felületi terminus, a "ticket" csak belső
fejlesztői szó.**
A manager felületen, a polgári mobilappon és minden polgárinak látható
kommunikációban a "bejelentés" szó szerepel. A "ticket" csak a fejlesztői és
belső termékfejlesztési dokumentumokban (mint K-005). Indoklás: brand-szintű
konzisztencia a polgári oldal és a manager felület között; magyar közszférás
UX-konvenció. (Forrás: `00_architektura` 3.2. Beszélgetés: 2026.05.14.)

**K-029 — A bejelentés-státusz öt állapotú: Új, Kiosztva, Folyamatban, Lezárt,
Elutasítva.**
Az állapot a munka állapotát írja le, nem az adminisztrátorét. A triage az
Új → Kiosztva átmenet (nincs külön "Triage" állapot). A pilotra ez a modell
fix; konfigurálhatóvá a 6-12. hónapban válhat. Indoklás: a koncepció 2.3 öt
állomásának belépés-triage-munkavégzés-lezárás logikáját képezi le, és a
Dashboard mérhetőségét adja. (Forrás: `10_triage_flow` 2. Beszélgetés:
2026.05.14.)

**K-030 — Az elutasítás kötelező indoklással jár, és nem törlés.**
Az Elutasítva látható, naplózott végállapot. Az elutasítás-akció kötelező
indoklást kér (előre definiált ok vagy szabad szöveg). Indoklás: az
indoklás-nélküli elutasítás a 2. pillért (strukturált válasz a polgárnak)
sérti; az eltüntetett bejelentés a polgári bizalmat és a riport-adatminőséget
rombolja. (Forrás: `10_triage_flow` 5. Beszélgetés: 2026.05.14.)

**K-031 — A triage négy döntésből áll: kategória, prioritás, határidő, felelős.**
A triage szándékosan négymezős — minden további mező a 30 másodperces keretet
feszíti. A prioritás háromértékű (Alacsony/Normál/Magas), alapérték "Normál";
a határidő automatikusan javasolt (kategória+prioritás szabály), felülírható.
Indoklás: Anna pályájának mérhető ígérete (30 másodperc, Wow #5) csak szigorú
mező-fegyelemmel tartható. (Forrás: `10_triage_flow` 3.3 és 3.5. Beszélgetés:
2026.05.14.)

**K-032 — A duplikáció-szűrés a pilotra deterministic heurisztika, nem ML.**
Két bejelentés akkor lehetséges duplikátum, ha térbeli közelség (≤50 m),
azonos gyökér-kategória és idő-közelség (≤14 nap) együtt teljesül. A rendszer
javasol, az összevonásról a diszpécser dönt; nincs automatikus összevonás.
Indoklás: a koncepció 2.7 explicit ("kézi és szabály-alapú, AI csak 18-24.
hónaptól"); a determinizmus átlátható és tanító-adat nélkül a 0. naptól
működik. (Forrás: `20_duplikacio` 2. Beszélgetés: 2026.05.14.)

**K-033 — A duplikáció-ellenőrzés nem kötelező lépés a triage-ben.**
A "Hasonló bejelentések" doboz döntéstámogatás, nem kapu. A diszpécser a
triage-et duplikáció-ellenőrzés nélkül is befejezheti; az üres eset csendes.
Indoklás: a 30 másodperces triage-keret (K-031, Wow #5) csak így tartható; a
duplikáció eszköz, nem gyámkodás. (Forrás: `20_duplikacio` 1.1 és 3.2.
Beszélgetés: 2026.05.14.)

**K-034 — Összevonáskor a régebbi bejelentés az eredeti, és a duplikátum
bejelentője átkötődik az eredeti ügy értesítendői közé.**
A duplikátum Elutasítva lesz "Duplikáció" indoklással és eredeti-ügy
hivatkozással; az eredeti alapból a régebben beérkezett (a diszpécser
felülírhatja). A duplikátum bejelentője megkapja az eredeti ügy
státuszfrissítéseit. Indoklás: a duplikátum bejelentője jóhiszeműen jelentett
valós problémát — a 2. pillér megköveteli, hogy ő is megtudja a megoldást.
(Forrás: `20_duplikacio` 4. Beszélgetés: 2026.05.14.)

**K-035 — A vezetői riport-modul két komponens: belső Dashboard és kifelé
kommunikálható heti PDF.**
A Dashboard a vezető belső munkaeszköze (élő, interaktív, névre bontott
csapat-tábla). A heti PDF a kommunikációs dokumentum (fix sablon, hivatalos
forma, automatikusan e-mailben a vezetőnek és a polgármesternek). A névre
bontott teljesítmény csak a Dashboardon jelenik meg; a PDF a csapatot
összesítve, név nélkül mutatja. Indoklás: K-011 (a riport dönti el a
vásárlást); a koncepció 3.11 (narratív és kommunikálható); a névtelenítés a
polgármesteri kommunikáció munkajogi/csapat-morális kockázatát zárja ki.
(Forrás: `40_riport` 2. és 7.1. Beszélgetés: 2026.05.14.)

**K-036 — A kategória-fa kétszintű; a gyökér terméktulajdon, az alkategória
tenant-tulajdon.**
A gyökér-kategóriák csak az Urbino által termékesített készletből választhatók
(a vezető nem hoz létre szabad szöveges gyökeret); az alkategóriákat a vezető
szabadon kezeli a saját tenantján. Kategória nem törölhető, csak deaktiválható.
Indoklás: K-008 multi-tenant fegyelem és a koncepció 2.8 — a szabad
gyökér-gyártás a városok közötti adat-összehasonlíthatóságot és a termékesített
jelleget rombolná; a deaktiválás (törlés helyett) az adatintegritást védi.
(Forrás: `50_konfig` 2.2 és 2.4. Beszélgetés: 2026.05.14.)

**K-037 — A tenant a Beállításokban tartalmat konfigurál, nem brandet.**
A vezető a tenant nevét, logóját, kontakt-adatait állítja; nincs arculat-,
téma-, szín- vagy app-név-beállítás. Indoklás: K-007 egységes Urbino-brand és
a koncepció 2.8 — "egy Urbino app létezik, a városnév konfigurációs paraméter,
nem saját brand". (Forrás: `50_konfig` 5.1. Beszélgetés: 2026.05.14.)

**K-038 — A manager felület harmadik pilot-szerepköre a tartalomkezelő.**
A tartalomkezelő a polgári app puha tartalmát (hírek, városi programok, városi
információk) kezeli; nem lát bejelentést, triage-et, Dashboardot, Beállításokat.
A vezető ⊇ tartalomkezelő (a vezető alapból látja a tartalmi menüket is). Ha
egy ember diszpécser és tartalomkezelő egyszerre, a K-025 implicit unió-modell
szerint mindkét szerepkört megkapja. Indoklás: a tartalomfeltöltés egy 10.000
fős városban reálisan külön munkatárs dolga, és semmi köze a bejelentés-gerinchez;
ez valós munkamegosztás leképezése, nem szerepkör-burjánzás. (Forrás:
`60_tartalom` 2.; `00_architektura` 2.1. Beszélgetés: 2026.05.14.)

**K-039 — A polgári app puha tartalmát a város kezeli a manager felületen; a
GYIK ellenben Urbino-hatáskör.**
A hírek, városi programok és városi információk tenant-tartalmak — a város
maga tölti a manager felületen (K-008, a tartalom feletti kontroll a városé).
A GYIK ezzel szemben termékesített, Urbino-szintű tartalom, amelyet az
Urbino-admin felület kezel; a pilotra egyszeri feltöltéssel kerül a polgári
appba. Indoklás: a hír a város saját politikai/kommunikációs csatornája (Péter
pályája), ezért városi kontroll alatt kell állnia; a GYIK városok közt
nagyrészt közös, ezért termékesítendő (K-008, mint a kategória-gyökereknél —
K-036). (Forrás: `60_tartalom` 1. és 6.2. Beszélgetés: 2026.05.14.)

---

## Felülírt állítások (történeti)

> Itt szerepelnek azok az állítások, amelyek korábban kanonikusak voltak, de
> azóta finomodtak. A változás követhetősége miatt nem törlődnek.

**(K-003 előtti változat) — A városgazdálkodási céget célozzuk meg elsődlegesen,
nem a polgármesteri hivatalt.** Forrás: stratégia v1.0 4.3.
**Felülírva K-003-mal (2026.05.12):** a polgármester a kapuőr, a vásárló a
városgazdálkodási vezető. A két lépés szétválasztva.

**(K-006 előtti változat) — A termék magja négy felület együtt: polgári app,
diszpécser-felület, terepi mobilapp, vezetői riport-modul.** Forrás: koncepció
v0.2, 2.4.
**Felülírva K-006-tal (2026.05.13):** három felület együtt a mag (manager
felület, polgári mobilapp, terepi mobilapp). A vezetői riport-modul nem önálló
felület, hanem a manager felület egy nézete. A diszpécser-felület és a vezetői
riport-modul ugyanazon a manager felületen él, szerepkör-szintű elválasztással.

**(K-019 előtti változat) — Három csomagszint: Alap, Pro, Enterprise; az Alap
csak a polgári app + diszpécser.** Forrás: stratégia v1.0 5.1.
**Felülírva K-019-cel (2026.05.13):** két fő csomag (Pro / Enterprise) plusz
egy önkiszolgáló kistelepülési Sub-csomag. Minden csomag a négy felületet adja
mélység-alapú árazással; a koncepció K-006 állításával konzisztens. A
"fele értéket szállító Alap csomag" megszűnt.

**(K-020 előtti változat) — Pilot 1. évre névleges díj (300-500 ezer Ft),
2. évtől M-sávos listaár.** Forrás: stratégia v1.0 6.3.
**Felülírva K-020-szal (2026.05.13):** alapító ár 50% kedvezménnyel a Pro
listaárból. A 2. évi ugrás kommunikálható szintű (75-100%, nem 5-7-szeres).

---

## Nyitott szálak — más modulok funkcionális tervezéséhez

> Ezek **nem kanonikus állítások**, hanem a manager felület funkcionális
> tervezéséből származó, **más modulokban eldöntendő** kérdések. Itt
> rögzítjük őket, hogy a polgári mobilapp és az Urbino-admin tervezésekor
> ne vesszenek el. Forrás: `90_sitemap` 5.4, `manager_felulet_atadas.md`.

**A polgári mobilapp funkcionális tervezésekor eldöntendő:**
- A státusz-badge-leképezés (a manager öt állapota → polgári badge-ek).
- Az elutasítás és a duplikáció polgári oldali, méltóságteljes kommunikációja.
- A polgári elégedettség-mérés (ha a riportba elégedettségi szám kell).
- A kategória-fa végleges szerkezete (a manager és a polgári app közös fája).
- A tenant-kontakt mint közös adatforrás (a manager Beállításokból olvasva).
- A hír-push tényleges kiküldési mechanizmusa (a manager-oldali kapcsoló kész).

**Az Urbino-admin funkcionális tervezésekor eldöntendő:**
- A GYIK-szerkesztő felülete (a GYIK Urbino-hatáskör — K-039).

---

## Verziónapló

- **v1 (2026.05.12)** — Első kanonikus lista. 18 állítás v0.1-v0.3 koncepciós
  érlelésből, plusz versenytárs-tájkép és asset-feltárás. Egy korábbi
  stratégiai állítás felülírva (a vásárlási csatorna pontosítása).
- **v2 (2026.05.13)** — Árazási döntések beillesztése. Négy új állítás (K-019
  - K-022) az új árazási modellből. Két korábbi stratégiai állítás felülírva
  (5.1 csomagstruktúra, 6.3 pilot árazás). Összesen 22 aktív kanonikus állítás.
- **v3 (2026.05.13)** — Architekturális tisztázás a felületekről. K-006 átfogalmazva
  (négy felület helyett három, vezetői riport mint nézet a manager felületen).
  Két új állítás (K-023 polgári webes funnel, K-024 Urbino-admin külön belső
  felület). Összesen 24 aktív kanonikus állítás.
- **v4 (2026.05.14)** — A manager felület funkcionális tervezésének eredménye.
  Tizenöt új állítás (K-025—K-039): szerepkör-modell és navigáció (K-025—K-028),
  triage és státusz-modell (K-029—K-031), duplikáció-szűrés (K-032—K-034),
  vezetői riport (K-035), konfiguráció (K-036—K-037), tartalomkezelés
  (K-038—K-039). Felülírt állítás nincs. Új szakasz: "Nyitott szálak" a más
  modulokban eldöntendő, manager felületből származó kérdésekhez. Összesen
  **39 aktív kanonikus állítás**.