diff --git a/TODO.md b/TODO.md
index aeece0c..710c3b6 100755
--- a/TODO.md
+++ b/TODO.md
@@ -123,6 +123,7 @@ Cél: az ügyfél önállóan, admin felületen szerkeszthesse a tartalmat — a
 | MITHOME-103 | Esemény-emisszió biztonsága: hitelesítés, rate limit, payload-validáció, elérhetetlenség-riasztás | 📋 |
 | MITHOME-105 | MITHOME-31 lezárása: elveszett üzenet bug összekötése a PLATFM-10 triázs pilottal | 📋 |
 | MITHOME-120 | Admin gyorskeresés (teljes szöveges kereső a Payload admin tetején) | ✅ |
+| MITHOME-121 | Partner logók soha nem töltődtek be a publikus oldalon (Media read access) + logo mező opcionálissá tétele | ✅ |
 
 ### EPIC: Többnyelvűség bevezetése — hu alapértelmezett + en (MITHOME-109)
 
@@ -206,6 +207,7 @@ docker-compose -f docker-compose.dev.yml down
 ---
 
 ## Frissítési Napló
+- **2026-09-12**: MITHOME-121 kész — a felhasználó kérésére a Partners `logo` mezője opcionálissá vált (`required: true` törölve; a frontend már eleve kiszűrte a logó nélküli partnereket). Eközben egy valódi, MITHOME-89 óta jelen lévő hiba is előkerült: a `Media` collection sosem kapott explicit `access.read`-et, így a Payload alapértelmezett "csak bejelentkezett user" szabálya miatt a `/api/media/file/*` route mindig 403-at adott — a Next.js image-optimizer emiatt sosem tudta betölteni a partner logókat a publikus oldalon (törött kép ikon, senki nem vette észre). Javítva: `access: { read: () => true }`. Staging-en emellett egy második, kapcsolódó hibát is találtam: a médiafájl fizikai byte-jai elvesztek egy korábbi (a `media_data_staging` volume bevezetése előtti) konténer-újraépítéskor — az árva Media rekord törlésével és a migráció volume-mountolt konténerből való újrafuttatásával helyreállítva. Élesben ellenőrizve mindkét helyen (helyi dev + staging).
 - **2026-09-12**: MITHOME-120 (admin gyorskeresés) kész — a felhasználó kérésére egy keresőmező került a Payload admin minden oldalának tetejére (`admin.components.header`), ami az összes Global + Collection összes szöveges mezőjét átkeresi mindkét locale-ban (kliens-oldali, index nélküli megoldás — `@payloadcms/plugin-search` aránytalan lenne a projekt méretéhez, ugyanaz az érvelés, mint MITHOME-118-nál). Útközbeni gotcha: a Payload komponens-útvonalak `process.cwd()`-hez (nem a config fájl mappájához) relatívak — dokumentálva. Élesben ellenőrizve böngészőben (Global + Collection találat is, helyes navigáció, 0 console hiba), a lint egy valódi hibát is elkapott (ref helyett state kellett). Staging-re is kideployolva.
 - **2026-09-11**: MITHOME-97 follow-up #2 — a felhasználó véletlen elgépelt egy URL-t (`stage.llmdev.mozdit.hu`), amire a Firefox valódinak tűnő "site could be impersonating" figyelmeztetést adott. Kiderült: egy elárvult `cms.stage.llmdev.mozdit.hu` nginx vhost a régi, leépített CMS-re (content-editor.js, port 4001, MITHOME-93) mutatott — a backend leállítva, de a vhost/tanúsítványa élt, nginx fallback-ként adta ezt bármilyen nem egyező `*.mozdit.hu` aldomainre. Megoldás: a vhost most a Payload admin felé proxyz (`/admin`, `/api/`, `/_next/` → staging app 127.0.0.1:8081), minden más redirect a kanonikus `stage.mozdit.hu`-ra — kényelmi admin-URL, meglévő tanúsítvány újrahasznosítva. Dokumentálva: `docs/nginx-vhosts.md` (eddig egyetlen nginx-konfig sem volt nyomon követve a repóban). Élesben ellenőrizve böngészőben (0 console hiba, bejelentkezés is működik ezen a domain-en).
 - **2026-09-11**: MITHOME-97 follow-up — automatikus, ismert Payload admin-felhasználó minden deploy után. `deploy.sh` a healthcheck után meghívja a Payload beépített `POST /api/users/first-register` végpontját `ADMIN_EMAIL`/`ADMIN_PASSWORD` alapján; ez a végpont csak üres `users` collection-nél enged létrehozást (403 minden további hívásra) — idempotens, sosem ír felül meglévő jelszót. Élesben ellenőrizve (friss DB → 200, ismételt hívás → 403, meglévő más-user-es DB → 403), majd staging-en ténylegesen bevezetve: `.env.staging`-hez szerveren generált admin jelszó, két egymást követő `deploy.sh staging` (első létrehozta, második helyesen kihagyta), bejelentkezés-teszt 200.