A ResidentFirst frontend (HRF-6) már ma sem mutatja meg az ingatlanhasználónak az
ÁSZF-et vagy a DPA-t — csak egy passzív "Adatvédelem" linket az Adatkezelési
tájékoztatóra, elfogadó checkbox nélkül, mert a lakó nem szerződő fél. A korábbi
ÁSZF VI. fejezete (lakói szabályok) emiatt gyakorlatilag halott szöveg volt: egy
B2B szerződésbe ágyazva, amit a címzettje soha nem lát.
Az ÁSZF-ből kikerült:
- VI. fejezet (lakói jogviszony, használat, ügyintézési felelősség, elállás) — a
helyén rövid hivatkozás az új dokumentumra
- IX.2 (fogyasztói jogérvényesítés) — az ÁSZF két megmaradt Felhasználója
(Kezelő, Szolgáltató partner) kategorikusan nem fogyasztó, ez a gépezet csak a
lakóra vonatkozott
- VIII.5, VII.2.3 lakó-említései — rövid hivatkozásra cserélve
- I.2.3 táblázat + I.2.4 — az ÁSZF hatálya explicit két félre szűkítve, kimondva
hogy a lakó nem Felhasználó e dokumentum értelmében
Új dokumentum: felhasznalasi-feltetelek-lakoknak.md — a fenti tartalom
tájékoztató jellegű, nem-szerződéses átfogalmazásban (nincs "elfogadom", csak
"Ön jogosult" jellegű megfogalmazás), kiegészítve a Békéltető testület
elérhetőségével.
Új dokumentum: adatkezelesi-tajekoztato-landing.md — a H2W Ticketing landing
oldal (demó igénylés, konzultációs jelentkezés, visszahívás-kérés és
online hívás widget, cal.diy időpontfoglalás, Umami) saját, jóval szűkebb
adatkezelési tájékoztatója. Eddig a landing a teljes SaaS-tájékoztatót
szolgálta ki (kezelő/partner/lakó szerepek, közös nyilvántartás stb.), ami
pontos volt, de irreleváns a látogató számára. A tényleges adatfolyamok
(server.js: /api/demo-request, /api/consultation-signup, /api/vapi-call,
/internal/consent) alapján íródott.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
A CI mostantól a build-manifest.py előtt lefuttatja a render-templates.py-t,
és a feloldott dokumentumokat is visszacommitolja a manifest+HTML mellé —
mostantól a _data.json / _templates szerkesztése önmagában elég, nem kell
kézzel futtatni és commitolni a render-templates.py-t. A trigger
paths-ignore-ja kiegészült a '*/*.md' mintával (a generált fájlok
commit-backje ne indítson újabb buildet), a _templates/ almappa mélyebben
van, így ez nem szűri ki a tényleges szerkesztéseket.
A "saját tulajdonú hardver" megfogalmazás mind a 4 dokumentumban javítva
"a Nethely Kft.-től bérelt szerver"-re — a tényleges konstrukció klasszikus
szerverbérlés, nem a Szolgáltató tulajdonában lévő, kolokált hardver.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
A négy H2W-Ticketing jogi dokumentumból eltűnt minden tervezet-jelleg:
- belsős "Megjegyzés a tervezethez" és "[Tisztázandó]" blokkok törölve
- minden [szögletes zárójeles] helyőrző valós adattal kitöltve
- elvi hibák javítva: az adatfeldolgozói melléklet aláírásmezővel és a
partner cégadatainak kitöltendő blokkjával rendelkező kétoldalú
szerződés volt, holott publikus HTML-ként szolgáljuk ki; a megszűnt
EU ODR-platform mint jogorvoslati fórum törölve; a DPA
al-adatfeldolgozó-táblájában szereplő Google Analytics javítva a
ténylegesen használt Umamira
- a HBus-12/HBus-16/HRF-A-7 YouTrackben eldöntött, de eddig meg nem írt
klauzulák bekerültek: SLA-jóváírás, AI-felelősségkizárás, kvóta- és
túlfutási szabályok, adatbázis-kötbér
Az ismétlődő adatok (szolgáltató azonosítója, tárhelyszolgáltató,
al-adatfeldolgozók) mostantól egyetlen helyen (_data.json) szerkeszthetők:
a H2W-Ticketing/*.md fájlok a _templates/*.md sablonokból generálódnak a
scripts/render-templates.py futtatásával. A generált fájlok tartalma
változatlan marad a build-manifest.py és a fogyasztó szinkron-szkriptek
számára — content_hash/version továbbra is a végleges, feloldott
szöveget hasheli.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
A Vapi tényleges retenciója 14-30 nap között van, csomagfüggő, nem a
korábban ígért 12 hónap. A döntés (HRF-42, 2026-08-01 komment): a jogi
szöveget igazítjuk a valósághoz, nem építünk saját tárolást.
Érintett: aszf.md 4.3, adatkezelesi-tajekoztato.md 5.1 tábla + 7. pont,
adatfeldolgozoi-melleklet.md 1. melléklet. Hatálybalépés: azonnali
(2026-08-05) — indoklás a HRF-42 kommentben.
Az ÁSZF saját 3.2. pontja "megismerhető, megjeleníthető és letölthető"
szöveget kér — ezt egy önálló (külső CSS/JS-függőség nélküli) HTML oldal
is teljesíti (böngészőből menthető/nyomtatható), külön PDF-render nélkül.
Ez NEM ugyanaz, mint a HRF-33/34 ajánlat-szerződés PDF-je — az egy
ténylegesen elfogadott, hash-elt clickwrap-példány, más indokkal; azt nem
érinti ez a változás.
Egyszerűsödött CI-környezet: WeasyPrint + natív libek (pango/cairo) törölve,
csak pandoc + python3 kell. A manifest "pdf" mezője megszűnt.
A rendereletHTML immár kicsi (nincs PDF), ezért a teljes dist/ kimenet
visszacommitolódik "manifest/" néven (nem csak a JSON) — a fogyasztók
ugyanazzal a git clone-nal a HTML-t is megkapják, nem csak a metaadatot.
A repó-szintű list-artifacts API üresen tért vissza egy sikeres v3
feltöltés UTÁN is (Gitea REST API hiányosság, nem valós hiány — a job
log megerősíti a sikeres feltöltést). Ahelyett, hogy erre az
API-viselkedésre építene, a HT-15 fogyasztóknak megbízhatóbb út: a CI a
kis JSON manifestet (nem a HTML/PDF-eket, hogy a repó ne hízzon) visszaírja
a repóba, ugyanoda, ahonnan a fogyasztók már ma is git clone-nal húzzák a
forrás markdown-t.
paths-ignore: manifest/** a push triggeren, hogy a visszacommitolás ne
indítsa el saját magát újra.
Az első valós CI-futás megmutatta: v4 újabb artifact-storage protokollt
használ, amit ez a Gitea-verzió (1.26.4) még nem támogat
("GHESNotSupportedError"). v3-mal a render+manifest lépés már bizonyítottan
lefut (pandoc HTML + WeasyPrint PDF mind a 4 dokumentumra), csak a feltöltés
bukott — ez javítja.
scripts/build-manifest.py: minden projekt-almappa .md dokumentumát
HTML+PDF-re renderel (pandoc → HTML, WeasyPrint → PDF, full_fonts=True —
lásd HRF-34, ugyanaz a determinizmus-óvintézkedés), és dist/legal-manifest.json-t
ír soronként: version (utolsó, a fájlt ténylegesen érintő commit rövid
hashe, NEM repo HEAD — HT-15), effective_from (a dokumentum saját
"Hatálybalépés napja" sorából parse-olva, null ha még [dátum] placeholder),
content_hash (a forrás git blob hashe, átmeneti megoldás, lásd a script
docstringjét).
.gitea/workflows/legal-manifest.yml: push/manual trigger, teljes (nem
sekély) checkout, pandoc+WeasyPrint telepítve explicit lépésként (nem
egyedi runner-image — így a CI-környezet a workflow fájlból látható és
reprodukálható).
Helyileg tesztelve: effective_from-parse, git_blob_hash, last_commit_hash,
pandoc HTML-render mind helyesen működik. A WeasyPrint-lépés Windows-on
nem tesztelhető (natív libek, lásd HRF-34) — a CI-futtatás bizonyítja.
A [dátum] placeholder mind a 4 dokumentumban (ÁSZF, Adatkezelési
tájékoztató, DPA-sablon, Impresszum) valós dátumra cserélve — Bence
döntése. Ez teszi lehetővé a HT-14/15 effective_from-alapú verzióválasztás
tényleges tesztelését.
A dokumentumok tartalma továbbra is tervezet — a "Megjegyzés a
tervezethez" szakasz és a [szögletes zárójeles] helykitöltők
változatlanok, ügyvédi review még hátravan.
