Self-serve branding archive must emit all four icon files (a partial archive now fails the tenant image build by design)

[mahmutkaya]

Owner: whoever builds the self-serve branding archive that build-tenant-image.yml consumes (branding_url).

What changed upstream

frontend piwas-21/restaurant-app-frontend#644 made the tenant branding contract six files, not three:

File	Used by
icon.svg	favicon + web app manifest vector icon
icon-192.png	manifest install icon, purpose: "any"
icon-512.png	manifest install icon, purpose: "any"
icon-maskable-512.png	manifest install icon, purpose: "maskable" (20% inset)
hero.png	home hero background
placeholder.png	menu item with no photo

A branding archive that carries icon.svg without all three PNGs now FAILS the tenant image build, by design, naming the missing files (scripts/apply-tenant-branding.sh in the frontend repo).

What this means for the generator

Any code that assembles a .tar.gz for branding_url must emit all four icon files, or the tenant image build stops. Supplying no icon at all is still legal and unchanged — that tenant inherits the whole platform icon set consistently.

The PNGs are rendered from the tenant's icon.svg: 192 px and 512 px on the plate colour, plus a 512 px copy inset 20% per side for the maskable variant. The originals were produced with headless Chromium; sharp is already a dependency of the frontend repo. Recipe in public/branding/README.md there.

Please do not "fix" this by restoring a fallback

The failure replaced a silent branding leak with a visible provisioning stop. Before #644 the workflow copied only icon.svg, hero.png and placeholder.png, while src/app/manifest.ts asked for the three PNGs. So a tenant that supplied its own branding got its own favicon in the browser tab and the SofraPiwas onion on its customers' home screens — another brand's mark on a paying tenant's phone, with nothing in the build log saying so.

The fail-loud rationale, quoted from #644 so the next reader has it here:

The fallback is the leak: keeping the platform PNGs under a tenant's own icon.svg is the exact mixed state this PR exists to stop. Generating them from the tenant's SVG would have to guess the design the platform set encodes (the #FCF6E6 plate, the 20% maskable inset) and would ship a wrong-looking icon just as silently — the same class of bug. A build that stops and names three files is the cheap failure, and branding archives are assembled by the founder / control plane, so the fix is "add three files".

So the correct fix on this side is emit the icons, never "let a partial archive through".

Related

• frontend fix(tenant-image): ship the tenant's own PWA install icons, not the platform onion restaurant-app-frontend#644 — the copy list, the shared script and the fail-loud rule.
• deploy feat(provision): forward the tenant PWA palette from the registry to the image build restaurant-app-deploy#159 — the sibling half: pwa_theme_color / pwa_background_color in tenants/registry.yml, forwarded to the image build. Worth knowing here because the generator's colours and the registry's colours must not become two opinions: absent defaults to RUMI red #c00000, so a control plane that generates a tenant's branding should generate the palette entry in the same place.