Contract-freeze · UX approval

Locked App Mode — Approval Frames

A locked product is served white-label on its own domain (and shipped as its own native app) with no indication FuzeFront is underneath — while still consuming the platform's authN, authZ, billing, payments, notifications, and sockets. Approving these frames approves the mode: locked + branding + native manifest model before any UI is implemented. Built in the fuse-seam design-system tokens.

Frame (a)

💬 White-label login

Locked-domain sign-in — product brand only, FuzeFront hidden; auth served same-origin.

mode = locked · branding · infra.auth
Frame (b)

🔒 Locked product shell

Product runs full-screen with its own chrome — no launcher, org-switcher, or return-to-portal.

mode = locked · chrome = none · infra hidden
Frame (c)

📱 Locked mobile shell

375px white-label surface with touch nav + safe-area — the TWA viewport.

mode = locked · viewport = 375
Frame (d)

🗂️ Separate native apps

Each product is its own installed app (own package id) — the Google/Zoho/Atlassian model.

native · one signed APK per product
Start the walkthrough →

Design write-up: DESIGN.md · Plan: docs/planning/locked-app-mode.md · Contract: services/app-registry-service/openapi.yaml (AppMode.locked, branding, native) · Gate spec: frontend/tests/locked-app-mode-frames.spec.ts

No flows declared in manifest.build.flows — nothing to approve.