Platform console and setup

Separate spaces and identities

app.kelna.fr is the restaurant application. console.kelna.fr is reserved for the Kelna team. Platform accounts, session audiences, cookies and permissions are separate from manager access. A platform account cannot be a tenant member.

The console API exposes no room or public device-pairing routes. /api/platform/* routes exist only on the console server. Shared /api/account and /api/auth/* routes use the platform audience there; platform invitation activation must take place on the console.

Prepare a restaurant

1. Activate the platform account using the server operator invitation, configure two-factor authentication and keep backup codes.
2. Prepare a manager link in the console and deliver it privately. No email is sent automatically. The manager activates their account and MFA in the application.
3. Create a client with this owner and its first venue. Add more venues for a group if needed.
4. Import a JSON plan (maximum 64 KiB) with its thresholds. Inspect it before publishing. Fictional layouts are for tests only.
5. Create a tablet or pass code and enter it on that device. Use separate browser profiles for two device views on one computer.

Permissions and audit

Every client data read or modification is audited. Writes require a session under fifteen minutes old; sign in again when prompted. Actions require platform.read, platform.provision, platform.plans, platform.devices or platform.invite.

Links and codes remain in browser memory without local storage or logging. The API role has no direct platform account access. Only the server operator grants platform permissions.

Versions and lost responses

Create a client or venue with a caller-supplied UUID. Plan import uses id, expectedVersion and plan. After a lost response, retry the original identifier and content. Reusing an identifier for a different request is rejected.

A version conflict requires reading the latest plan and inspecting the draft. An open service keeps its plan and thresholds; the next version applies to the following service. Manager link and device code retries issue a new secret with its own expiry.

Separate VMs, one central API

Prepare one fictional client per isolated restaurant and a separate VM per restaurant. VMs act as client devices and do not host a copy of the Kelna database. Use one profile for the tablet and another for the pass; pair each with its own code.

Open concurrent services, verify restaurant isolation, disconnect only one VM and revoke only one device. In phase 1 an open pass keeps its last state in memory with an offline badge; new actions require the network. No edge box or camera is needed.

The console prepares these scenarios but does not create or manage virtual machines. The current instance is restricted to fictional data.